1. CDC란

• CDC(Change Data Capture)는 데이터베이스의 변경 사항을 실시간으로 감지하고, 이를 다른 시스템으로 전파하는 기술입니다.
• CDC의 주요 장점은 데이터의 실시간 동기화를 가능하게 하여, 데이터의 신선도를 유지하고, 시스템 간의 데이터 일관성을 보장한다는 점입니다
  • 데이터베이스의 변경 사항을 즉시 감지하여 다른 시스템으로 전파하기 때문입니다.

1.1 CDC의 필요성

• 전통적으로 팀들은 배치 처리를 사용하여 데이터를 동기화했는데,
  • 이는 데이터가 즉시 동기화되지 않고, 리소스 할당을 위해 프로덕션 데이터베이스가 느려지며,
  • 지정된 배치 윈도우 동안에만 데이터 복제가 이루어진다는 것을 의미했습니다.
• CDC는 변경사항이 실시간으로 동기화되도록 보장하여 전통적인 배치 처리와 관련된 지연을 제거합니다.
• CDC는 지속적으로 변경사항을 추적하고 대상 데이터베이스를 즉시 업데이트하여 데이터가 항상 최신 상태를 유지하도록 합니다.

2. CDC의 동작 방식

• 소스 데이터베이스(일반적으로 MySQL, Microsoft SQL, Oracle, PostgreSQL과 같은 관계형 데이터베이스)에서 INSERT, UPDATE, DELETE를 통해 데이터가 된다.
• CDC 변경사항을 캐시, 검색 인덱스, 데이터 웨어하우스, 데이터 레이크와 같은 다운스트림 시스템으로 전파한다.
• CDC는 일반적으로 푸시(push)와 풀(pull)이라는 두 가지 주요 접근 방식으로 구현됩니다.
• 소스 데이터베이스가 다운스트림 서비스와 애플리케이션으로 업데이트를 푸시하거나, 다운스트림 서비스와 애플리케이션이 일정한 간격으로 소스 데이터베이스를 폴링하여 업데이트된 데이터를 가져오는 방식입니다.
• 각 접근 방식에는 장단점이 있으며, 자신의 사용 사례에 맞춰 이러한 측면들을 모두 고려하는 것이 중요합니다.

2.2 푸시 방식

• 이 접근 방식에서는 소스 데이터베이스가 대부분의 작업을 수행합니다.
• 데이터베이스의 변경사항을 캡처하고 이러한 업데이트를 대상 시스템으로 전송하여 적절한 조치를 취할 수 있도록 합니다.
• 이 방식의 장점은 대상 시스템이 거의 실시간으로 최신 데이터로 업데이트된다는 것입니다.
• 그러나 대상 시스템에 접근할 수 없거나 오프라인 상태인 경우 변경된 데이터가 손실될 수 있습니다.
• 이러한 위험을 완화하기 위해, 일반적으로 소스 시스템과 대상 시스템 사이에 메시징 시스템을 구현하여 변경사항이 최종 목적지에 커밋될 때까지 버퍼링합니다.

2.3 풀 방식

• 이 방식에서는 소스 데이터베이스의 작업이 푸시 방식보다 가벼워집니다.
• 업데이트를 적극적으로 전송하는 대신, 소스 데이터베이스는 각 테이블의 특정 컬럼에 데이터 변경사항을 기록합니다.
• 변경사항을 검색하고 그에 대한 적절한 조치를 취하는 것은 대상 시스템의 책임입니다.
• 푸시 방식과 마찬가지로, 대상 시스템을 사용할 수 없을 때 변경된 데이터가 손실되지 않도록 하기 위해 소스 시스템과 대상 시스템 사이에 메시징 시스템이 필요합니다.
• 풀 방식의 단점은 데이터가 변경되더라도 대상 시스템이 즉시 알림을 받지 못한다는 것입니다.
• 변경사항이 풀 요청 사이에 배치 처리되기 때문에, 대상 시스템이 이러한 변경사항을 알게 되기까지 지연이 발생합니다.

3. CDC 패턴

3.1 타임 스탬프 방식

• 가장 최근의 변경을 추적하는 방식입니다.
• LAST_MODIFIED, LAST_UPDATED 등의 컬럼을 사용합니다.
• 다운스트림 애플리케이션이나 시스템은 이 필드를 조회하여 마지막 실행 시점 이후 업데이트된 레코드를 확인할 수 있습니다.
• 장점:
  • 사용과 구현이 간단함
  • 시간에 따른 변경사항을 추적하는 간단한 방법 제공
• 단점:
  • 소프트 삭제만 처리 가능하며 실제 DELETE 작업은 추적 불가
  • 대상 시스템이 마지막 업데이트 값을 식별하기 위해 테이블의 각 행을 스캔해야 하므로 소스 시스템에 계산 부하 발생
  • 기존 데이터베이스 스키마 변경 필요

