re:Invent 2024: RivianがAWSでADAS開発を加速 - Polarisプラットフォーム事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - How Rivian accelerated ADAS development on AWS (AUT318)
この動画では、RivianのADAS（Advanced Driver Assistance Systems）開発をAWSで加速させている事例が紹介されています。Rivianは13以上の自律走行機能と20以上の安全機能を搭載したADASを開発しており、そのために構築したPolarisプラットフォームの詳細な技術アーキテクチャが解説されています。AWS Data Transfer TerminalやS3 Intelligent-Tiering、AWS Batchなどを活用し、ペタバイト規模のデータ処理、モデルトレーニング、シミュレーションを効率的に実行。特にAWS Batchでは200倍のスケールアップを実現し、S3 Intelligent-Tieringの導入でストレージコストを30%削減するなど、具体的な成果も示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Rivianとの協力：ADASの開発加速に向けて
皆様、こんにちは。本セッションにご参加いただき、ありがとうございます。おいしいランチを召し上がり、re:Inventを楽しんでいらっしゃることと思います。アメリカで販売される車両の90%以上が5つ以上のADAS機能を搭載していることをご存知でしょうか？そのため、ADASは私たちのお客様にとって重要な戦略的ワークロードとなっています。私はAWSのSenior Solutions ArchitectのVenkat Devarajanです。本日は、アドベンチャラスなEV車で知られるRivianをお迎えして、RivianがAWSでどのようにADAS開発を加速させているかについてご紹介させていただきます。本日は、AutonomyグループのシニアマネージャーであるMadan Thotaさんと、Lead Software EngineerのNarendra Challaさんにもご登壇いただきます。
アジェンダを簡単にご紹介させていただきます。まず、自動車業界のお客様、特にADAS機能開発に関して見られるトレンドと課題についてお話しします。その後、MadanさんにRivianのADASについてお話しいただき、AWSで構築された自動運転プラットフォームPolarisについても少しご紹介いただきます。続いて、Narendraさんからデータ取り込み、シミュレーション、モデルトレーニングワークロードに関するAWSアーキテクチャの詳細をご説明いただきます。また、これまでの重要な学びについてもご紹介させていただきます。
ADASの概要と自動車業界の課題
ADASについて簡単にご説明させていただきます。ADASとは、Advanced Driver Assistance Systemsの略で、ドライバーの快適性と安全性を支援する機能群のことです。例えば、自動緊急ブレーキや車線変更支援などが挙げられます。自動車技術者の団体であるSAEは、自動運転のレベルを5段階に分類しており、ADASはレベル2から2.5に該当し、レベル4、5になると自動運転車へと進化していきます。ADAS機能は、車両に搭載された走行モデルによってリアルタイムで実現されます。各種センサーからのデータがこの認識モデルに入力され、そのモデルの出力とHDマップを組み合わせて、パスプランニングモジュールが車両を制御します。
ADASの機能開発の流れについてご説明します。中心にストレージとコンピュートがあり、基盤としてフレームワークとソリューションが存在します。 すべてはデータ収集から始まります。OEMが保有する特別な計測機器を搭載したテスト車両でデータを収集し、そのデータをAWSに取り込みます。エッジでデータ処理を行うこともありますが、最近では大部分のデータ処理がクラウドで行われる傾向にあります。 Amazon S3がこのデータの保存先として広く採用されています。データが取り込まれると、準備とキュレーションが行われます。ここでは、データが有効で使用可能であることを確認し、データセットを検索できるようにメタデータを抽出します。その後、バウンディングボックスの追加やオブジェクトの識別などのデータラベリングを行います。また、HDマップや制限速度などの追加データソースでデータセットを補強します。
これで自動運転チームの開発者がモデルを構築できるデータセットが整いました。モデルとアルゴリズムの開発が行われ、堅牢なシミュレーション検証フェーズを経ます。ADASモデルのパフォーマンスに満足できたら、テスト車両群でテストを行います。テスト車両でKPIを満たしたモデルは、最終的に実際の量産車両に展開されます。
それでは、お客様の間で見られるトレンドと課題についてご説明していきましょう。 データの取り込みと容量は、様々なワークロードで共通して見られるテーマですが、ADASではさらに顕著です。ADAS レベル2システムでは1時間あたり最大400ギガバイトのデータが生成され、レベル3システムでは1時間あたり10テラバイト以上のデータが生成されます。そのため、このデータを効率的に処理・保存するメカニズムが必要となります。 次の課題はツールチェーンの複雑さです。現在、お客様がADAS開発を加速するために利用できるツールは300以上あり、多くの場合、これらの複数のツールを組み合わせて使用する必要があります。 最後に、市場投入までの時間です。ADAS機能の開発は、リソースを大量に必要とするプロセスで、その本質的な複雑さから開発サイクルが長くなりがちです。また、人命の安全性に関わるため、厳密な検証・認証プロセスが必要で、OEMが従うべき規制基準も存在します。
AWSによるADAS開発支援：データ取り込みからシミュレーションまで
これらのトレンドと課題を確認したところで、AWSがどのようにサポートできるかを見ていきましょう。最初に見た課題であるデータ取り込みについて、これまでお客様がAWSにデータを取り込む方法は2つありました。テスト車両をOEMの拠点まで運転して戻すか、ハードドライブを輸送するかのいずれかです。
どちらのアプローチにも大きな課題があります。最初のアプローチでは、データをアップロードするために車両が長距離を走行する必要があります。ハードドライブの輸送は、バックアップドライブの管理を含め、物流面での課題があります。どちらのシナリオでも、データ収集からモデル開発者が利用できるようになるまでの時間が大幅にかかってしまいます。
この課題を解決するため、re:InventでRivianとの共同開発によるAWS Data Transfer Terminalを発表しました。これは世界中に設置された物理的な拠点で、テスト車両が最寄りの場所でデータをアップロードできます。予約を取って施設を訪問し、データを直接S3バケットにアップロードすることができます。これらの拠点はAWSのバックボーンネットワークに接続されています。Rivianの自動運転部門VPは、Data Transfer Terminalの使用により、従来の方法と比べてデータの利用可能性が3倍に加速したと報告しています。
データ容量の課題に移りますと、S3はデータレイクの構築に人気のある選択肢となっています。一部のお客様は、シミュレーションやモデルトレーニングなどのワークフロー向けに、S3から専用のファイルベースシステムにデータを移動していますが、最近では、より多くのお客様がS3から直接データを使用する傾向が増えています。ストレージサービスは、パフォーマンスとコストの要件に基づいて慎重に選択する必要があります。しかし、S3にはいくつかの利点があります。 AZ間のデータアクセスを提供し、高い回復力と可用性を実現するために複数のアベイラビリティーゾーンで実行されるコンピュートクラスターが、リージョン内のデータにシームレスにアクセスできます。
Intelligent-tieringによるコスト最適化と、特にADASによるデータ量の爆発的な増加に対応するため、コスト効率の良いデータストレージの仕組みが必要です。Intelligent-tieringは低コストのアーカイブ層を提供し、アクセスパターンに基づいて自動的にデータを低コスト層に移動させます。Rivianはデータを直接Intelligent-tieringにアップロードしており、後のスライドでコスト削減効果を共有する予定です。 S3のパーティションは最大で5,500のGetトランザクションと3,500のPutトランザクションをサポートし、バケット内のパーティション数に制限はありません。キーの命名方式にエントロピーを導入することで、さらに高いGetおよびPut TPSをサポートすることができます。
アプリケーションによってはファイルシステムベースのアクセスインターフェースが必要な場合や、S3 APIを使用するようにアプリケーションをリファクタリングする必要がある場合があります。 これに対応するため、ファイルシステムコールをS3 APIコールに変換するオープンソースのファイルベースクライアントであるS3 Mountpointを提供しています。図に示すように、下部にストレージ、中央にコンピュートがある構成で、MountpointはEC2、Elastic Container Service、Elastic Kubernetes Serviceなど、複数のコンピュート環境にシームレスにアクセスできます。
Mountpointはデータキャッシングをサポートしており、ほとんどの場合、 複数のエポックで同じデータにS3からアクセスします。オブジェクトキャッシングにより、2倍速い読み取りを実現できます。MountpointはAWS APIのベストプラクティスを実装したCライブラリセットであるCommon Runtime（CRT）上に構築されています。大きなオブジェクトのダウンロードでは、ネットワーク使用率を最適化するために複数のバイトレンジフェッチを実行します。さらに高いスループットを実現するため、MountpointはS3 Express One Zoneと連携してランダムリードで6倍のスループットを達成します。
次にツールチェーンの複雑さという課題に対して、 AWSは目的に特化したツールの開発に投資して、AWS開発を加速させています。先ほどData Transfer Terminalの例を見ましたが、ここでは特に2つのソリューションについて説明したいと思います：Autonomous Driving Data Framework（ADDF）とVirtual Engineering Workbenchです。ADDFはオープンソースプロジェクトで、データ取り込み、シミュレーション、可視化などのAWS機能開発における一般的なタスクのモデルアーティファクトを提供します。これらのモデルはそのまま使用することも、要件に合わせてカスタマイズすることもできます。Virtual Engineering Workbench（VEW）は、事前設定された環境を含むセルフサービスポータルとしてユーザーインターフェースを提供します。これらの環境には必要なツールセットが適切にインストール、設定され、ライセンスが管理されており、開発チーム全体での一貫性を確保し、新しい開発者の立ち上げを迅速化します。
最後の課題である市場投入までの時間短縮に関して、CUのMatt Garmanが基調講演で述べたように、私たちはIntel、NVIDIA、AMDのチップを最初に導入しました。 また、トレーニング機能を備えた独自のカスタムアクセラレーターも提供しています。GPU分野は大規模言語モデル分野と同様に急速に進化しているため、最新のGPUインスタンスへのアクセスが重要です。また、短期的な実験のためにGPUキャパシティを確保できるキャパシティブロックも提供しています。このre:Inventでは、Instance StopやInstance Storeを含む、キャパシティブロックへの複数の改善が発表されました。また、Qualcommとパートナーシップを組み、クラウドでの推論実行を支援するDeal 2Qインスタンスを発表しました。
AWS Batchを使用した大規模シミュレーションの実行は、お客様の間で見られる一般的なトレンドとなっており、数十万台のインスタンスまでスケールアップすることが可能です。これまでAWS Batchは1つのコンテナしかサポートしていなかったため、シミュレーションソフトウェアやテストケース、センサーなど、複数のコンテナが必要な場合、それらを1つの巨大なコンテナにまとめる必要があり、運用上のオーバーヘッドが発生していました。現在、AWS Batchは1つのジョブで複数のコンテナをサポートするようになり、基本環境としてシームレスに利用できるようになりました。 最後に、シーン生成と検索に関しては、現在も実験的な段階であり研究テーマとして取り組んでいますが、今後数四半期で技術が追いついてくると予想しています。実際の生活では稀にしか発生しないシーンを生成したり、既存のシーンに新しいオブジェクトを追加して拡張したりする場合に、生成AIが活用できる可能性があると考えています。
Rivian Autonomy Platform：ADASソリューションの全貌
素晴らしいコマーシャルでしたね。車両を見るたびに、とても嬉しい気持ちになります。カラーやデザインも - 皆さんもRivianの車をお気に入りいただけたと思います。私はMadan Thotaと申します。Rivian Autonomyチームのシニアマネージャーを務めています。簡単な質問をさせていただきたいのですが：ADASがドライバーの安全性と快適性にとって重要だと考える方は何人いらっしゃいますか？かなり多くの手が挙がっていますね。車線逸脱警報や衝突検知などの機能により、多くの事故が防がれ、多くの命が救われてきました。ADASは今やすべての自動車にとって不可欠な存在となっています。
ここ数年、特にADAS、自動運転、自律走行に関連する分野で目覚ましい成長が見られました。自動車メーカーにとって、自律走行機能の開発に必要なインフラストラクチャとツールを持つことが必須となっています。これから20分間、Rivian Autonomy Platformと、自律走行機能の開発を加速するために構築したアプリケーションやワークフローについてお話しさせていただきます。 私たちのADASソリューションであるRivian Autonomy Platformには、13以上の自律走行機能と20以上の安全機能が搭載されています。Highway AssistやLane Change on Commandなどの自律走行機能に加え、衝突検知、緊急ブレーキ、Park Assistなど、多数の安全機能を備えています。運転中も駐車時も、常に安全性と運転体験を向上させる機能があるべきだというのが私たちの目標です。
この例では、Lane Change on Command機能をご覧いただけます。ウインカーを使用するだけで、安全な状況下で車線変更をガイドし、 適切なタイミングで車線変更を実行します。次の例では、 衝突が検知された際の緊急ブレーキをご覧いただけます。Rivian Autonomy Platformは社内で開発され、 システムの最適なパフォーマンスと将来のリリースに向けたスケーラビリティを確保しています。これらのAI搭載システムは、車両に搭載された高度なコンピューティング能力とセンサーを活用して、非常に優れたパフォーマンスを発揮しています。
搭載センサーに関して、私たちのGen-2車両には11台のカメラと 5台の先進的なレーダーが搭載されています。11台のカメラは、最先端の解像度とダイナミックレンジを備え、55メガピクセルのリアルタイムイメージングを実現します。さらに、マルチモーダルセンシング機能は、前方1,000フィートの検知範囲を持つレーダーによって強化されています。これらのテクノロジーが組み合わさることで、重複するセンサーカバレッジによる360度センシングを実現し、あらゆる条件下で最適なパフォーマンスを確保しています。
私たちのデータ収集フリートには、長距離用と短距離用の両方のLiDARが搭載されています。 これらは高解像度の3Dマッピングを提供し、これは私たちのPerceptionモデルのトレーニングに不可欠です。すべてのフリートに搭載された高性能なオンボードコンピュータとセンサーを組み合わせることで、私たちはモデルのトレーニングのために数百万マイルのデータを収集しています。 サンプルデータをお見せしましょう。これは私たちの車両から収集したビデオウォールです。このビデオウォールでは、 信号機、トラック、バイク、他の車両、歩行者、駐車場、高速道路の走行、昼夜のシーンなど、さまざまなシナリオの例をご覧いただけます。自律走行モデルのトレーニングにおいて、データの多様性は非常に重要です。これにより、システムが幅広い実世界のシナリオで確実に機能することが保証されるからです。
LiDARデータを見てみましょう。こちらは私たちのLiDARで収集したポイントクラウド3Dデータの別のサンプルです。 これは複数のLiDARからのデータを統合したシーンで、車両周辺の高解像度で詳細な階層ビューを提供します。 このデータにより、障害物、路面、物体を高精度で識別することができます。この包括的なアプローチにより、スケーラブルで信頼性の高い自律走行モデルのトレーニングが可能になりました。
私たちの車両から得られる様々な種類のデータをご覧いただきました。フリート車両は継続的にこのデータをクラウドにアップロードし、そこでデータの保存、処理、拡張を行い、キュレーションとラベリングを容易にしています。ラベル付けされたデータセットはモデルトレーニングに使用されます。トレーニングされたモデルと更新されたソフトウェアは、Triageチームとエンジニアリングチームがシミュレーション出力とそれらから生成されたダッシュボードをレビューした後、シミュレーションと検証が行われます。すべてが良好であれば、更新されたソフトウェアを車両にプッシュします。このサイクルにより、私たちの車両は継続的に学習し、改善を重ねています。
このプロセスを30秒で説明すると簡単そうに聞こえるかもしれませんが、実際には多くの課題があります。ペタバイト規模のデータが絶えず蓄積され、日々増加しています。複数のカメラからの映像、ポイントクラウドデータ、その他のテレマティクスデータなど、データの複雑さは非常に高くなっています。これらのデータを一緒に可視化するためのより良いツールが必要です。データ収集からモデルのデプロイメントまで、多くのチームがこの開発ライフサイクルに関わっています。個々のチームがライフサイクルの異なる段階で作業を行うため、データサイロが発生する可能性があります。チーム間のさらなるコラボレーションが必要で、私たちのソリューションはコスト最適化され、スケーラブルで、セキュアであり、可能な限り自動化をサポートする必要があります。
これらの課題を克服するため、私たちはPolarisというプラットフォームを構築しました。PolarisはRivianの自律走行データプラットフォームで、自律走行機能の開発をサポートするための包括的なソリューションです。まず、自律走行データアプリケーションと呼ばれるユーザーインターフェース層があり、 これはWebアプリケーション、コマンドラインインターフェース、ダッシュボードで構成されています。
これらは、自律システム開発のためのデータ管理と活用を支援するエンジニアのためのツールです。これらはMicroservicesとデータワークフローに接続されています。 サービス層には、Rivian向けにカスタマイズされた広範なビジネスロジックが含まれており、Rivianのセキュリティサービスとの統合や、APIを使用したすべてのアプリケーション間の通信機能も備えています。ラベリング、シミュレーション、トレーニングを含むデータワークフローは、大規模なデータ処理を実行します。これらのコンポーネントはすべて、AWSクラウドとAWSパートナーサービスによって支えられています。
AWSサービスは、大容量ストレージと高度な計算タスクを処理するための高性能クラウドインフラストラクチャを提供します。私たちは分析エンジニアリングパイプライン用にDatabricksを、運用データストアとしてMongoDBなど、AWSパートナーサービスを活用しています。これらのコンポーネントが連携することで、自律走行データの管理と運用のための堅牢でスケーラブルなソリューションを実現しています。
Polarisの詳細：自律走行データプラットフォームの構築
データディスカバリー（ログディスカバリー）は、 ランダムなアクセスパターンを持つペタバイト規模のデータを管理する上で極めて重要です。ソリューションの設計にあたっては、検索対象、検索の効率性と精度、そして検索結果に対して実行可能な操作という3つの側面に焦点を当てました。ディスカバリー検索は、車両から収集された生データの記録から、画像やアノテーションなどの派生成果物まで、自律走行データのライフサイクルに関連するあらゆるデータを検索できるインターフェースを提供します。
検索の精度は、様々なレベルで処理されるメタデータによって支えられています。ドライバーのメモといった基本的な情報から始まり、どの車両がデータをアップロードしたか、どのトリガーが特定のログを生成したか、どのソフトウェアバージョンでデータが収集されたかなど、システムメタデータにまで及びます。様々なシステム属性が収集されます。データがクラウドに到着すると、データ品質チェックによって期待値との整合性が確認され、不良データの混入を防ぎます。特定のカメラが欠落している場合やトピックが欠落している場合、カメラが正しくキャリブレーションされていない場合などは、DQチェック失敗としてラベル付けされます。これにより、ダウンストリーム処理から不良データを除外でき、計算リソースを節約するとともに、車両データ収集の品質を把握するための統計情報を提供できます。
データ取り込みは、ビデオコンテンツを分析し、オブジェクトを識別し、サマリーを生成し、この情報をメタデータに付加するMLパイプラインで処理されます。これにより、人間のドライバーが見落としがちな車やトラックなどのシーン要素を自動的に検出できます。KPI分析パイプラインは、イベントが特定された際にメタデータにメトリックタグを付加することで、元のログにフィードバックを提供します。これらの様々なメタデータの組み合わせにより、検索機能と効率性が向上し、アノテーションチーム、エンジニアリングチーム、トリアージチームが関連データを素早く見つけることができます。データが見つかると、ユーザーはアプリケーション内でログを可視化したり、ラベリング用の記録バッチを作成したり、トレーニングやシミュレーション用のデータセットとしてグループ化したりすることができます。
効率的な検索プラットフォームを構築し、他の自動運転データアプリケーションと統合することで、チームの生産性とデータ活用の効率性が向上しました。時間の経過とともに、このシステムは不適切なデータを除外し、より慎重なデータ活用を確実にしています。
データのキュレーションが完了したら、ラベリングを行う必要があります。私たちは手動ラベリングと自動ラベリングの両方を大規模に実施しています。データの手動ラベリングは非常に時間がかかり、コストもかかります。Auto labelingを使用することで、このプロセスを大幅にスピードアップできます。Auto labelingが標準的なデータセットを処理することで、人間のラベラーは難しいエッジケースの微調整や、生成されたラベルの検証に集中できるようになります。これは私たちのAuto labelingパイプラインの出力例で、特定のシーンの6台のカメラすべてを通過し、それらのフレーム内のオブジェクトを識別しています。キュレーションやAuto labelingパイプライン、そしてトレーニング用のデータセット作成まで、毎晩自動的に実行されるように設定しています。これは自動化の一例であり、より迅速な実行のためには自動化が鍵となります。
モデルのトレーニングが完了したら、ソフトウェアの変更 とモデルの更新を検証する必要があります。実際の車両で大規模なテストを行うのは非常に時間がかかります。シミュレーションは、ソフトウェアの検証をより迅速、安全、効率的に行う方法を提供します。私たちはPolarisと呼ばれるプラットフォーム内にSimDashというアプリケーションを構築し、ユーザーがシナリオ管理、データセット管理、ジョブ管理を行えるようにしました。エンジニアはデータセットとソフトウェアバージョンを選択し、バックエンドサービスにジョブを送信できます。SimDashアプリケーションを監視しているワークフローマネージャーには、いくつかのインテリジェンス機能が組み込まれています。ジョブのタイプと優先度に基づいて、CPUコンピュートかGPUコンピュートが必要かどうか、優先度に応じてSpotインスタンスかオンデマンドインスタンスで実行できるかどうかをチェックします。ジョブの設定を再構成し、AWS Batchに送信します。AWS Batchは非常に高いスケールのコンピュートを提供し、数千のインスタンスまで拡張できます。シミュレーションの90%をSpotインスタンスで実行しており、非常にコスト効率が良く、各機能リリースごとに数百万マイルのシミュレーションを実行することができています。全体として、シミュレーションアプリケーションとワークフローにより、変更を迅速かつコスト効率よく検証でき、ソフトウェアを車両にデプロイする前の段階で問題を特定することで、製品品質を向上させることができました。
トリアージについて話しましょう。自動運転システムは非常に信頼性が高く、安全に動作する必要があるため、重要な問題を素早く特定して解決することが不可欠です。ここで簡単なデモをお見せしたいと思います。これは私たちのディスカバリーアプリケーションのコンポーネントの1つであるTag Explorerで、トリアージチームやエンジニアリングチームが道路上で発生したイベントのリストを素早く確認できるようにするものです。 この例では、ユーザーがドライバーのメモを確認しています。エンジニアは「自動車線変更失敗」というメモを見つけ、そのリストアイテムをクリックします。関連するイベントデータが自動的にブラウザの可視化パネルにストリーミングされます。 エンジニアは3Dパネル内でレビューを行うことができます。
もう1つの例として、エンジニアが KPI分析パイプラインによって生成されたメトリクスタグをレビューしたい場合を見てみましょう。AVイベントを例に取ると、エンジニアはAVに関連するイベントのリストを確認し、特にAVレベル3のイベントを詳しく調査したいと考えています。そのリストアイテムをクリックすると、 関連データが自動的にブラウザにストリーミングされます。私たちの重要な学びの1つは、トリアージチームやエンジニアリングチームができるだけ関連データを見つけるのに時間を費やさなくて済むよう、データをできるだけ事前に処理しておくことでした。これにより、データの根本原因を特定する生産性が向上します。可視化ツールは非常に重要で、複雑なシステムの動作をデバッグし、 センサーデータを一緒にレビューすることができます。
私たちは、オープンソースアプリケーションのFox Glowを移植し、Rivianのニーズ、特にRivianのデータフォーマットやS2 65ビデオ圧縮をサポートするようにカスタマイズしました。スケーラブルで新しいパネルや可視化機能を容易に構築できるよう、カスタム拡張フレームワークを開発しました。このアプリケーションはWebとデスクトップの両バージョンをサポートしているため、車両テスト中にインターネット接続がない場合でも、デスクトップ版を使用することができます。このツールは私たちのすべての自動運転データアプリケーションと完全に統合されており、エンジニアはログ検出アプリケーション、シミュレーション出力ページ、詳細なKPIダッシュボードなど、どこからでもデータを視覚的に確認できます。イベントを1回クリックするだけで、そのイベントに関連するデータをブラウザにストリーミングできます。
このツールの例をいくつかご紹介しましょう。マップ、ビデオ、3Dパネルなど、複数のパネルをご覧いただけます。この例では、エンジニアがハイビームアシストのデータを確認しています。 対向車の状況を確認し、ハイビームの動作状況を確認することができます。 また、車線認識アルゴリズムの例では、エンジニアは3Dパネルとビデオ上で車線を確認することができます。これにより、エンジニアはデータがクラウドに到達した際のデバッグを行うことができます。Triageチケットやインシデント、KPIフィードバックループで特定されたイベントがある場合、これらのアプリケーションを使用して迅速にデータにアクセスし、視覚化することができます。
私たちが構築した自動運転プラットフォーム全体は、 AWSクラウドにデプロイされたアプリケーションとデータワークフローにより、この1年で素晴らしいマイルストーンを達成することができました。このプラットフォームは、スケーラブルなソリューション、より優れたデータ管理、コスト効率の向上により、データの管理と処理方法を改善しました。このデータプラットフォームは多くのコラボレーション機能をサポートしています。改善されたTriageプロセスとKPIダッシュボードからの洞察により、製品品質が向上しました。ラベリング、トレーニング、シミュレーションのスケールと自動化により、自動運転ソリューションの市場投入までの時間を短縮することができました。
AWSを活用したRivianの技術アーキテクチャ
ここで、このプラットフォームの技術アーキテクチャについて詳しく説明するため、同僚をご紹介したいと思います。Narendraをお迎えしましょう。ありがとうございます、Madan。皆さん、こんにちは。私はRivianの自動運転チームのLead Software EngineerのNarendraです。Polarisが、 ペタバイト規模のデータを処理し、モデルをトレーニングし、何千時間ものシミュレーションを実行して、お客様のアドベンチャーをパワフルにサポートする自動運転機能を提供するために、AWSでどのように構築されているかについて詳しく見ていきましょう。
アーキテクチャから始めましょう。 RivianまたはAWSのアップロードステーションを使用して、Rivian車両からデータを収集し、Amazon S3にアップロードします。このデータはS3に保存され、 SQS BatchとArgoを使用したイベント駆動型アーキテクチャで処理されます。この段階の出力はデータセットです。 これらのデータセットはS3に保存され、トレーニングに使用されます。トレーニングプラットフォームはAmazon EKS上に構築されています。トレーニングの実行にはKubeRay Operatorを使用しています。トレーニングが実行されると、メトリクスとアーティファクトがMLflowに記録されます。この段階の出力はモデルです。
モデルを Autonomy ソフトウェアと共にシミュレーションおよび検証ループに投入します。 このプラットフォームは Amazon Batch と Databricks 上に構築されています。良好なモデルとソフトウェアが得られたら、over-the-air アップデートを通じて自社のフリートに、そして最終的にお客様に展開します。それでは、これらのプロセスの詳細を順番に見ていきましょう。まず、データの取り込みと処理についてですが、カスタマーフリートからのデータは Rivian の Vehicle Cloud チームによって収集されます。 このデータは、アクセス権限ポリシー、暗号化、セキュリティ監視が適用された状態で Amazon S3 に保存されます。AWS Batch を使用してこのデータを処理し、個人を特定できる情報を削除します。
次に、メタデータを抽出して MongoDB メタデータデータベースに保存します。続いて、Rivian の一般車両やテスト用フリート車両からデータを収集し、AWS Transfer Terminal や Rivian アップロードステーションを使用して Amazon S3 にアップロードします。put オブジェクトイベントのイベント駆動型アーキテクチャを使用し、Amazon SQS と Argo workflows でこのデータを処理します。データ品質チェックやインデックス作成など、様々なワークフローを実行します。データ品質チェックではデータが基準を満たしているかを確認し、インデックス作成ではメタデータを抽出してメタデータデータベースに保存します。
メタデータデータベースには、Amazon S3 に保存された生データに関連するすべてのメタデータが含まれており、これが Polaris API とアプリケーションの基盤層となります。主要なアプリケーションの1つが Discovery で、ユーザーはメタデータを使用してデータを検索できます。Polaris Viz で直接データを可視化したり、Cosmo を使用してシミュレーションやトレーニング用のデータセットを作成したりすることができます。また、次の主要なワークフローであるアノテーションやラベリングのワークフローを通じて、データセットの作成や処理を行うこともできます。
ラベリングには、手動ラベリングと自動ラベリングの2種類があります。手動ラベリングでは、人間のアノテーターが車線、物体のバウンディングボックス、交通標識などのラベル付けを行います。自動ラベリングでは、Amazon EventBridge と AWS Batch を使用して毎晩バッチ推論を実行し、数万台の Amazon EC2 インスタンスにスケールアップして、結果を S3 バケットに保存します。このデータをさらに Ray を使用して Parquet 形式に処理します。また、トレーニングプロセスを最適化するためにもデータを処理します。この Ray データセットキャッシュ生成プロセスの出力が、Amazon S3 に保存される最終的なトレーニング用データセットとなります。
データセットが準備できたら、モデルトレーニングに進みます。アーキテクチャについては、Amazon EKS Terraform モジュールから始めて、私たちのスタックに合わせてカスタマイズし、異なるリージョンやアプリケーションにデプロイします。コンピューティングとストレージのために Amazon EC2 や Amazon S3 と連携し、ログやメトリクスのために Amazon CloudWatch や Amazon Managed Service for Prometheus などの他のサービスとも連携します。また、これらのログやメトリクスの可視化には Amazon Managed Grafana を使用しています。
Amazon EKS内では、ユーザーがEFAプラグインを有効にすることができ、私たちはそれをインストールします。主要なプラグインとしては、EFAやGPU operatorがあります。これらは、EFAネットワークインターフェイスやGPUなどのAmazon EC2リソースをKubernetesリソースとして変換します。また、Fluent BitやPrometheusのアドオンがあり、これらはログやメトリクスを収集してCloudWatchやPrometheusに転送します。さらに、Amazon EBS、Amazon EFS、S3 Mountpointなどのストレージプラグインがあり、これらはクラスターから直接ストレージにアクセスするために使用されます。
その上のレベルには、オーケストレーションを担当するジョブ管理層があります。 私たちはKueueを使用しており、これはギャングスケジューリング、プリエンプション、公平な共有スケジューリング、優先順位付けなどの機能を提供し、RayJob CRDを使用してトレーニングジョブをスケジュールします。RayJob CRDはKubeRayオペレーターオープンソースプロジェクトの一部で、クラスター上のPyTorchデータパラレルジョブを管理します。最上位には、Ray JobsやMLflow 、Polarisアプリケーションスイートなどを実行するアプリケーション層があります。
ユーザーフローは次のように機能します：ユーザーはRivX CLIを使用してジョブを送信します。 RivX CLIは、ジョブトレーニングのライフサイクルを管理するために社内で開発された専用ツールです。 ユーザーは、クラスター名、リージョン、使用するイメージ、さまざまなリソース、ジョブの優先度などのオプションを選択してジョブを送信します。Kueueは、リソースの可用性と優先度に基づいてこのジョブをクラスターにスケジュールします。 ジョブが実行されると、メトリクスをMLflowにログとして記録し、いくつかのアーティファクトも保存します。
また、RivXに似たUIアプリケーションであるCosmoを使用することもできます。 これはUIから直接ジョブを管理するためのものです。ジョブやアプリケーションの実行時には、さまざまな種類のメトリクスを収集します。 アプリケーションレベルのメトリクスと運用メトリクスを収集します。ここでは、Prometheusによって収集され、Grafanaに表示されているアプリケーションレベルのメトリクスを確認できます。ジョブ中のGPU、CPU、メモリ使用率、さらにRayオブジェクトやメモリなどのアプリケーション固有のメトリクスもあります。ユーザーはこのダッシュボードを使用して、処理速度の低下やメモリ不足などの問題をデバッグすることができます。
良好なモデルが得られたら、シミュレーションと検証のループに進みます。 Autonomyエンジニアはこの目的でPolaris SimDashを使用します。これはUIアプリケーションで、ユーザーはデータセットとGitまたはDockerタグを選択し、これがシミュレーションを実行するソフトウェアバージョンに変換されます。オンデマンドシミュレーション を実行できます。この場合、実行時にGitLab CI上でDockerイメージをビルドします。あるいは、Amazon EventBridgeを使用してランをスケジュールすることもでき、その場合はmainやリリースブランチ などの静的なブランチをゴールデンデータセットと共に選択します。
これらのフローはいずれもAWS Batchを使用しています。2024年には、AWS Batchを活用して200倍までのスケールアップを実現できました。AWS Batchがシミュレーションと評価を実行すると、その結果はAmazon S3に保存されます。これらの結果はDatabricksによって自動的に分析され、そこからいくつかのKPIを算出しています。ユーザーは、Amazon EKSでホストされているStreamlitのダッシュボードを通じてこれらのKPIにアクセスできます。また、Polaris vizを使用してシミュレーション結果に直接アクセスすることも可能です。これはTriageのようなアプリケーションで特に役立ちます。
これらは環境全体の最適化に役立つ運用メトリクスです。使用されているEC2インスタンスのタイプなど、さまざまなメトリクスを確認できます。成功率の高いインスタンスタイプを特定し、それらのEC2インスタンスを使用するようにコンピュート環境を最適化できます。また、SpotインスタンスやOndemandインスタンスなどの購入オプションの選択や、最適なアベイラビリティーゾーンの選択も可能です。
ADAS開発における重要な学びと今後の展望
これまでの取り組みから得られた重要な学びをご紹介します。コンピュートに関しては、Dockerイメージをキャッシュすることが重要です。NVIDIAのDockerイメージのような10～15ギガバイトの大規模なDockerイメージの場合、毎回イメージをプルするのに多くの時間がかかります。そのため、コンピュート環境のAMIにこれらのイメージをキャッシュすることで、大幅な時間と費用の節約になります。シミュレーション実行において、1000ドル以上のコスト削減を実現できました。GPUのモニタリングも重要です。現在、GPUはストレージ（これは雪だるま式に増加します）を除けば、おそらく最も高価なリソースです。NVIDIA GPU Operatorを使用してGPUをモニタリングしたり、PyTorchやNVIDIAのプロファイラーを使用してアプリケーションのパフォーマンスを向上させることができます。
重要なワークロードをより速く完了させたい場合、適切なスケジューラーの使用が非常に重要です。トレーニングとシミュレーションのワークロードをスケジューリングするために、KueueやAWS Batchなどのスケジューラーを使用しています。アプリケーション間、特にトレーニングアプリケーションで低レイテンシーが要求される場合、プレイスメントグループの使用が重要です。プレイスメントグループを使用することでノード間のレイテンシーが低減され、さらにEFAの使用が可能になり、GPU間の高帯域幅通信が実現できます。
最後に、Batchで大規模なスケーリングを実現したい場合、ジョブの実行時間を長くすることで、より高いスケーリングが可能になります。実行時間を2分から6分に増やすことで、2～3倍のスケーリングを実現できました。ここからはストレージに関する重要な学びをご紹介します。
Amazon S3のリクエストメトリクスは、デフォルトでは有効になっていないため、これを有効にする必要があります。メトリクスを有効にすることで、誰かがアプリケーションにスパムを送信している場合や、5XXエラーによる遅延などS3のパフォーマンスが低下している場合などの問題を特定できるようになります。 私たちはS3 Intelligent-Tieringを導入し、ストレージコストを30%削減することができました。S3 Intelligent-Tieringは、アクセスパターンに応じて異なるストレージ層間でデータを自動的に移行する手助けをしてくれます。
Amazonのほとんどのシステムは、デフォルトでgp2ボリュームを使用します。gp3ボリュームはより新しいタイプで、20%のコストパフォーマンス向上が見込め、スループットとIOPSをより細かく制御できます。 ストリーミングや可視化が必要なアプリケーションには、Transfer Accelerationを利用しています。高価なファイルサーバーをホストする代わりに、Transfer Accelerationを有効にしたS3を直接使用できます。私たちはPolarisの可視化においてTransfer Accelerationを最大限活用することができました。
Common Runtimeには、より高速なダウンロードとアップロードを可能にするCとC++で書かれたライブラリが含まれています。Common Runtimeを有効にしたPython .03を使用するか、Common Runtimeを搭載したS3 Mountpointを直接使用することができます。 RivianのAWSにおける今後の展望として、お客様のアドベンチャーをより早く実現できるよう、データストレージは4倍に、トレーニングとシミュレーション用のコンピュートは10倍に成長すると予測しています。また、2025年には、データキュレーションやトレーニング・シミュレーション用の合成シーン拡張に生成AIを活用する、といった興味深いプロジェクトも予定しています。
私たちは常にコスト最適化を心がけており、2025年にはシミュレーションと自動ラベリングの推論コストを削減するプロジェクトや、S3のライフサイクルポリシーをより厳格に実装してコストをさらに削減する取り組みを行う予定です。最後に、モデルのパフォーマンスに応じて自動的にデータセットを作成し、キュレーションプロセスとラベリングを経て、新しいトレーニングジョブを起動する、クローズドループのデータ管理システムの構築を目指しています。以上で発表を終わります。 こちらが私たちのLinkedInプロフィールです。ご質問がありましたら、ここでお受けいたしますので、評価もよろしくお願いします。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion