Change Data Capture(CDC)

정의

DBMS의 변경 데이터를 사용해 후속처리를 취할 수 있도록 데이터를 추적하기 위해 사용되는 소프트웨어 디자인 패턴들의 집합

CDC 구현 기법

1. timestamp

   • 특징
     • 테이블 내 마지막 변경 시점을 기록하는 timestamp(update date) 컬럼 존재
     • 더 최근의 timestamp 값을 갖는 레코드가 발견되면 변경된 것으로 식별
     • 변경된 데이터를 감지하는 일반적이면서도 간단한 CDC 매커니즘
   • 주의사항
     • 변경 감지가 필요한 테이블에 timestamp 컬럼 관리 필요
     • 삭제된 데이터 감지 불가
     • 실시간 변경 데이터 반영 힘듬

2. trigger

   • 특징
     • 변경 감지가 필요한 테이블에 trigger 생성
     • insert/update/delete 발생 시 queue 형식의 테이블에 기록
     • 데이터 수집기에서는 queue 테이블을 조회하여 insert/update/delete 작업 실행
   • 주의사항
     • 테이블마다 별도의 trigger 생성으로 인한 개발/운영 비용 증가(시스템 복잡도 증가 및 변경 관리의 어려움
     • DB의 성능 저하 문제

3. Event Programming
   

   • 특징
     • 어플리케이션 계층에서 데이터가 변경됐을 때 별도의 이벤트 발행
     • REST API 기반 또는 Message Queue 기반의 이벤트 발행
     • 다양한 조건에 의해 변경 데이터를 실시간 반영 가능
   • 주의사항
     • 변경 감지 데이터가 증가할수록 개발/운영 비용 증가 및 시스템 복잡도 증가
     • 개발자가 직접 SQL로 데이터를 수정 할 경우 이벤트 누락 가능성 존재
     • 소스코드에서 이벤트 발행코드 누락 시 데이터 일관성에 문제

4. Log Scanner
   

   • 특징
     • 요즘에는 일반적으로 Log Scanner 방식을 CDC라고 부르는 추세
     • 대부분의 DB에는 DB의 모든 이벤트를 저장하는 트랜잭션 로그가 존재
     • ex) Binlog(MySQL), WAL(PostgreSQL) 등
     • 트랜잭션 로그에서 변경데이터를 추출(insert/update/delete)
     • 로그 기반이기 때문에 개발자의 실수로 인한 이벤트 누락이 없음
     • DB에 직접 쿼리 하지 않기 때문에 DB 부하 최소화
     • timestamp 및 trigger 등의 생성 불필요
     • 실시간 변경 데이터 처리 가능
     • 카카오, 네이버, 쿠팡 등 국내 대기업에서 활용중인 기술
   • 주의사항
     • DB 설정 및 DB 계정 권한에 따라 도입 제한
     • 예를 들어 DB성능 향상을 위해 트랜잭션 로그를 생성하지 않는다거나..
     • 운영 이슈로 인한 데이터 bulk 작업과 같이 변경 데이터의 양이 많을 경우 동기화 지연 발생 가능성 존재
   • 오픈소스 CDC 툴
     • Debezium
       • 
       • RedHat에서 지원하는 Apache Kafka 기반의 분산 CDC 플랫폼
       • Kafka Connect의 Source 커넥터
       • DB의 변경사항을 캡처하여 Kafka의 topic에 변경사항을 발행
       • 기본적으로 하나의 테이블의 변경사항은 하나의 topic에 발행
       • 소비자는 kafka의 topic에서 메세지를 구독하여 data warehouse, cache, search engine 등에 동기화 가능
       • MySQL, PostgreSQL, MongoDB, Oracle 등 다양한 DB를 지원
     • Apache Nifi
       • 현재 기준 MySQL만 지원
       • CaptureChangeMySQL processor로 MySQL의 CDC 기능 지원