KubeCon+CloudNativeCon Japan 2026レポート 第3回

【KubeCon Japan 2026】スバルとヒュンダイがキーノートに登壇、ユースケースを語る

KubeCon+CloudNativeCon Japan 2026にて、スバルとヒュンダイがキーノートに登壇し、それぞれ自社の事例を紹介した。

松下 康之 - Yasuyuki Matsushita

6:01

KubeCon+CloudNativeCon Japan 2026の初日、2026年7月29日のキーノートセッションの一部として行われたスバルとヒュンダイのセッションを紹介する。製造業の両社だが、スバルのプレゼンテーションは運転支援システムのEyeSight開発に関わるプロセスの高速化、ヒュンダイはプライベートクラウドのリージョンを跨いでコンテナイメージの利用を可能にしたソリューションを解説する内容だ。

プレゼンテーションを行ったのはスバルが自動運転システムの開発部門に所属するDevOpsエンジニアの小林遼爾氏、ヒュンダイは子会社で2000年に創業された車輛向けのソフトウェア開発を専業とするHyundai AutoEver所属のDevOpsエンジニアであるJaewoo Choi氏だ。Choi氏はArgoCDのメンテナーでもある。

スバル

プレゼンテーションを行う小林氏

プレゼンテーションを行う小林氏

スバルのユースケースは今回のユースケースアワードを受賞しており、このプレゼンテーションではそのユースケースを解説する内容となった。

スバルの70年に及ぶ歴史を紹介。スライドに右上にEyeSightが掲載されている

スバルの70年に及ぶ歴史を紹介。スライドに右上にEyeSightが掲載されている

EyeSightについては、2030年に死亡に及ぶ交通事故をゼロにするという高い目標を掲げて開発が進められていることを紹介。スバルのEyeSightはLiDARを使わずにステレオカメラだけで道路や車線、車輛、歩行者、障害物などを認識する独自の機械学習システムでAMD/XilinxのSoC上で構築されている。スバルはセンサーから画像処理のロジック、制御ソフトウェア、実行する半導体の仕様まで社内で開発するという上から下まで一貫して社内開発を貫いている企業だ。このプレゼンテーションは画像処理を行うデータを収めた巨大なコンテナをいかに高速にGPUサーバーでトレーニングさせるか? という課題に挑戦したことを解説するものだ。

次世代のEyeSight開発にAIが利用されることを紹介

次世代のEyeSight開発にAIが利用されることを紹介

スバルが抱えていた課題について3つの軸で解説。ここでは巨大な学習データを収めたコンテナイメージをリポジトリーからGPUサーバーにプルする際の通信時間が最大で約3時間という時間がかかっていたこと、Kubernetes上でのイメージのプルや学習データの用意などのステップがすべてHelmのコマンドラインを実行するというマニュアル操作になっていたこと、そしてステップ自体をワークフローとして自動化していなかったことを挙げて順に説明を行った。

3つの課題を紹介

3つの課題を紹介

専用の高速ネットワークを用意して転送速度を改善

最初に紹介したのはコンテナイメージをプルする時間の削減という課題だ。

巨大なデータを収めたコンテナイメージをGPUサーバーに転送するのに最大3時間必要

巨大なデータを収めたコンテナイメージをGPUサーバーに転送するのに最大3時間必要

ここでは通常のサーバー間をつなぐ通信経路を使ってコンテナイメージを転送していたが、最大約3時間という常識を超えた通信時間が必要だったという。そのためより高速な通信を行えるネットワークを用意して、GPUサーバーと接続、高速にコンテナ転送が可能になったことを説明した。

GPUサーバーと高速な接続を行うことで通信時間が3分程度に短縮

GPUサーバーと高速な接続を行うことで通信時間が3分程度に短縮

ここではコンテナリポジトリ―としてHarborが使われていることがわかる。

ArgoCDの導入により自動化を実現

コンテナ回りの複数の処理がすべてHelmのコマンドラインに依存していたという問題には、ArgoCDを使ってパイプラインを実装し、自動化を行ったことを説明した。

