[レポート] Building event-driven architectures using Amazon ECS with AWS Fargate #CNS307 #AWSreInvent

セッションの概要

Event-driven architecture (EDA) enables organizations to build highly flexible and resilient systems, and customers are leveraging serverless containers to run EDA workloads due to its ease of use, scalability, and deep integrations with AWS serverless services. This session explores practical aspects of implementing EDA on Amazon ECS with AWS Fargate, focusing on patterns for consuming events in containerized environments using AWS Step Functions, Amazon SQS, and Amazon EventBridge. Learn how to build scalable, fault-tolerant, and event-driven solutions that can adapt to changing business requirements.

イベント駆動アーキテクチャ (EDA) により、組織は高度に柔軟で回復力のあるシステムを構築することができ、顧客は使いやすさ、スケーラビリティ、AWS サーバーレスサービスとの深い統合により、サーバーレスコンテナを活用して EDA ワークロードを実行しています。このセッションでは、AWS Step Functions、Amazon SQS、Amazon EventBridge を使用してコンテナ化された環境でイベントを消費するパターンに焦点を当て、AWS Fargate で Amazon ECS 上に EDA を実装する実践的な側面を探ります。変化するビジネス要件に適応できる、スケーラブルで耐障害性があり、イベント駆動のソリューションを構築する方法を学びます。

• Type: Breakout session
• Level: 300 – Advanced
• Features: Lecture-style
• Topic: Serverless & Containers
• Area of Interest: Event-Driven Architecture, Containers, Serverless
• Role: Developer / Engineer, DevOps Engineer, Solution / Systems Architect
• Services: Amazon Elastic Container Service (Amazon ECS), Amazon EventBridge, AWS Step Functions

セッションは軽快な進行で、終始楽しい雰囲気で進められました。

同期型マイクロサービスアーキテクチャの問題点

ECS を使用している同期型マイクロサービスを開発しているチームの事例からセッションは始まりました。
一見すると問題なさそうなシステムでしたが、高負荷によってシステムダウンすることに。

同期型モデルの利点は、低レイテンシ、シンプルさ、そして開発段階での迅速な失敗検知があります。
が、大きな欠点としてスロットリングが発生しやすく、レジリエンスの問題を抱えることになります。

イベント駆動型アーキテクチャ (EDA) の定義と利点

問題を解決する方法の 1 つとして、プロデューサとコンシューマの間にブローカーを配置し、非同期的にデカップリングする手法があります。
ブローカーはリクエストを受け付けた後、プロデューサにリクエストを受け取ったことだけを伝えて、その処理を切り離すのです。

ブローカーを介して非同期にメッセージをやり取りし、システムの結合度を下げること、これこそがイベント駆動型アーキテクチャ (EDA) です。

EDA の定義は、「何かが起こり、そして私たちが反応する (Something happens and we react)」と説明されました。なるほど。

セッション内で語られた EDA の主な利点は以下の 3 点です。

• スケーラビリティ (Scalability): 緊密な結合がないため、より大規模なアプリケーションを構築できる
• レジリエンス (Resilience): あるコンシューマがダウンしても、別のコンシューマは処理を続行でき、graceful degradation が可能になる
• アジリティ (Agility): プロデューサに変更を加えることなく、新しいコンシューマを追加できる

EDA を構築するためのビルディングブロック

EDA を構築するための主要なビルディングブロックとして、イベントルータ、イベントストア、ストリームの3つのカテゴリが紹介されました。

• イベントルータ
  • Amazon EventBridge
  • Amazon SNS Topics
• イベントストア
  • Amazon SQS
• ストリーム
  • Amazon Kinesis / MSK (Managed Streaming for Kafka)

AWS のマネージドサービスを活用することでサクッと EDA を構築することができます。

ECS と Fargate における実践的な EDA パターン

ECS サービスやコンテナを活用する具体的なパターンが紹介されました。ここからが本セッションの本題です。

Public API パターン

プロデューサが IAM ロールなどを使って EventBridge にイベントを直接送信するというパターンです。
EventBridge は API Destination を使用して、コンテナの API にセキュアにイベントをプッシュすることになります。

Private API パターン

EventBridge が PrivateLink や VPC Lattice を使用して、VPC 内のプライベートな入力エンドポイントにイベントを送信するパターンです。

Point to point パターン

ECS コンテナが SQS キューからイベントをプルするものです。
トラフィックのサイズや形状が一貫しない場合 (例：処理時間が異なる動画)、カスタムメトリクス計算 (Custom Metric Math) を使用したオートスケーリングの方法についても紹介されていました。

EventBridge

プロデューサーがイベントを EventBridge に送信し、EventBridge がタスク定義とともに Run Task API を呼び出し、Fargateタスクを起動する、というものです。
これは非同期で、成功の確認のみが返されます。

Step Functions

Step Functions を用いる場合、さらに 3 つのパターンに分類して紹介されました。

• Async パターン: run task を非同期で実行し、リクエストの確認応答を受け取ると Step Functions はすぐに次のステップに進む
• .Sync パターン: Step Functions がタスクを送信した後、describe ECS task APIをポーリングしてステータスを確認し、タスクの完了を待機
• Callback パターン: Step Functions がトークンを生成し、タスク実行時にコンテナに送信し、処理完了後にコールバックトークンを使用して Step Functions に戻りデータを返す

考えてみると私は .Sync パターンを使いがちでしたので、このセッションを聞いて Callback パターンも試してみたいと思いました。

Step Functions Activity パターン

Step Functions でアクティビティを作成すると、マネージド SQS キューが生成されます。
複数のワークフロー (Step Functions) がこのアクティビティキューにイベントを投入し、ECS ワーカーのプールがキューをポーリングし、タスク完了時にトークンとデータを使って Step Functions に結果を返す、という仕組みです。

何千、何万ものイベントがあり、それらを複数のワークフローから処理する必要がある場合にこのパターンを採用することで、マイクロトランジションの数を減らしてコスト削減に繋げることができるとのことでした。
確かに、StepFunctions で全てを賄うよりも、ECS などへ任せた方が良い場合もあるのかなと思いました。

おわりに

AWS からイベント駆動アーキテクチャの世界に足を踏み入れた私としては、とても満足感のあるセッションになりました。
ユースケースに応じた適切なパターン選択ができるよう、再度見直しておこうと思います。