CDCとログベース連携の内部

なぜログを読むのか：ポーリング方式の限界

あるDBの変更を別のシステム（検索インデックス、データウェアハウス、キャッシュ、マイクロサービス）へ伝えたい。素朴な方法はクエリポーリングです。updated_at 列を持たせ、定期的に「前回以降に更新された行」を SELECT で拾う。これは動きますが、原理的な穴があります。

• 削除を捕捉できない。DELETE された行はクエリ結果に現れないため、下流は消えたことを知れない。
• 中間状態を取りこぼす。ポーリング間隔の中で同じ行が複数回更新されると、最後の値しか見えず履歴が欠落する。
• 遅延とDB負荷のトレードオフ。間隔を縮めれば遅延は減るが、全件スキャンに近いクエリがDBを叩き続ける。

これらの根は同じで、ポーリングはDBの「現在の状態」を見るだけで、状態に至った「変更の系列」を見ていないことにあります。ところがDBは内部に、まさにその変更系列を持っています。クラッシュ後に復旧するためのトランザクションログです。ログベースCDC（Change Data Capture） は、このログを読むことで変更系列そのものを取り出します。

ログから変更イベントへ：デコードの中身

CDCコネクタ（Debeziumが代表例）は、自身をDBのレプリケーションクライアントとして登録します。PostgreSQLなら論理レプリケーションのスロットを作り、MySQLならレプリカサーバーとしてbinlogをストリーム購読します。受け取る生のログレコードは物理的・低レベルな表現なので、これを論理的な行変更イベントへデコードします。

# CDCイベント1件の論理構造（概念図）
{
  "op": "u",                  # c=作成, u=更新, d=削除, r=スナップショット読み出し
  "before": { id:7, qty:3 },  # 更新前の行（UPDATE/DELETEで意味を持つ）
  "after":  { id:7, qty:5 },  # 更新後の行（INSERT/UPDATEで意味を持つ）
  "source": { lsn:..., txid:..., table:"orders", ts_ms:... }
}

before を取れるかはDB設定に依存します。PostgreSQLはテーブルの REPLICA IDENTITY が FULL でないと更新前イメージが主キーだけになり、MySQLはbinlogが ROW 形式（STATEMENT ではなく）でないと行単位の前後像が得られません。「実行されたSQL文」ではなく「変更された行イメージ」を流すのがログベースCDCの要点で、これにより下流は文を再解釈せずに状態を組み立てられます。

順序保証：なぜ単一系列が効くのか

下流の正しさは順序にかかっています。同じ行に対する「在庫を5にする→3にする」が逆順で届けば、最終状態が壊れます。ここでログの性質が効きます。トランザクションログはコミット順に並ぶ単一の全順序系列なので、CDCはその順序をそのまま保てます。

ただし保証の範囲には境界があります。

実務上の定石は、イベントを行の主キーでパーティショニングすることです。こうすれば「同じ行への変更は同じパーティションに入り、コミット順を維持する」。異なる行どうしの相対順序は緩むものの、ほとんどの下流処理は行ごとに正しければ整合します。グローバルな全順序が必要なら単一パーティションにせざるを得ず、並列度を失います。これは順序と並列性のトレードオフで、一貫性モデル（/devops/consistency-models/）の選択そのものです。

オフセットと配信保証：少なくとも一度になる理由

コネクタはログ内の現在位置をオフセットとして永続化します。PostgreSQLなら LSN（Log Sequence Number）、MySQLなら GTID（Global Transaction ID） やファイル名＋位置です。再起動時はこの保存済み位置から読み直すことで、欠落なく再開できます。

問題は「いつオフセットを保存するか」です。変更を下流へ書く処理と、オフセットを保存する処理は別操作なので、両者の間でクラッシュすると齟齬が出ます。

ケースA: イベント送信 → （クラッシュ） → オフセット未保存
         → 再起動後、同じ位置から再送 → 重複（at-least-once）
ケースB: オフセット先に保存 → （クラッシュ） → イベント未送信
         → 再起動後、保存位置から進む → 欠落（at-most-once）

業務データで欠落は致命的なので、CDCは先にイベントを送ってからオフセットを保存する設計を採り、少なくとも一度（at-least-once）の配信になります。すなわち重複は定常的に起こりうる前提で、下流は同じイベントが二度来ても壊れないべき等処理が必要です。source 内のLSNやtxidは安定したべき等キーとして使えます。配信保証の原理は二将軍問題に根ざしており、詳細はべき等性とexactly-once（/devops/idempotency-exactly-once/）に通じます。

初期スナップショットとログの接続：継ぎ目を埋める

新しくCDCを始めるとき、テーブルには既に大量の既存データがあります。ログには「これから起きる変更」しか流れてこないので、最初に既存全行を読む初期スナップショットが要ります。難所は、スナップショット中もアプリは書き込みを続けるため、スナップショットとログの境目で欠落も重複も出さないことです。

鍵は順序です。スナップショットを開始する時点のログ位置を先に記録し、その一貫した読み取りでテーブルを読み切り、記録した位置からログのストリーミングを始める。

1) 現在のログ位置 P を記録する
2) 一貫した読み取り（スナップショット）で全行を読み、op="r" として流す
3) 位置 P からログを購読し直し、以降の変更を op=c/u/d で流す

スナップショット中に起きた更新は、(2) で読んだ行イメージか (3) のログのどちらか（または両方）に現れます。重複しても、配信が元々 at-least-once でべき等処理を前提とするため、同じキーの後勝ちで収束します。逆に位置 P をスナップショット開始時点に取るのが肝で、これより後ろに取ると P 以前の更新を取りこぼします。Debeziumの増分スナップショット（DDD-3／ウォーターマーク方式）は、テーブルをチャンクに区切り、各チャンク読み出しの前後にログへウォーターマークを書き込むことで、巨大テーブルを止めずに、スナップショットとログの重なりを正確に裁定します。

スキーマ変更への追従

長期運用で必ず来るのが**スキーマ変更（DDL）**です。列の追加・削除・型変更が起きると、ログ中の行イメージの構造も変わります。CDCはこれをどう追うか。

MySQLのbinlogはDDLを文として記録するため、コネクタはDDLを読んでスキーマの現在像を更新します。重要なのは、過去のイベントは当時のスキーマで解釈しなければならない点です。コネクタは時点ごとのスキーマ履歴を保持し、各ログ位置のイベントをその位置で有効だったスキーマで復元します。PostgreSQLの論理デコードは出力プラグインが各変更にスキーマ情報を添えるため、構造はイベント自体から取れますが、いずれにせよスキーマのバージョン管理がCDCの一部です。

まとめ

• ログベースCDCはDBのトランザクションログ（WAL／binlog）を読み、INSERT/UPDATE/DELETEを構造化イベント化する。ポーリングと違い削除や中間状態を取りこぼさず、低遅延でDBへの追加クエリ負荷も小さい。
• 流すのは「SQL文」ではなく変更後（と可能なら変更前）の行イメージ。前イメージには REPLICA IDENTITY FULL やbinlogのROW形式が要る。
• ログはコミット順の単一全順序系列なので、主キーでパーティショニングすれば同一行の順序を保てる。全順序と並列度はトレードオフ。
• コネクタはLSN／GTIDをオフセットとして永続化し、先にイベント送信→後でオフセット保存とするためat-least-once。下流はべき等処理が必須。
• 初期スナップショットは開始時点のログ位置を先に記録してから全行を読み、その位置以降のログへ接続することで継ぎ目を埋める。
• スキーマ変更は時点ごとのスキーマ履歴で追従し、各イベントを当時のスキーマで解釈する。DBの変更が下流の公開API変更になるため、後方互換な進化が安全。