イベント駆動アーキテクチャ

イベント駆動アーキテクチャとは

イベント駆動アーキテクチャ (Event-Driven Architecture, EDA) は、システム内で発生した重要な出来事 (イベント) を中心にサービス間の連携を設計するアーキテクチャスタイルである。イベントの発行者 (Publisher) と購読者 (Subscriber) が直接通信せず、イベントブローカーを介して非同期に連携する。

同期的な API 呼び出し (リクエスト/レスポンス) では、呼び出し元が呼び出し先の応答を待つ必要があり、呼び出し先の障害が呼び出し元に波及する。EDA ではイベントを発行するだけで処理が完了し、購読者が独立したタイミングで処理を行うため、サービス間の時間的結合が排除される。

イベントの種類

実務で扱うイベントは、次の 3 つを区別できると設計が楽になる。前の 2 つは役割の違い、3 つ目は発生源の違いである。

• ドメインイベント: ビジネス上の重要な出来事 (「注文が確定された」「支払いが完了した」)。ドメインの言葉で命名する
• 統合イベント: サービス間の連携に使うイベント。ドメインイベントを外部向けに変換したもの
• 変更データキャプチャ (CDC): データベースの変更をイベントとして発行する。Debezium が代表的なツール。流れてくるのは業務上の意図ではなく行の変化なので、購読側で意味を補う必要がある

AWS での実装パターン

AWS では複数のサービスが EDA の構築に使える。

• EventBridge: イベントルーティングのマネージドサービス。ルールベースで購読者にイベントを振り分ける
• SNS + SQS: ファンアウトパターン。SNS トピックに発行し、複数の SQS キューが購読する
• Kinesis Data Streams: 大量のイベントをリアルタイムに処理するストリーミングサービス
• DynamoDB Streams: DynamoDB テーブルの変更をイベントとして発行する CDC

結果整合性の受け入れ

EDA を採用すると、サービス間のデータは結果整合性 (Eventual Consistency) になる。注文サービスが「注文確定」イベントを発行し、在庫サービスがそれを受信して在庫を減らすまでにタイムラグがある。この間、在庫データは最新の状態を反映していない。

結果整合性を受け入れられるかどうかが、EDA の採用判断の最大のポイントだ。軸になるのは業種ではなく、その場で守らなければならない不変条件があるかどうかである。残高不足の口座から引き落とさないことを引き落としの瞬間に保証したいなら、同期的な処理が要る。逆に入出金の通知や記帳のように後追いで整えられる処理は、金融でも非同期のイベント連携で組むのが普通だ。

よくある落とし穴

• イベントの順序保証: 複数のイベントが発行された順序と異なる順序で処理される可能性がある。順序が重要な場合は Kinesis のパーティションキーや SQS FIFO キューを使う
• イベントの重複: ネットワーク障害やリトライにより、同じイベントが複数回配信される。購読者は冪等 (Idempotent) に設計する必要がある
• イベントスキーマの進化: イベントのフォーマットを変更する際、既存の購読者との互換性を維持する必要がある

「マイクロサービスパターン」(Chris Richardson 著) でイベント駆動の設計パターンが体系的に解説されている。「Building Event-Driven Microservices」(Adam Bellemare 著) はイベント駆動に特化した専門書だ。

イベント駆動 vs リクエスト駆動

イベント駆動とリクエスト駆動の違いを以下にまとめる。

観点	イベント駆動	リクエスト駆動
結合度	低い (疎結合)	高い (直接呼び出し)
同期/非同期	非同期	同期
スケーラビリティ	高い	中
AWS	EventBridge, SNS, SQS	API Gateway → Lambda

発行側のコードは短い。購読者が 1 つでも 10 でも、発行側の書き方は変わらない。

await eb.send(new PutEventsCommand({
  Entries: [{ Source: "myapp.orders", DetailType: "OrderCreated", Detail: JSON.stringify(order) }],
}));

より深く学ぶには関連書籍が役立つ。