3.2 트리거 방식

• 대부분의 데이터베이스는 트리거 함수를 지원합니다.
• 이는 테이블에서 INSERT, UPDATE, DELETE와 같은 특정 이벤트가 발생할 때 자동으로 실행되는 저장 프로시저입니다.
• 데이터 변경을 캡처하기 위해 각 테이블의 각 작업마다 하나의 트리거가 필요합니다.
• 이러한 데이터 변경사항은 동일한 데이터베이스 내의 별도 테이블("섀도우 테이블" 또는 "이벤트 테이블"이라고 함)에 저장됩니다.
• 또한 개발자는 메시징 시스템을 포함하여 이러한 데이터 변경사항을 큐에 게시하고, 관련 대상 시스템이 이를 구독할 수 있도록 할 수 있습니다.
• 장점:
  • 모든 유형의 변경사항(INSERT, UPDATE, DELETE)을 감지하고 캡처 가능
  • 트리거는 널리 사용되며 대부분의 데이터베이스에서 지원됨
    • 폴링 없이 실시간 데이터 캡처 가능
• 단점:
  • 레코드 업데이트에 여러 번의 쓰기가 필요하므로 소스 데이터베이스 성능에 부정적 영향
  • 소스 데이터베이스 스키마 변경 필요
  • 트리거 수가 많아지면 관리가 복잡해질 수 있음

3.3 로그 스트리밍 방식

• 트랜잭션 데이터베이스는 모든 변경사항(INSERT, UPDATE, DELETE)과 해당 타임스탬프를 트랜잭션 로그라는 파일에 기록합니다.
• 이러한 로그는 주로 백업과 재해 복구 목적으로 사용되지만, 대상 시스템으로 변경사항을 전파하는 데도 사용할 수 있습니다.
• 데이터 변경사항은 실시간으로 캡처됩니다. 대상 시스템이 트랜잭션 로그에서 직접 읽을 수 있으므로, 이 방식은 소스 데이터베이스에 계산 부하를 주지 않습니다.
• 장점:
  • 소스 데이터베이스에 계산 부하를 주지 않음
  • 모든 유형의 변경사항(INSERT, UPDATE, DELETE)을 감지하고 캡처 가능
    • 소스 데이터베이스의 스키마 변경이 필요 없음
• 단점:
  • 트랜잭션 로그 형식에 대한 표준화가 없음. 각 벤더가 자체 방식을 구현하며, 이는 향후 릴리스에서 변경될 수 있음
    • 대상 시스템은 소스 데이터베이스에 기록되었다가 롤백된 변경사항을 식별하고 제거해야 함

4. CDC 활용 사례

4.1 연속적인 데이터 복제

• 전체 소스 데이터베이스를 배치 모드로 대상 시스템에 복사할 때는 프로세스가 완료될 때까지 스키마 변경을 포함한 새로운 쓰기를 수용할 수 없습니다.
• 복사 프로세스가 길어질수록 소스에 대한 중요한 변경사항이 지연될 위험이 커지며, 변경사항을 대상에 전달하는 데도 추가 지연이 발생할 수 있습니다.
• 현대 애플리케이션에서는 사용자가 실시간 경험을 요구하기 때문에 이러한 시나리오는 바람직하지 않습니다.
• CDC는 변경된 데이터(전체 데이터베이스의 부분집합)를 다운스트림 소비자에게 지속적으로 복제함으로써 이러한 문제를 해결합니다.

4.2 마이크로서비스 아키텍처 통합

• 조직이 모놀리식 아키텍처를 분해하고 마이크로서비스를 도입함에 따라, 소스 데이터베이스의 데이터를 하나 이상의 대상 시스템으로 전송해야 할 필요가 있습니다.
• 이러한 전환에는 시간이 소요되므로, CDC를 사용하여 프로세스 동안 소스와 대상 데이터 저장소를 동기화된 상태로 유지할 수 있습니다.

4.3 클라우드 도입

• 조직은 TCO(총소유비용)를 줄이고 민첩성과 탄력성을 향상시키기 위해 점점 더 클라우드로 마이그레이션하고 있습니다.
• 클라우드 네이티브 서비스를 활용함으로써, 기업은 데이터베이스와 인프라를 구성, 유지 관리, 관리하는 데 시간과 리소스를 소비하는 대신 새로운 디지털 경험을 구축하는 데 집중할 수 있습니다.
• CDC는 이러한 마이그레이션을 지원하고 온프레미스와 클라우드 환경 전반에 걸쳐 데이터의 일관성과 최신성을 보장합니다.
• 이러한 원활한 데이터 통합은 기업이 중단 없이 클라우드 기능을 완전히 활용할 수 있도록 도와줍니다.