CDC(Change Data Capture)는 데이터베이스의 변경 로그를 읽어 "어떤 행이 어떻게 바뀌었다"는 이벤트로 바꿔 내보내는 기법이다. 애플리케이션 코드가 아니라 DB가 이미 남기는 기록에서 변경을 뽑아내므로, 다른 저장소와 동기화할 때 누락 위험이 가장 낮다.
PostgreSQL ──WAL──▶ Debezium ──이벤트──▶ Kafka ──▶ 검색 색인, 알림, 정산 …
(원본 변경) (변경 감지) (보관·분배)- WAL·binlog: PostgreSQL의 Write-Ahead Log, MySQL의 binlog처럼 DB가 모든 변경을 먼저 적는 로그
- Debezium: 이 로그를 읽어 변경 이벤트로 바꾸는 대표 커넥터. 보통 Kafka로 내보낸다
왜 이중 쓰기보다 나은가
앱이 DB에 저장하고 이어서 검색 엔진도 직접 갱신하면(이중 쓰기, dual write), 두 번째 호출이 실패할 때 영구적인 불일치가 남는다. CDC는 DB에 커밋된 변경만 읽으므로 "커밋됐는데 이벤트가 안 나감" 틈이 거의 없다. 앱은 검색 엔진의 존재를 몰라도 된다.
대가
- Debezium·Kafka 같은 인프라가 무겁고 운영 난이도가 높다
- 테이블 구조가 그대로 이벤트에 드러나 소비자가 스키마에 묶인다. 도메인 이벤트를 직접 설계하고 싶다면 트랜잭셔널 아웃박스 패턴가 낫다
- 전달은 at-least-once(최소 한 번 전달)라 소비자는 멱등해야 하고, 결과는 최종 일관성이다
DB 내부에서 변경을 복제하는 데이터베이스 다중화과 같은 로그를 쓰지만, 목적지가 다른 종류의 시스템이라는 점이 다르다. 검색 색인 동기화 맥락은 역색인과 검색 엔진를 본다.