BMWによるコンテナ活用方法

こんにちは。Andreas Poeschl氏をお招きしました。彼はBMWのエッジコンピューティングとコンテナランタイムの責任者です。今回はBMWがコンテナをどのように採用しているかについてお話しします。ようこそ、Andreasさん。

お招きいただきありがとうございます。

早速ですが、BMWのハイレベルな取り組みについてお聞かせください。BMWにおけるITとアプリケーションの戦略的展望について、少しお聞かせいただけますか？

ええ、もちろんです。現在、新規ユースケースに最新要件を求める割合が大幅に増加しているため、BMWではパブリック・クラウド・ファースト戦略を推進しています。既存のワークロードをパブリッククラウドに移行し、パブリッククラウド上でのみ新規ワークロードを開発することで、パブリッククラウドサービスの利点を活用しています。それに加えて、エッジの領域もあります。つまり、私たちにとってパブリッククラウドとは、常にパブリッククラウド＋必要に応じてエッジという意味なのです。すべてクラウドネイティブのワークロードですから、クラウドネイティブでなければなりません。これは従来のIT2.0ではありません。完全に新しいコンセプトであり、新しいアプローチであり、新しい運用方法であり、新しい開発方法なのです。

なるほど。パブリッククラウドに移行する際、ある種の選択を迫られることになります。1つのクラウドに深くコミットして、そのクラウド上ですべてのサービスを利用できるようにするか、または、マルチクラウドを志向する人もいます。つまり、クラウドを使い続けたいのです。Kubernetesやクラウドネイティブ環境がもたらす利点の1つは、クラウド間を移動できることです。BMWはこの点について戦略を持っていますか？

はい、私たちは2つの主要なパブリッククラウドと連携しており、通常はアプリケーションやビジネスの分野によって使い分けています。そのため、すべての異なるプロセスにおいて、プライマリー・クラウド・プロバイダーは1社で、もう1社はセカンダリーです。しかし、インスタンスではなく、戦略的な観点から、ご指摘のように行ったり来たりできるようにしたいと考えています。つまり、同じサービスを別のパートナーでも利用できるようにしたいのです。

つまり、必要に応じて柔軟性を求めるということですね。

その通りです。クラウドプロバイダーにはそれぞれ長所と短所がありますから、アプリケーションやビジネスの各分野で、私たちの要件に最も適したサービスを活用したいのです。

たしかにその通りです。しかし、BMWについて考えてみると、御社は世界中で事業を展開しています。多くのアプリケーションをパブリッククラウドに移行している一方で、工場やその他の場所でもコンピュートニーズがあるはずです。そこで何を使い、パブリッククラウドに移行できないようなアプリケーションも実行しているのでしょうか？

現在私たちは、工場のデータセンターと中央の拠点で仮想マシンを使うという定番のセットアップを行っています。そして現在行っているのは、PaaSサービスやSaaSサービスを活用できるように、コアコンポーネントをパブリッククラウドに移行することです。一方、これらのアプリケーションの一部には、拠点に直接接続されているものもあります。そのため、生産システムと製造現場との接続が必要で、低レイテンシーが求められます。データ量が多く、大きなデータをクラウドに送ったり戻したりしたくない、あるいは送れない。そのため、このエッジ部分は主に工場内に設置する予定ですが、その他の小規模な拠点も考えられます。

レイテンシーと帯域幅の制約については理解しています。そこでどのようなアプリケーションを実行するのか、例を挙げていただけますか？

レイテンシーという点では、1つの例として、工場内に自動化された物流機器があり、そこでロジスティックトレインや自律的な物流要素を制御しようとしていると想像してください。時速6キロのかなり低速の車両の、パブリッククラウドまでの一般的なレイテンシーが50～60ミリ秒だとすると、この低速の車両が60ミリ秒以内に移動する距離は10センチメートルです。つまり、何かに衝突するのに十分な距離です。

エッジで1ミリ秒、2ミリ秒、3ミリ秒となると、5ミリになる。そのため、低レイテンシーが必要になります。また、同期通信を必要とする製造現場のコンポーネントとの通信も必要になります。クラウドに直接接続することはできません。

