소스 테이블의 스키마가 변경되면?

CDC 수행 중 소스 테이블 스키마가 변경되면, Debezium은 변경 이후의 전체 테이블 스키마 정보를 포함한 change event를 생성합니다. 이벤트를 직렬화 결과 기준으로 보면, 단순 ddl 로그가 아니라 변경된 시점의 컬럼 전체 메타데이터가 함께 전달됩니다. 이때 역직렬화 단계에서 분기 처리한다면, 스키마 변경으로 인한 문제 없이 파이프라인을 유지할 수 있습니다.

소스 DB의 컬럼 변경이 타깃 DB 스키마 변경으로 이어져야 하는 경우, 이러한 이벤트를 파싱해 타깃 스키마까지 동기화 해주면 됩니다. 제 경우 MySQL → MongoDB 구조라 스키마리스 특성과 공용 모델 사용 덕분에 문제가 없지만, MySQL → PostgreSQL과 같은 경우에는 반드시 이 부분을 고려해야 합니다.

스냅샷을 빠르게 하고싶다면?

초기 CDC 를 도입하다보면 타겟 테이블이 오염되었을 경우가 존재합니다. 주문정보가 순서가 바뀌었거나, 특정 기간 데이터가 누락되는 등 다양한 이유로 인해 타겟 테이블을 초기화하고 다시 스냅샷을 떠야 하는 상황이 발생할 수 있습니다. 이 때, 복구를 위해 debezium 을 스냅샷 복구 or initial 모드를 실행하게 되면 싱글스레드로 순차업데이트 하게 되는데 초기 싱크할 때 거의 4~5시간이 걸렸습니다. 이럴 땐 대규모 CDC Pipeline 운영을 위한 Debezium 개선 여정 에서 처럼 1개씩 source -> mq -> target 으로 보내는게 아니라, 배치로 깨끗한 테이블에 초기 데이터 적재를 수행한 뒤 debezium.source.snapshot.mode 를 no_data 로 설정해서 스냅샷 단계를 건너뛰고 바로 변경로그부터 처리하도록 할 수 있습니다. 이 떄 주의해야할 부분은 배치싱크 시점을 잘 기록해놓고 debezium 의 offset metadata 에 반영해주어야합니다.

핵심은 초기 binlog pos 스냅샷과 벌크싱크 배치가 끝난 시점의 pos 사이 발생한 새로운 이벤트들을 누락없이 중복하여 처리하는 것입니다. 그리고 sink connector 에서는 중복처리 해주지만 페이로드에서 before 무시 및 after 로 싱크하게된다면 eventually consistent 한 상태를 유지할 수 있습니다. 실제로 배치싱크 수행 후 debezium 실행하게 되면 약 5시간 -> 50분 내외로 처리할 수 있었습니다.

시퀀스 다이어그램

스냅샷 자체가 싱글스레드로 순차 진행 되기 때문에 대량의 초기 데이터를 빠르게 적재하려면 배치 싱크를 활용하는게 좋습니다.

하지만 아직 많이 부족하다고 생각하는 부분은 모니터링입니다. 관련된 메트릭을 수집하고, 장애 알람을 설정하는 부분이 아직 미흡해서 추후 개선이 필요합니다.