アーキテクチャ レッスン4
イベント駆動アーキテクチャ
イベントの発行と購読でサービス間を疎結合につなぐイベント駆動アーキテクチャの仕組みを学ぶ
イベント駆動アーキテクチャとは
イベント駆動アーキテクチャは、 「注文が作成された」「支払いが完了した」のような出来事(イベント)を 発行し、それに関心のあるサービスがそれぞれ独立して反応する構成です。
サービスAがサービスBのAPIを直接呼び出す同期的な連携と違い、AはイベントをPublish(発行)するだけで、 誰がそれをSubscribe(購読)して何をするかを知る必要がありません。これによりサービス間の疎結合が実現します。
Pub/Subの仕組み
Order Service --publish--> [ "OrderCreated" event ] --> Event Bus / Broker
|
+-----------------------------------+-----------------------------+
| | |
Inventory Service Notification Service Analytics Service
(subscribe) (subscribe) (subscribe)
在庫を引き当てる 確認メールを送る 集計データを更新する擬似コードで表すと、PublisherはSubscriberの存在を意識せずイベントを発行するだけです。
// Publisher側(Order Service)
function createOrder(input):
order = Order.create(input)
save(order)
eventBus.publish("OrderCreated", { orderId: order.id, items: order.items })
// Inventory/Notification/Analyticsを直接呼び出さない
// Subscriber側(Inventory Service)
eventBus.subscribe("OrderCreated", (event) => {
reserveInventory(event.items) // 独立して在庫を引き当てる
})
// Subscriber側(Notification Service)
eventBus.subscribe("OrderCreated", (event) => {
sendConfirmationEmail(event.orderId) // 独立して通知を送る
})主なパターン
イベント通知(Event Notification)
「何が起きたか」を最小限の情報(IDなど)だけ通知し、詳細が必要な購読者は別途問い合わせる
イベントキャリードステートトランスファー
イベントに必要なデータ本体を含めて配信し、購読者が問い合わせなしに処理を完結できるようにする
イベントソーシング
状態そのものではなく、状態を変化させた一連のイベント列を記録の正とみなす(応用度の高いパターン)
メリットと注意点
メリット
- • PublisherとSubscriberが互いを知らずに済む疎結合な設計
- • 新しい購読者(機能)を追加してもPublisher側の変更が不要
- • 一時的な負荷の急増をキューがバッファとして吸収できる
注意点
- • 処理は非同期になるため、即時の強い整合性は保証されない(結果整合性が前提)
- • イベントの重複配信・順序の乱れに耐える冪等な処理設計が必要
- • 処理の全体像を追うには分散トレーシングなどの仕組みが要る
ポイント
- Publisherはイベントを発行するだけで、Subscriberの存在を知らない疎結合な関係を作る
- イベント通知・イベントキャリードステートトランスファー・イベントソーシングなど複数のパターンがある
- 非同期化によって疎結合と負荷吸収を得る代わりに、結果整合性や冪等性の設計、可観測性の確保が必要になる
確認クイズ
1 / 3イベント駆動アーキテクチャの基本的な仕組みとして正しいものはどれか?