CDC（Change Data Capture）：アプリを汚さずに変更を伝播する

CDC とは

Change Data Capture（CDC） は、データベースへの変更（INSERT / UPDATE / DELETE）を検知して、その変更を他のシステムへ伝播する仕組みだ。

アプリケーションコードを変更せず、DB のログ（WAL: Write-Ahead Log）を読むことで変更を拾う点が Dual Write や Outbox Pattern との最大の違いだ。

WAL（Write-Ahead Log）とは

PostgreSQL などのデータベースは、クラッシュ時の復旧のために変更内容を先にログへ書き出す仕組み（Write-Ahead Logging）を持つ。CDC はこのログを「外部からも読める」ようにして変更イベントを生成する。

アプリ → INSERT/UPDATE/DELETE → PostgreSQL
                                    ↓
                              WAL（変更ログ）
                                    ↓
                            CDC ツール（Debezium）が読む
                                    ↓
                              Kafka トピック
                                    ↓
                          下流サービス・DWH・検索インデックス

Debezium + Kafka による構成

Debezium は PostgreSQL・MySQL・MongoDB など主要 DB の CDC を Kafka Connect として実装したオープンソースツールだ。

┌─────────────────────────────────────────────────────────┐
│  PostgreSQL                                             │
│  ┌──────────┐   変更発生     ┌─────────────────┐       │
│  │  orders  │ ──────────→    │  WAL（変更ログ） │       │
│  └──────────┘                └────────┬────────┘       │
└────────────────────────────────────────┼────────────────┘
                                         │ Logical Replication Slot
                                ┌────────▼────────┐
                                │   Debezium      │
                                │  (Kafka Connect)│
                                └────────┬────────┘
                                         │
                    ┌────────────────────▼──────────────────────┐
                    │                Kafka                       │
                    │  Topic: db.public.orders                   │
                    │  { op: "c", after: { id: 1, ... } }       │
                    └──────┬──────────────┬──────────────┬──────┘
                           ↓              ↓              ↓
                    在庫サービス    通知サービス    データウェアハウス

Debezium イベントの形式

{
  "op": "u",            // c=create, u=update, d=delete, r=read(snapshot)
  "before": {
    "id": 1,
    "status": "pending"
  },
  "after": {
    "id": 1,
    "status": "shipped"
  },
  "source": {
    "table": "orders",
    "lsn": 12345678      // WAL 上の位置（重複排除に使える）
  }
}

CDC の主なユースケース

1. データウェアハウスへのリアルタイム同期

PostgreSQL（トランザクションDB）
    ↓ CDC（Debezium + Kafka）
BigQuery / Redshift（分析DB）

アプリを一切変更せず、分析基盤をリアルタイムに更新できる

2. マイクロサービス間のデータ伝播

サービス A が自分の DB を更新する → CDC が検知 → サービス B が Kafka を購読して自分の DB を更新する。サービス A はサービス B の存在を知らない。

3. 旧ストアから新ストアへの移行

Phase 1: CDC で旧ストアの変更を新ストアへ複製（追随）
Phase 2: 両ストアが同期した状態を確認
Phase 3: アプリの読み先を新ストアへ切り替え
Phase 4: CDC を停止、旧ストアを廃止

Dual Write と違い、アプリコードを変更せず移行できる。

Dual Write / Outbox / CDC の比較

観点	Dual Write	Outbox Pattern	CDC
アプリ変更	必要（書き込み処理の変更）	必要（outbox テーブルへの書き込み）	不要（DB ログを読む）
部分失敗リスク	高い	ない（TX 内で完結）	ない（WAL は DB がコミット後に書く）
配信保証	なし	At-Least-Once	At-Least-Once
実装コスト	低い	中	高い（Kafka + Debezium の運用が必要）
運用コスト	低い	中	高い（Kafka クラスタの管理）
スキーマ変更への追従	手動でコード修正	手動でコード修正	Debezium が自動検知
適用場面	小規模・一時的な移行	イベント駆動サービス	大規模・長期的な同期

CDC を選ぶべき場面

アプリコードを変更したくない（レガシーシステム、他チームが管理している）
複数の下流システムへ同じ変更を伝播したい
大量データのリアルタイム同期が必要
DB の変更履歴そのものをイベントソースとして扱いたい

CDC を避けるべき場面: 小規模プロジェクトや一時的な移行では Kafka + Debezium の運用コストが見合わないことが多い。

出典・参考文献

Martin Kleppmann, Designing Data-Intensive Applications (2017) Chapter 11
Debezium Documentation — debezium.io
Gunnar Morling, “Change Data Capture with Debezium and Apache Kafka”