CDC(Change Data Capture) 개념 및 테크 기업 사례 살펴보기

CDC(Change Data Capture) 개념

CDC(Change Data Capture)는 데이터베이스에서 데이터의 변경 사항을 실시간으로 추적하고 기록하는 기술이다. 

쉽게 말해, 데이터베이스에 어떤 변화가 생겼는지(ex. 데이터 추가, 수정, 삭제)를 자동으로 감지하고, 그 변화를 다른 시스템이나 애플리케이션에게 전달한다.

 

CDC가 왜 중요할까?

기업에서는 여러 시스템이 서로 데이터를 공유하거나 동기화해야하는 경우가 많다. 간단한 예를 들어, 웹 사이트에서 고객이 주소를 변경하면, 그 정보가 다른 관련 시스템(ex. 배송 시스템, 고객 관리 시스템 등)에도 즉시 반영돼야 한다. 이 때, CDC를 사용하면 데이터베이스의 변화가 생길 때마다 이를 자동으로 감지하고 필요한 시스템에 변화된 정보를 실시간으로 전달할 수 있다.

 

CDC의 Use Case

1. 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝗥𝗲𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻

CDC는 원본 데이터베이스(=Source Database)에서 일어나는 모든 변화를 다른 데이터베이스(Target Database)로 복사하는데 사용할 수 있다. 여기서 중요한 점은, CDC를 통해 복사된 데이터가 원본 데이터와 똑같고, 데이터의 정확성과 일관성이 보장된다는 것이다.

즉, CDC를 사용해 데이터를 복제하면, 원본 데이터베이스에서 보장되던 ACID(Atomicity, Consistency, Isolation, Durability)가 Target Database에서도 그대로 유지된다.

 

또한, Real-Time CDC는 데이터베이스를 실시간으로 계속 추적하고, 그 변화 내용을 즉시 다른 데이터베이스에 복사해주는 기술이다. 이 기능은 특히 다운타임이 허용되지 않는 경우 매우 유용하다.

 

예를 들어, 어떤 회사가 자체 서버(온프레미스)에 중요한 데이터 베이스를 운영하고 있다고 가정해보자.

이 데이터베이스가 중요한 애플리케이션을 지원하고 있다면, 단 1분이라도 중단되면 아마 담당자 머리가 깨지게 될 거다.

즉, 시스템을 멈추지 않고(= 다운타임 없이) 이 데이터베이스를 클라우드로 이전할 때 Real-Time CDC를 사용할 수 있다.

 

2. Operational Databases to Data Lake(or Data Warehouse) For Analytics

거창하게 영어로 썼지만, 말 그대로 데이터 분석을 위해 Operational Database에서 Data Lake나 Data Warehouse로 데이터를 옮기는 경우를 말한다. (여기서 Operational Database는 실시간으로 데이터를 처리하는 데이터베이스를 의미한다.)

 

이러한 Operational Database에 저장된 데이터를 분석하려면, 데이터를 분석하기에 적합한 시스템으로 옮겨야 한다.

이 때 사용하는 시스템이 Data Lake와 Data Warehouse다.

• Data Lake: 다양한 형식의 데이터를 원본 그대로 저장할 수 있는 저장소. 주로 분석을 위한 대용량 데이터를 보관하는데 사용된다. (ex. S3)
• Data Warehouse: 구조화된 데이터를 저장하고, 빠른 분석을 위해 최적화된 데이터베이스. (ex. Amazon Redshift)

이 때의 데이터를 이동 시키는 방식에는 크게 두 가지가 있다.

너무나도 익숙한 ETL(Extract, Transformation, Load)과 ELT(Extract, Load, Transformation)

 

ETL: CDC로 추출(Extract)된 데이터가 즉시 변환(Transformation)을 거쳐 Data Lake나 Data Warehouse로 전송(Load)된다. 

ELT: 데이터는 원본 그대로 Data Lake나 Data Warehouse로 복제(Load)되며, 변환(Transformation)작업은 시스템 내부에서 수행된다. 

 

ETL은 데이터를 이동하는 과정에서 바로 가공하기 때문에 이후의 분석 작업이 빠르고 효율적일 수 있지만, 복잡한 변환이 필요한 경우 작업 시간이 오래 걸릴 수 있다. 반면, ELT는 데이터를 빠르게 저장할 수 있고, 나중에 필요한 변환 작업을 유연하게 수행할 수 있지만 분석 시점에서 추가 작업이 필요할 수 있다. 주어진 상황에 맞게 둘 중 하나를 선택해서 사용하고 있는 추세다.

 

