業務DBの変更をリアルタイムにデータ基盤へ流したい、と思って候補を調べると、必ず名前が出てくるのがDebeziumです。Red Hat主導のOSSプロジェクトで、CDC（Change Data Capture）の事実上のOSSデファクトになっています。
主要なRDBの全てに対応し、Kafka Connect上で動く構成が標準。マネージドCDC（Fivetran、AWS DMS等）の中身もDebeziumベースであることが多く、OSSの根幹を担っています。基本構造と運用設計を整理します。
対応するDB
| DB | 使うログ |
|---|---|
| MySQL | binlog |
| PostgreSQL | WAL（論理デコーディング） |
| Oracle | LogMiner / XStream |
| SQL Server | SQL Server CDC機能 |
| MongoDB | oplog |
| Cassandra | commit log |
Kafka Connectベースの構成
DebeziumはKafka ConnectのSource Connector集として実装されています。Kafka Connect環境にDebeziumコネクタを設定して動かす、というのが基本の使い方です。
{
"name": "mysql-orders-connector",
"config": {
"connector.class": "io.debezium.connector.mysql.MySqlConnector",
"tasks.max": "1",
"database.hostname": "mysql",
"database.port": "3306",
"database.user": "debezium",
"database.password": "${DEBEZIUM_PASSWORD}",
"database.server.id": "184054",
"topic.prefix": "shop_db",
"database.include.list": "shop",
"table.include.list": "shop.orders,shop.customers",
"schema.history.internal.kafka.bootstrap.servers": "kafka:9092",
"schema.history.internal.kafka.topic": "schema-changes.shop"
}
}これだけで、MySQLの`shop.orders`と`shop.customers`の変更が、`shop_db.shop.orders`と`shop_db.shop.customers`というKafka Topicに流れます。Kafkaの基本はKafka とはを参照してください。
変更イベントの構造
Debeziumが流すイベントの構造は以下の通りです。
{
"before": null,
"after": {
"order_id": 1001,
"customer_id": 42,
"amount": 1500.00,
"ordered_at": "2026-06-13T10:30:00Z"
},
"source": {
"version": "2.5.0",
"connector": "mysql",
"ts_ms": 1718270400000,
"db": "shop",
"table": "orders"
},
"op": "c",
"ts_ms": 1718270400123
}`op`は操作種別（c=create, u=update, d=delete）、`before`と`after`が変更前後の状態です。下流側は`op`を見て処理を分岐します。
運用上のハマりどころ
- 初回スナップショット：既存データを最初に流すため、初回は重い。スナップショットモード（initial / never / incremental）を選ぶ。
- WAL/binlog保持期間：Debeziumがダウンしている間にログが消えると、復旧時に整合性が崩れる。保持期間を十分（数日〜1週間）確保する。
- スキーマ進化：ALTER TABLEがあるとDebeziumは内部スキーマ履歴を更新し、Kafka Connect経由でSchema Registryと連携が必要。
- 大規模テーブル：初回スナップショットが何時間もかかる。Incremental Snapshotsで段階取り込みを選択する。
マネージド代替
- Confluent Cloud：Debezium Connectorをマネージドで提供
- AWS DMS：AWSマネージドCDC（独自実装）
- Fivetran：CDCコネクタの中身がDebeziumベース（一部）
- Striim・HVR：エンタープライズ向け商用CDC
向く・向かない場面
- 向く：複数の下流にイベントを配信、Kafka基盤を持つ、コストを抑えたい、コネクタの自由度を保ちたい
- 向かない：マネージドの楽さ重視（→Fivetran/DMS）、Kafkaを持っていない・運用人員が薄い、シンプルなDB→DWH 1本だけ
まとめ
- DebeziumはOSSログベースCDCのデファクト。主要RDBに広く対応。
- Kafka Connectベースの構成で、設定だけでCDCが動く。
- イベントは`before`/`after`/`op`の構造で、下流が分岐処理しやすい。
- 初回スナップショット・WAL保持・スキーマ進化が運用のハマりどころ。
- マネージドCDCの中身もDebeziumベースが多く、自社運用との比較で判断する。
全体像はCDC実装ガイド、隣接はSnowflake Streams CDC・PostgreSQL論理レプリケーション。Debezium導入の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. Kafka無しでDebeziumを使えますか？
A. Debezium Server（standaloneモード）を使えば、Kafkaを介さずにKinesis、Google Pub/Sub、Pulsar等に直接書き込めます。「DebeziumがKafkaに依存している」のは誤解で、Kafkaは「最も使われる下流」の一つです。Kafka未導入の組織でも、別のメッセージングと組み合わせて利用できます。
Q. PostgreSQLでDebeziumを使うには何が必要？
A. `wal_level = logical`、十分なreplication slots、論理デコーディング用プラグイン（pgoutput等）の設定です。マネージドPostgreSQL（Aurora、Cloud SQL等）でも論理レプリケーション用の設定オプションがあり、有効化すればDebeziumから読めます。詳細はPostgreSQL論理レプリケーションを参照してください。
Q. Debezium運用にどのくらいの人員が要りますか？
A. Kafka Connect環境を持っているなら、Debeziumの追加運用負荷は限定的です。専任で0.2〜0.5名程度。Kafka環境自体を立てるところから始めると、ストリーミング基盤全体で1〜2名規模になります。マネージドKafka（Confluent Cloud等）を使うと、運用負荷は大きく下がります。Kafkaの選定はKafka とはを参照してください。
Q. Debeziumのスキーマ進化はどう動く？
A. Debeziumは内部にスキーマ履歴を保持し、ALTER TABLE時に追跡します。下流のSchema Registry（Avro/Protobuf）と連携することで、ProducerとConsumerの間のスキーマ互換性を組織として強制できます。「後方互換のみ許可」「前方・後方両方互換」など、互換性ポリシーをSchema Registryで設定します。