LESSON 30分

ストーリー

田
田中VPoE
イベント駆動アーキテクチャでは、新しいイベントをプロデュースする設計を見た。しかし、既存のアプリケーションDBにはイベントを発行する仕組みがないことが多い
あなた
確かに、PostgreSQLやMySQLの変更をリアルタイムにデータ基盤に連携するにはどうすればいいですか？
あ
田
田中VPoE
それがChange Data Capture — CDCだ。データベースのトランザクションログ（WAL/binlog）を読み取り、INSERT/UPDATE/DELETEの変更をリアルタイムにストリームとして配信する
あなた
データベースのレプリケーションに似ていますね
あ
田
田中VPoE
まさにそうだ。ただしCDCの目的はデータ基盤への連携だ。ソースDBに負荷をかけずに、秒単位の遅延でデータをDWHに連携できる。従来の「日次でSELECT * FROM …」というETLとは根本的に異なるアプローチだ

CDCの仕組み

CDCの方式

方式仕組みメリットデメリット
ログベースCDCDB のトランザクションログを読み取るソースDBへの負荷が最小、削除も検出可能DB固有の設定が必要
タイムスタンプベースupdated_at列で差分を検出実装が簡単削除が検出できない、タイムスタンプ列が必要
トリガーベースDBトリガーで変更を記録柔軟ソースDBに負荷、パフォーマンス影響
差分比較前回スナップショットとの差分を計算DB設定不要大量のSELECT、高負荷

ログベースCDCの仕組み

ログベースCDC（PostgreSQL WAL の例）:

┌──────────────────────────────────────────────┐
│  PostgreSQL                                  │
│                                              │
│  テーブル: orders                              │
│  ┌─────────────────────────────────────────┐ │
│  │ INSERT INTO orders (id, amount, status) │ │
│  │ VALUES (1, 5000, 'pending')             │ │
│  └────────────────────┬────────────────────┘ │
│                       ↓                      │
│  WAL (Write-Ahead Log)                       │
│  ┌─────────────────────────────────────────┐ │
│  │ LSN: 0/16B3740                          │ │
│  │ Operation: INSERT                       │ │
│  │ Table: public.orders                    │ │
│  │ Data: {id:1, amount:5000, status:pending}│ │
│  └────────────────────┬────────────────────┘ │
└───────────────────────┼──────────────────────┘
                        ↓
┌───────────────────────┴──────────────────────┐
│  Debezium (CDC Connector)                     │
│  ┌─────────────────────────────────────────┐ │
│  │ WALを読み取り、変更イベントに変換          │ │
│  │ Kafka Topic: dbserver1.public.orders     │ │
│  └────────────────────┬────────────────────┘ │
└───────────────────────┼──────────────────────┘
                        ↓
┌───────────────────────┴──────────────────────┐
│  Apache Kafka                                 │
│  Topic: dbserver1.public.orders              │
│  ┌─────────────────────────────────────────┐ │
│  │ {                                       │ │
│  │   "op": "c",  // c=create, u=update     │ │
│  │   "before": null,                       │ │
│  │   "after": {                            │ │
│  │     "id": 1,                            │ │
│  │     "amount": 5000,                     │ │
│  │     "status": "pending"                 │ │
│  │   },                                    │ │
│  │   "source": {                           │ │
│  │     "ts_ms": 1718456789000,             │ │
│  │     "db": "orders_db",                  │ │
│  │     "table": "orders"                   │ │
│  │   }                                     │ │
│  │ }                                       │ │
│  └─────────────────────────────────────────┘ │
└──────────────────────────────────────────────┘

CDCツールの比較

主要ツール

ツールライセンス対応DBデプロイ方式特徴
DebeziumOSSPostgreSQL, MySQL, MongoDB, SQL Server, OracleKafka Connect最も広く使われるCDCツール
AWS DMSマネージド主要RDBMS + MongoDBAWSサービスフルマネージド、マイグレーション向け
FivetranSaaS主要RDBMS + SaaSSaaSノーコード、簡単セットアップ
AirbyteOSS300以上のコネクタセルフホスト / CloudOSSで柔軟、EL特化
Striim商用主要RDBMSオンプレ / クラウドエンタープライズ向け

Debezium + Kafka Connect の構成

Debezium + Kafka Connect:

                 Kafka Connect Cluster
                 ┌───────────────────────┐
  PostgreSQL ───→│ Debezium Source       │──→ Kafka Topic
  MySQL     ───→│ Connector             │──→ Kafka Topic
  MongoDB   ───→│                       │──→ Kafka Topic
                 └───────────────────────┘
                           ↓
                 ┌───────────────────────┐
                 │ Kafka Connect Sink    │
                 │ Connector             │
                 │ ├── S3 Sink           │──→ データレイク
                 │ ├── BigQuery Sink     │──→ DWH
                 │ └── Elasticsearch Sink│──→ 検索
                 └───────────────────────┘

CDCパイプラインの設計

データレイクへの取り込みパターン

パターン説明レイテンシ複雑さ
CDC → Kafka → S3 (Bronze)KafkaからS3にParquetで書き出し分〜時間低
CDC → Kafka → Flink → DWHFlinkでリアルタイム変換してDWHに書き込み秒〜分高
CDC → Kafka → Kafka Connect → BigQueryKafka Connectで直接BigQueryに書き込み分中

初期ロードと増分同期

CDC パイプラインの流れ:

Phase 1: 初期ロード（Initial Snapshot）
  ┌──────────────┐
  │ ソースDB      │ → テーブル全体をスナップショット → Bronze層
  │ 10億レコード   │   （数時間かかる場合あり）
  └──────────────┘

Phase 2: 増分同期（Incremental Sync）
  ┌──────────────┐
  │ ソースDB      │ → WALの変更のみをリアルタイム配信 → Bronze層
  │ INSERT/UPDATE │   （秒単位の遅延）
  │ DELETE        │
  └──────────────┘

注意点:
  - 初期ロード中にも変更は発生する
  - スナップショットのLSN以降のWALを増分として適用
  - Debeziumはこのハンドオフを自動で管理する

「CDCは『ソースDBの変更をデータ基盤にリアルタイムで同期する橋』だ。日次ETLではできなかった『ほぼリアルタイムのDWH更新』を、ソースDBに負荷をかけずに実現する」 — 田中VPoE

まとめ

ポイント内容
CDCデータベースの変更をリアルタイムにキャプチャし、ストリームとして配信
ログベースCDCWAL/binlogを読み取る方式が最もソースDB負荷が低い
DebeziumOSSで最も広く使われるCDCツール、Kafka Connectで動作
パイプライン設計初期ロード → 増分同期の2フェーズで構成

チェックリスト

  • CDCの4つの方式（ログベース、タイムスタンプ、トリガー、差分比較）を説明できる
  • ログベースCDCの仕組み（WAL読み取り）を理解した
  • Debeziumの基本構成とKafka Connectとの連携を理解した
  • 初期ロードと増分同期のハンドオフを説明できる

次のステップへ

次は「リアルタイム分析基盤」を学びます。CDCとストリーム処理を組み合わせて、リアルタイムダッシュボードやリアルタイムMLを実現する設計を身につけましょう。

推定読了時間: 30分