실제 빅테크 기업들의 CDC 사례

1. 네이버 페이

Legacy -> MSA

도메인 DB 떼어 내기(좌), 도메인 DB 간 데이터 동기화(우)

 

서비스 확장을 위해 기존 시스템(하나의 Oracle DB에서 동작하는 Monolithic한 구조)에서 서비스 중단없이 MSA(Microservice Architecture)로 나아가는 과정에서 CDC를 사용했다.

 

도메인 DB 떼어 내기

- 기존 Oracle DB로 서비스하는 상태에서 특정 도메인(ex. 배송) 영역만 MySQL 기반의 새로운 DB로 복사하고, 복사 후에는 기존 DB의 변경 사항을 새로운 DB에 반영한다.

- 기존 DB와 데이터 동기화가 완료되면, 해당 도메인에 대한 요청을 새로운 DB로 전환한다.

- 전환 후 문제가 발생할 경우, 기존 DB로 롤백해야 한다. 롤백을 하려면 새로운 DB에서 변경된 사항을 기존 DB로 모두 반영한 후에 할 수 있다. 이렇게 기존 DB로 동기화 해주는 과정이 오래걸린다면 서비스 연속성이 깨질 수 있다. 따라서, 평상시에 새로운 DB의 데이터를 기존 DB로 데이터를 역복제하여 동기화 상태를 유지해야 한다. 이 때, 양방향 복제 중 복제가 무한히 반복되지 않도록 트랜잭션 로그에서 이미 복제된 내용을 필터링 하는 기능이 필요하다.

 

도메인 DB 간 데이터 동기화

- MSA(Microservice Architecture)로 전환한 후에도, 도메인 간 데이터 동기화를 위해 변경 사항을 서로 전달하는 작업이 필요하다.

- 도메인별로 데이터베이스를 유지하면서도, 구매자와 판매자 같이 사용 유형에 따른 여러 도메인 데이터를 빠르게 하나의 뷰로 제공해야 한다. 이를 위해 읽기전용 DB를 유지하고, 여러 도메인에서 발생하는 데이터를 실시간으로 동기화해야 한다.

- 데이터 통계 분석을 위한 저장소나 향후 외부 시스템과의 데이터 연동을 대비해, 카프카와 같은 데이터 스트리밍 버스를 통해 필요한 변경사항을 발행할 수도 있다.

- 이렇게 여러 저장소 간 데이터를 유연하게 동기화하는 작업이 필요하다.

 

이외에도 도메인 DB 최적화를 위해서도 CDC 기술이 사용됐다.

 

2. 토스

토스 증권에서도 Data Analyst가 사용하는 분석계 데이터, ML Engineer가 사용하는 학습용 데이터, 토스 앱에서 사용되는 서비스용 데이터 등 다양한 분야에서 CDC를 도입해 실시간으로 데이터를 제공하고 있다. 토스의 경우 오픈 소스인 Debezium을 사용하고 있다.

토스는 최근 여러 파트에서 사용되는 CDC를 잘 운영하고 있는가?에 대해 포커싱해서 글을 작성했는데 이번 포스팅에서는 CDC의 개념과 구축 사례를 간단하게 살펴볼 것이기 때문에 해당 부분은 링크만 첨부하고 추후 정리할 예정이다.

 

 

3. 기타 참고할만한 테크 기업의 CDC 구축 사례

우아한 형제들, LINE, 하이퍼커넥트 등의 사례들은 맨 아래 링크로 걸어두겠다.

 

CDC 구현 방법

CDC를 구현할 때 방법은 크게 세 가지이다. 

Pull 기반 CDC, Push 기반 CDC, Log 기반 CDC

 

1. Pull 기반 CDC

Pull 기반 CDC는 클라이언트가 소스 데이터베이스를 직접 주기적으로 조회(쿼리)해 변경된 데이터를 가져와 타겟 데이터베이스로 전달하는 방식이다.

• 모든 소스 테이블에 변경 표시를 추가해야 함
  : 데이터베이스에서 어떤 레코드가 변경됐는지를 식별하기 위해, 모든 테이블에 변경 여부를 나타내는 flag를 추가해야 한다.
  예를 들어, 각 테이블에 is_modified와 같은 flag 컬럼을 추가해 데이터가 삽입 및 수정될 때 True로 설정하여 해당 레코드만 쿼리하여 변경된 데이터를 추출하고, 이후 False로 리셋할 수 있다. 또는, last_modified와 같은 타임스탬프 컬럼을 추가해, 데이터가 변경될 때마다 이 컬럼을 현재 시간으로 업데이트하고 변경된 데이터를 추출할 수 있다.
• 실시간 CDC가 아님
  : 실시간으로 동작하지 않으며, 주로 시간 간격을 두고(ex. 매 시간, 매일) 배치 단위로 실행되기 때문에 데이터가 즉각적으로 동기화되지 않을 수 있다.
• 소스 데이터베이스에 높은 부하 발생
  : CDC 작업이 수행될 때, 소스 데이터베이스에 많은 부하가 발생할 수 있으며 성능 저하로 이어질 수 있다. 어떤 레코드가 변경됐는지 확인하기 위해 전체 테이블을 스캔하거나, 특정 조건에 맞는 대규모 쿼리를 실행해야 하기 때문이다.
• 삭제 이벤트 복제가 어려움
  : 데이터가 삭제된 경우, 해당 이벤트를 정확하게 복제하는 것이 매우 어렵다. (추적 어려움)

 

2. Push 기반 CDC

Push 기반 CDC는 소스 데이터베이스에 트리거를 설정하는 방식이다. 트리거는 데이터베이스에 변경 이벤트(ex. 데이터 추가, 수정, 삭제)가 발생할 때마다 자동으로 해당 이벤트를 감지하고, 그 변경 사항을 타겟 시스템로 즉시 전달한다.

• 실시간 CDC(Real-Time CDC)
  : Push 기반 CDC는 변경 사항이 발생할 때마다 즉시 데이터를 타겟 시스템으로 전송하므로, 데이터를 실시간으로 동기화할 수 있다. 즉, 데이터가 즉각적으로 업데이트되며, 최신 상태를 유지할 수 있다는 장점이 있다.
• 높은 데이터베이스 부하
  : 트리거가 변경 이벤트를 실시간으로 감지하고 데이터를 전송하는 과정에서 데이터베이스에 높은 부하가 발생할 수 있다. 특히, 변경 이벤트가 자주 발생하는 경우, 데이터베이스 성능에 영향을 미칠 수 밖에 없다.

 

3. Log 기반 CDC

로그 기반 CDC는 데이터베이스에 일어나는 모든 데이터 변경 사항을 기록하는 트랜잭션 로그를 활용하는 방식이다.

트랜잭션 마이너(Transaction Miner)라는 도구가 로그를 분석해서 필요한 변경 사항을 추출하고, 그 데이터를 타겟 시스템으로 전송한다. (ex. Debezium)

• 데이터 베이스에 가장 적은 부하
  : 트랜잭션 로그를 읽어들이기 때문에, 데이터베이스에 직접적인 부하를 거의 주지 않는다.
• 실시간 CDC
  : 트랜잭션 로그를 실시간으로 모니터링하고, 변경 사항을 즉시 반영해 실시간으로 데이터를 동기화할 수 있다.
• 설정이 복잡함
  : 설정 과정이 위 두 CDC보다 복잡하며, 트랜잭션 로그를 분석하고 필요한 데이터를 추출하는 과정 역시 까다롭다.
• 모든 데이터베이스에 오픈 소스 커넥터가 있는 것은 아님
  : 로그 기반 CDC를 구현하려면 특정 데이터베이스에 맞는 커넥터가 필요하지만, 모든 데이터베이스가 이를 지원하는 건 아니다. 일부 데이터베이스에서는 사용할 수 있는 오픈 소스 커넥터가 없을 수 있다.

 

지금까지 CDC의 개념과 테크 기업들의 실제 CDC 사례를 간략하게 살펴봤다. (잘못된 내용이 있으면 댓글로 남겨주시면 감사하겠습니다)

다음 포스팅에서는 AWS 서비스로 간단하게 CDC를 구축하는 방법을 작성할 예정이다.

 

 

테크 기업들의 CDC 사례 링크

우아한 형제들: https://techblog.woowahan.com/10000/

CDC 너두 할 수 있어(feat. B2B 알림 서비스에 Kafka CDC 적용하기) | 우아한형제들 기술블로그

LINE: https://techblog.lycorp.co.jp/ko/change-data-capture-for-headless-cms

Headless CMS를 위한 변경 데이터 캡쳐(CDC) 기술 설계하기

하이퍼 커넥트: https://hyperconnect.github.io/2021/01/11/cdc-platform.html

CDC & CDC Sink Platform 개발 1편 - CDC Platform 개발

 

 

Reference

SAI #02: Feature Store, Splittable vs. Non-Splittable Files and more...