💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

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

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 種類しかない。

| 方式 | 仕組み | 長所 | 短所 |

| --- | --- | --- | --- |

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](https://debezium.io/) は事実上 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](https://estuary.dev/) は 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](https://github.com/apache/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](https://airbyte.com/) は 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](https://www.fivetran.com/) はマネージド 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](https://slingdata.io/) は単一バイナリ 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](https://sequinstream.com/) は 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 公式ドキュメント](https://debezium.io/documentation/)

2. [Debezium 3.0 Release Notes](https://debezium.io/blog/2025/01/30/debezium-3-0-final-released/)

3. [Debezium Server ガイド](https://debezium.io/documentation/reference/stable/operations/debezium-server.html)

4. [Estuary Flow Docs](https://docs.estuary.dev/)

5. [Apache Flink CDC](https://github.com/apache/flink-cdc)

6. [Flink CDC 3.x Documentation](https://nightlies.apache.org/flink/flink-cdc-docs-stable/)

7. [Airbyte Documentation](https://docs.airbyte.com/)

8. [Airbyte Protocol Spec](https://docs.airbyte.com/understanding-airbyte/airbyte-protocol)

9. [Fivetran Docs](https://fivetran.com/docs)

10. [Sling Documentation](https://docs.slingdata.io/)

11. [Sequin Docs](https://sequinstream.com/docs)

12. [Meltano Hub](https://hub.meltano.com/)

13. [Striim Platform](https://www.striim.com/docs/)

14. [Qlik Replicate](https://www.qlik.com/us/products/qlik-replicate)

15. [Oracle GoldenGate](https://www.oracle.com/integration/goldengate/)

16. [AWS DMS Documentation](https://docs.aws.amazon.com/dms/)

17. [GCP Datastream](https://cloud.google.com/datastream/docs)

18. [Azure Data Factory CDC](https://learn.microsoft.com/azure/data-factory/concepts-change-data-capture)

19. [Hightouch Documentation](https://hightouch.com/docs)

20. [Census Documentation](https://docs.getcensus.com/)

21. [dbt Documentation](https://docs.getdbt.com/)

22. [Apache Airflow](https://airflow.apache.org/docs/)

23. [Dagster Docs](https://docs.dagster.io/)

24. [Confluent Schema Registry](https://docs.confluent.io/platform/current/schema-registry/index.html)

25. [Karapace OSS Schema Registry](https://github.com/Aiven-Open/karapace)

26. [Apicurio Registry](https://www.apicur.io/registry/docs/)

27. [Postgres Logical Replication](https://www.postgresql.org/docs/current/logical-replication.html)

28. [MongoDB Change Streams](https://www.mongodb.com/docs/manual/changeStreams/)

29. [Outbox Pattern (microservices.io)](https://microservices.io/patterns/data/transactional-outbox.html)

30. [Mercari Engineering Blog](https://engineering.mercari.com/)