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

ストーリー

田

田中VPoE

ストリーム処理の基礎を学んだ。次は、ストリーム処理のデータを生み出すアーキテクチャ — イベント駆動アーキテクチャ（EDA）だ

あなた

マイクロサービス間の通信にイベントを使うパターンですよね

あ

田

田中VPoE

それも含むが、データ基盤の観点ではより広い意味がある。「システムで起きたことをイベントとして記録し、それを複数のコンシューマが自由に利用できるようにする」という設計思想だ

あなた

従来のAPIコール（リクエスト-レスポンス）とは何が違うんですか？

あ

田

田中VPoE

APIコールは「今すぐこれをやって」という命令型。イベントは「これが起きた」という事実の通知だ。イベントの消費者はプロデューサーを知らなくていい。これが疎結合を実現する

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

リクエスト駆動 vs イベント駆動

観点	リクエスト駆動	イベント駆動
通信モデル	同期（リクエスト-レスポンス）	非同期（Publish-Subscribe）
結合度	高い（呼び出し先を知る必要あり）	低い（イベントを発行するだけ）
スケーラビリティ	呼び出し先に依存	コンシューマを独立にスケール
障害の伝播	連鎖障害のリスク	バッファリングで吸収
データ基盤との統合	ETLで定期的に抽出	イベントがリアルタイムにデータ基盤に流入

リクエスト駆動:
  注文サービス ──→ 在庫サービス ──→ 決済サービス ──→ 通知サービス
                    (同期呼び出し、1つ止まると全部止まる)

イベント駆動:
  注文サービス ──→ [注文イベント] ──→ イベントブローカー
                                      ├──→ 在庫サービス
                                      ├──→ 決済サービス
                                      ├──→ 通知サービス
                                      └──→ データ基盤（DWH/分析）

Apache Kafkaの基本

アーキテクチャ

Kafka アーキテクチャ:

プロデューサー                    コンシューマー
┌────────┐     ┌──────────────────────────┐     ┌────────────┐
│ アプリA  │────→│         Topic            │────→│ 分析パイプライン │
│ アプリB  │────→│  ┌────┬────┬────┬────┐   │────→│ ML推論サービス │
│ CDC     │────→│  │ P0 │ P1 │ P2 │ P3 │   │────→│ DWH取り込み   │
└────────┘     │  └────┴────┴────┴────┘   │     └────────────┘
               │    Partition              │
               │    (順序保証はパーティション内) │
               └──────────────────────────┘
                         Broker

主要概念

概念	説明
Topic	メッセージのカテゴリ。例: `orders`, `user-events`
Partition	Topic内の並列処理単位。順序保証はパーティション内のみ
Offset	パーティション内のメッセージの位置
Consumer Group	1つのトピックを協調して消費するコンシューマの集合
Retention	メッセージの保持期間。デフォルト7日、無期限も可能

イベント設計のベストプラクティス

イベントスキーマ

{
  "event_id": "evt_abc123",
  "event_type": "order.completed",
  "event_version": "1.2",
  "timestamp": "2025-06-15T14:30:00Z",
  "source": "order-service",
  "correlation_id": "corr_xyz789",
  "data": {
    "order_id": "ord_12345",
    "customer_id": "cust_67890",
    "total_amount": 15000,
    "currency": "JPY",
    "items": [
      {
        "product_id": "prod_111",
        "quantity": 2,
        "unit_price": 7500
      }
    ]
  },
  "metadata": {
    "user_agent": "Mozilla/5.0...",
    "ip_address": "192.168.1.1"
  }
}

スキーマ進化

戦略	説明	適用場面
後方互換	新しいスキーマで古いデータを読める	フィールド追加（オプショナル）
前方互換	古いスキーマで新しいデータを読める	コンシューマの段階的更新
完全互換	前方・後方の両方	最も安全、制約が厳しい

スキーマレジストリの役割:

プロデューサー → スキーマレジストリ → コンシューマー
                (Confluent Schema Registry / AWS Glue Schema Registry)

1. プロデューサーがスキーマを登録
2. レジストリが互換性をチェック
3. 互換性違反はデプロイをブロック
4. コンシューマーがスキーマを取得してデシリアライズ

イベントソーシング

概要

観点	CRUD	イベントソーシング
データの保存	現在の状態を上書き	全イベントを追記
履歴	失われる	完全に保持
監査	別途ログが必要	イベント自体が監査証跡
状態の復元	最新の状態のみ	任意の時点の状態を再構築可能
複雑さ	低い	高い（イベントの再生が必要）

イベントソーシングの例（銀行口座）:

イベントストア:
  [口座開設 balance=0]
  → [入金 +10,000]
  → [出金 -3,000]
  → [入金 +5,000]
  → [出金 -2,000]
  = 現在の残高: 10,000

任意の時点の状態を復元:
  2番目のイベントまで再生 → 残高 10,000
  3番目のイベントまで再生 → 残高 7,000

「イベント駆動アーキテクチャとデータ基盤は相性が良い。アプリケーションが発行するイベントをそのままデータレイクに流せば、ETLの遅延なしでデータが蓄積される。これがリアルタイムデータ基盤の基盤だ」 — 田中VPoE

まとめ

ポイント	内容
イベント駆動	「これが起きた」という事実の通知を基盤とするアーキテクチャ
Apache Kafka	Topic、Partition、Consumer Groupが基本概念
イベント設計	スキーマバージョニングとスキーマレジストリで互換性を管理
イベントソーシング	全イベントを追記し、任意の時点の状態を再構築可能

チェックリスト

リクエスト駆動とイベント駆動の違いを説明できる
Kafkaの基本概念（Topic, Partition, Consumer Group）を理解した
イベントスキーマの設計とスキーマ進化の戦略を理解した
イベントソーシングの利点と適用場面を説明できる

次のステップへ

次は「Change Data Capture（CDC）」を学びます。既存データベースの変更をリアルタイムにキャプチャし、データ基盤に連携する技術を身につけましょう。

推定読了時間: 30分