# 変更データキャプチャ(CDC) ## 定義 変更データキャプチャ(change data capture, CDC)とは、データベースへ書き込まれた全てのデータ変更を観測し、他システムへ複製可能な形式で抽出するプロセスである。長らく多くのデータベースはレプリケーションログを内部実装の詳細として扱い、公開 API として文書化してこなかったため、変更を別のストレージ技術(検索インデックス・キャッシュ・データウェアハウス等)へ複製することは困難だった。CDC はこのレプリケーションログを実質的な公開インタフェースとして扱い、変更をストリームとして即座に利用可能にする。CDC を導入すると、変更を抽出する元のデータベースが実質的な*リーダー*となり、それを消費する検索インデックスやデータウェアハウスなどの派生データシステムは*フォロワー*として振る舞う——CDC はログベースメッセージブローカ(→ [[分散メッセージブローカ]])とも相性がよく、メッセージの順序を保存できるためレプリケーション的な一貫性を保ちやすい。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] "Change Data Capture", "Implementing CDC") ## デュアルライト問題の解決 CDC が解く中心的な問題は*デュアルライト(dual write)*——アプリケーションコードがデータベースと検索インデックスなど複数システムへ別々に書き込む方式——が引き起こす競合状態である。2クライアントが同じキーを異なる値に並行更新する場合、到着順序がシステムごとに異なりうるため、両システムが恒久的に矛盾した最終値を持ってしまう。単一のデータベースを唯一の書き込み先(リーダー)とし、そこからの変更ログを他システムへ順序どおり伝播させれば、この競合状態は原理的に発生しない。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] "Keeping Systems in Sync", "Change Data Capture") ## 実装 論理(行ベース)レプリケーションログを用いるのが一般的だが、スキーマ変更や更新の適切なモデリングなど課題がある。Debezium(→ [[Debezium]])は MySQL・PostgreSQL・Oracle・SQL Server・Db2・Cassandra 等向けのソースコネクタを提供し、標準イベントスキーマへ変更を変換する。Kafka Connect フレームワークも各種データベース向け CDC コネクタを提供する。MySQL の binlog を解析する Maxwell、Oracle 向けの GoldenGate、PostgreSQL 向けの pgcapture も類似の役割を担う。CDC は通常メッセージブローカと同様に非同期であり、システム・オブ・レコードは変更が消費者に適用されるのを待たずにコミットする——これによりレプリケーションラグの問題(→ [[レプリケーションラグと読み取り整合性]])が生じうる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] "Implementing CDC") Cassandra のようなクォーラムベースの結果整合的データベース(→ [[クォーラムベースレプリケーション]])では、書き込みが可視になるにはノードの過半数への永続化が必要であり、単一の「真実の源」となるログが存在しないため CDC の実装が難しい。Cassandra はこの問題をノードごとの生ログセグメントを個別に公開する形で回避しており、消費側がクォーラムリーダーと同様の方法で複数ノードのログをマージして単一ストリームへ統合する必要がある。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] "API support for change streams") 新しい派生データシステムを追加する際、変更ログの全履歴を無限に保持するのは非現実的なため、既知のオフセットに対応するコンシステントなスナップショットから開始し、それ以降の変更ログを適用する必要がある(Debezium は Netflix の DBLog watermarking アルゴリズムでインクリメンタルスナップショットを実現する)。ログコンパクション(各キーの最新値のみを残す)を使えば、CDC トピックがそれ単独でデータベースの完全なコピーを再構築できる手段になり、スナップショット取得の手間を省ける。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] "Initial snapshot", "Log compaction") ## CDC とイベントソーシングの異同 CDC とイベントソーシング(→ [[イベントソーシングとCQRS]])はいずれも「変更のログ」という発想を採るが、抽象レベルが異なる。CDC ではアプリケーションはデータベースを可変な方法で使い続け、変更ログは低レベルで(レプリケーションログの解析等により)抽出される——これにより抽出された書き込み順序は実際に書き込まれた順序と一致し、デュアルライトの競合状態を回避できる。イベントソーシングでは、アプリケーションロジック自体が不変イベントの上に明示的に構築され、イベントストアは追記専用でイベントの更新・削除は基本的に禁止される。ログコンパクションの扱いも異なる: CDC の更新イベントは通常レコードの新バージョン全体を含むため最新イベントのみ残せばよいが、イベントソーシングのイベントはユーザーアクションの意図をより高いレベルで表現するため後続イベントが先行イベントを上書きせず、状態を再構築するには全履歴が必要になる。既存データベースへの CDC 導入は最小限の変更で済むのに対し、イベントソーシングの採用はアプリケーション設計への大きな変更を要する。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] "CDC versus event sourcing") ## 横断的知見 - (この節は今後、複数ソースの突き合わせで得られた知見を蓄積する。現時点では単一ソースからの知見のみ。) ## 未解決の問い - Cassandra のようなクォーラムベースデータベースでのノード別生ログのマージは、クォーラムリーダーの読み取りと同等の一貫性を消費側に要求する。この一貫性保証の実装コストは、単一リーダーデータベースの CDC と比べてどの程度大きいか。 - CDC の非同期性がもたらすレプリケーションラグは、派生システム(検索インデックス等)がどの程度古いデータを許容できるかに依存する。読み取り整合性(→ [[レプリケーションラグと読み取り整合性]])の技法は CDC 由来の派生システムにどこまで転用できるか。 - ログコンパクションされた CDC トピックからのフルスキャンによる派生システム再構築は、元のデータベースへの初期スナップショット取得と比べてどのようなコスト・一貫性のトレードオフを持つか。 ## 関連 - ソース: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]]("Change Data Capture", "Implementing CDC", "CDC versus event sourcing") - 実体: [[Debezium]] / [[Apache Kafka]] - 概念: [[分散メッセージブローカ]] / [[イベントソーシングとCQRS]] / [[導出データ]] ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]]("Keeping Systems in Sync", "Change Data Capture" 節)