メインコンテンツまでスキップ

🧩 Event-driven Architecture（イベント駆動アーキテクチャ）

✅ このスタイルの概要​

イベント（事象）の発生をトリガーとしてサービス間をゆるく結合する統合スタイル。
「何かが起きた」という事実をイベントとして発行し、それを購読するサービスが反応する。

✅ 解決しようとした問題​

同期リクエスト型の連携（REST/gRPC など）だけでは、次のような課題があります：

  • 一つの処理に関わるサービスが多いと、連鎖的な同期呼び出しが発生しやすい
  • 呼び出し元が、呼び出し先すべてを知っている必要がある（強い結合）
  • 一部サービスの遅延・障害が、呼び出し元のレスポンスに直結する

Event-driven Architecture（EDA）はこれに対して：

「状態の変化（イベント）を発行し、
誰がそれを処理するかは疎結合にする」

ことで、柔軟性と耐障害性を高めようとする。

✅ 基本思想・ルール​

● Event（イベント）​

  • 「注文が作成された」「在庫が引き当てられた」など、過去に起きた事実
  • 不変であり、原則として“取り消さない”

● Event Producer / Consumer​

  • Producer：イベントを発行するサービス
  • Consumer：イベントを購読して反応するサービス
  • 両者はメッセージブローカー（Kafka, RabbitMQ など）を介して疎結合につながる

● Pub/Sub モデル​

  • 発行側は「誰が購読しているか」を知らない
  • 購読側は「誰が発行したか」を気にせず、自分の関心のあるイベントだけを見る

概念図（Conceptual Diagram）​

Event-Driven Architecture diagram

出典: Microsoft, “Asynchronous messaging patterns – Azure Architecture Center”.
https://learn.microsoft.com/en-us/azure/architecture/patterns/async-request-reply

✅ 得意なアプリケーション​

  • マイクロサービス間の連携が多いドメイン
  • 「何かが起きたこと」に反応して追加処理を行うシステム（通知、集計、非同期バッチ）
  • 高スループットなイベント処理基盤（ログ／トラッキング／IoT）

特徴：

  • 新しいサービスを「既存イベントの購読者として追加」しやすい
  • 非同期処理へ自然に移行できる

❌ 不向きなケース​

  • 強い一貫性が必要で、「結果がすぐ分からないと困る」操作
  • 処理フローがシンプルで、同期呼び出しだけで十分なシステム
  • イベント設計・スキーマ管理のコストをかけられないチーム

また、EDA の乱用は：

  • イベントの氾濫
  • 依存関係の見えづらさ（どこで何がトリガーされるか分かりにくい）

といった問題を生む。

✅ 歴史（系譜・親スタイル）​

  • GUI のイベント駆動モデル（クリックに反応するなど）からの発展
  • メッセージングシステム（MQ）や Pub/Sub の普及
  • Kafka などのログ＋ストリームプラットフォームにより本格的に広まった

✅ 関連スタイル​

✅ 代表的なフレームワーク​

Event-driven Architecture は、メッセージング基盤やイベントプラットフォームの上で実現される。

  • Apache Kafka
    高スループットな分散ログ／ストリームプラットフォーム。EDA の代表的実装。

  • RabbitMQ
    メッセージブローカーとして、キューイング型・Pub/Sub 型の両方で利用される。

  • Amazon SNS / SQS / EventBridge
    AWS 上でのイベント駆動統合の主要コンポーネント。

  • Google Cloud Pub/Sub
    GCP におけるグローバルな Pub/Sub サービス。

  • NATS / Pulsar など
    軽量・高性能なメッセージング基盤として採用例が増えている。

✅ このスタイルを支えるデザインパターン​

Event-driven の内部構造は、オブジェクト指向パターンで見ると次のように分解できる。

  • Observer
    イベントの発行（Subject）と購読（Observer）のモデルそのもの。

  • Mediator
    メッセージブローカーが、Producer と Consumer の仲介役として機能する。

  • Command
    イベントを「操作オブジェクト」として扱い、その意味を Consumer 側で解釈する。

  • Chain of Responsibility
    複数のハンドラ／コンシューマが順に処理を引き継ぐ構造に現れる。

  • Iterator
    イベントストリームを順次処理する際の抽象として利用される。

✅ まとめ​

Event-driven Architecture は、

  • 疎結合
  • 非同期処理
  • 拡張性

を重視する統合スタイルである。

すべてをイベント駆動にするのではなく、
同期呼び出しと組み合わせながら「どこをイベント化すると価値が高いか」を見極める ことが重要である。