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

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

イベント駆動アーキテクチャ（EDA）とは、システム内で何か重要なことが起きた時（イベント）に、それを通知する仕組みで、複数のコンポーネントが協力して動くソフトウェア設計パターンです。 例えば、eコマースで顧客が注文を確定した瞬間に「OrderPlaced」というイベントが発生し、それが在庫システム、支払いシステム、配送システムに通知され、各システムが自動的に対応します。

ひとことで言うと： 駅のアナウンス「2番線に電車が到着します」を聞いて、乗客が一斉に移動するように、1つのイベント通知に対して複数のシステムが動く。

ポイントまとめ：

• 何をするものか： イベント（「注文確定」など）を通じてシステム同士が連携。
• なぜ必要か： 疎結合で、スケーラブルで、柔軟なシステムが構築できる。
• 誰が使うか： 大規模なシステム開発、マイクロサービス導入企業。

なぜ重要か

従来のシステムでは、注文システムが在庫を直接更新、支払いシステムに直接依頼、配送に直接指示、という直結な関係です。すると、在庫システムが故障すれば注文処理全体が停止します。また、新しいシステム（例：ポイント加算システム）を追加する度に注文システムのコードを修正する必要があります。

イベント駆動なら、各システムがイベントをリッスンして独立に動作するため、システムが壊れても他に影響しない、新しいシステムを追加しても既存コードを修正しない、という柔軟性が得られます。

仕組みをわかりやすく解説

イベント駆動は3つの主要コンポーネントで動作します。

イベントプロデューサー - 何か起きた時にイベントを発生させるコンポーネント。例えば、顧客が注文ボタンをクリックすると「OrderPlaced」イベントを発生。

イベントブローカー - イベントを受け取って、関心のあるシステムに配信する仲介役。Apache Kafkaなどが有名。

イベントコンシューマー - イベントをリッスンして対応するコンポーネント。「OrderPlaced」イベントを受け取った在庫システムは、在庫を予約する。

例：顧客注文 → 注文システムが「OrderPlaced」を発生 → ブローカーが配信 → 在庫・支払い・配送システムが各自処理。

実際の活用シーン

Eコマース注文処理 - 注文確定イベントが、在庫管理、支払い処理、配送手配、顧客通知を自動で起動。

IoTセンサー監視 - センサーの読み値が変化するイベント → アラート、ダッシュボード更新、ログ記録が自動実行。

銀行の不正検知 - 大きな取引イベント → 不正検知システムが分析、疑わしければアラート。

メリットと注意点

スケーラビリティ がメリット。個々のコンポーネントを独立にスケールでき、全体の構成を変更する必要がない。

柔軟性 - 新しいシステムの追加が容易。既存コードを修正せず、イベントリッスンを追加するだけ。

復旧力 - 1つのシステムが故障しても、他のシステムは動作継続。

一方、複雑性が増加 - デバッグ、テストが難しくなります。複数システムの協調動作を追跡するのが困難。

イベント順序 - ネットワーク遅延でイベントが順不同に到着する可能性があり、処理に工夫が必要。

関連用語

• マイクロサービス — イベント駆動とよく組み合わせて使用。
• メッセージキュー — イベント配信の実装基盤。
• 非同期処理 — イベント駆動の基本。
• 分散システム — 複数システムの協調が必要。
• ワークフロー自動化 — イベント駆動で実現される機能。

よくある質問

Q: すべてのシステムに向いていますか? A: いいえ。シンプルなシステムでは、従来設計の方が理解しやすい場合もあります。複雑で拡張性を重視する場合に適してます。

Q: リアルタイムで動作しますか? A: ほぼリアルタイムですが、ネットワーク遅延やブローカーの処理時間があります。ミリ秒単位の遅延は避けられません。

Q: イベントが失われることはありますか? A: ブローカー設定で「配信保証」を定め、失われないようできます。ただしパフォーマンスに影響します。