CDC(Change Data Capture)란?

과거부터 데이터베이스 replica 생성, 데이터 수집 등 데이터베이스 복제에 대한 요구사항이 발달하면서, '변경을 다른 곳에 복제하는 것'에 대한 많은 관심이 높아져왔고 관련 솔루션도 점점 발달해 왔습니다. 

 

CDC 솔루션은 크게 1) 로그 기반, 2) trigger 기반(DB 프로시져 등을 통한) 형태가 존재합니다. 이번 글에서는 로그 기반 CDC를 중점으로 살펴보겠습니다.

 

주로 데이터베이스의 복제를 위해 사용되던 replication log는 초기에 외부에 사용되는 API라기보다는 내부 구현용으로 여겨져 왔습니다.  그렇기에 그러한 replication log는 데이터베이스에 가한 모든 변경에 대한 기록을 가지고 있지만, 이러한 모든 변경 기록을 통해 다른 스토리지에 데이터를 복사하는 일은 매우 어려운 일이 었습니다. 

 

write-ahead log - Image from [3]

 

로그는 점점 그 기능이 단순한 기록만이 아니라 변경에 대한 모든 히스토리 기록이라는 관점이 점점 발달되면서 더욱 중요한 역할을 가지게 되었습니다. 

 

하지만 점점 그러한 요구사항이 발달하며 Oracle OGG, LinkedIn의 Databus, Facebook의 Wormhole 등 다양한 상용, 오픈소스 솔루션이 만들어졌습니다. 또한, 변경 히스토리에 대한 모든 기록화가 가능해지면서 일정 시점의 데이터를 복원하는 등 현재 상태만 제공하는 것을 넘어 더욱 풍부한 데이터를 제공할 수 있게 되었습니다. 이는 데이터로 만들 수 있는 다양한 데이터 상품에도 큰 영향을 주게 되었습니다.

 

 

Log-based CDC - Image from [4]

 

 

예로, 데이터 분석에 있어서 유저가 어떤 상품을 장바구니에 담았었는지와 실제 구매 상품 간의 상관성을 조사한다고 해보겠습니다. 그러한 경우 해당 유저의 장바구니에 대한 과거 기록을 히스토리 형태로 기록해둔 테이블이 없다면 그러한 목적에 사용할 데이터가 존재하지 않습니다. 히스토리 형태의 테이블을 따로 만들 수 있지만 이러한 부분은 데이터베이스의 운영상 예민할 수 밖에 없는 성능 및 부하, 디스크 공간 등에 영향을 주게 됩니다. 이러한 경우 CDC를 사용해서 아래와 같이 모든 변경분에 대한 이벤트 히스토리를 Kafka 또는 OLAP용 데이터베이스 등에 따로 저장하고 목적에 맞게 사용할 수 있습니다:

 

 

 

 

Reference

[1] https://en.wikipedia.org/wiki/Change_data_capture

[2] https://en.wikipedia.org/wiki/Write-ahead_logging

[3] https://martinfowler.com/articles/patterns-of-distributed-systems/wal.html

[4] https://www.striim.com/log-based-change-data-capture/

[5] https://www.striim.com/change-data-capture-cdc-what-it-is-and-how-it-works/