이전 글 요약

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

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

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

전체 데이터 흐름

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

CDC와 Debezium

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