変更データキャプチャ (CDC) とは

変更データキャプチャ (Change Data Capture、CDC) は、データベースの INSERT、UPDATE、DELETE をリアルタイムに検出し、変更イベントとして下流のシステム (検索エンジン、キャッシュ、分析基盤) に伝播させるデータ統合パターンである。チェンジデータキャプチャとも表記される。アプリケーションコードを変更せずに、データベースの変更を複数のシステムに配信できる。

CDC の実装方式

CDC の実装方式を以下にまとめる。

方式	仕組み	遅延	DB 負荷	信頼性
ログベース	トランザクションログを読み取り	ミリ秒〜秒	低い	高い
トリガーベース	DB トリガーで変更を検出	ミリ秒	高い	高い
ポーリング	定期的にテーブルをスキャン	秒〜分	中程度	中程度
タイムスタンプ	updated_at で変更を検出	秒〜分	中程度	DELETE を検出不可

ログベースが最も効率的で、本番環境で推奨される。DB のトランザクションログ (MySQL の binlog、PostgreSQL の WAL) を読み取るため、アプリケーションへの影響が最小限だ。

AWS での CDC

DynamoDB Streams

DynamoDB が標準で備える CDC の仕組みである。項目レベルの変更を時系列に記録するが、ストリーム内のデータの寿命は 24 時間で、それを過ぎたレコードはいつ削除されてもおかしくない。取りこぼすと後から取り返せないため、Lambda をトリガーに設定して即時処理し、失敗時は再試行と DLQ で拾う構成が定番だ。

RDS + Debezium

Debezium (オープンソースの CDC ツール) でトランザクションログを読み取り、Kafka や Kinesis へ転送する。読み取り方は DB エンジンで異なり、MySQL は binlog を読むのに対し、PostgreSQL に「バイナリログ」は存在せず、レプリケーションスロット経由で WAL を論理デコーディングして読む (PostgreSQL 10 以降は標準の pgoutput プラグインが使える)。そのため PostgreSQL 側の準備が要る点が落とし穴で、RDS ならインスタンスパラメータ rds.logical_replication を 1 にして wal_level が logical になっていることを確認しておく。Kafka を使うなら Amazon MSK (Managed Streaming for Apache Kafka) と組み合わせる。

活用パターン

活用パターンを図で示す。

[DynamoDB] → [Streams] → [Lambda] → [OpenSearch] (検索インデックス更新)
                                   → [ElastiCache] (キャッシュ更新)
                                   → [S3] (分析用データレイク)
                                   → [SQS] (他サービスへの通知)

CQRS の読み取りモデル更新
検索インデックスの同期
キャッシュの自動更新
データレイクへのリアルタイム連携
マイクロサービス間のデータ同期

Transactional Outbox との違い

Transactional Outbox との違いを以下にまとめる。

パターン	仕組み	用途
CDC	DB のログを直接読み取り	汎用的なデータ同期
Transactional Outbox	Outbox テーブルに書き込み → ポーリング	イベント発行の信頼性保証

CDC はアプリケーションコードの変更が不要だが、DB のログ形式に依存する。Outbox パターンはアプリケーションが明示的にイベントを書き込むため、イベントの内容を制御しやすい。

Change Data Capture の理解を深めるには関連書籍が参考になる。

サイト情報

変更データキャプチャ (CDC) とは - DB の変更をリアルタイム連携するパターン