Debezium による CDC: RDB から Kafka へのリアルタイム連携

トランザクションDBの更新をほぼリアルタイムでイベント化し、Kafka に流し込む王道のやり方が Debezium を使った CDC です。アプリの改修を最小化しつつ、低遅延・高整合でデータ連携できます。

本稿は実務でつまずきやすい論点を、Kafka の公式挙動に沿って整理します。あわせて CCDAK で問われやすい観点（Connect、シリアライザ、パーティショニング、配信保証）も明確にします。

なぜ Debezium で CDC か: 仕組みと全体像

Debezium はデータベースの変更ログ（例: MySQL の binlog、PostgreSQL の WAL）を購読し、Kafka Connect の Source コネクタとして変更イベントを Kafka トピックに出力します。アプリ側にトリガや改修を入れず、DB エンジンが保証する順序と一貫性を最大限活用できるのが強みです。

イベントは通常、before/after のレコード、操作種別（c: create, u: update, d: delete, r: snapshot）、タイムスタンプ、ソースメタデータを含むエンベロープ形式でエンコードされます。キーには主キー（もしくは論理キー）を使い、メッセージの整合性と Kafka のパーティション内順序を担保します。

• 低遅延で欠損を起こしづらいログベース CDC
• Kafka Connect による運用一元化（スケール、リスタート、オフセット管理）
• キー設計とログコンパクションで後段のアップサート処理に適合

RDB→Debezium→Kafka のデータフロー

Kafka Connect と Debezium コネクタ設定（PostgreSQL例）

Debezium は Kafka Connect の Source コネクタとして稼働します。Connect ワーカー（分散/スタンドアロン）にコネクタ設定を POST し、タスクが DB のログを読み取り Kafka に出力します。シリアライザは Confluent の Schema Registry を併用する Avro/Protobuf/JSON Schema、もしくはプレーン JSON（スキーマなし）から選びます。CCDAK ではキー/バリューのコンバータ設定とスキーマ進化の扱いがよく問われます。

PostgreSQL では論理デコード（pgoutput など）が必要です。publication と replication 権限、スロット管理、WAL 設定（十分な保持）が前提です。トピック名は通常 serverName.schema.table の形式になり、トランザクションメタデータ用の内部トピックも生成されます。

• Connect ワーカー: オフセットは内部トピックに保存（_connect-offsets）。再起動・リバランス時の再処理に備えて重複許容な設計にする。
• コンバータ: key.converter/value.converter を統一。スキーマあり形式を使うと進化管理が容易。
• topic.creation を利用し、パーティション数・コンパクションポリシーを初期化で固定化しておく。

POST /connectors への Debezium PostgreSQL コネクタ設定例

{
  "name": "inventory-postgres-cdc",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "tasks.max": "1",
    "database.hostname": "postgres",
    "database.port": "5432",
    "database.user": "replicator",
    "database.password": "<redacted>",
    "database.dbname": "inventory",
    "plugin.name": "pgoutput",
    "slot.name": "debezium_slot",
    "publication.autocreate.mode": "filtered",
    "tombstones.on.delete": "true",
    "topic.prefix": "dbserver1",
    "snapshot.mode": "initial",
    "schema.include.list": "public",
    "table.include.list": "public.customers,public.orders",
    "max.batch.size": "2048",
    "max.queue.size": "8192",
    "heartbeat.interval.ms": "10000",
    "key.converter": "io.confluent.connect.avro.AvroConverter",
    "key.converter.schema.registry.url": "http://schema-registry:8081",
    "value.converter": "io.confluent.connect.avro.AvroConverter",
    "value.converter.schema.registry.url": "http://schema-registry:8081",
    "schema.history.internal.kafka.bootstrap.servers": "kafka:9092",
    "schema.history.internal.kafka.topic": "schema-changes.inventory",
    "topic.creation.default.replication.factor": "3",
    "topic.creation.default.partitions": "6",
    "topic.creation.default.cleanup.policy": "compact,delete"
  }
}

スキーマとメッセージ設計: キー、エンベロープ、コンパクション

Debezium のメッセージは before/after、op、source、ts_ms、transaction などを含むエンベロープ構造です。アップサートを行う下流（例: ksqlDB のテーブル、JDBC Sink での upsert、DWH の MERGE）に繋ぐ場合、Kafka トピックにログコンパクションを設定し、キーに主キー相当を入れるのが基本です。delete は tombstone メッセージで表現され、コンパクションにより最終状態が保たれます。

スキーマ進化（列追加・NULL 可変化など）は Schema Registry の互換性設定で制御します。後方互換を維持する変更を優先し、互換性違反のデプロイをブロックできるようにします。CCDAK では互換性モード（BACKWARD/FORWARD/FULL）と、レコードキー/バリューで別スキーマが管理される点が頻出です。

• キーは主キーまたは論理キー。キーレスは避ける（パーティション分散と順序の根拠がなくなる）。
• トピックはテーブル単位が基本。高スループットならシャーディングキー再検討（ただし順序要件に注意）。
• Delete の表現: before にのみ値、after は null、op=d。さらに tombstone によりコンパクションを確定。

オフセット、スナップショット、再処理の実務ポイント

Kafka Connect はソースの読み取り位置を内部オフセットトピックに保存します。Debezium はこれを用いて binlog/WAL の位置を管理し、再起動後に同位置から再開します。クラスタ再平衡や障害時には少量の重複が発生しうるため、下流は冪等またはアップサートで受ける設計にします。

スナップショットは初回にテーブル全件を読み取り、その後にログ追随に移行します。大規模テーブルではスナップショットを段階的に行う incremental snapshot 機能の検討、業務時間外の実行、I/O 制御が有効です。スナップショットとログ適用の整合は Debezium がトランザクション境界を考慮して処理します。

• snapshot.mode: initial / initial_only / never（要件とダウンタイム許容度で選択）。
• スナップショット中の更新はログ追随で補完される。トピック側は後行のイベントで最終状態に収束。
• 再処理が必要ならオフセットリセット + 再購読。ただし下流の重複排除を必ず担保。

運用監視とパフォーマンス最適化

監視は三層で行います。DB（WAL/binlog 進行と保持）、Connect/Debezium（タスク状態、キュー長、エラー率、ソース位置）、Kafka（パブリッシュレイテンシ、プロデューサリトライ、ブローカー側のスループットとレプリケーション）。Connect と Debezium は JMX メトリクスを公開するため、アラート閾値を明確化します。

パフォーマンスはバッチとキューのサイズ、ポーリング間隔、トピックのパーティション数、レプリケーション係数でバランスします。過剰なパーティションは順序保証とキー偏りを悪化させるため、主キーの一意性とスループットを基に適正値を見積もります。

• Debezium: max.batch.size、max.queue.size、poll.interval.ms を負荷と遅延でチューニング。
• Kafka: あらかじめ topic.creation.* で compaction とパーティション数を固定化。
• DB: WAL/binlog 保持期間を十分に確保。遅延時にスロット/ポジションが切れないようにする。

CCDAK 対策: よく出る論点と落とし穴

CCDAK では Kafka Connect の基本、シリアライザと Schema Registry、パーティショニング、ログコンパクション、配信保証（少なくとも一度、厳密に一度の違い）が頻出です。Debezium 固有の挙動は直接問われにくいものの、CDC トピックをどう設計し、下流がどう受けるべきかは本質的に Kafka の設計問題です。

特に、キーの設計を問う設問、トピックのクリンナップポリシー選択、再処理時の重複と整合性の扱い、Connect のオフセット管理に関する理解が差になります。

• キーに主キーを入れ、同一キーは同一パーティションに送る。順序はパーティション内でのみ保証。
• ログコンパクションを有効化し、tombstone を理解。delete 伝播とストレージ効率を両立。
• Connect は少なくとも一度配信。下流は冪等またはアップサートで受ける。

問題で確認

よくある質問