CDC (Change Data Capture)

1. CDC (Change Data Capture)

데이터베이스 내의 데이터에 변경 (Insert, Update, Delete) 이 발생했을 때, 이 변경 이벤트만을 추출하여 데이터 웨어하우스, 데이터 레이크, 또는 다른 애플리케이션으로 전달하는 소프트웨어 기술

기존 Batch와의 차이

• 기존 ETL: 정해진 특정 시간에 대량의 데이터를 한번에 조회해서 옮기는 방식. 시스템 부하가 크고, 실시간성을 보장하지 못함

• CDC: 변경된 트랜잭션 로그 기반으로 작동하므로, 데이터가 생성되는 즉시 (Near Real-time) 타겟 시스템에 반영됨

2. CDC 주요 구현 방식

1) 로그 기반 (Recommended)

• 원리: 데이터베이스는 모든 변경 사항을 별도의 로그 파일에 기록함. CDC 도구는 이 로그 파일을 직접 읽어 변경 사항을 캡쳐
  • ex. MySQL - Binlog, PostgreSQL - WAL, Oracle - Redo Log
• 장점

  • 저부하: 소스 데이터베이스에 쿼리를 날리지 않으므로 운영 DB 성능 저하가 거의 없음

  • 완전성: 모든 변경 사항과 삭제 작업까지 완벽하게 캡쳐할 수 있음

• 단점
  • 구현 난이도가 높고, 데이터베이스 종류마다 로그 형식이 다름

2) 쿼리 기반

• 원리: LAST_UPDATED 와 같은 타임스탬프 컬럼이나 증가하는 ID 컬럼을 주기적으로 조회하여 변경분을 찾는 방식.

• 장점
  • 별도의 로그 접근 권한 없이 SQL만으로 구현 가능
• 단점

  • 삭제 감지 불가: 데이터가 지워지면 변경분을 조회할 수 없으므로 삭제 사실을 알 수 없음. (soft delete 제외)

  • polling 부하: 운영 데이터베이스에 직접 주기적으로 조회 요청을 날리기 때문에 부하 부담이 있음.

3) 트리거 기반

• 원리: 데이터베이스 내부에 트리거를 설정하여 변경 사항 발생 시 별도 테이블에 기록

• 단점: Write 성능을 심각하게 저하시키기 때문에 대용량 시스템에서는 지양.

3. 로그 기반 CDC 구현 방식

표준적인 아키텍처인 [Source DB → CDC Connector(Debezium) → Kafka → Sink Connector → Target DB] 구성 기준.

1) 소스 데이터베이스 설정 (Source Configuration)

CDC 도구가 로그에 접근할 수 있도록 소스 DB의 환경을 구성하는 단계

• 로깅 활성화: DB의 설정 파일에서 변경 사항을 기록하는 옵션 활성화
  • MySQL: binlog_format = ROW (SQL 문장이 아닌 변경된 데이터 값 자체를 기록하도록 설정)
  • PostgreSQL: wal_level = logical (외부에서 논리적으로 해석 가능한 로그 레벨로 설정)
• 계정 및 권한: CDC 도구가 사용할 전용 DB 계정을 생성하고, 복제 프로토콜을 사용할 수 있는 권한(REPLICATION CLIENT, REPLICATION SLAVE) 부여

2) CDC 커넥터 배포 및 초기 적재 (Initial Snapshot & Streaming)

CDC 엔진(예: Kafka Connect + Debezium)을 실행하여 소스 DB와 연결

• 핸드셰이크(Handshake): CDC 커넥터가 소스 DB에 접속하여 자신을 ‘복제본(Replica)’으로 등록

• 초기 스냅샷(Snapshot): 로그는 ‘연결 시점 이후’의 변경분만 존재. 따라서 최초 실행 시에는 기존에 쌓여 있는 모든 데이터를 SELECT * 형태로 조회하여 타겟으로 먼저 넘김.

• 로그 스트리밍(Log Streaming): 스냅샷이 완료되면 자동으로 모드를 전환하여, 실시간으로 발생하는 트랜잭션 로그(Binlog/WAL)를 읽어들이기 시작함

3) 메시지 변환 및 버퍼링 (Serialization & Buffering)

읽어들인 바이너리 데이터를 가공하여 메시지 큐에 저장

• 직렬화(Serialization): DB 내부의 바이너리 데이터를 범용적인 포맷(JSON, Avro, Protobuf 등)으로 변환. 이 과정에서 메타데이터(생성 시간, 트랜잭션 ID, 변경 전/후 값)가 포함된 구조체(Struct)가 생성됨.

• 토픽 라우팅(Topic Routing): 일반적으로 서버명.데이터베이스명.테이블명 형식으로 Kafka 토픽을 구분하여 데이터를 발행함. Kafka는 이 데이터를 디스크에 저장하여 타겟 시스템의 장애나 지연에 대비한 버퍼(Buffer) 역할 수행.

4) 타겟 시스템 반영 (Sink & Apply)

메시지 큐에 쌓인 데이터를 최종 목적지에 반영

• Sink Connector: Kafka에 저장된 데이터를 읽어 타겟 DB(Snowflake, BigQuery, ElasticSearch 등)에 적재하는 역할. 별도의 코딩 없이 설정(Configuration)만으로 동작하는 경우가 많음.

• 데이터 반영(Apply):

  • Upsert: 소스에서의 INSERT와 UPDATE는 타겟에서 Upsert 로직으로 처리하여 데이터 정합성을 맞춤.

  • Delete 처리: 소스에서의 DELETE 이벤트는 타겟에서 실제 데이터를 삭제하거나, is_deleted 플래그를 업데이트하는 방식으로 처리.

기술적 핵심 요약 (Technical Key Points)

1. 오프셋 관리 (Offset Management):
   • CDC 도구는 자신이 로그의 “어디까지 읽었는지”에 대한 위치 정보(Offset, LSN 등)를 주기적으로 저장함.
   • 시스템이 재시작되더라도 저장된 오프셋 위치부터 다시 읽기 시작하여 데이터 유실이나 중복을 방지(Exactly-once 또는 At-least-once).
2. 스키마 레지스트리 (Schema Registry):
   • 소스 DB의 테이블 구조(컬럼 추가/변경)가 바뀌었을 때, CDC 도구는 이를 감지하여 버전을 관리함. 이를 통해 데이터 구조 변경 시 파이프라인이 중단되지 않도록 대응함.
3. 데이터 일관성 (Consistency):
   • CDC는 트랜잭션의 순서를 보장해야 함. 따라서 Kafka의 파티션을 설정할 때, 동일한 Primary Key를 가진 데이터는 반드시 동일한 파티션으로 들어가도록 설정하여 순서 뒤바뀜을 방지함.

4 데이터 엔지니어링에서의 CDC 활용 사례

• 실시간 분석을 위한 ETL/ELT 파이프라인 구축
  • 과거에는 ‘어제 데이터’를 분석할 수 있었지만, CDC를 통해 운영 DB(OLTP)의 데이터를 분석용 DB(OLAP)로 초 단위 지연으로 동기화할 수 있음. 이를 통해 경영진은 실시간 대시보드를 확인할 수 있음.
• MSA 간 데이터 동기화

  • MSA 환경에서는 서비스마다 DB가 분리되어있음. A 서비스의 데이터 변경을 B 서비스가 알아야 할 때 CDC와 메시지 큐 (Kafka 등) 를 결합하여 데이터를 전파함

  • Outbox Pattern: 분산 트랜잭션 문제를 해결하기 위해 트랜잭션 로그를 CDC로 읽어 이벤트를 발행하는 패턴에서 핵심 역할을 함.

• 무중단 클라우드 마이그레이션
  • 온프레미스 DB를 클라우드로 옮길 때 사용.

    • 초기 전체 데이터 복제

    • 복제하는 동안 발생한 변경분을 CDC로 계속 캡쳐하여 클라우드 DB에 반영

    • 양쪽 데이터가 동기화되면 시스템 전환 (Cut-over)

• 캐시 및 검색 엔진 갱신
  • DB가 업데이트 되었을 때, 이를 감지하여 Redis와 같은 캐시나 Elasticsearch 같은 검색 엔진의 데이터를 자동으로 최신화하여 데이터 정합성 유지

5. 대표적인 CDC 도구

1. Debezium: 가장 널리 쓰이는 오픈소스 CDC 플랫폼. Apache Kafka를 기반으로 동작하며 MySQL, PostgreSQL, MongoDB, SQL Server 등을 지원함.

2. AWS DMS: 클라우드 관리형 서비스로, 설정이 간편하며 마이그레이션 및 지속적 복제에 주로 사용됨.

3. Oracle GoldenGate: 엔터프라이즈급 솔루션으로 매우 강력하지만 고가임.

4. Kafka Connect: 다양한 Source/Sink 커넥터를 통해 CDC 파이프라인 구성.