Skip to content
Published on

CDC とデータ統合 2026 完全ガイド — Debezium 3 · Estuary · Flink CDC · Airbyte · Fivetran · Sling · Hightouch · Census · Sequin 徹底比較

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — 「うちのデータ、結局どこで合流するの?」

2026 年、あるデータプラットフォームチームの会議。

PM: 「新モデルの学習用に決済データをリアルタイムで欲しい。」 DBA: 「またですか? 先週レコメンドチームも同じこと言ってましたよ。」 プラットフォーム: 「Debezium にトピック一つ追加すればいい。」 DBA: 「replication slot は既に 5 個開いてて、lag が 30 分です。」

この短いやり取りに、2026 年のデータ統合のすべてが詰まっている。OLTP は真実の源泉だが、分析・AI・SaaS はその真実を別の形で欲しがる。その間を埋めるのが CDC (Change Data Capture) とデータ統合だ。

この領域はここ 5 年で爆発的に成熟した。一方には Debezium・Flink CDC のような OSS 陣営があり、もう一方には Fivetran・Airbyte・Estuary のようなマネージド SaaS がある。そしてその上に Hightouch・Census のような reverse ETL が載り、Sling・Sequin のような軽量ツールが隙間を埋める。

この記事はその全体地図を整理する。Debezium 3.0 の変化、Estuary Flow のマネージドな野心、Flink CDC がいかに ELT ツールへ進化したか、Airbyte と Fivetran の本質的な違い、Postgres logical replication や MongoDB Change Streams といった DB ネイティブの仕組み、outbox パターン、そして reverse ETL がなぜ別カテゴリになったか、までを扱う。

第 1 章 · CDC 基礎 — ログ vs トリガー vs ポーリング

CDC とは「DB の変更を検知してどこかへ流す」行為全般だ。実装方式は 3 種類しかない。

方式仕組み長所短所
PollingSELECT ... WHERE updated_at > ?最も単純レイテンシ大、削除を捉えられない、DB 負荷
TriggerDB トリガー → 別テーブルへ記録どんな DB でも動くトランザクション性能を犠牲
Log-basedWAL / binlog / redo を直接読むほぼゼロオーバーヘッドDB 権限・複雑度

2026 年の本格的な CDC はほぼすべて log-based だ。MySQL は binlog、Postgres は WAL (Write-Ahead Log) + logical replication、MongoDB は oplog / Change Streams、SQL Server は CDC テーブル、Oracle は redo log を LogMiner や XStream で読む。

ポーリングは小規模システムでは今でも有効。トリガーは他に手段が無く、変更頻度が極めて低い場合の最終手段だ。

もう一つの軸は snapshot + incremental。CDC を始めた瞬間に既にテーブルに 1 億行ある場合、それを全部読んでから (snapshot)、その時点以降の変更を追う (incremental) 必要がある。Debezium は incremental snapshot、Flink CDC は parallel snapshot で解いた。

第 2 章 · なぜ今 CDC なのか — 4 つのユースケース

なぜ CDC が突然必須インフラになったのか。4 つのユースケースが同時に爆発したからだ。

  1. リアルタイム分析 / Operational analytics — 売上ダッシュボードを 5 分レイテンシで vs 24 時間バッチで。
  2. マイクロサービス統合 — サービス A の DB 変更をサービス B が知る必要があるが、直接 API 呼び出しは結合度が高すぎる。イベント発行で分離。
  3. 監査 / Audit / コンプライアンス — 誰がいつ何を変えたかを immutable log として保管。
  4. AI 学習データ / Feature store sync — モデルの学習データセット、ベクトルストア、レコメンド feature を OLTP と同期。

特に 4 番が 2024 〜 2026 年に爆増した。モデルはより頻繁に学習され、RAG システムは鮮度 SLA を要求する。「昨日追加された文書が今日の検索に出てこない」はもはや許されない。

これら 4 つに共通するのは、OLTP に余計な負荷を掛けずに変更を伝搬する必要があるという制約だ。だから log-based CDC が勝った。

第 3 章 · Debezium 3.0 (Red Hat, Apache 2.0) — Kafka Connect の王

Debezium は事実上 OSS CDC の標準だ。Red Hat がスポンサーし、Apache 2.0 ライセンス。2025 年初に Debezium 3.0 がリリースされ、2026 年現在 3.x ラインが活発に更新されている。

対応 DB:

  • MySQL, MariaDB
  • PostgreSQL (logical replication, pgoutput / decoderbufs / wal2json)
  • MongoDB (Change Streams, レプリカセット必須)
  • SQL Server (native CDC)
  • Oracle (LogMiner)
  • IBM Db2
  • Apache Cassandra
  • Vitess
  • Spanner (preview)

伝統的には Debezium は Kafka Connect 上で動く。JSON / Avro / Protobuf にシリアライズして Kafka トピックへ投げる。メッセージキーは PK、値は before / after / source / op の構造だ。

{
  "before": { "id": 42, "email": "a@x.com" },
  "after":  { "id": 42, "email": "b@x.com" },
  "op": "u",
  "source": { "db": "shop", "table": "users", "lsn": 12345 },
  "ts_ms": 1731700000000
}

3.0 の主な変更:

  • Kafka 3.x / 4.0 互換 — share groups まで活用可能
  • Java 17+ 必須
  • Schema history 改善 — トピック以外の外部ストレージにも保存可能
  • Incremental snapshot の安定化 — 運用中に新テーブル追加が無停止
  • Debezium UI — 独立した管理コンソール

長所: 実績ある安定性、大きなコミュニティ、主要 DB を全部カバー。 短所: Kafka Connect の運用負荷、JVM 依存、メモリが重い。

第 4 章 · Debezium Server / Engine — 組み込みモード

すべてのチームが Kafka Connect を立てる余裕があるわけではない。Debezium は 2 つの軽量モードを提供する。

Debezium Server — スタンドアロンで動くコンテナ。Kafka 以外の sink へ直接送れる。

  • Kinesis, Pub/Sub, Pulsar
  • EventHubs, Event Grid
  • HTTP, NATS, Redis Streams
  • ファイル, S3
debezium:
  sink:
    type: pubsub
    pubsub:
      project.id: my-project
  source:
    connector.class: io.debezium.connector.postgresql.PostgresConnector
    database.hostname: pg.internal
    database.dbname: shop
    plugin.name: pgoutput
    slot.name: debezium
    publication.name: debezium_pub
    topic.prefix: shop

Debezium Engine — Java ライブラリとしてアプリに組み込み、自分のアプリ内で直接 CDC イベントを受け取る。トラフィックが少なく単一ノードのユースケースに向く。HA は無い。

2026 年、Debezium Server は「Kafka 無し Debezium」のスローガンで人気を集めている。NATS JetStream や Redis Streams との組合せが特に速い。

第 5 章 · Estuary Flow — マネージド CDC SaaS

Estuary Flow は 2020 年創業のマネージド CDC + 統合プラットフォーム。2024 〜 2025 年に急成長し、Fivetran の有力代替として定着した。

特徴:

  • リアルタイム CDC — 平均レイテンシ 100ms 以内を謳う
  • 毎秒数百万行 の事例 — 巨大ワークロードに対応
  • Source 200+ / Destination 100+ で急速に増加
  • オープンソースコア (Flow は Apache 2.0) + マネージドホスティング
  • Materializations — 単純コピーではなく、sink 側で継続更新される materialized view 概念

価格は GB 処理量ベース。Fivetran の MAR (Monthly Active Rows) より予測しやすい。

# flow.yaml
captures:
  shop/postgres:
    endpoint:
      connector:
        image: ghcr.io/estuary/source-postgres:dev
        config:
          address: pg.internal:5432
          database: shop
          user: estuary
    bindings:
      - resource:
          stream: public.users
          mode: Normal
        target: shop/users

materializations:
  shop/snowflake:
    endpoint:
      connector:
        image: ghcr.io/estuary/materialize-snowflake:dev
        config:
          account: xy12345.us-east-1
          database: ANALYTICS
          warehouse: COMPUTE_WH
    bindings:
      - source: shop/users
        resource: { table: USERS }

長所: 本物のリアルタイム、予測可能な価格、OSS コア。 短所: 新興、エコシステムはまだ Airbyte より小さい。

第 6 章 · Apache Flink CDC 3.x — Flink 上の ELT

Flink CDC (旧 Ververica CDC connectors) は 2024 年に Apache インキュベーションを経て、Flink CDC 3.0 から 完全な ELT パイプラインツール へ進化した。単なるコネクタではない。

中心概念:

  • Source — MySQL, Postgres, MongoDB, Oracle, SQL Server, TiDB, OceanBase
  • Sink — Doris, StarRocks, Iceberg, Paimon, Kafka, Elasticsearch
  • Pipeline — Source → Transformation → Sink を単一の YAML で定義
  • Schema evolution — sink が対応していれば ALTER TABLE を自動伝搬
  • Parallel snapshot — 大テーブルを chunk に分けて並列読み込み。1 億行テーブルも 1 時間以内。
# pipeline.yaml
source:
  type: mysql
  hostname: mysql.internal
  username: flinkcdc
  password: ${MYSQL_PASS}
  tables: shop.\.*
  server-id: 5400-5404

sink:
  type: paimon
  catalog.properties.metastore: filesystem
  catalog.properties.warehouse: s3://lake/paimon

route:
  - source-table: shop.\.*
    sink-table: ods_shop.<>

pipeline:
  name: shop-to-paimon
  parallelism: 8

Flink CDC が魅力的なのは lakehouse 連携 だ。Iceberg や Paimon に流し込めば Trino / Spark / Doris がそのままクエリできる。Trino + Iceberg + Flink CDC は 2026 年のモダンデータスタック人気構成。

第 7 章 · Airbyte 1.x (Y Combinator W20) — OSS ELT 標準

Airbyte は YC W20 出身、2024 年に 1.0 に達し、2026 年現在 1.x 後半。OSS ELT の標準になった。

特徴:

  • 350+ コネクタ — ほぼあらゆる SaaS と DB
  • オープンソース (MIT / ELv2 混在) + Cloud マネージド
  • Airbyte Protocol — 誰でも標準インターフェースで新コネクタを作れる
  • CDK — Python / Java でカスタムコネクタ、low-code CDK もあり
  • Embedded — 自社製品の中に Airbyte を組み込むオプション

CDC 対応: MySQL, Postgres, MongoDB, SQL Server など。内部的に Debezium を使う (以前は Debezium Embedded、現在は Airbyte 独自実装と Debezium の併用)。

長所: 圧倒的なコネクタ数、OSS、セルフホスト可能。 短所: リアルタイム CDC は弱い (バッチ / マイクロバッチ志向)、運用は軽くない。

2024 年にはマネージド価格の議論があり、2025 年に価格モデルが再整理された。セルフホストが依然として魅力的な理由。

第 8 章 · Fivetran — マネージド ELT の王座

Fivetran はマネージド ELT の代名詞だ。クローズドソースで価格は高い悪名だが、「ただ動く」という運用安定性で企業市場を支配した。

特徴:

  • 600+ コネクタ — Salesforce, Hubspot, Stripe, Zendesk, NetSuite, Workday などほぼ全 SaaS
  • MAR ベース価格 — Monthly Active Rows。一度でも変更された行をカウント。予測不能と批判が多い
  • HVR 買収 — エンタープライズ CDC (Oracle, SAP HANA) を強化
  • dbt 連携 — Transformations 機能
  • Hubspot 連携 — マーケティングデータ領域に強い

2025 〜 2026 年のトレンド: 大企業は依然 Fivetran を使う。スタートアップやデータエンジニアリングチームは Airbyte / Estuary / Sling へ移行中。

第 9 章 · Stitch (Talend → Qlik) / Hevo / Meltano — その他 ELT

Stitch (Singer ベース、Talend が買収 → Qlik が Talend を買収) は 2025 年に EOL が発表され、ユーザは Airbyte / Fivetran / Estuary へ移行した。Singer プロトコルは OSS として生き残っている。

Hevo Data — インド発 ELT。150+ コネクタ、競争力ある価格。インド・東南アジアで強い。

Meltano — GitLab からスピンアウトした OSS ELT。Singer ベース。CLI 中心で dbt との結合度が高い。「ELT をコードで」の哲学が強いチームに人気。

Rivery — イスラエル発、ELT + ワークフロー結合。小規模だが熱心なユーザがいる。

これらの共通点: SaaS コネクタの幅が本業で、CDC は副次的。

第 10 章 · Sling CLI — 高速ローカル・CLI 統合

Sling は単一バイナリ CLI でデータを動かすツール。Go で書かれており非常に速く、データエンジニアがその場で書ける。

# Postgres → Snowflake
sling run \
  --src-conn POSTGRES \
  --src-stream "public.users" \
  --tgt-conn SNOWFLAKE \
  --tgt-object "ANALYTICS.PUBLIC.USERS" \
  --mode full-refresh

特徴:

  • 100+ DB / クラウドストレージ対応
  • YAML でパイプライン定義 (replication.yaml)
  • Sling Cloud (マネージド) + OSS CLI
  • CDC は incremental モードで対応 (binlog ベースの本格 CDC ではない)

長所: 圧倒的に速い、シンプル、セルフホストが自然。 短所: 本格 CDC は無い、dbt のような変換は別。

「この DB からあの DB へ毎日 1 回」というユースケースを CI/CD で回すのに圧倒的。

第 11 章 · Sequin — Postgres → どこへでも

Sequin は Postgres CDC に特化した OSS ツール。コアメッセージは「Postgres を Kafka のように使え」。

  • Postgres logical replication を読む
  • Sink: Kafka, Webhook (HTTP POST), Redis Streams, SQS, GCP Pub/Sub, NATS
  • Elixir で書かれている (BEAM VM の並行性)
  • マネージド + セルフホストの両方
# sequin.yaml
streams:
  - name: orders_stream
    source:
      type: postgres
      database: orders
      tables: ["public.orders", "public.order_items"]
    consumers:
      - name: webhook_to_shipping
        type: http_push
        endpoint: https://shipping.internal/webhook
        max_ack_pending: 100
      - name: kafka_to_warehouse
        type: kafka
        topic: orders-cdc
        bootstrap_servers: kafka.internal:9092

Sequin は「Debezium は重すぎる、Postgres 一つだけなのに Kafka まで立てたくない」というチームに強い。2024 〜 2025 年に急成長した。

第 12 章 · Striim / Qlik Replicate / Oracle GoldenGate — エンタープライズ

エンタープライズには別の市場がある。

Striim — エンタープライズストリーミング統合。SAP, Oracle, SQL Server, メインフレームまでカバー。価格は高いが大企業の標準。

Qlik Replicate (旧 Attunity) — Qlik が 2019 年に Attunity を買収。Oracle, SQL Server, SAP HANA, Db2 をほぼ網羅。金融業界でよく見る。

Oracle GoldenGate — Oracle CDC の標準。Oracle 同士のレプリケーションが本業だが heterogeneous も対応。価格は容赦ない。

IBM InfoSphere Data Replication (CDC) — メインフレーム + Db2 環境。

SAP Data Services / SAP SLT — SAP システム統合専用。

スタートアップではほぼ見ないが、金融・通信・政府では依然標準だ。

第 13 章 · AWS DMS · GCP Datastream · Azure Data Factory — クラウドネイティブ

3 大クラウドすべてがマネージド CDC を提供する。

AWS DMS (Database Migration Service) — Oracle / SQL Server / MySQL / Postgres → RDS / Aurora / Redshift / S3 への移行 + 継続 CDC。名前は「マイグレーション」だが実際は CDC として使うケースが多い。2024 年に Serverless DMS が GA。

AWS DMS + Kinesis Data Streams + Lambda — DMS が Kinesis に変更イベントを投げ、Lambda が処理するパターン。

GCP Datastream — Oracle / MySQL / Postgres / SQL Server → BigQuery / Cloud Storage。BigQuery へのリアルタイム CDC が本業。コンソールで一発。

GCP Datastream + Dataflow — データを Dataflow (Flink / Beam) で加工してから BigQuery に着地。

Azure Data Factory + Synapse Link — Synapse Link for SQL / Dataverse / Cosmos DB は OLTP → analytics をワンクリックで繋ぐ。Synapse Link for Cosmos DB は NoSQL と分析をミラーする。

Azure Database Migration Service — Azure 版 DMS。

長所: 自分のクラウドにきれいに統合される、コンソールクリックで完了。 短所: マルチクラウド / オンプレが混ざると限界がすぐに来る。

第 14 章 · Postgres logical replication · MySQL binlog · MongoDB Change Streams

CDC の根本は DB が提供する機能だ。この 3 つは押さえておくべき。

Postgres logical replication:

  • wal_level = logical が必要
  • max_replication_slots, max_wal_senders の調整
  • Publication / Subscription モデル
  • pgoutput (built-in), wal2json, decoderbufs (Debezium プラグイン)
  • Logical slot は 進めないとディスクを食い尽くす。正常運用ではコンシューマが LSN を進めなければならない
ALTER SYSTEM SET wal_level = logical;
SELECT pg_create_logical_replication_slot('debezium', 'pgoutput');
CREATE PUBLICATION dbz_pub FOR ALL TABLES;

罠: pg_repack, VACUUM FULL, 一部の ALTER TABLE は logical replication と衝突する。本番で行が流れなくなったら、ほぼ slot の詰まりだ。

MySQL binlog:

  • log_bin = ON, binlog_format = ROW
  • gtid_mode = ON を強く推奨 (フェイルオーバが容易になる)
  • expire_logs_days が短すぎるとコンシューマが追い付けず欠損

MongoDB Change Streams:

  • レプリカセット必須。スタンドアロンでは使えない
  • db.collection.watch() でサブスクライブ
  • Resume token でクラッシュ後の再開

第 15 章 · Reverse ETL — Hightouch · Census · Polytomic · Grouparoo

伝統的な ETL が SaaS / DB → ウェアハウスなら、reverse ETL はウェアハウス → SaaS だ。「データチームが作ったモデル結果を営業 / マーケティングツールに戻したい」という要求が爆発し、別カテゴリになった。

Hightouch — リーダー。Snowflake / BigQuery / Databricks / Redshift → Salesforce / Hubspot / Iterable / Segment / 広告ツール。SQL で audience を定義、sync mode 多彩 (upsert, mirror, update only)。

Census — Hightouch の最も強い対抗馬。似たポジショニング、価格・可観測性・監査で差別化。

Polytomic — より新興。AI / ML モデル出力の sync を強調。

Grouparoo — OSS reverse ETL だったが 2022 年に Airbyte に買収され、事実上 EOL。Airbyte が reverse ETL を吸収する試みだったが、市場は別カテゴリとして定着した。

Workato — より広い iPaaS。reverse ETL も含むが RPA / ワークフロー自動化が本業。

2026 年の reverse ETL の大きな変化: AI レコメンド結果を運用ツールへ push することが主要ユースケースになった。モデルが作る lead score, churn risk, NBA (next best action) を Salesforce へ流す。

第 16 章 · dbt + ウェアハウス — Transformation 層

CDC / ELT がデータを動かすなら、dbt はそれを変換する。Modern Data Stack の T。

  • dbt Core (OSS, Apache 2.0)
  • dbt Cloud (マネージド)
  • SQL でモデル定義、jinja templating、自動 lineage
  • 対応ウェアハウス: Snowflake, BigQuery, Databricks, Redshift, Postgres, DuckDB, Trino, Athena など

Modern Data Stack 標準フロー:

Source (Postgres, Salesforce, Stripe)
  → CDC/ELT (Airbyte/Fivetran/Estuary/Debezium)
  → Warehouse (Snowflake/BigQuery/Databricks)
  → Transform (dbt)
  → BI (Looker/Mode/Hex)
  → Reverse ETL (Hightouch/Census) → SaaS

2024 年 dbt Labs は SDF Labs を買収して SQL コンパイラを強化、2025 〜 2026 年には dbt Core 上に Fusion エンジンを載せると発表した。

第 17 章 · パイプラインオーケストレーション — Airflow · Dagster · Prefect · Mage · Kestra

CDC 自体はストリームだが、それを受けて dbt を回し ML 学習をトリガーするのはバッチ / スケジュール仕事だ。オーケストレータが必要。

Apache Airflow — 事実上の標準。2024 年に Airflow 3.0 が大規模リファクタとともに登場。UI 改善、scheduler 分離、より優れた dynamic DAG。

Dagster — Software-defined assets という概念。データ資産を一級市民として扱う。モダンなデータチームで急成長。

Prefect — Python first, dynamic workflow, 軽量。

Mage — UI 中心の ETL。非開発者でもアクセス可能。

Kestra — YAML ベースオーケストレーション。データパイプライン + 一般自動化。

2026 年の流れ: Dagster が Airflow のデータエンジニアリング市場を浸食中。Airflow は依然最大の導入実績だが、新規プロジェクトは Dagster を選ぶ割合が増えた。

第 18 章 · Schema Registry — Confluent · Karapace · Apicurio

CDC イベントはスキーマが進化する。Avro / Protobuf / JSON Schema をどこかで管理する必要がある。

Confluent Schema Registry — Kafka 標準。ライセンスは Confluent Community License で「偽 OSS」という批判もある。

Karapace — Aiven が作った Apache 2.0 互換 Schema Registry。Confluent の真の OSS 代替。

Apicurio Registry — Red Hat 製。Apache 2.0。スキーマだけでなく OpenAPI / AsyncAPI も管理。

互換性ポリシー (Confluent 規約):

  • BACKWARD — 新スキーマが古いデータを読めること
  • FORWARD — 古いスキーマが新データを読めること
  • FULL — 双方向
  • NONE — チェック無し (危険)

CDC 運用でよくある事故: 誰かが DB カラムを drop し、schema registry が BACKWARD で、下流が壊れる。

第 19 章 · CDC パターン — Outbox · Transactional Outbox · Saga

CDC をマイクロサービス統合として使う際に最も一般的なパターン。

Outbox パターン: ドメイン DB に「outbox」テーブルを置き、ビジネストランザクションと同一トランザクションでイベントを outbox に INSERT する。CDC がその outbox テーブルを読みメッセージブローカに送る。at-least-once 配信が保証されるのが要点。

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
INSERT INTO outbox (aggregate_id, event_type, payload)
  VALUES (1, 'AccountDebited', '{"amount":100}');
COMMIT;

CDC は outbox テーブルの変更だけを追跡し、Kafka に転送する。Debezium には outbox event router が組み込まれている。

Transactional Outbox — 同じ概念。Eventuate.io のようなライブラリ。

Saga パターン — 分散トランザクションの代替。一連のローカルトランザクション + 補償トランザクション。CDC で saga ステップ間通信。

Change feed — DocumentDB, Cosmos DB, DynamoDB のネイティブ change stream。同じ概念の別名。

Dual write アンチパターン — DB に書いた後 Kafka にも直接書くコード。どちらかが失敗しうる。絶対に避けるべき。outbox パターンが答え。

第 20 章 · 信頼性 — Exactly-once · Ordering · Schema Evolution

CDC を本番で運用するといずれ突き当たる 3 つ。

Exactly-once semantics:

  • Debezium は基本 at-least-once だ。重複が発生しうる。
  • Kafka transactions (Kafka 3.x) + idempotent consumer で実用的 exactly-once は達成可能
  • Flink は checkpoint + 2PC で exactly-once を標準サポート

Ordering guarantees:

  • 同じ PK のイベントは同じパーティションに行く必要 → producer がキーを PK にする
  • 異なる PK 間の順序は保証されない
  • Postgres logical replication は単一 publication 内では commit 順序を保証

Schema evolution:

  • Avro + Confluent Schema Registry + BACKWARD compatibility が標準
  • カラム追加: 安全
  • カラム削除: 下流影響、段階的 deprecate
  • カラム型変更: 最も危険、新カラム + マイグレーション

第 21 章 · CDC for AI — Feature store / Vector store sync

2024 〜 2026 年の最大のユースケース変化は AI 学習 / 推論データの鮮度 だ。

Feature store sync — Tecton, Feast, Hopsworks のような feature store は OLTP / イベントと同期する必要がある。リアルタイム feature (例: 直近 1 時間の売上) は CDC + Flink / Kafka Streams で計算。

Vector store sync — RAG システムの source of truth が OLTP にある場合、Pinecone / Weaviate / pgvector をどう更新するか。CDC → embedding pipeline → vector store が標準アーキテクチャ。

LLM 学習データ freshness SLA — 「昨日追加された文書は今日の検索に出るべき」という SLA。CDC が基盤。

ML モデル学習 — バッチ CDC dump を S3 に送り、Spark / Ray で学習。

この領域は 2026 年の fastest growing。Estuary, Sequin, Striim 等が皆 「AI」 で売り込んでいる。

第 22 章 · 韓国事例 — Coupang / Kakao / Naver / Woowa Brothers

Coupang — Kafka + Debezium の組み合わせがよく知られた事例。注文 / 在庫変更を Kafka へ流し、多くのマイクロサービスが購読。

Kakao — 技術ブログに Debezium + Kafka Connect の運用事例多数。Kakao Bank / Kakao Pay は厳密な CDC 運用。

Naver — 自社データプラットフォームに binlog ベース CDC を多用。NCloud のデータ統合サービスもある。

Woowa Brothers (Baemin) — Debezium 導入記と運用ノウハウの技術ブログが多い。

NCsoft / Nexon — ゲームログ / セーブデータ CDC。Kafka + 自社ツール。

Toss — Toss 技術ブログに散発的に CDC 記事。Postgres logical replication + 自社コンシューマ。

共通点: 多くは Debezium + Kafka を自社運用し、Fivetran のようなマネージドはグローバル SaaS のローカル支社で主に使われる。

第 23 章 · 日本事例 — Mercari · LINE · Cookpad · ZOZO

Mercari — ML プラットフォームで CDC が中核。Tech blog に Debezium + GCP Pub/Sub 事例。

LINE (LY Corporation、ヤフー統合後) — データエンジニアリングブログに Kafka + Debezium + Hadoop / Trino lakehouse 事例多数。PrivateMode CDC 運用が非常に大規模。

Cookpad — レシピデータ + ユーザログ CDC。Aurora + DMS + Redshift の組合せ。

ZOZO — ファッション EC。Snowflake への CDC で Fivetran / 自社ツールを併用。

CyberAgent — 広告 / ゲーム / メディア事業多様。Kafka + Debezium が社内標準。

Recruit / Indeed — データプラットフォームに自社 CDC インフラ。

日本は Snowflake / Databricks 導入が加速中で、それに伴い Airbyte / Fivetran の比重が高まっている。

第 24 章 · 意思決定 — どれを選ぶか

チェックリスト:

  1. DB 一つ、リアルタイム不要 → Sling CLI + cron / dbt
  2. Postgres 一つ、リアルタイム必要 → Sequin または Debezium Server
  3. 複数 DB + Kafka が既にある → Debezium + Kafka Connect
  4. Flink が既にある or 一括導入 → Flink CDC 3.x + Iceberg / Paimon
  5. SaaS コネクタ大量必要、予算 OK → Fivetran
  6. SaaS コネクタ大量必要、予算厳しい → Airbyte (セルフホスト / Cloud)
  7. マネージド + 真のリアルタイム + 価格予測可能 → Estuary Flow
  8. OLTP の真実を SaaS へ push → Hightouch / Census (reverse ETL)
  9. AWS だけ → AWS DMS + Kinesis
  10. GCP だけ、BigQuery → GCP Datastream
  11. エンタープライズ Oracle / SAP → Striim / Qlik Replicate / GoldenGate

避けるべきアンチパターン:

  • Dual write — DB と Kafka に直接両方書くコード。絶対禁止。outbox パターンを使え。
  • ポーリングで分単位 lag — 運用 DB に圧迫。log-based へ移行。
  • MAR 爆発 — Fivetran 請求書を見て驚く前に価格モデルをシミュレートせよ。
  • Schema BACKWARD 無視 — カラム drop 一発で全下流ダウン。

第 25 章 · 運用知見 — よく遭遇する問題

Postgres logical slot が減らない:

SELECT slot_name, active, restart_lsn, confirmed_flush_lsn,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_replication_slots;

retained_wal が GB に達するならコンシューマが lag しているか死んでいる。対応:

  1. コンシューマを再起動
  2. 駄目なら slot を削除し再作成 + 初回 snapshot をやり直し

Kafka トピック rebalance が 5 分かかる: KIP-848 (next-gen consumer rebalance) 有効化、Static membership (group.instance.id) 設定。

Debezium が最初に lag 爆発: snapshot 中。incremental.snapshot.chunk.size と snapshot.fetch.size を調整。Flink CDC は parallel snapshot でこの問題が少ない。

MySQL binlog が早く expire → コンシューマ lag 時にデータ欠損。binlog_expire_logs_seconds を伸ばすか、S3 アーカイブを追加。

Snowflake コスト爆発 — CDC が micro-batch で入り small file が爆発。compaction 周期と warehouse サイズを調整。dbt incremental model で整理。

エピローグ — データは運ぶものではなく約束だ

2026 年の CDC とデータ統合は結局 契約 (contract) に収束する。Schema 進化、ordering、exactly-once、freshness SLA — これらすべてが producer と consumer の間の契約だ。

ツールは豊富にある。Debezium も良い。Estuary も良い。Flink CDC も良い。Airbyte も良い。だが、間違ったツールをうまく運用するより、正しいツールをうまく扱えないことの方が、よくある失敗だ。

問う順序が重要:

  1. このデータのオーナーは誰か? — source of truth はどこ
  2. 誰がどれだけ速く必要か? — freshness SLA
  3. 再処理可能か? — 保持期間、replay コスト
  4. schema はどう進化するか? — 契約変更を誰が承認するか
  5. 障害をどう検知・復旧するか? — observability, lag 監視

この 5 つに答えを持つチームはどのツールでもうまくいく。答えを持たないチームは Fivetran の請求書を見て初めてデータガバナンスを始める。

CDC はインフラではない。データ契約の表現だ。そう扱おう。

参考 / References

  1. Debezium 公式ドキュメント
  2. Debezium 3.0 Release Notes
  3. Debezium Server ガイド
  4. Estuary Flow Docs
  5. Apache Flink CDC
  6. Flink CDC 3.x Documentation
  7. Airbyte Documentation
  8. Airbyte Protocol Spec
  9. Fivetran Docs
  10. Sling Documentation
  11. Sequin Docs
  12. Meltano Hub
  13. Striim Platform
  14. Qlik Replicate
  15. Oracle GoldenGate
  16. AWS DMS Documentation
  17. GCP Datastream
  18. Azure Data Factory CDC
  19. Hightouch Documentation
  20. Census Documentation
  21. dbt Documentation
  22. Apache Airflow
  23. Dagster Docs
  24. Confluent Schema Registry
  25. Karapace OSS Schema Registry
  26. Apicurio Registry
  27. Postgres Logical Replication
  28. MongoDB Change Streams
  29. Outbox Pattern (microservices.io)
  30. Mercari Engineering Blog
Discuss on Twitter • View on GitHub