re:Invent 2024: AWSストレージサービスを活用したAmazon EKSでのステートフルワークロード
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Empowering stateful workloads on Amazon EKS with AWS storage services (KUB324)
この動画では、リアルタイムのインファレンスアプリケーションの設計と実装について解説しています。Stable DiffusionやFlux.1 Devなどのモデルを使用した画像生成システムを例に、フロントエンドからバックエンドまでの信頼性確保、処理待ち時間の最適化、需要に応じたスケーリングという3つの課題への対処方法を説明します。Amazon API Gateway、AWS Lambda、SNS、SQSを組み合わせた非同期処理の仕組みや、KEDAとKarpenterを活用したAmazon EKS環境でのスケーリング方法が詳しく解説され、実際のライブデモを通じてシステムの動作が示されています。このソリューションはAWS Solutions Libraryで公開されており、30分程度で環境をデプロイできます。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
リアルタイムインファレンスアプリケーションの設計と課題
はい、みなさん、お集まりいただきありがとうございます。今日は皆様にとてもワクワクするような機会についてお話しします。デジタルランドスケープの変革を目指す先進的なデジタル企業から依頼された Social Architect として想像してみてください。皆様のタスクは、リアルタイムのインファレンスアプリケーションを設計することです。
簡単ですよね？エンドユーザーからのリクエストを受け取り、インファレンスエンドポイントと通信し、モデルファイルをロードして出力を生成するフロントエンドが必要です。ただし、各ユーザーが異なるプロンプトで異なる画像を生成するため、これはステートフルなアプリケーションとなります。 そこで、私たちは3つの主要な課題に取り組む必要があります：フロントエンドからバックエンドまで、ソリューション全体の信頼性をどのように確保するか、エンドユーザーが画像を長時間待たないようにする方法、そして需要に応じてアプリケーションをスケールインとスケールアウトする方法です。
この旅に私と一緒に出発する準備はできましたか？素晴らしい。ここで質問があります - 私には2つの選択肢があります：100%確実に動作する事前録画のデモと、みなさんと一緒にリスクを取るライブデモです。ライブデモを見たい方は手を挙げてください。なるほど、みなさん勇気がありますね。では、ライブデモをやってみましょう。参考として、すでに構築したソリューションをお見せします。
これは Stable Diffusion です - このFoundation Modelを使用しています。とてもシンプルなプロンプトを使ってみましょう：走っている馬です。画像生成を待っている間に説明させていただきます。 このリフレッシュプライシングにより、異なるサイズや異なるファミリーなど、様々なタイプのインスタンスを使用する機会が得られます。これは非常に信頼性が高いため、価格を確認できます。ステートフルなアプリケーションでも、Spotインスタンスを使用してコストを削減できます。
はい、画像が生成されました。g6eインスタンスタイプを使用し、2つのモデルを使っています。 ここで違いがわかります：こちらが Stable Diffusion で、もう一つは人気のある別のFoundation Modelである Flux.1 Dev です。この構築したソリューションでは、先ほど述べた課題にどのように対処したかがわかります - モデルを柔軟に切り替えることができ、環境全体で異なるインスタンスタイプを活用でき、Spotインスタンスが時々利用できない場合でも、Spotインスタンスを使用して信頼性を確保できます。
非同期モデルを活用した信頼性の高いアーキテクチャの実装とデモンストレーション
信頼性と、環境全体をどのようにアーキテクトするかについてお話ししましょう。これはステートフルなアプリケーションなので、バックエンドやフロントエンドに障害が発生した場合でもエンドユーザーへの影響を防ぐ必要があります。そこで私たちは非同期モデルを採用しました。具体的には次のような仕組みです：フロントエンドでは、左側のエンドユーザーからのリクエストが Amazon API Gateway に送信されます。その後、AWS Lambda がメッセージを変換、検証し、Amazon Simple Notification Service に送信します。そこから、メッセージは Simple Queue Service に配信されます。
ここまでの工程は、エンドユーザーからメッセージを受け取り、それをキューに格納するだけです。これで前半の処理は完了です。 後半の処理では、すでにキューに入っているメッセージを使用します。アイコンを順番に見ていくと、キューエージェントが SQS からメッセージを取得し、SD ランタイムと通信を開始します。SD ランタイムは、ここではインファレンスエンドポイントとして機能する Stable Diffusion Web UI というオープンソースプロジェクトです。
インファレンスエンドポイントを使用して、モデルファイルと通信し、推論作業を処理します。画像が生成されると、ステップ2の Amazon S3 バケットに保存されます。しかし、これでプロセスは完了ではありません。ステップ3の Amazon SNS にコールバックを送信してユーザーに通知する必要があります。これにより、ジョブが完了し、Stable Diffusion の処理が終了したことを示します。すべてが正常に動作すれば、ステップ4でセットアップされたキューからそのメッセージを取得します。これら2つのフェーズを分離することで、例えばインファレンスエンドポイントが失敗するようなバックエンド障害が発生した場合でも、Amazon SQS キュー内のメッセージは保持され、新しいタスクが再試行されます。
ご覧の通り、これはセーフアプリケーションですが、フロントエンドとマネージドサービスを活用してバックエンドをステートレスに保っています。Amazon EKS 上でステートレスなコンテナを実行し続けています。 パフォーマンスの側面を見てみましょう。3つのステップでこれらのモデルを素早くロードしたいと考えています。 Amazon EKS 環境に追加することで環境を迅速にスケールアウトし、イメージを素早くロードし、モデルを素早くロードしたいと思います。 これらがモデルを素早くロードするために実行する手順です。
スケーラビリティの観点から、 大量のトラフィックが発生した場合、現在は1つのノードで1つのPodを実行しているだけでは不十分です。環境をスケールする必要があるため、Podをスケールアウトするためのオープンソースメカニズムである KEDA を活用しています。多数のタスクが発生し、Podがペンディング状態になった場合、 バックエンドリソースが必要になります。これらのタスクやジョブを実行するために、Karpenter を使用してノードを素早くスケールアップします。 Podが起動して実行されると、このようにして迅速なスケーリングを実現します。
それでは私の環境でデモをお見せしましょう。これは既にリソースがデプロイされている Amazon EKS 環境です。 ここには推論ランタイムが Pod と Service として実行されています。KEDA は スケーリングを担当し、Karpenter がバックエンドの Amazon EC2 インスタンスのスケールアウトを制御しています。 モデルファイルを素早くロードするために、これらの設定を見てみましょう。これらのリソースは既にありますが、新しい画像生成タスクを開始できるかどうかを素早くテストする必要があります。 ここでモデルファイルをお見せしましょう。既に Amazon S3 CSI ドライバーを有効にしています。 ご覧のように Amazon S3 が有効になっており、S3 バケットを永続ボリュームとして使用できます。永続ボリュームはここにあり、 このバケットに全てのモデルファイルをロードしています。
ジョブの開始に移りましょう。 まずは1つのテストから始めます。先ほど生成した画像を覚えていますか？私は少し変更を加えました。 違いがわかると思います。なぜなら今は 画像生成に別のモデルを使用する柔軟性があるからです。基盤となるモデルは Stable Diffusion です。Lora は一緒に動作する別の拡張モデルです。全く同じプロンプト「a horse running」を使用しますが、どのような違いが出るか見てみましょう。このプロンプトは Amazon API Gateway に送信されます。 生成された画像が保存されている Amazon S3 バケットを確認してみましょう。もう画像ができていて、 違いがはっきりとわかります。2つの画像は全く異なっています - 以前は Lora モデルを使用したため、中国画のスタイルでした。
Lora のような異なるモデルがどのように様々な結果を生み出せるかを見てきましたが、ここからは多くのノードとリクエストを持つ大規模環境での画像生成の扱い方について説明しましょう。忙しい時には環境が素早くスケールアウトし、静かな時期にはコスト削減のためにスケールインできるようにする必要があります。これをロードテストを通じて、どれだけ素早くスケールできるかをお見せします。
ロードテストのプロセスを開始しましょう。始める前に、現在の設定をお見せしたいと思います。現在、環境には1つのノードしかありません。 現時点で実行されているのは1つの Pod だけです。5人のユーザーを設定してプロセスを開始し、スケーリングテストを始めましょう。
リクエストが増え始めているのがわかります。さらに17個のリクエストが来ています。 コンソールに戻ると、何が起きているかを観察できます。多くの Pod がバックエンドリソースを待って Pending 状態になっています。 メトリクスが拡大し、これらの Pending 状態の Pod に対応するために新しいノードが立ち上がっているのが確認できます。
新しいノードが起動すると、バックエンドのPodが増加していく様子が確認できます。 新しいノードがオンラインになると、CPU使用率がより均等に分散されていることがわかります。 バックエンドで何が起きているのか、ダッシュボードを使って説明させていただきます。 直近3分間の状況を簡単にお見せしましょう。 リフレッシュして変化を確認してみましょう。負荷テストを実行したため、これらの数値が上昇しているのがわかります。数値が閾値に達すると、バックエンドがPodのスケーリングをトリガーし、多くのPendingポッドがあるため、それらのタスクを処理するための新しいノードが起動されます。
環境に戻って見てみましょう。 現在、多くのノードが稼働しており、数多くのバックエンドノードが動作しています。スケーリングは非常に素早く行われ、バックエンドをトリガーするメッセージ数が増加しているのがご覧いただけます。 テストを停止すると、コスト削減のためにこの環境全体が自動的にスケールバックするのをすぐにご確認いただけます。
これが環境全体のセットアップ方法です。特に強調したいのは、エンドツーエンドの可視性です。先ほど実施したテストの中から、一つの例を詳しく見てみましょう。これは環境全体のエンドツーエンドのワークフローを示しています。 まず、エンドユーザーがAPI Gatewayにリクエストを送信し、それがLambdaに渡されてメッセージの検証が行われます。
そこからLambdaがメッセージをSNSに渡し、キューに配置します。その後、エージェントがキューから画像を取得し、推論を完了させます。これが環境全体のエンドツーエンドの仕組みです。
スライドに戻りましょう。 この環境全体はすでにAWS Solutions Libraryで公開されています。30分程度で環境全体をデプロイして、実験を開始することができます。また、このソリューションで私たちが行ったアーキテクチャの決定に関する詳細も含まれています。より詳しく知りたい方は、関連セッションをご覧ください。 録画をご覧いただくか、これらのセッションに注目していただければと思います。また、明日は同様のソリューションについて、Amazon ECSに関する詳細をご説明させていただく予定です。
このソリューション全体についてさらに学びたい方や、ソリューションの構築手順を詳しく知りたい方のために、ブログ記事を用意しています。こちらがURLですので、写真を撮っていただければと思います。また、より詳しい情報を探せるリンクも多数掲載しています。
本日はご参加いただき、ありがとうございました。アンケートにご協力いただければ幸いです。皆様からのフィードバックは、今後のセッションの改善に活かさせていただきます。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion