← AWSサービスの内部原理 コース
54. EventBridgeはイベントルーター — ルールのパターンマッチが配線を置き換える
イベントが発行者から宛先へ届くまでを、「チャネルを選んで送る」のではなく「1本のバスに流してルールが仕分ける」流れとして図で追っていきます。
① バスは「受けて、ゼロ個以上へ届ける」ルーター
AWSサービスaws.ec2 など
自作アプリ
SaaSパートナー
ゼロ個以上へ配送
イベントバスルーター
受けて配るだけの一点ターゲット群0個 = 無配送も正常
- 公式定義そのまま —「An event bus is a router that receives events and delivers them to zero or more destinations, or targets」(eb-event-bus)。
- バスは3種類: default(AWSサービスのイベントが自動で届く)/ custom(自作アプリ)/ partner(SaaS)。図の原理はどれも同じ。
- 発行者は宛先を持たない。これがLambda編・S3編で見た「発行者と消費者の疎結合」の、EventBridgeにおける形。
バスはイベントを受け取るだけの一点で、そこに何個の宛先がぶら下がるか(0個かもしれない)は発行者の関心事ではない。宛先を決めるのは次に出てくるルール。
② バスに紐づく各ルールが全イベントを評価する
イベント1件バスに到着
パターンに合うか?
ルールAstate=running
ルールBsource=aws.s3
ルールCOrder Placed
○ マッチ
× 不一致何もしない
○ マッチ
- 「You associate a rule with a specific event bus, so the rule only applies to events received by that event bus.」— ルールはバスに属す(eb-event-bus)。
- イベントパターンはJSONの構造・値への宣言的条件。例: {"source":["aws.ec2"], "detail-type":["EC2 Instance State-change Notification"], "detail":{"state":["running"]}}(eb-event-bus)。
- 照合規則: パターンに書いた全フィールドをイベントが同じ入れ子構造で含むこと(フィールド間はAND)、各フィールドの値は配列のいずれかに一致すればよい(配列内はOR)、パターンに書かなかったフィールドは無視される(eb-create-pattern)。
- これは既習のパターンマッチング(宣言的な条件評価)そのもの。手続きで「もしこうなら送る」と書くのではなく、「こういう形のイベントを受けたい」と形を宣言し、判定はEventBridgeがやる。
ルールは「配線」ではなく「宣言的な受信条件」。到着した1件を全ルールが各自のパターンで独立に評価し、内容だけで宛先が決まる — 完全な内容ベースルーティング。
③ マッチは複数OK・各ルールは最大5ターゲットへ並列送信
イベント1件
各最大5ターゲットへ並列送信
ルールA ○
ルールC ○
ルール単位でtransform可Lambda
SQS
SNS
Step Functions
- 「An event might match multiple rules, and each rule can specify up to five targets. (An event may not match any rules, in which case EventBridge takes no action.)」(eb-event-bus)
- 「A single rule can send an event to multiple targets, which then run in parallel.」(eb-rules)
- ルール単位でイベント変換(transform)を挟める。「optional transformation of events prior to delivery to a target」(eb-event-bus)。
- 「どのルールにもマッチしなければ何も起きない」— これはエラーではなく設計上の正常。発行者は宛先の有無を関知しない。
1イベント → 複数ルール → 各最大5ターゲットの並列。マッチ0件なら無反応。宛先の数と有無は、発行時点ではなくルール群の状態によって決まる。
④ SNSとの主客転倒 — 「チャネルを選ぶ」vs「1本に流して仕分ける」
SNS: 発行者トピックを選ぶ
EB: 発行者バス1本に流す
届く先
トピックX/Y/Zチャネルが主役
バス+全ルールパターンが主役
購読者フィルタは付加機能
ターゲットルールが仕分けの本体
- SNSでは発行者がどのトピック(チャネル)に出すかを選ぶ。フィルタポリシーは各購読に後付けで乗せる絞り込み — SNSレッスンで見た通り、主役はトピック選択で、フィルタは付加機能。
- EventBridgeでは発行者はバス1本に流すだけ。どこへ行くかは全部ルール側が内容で決める。フィルタに当たるパターンマッチが仕分けの本体そのもの。
- 同じ「宣言的フィルタ」という発想の主客転倒。SNS=購読側のオプション、EventBridge=ルーティングの中心。だからEventBridgeは「多対多の内容ベースルーティング」、SNSは「チャネルへのファンアウト」と役割が分かれる。
両者ともパターン照合を使うが、SNSはチャネル選択が主でフィルタが従、EventBridgeはルール(パターン)が主。発行者から見た「宛先の決め方」が正反対。
⑤ Pipes(1対1)とScheduler(時刻がイベント源)
DynamoDB Streams追記ログが源
読み方はイベントソースマッピングと同型cron/rate式時計が源
単発実行も可それぞれのターゲットへ
Pipe点対点 1源→1的
Scheduler時刻が来たら発火
ターゲット例: バスに流して多対多へ
- Pipesはpoint-to-point —「each pipe receives events from a single source for processing and delivery to a single target」(eb-what-is)。バスの多対多とは別物の1対1。途中で任意にenrich/変換を挟める。
- よくある組み合わせ:「a pipe with a DynamoDB stream for a source, and an event bus as the target」— PipeがStreamsを読み、バスに流し、バスが多数のターゲットへ配る(eb-what-is)。源はDynamoDB編で見た追記ログ(Streams)、その読み取りはLambda編のイベントソースマッピング(ポーリング)と同じ「順序ログを追う」発想。
- Schedulerはcron/rate式(単発実行も可)で「時刻そのものをイベント源にする」サーバーレススケジューラ(eb-what-is)。イベントの源が「外から来る出来事」から「時計が指す瞬間」に変わるだけで、下流(ターゲットへ届ける)は同じ。
Pipesは1対1(源はStreams、読みはイベントソースマッピングと同型)、Schedulerは時刻をイベント源にする。どちらもバスの「多対多ルーティング」とは別レイヤーで、既習部品の組み替えとして理解できる。