Debeziumとは？コネクタ設定と3つの配置形態を実装視点で解説【2026年版】

Debeziumは、MySQLのbinlogやPostgreSQLの論理レプリケーションストリームを読み、テーブルの変更をイベントとして送り出すKafka Connect向けのソースコネクタ群です。2026年8月時点の最新安定版は2026年7月1日公開の3.6.0.Finalで、ソースコネクタは13種、送り先はKafkaに限らずAmazon KinesisやGoogle Cloud Pub/Subまで広がりました。この記事では設定JSONの必須プロパティ、変更イベントの構造、3つの配置形態の選び分け、採用を見送る条件を扱います。仕組み自体の3方式比較やデータベース側の有効化手順はCDC（Change Data Capture）とはの解説記事に譲りました。

まとめ｜Debezium採用の可否を分ける運用体制と3つの前提条件

Debeziumで成果が出るのは、次の3つが同時に成り立つ場合に限られます。対象テーブルが十数本以上あり、秒から分単位の反映遅延に業務上の意味があること。JVMアプリケーションの常時稼働を監視・復旧できる体制があること。データベース側でレプリケーション権限とログ保持期間を自分たちで変更できることです。3つ目が握れていない案件では、設定をどれだけ詰めても動きません。

配置形態の選択は、Kafkaクラスタを持つかどうかでほぼ決まります。すでにKafkaがあるならKafka Connectの分散モードが公式の推奨で、無いならDebezium Serverを単体プロセスとして立てKinesisやPub/Subへ直接流す構成が現実的です。1データベースを1アプリで見るだけなら組み込みエンジンでブローカーを省けます。

逆に、対象テーブルが数本で日次バッチの遅延で足りる案件では運用コストが釣り合いません。そこはマネージドのELTサービスやAWS Database Migration ServiceのCDCモードへ寄せた方が、総所有コストは下がります。判断の分岐点は第7章で条件付きに示しました。

Kafka Connectプラグイン集合としてのDebeziumの構成要素

Debeziumという名前は単一のミドルウェアではなく、Kafka Connectというフレームワークのプラグインとして動く一群のコネクタと周辺ツールの総称です。

ソースコネクタ13種とトランザクションログ読み出しの担当範囲

3.6系のソースコネクタは、MySQL・MariaDB・MongoDB・PostgreSQL・Oracle・SQL Server・Db2・Cassandra・Vitess・Spanner・Informix・CockroachDB・YashanDBの13種です。読み出し方式はデータベースごとに異なり、MySQLコネクタはbinlogアクセス用のクライアントライブラリを使い、PostgreSQLコネクタは論理レプリケーションストリームを購読します。書き戻し用のシンクコネクタはJDBCとMongoDB Sinkの2種のみです。

設定で最初に書くのは実装クラス名です。PostgreSQLならio.debezium.connector.postgresql.PostgresConnector、MySQLならio.debezium.connector.mysql.MySqlConnectorを指定します。トランザクションログの有効化はデータベース側の作業で、Debeziumの守備範囲外です。その前提条件はログベースCDCの設定と権限をまとめた記事で確認してください。

Apache 2.0ライセンスとRed Hat商用サポートの提供境界

DebeziumはApache License 2.0で公開されており、商用利用にライセンス費用は発生しません。ただしコミュニティ版に付いてくるのは、ドキュメントとチャット・メーリングリストでの助け合いだけです。SLA付きのサポートが要る案件では、Red Hatがビルドして提供するディストリビューションを選びます。無償だから安いという話にはならず、コストはコネクタの監視と復旧を誰が担うかへ移動します。

Kafkaを前提としない配置も含めたDebezium3形態の選び分け

公式アーキテクチャ文書は「Kafkaへ変更イベントを流すのであればKafka Connect経由でのコネクタ配備を推奨する」と明記しています。判断が要るのはKafkaが無い環境です。

Kafka Connect分散モードで動かす標準構成の運用単位

標準構成では、Kafkaブローカーとは別サービスとしてKafka Connectのワーカーを立て、そこへDebeziumのコネクタJARを配置します。運用単位はワーカークラスタで、コネクタはタスクへ分割されワーカー間に割り当てられます。既定では1テーブルの変更が1つのKafkaトピックへ書かれ、トピック名はテーブル名に対応する形です。

ブローカーとワーカーの両方を自前で持つと監視対象が増えます。AWSならAmazon MSKでKafkaクラスタを管理する構成と組み合わせ、Connectワーカーだけを自前運用する形が扱いやすい落としどころです。

Debezium ServerとEmbedded Engineが向く非Kafka構成

Debezium Serverは、コネクタとシンクを1つのJVMプロセスに閉じ込めた単体アプリケーションです。配布物を展開するとdebezium-serverディレクトリができ、run.shで起動し、シンクはdebezium.sink.typeで選びます。3.6系ではKinesis・Google Cloud Pub/Sub・Pulsar・Azure Event Hubs・Redis Stream・Apache Icebergなど20種以上が用意され、新たにAmazon SNSシンクも加わりました。

もう1つの選択肢が組み込みエンジンです。Debezium Engineのライブラリを自作アプリの依存に加え、変更イベントをコールバックで受け取ります。ブローカーもConnectワーカーも要らない代わりに、再開位置の保持や並列化は自分で書くことになります。3.6系ではQuarkus向けの拡張が入りました。

Kafkaの有無と運用単位から3つの配置形態を比べた選び分け

3形態を前提基盤と送り先、向く場面で並べます。上から順に検討し、Kafkaを持てない制約が出た時点で下へ降りる進め方が早いです。

PostgreSQLとMySQLで書くコネクタ設定JSONの必須項目

接続情報以外で結果を左右するのは、論理デコーディングの選択とスキーマ履歴の置き場所です。

PostgreSQLコネクタでpgoutputとpublicationを決める設定

PostgreSQLではplugin.nameの既定値がdecoderbufsで、これはサーバへの追加インストールが必要な外部プラグインです。PostgreSQL 10以降に標準搭載されたpgoutputを指定すれば追加インストールなしで動くため、新規案件はここを明示的に切り替えるところから始めます。3.6系のTested Versionsが対応するのはPostgreSQL 14から18、ドライバは42.7.7です。

次に効くのがslot.nameとpublication.nameです。既定値はそれぞれdebeziumとdbz_publicationで、いずれも起動時に存在しなければコネクタが自動で作ります。ただし自動作成されたパブリケーションは全テーブルを含み、そのうえでDebezium側のinclude設定による絞り込みがかかります。テーブルを限定したいならpublication.autocreate.modeをfilteredかdisabledにしてください。

MySQLコネクタでserver.idとスキーマ履歴を用意する必須設定

MySQLコネクタはレプリカとして振る舞うため、クラスタ内で衝突しないdatabase.server.idを割り当てます。他のレプリカと重複させると接続が切られ続けるので、番号の払い出しルールは最初に決めておくと後が楽です。対応するのは8.0系・8.4系・9.0・9.1、ドライバは9.1.0です。

忘れやすいのがスキーマ履歴です。MySQLコネクタは過去のDDLを再現するために履歴を保持し、schema.history.internal.kafka.topicで保存先を指定します。このトピックを消すとコネクタは再開できません。なお2.7系でMariaDBコネクタが分離されたため、MariaDBには専用コネクタを選びます。

REST API経由でコネクタを登録し稼働状態を確かめる手順

登録から確認までは4手です。設定変更のたびに全体を再投入するため、JSONはリポジトリで管理してください。

1. Connectワーカーへコネクタ設定JSONをPOSTし、コネクタを作成する
2. コネクタとタスクの状態を取得し、いずれもRUNNINGになっていることを確かめる
3. 対象テーブルへテスト用のINSERTとDELETEを流し、想定したトピックにイベントが出るか見る
4. PostgreSQLならレプリケーションスロットの消費位置が進んでいるかを確認する

タスクがFAILEDで止まったときは、状態取得のレスポンスにスタックトレースが載ります。原因は設定の綴り誤りと権限不足が大半です。

変更イベントのペイロード構造とSMTで整える下流アプリ向けの形式

Debeziumが出すイベントは、下流のアプリケーションがそのまま扱える形ではありません。

opとbefore・after・sourceで構成される変更イベントの読み方

バリューのペイロードには、操作種別を示すop、変更前の行を持つbefore、変更後の行を持つafter、読み出し元の位置情報を持つsourceが入ります。opの値はINSERTがc、UPDATEがu、DELETEがd、スナップショット由来の読み出しがrです。イベント生成時刻はts_msで取れます。

DELETEの扱いには癖があります。tombstones.on.deleteの既定値はtrueで、削除イベントの直後に同じキーでバリューがnullのトゥームストーンイベントが1件追加されます。Kafkaのログコンパクションで当該キーを消せるようにする仕組みです。下流がこのnullを想定していないとNullPointerExceptionで落ちるため、既定値のままかfalseかを受け側と合わせて決めてください。

ExtractNewRecordStateで平坦化するときの削除イベントの扱い

多くの下流アプリケーションが欲しいのは、入れ子構造ではなく変更後の行そのものです。ここで使うのが新レコード状態抽出の変換で、afterの中身をトップレベルへ引き上げて平坦にします。JDBCシンクへ渡す構成ではほぼ必須の前処理です。

落とし穴は削除です。平坦化するとDELETEイベントのafterがnullのため、既定の挙動では該当レコードが下流へ届きません。削除を伝えたいなら、削除の扱いを制御するオプションでトゥームストーンを残すか、操作種別をフィールドへ持ち上げる設定を足します。受け側を冪等に組む前提はデータパイプラインの冪等性設計をまとめた記事で整理しました。

ルーティング系SMTと3.6系の新しい変換で下流を単純化する範囲

変換はKafka Connectの単一メッセージ変換として提供され、コネクタ設定の中に並べて書きます。上の2つで済む案件が多く、下へ行くほど適用場面が限定されます。

• 新レコード状態抽出: afterを平坦化して下流へ渡す、最も使用頻度が高い変換
• トピックルーティング: 論理テーブル名でトピックを束ね、シャード分割されたテーブルを1トピックへ集約する
• メッセージフィルタリング: 式で不要なイベントを落とし、下流の処理量を削る
• 内容ベースルーティング: ペイロードの値を見て送り先トピックを振り分ける
• Docling変換: 3.6系で追加された、文書を構造化して変更イベントに付与する変換

イベント単位で完結する処理はコネクタ側が向き、複数イベントの結合や集計は下流のストリーム処理へ出す切り分けが素直です。

3.6系と3.7系の現在地と対応データベースのバージョン範囲

リリース間隔が短いため、系列の位置づけを把握しないままバージョンを選ぶと開発中の系列を本番に入れる事故が起きます。

2026年7月1日に公開された3.6系の変更点と3.7系の開発状況

公式のリリース一覧では、3.6が最新安定版として2026年7月1日、その前の3.5が2026年6月2日に公開されています。3.6系の変更で実装に響くのは、リレーショナルスキーマ管理を差し替え可能にしてメモリ使用量を削れるようにした点と、テーブル履歴とスキーマをRocksDBでヒープ外に置ける点です。Connectワーカーのヒープが逼迫していた環境に効きます。

一方の3.7は2026年7月30日時点でdevelopment扱いで、Ingresコネクタのインキュベーティング追加などが並びます。本番投入は安定版の公開を待ち、いま設計するなら3.6系を基準に据える形が無理のない選択です。

Java17と21の使い分けとデータベース側の対応バージョン範囲

実行環境の下限は、コネクタとその他のコンポーネントで分かれています。Debezium Serverや組み込みエンジンを選ぶ場合はJava 21が必要で、既存アプリのランタイムが17止まりだと配置形態の選択が制約されます。Java 11で動かせるのは2.7系までです。

PostgreSQL 18への対応は3.4系（2026年3月30日）で入りました。データベースを先に上げると、対応系列が出るまで動かせない期間が生まれます。バージョンアップ計画とコネクタの対応表は同じ資料で並べて管理してください。

Debeziumを採用しない方がよい条件とマネージド移行の線引き

Debeziumは変更を逃さず低遅延で拾う目的に対しては強力ですが、その強さは常時稼働するJVMプロセス群を抱える対価と引き換えです。対価に見合わない案件では入れない方がよく、それは珍しいケースではありません。

対象テーブルが数本で日次の遅延で足る案件でDebeziumが過剰になる線

対象テーブルが5本以下で、下流が日次のレポートや夜間バッチだけという構成にDebeziumを入れるのは過剰です。得られるのは「削除も取りこぼさない」という一点で、代わりにワーカーの監視、スロット残量の監視、バージョン追随という3系統の運用が増えます。日次のフル洗い替えで済むならSQLとスケジューラだけの方が壊れにくいです。

もう1つ見送るべきなのが、データベースの設定変更権限を持てない案件です。レプリケーション権限の付与やログ形式の変更ができない環境では、ログベースの読み出し自体が成立しません。契約や運用分担の話なので、後から技術では埋められません。

マネージドELTやDMSへ寄せる判断の分岐点と移行後に残る作業

分岐点は、専任で面倒を見られる人がいるかどうかです。いないならマネージドへ寄せます。移行先は用途で分かれ、分析用途の取り込みならマネージドのELTサービス、データベース間の移行や継続同期ならAWS Database Migration ServiceのCDCモードが素直な選択になります。OSSのまま運用負荷を下げる中間案としては、AirbyteでOSS版ELTをセルフホストする構成も候補に入るでしょう。

ただし、マネージドへ寄せても消えない作業が2つ残ります。下流を冪等に組むことと、スキーマ変更を受け止める互換方針を決めることです。ここを設計しないまま製品を替えると、同じ障害が別の顔で再発します。取り込み層から下流までの設計と構築を外部に任せるなら、データ分析基盤構築・MLOps構築支援のように設計から運用までを一括で引き受ける体制と組む選択肢もあります。

スロット滞留と内部トピック欠損というDebezium運用の落とし穴

本番で止まる原因は、コネクタのロジックより周辺の状態管理に集まります。

heartbeat設定でレプリケーションスロット滞留を避ける勘所

PostgreSQLで最も多い障害は、レプリケーションスロットが消費されずWALが積み上がってディスクを埋める形です。更新の少ないテーブルだけを対象にしていると、Debeziumがイベントを出さないためスロットの確認位置が進まず、同じインスタンス上の他のデータベースで起きた更新分のWALまで保持され続けます。

対処はheartbeat.interval.msを設定して定期的にハートビートを送ることです。公式ドキュメントの例では600000ミリ秒、つまり10分間隔が挙げられています。それでも位置が進まない構成ではheartbeat.action.queryに軽い更新クエリを指定し、確認位置を前進させます。スロットの滞留量は監視項目に入れてください。

Kafka Connect内部トピックの欠損で全件再取得に陥る事故の予防

Kafka Connectは、コネクタの再開位置を内部のオフセットトピックに、設定を構成トピックに、状態を状態トピックに保存します。この3つはワーカーの外にある永続状態で、クラスタを作り直すときに一緒に消す事故が起きやすい箇所です。オフセットが消えるとコネクタは再開位置を失い、初期スナップショットからやり直します。

予防策は2つです。内部トピックの名前を環境ごとに明示指定して削除対象の判断がつくようにすること。もう1つは、Kafkaクラスタの入れ替え手順書に内部トピックの退避と復元を1工程として書くことです。MySQLのスキーマ履歴トピックも同じ性質なのでまとめて扱ってください。

よくある質問

Debeziumの導入検討で実際に寄せられる質問のうち、公式ドキュメントの記述に照らして答えられるものを5つ挙げます。

Debeziumの読み方は何ですか？

「デビージアム」または「デベジウム」と読まれることが多く、日本語表記も定まっていません。名称はデータベース（DB）とラテン語風の接尾辞を組み合わせた造語で、公式に発音の規定はありません。社内資料では英字表記のDebeziumで統一しておくと引き継ぎで混乱しにくくなります。

Debeziumは無料で商用利用できますか？

できます。ライセンスはApache License 2.0で、商用利用や改変、再配布に費用は発生しません。ただし無償で提供されるのはソフトウェアとドキュメント、コミュニティでの助け合いまでです。SLA付きの窓口が必要ならRed Hatの商用ディストリビューションを検討してください。

1つのコネクタで複数のデータベースをまとめられますか？

できません。コネクタは1つのデータベースサーバに1つ割り当てる設計で、対象を増やすならコネクタを増やします。PostgreSQLではレプリケーションスロットとパブリケーションもデータベース単位のため、コネクタごとに別の名前が必要です。

Debeziumで取得したイベントをそのままデータベースへ書き戻せますか？

JDBCシンクコネクタを使えば書き戻せます。ただし、そのままでは入れ子構造のペイロードが渡るため、新レコード状態抽出の変換で平坦化する前処理が実質必須です。削除イベントの扱いも設定で明示してください。既定の平坦化では削除が下流に届かず、書き戻し先に不要な行が残り続けます。

Debeziumのバージョンアップはどれくらいの頻度で必要ですか？

安定版の公開間隔は短く、2026年でみると3.4が3月30日、3.5が6月2日、3.6が7月1日です。すべてを追う必要はありませんが、対応データベースのバージョン範囲が系列ごとに変わるため、データベース側のバージョンアップ計画と同じ周期で見直す運用が現実的です。PostgreSQL 18対応が3.4系で入ったように、上げたい時期から逆算して系列を選びます。

関連記事

• CDC（Change Data Capture）とは？3方式の仕組み・実装設定と採用判断を実装者目線で解説：前提となる変更データキャプチャの方式比較とデータベース側の設定を扱っています。
• Amazon MSK（Managed Streaming for Apache Kafka）とは？仕組み・料金・使い方とKafka自前運用との違いを解説：土台となるKafkaクラスタをマネージドで持つ選択肢を整理しています。
• Airbyteとは？OSS版ELTの仕組み・セルフホスト構成とFivetranとの違いを実装視点で解説【2026年版】：運用負荷を下げたいときの代替案です。
• データパイプラインとは？種類・構成要素と冪等性から考える設計判断を解説【2026年版】：受け側を冪等に組む設計の前提です。
• データ分析基盤の構築とは？5層アーキテクチャとBigQuery実装手順を技術視点で解説：取り込み層を含む基盤全体の並びです。