データ量が多いという点では、塗装工場や最終組み立て工程で、多くのカメラ、高密度、高解像度のカメラで車の写真やビデオを撮影し、問題やエラーを見つけ、視覚的な測定によって品質を向上させることを想像してみてください。エッジ上で前処理を行い、最終的な作業を中央のパブリッククラウド環境で行うことは非常に理にかなっています。
 

ありがとうございます。おかげで理解が深まりました。このようなアプリケーションは非常に興味深く、皆さんが直面している課題もよくわかります。このようなタイプのアプリケーションを見るとき、クラウドネイティブをアーキテクチャとして選んだ理由は何だったのでしょうか？BMWはなぜその方向に進んだのでしょうか？

過去には、メンテナンス、アップグレード、依存関係が常に問題の1つでした。したがって、もちろん、この古いVMベースのOS、モノリシックなスタイルから、コンテナ化され、オーケストレーションされた、Kubernetesを介した最新のアプリケーションへの移行は、私たちの観点からは自然な進化です。なぜなら、ワークロードと基礎となるインフラを最適に分離することができるからです。ダウンタイムゼロのメンテナンス（少なくともその計画をすること）を行う機会があり、システムの可用性が向上します。その一方で、すべてのコンポーネントが完全に内包されているため、すべてのコンポーネントが連携して動作することを確認するためのメンテナンスの労力を削減し、異なるコンポーネントのリリースサイクルを干渉することなく別々に行うことができるのです。

つまり、どちらもマイクロサービス・アーキテクチャを採用することで、おっしゃる通り、独立したサービスを個別に更新したり、入れ替えたりできるようになるわけですね。

そのとおりです。

なるほど。納得です。素晴らしいですね。さて、御社は工場でRancherをお使いですね。Rancherは御社のアーキテクチャや環境に何をもたらしましたか？工場にRancherを選んだ理由は何ですか？

私たちは、すべての工場と連携できる管理インターフェースを探していました。アプリケーショングループやDevOpsチームといった社内のカスタマーが、複数の場所にある複数のクラスタを同じ方法で管理できるようにしたかったのです。ユーザー管理に関しても、ポリシーに関しても。Rancherを高く評価しているのは、さまざまなインフラプラットフォームで作業ができることです。私たちは今、Harvesterを使用していますが、そこでは、私たちの標準的なサービスを、通常の購買から外して使用することができます。多くのディスクを搭載したサーバーを使い、Longhornと組み合わせてストレージシステムを構築し、Harvesterをベースとしたハイパー・コンバージド・インフラを構築しています。そして、Harvesterクラスタ自体で管理・保守することも、Rancherで管理・保守することもできます。この組み合わせは、作業の軽減というメリットをもたらしてくれます。

すばらしいです。御社の環境、御社の方針、御社のビジネスにフィットするツールがあったことをうれしく思います。これからも御社の成功を期待しています。では、BMW でのエッジとコンテナの今後についてお聞かせください。

いい質問ですね。実は、これはかなり新しい試みなのです。現在、私たちは経験を積み上げているところです。オンプレミスの分野で非常に優れた実績を残していますが、特定のワークロードについて、クラウドで多くの取り組みを始めました。しかし現在、このような従来のワークロードのパブリッククラウドへの移行や、最新のアーキテクチャ、最新のコンセプトへの移行を目の当たりにしており、Infrastructures as a ServiceからPaaSやSaaSサービスまで、より高いレベルのサービスを利用することができるため、IT全体の労力を大幅に削減できるのではないかと期待しています。その一方で、ビジネスのためのサービス向上、スピードや安定性を高め、可用性を向上させる。それが、パブリッククラウドとエッジへの移行を進める主な理由だと私は考えています。

御社は素晴らしい取り組みを始めているようですね。BMWがどのように革新を続けていくのか、楽しみにしています。貴重なお話しをありがとうございました。

こちらこそ、お招きいただきありがとうございました。