AWS SAA-C03 で Amazon EventBridge はどう問われるか

AWS Batch は、実行時間の長いバッチ処理をマネージドにスケジューリングして実行するサービスで、ジョブの状態が変わるたびに Job State Change イベントを Amazon EventBridge の既定イベントバスへ送信します。このイベントの detail.status が SUCCEEDED であるものだけをイベントパターンで抽出すれば、「正常終了したときだけ後続処理を動かす」というトリガーを追加のポーリングなしに実現できます。さらに EventBridge の API 送信先は、AWS 外部の HTTP エンドポイントをルールのターゲットにできる機能で、基本認証・API キー・OAuth の認証情報を接続 (connection) として登録すると、その資格情報は AWS Secrets Manager に保管され EventBridge が自動的に付与します。 本シナリオの要件は、長時間実行されるバッチの正常終了を検知して社外 API を呼び出すこと、そして認証情報をコードに埋め込まないことです。したがって A と B の組み合わせが最適です。 C と E が挙げる EventBridge スケジュールは、cron 式やレート式で「決まった時刻」に処理を起動する時間ベースの仕組みであり、イベントパターンでジョブの SUCCEEDED を検知することはできません。ジョブが失敗しても時刻が来れば後続処理が動いてしまうため要件を満たしません。さらに E は解析ワークロード自体を Lambda で実装しますが、Lambda の最大実行時間は 15 分であり、数時間かかる解析には適しません。D は Lambda 内から直接 HTTP リクエストを送る案ですが、認証情報をコードにハードコードすることになり、ローテーションもできず、セキュリティ要件に明確に違反します。

イベント駆動型アーキテクチャは、イベントの発生元 (プロデューサー) と処理側 (コンシューマー) の間にイベントルーターを挟むことで、片方の障害や仕様変更がもう片方へ波及しない疎結合な構成を実現するための設計パターンです。Amazon EventBridge はサーバーレスのイベントバスであり、イベント本文 (JSON) に対するイベントパターンでルールを定義し、Lambda 関数、SQS キュー、Step Functions ステートマシンなど多数のターゲットへ同一イベントを同時配信できます。さらに外部 SaaS をパートナーイベントソースとして直接接続でき、スキーマレジストリやアーカイブ/リプレイも利用できます。本シナリオでは、申請アプリは EventBridge へイベントを 1 回発行するだけでよく、購読側を増やす場合もルールを追加するだけで済むため、C が要件をすべて満たします。A は同期呼び出しによる密結合そのもので、下流の 1 つが停止すると申請処理全体が失敗し、購読先追加のたびに改修が必要になります。B は SQS 標準キューを共有する構成ですが、1 つのメッセージを受信して削除できるコンシューマーは原則 1 つだけであり、複数サブシステムへのファンアウトになりません。D の Kinesis Data Streams は大量ストリームの順序付き処理には適するものの、シャード管理やコンシューマー実装の負荷が高く、ペイロード内容に基づくルーティングや SaaS パートナーイベントの直接取り込みには対応できないため、本要件には不適合です。

複数ステップから成るバッチ処理をクラウドへ移行する際は、個々の処理を実行する仕組みと、処理の順序・条件分岐・エラー処理を制御するオーケストレーションの仕組みを分けて設計します。AWS Step Functions は、処理フローをステートマシンとして宣言的に定義できるサーバーレスのワークフローサービスで、各状態から AWS Lambda 関数を呼び出せるほか、Retry と Catch による例外処理、Choice による条件分岐、Parallel や Map による並列実行を設定として記述できます。実行履歴はコンソールでビジュアルに追跡できるため、どのステップで失敗したかの特定も容易です。起動は Amazon EventBridge のスケジュールやイベントから行えるので、イベント駆動かつサーバーレスという要件を満たしつつ運用負荷を最小化できます。よって B が適切です。A のように EventBridge のルールだけで関数を連鎖させると、状態の受け渡し、リトライ、失敗時の巻き戻しをすべてアプリケーションコードに実装することになり、処理全体の可視化も失われて保守が困難になります。C の AWS Glue ワークフローは、Glue のジョブ・クローラー・トリガーをつなぐための機能であり、任意の Lambda 関数を汎用的にオーケストレーションする用途には使えません。D は AWS Batch を Amazon EC2 上の ECS クラスターで動かす構成で、EC2 のキャパシティ管理と AMI の保守が残るためサーバーレスという前提に反し、ステップ間の条件分岐や補償処理も自前で実装する必要があります。