re:Invent 2024: BMWがAWSで実現したグローバル開発基盤CodeCraftの進化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Learnings from BMW's global software development platform on AWS (AUT319)
この動画では、BMWのソフトウェア開発プラットフォーム「CodeCraft」のAWSへの移行事例が紹介されています。2,000人以上の開発者が利用し、1日165,000回のビルドを処理するCodeCraftは、オンプレミスでのスケーリング課題を解決するためにAWSへの移行を決断しました。EC2インスタンスの最適化やKarpenterの導入により、インフラのコストを最大66%削減。さらにEC2 Spotインスタンスの活用を44%まで高め、月間6桁ドルのコスト削減を実現しています。EC2 FleetやSpot Placement Score Trackerなどのツールを活用し、Spotインスタンスのリクレーム対策も実施。結果として開発者の生産性向上とコスト効率化の両立に成功し、Automotive Congressでビジネスインパクト部門の表彰も受けています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
BMWのソフトウェア開発プラットフォーム「CodeCraft」の紹介
皆様、こんにちは。AWS Principal Solutions Architectのクリスチャン・ミュラーと申します。本日は、BMWのセリーヌ・ローラン＝ウィンターさんと一緒にプレゼンテーションをさせていただきます。私は過去18ヶ月間、BMWのSoftware Factoryの一部であるソフトウェア開発プラットフォームチームと密接に協力してきました。この期間中、BMWの現在および将来の規模、信頼性、コスト効率に関する要件を考慮したハイブリッドソリューションを設計しました。本日は、その内容を皆様と共有させていただきたいと思います。
詳細に入る前に、セリーヌから、なぜ自動車業界において今日ソフトウェア開発がこれほど重要なのかについて説明させていただきます。また、BMWの社内で「CodeCraft」と呼ばれているソフトウェア開発プラットフォームについてもご紹介します。 このプレゼンテーションの大部分では、私が学んだことや成功事例について詳しくお話しし、皆様と共有させていただきます。その後、セリーヌが私たちの達成したビジネス成果について締めくくらせていただきます。
自動車業界におけるソフトウェア開発の重要性とCodeCraftの課題
皆様、ご参加ありがとうございます。セリーヌと申します。BMW GroupのVice President of Connected Vehicle Platformsとして、プレミアムで革新的なコネクテッドドライブサービスを提供するチームを率いています。これは、エンターテインメントシステムなどの車載機能と、AWSで稼働するバックエンドサービスとの完璧な連携があってこそ実現できることです。
自動車業界において、なぜ今日ソフトウェア開発がこれほど重要なのかについてお話ししましょう。現代の自動車には、大小様々な電子制御ユニットが数百個も搭載されています。最近のトレンドは、機能をドメインごとにまとめるドメインアーキテクチャに向かっています。例えば、レーンキープアシストとアダプティブクルーズコントロールは、自動運転ドメインの一部です。これらの高性能な電子制御ユニットは、車両ネットワークとセントラルゲートウェイを介して相互に通信を行っています。
つまり、BMW 7シリーズのような現代の車両には、社内外のソフトウェア開発者によって開発された5億行以上のコードが含まれており、最も複雑な製品の一つとなっています。BMWが提供している様々なモデルや、私たちが展開している市場の多様性を想像してみてください。例えば、イギリスとニュージーランドでは左側通行のため、自動運転機能に関して異なるソフトウェア要件が必要になるといった具合です。
そのため、私たちは早い段階で、勝利への足がかりとなるプラットフォームとしてCodeCraftを開発しました。CodeCraftには、コードリポジトリ、アーティファクトリポジトリ、CIパイプライン、イシュートラッカーなど、このような開発者プラットフォームに期待される多くのツールやサービスが含まれています。当初、このプラットフォームはオンプレミスでしたが、その成功に伴い、多くのスケーリングの課題に直面していました。そこで、AWSでCodeCraftを拡張するための計画についてAWSと協議を始めました。
これらの課題について見ていきましょう。CodeCraftには2,000人以上の開発者が携わっており、1日あたり165,000回のビルド、そして5,500のビルドが同時並行で実行されています。これは、同時に85,000の仮想CPUを使用していることを意味します。 チームは3つの重要な成功要因に焦点を当てています。
まず第一に信頼性、次にビジネスへの影響（これは開発者の生産性に直結します）、そしてコスト効率です。プラットフォームの成功により、すべての開発者がこれを使用したいと考える中で、私たちは信頼性に関して大きな課題に直面していました。多くのジョブがパイプラインで待機状態となり実行できないため、開発者の生産性が低下し、スケーリングにおいても大きな課題に直面していました。オンプレミスでコスト効率よくスケールすることはほぼ不可能だったため、私たちはAWSに支援を求めました。この点についてはChristianが説明してくれます。
AWSを活用したCodeCraftの進化と成果
ありがとう、Céline。 BMWが使用していたオンプレミスのリソースがすべてライフサイクル終了を迎えたわけではなかったため、まずは全体的なアーキテクチャの概要から説明させていただきます。そこで私たちは、必要に応じて特定のワークロードをAWSに移行できるハイブリッドソリューションを設計しました。最初に、 堅牢なネットワークインフラを確立し、その後、GitHubやArtifactory、BuildStreamやCI/CDなどのコアサービスをAWSに移行または複製しました。これはAWSで最初のビルドを実行するための前提条件に過ぎませんでした。
過去 15ヶ月にわたり、インフラストラクチャとCIジョブの大部分をAWSに移行しました。これが右側のオレンジ色で示されている部分です。今後12ヶ月で、残りのCIジョブもAWSに移行する予定です。これは、これらのリソースもオンプレミスでライフサイクル終了を迎えるためです。では、AWSへの移行による最大の改善点と学びについて話しましょう。もちろん、手っ取り早い成果の1つは、可能な限り早く最新のEC2インスタンス世代に移行することでした。 例えば、CodeCraftのGitHubリポジトリをm6インスタンスまたはm6aインスタンスファミリーから、より新しい世代のm7aインスタンスファミリーに移行したとき、git pushとgit cloneの操作における平均レイテンシーとピークレイテンシーの低減を測定することができました。
私たちが当初から自問していたもう1つの疑問は、これらのEC2インスタンスがBMWのジョブに対して適切なサイズになっているかということでした。BMWが毎日実行している16万5千のジョブのそれぞれが、マルチテナント環境でのビルド間の副作用を防ぐために、新しくプロビジョニングされたEC2インスタンス上で実行されているのです。これらのCIジョブは、2 vCPUマシンで数分間だけLintingを実行する小規模なものから、192 vCPUマシンで数時間かけて大規模なインフォテインメントシステムをビルドするものまでさまざまです。通常、AWSではCompute Optimizerを使用してEC2インスタンスのライトサイジングの推奨事項を得ることができますが、これらのジョブは最大でも数時間しか実行されないため、Compute Optimizerからこのような推奨事項を得ることはできません。
そこでチームは独自のソリューションを考案する必要がありました。CodeCraftは、CPUやメモリの使用率、ネットワークやI/O使用率など、あらゆる種類のオペレーティングシステムメトリクスを収集できるオープンソースのLinuxユーティリティであるsysstatを採用しました。CodeCraftはこれをビルド実行用のベースとなるAmazon Machine Imageに組み込み、sysstatが生成するメトリクスファイルは各CIジョブの終了時にS3にアップロードされます。その後、このメトリクスファイルは自動的に分析・可視化され、特定のCIジョブが適切なサイズのEC2インスタンス上で実行されているかどうかについて、プラットフォームチームと社内チームに洞察を提供します。
さらに、チームは特定のCIジョブの実行時間に関するメトリクスも収集しており、これにより異なるCPUベンダーやアーキテクチャを簡単にベンチマーク比較することができます。AMD CPUとIntel、Amazon Gravitonを比較したところ、ビルドの種類やCPUベンダーによってかなり大きな違いが測定されました。
CodeCraftはコアサービスとソーシャルサービスをコンテナ化し、AWS上で実行するためにAmazon EC2を選択しました。当初は、需要の変動に応じてコンピュートインスタンスを調整する従来のKubernetesクラスターオートスケーラーを使用することにしました。今年3月、チームはAWSがイニシアチブを取ったオープンソースプロジェクトである柔軟なKubernetesクラスターオートスケーラー、Karpenterに移行することを決定しました。Karpenterに移行することで、チームはAWSインフラストラクチャのコストを最大66%削減することができました。
この成功には主に2つの理由があります。1つ目は、KarpenterがEC2インスタンスの使用率を常に最適化し、インスタンス間でコンテナを移動させることです。Karpenterは適切なサイズのEC2インスタンスをプロビジョニングし、不要になったインスタンスを終了させます。これによりCodeCraftは、EC2インスタンスの使用率を94%近くまで高めることができました。2つ目は、KarpenterがEC2 Spotとうまく連携し、オンデマンドと比較して最大90%割引で未使用のEC2キャパシティを利用できることです。
EC2 Spotについて簡単におさらいさせていただきます。Spot instancesは、On-demand instancesやReserved instancesと何ら変わりはありません。単にAWSの未使用のEC2キャパシティを、On-demand instancesと比べて最大90%割引で提供しているものです。ただし、注意していただきたいのは、On-demandで追加のキャパシティが必要になった場合、そのインスタンスを取り戻す可能性があるということです。その際は中断通知を送信し、2分後にインスタンスを終了して回収します。そのため、複数のインスタンスタイプを使用してSpot fleetを分散させることが重要になります。
これは具体的にどういうことでしょうか？例えばC7iインスタンスタイプの場合、AWSの各リージョンの各Availability Zoneにおける各インスタンスサイズが、それぞれ個別のSpotプールとなります。もし、これら10種類のインスタンスファミリーのいずれかでワークロードを実行でき、さらに3つのリージョンの3つのAvailability Zoneで、extralargeとlargeのインスタンスサイズで実行できるとすれば、190の異なるSpotプールにアクセスできることになり、Spotが回収される可能性が大幅に低下します。
CodeCraftがSpotを採用した際、彼らは自社のCIツールであるZuul CIを活用していました。 Zuul CIはEC2 run instance APIを使用して、単一のインスタンスをリクエストまたは起動します。私たちAWSのチームは、Spotプールの可視性に基づいて、Spot回収が最も少なくなるインスタンスタイプについて、CodeCraftにアドバイスを提供していました。しかし、これはスケーラブルなソリューションではなく、日々変化する可能性があります。
そこで、私たちはCodeCraftチームと協議し、EC2 Fleetへの移行を決定しました。 EC2 FleetでもCodeCraftは単一のEC2インスタンスを起動しますが、EC2 Fleetではワークロードを実行可能なEC2インスタンスタイプのリストを提供できます。
具体的には次のような形になります：まず、アロケーション戦略を定義します。私たちは最初にcapacity optimizedを選択しました。これは、AWSが回収される可能性が最も低いインスタンスタイプを選択するというものです。次に、launch templateを設定し、名前を付けます。最も重要なのは、このワークロードを実行できる11の異なるインスタンスタイプを最初に選択したことです。最後に、target capacityとcapacity typeを指定します。これらの機能は、私たちがアップストリームのオープンソースプロジェクトに貢献したもので、現在ではZuul CIとAWSを使用するすべてのユーザーが活用できるようになっています。
これはBMWのFinOpsツールのスクリーンショットです。 下の表を見ると、2023年1月時点ではCodeCraftのSpotインスタンスの利用率はわずか2%でした。それが2024年10月には44%まで増加しています。これがまさに、CodeCraftが現在Spotインスタンスを使用することで、毎月6桁ドルという大きなコスト削減を実現できている理由です。しかし、すべてが期待通りにスムーズだったわけではありません。CodeCraftチームは当初の予想をはるかに上回るSpotリクレイムを経験しました。Spotインスタンスによる大きなコスト削減のメリットは依然としてありますが、リクレイムが発生すると、CIジョブは新しいインスタンスで再スケジュールされ、最終的には完了します。ただし、変更をプッシュした開発者は、フィードバックを受け取るまでの遅延が長くなり、開発者の生産性低下につながる可能性があります。これは私たちが目指すものとはまさに正反対です。
AWSが推奨するツールの1つが、 Spot Placement Score Trackerです。これを使用することで、より良い理解や客観的な見方を得ることができます。このツールは、Spotリクエストが成功する可能性を示す指標であるSpot Placement Scoreを測定・収集し、CloudWatchに保存します。すべてのEC2 Fleet設定に対してこれを継続的に行うことで、設定したEC2 Fleetを使用した場合の体験がどのようになるかを客観的に示すダッシュボードを提供します。
さらに、私たちはEC2 Instance Selectorを使用しています。これはCLIツールで、 CPU、メモリ、CPUアーキテクチャなど、多くのパラメータでコンピューティング要件を指定できます。その結果として、 要件に合致するインスタンスタイプのリストが得られます。ここでは、最初に選択した11のインスタンスタイプをすべてハイライトしています。一定のパフォーマンスが必要なため、バースト容量を持つインスタンスをすべて除外すると、まだ設定していない使用可能なインスタンスタイプがかなりあることがわかります。
この学びを活かして、 初期のEC2 Fleet設定に戻り、これら20のインスタンスタイプを追加しました。これにより、活用するSpotプールを3倍に増やし、300のSpotプールを利用できるようになりました。さらに、割り当て戦略をprice-capacity optimizedに変更しました。これにより、AWSはリクレイムの可能性が最も低いSpotプールの中から、最も安価なインスタンスタイプを選択します。これにより、すでに 過去に見られたSpotリクレームの数を減少させることができました。私たちはさらにSpotリクレームを減らせると考えており、いくつかの変更を準備中です。ここで、ビジネス成果についてCélineに引き継ぎたいと思います。CodeCraftチームは、顧客である開発者の満足度を測定してきました。
AWSの利用を開始して以来、顧客満足度スコアは着実に向上し続けており、一度も中断することはありませんでした。Automotive CongressはCodeCraftをビジネスインパクト部門で表彰しました。これは、必要に応じてジョブをスケールできるようになり、コードのプッシュからエンジニアへのフィードバックまでの応答時間を短縮できたことが評価されたものです。
開発者の生産性が向上し、これは私たちの主要な目標の一つである、ビジネスへのより良いインパクトと市場投入までの時間短縮につながりました。また、プラットフォーム全体のコストを削減することで、コスト効率も達成しました。しかし、より重要なのは、ジョブあたりのコストがまだ完了していないということです。プラットフォームのワークロードが増加しているため、コスト効率の良いスケーリングに引き続き取り組み、より持続可能な未来に貢献していく必要があります。
ご清聴ありがとうございました。1分ほどお時間を頂き、セッションの評価をしていただけますと幸いです。ご質問がございましたら、喜んでお答えいたしますので、しばらくこの場に残らせていただきます。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion