Debezium은 캡처까지만 한다 - 소스 교체와 병렬 처리, 실전에서 확인하기

gywndi@gmail.com (gywndi) — Sun, 23 Aug 2026 22:30:49 +0900

이전 글 요약

이전 글에서 확인한 건, Debezium 임베디드 엔진의 콜백을 제출 스레드(TRD1)와 순서 보장 배출 스레드(TRD2)로 나누면 병렬로 처리해도 성능 손실 없이(98~101%) 순서를 지킬 수 있다는 것이었습니다. 다만 그건 id 하나 뽑아서 큐에 넣고 순서만 재본 순수 벤치마크였습니다.

이번 글에서 구현한 건 두 가지입니다.

MySQL을 Postgres로 갈아 끼워도, 우리 코드는 한 줄도 안 바뀔까? JDBC 드라이버를 바꿔도 애플리케이션 로직은 그대로이듯, Debezium도 “어디서 캡처할지"만 책임지고 그 뒤(가공, 전송)는 전부 우리가 용도에 맞게 짜는 애플리케이션 코드가 되도록 구현했습니다.
워커 4개가 동시에 갈아엎어도, Kafka엔 여전히 1, 2, 3 순서로 꽂힐까? 지난번엔 id 하나만 뽑아 순서를 쟀지만, 이번엔 진짜 컬럼을 가공하고 진짜 Kafka로 전송하는 작은 애플리케이션으로 그 결론을 그대로 재현했습니다.

전체 데이터 흐름

멀티소스는 Debezium 커넥터 단계에서만 갈립니다. 그 뒤(TRD1 - 워커 풀 - TRD2 - KafkaSink)는 소스와 무관하게 완전히 같은 코드가 처리하고, 같은 토픽으로 모입니다.

SMT는 병렬화할 수 없다 — Debezium 바깥에서 순서를 지키며 처리량 올리기

gywndi@gmail.com (gywndi) — Tue, 18 Aug 2026 22:57:37 +0900

CDC와 Debezium

서로 다른 종류의 시스템(RDBMS, 검색엔진, 캐시, 다른 서비스의 데이터베이스 등) 간에 데이터를 실시간으로 동기화해야 하는 경우, 원본 데이터베이스를 주기적으로 폴링하는 방식은 확장성과 지연 시간 모두에서 한계가 있습니다. 이 문제를 해결하는 표준적인 방법이 CDC(Change Data Capture)입니다 — 데이터베이스가 남기는 변경 로그를 실시간으로 읽어, 변경 사항을 이벤트로 만들어 필요한 곳에 전달하는 방식입니다. Debezium은 이 CDC를 구현하는 오픈소스 도구 중 가장 널리 쓰이는 것 중 하나이고, 이기종 시스템 간 데이터 동기화 파이프라인의 핵심 구성 요소로 많이 채택되고 있습니다.

CDC on gywn's tech

Debezium은 캡처까지만 한다 - 소스 교체와 병렬 처리, 실전에서 확인하기

이전 글 요약

전체 데이터 흐름

SMT는 병렬화할 수 없다 — Debezium 바깥에서 순서를 지키며 처리량 올리기

CDC와 Debezium