CDC 파이프라인을 Debezium과 Flink로 재설계한 이유

문제 상황

• 초기 NiFi 기반 MySQL binlog CDC 파이프라인이 서비스 규모 확장과 이벤트 폭증에 따라 확장성, 처리 안정성, 오프셋 관리에서 한계 노출
• CDC 데이터가 단순 적재를 넘어 실시간 비즈니스 모니터링의 핵심 소스로 쓰이면서 순서 보장, Exactly-once, 스키마 대응에 대한 요구 증가
• GUI 중심 운영과 클러스터 자원 공유 구조로 인해 버전 관리, 배포 자동화, 결함 격리에 제약 발생

원인 분석

• 특정 프로세서 부하 집중 시 수평 확장 어려움과 오프셋 상태의 불투명성
• 관리형 복제 도구나 단순 스트리밍 도구만으로는 필터링, 포맷 변환, 정합성 검증을 충분히 처리하기 어려움
• Parquet 스키마 제약과 단일 파티션 토픽 구조가 운영 중 병목을 유발

해결 방법

• 변경 로그 캡처는 Debezium, 스트림 처리와 비즈니스 로직은 Apache Flink로 분리
• Kafka를 완충 지대로 두고 DB 단위 통합 토픽, 스키마 내장 이벤트, 체크포인트 기반 Exactly-once를 적용
• 서비스별 Job 분리, 스키마 해시 기반 버킷 분리, 토픽 파티션 확장과 메트릭 모니터링으로 안정성과 처리량 개선

적용해볼 점

• CDC를 단순 적재가 아닌 실시간 정합성 검증과 운영 모니터링의 기반으로 설계할 필요
• 오프셋, 지연, 처리량 지표를 기준으로 파이프라인 가시성을 확보할 필요
• 스키마 변경과 부하 불균형을 구조적으로 분리하는 운영 전략을 고려할 필요