LASSIC Media らしくメディア
CDC(変更データキャプチャ)導入を外注で進める
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- CDC(変更データキャプチャ)がバッチ連携の遅延やアプリ改修なしのデータ連携という課題にどう対応するかを整理します。
- Debeziumによるログベースのデータ連携が、ポーリング型と何が異なるのかを公式情報に基づいて解説します。
- 初期スナップショット・スキーマ変更・配信保証など、導入時に詰めておくべき論点と外注時の委託範囲を整理します。
目次
CDC(変更データキャプチャ)とは何か
CDC(変更データキャプチャ)とは、データベースに生じた変更（追加・更新・削除）を検知し、その差分をイベントとして他システムへ連続的に連携する仕組みを指します。Debezium公式ドキュメントは、CDCをデータベースが持つ変更検知機能を利用してソースシステムから変更を取り込む方式と説明しています*1。
本稿で扱うCDCは、データベースのトランザクションログ（MySQLのbinlog、PostgreSQLのWAL＝Write Ahead Log）を読み取って変更を捕捉する「ログベースCDC」です。テーブルを定期的に問い合わせるポーリング型や、業務横断でデータを統合するデータメッシュ、分析基盤としてのDWHとは異なる、DB直下の変更検知レイヤーとして位置づけられます。
バッチ連携の限界とCDCが解く課題
基幹システムと他システムをデータ連携する際、多くの現場では夜間バッチによる全件または差分抽出が使われてきました。バッチ連携には、連携タイミングまでデータが反映されない遅延と、抽出処理と本来の書き込み処理が別経路になることによる整合性確認の手間という2つの制約があります。
CDCはこの制約に対し、アプリケーション側の改修をせずにDB変更を捕捉できる点で異なるアプローチを提供します。Debezium公式ドキュメントは、ログベースCDCが変更を低遅延で検知しつつ、頻繁なポーリングに伴うCPU負荷の増加を避けられる方式であるとしています*1。
ただし、CDCを導入したからといって遅延が解消するとは限りません。ログの読み取り間隔・下流のKafka Connect構成・ネットワーク帯域によって、実際の反映速度は変動します。導入目的（リアルタイム性が必要な業務か、日次バッチで十分な業務か）を先に明確にすることが、過剰投資を避ける前提になります。
Debeziumの仕組み — ログベースCDCとポーリング型の違い
Debeziumは、MySQL・PostgreSQL・SQL Server・Oracle等のデータベースに対応するコネクタ群を提供するオープンソースのCDCプラットフォームです。MySQLコネクタはbinlogにアクセスするクライアントライブラリを、PostgreSQLコネクタは論理レプリケーションストリームを利用して変更を読み取ります*1。
ポーリング型のCDC（テーブルの更新日時列や差分フラグを定期的に問い合わせる方式）と比較すると、ログベースCDCは削除操作も含めた全ての変更を取りこぼしなく捕捉できる点、および頻繁な問い合わせによるDB負荷を避けられる点が異なります。Debezium公式ドキュメントでも、MySQL・PostgreSQLにおいてミリ秒単位の遅延で変更イベントを生成できるとされています*1。
DebeziumはApache Kafka Connect（Kafkaが提供するコネクタ実行フレームワーク）上で動作するソースコネクタとして実装されます。Kafka公式ドキュメントは、Kafka Connectがスタンドアロンモードと分散モードの2つの実行方式をサポートし、コネクタが担当するデータ処理をタスク（Task）に分割して実行すると説明しています*2。Debeziumが検知した変更イベントはKafkaトピックに書き込まれ、Sinkコネクタや各種コンシューマーを介して下流システムへ配信される構成です。
データベースが稼働を続けトランザクションログが循環削除されている場合、コネクタ起動時点のログだけでは全データを復元できません。Debeziumはこの場合に初期スナップショットを取得する機能を持ち、PostgreSQLコネクタでは接続直後に各スキーマの一貫性のあるスナップショットを取得したうえで、スナップショット完了地点から継続的なストリーミングに移行します*1。稼働中のシステムに影響を与えずにスナップショットを取得するインクリメンタルスナップショットの機能も用意されています*1。
アウトボックスパターンとイベント配信の設計
マイクロサービス間でイベントを配信する設計では、業務データの更新とイベント発行を1つのトランザクションでまとめて行いたいという要件が生じます。これに対する代表的な設計が、業務テーブルと同じトランザクションでoutbox（発信箱）テーブルにイベントを書き込み、そのoutboxテーブルの変更をDebeziumで検知してKafkaへ送るアウトボックスパターンです*3。
Debezium公式ドキュメントのOutbox Event Router機能は、このoutboxテーブルの変更イベントを、下流が扱いやすい形式に変換してルーティングする仕組みとして提供されています*3。アプリケーション側は業務トランザクションの一部としてoutboxへの書き込みを行うだけでよく、メッセージブローカーへの直接送信処理を持つ必要がなくなります。
配信保証については、アウトボックスパターンは基本的に少なくとも1回配信（at-least-once）を保証する設計であるとされています*3。Kafka Connect側のプロセスが再起動した場合、直前に配信済みのイベントが再送される可能性があるため、少なくとも1回配信のもとで厳密に1回だけ処理したい（exactly-once相当にしたい）場合は、イベントを受け取るコンシューマー側を冪等（同じイベントを複数回処理しても結果が変わらない設計）にすることが前提になります*3。
導入前に詰めるべき4つの論点
CDC導入プロジェクトでは、仕組みの理解だけでなく、運用に入ってから顕在化する論点を事前に整理しておく必要があります。ここでは4つの論点を挙げます。
| 論点 | 内容 |
|---|---|
| 初期スナップショット | 既存データをどの時点でどう取り込むか。稼働中システムへの負荷を抑えるインクリメンタルスナップショットを使うかどうかを決める必要があります。*1 |
| スキーマ変更への追従 | 本番DBのテーブル定義が変わった際、下流のイベントスキーマも追従させる設計が要ります。outboxイベントのスキーマはAPI契約と同様に扱い、互換性を保ちながら変更する運用が推奨されています。*3 |
| 順序保証 | Kafkaはパーティション内では順序を保証しますが、パーティションをまたぐ順序は保証しません。テーブル単位・キー単位でどのパーティションに配置するかの設計が必要です。 |
| 配信保証と冪等性 | 少なくとも1回配信が前提のため、イベントを受け取る側の処理を冪等にする設計が必須です。*3 |
CDC導入を内製で進める場合の必要スキルと工数
CDC基盤を内製で構築・運用するには、複数領域の知識が必要になります。データベース側では、対象DBのトランザクションログ機構（binlogのフォーマット、WALのレプリケーションスロット等）の理解と、ログ保持設定の変更権限が必要です。連携基盤側では、Kafka Connectのクラスタ構築・コネクタ設定・オフセット管理の知識が求められます。
設計を誤った場合の代表的な失敗コストとして、ログ保持期間の設定不足によりコネクタが長時間停止した際に復旧に必要なログが既に削除されており、再スナップショットが必要になるケースが挙げられます。再スナップショットは対象テーブルの規模によっては本番DBに追加負荷をかけるため、実施タイミングの調整が必要になります。
また、下流のコンシューマーを冪等に作り込む設計は、既存システムの改修を伴うことが多く、CDC基盤単体の構築より工数がかかる場合があります。DB管理者・アプリケーション開発者・基盤担当者の3者が連携して進める体制が実務上は必要です。
外注の委託範囲と発注準備
CDC基盤の構築を外部パートナーに委託する場合、委託範囲を事前に切り分けておくと発注後の手戻りを抑えられます。想定される委託範囲は、Debeziumコネクタの選定・設定、Kafka Connectクラスタの構築、初期スナップショット方式の設計、outboxパターン導入時のアプリケーション改修支援、監視・アラート設計です。
発注準備として整理しておきたい情報は次の通りです。対象データベースの種類とバージョン、想定する変更頻度（1日あたりの更新件数の目安）、下流システムの数と処理方式（バッチ処理かリアルタイム処理か）、許容できる反映遅延の目安、既存のログ保持設定です。これらが曖昧なまま発注すると、見積もり時点でコネクタ構成やクラスタ規模が確定できず、要件定義の後戻りが発生しやすくなります。
専門パートナーに依頼する場合と内製で進める場合の違いは、Debeziumやトランザクションログ機構の知見を持つ人材を新たに確保・育成する必要があるかどうかです。内製では、対象DBとKafka Connectの両方に精通した人材の採用・育成にリードタイムを要します。外部委託では、複数のDB・コネクタ導入を経験したパートナーの知見を活用し、設計段階での手戻りを抑える狙いがあります。
まとめ：CDC導入で確認すべき3つの判断軸
本稿では、CDC(変更データキャプチャ)がバッチ連携の遅延やアプリ改修コストという課題にどう対応するか、DebeziumによるログベースCDCの仕組み、導入時に詰めるべき論点を整理しました。判断軸を3つに集約すると、第一に自社の連携要件（許容遅延・変更頻度）がCDCを必要とする水準かどうか、第二に初期スナップショット・スキーマ変更・順序保証・冪等性という4つの論点を設計段階で詰められるかどうか、第三に内製と外注のどちらでリードタイムとリスクを抑えられるかです。
よくある質問
CDCとポーリング型の差分連携はどちらを選ぶべきですか。
許容できる反映遅延と対象テーブルの更新頻度で判断します。ミリ秒〜秒単位の反映が必要で更新頻度が高い場合はログベースCDCが適しますが、日次更新で十分な業務ではポーリング型やバッチ連携の方が構成をシンプルに保てます。Debezium公式もログベースCDCの利点を低遅延とDB負荷の抑制としています*1。
Debezium導入にKafkaは必須ですか。
Debeziumの標準的な構成はApache Kafka Connect上で動作するソースコネクタとしての利用です*1。Kafka基盤を新たに構築する負担を考慮した上で、既存のメッセージング基盤との統合方法を検討する必要があります。
本番データベースへの負荷は増えますか。
ログベースCDCはトランザクションログを読み取る方式のため、通常運用時のテーブルへの問い合わせ負荷は抑えられます*1。ただし初期スナップショット取得時は対象テーブルの規模に応じた負荷が発生するため、インクリメンタルスナップショット機能の利用や実施タイミングの調整が必要です*1。
スキーマ変更にはどう対応しますか。
outboxパターンを採用する場合、イベントスキーマをAPI契約と同様に扱い、フィールド追加を基本としつつ削除・リネームは移行計画とセットで行う運用が推奨されています*3。本番DBのテーブル定義変更とイベントスキーマの変更を同期させる運用ルールを事前に定めておくことが必要です。
外注する場合、どこまでを委託範囲にすればよいですか。
コネクタ選定・Kafka Connectクラスタ構築・初期スナップショット設計・監視設計までを委託範囲とするのが一般的です。下流コンシューマーの冪等化改修は既存システムへの手当てが必要なため、委託範囲に含めるかどうかを発注前に切り分けておくことが手戻りを防ぎます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Debezium「Debezium Architecture」Debezium Documentation（https://debezium.io/documentation/reference/stable/architecture.html）
- *2 出典：Apache Kafka「Kafka Connect User Guide」Apache Kafka 4.1 Documentation（https://kafka.apache.org/41/kafka-connect/user-guide/）
- *3 出典：Debezium「Outbox Event Router」Debezium Documentation（https://debezium.io/documentation/reference/stable/transformations/outbox-event-router.html）
