IT 技書の森

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

イベントの発行と購読を中心にシステムを構成し、サービス間の疎結合と非同期処理を実現するアーキテクチャスタイル

分散システム非同期

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

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

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

イベントの種類

イベントは大きく 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 
await eb.send(new PutEventsCommand({
  Entries: [{ Source: "myapp.orders", DetailType: "OrderCreated", Detail: JSON.stringify(order) }],
}));

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

関連用語