言われてみたらこういうの欲しいとか思わないですか？え、思う？そうですよね！〜DebeziumとKafkaで実現するフルOSSのChange Data Capture〜（オープンソースカンファレンス2026 Hokkaido）

© 2026 NTT DATA Japan Corporation
2026/06/27(Sat.)
Open Source Conference 2026 Hokkaido
言われてみたらこういうの欲しいとか思わないですか？
え、思う？そうですよね！
〜DebeziumとKafkaで実現するフルOSSのChange Data Capture〜
NTT DATA Japan Corporation
Technology Consulting & Solution Segment, Solution Sector,
Cloud & Data Center Division, OSS Team
Sasaki Toru / 佐々木徹

© 2026 NTT DATA Japan Corporation 2
自己紹介: 佐々木徹 (ささきとおる)
過去の登壇の様子
NTTデータソリューション事業本部クラウド&データセンタ事業部 OSS担当
所属
Strata Data Conference 2018 New York など多数
外部講演
翔泳社
「Apache Spark入門動かして学ぶ最新並列処理基盤フレームワーク」
「Apache Kafka 分散メッセージングシステムの構築と活用」 (ファーストオーサ)
書籍執筆
並列分散処理基盤による大量データ処理(バッチ処理/ストリーム処理)
専門領域
最近はOSSのApache Kafkaやこれを活用したパブリッククラウドサービスの活用が主領域

このセッションでお話しすること
CDC (Change Data Capture)
の基本的なところ
ちょっとだけ
と
も

Section. 1
Change Data Capture (CDC) とは何か？
Debeziumとは何か？

Change Data Capture (CDC) とは
Change Data Capture(CDC)はデータストアに加えられた変更を取得して他のシステムなどに連携するしくみまたは処理です
特にデータベースを対象とすることが多く、データベースで発生した挿入/更新/削除の記録を取得して外部に連携します
データストア
データベース
(RDBMSなど)
他のデータベースへの反映
リアルタイム処理、通知
システム通知
データ分析
RDBMSの場合、
INSERT / UPDATE /
DELETE / TRUNCATEなどの
データの更新が行われるものが
取得対象
変更情報の取得なので参照(SELECT)の操作情報は取得されません
※ SELECTなどまで取得する場合はAuditログなどの活用を考慮することになります
※ SELECTであってもPostgreSQLのpg_logical_emit_messageなど変更が加わる操作であれば取得されるものもあります
Change Data Capture
(CDC)
変更情報の
取得
取得した
変更情報の
連携

Debezium とは
DebeziumはDBMSなどのCDCを実現するためのKafka Connectのプラグイン(※1)の集合です
複数のRDBMSなどのデータソースに対応し、変更情報をリアルタイムに取得してApache Kafkaに連携します
※1: Apache Kafka / Kafka Connectに依存せず単体で動作するDebezium Serverもありますが、本資料では割愛します
データベース
(RDBMSなど)
Kafka Connect
リアルタイム
データ活用
など
MySQL, MariaDB, MongoDB,
Oracle, PostgreSQL, SQLServer, Db2, Cassandra, etc.
Debeziumが
対応している主なDB
上で
実行
Apache Kafka
Debezium
一部
出力を担う
プラグインも
あります
※ JDBC Sink Connector

補足: Apache Kafka とは
Apache Kafkaは複数台のサーバで動作する分散メッセージングシステムです
処理・活用基盤内でのストリームデータ(都度送受信される小さなデータの列)の適切な受け渡しを仲介してくれます
Apache Kafkaの詳細については公式のドキュメントも参考にしてください
https://kafka.apache.org/
データの生成データの活用
Apache
Kafka データの処理
(この流れをデータが生成されたときなど必要な時に都度実施する)
生成される
データを
順次受信
必要な時に
データを後続に
送信(連携)
これらを適切に/安定的に行ってくれることで
都度処理/リアルタイム処理の実現や拡張性の確保が
容易に行えるようになる
ストリーム/リアルタイム処理中のMQ(メッセージングキュー)相当の役割
※かなり乱暴な説明です
…
(通常3台以上)

補足: Kafka Connectとは
Kafka Connectは外部システムとKafkaの間でストリーミングデータを連携するためのFW/実行基盤です
Kafkaと連携してサーバ複数台でクラスタを形成し、コネクタ(プラグイン)の追加で様々な種類の外部システムに対応します
データの生成データの活用
Kafka Connect
クラスタの形成など
(依存)
ストリームデータとして
取得・読取
ストリームデータから
出力・書込
Kafkaへ送信 Kafkaへ受信
…
…
(通常2台以上)
(通常3台以上)
Kafka Connectにはいまのところ
それ単体のロゴがありません
Source Connector
取得元の方式に
対応するコネクタを
追加して実行
Sink Connector
出力先の方式に
対応するコネクタを
追加して実行
登録・実行登録・実行

DebeziumとKafkaを利用したCDCの全体像
KafkaとDebeziumを組み合わせてCDCを実現する際の典型的な構成は以下の通りです
KafkaやKafka Connectのサーバ、Debeziumのコネクタなどは必要に応じて増やすことで拡張することができます
Kafkaクラスタ
(一般にサーバ3台〜)
Kafka Connectクラスタ
Topic (※1)
変更情報を取得する
データベース
RDBMS
など
RDBMS
など
Topic (※1)
Topic (※1)
※1: Kafkaでメッセージ(データ)を格納する論理的な単位で、MQのTopicと役割は近くデータの種類ごとなどに区分して格納します
変更情報の
連携先
変更情報の
取得
変更情報の
連携
… …
Debezium
コネクタ
Debezium
コネクタ

Change Data Captureの実現方式
Change Data Captureの実現方式にはいくつか種類があり、主に以下ものがあります
最近ではLog-basedのものが主流になってきており、多くのツールなどがこの方式を採用しています
実現方式変更情報の取得方法特徴など
Query-based
CDC
各レコードに設けられた最終更新日時のカラムなどを
参考に前回取得時からの変更を取得する
SQLクエリを実行
実装が容易な一方でテーブル構造や処理に制約が生じたり、
物理削除されたレコードの差分の取得漏れが発生したりする
Trigger-based
CDC
対象テーブルにトリガを設定、
その処理内で変更情報履歴を別テーブルなどに記録し、
変更情報履歴の差分を取得
業務データの更新時に変更情報履歴のテーブルも一緒に更新し、
特に業務データの更新量が大きい場合処理負荷が高くなりやすく、
Log-basedと比較して取得までのレイテンシが高くなりやすい
Log-based
CDC
トランザクションログを読み込み、
変更情報を都度取得
低遅延で取得漏れが発生しにくく、最近の主流の方式
DBMSごとにトランザクションログ取得の方式が異なる(※1)ため、
DBMSが変わった際の特性の違いなどには注意が必要
DebeziumもPostgreSQLやOracle向けのコネクタなどでこの方式を採用しています
※1: PostgreSQLではLogical Replication、OracleではRedo Logなど

たまにある疑問: CDCとETLはどう違う？
ETL (Extract, Transform, Load) はデータ抽出・加工・出力とデータの流れの一連を表すものです
CDC (Change Data Capture)はDBMSなどからの変更データの抽出の処理/方式でそれぞれが指す範囲や粒度が違います
データストアなど
（ソース側)
データの記録/活用
(ターゲット側)
データの処理
抽出
(Extract)
加工
(Transform)
格納
(Load)
この一連の処理
全てでETL
データストア(特にDBMS)からの
抽出方式の1つがCDC
※ ETLの指す抽出(Extract)はCDCに限定されず、
全量取得や指定条件での取得による抽出なども含むより広いものです
前述のDebezium + Kafkaで構成される処理範囲はCDCですが、
Kafkaにデータ加工を行う処理エンジンやKafka Connectによる出力を組み合わせることでETL全体を構成することができます

Section. 2
DebeziumによるCDCの動作の流れ
-PostgreSQLコネクタを例に-
PostgreSQL以外の他のRDBMSのコネクタでも概ね同じ概念・動作になっていますが、
利用されるDBMSの機能などはコネクタ(対象とするDBMS)ごとに異なります

Kafkaクラスタ
Topic (※1)
データベース
RDBMS
など
RDBMS
など
Topic (※1)
Topic (※1)
変更情報の
連携先
… …
Debezium
コネクタ
Debezium
コネクタ
DebeziumによるCDCの全体像 (構成は再掲)
Kafka ConnectでDebeziumのPostgreSQLコネクタによるCDCを利用する流れ
前述の通り、DebeziumはKafka Connect上でコネクタとして動作します
ここではDebeziumのPostgreSQLコネクタを実行する流れを順を追って簡単に見ていきますご紹介内容
① コネクタ(設定)の
投入
② 実行の流れ
③ 差分取得のしくみ
④ WAL情報取得後の
内部処理
⑤ 出力される
データ(メッセージ)

Kafkaクラスタ
Topic (※1)
データベース
RDBMS
など
RDBMS
など
Topic (※1)
Topic (※1)
変更情報の
連携先
… …
Debezium
コネクタ
Debezium
コネクタ
Kafka ConnectにDebeziumのコネクタを作成
DebeziumのCDCを実行するにはKafka Connectの実行単位であるコネクタを作成します
コネクタ作成時に設定として変更情報の取得対象とするテーブルやトランザクション情報の取得の有無などを指定します
Kafka ConnectのREST APIで設定を添えてコネクタを作成
$ curl -X POST -d @config.json http://cnct:8083/connectors
PostgreSQLのコネクタ作成時の主な設定
項目設定する値など
database.hostname ホスト名
database port ポート番号
database.dbname データベース名
plugin.name 論理デコードプラグイン名
slot.name Replication Slot名
publication.name Publication名
table.include.list 取得対象とするテーブルリスト
slot.failover Failover対応のReplication Slotを作成

Debeziumの実行の流れ
Debeziumの実行は ①スナップショット、 ②ストリーミングの2つのフェーズに分かれています
これらのフェーズは設定および状況に応じて必要なものが実行され、必要なデータを漏れなく取得できるようになっています
① スナップショットフェーズ
② ストリーミングフェーズ
取得対象とするテーブルに対して、実行時点のすべてのレコードを取得
トランザクションログを読み込んで取得対象とするテーブルの変更情報を継続的に取得
完了後に移行
PostgreSQLコネクタの場合
PostgreSQLコネクタの場合
対象の各テーブルにSELECT文を順に実行して取得
Logical Replicationを利用してWAL情報を順次取得
設定によってどちらかだけ、
または両方の実行を
指定することができる
DB間のデータ同期を目的とする場合は両方実行、
定期的な断面バックアップを取得する目的の場合は
スナップショットのみの実行など
コネクタの再起動時など
途中から再開できる場合は
スナップショットを省略できる場合もある
PostgreSQLコネクタではReplication Slotと
Kafka Connectの管理機構を利用して
取得したWALの位置を管理しており、
これらの記録からResumeが可能と判断される場合が該当

Kafkaクラスタ
Topic (※1)
データベース
RDBMS
など
RDBMS
など
Topic (※1)
Topic (※1)
変更情報の
連携先
… …
Debezium
コネクタ
Debezium
コネクタ
DebeziumのPostgreSQLコネクタの差分取得のしくみ
DebeziumのPostgreSQLコネクタの差分取得にはLogical Replicationのしくみが利用されています
WALのデコーディングにはpgoutputが利用できるようになっています
PostgreSQLのJDBCで
Logical Replication Streamの接続
(Connection.replicationStream().logical())
コネクタ作成時の設定に指定した
PublicationとReplication Slotを作成、
変更情報を受け取るたびにReplication Slotを更新
※ 処理完了のWALの管理にはPostgreSQLのReplication Slotと
Kafka ConnectのOffsetCommitを併用しています

Kafkaクラスタ
Topic (※1)
データベース
RDBMS
など
RDBMS
など
Topic (※1)
Topic (※1)
変更情報の
連携先
… …
Debezium
コネクタ
Debezium
コネクタ
DebeziumのPostgreSQLコネクタによるWAL情報の処理/加工
PostgreSQLから受信したWAL情報はKafka Connect上で処理/加工されてKafkaに連携されます
途中で任意の簡単な加工処理を挟むことができ、必要に応じて実装/設定を行います
DebeziumのPostgreSQLコネクタの処理の流れ
メッセージ送信
Converter
Transformation
WAL情報のデコード
LogicalReplicationの受信
OffsetCommit
PostgreSQL
から
Kafkaクラスタへ
Kafkaクラスタと
PostgreSQL
へ
pgoutoutなど
デコーディングプラグインに
合わせて解釈
受信データの
任意の加工処理 (※1)
JSONなど出力用の
フォーマットへ変換
処理済みのWALの情報を
Kafka Connectへの記録と
Replication Slotへの更新
※毎回必ずではなく一定周期などで実施
※1: 共通で実施する処理を実行できますが、軽微な処理にとどめ、複雑な業務処理は実施しないことが推奨されます

Kafkaクラスタ
Topic (※1)
データベース
RDBMS
など
RDBMS
など
Topic (※1)
Topic (※1)
変更情報の
連携先
… …
Debezium
コネクタ
Debezium
コネクタ
DebeziumのPostgreSQLコネクタによる差分情報の出力
WAL情報として取得され、Kafka Connectのコネクタ上で加工されたデータは差分情報としてKafkaクラスタに出力されます
差分情報は主に以下の情報を持ち、この情報を利用して連携先でデータ同期など目的の処理を行います
取得元のテーブル、トランザクション情報、論理メッセージ(※1)
ごとに分類されてTopicに出力される
項目値の意味など
op 処理種別 (挿入/更新/削除など)
ts_ms, ts_us, ts_ns タイムスタンプ
before 変更前のレコード(※2)
after 変更後のレコード (※3)
source.txId 対象の変更のトランザクションID
source.lsn 対象の変更のWALのLSN
DebeziumのPostgreSQLコネクタから出力される
差分情報に含まれる主な項目
※1: pg_logical_emit_messageでWALに記録されたメッセージのことです
※2: 挿入の際はnullで、情報量はREPLICA IDENTITYの設定に依存します
※3: 削除の際はnullになります

補足: JSONフォーマットで出力された差分情報の例
{
"before": null,
"after": {
"id1": 14,
"id2": 114,
"text": "hoge"
},
"source": {
"version": "3.1.3.Final",
"connector": "postgresql",
"name": "debezium1",
"ts_ms": 1753883129391,
"snapshot": "false",
"db": "postgres",
"sequence": "["22355936","22357640"]",
"ts_us": 1753883129391521,
"ts_ns": 1753883129391521000,
"schema": "public",
"table": "hoge",
"txId": 770,
"lsn": 22357640,
"xmin": null
},
"transaction": null,
"op": "c",
"ts_ms": 1753883129584,
"ts_us": 1753883129584540,
"ts_ns": 1753883129584540700
}
INSERTの例
{
"op": "m",
"ts_ms": 1753883783818,
"source": {
"version": "3.1.3.Final",
"connector": "postgresql",
"name": "debezium1",
"ts_ms": 1753883129391,
"snapshot": "false",
"db": "postgres",
"sequence": "["22359496","22359496"]",
"ts_us": 1753883129391521,
"ts_ns": 1753883129391521000,
"schema": "",
"table": "",
"txId": null,
"lsn": 22359496,
"xmin": null
},
"transaction": null,
"message": {
"prefix": ”hoge",
"content": "ZnVnYWFhYWFhYWE="
}
}
論理メッセージの例
{
"status": "BEGIN",
"id": "779:22376928",
"event_count": null,
"data_collections": null,
"ts_ms": 1753887019306
}
{
"status": "END",
"id": "779:22379104",
"event_count": 2,
"data_collections": [
{
"data_collection": "public.hoge",
"event_count": 2
}
],
"ts_ms": 1753887019306
}
トランザクション情報の例
INSERTを意味する “c”
(CREATE)
新たに作成された
レコードの値
論理メッセージの内容
(ContentはBase64)
論理メッセージを
意味する “m”
トランザクションの
COMMIT情報
トランザクション中の
イベント数情報
※ 受信対象に設定して受信したイベント数で、
トランザクション中にPostgreSQL上で
処理されたすべての操作数ではない

Section. 3
DebeziumによるCDCの使いどころ

代表的なDebeziumが利用される処理パターン
Debeziumが利用される処理パターンうち、代表的なものは以下の通りです
特にDebeziumはKafkaへデータを連携するため、Kafkaを活かしたリアルタイム性・大量データ処理が得意です
ユースケース模式図代表的な適用業務備考
対象DBの
変更情報を
リアルタイムに取得し、
リアルタイムに処理する
DBの更新情報を
利用した
リアルタイム処理
Debeziumで当初想定されたユースケース
Kafkaに入れられたDBの更新情報にストリーム処理を行うもの
DB間の
継続的な
レプリケーション
(非同期)
処理のオフロードを
目的とした
参照DBの作成
DBに備わる機能やレプリケーションツールと重複するユースケース
◼ 異種DB間でのレプリケーション / DB以外への出力
◼ データの加工・集計などの処理を途中で行うなど単純なレプリケーションでない
◼ 複数のDBにレプリケーションを行う
◼ レプリケーション先への反映がリアルタイムではない
◼ 上記のリアルタイム処理と両方行う
といったケースではDebeziumでの対応にメリットある場合がある
DB間の
特定断面での
データ複製
新たなDBの移行、
特定タイミングのDBの
スナップショットの作成
DBのダンプ/レストアツールやレプリケーションツールと重複するユースケース
◼ 異種DB間でのデータ移行
◼ DB以外へのスナップショットの出力 (e.g. S3)
◼ 複数のDBやそのほかの出力先に出力する
◼ 保存前にデータのフィルタリングや加工を行う場合
と言ったケースではDebeziumでの対応にメリットがある場合がある
ストリーム
処理
継続的に実施
1回限り実施

Case1: データベースの変更情報のリアルタイム処理
データベースの変更情報をリアルタイムに取得し、変更情報を利用した処理を都度行います
ストリーム処理 / リアルタイム処理の処理エンジンの多くがKafkaに対応しており、それらを利用して処理を実現できます
データベースデータの活用
Apache
Kafka
データの
リアルタイム処理
Debezium
リアルタイム処理にはKafkaのエコシステムが
利用でき、多くの選択肢が存在する
代表的なリアルタイム処理エンジン
低遅延のLog-Basedの
CDCであるDebeziumと
Kafkaの組み合わせで
リアルタイム処理が得意
Apache
Flink
Kafka
Streams

Case1: データベースの変更情報のリアルタイム取得/処理具体例
データベースに記録されるユーザのログイン情報や各種操作記録、取引記録などをリアルタイムに取得し、
内容を確認する処理を随時行って、不正などが疑われる場合は別システムに連携したり、通知を行うなどを行います
具体例: ユーザ操作や各種取引の異常(不正)検知
データベース
不正判断結果の
記録・分析・アラート
Apache
Kafka
ユーザ操作・取引の
不正判断処理
Debezium
ユーザが操作する
システムなど
ユーザ操作・取引情報の
記録
(業務処理の一環)
データベースの
関連テーブルの変更情報
の取得
CDCの取得結果を
リアルタイムに処理

Case2: データベース間・他システムへの変更情報の連携・反映
データベースの変更情報をリアルタイムに取得し、別のデータベースやシステムなどに都度反映します
単純なデータ同期のほか、途中でリアルタイムにデータの加工などを行いながら反映していくこともできます
データベース
(ソース側)
Apache
Kafka
データベース
(ターゲット側)
データの加工処理
(加工せずそのまま反映)
Debezium

Case2: データベース間・他システムへの変更情報の連携・反映
具体例: 基幹系・勘定系などの既存のデータベースからの一部処理のオフロード
基幹系・勘定系の
データベース
Apache
Kafka そのまま、または
データ加工しながら連携
参照用など
オフロード処理の
データベース
基幹系・勘定系などから必要なデータを別のデータベースなどに連携し、参照など一部の処理をオフロードします
これにより基幹系・勘定系の負荷の軽減を図ったり、利用者や連携システムの増加へ対応できるようにします
基幹系・勘定系に
関わる基幹業務処理での
更新など
基幹処理以外の
ユーザ向けアプリの
データ参照など
基幹処理以外をオフロードすることで
基幹系・勘定系DBの負荷を軽減
Debezium

想定質問: DBMSに備わっているレプリケーション機能でいいのでは？
A. その通りです
⚫ DBMS単体 / 標準機能のみで実現できる処理はそちらを利用するのが良いと思います
⚫ 単体 / 標準機能では実現が難しい処理やそうした処理を将来的に入れる余地の確保などでCDC利用を検討してください
単体 / 標準機能では実現が難しい処理の例
⚫ 参照用のデータベースへの反映時にデータ加工も同時に行う
⚫ 異種データベース間でのデータ同期 (e.g. PostgreSQL から Oracle)
⚫ 他のリアルタイム処理との併用

Case3: データベースの特定断面でのデータ複製
Debeziumのスナップショットを利用し、処理時刻での対象テーブルの全量データを取得します
スナップショットの取得もKafkaへ出力されるため、取得途中でも順次他システム・他DCなどへの転送や処理が行えます
データベース
(ソース側)
Apache
Kafka
ターゲット
(同一サイト内)
(同じDC内など)
ターゲット
(遠隔サイト内)
(遠隔のDCへの転送など)
遠隔
NW
Debezium

Case3: データベースの特定断面でのデータ複製具体例
別のDCなど遠隔の拠点間でNW帯域が限られる、不安定な環境に存在するデータベース間のデータ同期に利用します
Kafkaの送達保証(※1)を活かして、少量ずつデータを送信することで安定的な連携を行うことができます
具体例: 遠隔の拠点に存在するデータベースへのデータ同期・複製
※1: Kafkaが標準で提供するデータの送受信においてデータの重複や欠損(データロスト)を防ぐための仕組みや機構
データベース
(ソース側)
Apache
Kafka
ターゲット
(同一サイト内)
(同じDC内など)
遠隔
NW
やや不安定なNWでもKafkaの送達保証で確実にデータが送信でき、
帯域が細い場合でもKafkaのサポートで少量を少しずつ送信することができる
Debezium

Section. 4
クロージング

本セッションでお話ししたこと
Kafka + Debeziumの構成で実現するCDCについて、処理の流れや使いどころを紹介しました
CDC/Debeziumはそれ自体の機能はシンプルですが、既存/新規システムの活用幅を広げるものとしてぜひ活用してください

本資料に掲載されている商品名、会社名、サービス名は各社の商標または登録商標です

言われてみたらこういうの欲しいとか思わないですか？え、思う？そうですよね！〜DebeziumとKafkaで実現するフルOSSのChange Data Capture〜（オープンソースカンファレンス2026 Hokkaido）

More Related Content

More from NTT DATA Technology & Innovation