HelmのコマンドラインからArgoCDのパイプラインで自動化

HelmのコマンドラインからArgoCDのパイプラインで自動化

マニュアルでのコマンド実行からArgoCDによるパイプラインになったことで並列実行も可能になり、各自のコマンドラインからGitに格納されたテンプレートを使ってプロセス自体がコード化されたことも大きな違いだろう。

複数のコマンドラインがArgoCDのワークフローで実装された

複数のコマンドラインがArgoCDのワークフローで実装された

改善のまとめとしてコンテナイメージのGPUサーバーへの転送は60倍高速になり、GitOpsの導入でカタログ化され、機械学習のワークフローもArgoCDによって整理されたことを解説した。

3つの課題解決の結果を紹介

3つの課題解決の結果を紹介

今後の予定については、複数のGPUサーバーで分散学習を行うことやエッジデバイスへの実装を自動化することなどを挙げた。

これからの開発予定などを紹介

これからの開発予定などを紹介

ヒュンダイ

次に登壇したのはヒュンダイのJaewoo Choi氏だ。

登壇したJaewoo Choi氏。ArgoCDのメンテナーを務めていることはポイントだ

登壇したJaewoo Choi氏。ArgoCDのメンテナーを務めていることはポイントだ

まずはヒュンダイが展開するプライベートクラウド、ここではHKS(hCloud K8s)と記載されているが、バニラなKubernetesをサービス化して社内向けに提供するという多くのKubernetes導入企業と同様の施策を行っていることを紹介。コンテナのデリバリーにはArgoCD、リポジトリーにはHarborを使っていることも紹介。このArgoCDとHarborという組み合わせは、期せずしてスバルとも同じということになる。

インフラはKubernetes-as-a-Service、デリバリーはArgoCDとHarbor

インフラはKubernetes-as-a-Service、デリバリーはArgoCDとHarbor

Choi氏が解説するインフラストラクチャーは5000以上のアプリケーションが300台以上のクラスターで実行されているとして、その中核となるCI/CDにArgoCDが存在していることを紹介。

CI/CDの中核はArgoCDで構成されている

CI/CDの中核はArgoCDで構成されている

しかし、韓国のリージョンにあるリポジトリーからヨーロッパや北米などの外部のリージョンにコンテナのデリバリーができない仕様になっていたと説明。これが今回の課題となる。

韓国のリージョンから海外のリージョンにコンテナのデリバリーができなかった

韓国のリージョンから海外のリージョンにコンテナのデリバリーができなかった

そのためリージョンごとにHarborによるリポジトリーを構成し、高速にアプリケーションのデリバリーが可能になったという。ここではHarbor同士がレプリケーションを行うことでローカルのリポジトリーからのアクセスが可能になったという。

リージョンごとに置かれたHarborがレプリケーションを行うことでイメージを複製

リージョンごとに置かれたHarborがレプリケーションを行うことでイメージを複製

最後のスライドではCNCFのプロジェクトを使うだけではなく、それをヒュンダイ流に言えば、チューンアップすることで最大の効果を得られるようになると説明。これがタイトルにある「Out of the Box」の意味であると説明した。日本の企業ではよくあるように、業務の仕様に合わせてソフトウェアの仕様を魔改造することで機能を実現するのではなく、ソフトウェアの仕様に合わせて業務を変えるということを暗に示唆しているのかもしれないが、筆者的には「Keep tuning as we grow」の下に小さな文字で書かれた「and contribute back to upstream projects:) 」にも注目したいところだ。

企業が利用するオープンソースソフトウェアの消費者のままでいるのではなく、中核となるソフトウェアについては積極的にコミュニティに参加し、コードを貢献し、コミュニティの負担を軽減するための労力を費やそうという意味だが、小さな字で書かれているということにヒュンダイとしての立ち位置が現れているように思える。ヒュンダイがこの1文をスライドのタイトルに掲げられるようになるのはいつになるのか、このような表明がなかったスバルは相変わらずオープンソースの消費者的な立ち位置だが、それが変わることがあるのか、どちらの企業も引き続き注視していきたい。

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored