※本記事は、AWS re:Invent 2024のセッション「Supercharge your AI and ML workloads on Amazon ECS (SVS331)」の内容を基に作成されています。セッションの詳細情報はAWS re:Inventの公式サイト（https://go.aws/reinvent ）でご覧いただけます。

本記事では、セッションの内容を要約・構造化しております。なお、本記事の内容は発表内容を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのセッション動画をご視聴いただくことをお勧めいたします。

また、より詳細な技術情報や最新のアップデートについては、AWS公式チャンネル（http://bit.ly/2O3zS75 ）やAWSイベント情報（http://bit.ly/316g9t4 ）もご参照ください。セッションで紹介された実装方法や最適化手法については、必ず最新のAWSドキュメントを参照の上、ご自身の環境に適した形で実装をご検討ください。

1. はじめに

1.1 講演者の紹介

●Steve Kendrex： ECS Fargateのシニアマネージャーとして、セッション全体のファシリテーションを担当しています。冒頭で参加者のECS利用状況を確認し、ほぼ全ての参加者がECSを利用しているか検討中であることを確認しました。全体のセッションの流れと、ECSでのgen AI活用の可能性について概要を説明しています。

●Abhishek： ECSにおける機械学習の重要な考慮事項について説明を担当しています。AIおよび機械学習ワークロードを実行する際の基本的な課題から、それらをECSで解決する方法まで、体系的な説明を提供しています。特に、アーキテクチャ設計からスケーリング戦略まで、実装に必要な技術的な詳細を解説しています。

●Frank Fan： 実践的なデモンストレーションを担当しています。Stable Diffusionを用いた生成AIの推論アプリケーションをECS上で実行する具体的な実装方法を示しています。信頼性、パフォーマンス、スケーラビリティの三つの主要な側面に焦点を当て、実際の動作環境での最適化手法や監視方法を含めた包括的なデモンストレーションを行っています。

1.2 セッションの目的

Steve Kendrex：今回のセッションでは、ECSユーザーの皆様に向けて、gen AIワークロードの実装方法について説明していきます。会場の多くの方がすでにECSを使用されているか検討中とのことですが、では具体的にどのようにgen AIを始めればよいのでしょうか。

Abhishek：その点について、私から補足させていただきます。急速に進化するgen AI領域において、新しいモデルや計算能力、アクセラレータが次々と登場していますが、実はAI/MLアプリケーションの構築における基本的な課題は、従来のアプリケーションと大きく変わりません。むしろ、皆様の組織ですでに解決してきた課題と共通する部分が多いのです。

Steve Kendrex：そうですね。このセッションでは、三つの主要なシナリオに焦点を当てています。一つ目は、すでにECSを使用している方々が、既存のプラットフォームを活用してgen AIを始める方法です。二つ目は、軽量な実装から始めたい方向けの、シンプルな開始方法です。そして三つ目は、より高度なgen AIプラットフォームを可能な限り迅速かつスケーラブルに構築する方法です。

Frank Fan：私からは、これらの課題に対する具体的な解決策として、Stable Diffusionを使用した実際の推論アプリケーションのデモンストレーションを通じて、ECSでの実装方法を示していきます。特に重要なのは、信頼性、パフォーマンス、スケーラビリティの三つの側面です。

Abhishek：そして、これらの実装において重要なのは、従来のアプリケーション開発の知見を活かしながら、AI/ML特有の要件にも対応できる柔軟なアーキテクチャを設計することです。このセッションを通じて、皆様がECSでgen AIを効果的に実装するための具体的な方法論を提供していきたいと考えています。

1.3 ECSの現状の利用状況

Steve Kendrex：会場の皆様へ最初に確認させていただきましたが、ほぼ全ての方がすでにECSを利用されているか、検討中とのことでした。これは非常に心強い状況です。現在、多くのトラックやセッションでAWSにおけるgen AIの活用方法について議論されていますが、ECSユーザーの皆様にとって最も重要なのは、既存のプラットフォームをどのように活用してgen AIを開始できるかという点でしょう。

Abhishek：その通りですね。現在のECS活用シーンを見ると、従来型のアプリケーションが中心ですが、これらの基盤は実はgen AI実装にも非常に適しています。なぜなら、組織がすでに解決してきた課題の多くが、gen AIワークロードでも共通して存在するからです。私たちの経験では、ECSの既存ユーザーは、その知見を活かしてgen AIへの展開をスムーズに行えることが多いです。

Frank Fan：実際の現場では、まずは軽量な実装から始めて、徐々に拡張していくアプローチが有効だと考えています。例えば、私が後ほどデモでお見せするStable Diffusionの実装では、既存のECSインフラストラクチャを活用しながら、gen AI特有の要件に対応する方法を具体的に示していきます。

Steve Kendrex：そうですね。re:Inventの様々なセッションでgen AIについて議論されていますが、このセッションでは特にECSユーザーの視点から、既存のプラットフォームを活用した具体的な実装方法に焦点を当てていきたいと思います。皆様の多くがすでにECSを使用されている強みを活かし、より高度なgen AIプラットフォームの構築までをカバーしていきましょう。

2. AI/MLワークロードにおける主要な課題

2.1 柔軟性の確保

Abhishek：AI/MLワークロードの実装において、最も重要な課題の一つが柔軟性の確保です。gen AIの急速な進化に伴い、新しいモデルが次々と登場する中で、組織のニーズに合わせて適切なモデルを選択し、カスタマイズできる環境が必要不可欠です。

Steve Kendrex：その通りですね。ECSユーザーの多くが、異なるモデルやツールキットを試験的に導入したいというニーズを持っています。そのため、プラットフォームとしてどのような柔軟性を提供できるかが重要になってきます。

Abhishek：具体的には、以下の三つの観点での柔軟性が重要です。まず、モデルの選択に関する柔軟性です。例えば、Stable Diffusionやその他のファウンデーションモデルなど、様々なモデルを自由に選択し、評価できる環境が必要です。次に、選択したモデルをカスタマイズする自由度も重要です。組織特有のニーズに合わせてモデルをファインチューニングしたり、特定のユースケースに最適化したりする必要があります。

Frank Fan：私の経験では、特に推論アプリケーションの実装において、異なるMLツールキットやライブラリを組み合わせる必要性が頻繁に発生します。例えば、後ほどデモでお見せするStable Diffusionの実装では、異なるランタイムや拡張モデルを組み合わせることで、様々なスタイルの画像生成を実現しています。

Abhishek：その通りです。ECSの重要な利点は、これらの柔軟性を確保しながら、一貫した運用環境を提供できることです。例えば、同じモデルでも異なるランタイムを使用したり、LoRAのような拡張モデルを組み合わせたりすることで、特定のスタイルや要件に対応できます。このような柔軟性は、rapidly evolving（急速に進化する）gen AI領域において特に重要です。

Steve Kendrex：また、この柔軟性は、コストやパフォーマンスの最適化にも直結します。異なるモデルやツールキットを評価し、組織のニーズに最適な組み合わせを見つけることができるからです。

2.2 信頼性と可用性の実現

Frank Fan：信頼性と可用性の実現は、AI/MLワークロードにおいて特に重要な課題です。私のデモでお見せする画像生成アプリケーションを例に取ると、フロントエンドとバックエンドの推論エンドポイント間の信頼性確保が重要になります。計画的または予期せぬ障害が発生した場合でも、環境全体が継続して稼働し続ける必要があります。

Abhishek：その通りですね。信頼性については、特に二つの重要な側面があります。一つは結果の一貫性と正確性で、これはモデルの出力が安定していることを意味します。もう一つは、エンドユーザーからのリクエストに対する高可用性の確保です。これはシステム全体の設計に大きく関わってきます。

Steve Kendrex：具体的な実装方法として、同期型と非同期型のアプローチを比較してみましょう。同期型は単純でエラーの即時検出が可能ですが、スパイク的な負荷への対応や、バックエンドの障害時の影響が課題となります。

Frank Fan：そうですね。そのため、私たちは非同期型のアプローチを推奨しています。メッセージブローカーを中間に配置することで、フロントエンドとバックエンドを分離し、システムの信頼性を向上させることができます。例えば、エンドユーザーからのリクエストをSNSで受け取り、属性に基づいて異なるSQSキューに振り分けることで、プレミアムユーザーと一般ユーザーで異なるサービスレベルを提供することも可能です。

Abhishek：その設計は興味深いですね。各キューに異なるインスタンスタイプを関連付けることで、プレミアムユーザーには最高性能のインスタンスを、一般ユーザーにはコスト効率の良いインスタンスを割り当てることができます。また、複数のランタイムを組み合わせることで、異なるユースケースに対応することも可能です。

Frank Fan：そして重要なのは、メッセージの確実な処理です。SQSでは、処理が完了するまでメッセージは削除されず、処理に失敗した場合は別のタスクで再試行されます。これにより、システムの信頼性が大きく向上します。また、S3への画像保存やユーザーへの通知など、全ての処理ステップが完了してはじめてメッセージが削除される設計としています。

Steve Kendrex：このような設計により、個々のコンポーネントの障害が全体に波及することを防ぎ、高い信頼性と可用性を実現できますね。ECSの既存ユーザーにとって、これらのパターンは従来のアプリケーションでも使用されている馴染みのある設計だと思います。

2.3 パフォーマンスの最適化

Frank Fan：パフォーマンスの最適化は、エンドユーザー体験に直接影響を与える重要な要素です。私の経験では、特に画像生成のような推論アプリケーションでは、エンドポイントの応答性能と処理時間が重要になります。例えば、ユーザーが画像生成を要求してから結果が表示されるまでの時間を最小限に抑える必要があります。

Abhishek：その通りですね。パフォーマンスを考える際には、アプリケーションの性質に応じて適切なアプローチを選択する必要があります。チャットボットのような対話型アプリケーションでは、ユーザーとの迅速なインタラクションが求められます。一方で、バッチ処理のような非同期処理が適している場合もあります。

Steve Kendrex：コンピュートリソースの選択も重要な要素ですね。CPU、GPU、AWS Inferentiaなど、様々な選択肢がありますが、それぞれの特性を理解して適切に選択する必要があります。

Frank Fan：具体的な例を挙げると、私たちのデモ環境では、G6eインスタンスを使用しています。このインスタンスは最大8個のGPUを搭載し、各GPUは48GB以上のメモリを備えています。G5やG6と比較して、少なくとも3倍のパフォーマンスを実現できます。また、シングルカードアーキテクチャを採用しているため、リアルタイム推論ワークロードに最適です。

Abhishek：パフォーマンス最適化には、インスタンスの選択だけでなく、モデルのロード時間の短縮も重要です。例えば、コンテナイメージのサイズを20GBから1GB未満に削減し、起動時間を6分から1分未満に短縮した事例があります。また、モデルのロード時間も30秒から10秒に短縮することができました。

Frank Fan：そうですね。私たちのアプローチでは、Bottlerocket OSを使用してデータボリュームを最適化し、EBSのパフォーマンスを1,000MB/sに最大化することで、高速なファイルアクセスを実現しています. また、ウォームプールを活用することで、インスタンスの事前初期化も行っています。

Steve Kendrex：これらの最適化により、例えば画像生成の場合、リクエストから結果生成までわずか1.4秒程度で完了することができます。このレベルのパフォーマンスは、ユーザー体験の向上に直接つながりますね。

2.4 スケーラビリティの実現

Abhishek：スケーラビリティは、AI/MLワークロードにおいて特に重要な課題です。私たちが推奨するのは、顧客向けアプリケーションとモデル層を分離し、それぞれが独立してスケーリングできる設計です。例えば、Webベースのアプリケーションでは、ユーザーセッション数やリクエスト数に基づいてアプリケーション層をスケーリングし、一方でモデル層は処理待ちのタスク数に基づいてスケーリングするといった具合です。

Frank Fan：具体的な実装では、キューの深さを重要なメトリクスとして活用しています。例えば、アクティブなタスク数が3で、キュー内に12の保留中のジョブがある場合、単純に12÷3=4で、タスクあたり4つの保留ジョブと計算できます。しかし、負荷テストの結果、タスクあたりの保留ジョブ数が10を超えると性能が低下することが判明しました。そのため、このメトリクスをカスタムメトリクスとして定義し、スケーリングの判断に使用しています。

Steve Kendrex：そのアプローチは興味深いですね。スケーリングの判断基準として、単純なキューの深さだけでなく、アクティブなタスク数との関係を考慮することで、より適切なスケーリングが可能になりますね。

Abhishek：はい。また、ECSのサービスオートスケーリング機能を活用することで、事前定義されたメトリクスやカスタムメトリクスに基づいて、自動的にスケーリングを行うことができます。例えば、CPUやメモリの使用率、リクエスト数、キューの深さなど、様々なメトリクスを組み合わせることが可能です。

Frank Fan：さらに、最近導入された予測スケーリング機能も非常に有効です。この機能は機械学習ベースのアルゴリズムを使用して、毎朝9時のトラフィック増加や、毎週月曜日の利用ピークなど、周期的なパターンを自動的に検出し、プロアクティブにスケーリングを行います。これにより、手動でのスケジュール設定や過剰なプロビジョニングが不要になります。

Steve Kendrex：予測スケーリングとターゲットトラッキングを組み合わせることで、定期的なパターンと予期せぬトラフィック変動の両方に効果的に対応できますね。予測スケーリングがセーフティネットとして機能し、ターゲットトラッキングが実際の負荷に応じた微調整を行う、という組み合わせは特に効果的です。

2.5 コスト最適化の必要性

Abhishek：コスト最適化は、スケーラビリティと密接に関連する重要な課題です。ECSでは、コンピュートオプションに応じて様々なコスト最適化の手法を提供しています。例えば、EC2とFargateの両方で、Gravitonベースのインスタンスを使用することで、より良い価格性能比を実現できます。

Steve Kendrex：そうですね。また、EC2インスタンスを使用する場合、スポットインスタンスやセービングプランなどの割引オプションを活用することで、大幅なコスト削減が可能です。特にAI/MLワークロードでは、GPUインスタンスのコストが大きな割合を占めるため、これらの最適化は重要です。

Frank Fan：実際の運用では、スケールダウン戦略も重要です。私たちのデモ環境では、バックログタスク数に基づいてスケーリングを行い、需要が減少した際は自動的にリソースを縮小します。また、EBSボリュームのパフォーマンスについても、初期のファイル読み込み後はLambda関数を使って容量を削減するなど、きめ細かな最適化を行っています。

Abhishek：その通りです。また、非同期アーキテクチャを採用することで、スポットインスタンスの活用がより効果的になります。メッセージがキューで保持される設計により、スポットインスタンスが利用できない場合でもメッセージは失われず、処理の再試行が可能です。これにより、信頼性を維持しながらコストを最適化できます。

Steve Kendrex：さらに、予測スケーリングを活用することで、過剰なプロビジョニングを回避できますね。事前に需要パターンを予測してスケーリングすることで、必要なリソースを必要な時にだけ確保することができます。

Frank Fan：はい。また、プレミアムユーザーと一般ユーザーでインスタンスタイプを分けることで、コストとパフォーマンスのバランスを取ることも可能です。例えば、高性能なGPUインスタンスをプレミアムユーザー向けに、より cost-effective なインスタンスを一般ユーザー向けに割り当てるといった戦略です。

3. アーキテクチャの設計

3.1 顧客向けアプリケーション層の設計

Abhishek：AI/MLアプリケーションの設計において、私たちが推奨するのは、顧客向けアプリケーション層とモデル層を明確に分離する方式です。これは基本的にマイクロサービスアーキテクチャの考え方に基づいています。例えば、Webベースのアプリケーションの場合、ロードバランサーを介してユーザーリクエストを受け付け、ECSサービスとして実行される複数のタスクで処理を行います。

Steve Kendrex：その分離アプローチの利点について補足させてください。チーム間で技術選択を分離でき、それぞれのチームが適切な技術スタックを選択できます。また、アプリケーション層とモデル層が独立してスケールできる点も大きな利点です。

Frank Fan：実際の実装では、フロントエンドアプリケーションはAPI Gatewayを通じてリクエストを受け付け、認証・認可にはAPI Keyを使用しています。Lambda関数で検証を行った後、SNSを介して属性に基づいて異なるSQSキューにメッセージを振り分けます。これにより、プレミアムユーザーと一般ユーザーで異なるサービスレベルを提供することが可能になります。

Abhishek：その通りです。このアーキテクチャにより、フロントエンドチームはユーザー体験の最適化に集中でき、モデルチームはモデルの性能改善に注力できます。また、ユーザーセッションの管理も、フロントエンドアプリケーションで完結させることができます。セッション数やリクエスト数に基づいてアプリケーション層をスケールし、モデル層は処理待ちタスク数に基づいて独立してスケールする、という柔軟な運用が可能になります。

Steve Kendrex：このアプローチにより、より早いタイムトゥマーケットも実現できますね。各チームが独立して開発とデプロイメントを行えるため、組織全体のアジリティが向上します。また、サーバーレスパターンを採用することで、インフラストラクチャの管理負荷も軽減できます。

3.2 モデル層の設計と選択肢

Abhishek：モデル層の設計において、最も重要なのはモデルエンドポイントの分離です。顧客向けアプリケーションとモデルエンドポイントを分離することで、それぞれのチームが独自の技術スタックを選択でき、独立したスケーリングも可能になります。

Frank Fan：具体的な実装では、興味深い選択肢があります。モデルエンドポイントは必ずしもECSである必要はありません。例えば、Amazon BedrockのようなフルマネージドのサーバーレスAPIサービスを使用することもできますし、SageMakerを使用してモデルのトレーニングとデプロイを行うことも可能です。また、ECS上で完全にセルフホストすることもできます。

Steve Kendrex：その選択の基準について説明いただけますか？

Abhishek：はい。例えばAmazon Bedrockは、使いやすさを重視する場合に最適です。幅広い基盤モデルにアクセスでき、サーバーレスでAPIとして利用できます。一方、SageMakerは機械学習に特化した環境を提供し、モデルの構築からデプロイまでをカバーします。ECSでのセルフホストは、最も柔軟性が高く、モデルの実行環境やライブラリの選択を完全にコントロールできます。

Frank Fan：私のデモでは、ECSでのセルフホストを選択しました。その理由は、組織がすでにECSでの運用経験を持っており、既存のツールやプラットフォームを拡張できるからです。また、モデルの選択やインフラストラクチャの構成に関して完全な制御が可能で、特にGPUインスタンスの選択やカスタムランタイムの利用が自由にできます。

Abhishek：その通りです。ECSを選択することで、AWSの他のサービスとの深い統合も活用できます。例えば、オブザーバビリティ、セキュリティ、アプリケーションオートスケーリングなどの機能を活用でき、さらにFargateと組み合わせることで、サーバーレスコンピュートも利用可能です。

Steve Kendrex：このアプローチにより、異なるチームが独立して開発を進められ、組織全体のアジリティが向上しますね。モデル層の独立したスケーリングも、コスト効率とパフォーマンスの最適化に大きく貢献します。

3.3 サーバーレスアーキテクチャの活用

Abhishek：顧客向けアプリケーションにおいて、私たちは特にサーバーレス技術の活用を推奨しています。サーバーレスを採用することで、チームは基盤となるインフラストラクチャの管理ではなく、ビジネスロジックの開発に集中できます。サーバーレステクノロジーの選択肢は、その設計の自由度と制御性に応じて幅広いスペクトラムを形成しています。

Steve Kendrex：そうですね。そのスペクトラムの中で、AWS Lambdaは最も高度に最適化されたサーバーレスソリューションです。ただし、Lambda特有のプログラミングモデルや実行時間の制限、ストレージ制限などの制約があります。一方、ECSは異なるアプローチを提供しています。

Abhishek：ECS自体がサーバーレスコントロールプレーンとして機能する点が重要です。クラスターのバージョン更新やプラットフォームの更新について心配する必要がなく、ECSが全てを管理してくれます。新機能は自動的に利用可能になり、アップグレードについて考える必要もありません。

Frank Fan：その上で、ECS with Fargateを使用すると、完全なサーバーレス体験が得られます。これにより、サーバーのパッチ適用やセキュリティ要件への対応など、差別化につながらない作業からチームを解放できます。

Steve Kendrex：一方で、AI/MLワークロードでは特定のアクセラレータが必要な場合もありますね。その場合は、EC2コンピュートを使用してインフラストラクチャをより詳細に制御することができます。これは特に性能のベンチマークで特定のアクセラレータが有効だと判明した場合に重要です。

Abhishek：その通りです。ECSの素晴らしい点は、このように柔軟な選択が可能なことです。Fargateでサーバーレスの利点を活用しながら、必要に応じてEC2でより詳細な制御も可能です。これにより、アプリケーションの要件に応じて最適なアプローチを選択できます。

4. ECSにおけるコンピュート選択肢

4.1 AWS Fargateの活用

Abhishek：ECSでは、様々なコンピュートオプションが利用可能です。その中でもAWS Fargateは、完全なサーバーレスコンピューティングを提供する選択肢として注目に値します。AI/MLワークロードにおいても、特に小規模なモデルのサービングや、CPUベースの推論に適しています。

Steve Kendrex：特筆すべきは、Fargateを使用することで、基盤となるインフラストラクチャの管理から完全に解放されることです。サーバーのパッチ適用やメンテナンス、セキュリティ要件への対応など、差別化につながらない作業を全てAWSに任せることができます。

Frank Fan：私の経験では、全てのAI/MLワークロードがGPUを必要とするわけではありません。小規模なモデルや、レイテンシ要件が厳しくないワークロードでは、CPUベースのサービングで十分な場合が多いです。そういった場合、Fargateは非常に魅力的な選択肢となります。

Abhishek：その通りです。さらに、FargateではGravitonインスタンスも利用可能で、より良い価格性能比を実現できます。例えば、CPUベースの推論ワークロードでGravitonを使用することで、コスト効率を最適化しながら必要なパフォーマンスを確保できます。

Steve Kendrex：また、FargateはECSのサーバーレスコントロールプレーンと完全に統合されているため、スケーリングやモニタリングも seamless に行えます。オートスケーリングポリシーを設定するだけで、需要に応じて自動的にタスク数を調整できます。

Frank Fan：確かに、特にフロントエンドアプリケーションやキューベースの非同期処理など、GPUを必要としないコンポーネントでは、Fargateの活用が有効ですね。コスト最適化の観点からも、必要に応じてFargateとEC2を使い分けることで、より効率的なアーキテクチャを実現できます。

4.2 EC2インスタンスの活用

Frank Fan：EC2インスタンスの選択は、特にAI/ML推論ワークロードにおいて重要な決定となります。私たちのデモ環境では、G6eインスタンスを採用しています。このインスタンスファミリーは最大8個のGPUを搭載し、各GPUは48GB以上のメモリを備えており、G5やG6と比較して少なくとも3倍のパフォーマンスを実現できます。

Abhishek：アクセラレータの選択には、いくつかの重要な考慮事項がありますね。CPUは汎用的で費用対効果が高く、小規模なモデルには適していますが、より大規模なモデルやレイテンシ要件の厳しいワークロードではGPUが効果的です。また、AWS InferentiaのようなASIC（特定用途向け集積回路）は、推論ワークロード専用に設計されているため、高性能かつコスト効率に優れています。

Steve Kendrex：ただし、InferentiaのようなASICを使用する場合は、AWS Neuron SDKを通じて特定の演算を公開する必要があり、モデルの互換性を確認する必要がありますね。

Frank Fan：そうです。特にGPUインスタンスを選択する際は、GPU世代、メモリサイズ、帯域幅を考慮する必要があります。例えば、リアルタイム推論ワークロードには、シングルカードアーキテクチャのG6eが適していることがテストで判明しています。

Abhishek：さらに、ECSはオートスケーリンググループと深く統合されており、アプリケーションの需要に応じて自動的にインスタンス数を調整できます。これにより、コスト効率を維持しながら、必要な時に必要なだけのリソースを確保できます。

Steve Kendrex：そして、キャパシティプロバイダーを活用することで、オンデマンドインスタンスとスポットインスタンスを組み合わせた柔軟な構成も可能ですね。特にワークロードが中断に対して耐性がある場合、スポットインスタンスの活用は大きなコスト削減につながります。

4.2 EC2インスタンスの活用

Frank Fan：EC2インスタンスの選択は、特にAI/ML推論ワークロードにおいて重要な決定となります。私たちのデモ環境では、G6eインスタンスを採用しています。このインスタンスファミリーは最大8個のGPUを搭載し、各GPUは48GB以上のメモリを備えており、G5やG6と比較して少なくとも3倍のパフォーマンスを実現できます。

Abhishek：アクセラレータの選択には、いくつかの重要な考慮事項がありますね。CPUは汎用的で費用対効果が高く、小規模なモデルには適していますが、より大規模なモデルやレイテンシ要件の厳しいワークロードではGPUが効果的です。また、AWS InferentiaのようなASIC（特定用途向け集積回路）は、推論ワークロード専用に設計されているため、高性能かつコスト効率に優れています。

Steve Kendrex：ただし、InferentiaのようなASICを使用する場合は、AWS Neuron SDKを通じて特定の演算を公開する必要があり、モデルの互換性を確認する必要がありますね。

Frank Fan：そうです。特にGPUインスタンスを選択する際は、GPU世代、メモリサイズ、帯域幅を考慮する必要があります。例えば、リアルタイム推論ワークロードには、シングルカードアーキテクチャのG6eが適していることがテストで判明しています。

Abhishek：さらに、ECSはオートスケーリンググループと深く統合されており、アプリケーションの需要に応じて自動的にインスタンス数を調整できます。これにより、コスト効率を維持しながら、必要な時に必要なだけのリソースを確保できます。

Steve Kendrex：そして、キャパシティプロバイダーを活用することで、オンデマンドインスタンスとスポットインスタンスを組み合わせた柔軟な構成も可能ですね。特にワークロードが中断に対して耐性がある場合、スポットインスタンスの活用は大きなコスト削減につながります。

4.3 ECS Anywhereのハイブリッドデプロイメント

Abhishek：ECS Anywhereは、AI/MLワークロードをハイブリッド環境で実行するための重要な選択肢となっています。特に、厳格なデータレジデンシーやプライバシー要件がある組織にとって、オンプレミス環境でのデータ収集と処理を行いながら、クラウドでのモデル実行を組み合わせることが可能になります。

Steve Kendrex：具体的な利用パターンとして、私たちはお客様がオンプレミスでデータを収集し、そのデータに対して推論を実行するハイブリッドアプローチを多く見ています。これにより、データプライバシーを維持しながら、クラウドの利点も活用できます。

Frank Fan：その通りです。私の経験では、特に金融機関や医療機関など、規制要件の厳しい業界でこのアプローチが有効です。オンプレミスでのデータ処理とクラウドでのモデル実行を組み合わせることで、コンプライアンス要件を満たしながら、AI/MLの能力を最大限に活用できます。

Abhishek：また、ECS Anywhereは既存のECSツールやプラットフォームとシームレスに統合されるため、ハイブリッド環境であっても一貫した運用が可能です。これは、オンプレミスとクラウドの両方の環境を管理する必要がある組織にとって大きな利点となります。

Steve Kendrex：KeplerのようなOEM向けに、ハイブリッドクラウド戦略はそのクラウドジャーニーを加速する重要な要素となっています。段階的なクラウド移行を可能にしながら、既存のオンプレミスインフラストラクチャも活用できる柔軟性は、多くの組織にとって魅力的な選択肢となっていますね。

5. スケーリング戦略

5.1 サービスオートスケーリング

Abhishek：ECSのサービスオートスケーリングは、AWS Application Auto Scalingとの深い統合により実現されています。このサービスを通じて、様々なスケーリングポリシーを利用できます。例えば、ECSが提供する事前定義されたメトリクス（CPU使用率やロードバランサーのリクエスト数など）や、独自のカスタムメトリクスを使用してスケーリングを制御できます。

Frank Fan：スケーリングポリシーの選択は非常に重要ですね。私たちのデモ環境では、より細かな制御が必要だったため、ステップスケーリングを採用しました。これにより、タスク数の増減をきめ細かく定義でき、例えばキューの深さに応じて段階的にスケールアウトすることが可能です。

Steve Kendrex：また、ターゲットトラッキングスケーリングも効果的な選択肢の一つですね。例えば、CPU使用率を平均75%に維持するというターゲットを設定するだけで、ECSとオートスケーリングが自動的にタスク数を調整してくれます。

Abhishek：そうですね。さらに、スケジュールドスケーリングを使用することで、予測可能なトラフィックパターンに対応することもできます。例えば、毎朝9時にトラフィックが増加し、午後5時に減少するようなパターンがある場合、事前に定義したスケジュールでスケーリングを行うことができます。

Frank Fan：私たちの実装では、カスタムメトリクスとして「バックログタスク数」を重要な指標として活用しています。アクティブなタスク数に対する保留中のジョブ数の比率を監視することで、より適切なスケーリング判断が可能になりました。実際のテストでは、タスクあたりの保留ジョブ数が10を超えると性能が低下することが判明したため、この指標を基にスケーリングポリシーを設定しています。

Steve Kendrex：そして、これらのスケーリングポリシーは組み合わせることも可能ですね。例えば、スケジュールドスケーリングで基本的なキャパシティを確保しながら、ターゲットトラッキングで細かな調整を行うといった戦略も効果的です。

5.2 予測スケーリングの活用

Abhishek：約2週間前に発表された予測スケーリングは、私たちが非常に期待している新機能です。これは機械学習ベースのアルゴリズムを使用して、アプリケーションの需要パターンを自動的に学習し、予測的にスケーリングを行う革新的な機能です。

Steve Kendrex：具体的な例を挙げると、毎朝9時にトラフィックが増加し、午後5時に減少するような定期的なパターンや、毎週月曜日に特定のトラフィックパターンが発生するような周期的な需要変動を、システムが自動的に検出し学習することができますね。

Frank Fan：その通りです。従来のスケジュールドスケーリングでは、このようなパターンに対応するために手動で設定を行う必要がありましたが、予測スケーリングではそれが不要になります。システムが自動的にパターンを検出し、事前にリソースをスケールアウトすることで、より効率的な運用が可能になります。

Abhishek：重要な点は、予測スケーリングが他のスケーリングポリシーと補完的に動作するように設計されていることです。私たちは特に、ターゲットトラッキングと予測スケーリングの組み合わせを推奨しています。予測スケーリングが事前にリソースを確保し、ターゲットトラッキングが実際の負荷に応じて微調整を行うという組み合わせが効果的です。

Steve Kendrex：また、予測スケーリングは単独ではアプリケーションのスケールダウンを行わない点も特徴的ですね。これにより、予測的なスケールアウトの安全性を確保しながら、他のスケーリングポリシーと組み合わせることで、総合的なスケーリング戦略を実現できます。

Frank Fan：実際の運用では、予期せぬトラフィックスパイクと定期的なパターンの両方に効果的に対応できることが重要です。予測スケーリングにより、手動での介入やオーバープロビジョニングを減らしながら、より効率的なリソース管理が可能になっています。

5.3 キャパシティプロバイダーの役割

Abhishek：キャパシティプロバイダーは、サービスのスケーリングニーズに合わせて基盤となるインフラストラクチャを自動的に調整する重要な機能です。例えば、サービスが3つのタスクの起動を要求した場合、キャパシティプロバイダーが必要なインスタンス数を自動的に判断して起動します。

Frank Fan：私のデモ環境では、特にGPUインスタンスのような高コストなリソースを効率的に管理するために、キャパシティプロバイダーが重要な役割を果たしています。例えば、スポットインスタンスを活用することで、コストを大幅に削減できます。非同期アーキテクチャを採用しているため、スポットインスタンスが利用できない場合でもメッセージは失われることなく、別のインスタンスで処理を再開できます。

Steve Kendrex：また、Auto Scaling Groupのウォームプールも重要な機能ですね。特にAI/MLワークロードでは、大規模なGPUインスタンスの起動に時間がかかるため、事前に初期化されたインスタンスをプールしておくことで、起動時間を短縮できます。

Abhishek：その通りです。ウォームプールを使用することで、インスタンスを事前に初期化しておき、必要なときにすぐに使用できる状態にしておくことができます。これは、オーバープロビジョニングによるコスト増加を避けながら、迅速なスケールアウトを実現する効果的な方法です。

Frank Fan：実際の運用では、タスクあたりの保留ジョブ数に基づいてスケーリングを行い、需要の変動に応じてインスタンス数を自動調整しています。また、スポットインスタンスとオンデマンドインスタンスを組み合わせることで、コストとリスクのバランスを取ることができます。

Steve Kendrex：さらに、キャパシティプロバイダーは予測スケーリングやその他のスケーリングポリシーと連携して動作し、アプリケーション層とインフラストラクチャ層の両方で一貫したスケーリングを実現できますね。

6. ストレージとモニタリング

6.1 ストレージオプションの選択

Frank Fan：AI/MLアプリケーションのストレージ戦略について、私たちは幾つかの重要な選択肢を検討しました。まず、モデルファイルをコンテナイメージにバンドルする方法がありますが、これは従来型のアプリケーションでは一般的でも、AI/MLワークロードには適していません。なぜなら、モデルサイズが数GBから数百GBに及ぶ場合、アプリケーションのロード時間が大幅に遅くなってしまうからです。

Abhishek：その通りですね。また、S3からランタイムにモデルをプルする方法もありますが、私たちの経験では、Amazon EFSを使用する方法が最も効果的です。EFSは高いレイテンシとスループットを提供し、弾力的にファイルを扱うことができます。

Steve Kendrex：具体的な最適化事例を共有できますか？

Frank Fan：はい。私たちのデモ環境では、コンテナイメージのサイズを20GBから1GB未満に削減することに成功しました。これにより、イメージのロード時間を6分から1分未満に短縮できました。また、モデルのロード時間も30秒から10秒に短縮しています。これはBottlerocket OSを活用し、データボリュームを最適化した結果です。

Abhishek：EBSのパフォーマンスも重要ですね。初期のファイル読み込み時には1,000MB/sまでパフォーマンスを最大化し、その後はLambda関数を使用して容量を削減するアプローチを採用しています。

Frank Fan：さらに、EFSを使用することで、新しいモデルファイルをボリュームに追加するだけで、コンテナから即座にアクセスできるようになります。これにより、モデルの更新や切り替えが非常に柔軟になりました。また、S3を使用して生成された画像を保存し、ユーザーに提供するという統合的なアプローチも採用しています。

6.2 CloudWatchとの統合

Abhishek：ECSはAmazon CloudWatchと深く統合されており、特にCloudWatch Container Insightsを通じて様々なメトリクスを提供しています。この週初めに発表された強化版のCloudWatch Container Insightsでは、タスクとコンテナレベルでより詳細なメトリクスが利用可能になりました。

Steve Kendrex：ただし、現在のECSでは、GPUの予約状況は把握できますが、GPU使用率やGPU温度などの詳細なメトリクスはまだ標準では提供していませんね。

Frank Fan：その通りです。そのため、私たちのデモ環境では、NVIDIA Data Center GPU Manager（DCGM）パッケージをECSにインストールして、これらのGPUメトリクスを収集しています。実際のデモでは、ADOTとDCGMを組み合わせることで、詳細なGPUメトリクスのモニタリングを実現しています。

Abhishek：モニタリングのアプローチとしては、主に二つのパターンがあります。一つはサイドカーパターンで、ADOTコンテナをタスク内の他のコンテナと一緒に実行し、メトリクス、ログ、トレースを収集してバックエンドにプッシュします。もう一つは中央集中型パターンで、専用のタスクでADOTを実行し、他のタスクから情報を収集します。

Steve Kendrex：将来的には、より詳細なGPUメトリクスをECSの標準機能として提供することをロードマップに入れていますが、現時点ではDCGMを活用する方法が最も効果的ですね。

Frank Fan：はい。特にAI/MLワークロードでは、GPUの使用状況を詳細に把握することが重要です。私たちのデモ環境では、これらのメトリクスを使用して、パフォーマンスのボトルネックを特定し、リソースの使用効率を最適化しています。さらに、これらのメトリクスはスケーリングの判断にも活用できます。

6.3 FireLensとX-Rayの活用

Abhishek：モニタリング戦略における重要な要素として、FireLensとAWS X-Rayの活用があります。FireLensを使用することで、ログやメトリクスを柔軟にパートナーソリューションやAWSの他のサービスにルーティングすることができます。CloudWatchを使用したくない場合や、異なるAWSサービスにログを転送したい場合に特に有効です。

Frank Fan：私たちのデモ環境では、X-Rayデーモンをコンテナと一緒にタスクの中で実行しています。これにより、AI/MLワークロードのエンドツーエンドのリクエストトレーシングが可能になります。例えば、ユーザーリクエストがAPI Gatewayを通じてLambda関数に渡され、SNSを経由してSQSキューに入り、最終的に推論エンドポイントで処理されるまでの全フローを追跡できます。

Steve Kendrex：トラブルシューティングの観点からも、この可視性は非常に重要ですね。実際のデモでは、X-Rayを使用してリクエストの処理時間が約1.4秒であることを確認できました。

Frank Fan：その通りです。また、分散トレーシングを実装する方法として、私たちは二つのパターンを推奨しています。一つはサイドカーパターンで、Amazon Distro for OpenTelemetry（ADOT）をコンテナと共にタスク内で実行します。もう一つは中央集中型パターンで、ADOTを専用のタスクで実行し、複数のタスクから情報を収集します。

Abhishek：これらのモニタリングツールを組み合わせることで、パフォーマンスの問題や障害の迅速な特定と解決が可能になります。特にAI/MLワークロードのように複雑なシステムでは、この種の詳細な可視性が運用上不可欠です。

Steve Kendrex：また、これらのツールはECSと深く統合されているため、追加の設定作業を最小限に抑えながら、包括的なモニタリングソリューションを構築できますね。

7. 実装デモ

7.1 信頼性の実現方法

Frank Fan：実装デモとして、まず信頼性の実現方法についてご説明します。私たちのデモ環境では、前進型のイメージ生成アプリケーションを実装しています。基本的なアーキテクチャとして、エンドユーザーがフロントエンドに接続し、バックエンドの推論エンドポイントと連携する構造を採用しています。

Steve Kendrex：同期型のアーキテクチャも検討されたのでしょうか？

Frank Fan：はい。同期型は単純で失敗の即時検出が可能ですが、スパイクワークロードへの対応やバックエンドの障害時の影響が課題となります。そのため、私たちは非同期型のアプローチを採用しました。SNSとSQSを使用したメッセージブローカーを実装することで、フロントエンドとバックエンドを分離し、システムの信頼性を向上させています。

Abhishek：具体的な実装フローを説明していただけますか？

Frank Fan：はい。まず、エンドユーザーのリクエストはAPI Gatewayで受け付け、API Keyによる認証を行います。その後、Lambda関数で検証を行い、SNSを介して属性に基づいて異なるSQSキューにメッセージを振り分けます。例えば、ユーザーが「馬が走っている」という単純なプロンプトを送信すると、それがこのフローで処理されます。

Steve Kendrex：エラーハンドリングはどのように実装されていますか？

Frank Fan：SQSのメッセージは、処理が完全に完了するまで削除されない設計としています。具体的には、次の4つのステップが全て完了するまでメッセージは保持されます。まず、キュー内のジョブをエージェントが取得し、SD（Stable Diffusion）ランタイムに渡します。次に、生成された画像をS3バケットに保存します。そして、エンドユーザーに完了通知を送信します。最後に、全てが成功した時点でメッセージを削除します。これにより、どの段階で障害が発生しても、別のタスクで処理を再試行できます。

Abhishek：この実装により、フロントエンドの可用性を維持しながら、バックエンドの処理を確実に行うことができますね。また、スパイク的な負荷に対しても、キューがバッファとして機能することで、システム全体の安定性が向上します。

7.2 パフォーマンス最適化の実践

Frank Fan：私たちのデモ環境では、パフォーマンス最適化の実践として、特に三つの重要な側面に焦点を当てました。まず、ホストの起動を高速化するためにAuto Scaling Groupのウォームプールを活用し、インスタンスを事前に初期化する方法を採用しています。

Steve Kendrex：コンテナイメージのサイズが非常に大きいという課題がありましたよね。

Frank Fan：はい。当初、推論エンドポイントのコンテナイメージには、PyTorch、依存関係、CUDAドライバーなど、多くのコンポーネントが含まれており、サイズが14GBにも達し、ロードに6分もかかっていました。これを改善するため、Bottlerocket OSを活用した新しいアプローチを採用しました。

Abhishek：具体的にはどのような方法を取られたのでしょうか？

Frank Fan：Bottlerocket OSは、OSボリュームとデータボリュームの2つのボリュームを持っています。OS部分はセキュリティパッチなど独自のライフサイクルで更新されますが、データボリュームに大きな推論エンドポイントイメージを配置し、そのEBSボリュームのスナップショットを作成して他のECSインスタンスにマップする方法を採用しました。これにより、イメージサイズを20GBから1GB未満に削減し、ロード時間を1分未満に短縮することができました。

Steve Kendrex：モデルファイルのロードについてはどのような最適化を行いましたか？

Frank Fan：モデルファイルについては、Amazon EFSを活用することで、より良いレイテンシとスループットを実現しています。EBSのパフォーマンスを初期ロード時に1,000MB/sまで最大化し、その後Lambda関数を使用して容量を削減するアプローチを採用しました。これにより、モデルのロード時間を30秒から10秒に短縮することができました。また、EFSを使用することで、新しいモデルの追加も容易になり、コンテナから即座にアクセス可能になっています。

7.3 スケーラビリティのデモンストレーション

Frank Fan：デモ環境では、継続的なリクエストを生成する負荷テストを実施し、システムのスケーリング能力を実証しました。特に注目すべき点は、バックログタスク数という独自のメトリクスを使用している点です。このメトリクスは、保留中のジョブ数をアクティブなタスク数で割ることで算出されます。

Abhishek：それは興味深いアプローチですね。なぜそのメトリクスを選択したのでしょうか？

Frank Fan：負荷テストを通じて、タスクあたりの保留ジョブ数が10を超えると性能が低下することが判明したためです. メトリクスがしきい値を超えると、新しいタスクの起動がトリガーされますが、このタスクは一時的にペンディング状態となります。これは、バックエンドのEC2インスタンスがまだ準備できていないためです。

Steve Kendrex：Auto Scalerの動作はどのように確認されましたか？

Frank Fan：ダッシュボードを通じて、メトリクスが500-600まで上昇し、希望するタスク数が10に設定されていることを確認できました。キャパシティプロバイダーがシグナルを受け取り、バックエンドのEC2インスタンスリストを拡張していく様子も観察できました。EC2インスタンスが準備できると、タスクの増加とCPU使用率の安定化が確認できました。

Abhishek：また、テスト完了後のスケールインも重要なポイントですね。

Frank Fan：その通りです。負荷が減少すると、システムは自動的にスケールインを開始し、不要なリソースを解放します。これにより、コストを最適化しながら、需要の変動に効果的に対応できることを実証できました。最終的にはEC2コンソールで、全てのインスタンスが正常に動作していることを確認しました。

8. 実例と成功事例

8.1 Womboとシナリオの事例

Steve Kendrex：ECSを活用したgen AI実装の成功事例として、WomboとScenarioの事例が特筆すべきものです。両社とも、ECSとFargateを活用することで、市場投入までの時間を大幅に短縮することに成功しています。

Abhishek：特に興味深いのは、彼らがgen AIの推論ワークロードを実装する際に、ECSを選択した理由ですね。既存のインフラストラクチャとツールを活用できる点が、開発速度の向上に大きく貢献したと聞いています。

Steve Kendrex：その通りです。彼らのケースでは、EC2とFargateを使い分けることで、コストとパフォーマンスの最適なバランスを実現しています。パフォーマンス要件の高い推論ワークロードにはEC2を、その他のコンポーネントにはFargateを使用するというアプローチを採用しました。

Frank Fan：私が注目したのは、彼らの実装が私たちのデモで示した非同期アーキテクチャと類似している点です。SNSとSQSを活用したメッセージブローカーの実装により、システムの信頼性と拡張性を確保しています。

Abhishek：また、両社ともECSのサーバーレスコントロールプレーンを最大限に活用していますね。クラスターのバージョン管理や更新の心配なく、新機能を即座に利用できる点が、開発の加速に貢献したと聞いています。

Steve Kendrex：彼らの成功の鍵は、既存のECSの知見とツールを活用しながら、gen AI特有の要件に対応できる柔軟なアーキテクチャを構築できた点にあると言えるでしょう。これは、既存のECSユーザーがgen AIを始める際の良いモデルケースとなっています。

8.2 Keplerのハイブリッド活用事例

Steve Kendrex：Keplerの事例は、ECS Anywhereを活用したハイブリッドアプローチの効果的な実装例です。彼らは機械学習ワークロードをクラウドとオンプレミス環境の両方で実行することで、より早いクラウド移行を実現しました。

Abhishek：特に注目すべきは、彼らのデータ収集アプローチですね。データレジデンシーやプライバシー要件に対応するため、オンプレミスでデータを収集し、クラウドで推論を実行するハイブリッドパターンを採用しています。

Steve Kendrex：そうです。Keplerは特にOEM向けのユースケースで、このハイブリッドアプローチを効果的に活用しています。厳格なデータ要件を満たしながら、クラウドの利点も最大限に活用できる点が、彼らの成功の鍵となっています。

Frank Fan：技術的な観点から興味深いのは、彼らがECS Anywhereを使用してオンプレミス環境とクラウド環境を一貫した方法で管理している点です。これにより、運用の複雑さを最小限に抑えながら、段階的なクラウド移行を実現しています。

Abhishek：また、既存のツールやプラットフォームをシームレスに拡張できる点も重要ですね。ECSの深いAWSサービス統合を活かしながら、オンプレミスのインフラストラクチャも効果的に活用しています。

Steve Kendrex：このアプローチにより、Keplerは既存のオンプレミスインフラストラクチャへの投資を活かしながら、クラウドへの移行を加速することができました。これは、同様の要件を持つ他の組織にとっても、有効なモデルケースとなっています。

8.3 AmazonのRufus実装事例

Steve Kendrex：AmazonのRufus実装は、ECSを大規模なgen AI実装に活用した重要な事例です。昨日のAndy Jassyの基調講演でも触れられていましたが、Rufusは世界最大のEコマースプラットフォームにおいて、買い物体験をよりパーソナライズされた形で提供するために開発されました。

Abhishek：技術的な観点から注目すべきは、RufusがAWS TrainiumとAWS Inferentiaインスタンスをどのように活用しているかですね。これらの特殊なアクセラレータをECSを通じて効果的に管理し、高性能な推論処理を実現しています。

Steve Kendrex：そうですね。特にInferentiaは推論ワークロード専用に設計されたASICで、コスト効率とパフォーマンスの両面で優れた成果を上げています。ECSを使用することで、これらの特殊なハードウェアアクセラレータを効率的に管理し、スケーリングすることができています。

Frank Fan：私のデモで示した非同期アーキテクチャの考え方は、このような大規模な実装でも活かされていますね。リクエストの信頼性を確保しながら、効率的なリソース利用を実現している点が印象的です。

Abhishek：また、ECSのサーバーレスコントロールプレーンの利点も、このような大規模な実装で特に重要になってきます。インフラストラクチャの管理負荷を軽減しながら、複雑なgen AIワークロードを運用できる点が、Rufusのような大規模実装の成功につながっていると言えます。

Steve Kendrex：この事例は、ECSが小規模な実装から世界最大級のgen AIワークロードまで、幅広いスケールで効果的に活用できることを示す良い例となっていますね。

9. まとめと推奨事項

9.1 主要な利点の整理

Frank Fan：本日のデモと議論を通じて、ECSでのgen AI実装における主要な利点が明確になりました。特に柔軟性の観点では、異なるモデルやランタイム、拡張モデルを組み合わせることで、様々なユースケースに対応できることを示しました。例えば、Stable Diffusionを基盤モデルとして、LoRAなどの拡張モデルを組み合わせることで、特定のスタイルの画像生成も可能です。

Abhishek：信頼性と可用性の面では、非同期アーキテクチャの採用が重要でしたね。SNSとSQSを活用したメッセージブローカーの実装により、システムの回復力を高め、スパイク的な負荷にも対応できる設計を実現しました。特に、メッセージの処理が完了するまで削除しない設計により、高い信頼性を確保できています。

Steve Kendrex：パフォーマンスとスケーラビリティについても、いくつかの重要な最適化を実現できました。Bottlerocket OSとEFSを活用することで、コンテナイメージのサイズを20GBから1GB未満に削減し、起動時間を6分から1分未満に短縮。また、モデルのロード時間も30秒から10秒に改善しています。

Frank Fan：コスト最適化の面では、スポットインスタンスの活用やGravitonインスタンスの使用、予測スケーリングの導入など、様々なアプローチを組み合わせることができます。特に、タスクあたりの保留ジョブ数に基づくスケーリングは、リソースの効率的な利用に貢献しています。

Abhishek：これらの利点は、WomboやKepler、さらにはAmazonのRufusのような実際の実装事例でも実証されています。小規模な実装から世界最大級のEコマースプラットフォームまで、ECSが幅広いスケールで効果的に活用できることが示されました。

9.2 関連セッションの紹介

Frank Fan：本日のデモと議論で紹介された内容をさらに深く理解するために、いくつかの重要な関連セッションをご紹介したいと思います。スライドに表示されているQRコードをスキャンしていただくと、本日の発表内容に関連する全てのスライド、手順、ブログ記事にアクセスできます。

Steve Kendrex：また、皆様に重要なお願いがあります。セッション後のサーベイにぜひご協力ください。皆様からのフィードバックは、より良いソリューションを開発し、より多くの方々に便益をもたらすために非常に重要です。

Abhishek：補完的な学習リソースとして、特にECSでのAI/ML実装に関連する技術セッションをいくつか選んでいます。これらのセッションでは、本日触れられなかった詳細な技術的側面や、異なる実装アプローチについても学ぶことができます。

Frank Fan：また、スライドに掲載されているブログ記事では、今回デモで示した最適化手法や実装パターンについて、より詳細な技術情報を提供しています。特に、Bottlerocket OSを使用したコンテナイメージの最適化や、EFSを活用したモデルファイルの効率的な管理について、詳細な手順を確認いただけます。

Steve Kendrex：こうした補完的なリソースを活用することで、皆様それぞれの具体的なユースケースに合わせた実装を進めていただけると考えています。

9.3 今後の展望

Steve Kendrex：今後のECSの開発には、特にAI/MLワークロードに関連する重要な機能拡張を予定しています。特に、GPU関連のメトリクスについては、現在のGPU予約状況の把握だけでなく、GPU使用率やGPU温度など、より詳細なメトリクスを標準機能として提供することを計画しています。

Abhishek：現在これらのメトリクスは、NVIDIA Data Center GPU Managerを使用して収集していますが、将来的にはECSの標準機能として提供されることで、より簡単に監視と最適化が行えるようになりますね。また、今週初めに発表された強化版のCloudWatch Container Insightsのように、より詳細なタスクとコンテナレベルのメトリクスの提供も続けていきます。

Frank Fan：デモで示したような最適化パターンも、今後さらに進化させていく予定です。例えば、Bottlerocket OSを使用したコンテナイメージの最適化や、EFSを活用したモデルファイルの管理など、より効率的な実装パターンを開発していきます。

Steve Kendrex：また、予測スケーリングのような新機能も、さらに進化させていく予定です。機械学習ベースのアルゴリズムを活用して、より正確な需要予測とプロアクティブなスケーリングを実現していきます。

Abhishek：これらの機能拡張により、ECSはgen AIワークロードの実行環境として、さらに強力なプラットフォームになっていくでしょう。小規模な実装から世界最大級のワークロードまで、より効率的にサポートできる環境を提供していきたいと考えています。