EventBridgeを理解する

EventBridgeは出来事を受け取り、内容に合う処理へつなぎます。イベントバスとルールを中心に、Pipes、Scheduler、再試行の役割を区別し、イベント駆動の設計を具体例で理解します。

この単元で学ぶこと

イベントバス・パターン・ターゲットを説明する
Pipes・Scheduler・アーカイブの目的を区別する
失敗・再送・権限・ループへの対策を説明する

本文解説

1. イベントを受け取るイベントは注文が確定した、インスタンスの状態が変わった等の出来事を表します。EventBridgeはAWSサービス、独自アプリ、対応する外部サービス等からのイベントを連携に利用します。アプリは発生した事実を発行し、その後の処理は受取側が担当できます。事実の通知と、業務結果が成功したことを同一視しないようにします。

2. バスとルールと対象イベントバスはイベントを受け取る経路で、ルールはどの内容をどのターゲットへ送るかを定義します。例えば注文状態がcancelledなら返金用の処理へ送ります。一つのルールから複数ターゲットへ送ることもできるため、バスは一つのワーカーだけに仕事を渡す待ち行列とは同じではありません。対象サービスの対応と権限も確認します。

3. パターンの照合イベントパターンには照合したいフィールドを指定します。sourceがshop.orders、detail内statusがpaidという二つの条件なら、両方に合うイベントを選びます。指定していないフィールドまで完全一致する必要はありません。フィールド名や入れ子の位置も意味を持つため、実際のサンプルイベントを使い、一致する例と一致しない例でテストします。

4. Pipesで一対一をつなぐ EventBridge Pipesは対応する一つのソースから一つのターゲットへの連携を簡素化します。必要に応じてフィルタリングや情報追加を挟めます。例えばSQSの受注依頼を読み、関連情報を追加してワークフローへ渡す構成です。多対多のルーティングを行うイベントバスとの違いは、何を何へつなぐ単位かにあります。

5. 時刻で始めるScheduler EventBridge Schedulerは一度だけの予定や、cron・rateによる繰返しの呼出しを管理します。毎朝集計を開始する例は、注文イベントの到着に反応する処理と異なります。タイムゾーンや必要な時刻条件、再試行、柔軟な時間枠を要件に合わせて設定します。予定時刻になったことと、呼出し先の業務がその瞬間に完了することは別です。

6. 失敗に備えるターゲットが利用不能等で配信できない場合、再試行ポリシーに従って再送します。再試行には回数や期間の条件があり、設定したDLQへ失敗イベントを残して調査する設計もできます。再試行を前提に、同じ注文IDへの処理が二重の返金等を起こさないようにします。パターンの一致、配信の成否、業務の結果を段階別に監視します。

7. アーカイブと再生イベントバスで受けたイベントのアーカイブを設定し、後から元のバスへ再生する機能があります。修正後の再処理や機能検証に利用しますが、過去イベントを送れば外部の業務状態も自動で正しく復元されるとは限りません。既実行の効果、必要な順序、対象ルール、保存する情報と保持条件を確認します。

8. 自分を起動し続けないあるイベントで資源を更新し、その更新イベントがまた同じルールに一致すると、意図しない処理の循環を作ることがあります。状態や発生元を絞り、処理済みを識別し、必要な権限だけを与えます。料金や負荷の増加も監視します。Serverlessの連携でも、どの出来事に何を実行するかという業務の条件は利用者が設計します。

図解

到着と時刻を区別する — Pipesの一対一連携やアーカイブも目的に応じて使い分けます。

重要ポイント

パターンに指定した条件でイベントを選ぶ。
バスの多対多、Pipesの一対一、Schedulerの時刻起動を区別する。
再生と再試行でも冪等性や業務状態を確認する。

間違えやすい点

ルール一致を業務成功とみなす。
アーカイブの再生で元の処理順や外部状態まで自動復元すると考える。

用語解説

イベントバス: イベントを受け取り、ルールに従い処理先へつなぐ経路。
イベントパターン: イベントの構造や値に対する照合条件。
ターゲット: 一致したイベント等の送信先となる処理やサービス。
再生: アーカイブしたイベントを元のイベントバスへ再送する機能。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。