Apache Iceberg와 Flink CDC 연동 심층 분석: 성능 최적화 및 운영 사례

기존 MySQL 전체 데이터를 일 단위 배치로 HDFS에 적재하던 방식은 디스크 사용률 100% 도달 등 심각한 DB 부하를 유발했다. 이를 해결하기 위해 Apache Iceberg와 Flink CDC를 연동하여 실시간 변화분만 반영하는 구조로 전환했다. 이 방식은 전체 데이터 적재 단계를 제거하고, CDC로 Iceberg 테이블에 실시간 데이터를 반영함으로써 DB 부하 없이 Spark 조회가 가능해졌다.

Flink CDC 직접 적재 아키텍처

기존 Kafka Connect 기반 Debezium 방식은 JSON 포맷의 무거운 메시지로 인해 처리율 저하가 발생했다. 이를 개선하기 위해 Kafka를 거치지 않고 Flink RowData 포맷을 사용하여 Iceberg에 직접 적재하는 구조를 채택했다. 이 구조는 메시지 경량화를 통해 처리율을 크게 향상시켰다.

• 성능 비교: Kafka 전송 구조는 병렬성 1당 평균 5k msg/s인 반면, Iceberg 직접 적재 구조는 병렬성 1당 평균 15k msg/s를 기록했다.
• 최대 처리량: 병렬성 20 설정 시 각각 최대 360k msg/s, 280k msg/s의 처리율을 기록했으며, DB 부하 테스트 결과 최대 병렬성 45까지 확장 가능함을 확인했다.

테이블 설정 및 파티셔닝 전략

Iceberg 테이블은 Format Version 2를 사용하며, 파일 포맷은 Parquet, 압축은 zstd를 적용해 Trino 조회 성능과 GC 안정성을 높였다. 쓰기 모드는 기본값인 **COW(Copy-on-Write)**를 유지했으나, Flink 적재 로직 특성상 실질적인 영향은 미미한 것으로 분석됐다.

파티셔닝은 기본키 기준 Bucket 파티션을 사용하며, 복합키인 경우 카디널리티가 높은 컬럼을 선택한다. Modulo 값 테스트 결과, 50 이상부터 Spark 조회 시간이 증가하는 경향이 있어 최종적으로 Modulo 값을 5로 설정하여 과도한 파일 세분화를 방지했다.

스캔 플래닝 및 컴팩션 최적화

Iceberg의 스캔 플래닝은 파티션 정보, 시퀀스 넘버, 통계 정보를 기반으로 필요한 데이터 및 삭제 파일만 선별한다. 특히 Equality Delete 파일은 시퀀스 넘버가 더 작은 과거 데이터 파일에만 반영되며, 동등 컬럼의 최소/최대 값 구간이 겹치는 경우에만 최종 반영되어 성능을 최적화한다.

컴팩션은 조회 성능 유지에 핵심적이다. 30억 레코드 규모에서 컴팩션을 수행하지 않으면 7일차 조회 시간이 60분까지 급증하지만, 컴팩션 수행 시 39분 소요 후 조회 시간이 1.7분 수준으로 회복된다. 다만, 특정 조건에서 삭제 파일이 누적되는 문제를 해결하기 위해 rewrite-all 또는 rewrite_position_delete_files 등의 기능을 활용해야 한다.

샤딩 테이블 통합 운영의 한계

복수 샤딩 테이블을 단일 Iceberg 테이블로 통합하는 실험을 진행했으나, 실서비스 적용은 보류됐다. 32개 테이블(27억 레코드) 통합 시 소싱 평균 270초로, 단일 테이블 32회 소싱(640초)보다 성능상 이점이 있었으나, 복수 Flink 잡의 동시 커밋 시 CommitFailedException이 발생했다. 재시도 설정으로 완화 가능하나, 100개 이상 샤딩 규모에서는 안정성 확보가 어려워 최종적으로 미적용을 결정했다.