アーキテクチャパターン

イベント駆動アーキテクチャいべんとくどうあーきてくちゃ

イベント駆動非同期処理メッセージキューマイクロサービス疎結合Kafka

イベント駆動アーキテクチャについて教えて

簡単に言うとこんな感じ！

「何か起きたら知らせて、受け取った側が自分のペースで動く」仕組みのこと！注文が確定したらメールも在庫更新も同時並行で動く、あの感じだよ。

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

イベント駆動アーキテクチャ（Event-Driven Architecture / EDA）とは、システム内のコンポーネントがイベント（出来事の通知）を介して連携する設計パターンです。あるコンポーネントがイベントを発行（Publish）すると、それを購読（Subscribe）している別のコンポーネントが反応して処理を行います。呼び出し元は相手の応答を待たず、非同期に処理が流れていくのが最大の特徴です。

従来の「呼び出し元が直接受け取り側のAPIを呼ぶ」同期型アーキテクチャと比べ、EDAでは送り手と受け手が互いを知る必要がありません。この疎結合な設計により、サービスを独立してスケールさせたり、新しいサービスを既存の流れに途中から参加させたりすることが容易になります。Eコマースや金融など「大量の出来事をリアルタイムに処理する」場面で特に力を発揮します。

主な構成要素

構成要素	役割	代表的な実装
イベントプロデューサー	イベントを発行するコンポーネント	Webアプリ、IoTデバイス
イベントブローカー	イベントを受け取り、適切なコンシューマーへ配信	Apache Kafka、Amazon SNS/SQS、RabbitMQ
イベントコンシューマー	イベントを受け取り処理するコンポーネント	マイクロサービス、Lambda関数
イベントストア	発生したイベントを永続的に保存	Kafka、EventStoreDB

イベントの種類

通知イベント：「こういうことが起きた」という事実のみを伝える（例：OrderPlaced）
イベント転送オブジェクト：関連するデータも一緒に運ぶ（例：注文IDと明細をセットで送信）
ドメインイベント：ビジネス上の重要な出来事（DDD用語）

歴史と背景

EDAの概念は1990年代のメッセージキューイングシステム（IBM MQなど）に源流があります。2000年代にはSOA（サービス指向アーキテクチャ）とともにエンタープライズ統合の手法として整理されました。2010年代にNetflixやLinkedInがApache Kafkaを開発・オープンソース化したことで、大規模なリアルタイムイベントストリーミングが現実的になり、マイクロサービスとの組み合わせで爆発的に普及しました。現在はAWS EventBridge、Google Pub/Sub、Azure Event Hubsなどクラウドマネージドサービスが揃い、導入ハードルが大きく下がっています。

同期型アーキテクチャとの比較

観点	同期型（REST）	イベント駆動型
結合度	強い（相手のURLを知る必要がある）	弱い（ブローカー経由）
スケーラビリティ	受け手の処理能力に依存	コンシューマーを独立してスケール可能
障害への強さ	一方が落ちると連鎖する	ブローカーがバッファになる
トレーサビリティ	追いやすい	イベントIDでの追跡が必要

仕様	内容
CloudEvents (CNCF)	イベントデータの標準フォーマット仕様
AsyncAPI	非同期APIの記述仕様（OpenAPIのEDA版）