[レポート] UberがAWS Batchで効率的でスケーラブルな自動車両シミュレーションを構築する方法 #CMP328 #reinvent

ラスベガスからこんにちは、岩城です。

セッション「How Uber builds efficient & scalable autonomous vehicle simulations with AWS Batch」を聴講しましたのでレポートします。

概要

UberがAWS Batchを使用して毎日何十万台ものvCPUで数十万台の自動車両シミュレーションを実行する方法を学びます。 UberがネイティブAWSサービスで高性能でスケーラブルなシミュレーションパイプラインをどのように構築したかのストーリーをご覧ください。

• Session Type:Session
• Topic:Compute
• Session Level:300 - Advanced

スピーカー

• Steve Kendrex
  • Sr. Technical Product Manager, Amazon Web Services
• Jo Adegbola
  • Sr. SDM, Amazon Web Services
• Matt Ranney
  • Senior Staff Engineer, Uber ATG

※敬称略

レポート

Introducing AWS Batch

• フルマネージド
• AWSサービスと統合
  • AWSプラットフォームとネイティブに統合されたAWS Batchは、S3、DynamoDB、Rekognitionなどのサービスと簡単かつ安全に対話可能
• 最適化されたリソースプロビジョニング
  • AWS Batchは、EC2およびEC2 Spotを使用してジョブのニーズに合わせた計算リソースを自動的にプロビジョニングする

AWS Batchを利用するユーザー

• 気象/システムモデリング
• 金融市場/リスク分析
• 石油およびガス探査
• 遺伝子配列
• 自動運転車MLおよびシミュレーション

New: Allocation strategies for AWS Batch

• 2019年10月16日にリリースされた機能
  • AWS公式ブログ
  • 日本語ドキュメント
• Spot Capacity Optimized
  • AWSが最も深いスポットキャパシティプールを予測する
  • それに応じたインスタンスタイプを起動できるようする
  • スポットインスタンスのみで利用可能
• Best Fit
  • 以前と同じ動作
  • SLI/SDKを介して作成された環境は、後方互換性を維持するため、Best Fitがデフォルト設定される
  • スポットインスタンスまたはオンデマンドがサポートされる
• Best Fit Progressive
  • Best Fitと同じ
  • 容量エラーに達すると、AWS Batchはは次に最適なインスタンスタイプを選択する
  • オンデマンドまたは特定の用途のスポットインスタンスの場合推奨

ワークフロー、パイプライン、およびジョブの依存関係

• ジョブは、他のジョブまたは配列ジョブの特定要素の正常終了への依存関係を表現可能
• 希望するワークフローエンジンと言語を使用してジョブを送信
• フローベースのシステムは単純にジョブを連続して送信する
• DAGベースのシステムはジョブ間の依存関係を特定して多数のジョブを一度に送信する
  • DAGとは？
  • 情報処理試験でよくみるやつ

AWS Batchでのマルチノード並列ジョブ

• マルチノード並列ジョブは、複数のEC2インスタンスにまたがる単一のジョブを実行する
  • 用途：分散型ディープラーニング、HPC
• ノード間の低遅延のためにElastic Fabric Adapterと統合

GPUスケジューリング

• 必要なGPUの数に基づいてジョブを受け入れ、スケールアップ
• PまたはGファミリーのインスタンス
• GPUをコンテナに固定して、オーバーサブスクリプションを防ぐ
• リリース時に新しいアクセラレータ/GPUを採用
• NVLinkのサポート

Uberの事例

自動運転車の基本

この後、Uber社がどのような考えで自動運転をシミュレーションしているの説明されていました。 私の英語力不足やシミュレーターを説明できるほどの知識がないため、レポートは割愛します。 分かる人には面白い内容だと思いますのでスライドの写真だけ載せておきます。

AWSでのシミュレーション

• Uberで行っていた従来のシミュレーションは、パブリッククラウドの理想的なワークロード
• 不規則な需要に対応可能
• 各テストには、実行時に数千の仮想車両が必要で、完了時にはゼロにしたい
  • 一部では10万回テストしている
  • 100万回テストしているものも

本番環境を構成しているサービス

• Fargate
• Aurora
• S3
• Lambda

各環境の使い分け

• 本番環境、検証環境、開発環境がある
• 各環境ごとにALBを介してアクセスする
• 開発環境はエンジニアごとに用意
• 本番環境、検証環境は日付ごとに用意

ATG Components

• ATG
  • Uber Advanced Technologies Group

AWSバッチを直接使用しない理由

• コンテナが大きい
• ジョブサイズの制限
• より短いタスク長
• 可観測性

可観測性

• JSONを使用した構造化ロギング可能
• CloudWatch Logsがうまく機能する
• 他のログアグリゲーターやJSONツールと簡単に統合可能

AWS Batchに期待すること

• 大きなコンテナと書き込みの増幅
• 一時的なコンピュート上の一時的なストレージ
• メモリ不足
• エンドユーザー向けに非常に好意的に注目されている
• 常に高速になっているが、それでももっと高速であることを願っている

Uberは現在もAWS Batchを使用している

• Uberが試した何よりもうまくスケールして処理する
• 実験に適している

推奨事項

• アカウントチームと協力して仮定を検証する
• コンテナのサイズを小さく保つ
• pre-OOMキラーを追加する
• 時々tmpfsが最良の選択となる
• すべてをJSONとして記録する

AWS Batchのロードマップ

• AWS Batchコンソールの大幅な改善
• ジョブレベルのメトリックのためのコンテナInsightsとの完全な統合
• 速度とスケール（より速いスケーリング、より高い制限）
• カスタムロギング設定
• 新しいコンピュート戦略とタイプ
• より良い配置ロジックと追加のスケジューリング方法
  • 使用率の向上、コストの削減、スケジューリングの公平性の向上

まとめ

AWS Batchを自動運転技術のシミュレーションで利用するユースケースでした。これまでUber社がAWS Batchを利用してきた知見やそこから見えてきたAWS Batchへの課題が興味深かったです。最後にAWS Batchのロードマップも紹介され、AWS Batchへの期待が高まりました。

本エントリがどなかたのお役に立てれば幸いです。