- Change Data Capture의 약자.
- 변경된 데이터를 추적하고 판별하여 변경된 데이터로 작업을 수행할 수 있도록 하는 소프트웨어 설계 패턴
DBMS들은 데이터가 변경되면 그 변경 내용을 통지하는 기능을 제공한다. CDC는 이 기능을 활용해 구현한다.
INSERT, UPDATE, DELETE 실행하면 DB 데이터가 변경된다. DB는 변경된 데이터를 CDC 처리기에 전송한다. DB는 커밋된 데이터만 변경된 순서에 맞게 전달한다. CDC처리기에는 롤백된 데이터가 전달되지 않는다. 또한 잘못된 순서로 데이터가 전달되는 일도 없다.
변경 데이터는 레코드 단위로. 1개의 레코드 추가, 2개 수정, 3개 삭제했다면 총 6개의 레코드 변경분이 CDC 처리기에 전달된다.
CDC 처리기는 전달 받은 변경 데이터 확인 후 가공 후 대상 시스템에 전파한다. 이 CDC 처리기는 2가지 형태로 대상 시스템에 변경 데이터를 전파한다.
- 변경 데이터 그대로 대상 시스템에 전파
- 변경 데이터를 가공/변환 후 대상 시스템에 전파
어? DDH 아닌가… 2번 데이터를 가공/변환 후 대상시스템에 전파!
2번 케이스를 생각. 새로운 주문 데이터 생성되거나 주문 상태가 배송 중 이 되면 통지 시스템에 이 주문 데이터를 모두 전송할 필요없다. 단지 주문 ID, 변경된 주문 상태만 보내면됨.
목적에 따라 CDC 처리기는 DB, 메시징 시스템, API 등 다양한 대상에 데이터 전파가 가능하다. 두 시스템간 데이터 동기화 목적(낸드소프트)이라면 단순히 DB와 DB사이에 CDC를 두어 데이터를 복제할 수 있다.
그런데 DDH는 변경분 통지가 아니라 CDC 처리기가 일정 시간마다 원본 DB읽어서 비교하는 방식이긴함…
CDC와 데이터 위치
CDC 처리기는 변경 데이터 어디까지 처리했는지 기록 해야됨. MySQL은 바이너리 로그 써서 CDC 구현하는데 각 로그 항목은 변경된 데이터와 로그 파일에서의 위치(포지션)값 가진다. 이 위치 기록해야 CDC 처리기 재시작시 마지막으로 조회한 로그부터 읽을 수 있게됨! 이거 기록안하면 마지막 로그 데이터부터 읽어야되는데 이때 CDC 처리기 재시작 동안 발생한 변경 데이터 놓치게 된다.
CDC가 유용할 때
시스템이 복잡해서 연동 코드 넣기 부담스러울때 CDC 유용. 신규 주문 시스템에서 발생한 주문 데이터를 기존 주문 시스템에 반영해야되는 요구사항. 이를 위해 신규 주문 시스템에서 주문이 생성되거나 변경되면 그 데이터를 기존 주문 시스템에 전달해야했음
하지만 신규 주문 시스템 개발조직은 연동 코드 추가에 난색 표함.일정 여유 없고 이미 코드 복잡해 코드 추가가 부담됨. 이때 CDC 이용!
CDC 처리기가 변경 감지했을때 카프카로 변경 메시지를 보내고 카프카는 이를 구독하는 시스템에 전파하면된다.
카프카를 두면 대상 시스템들의 데이터 처리 속도에 맞추어서 알아서 메시지를 소비하면 되는 장점이 있다.