카카오, Flink CDC 기반 MySQL 실시간 동기화 아키텍처 공개

카카오 데이터 분석 플랫폼 팀은 Apache Flink와 Flink CDC를 활용해 프로덕션 환경의 데이터베이스 부하를 최소화하면서 실시간 데이터 동기화 파이프라인을 구축한 경험을 공유했다. 핵심 목표는 Change Data Capture (CDC) 작업을 별도 시스템으로 분리해 코어 서비스 영향 없이 일간 지표 계산을 수행하는 것이다.

Flink CDC와 Debezium 비교

일반적인 CDC 도구인 Debezium은 Kafka Connect 연동 시 Snapshot 단계에서 수천만 건의 레코드를 처리하는 데 며칠이 걸릴 수 있으며, 이는 기본 3일인 바이너리 로그 보존 기간을 초과하기 일쑤다. 이로 인해 스냅샷과 스트리밍을 위한 도구를 복잡하게 분리해야 했다.

Flink CDC는 분산 처리와 Incremental Snapshot 지원을 통해 이러한 문제를 해결한다. 테이블을 청크로 나누어 초기 데이터 복사를 병렬화해 소스 DB 부하를 크게 줄인다. 또한 Flink의 Checkpoint 메커니즘을 통해 스냅샷 단계의 장애 시 자동 복구가 가능해 전체 작업을 재시작할 필요가 없다.

스냅샷과 Binlog 일관성 유지

파이프라인은 초기 Snapshot 이후 Binlog Stream으로 이어지는 2단계로 운영된다. 전환 과정에서 데이터 손실이나 불일치를 방지하기 위해 커넥터는 첫 번째 청크의 GTIDs (Global Transaction Identifiers)를 메모리에 저장한다. 이후 JobManager는 완료된 스냅샷 스플릿 중 가장 낮은 GTID를 식별해 바이너리 로그 스트림의 정확한 시작 지점을 결정한다.

청크 크기는 청크 키 컬럼의 범위에 기반한 Distribution Factor를 통해 동적으로 계산된다. 키 분포가 불균일한 경우 순차 쿼리로 폴백되는데, 이는 병렬성과 효율성을 제한한다.

프로덕션 안정성을 위한 커스터마이징

카카오는 프로덕션 엣지 케이스를 처리하기 위해 flink-connector-mysql-cdc에 여러 커스텀 수정 사항을 적용했다:

• 단계 변경 알림: 실행 중인 작업에서 Kafka 토픽을 동적으로 변경할 수 없으므로, Snapshot에서 Binlog Stream으로 전환될 때 관련 GTIDs를 포함해 Watchtower 알림 시스템을 통해 경고를 발송한다.
• DDL 이벤트 처리: 민감 정보 노출 방지와 exactly-once 시맨틱 유지를 위해 DDL 이벤트는 작업을 중단하지 않고 건너뛴다. 건너뛴 DDL의 GTIDs는 수동 검증 및 재동기화를 위해 전송된다.
• DB 전환 보호: 프라임리 DB 연결을 방지하기 위해 페일오버를 모니터링한다. 2대 서버 구성에서는 1000ms마다 DNS IP 변경을 확인한다. 대규모 InnoDB Clusters에서는 read_only 설정을 쿼리해 실수로 프라임리 노드에 연결되었는지 감지하며, 필요 시 예외를 발생시키고 세컨더리 도메인으로 재연결한다.

버전 권장 사항

해당 아티클은 Apache Flink 1.17.1과 Flink CDC 2.4.1을 참조한다. 다만 카카오는 개선된 스냅샷 로직과 MySQL-to-Kafka 파이프라인 공식 지원을 위해 Flink CDC 3.x (특히 3.1 이상) 사용을 권장한다. Flink CDC 3.x는 현재 Apache Flink 1.18과만 호환된다.