변경 데이터 캡처(CDC) 깊이 알기
문제 정의 (What & Why)
Section titled “문제 정의 (What & Why)”아마존, 넷플릭스, 우버 등 규모가 큰 서비스의 경우 대부분 마이크로서비스 아키텍처(MSA, Microservice Architecture)를 채택하고 있습니다.
이러한 아키텍처에서 반드시 해결해야하는 문제가 바로 다양한 역할을 맡고 있는 여러 시스템 간에 데이터를 일관성 있게, 그리고 신속하게 연동하는 것입니다.
예를 들어, 고객이 아마존에서 주문을 완료하는 상황을 생각해 봅시다.
이 때 주문 완료라는 하나의 이벤트는 단순히 주문 정보가 데이터베이스에 저장되는 것에서 끝나지 않습니다.
왜냐하면 즉시 물류 시스템으로 전달되어 배송 준비를 시작해야 하고, 고객에게는 주문 확인 알림이 발송되어야 하며, 동시에 데이터 분석 플랫폼에서는 실시간 판매 현황을 집계해야 하기 때문이죠.
이처럼 여러 시스템에 걸쳐 데이터 변경 사항을 안정적으로, 그리고 실시간으로 전파해야 하는 복잡한 요구사항을 효과적으로 해결하기 위한 기술이 바로 변경 데이터 캡처(CDC, Change Data Capture) 입니다.
변경 데이터 캡처(CDC)란 무엇인가?
Section titled “변경 데이터 캡처(CDC)란 무엇인가?”변경 데이터 캡처(CDC, Change Data Capture) 의 정의는 데이터베이스에서 데이터가 새로 생성(INSERT), 수정(UPDATE), 또는 삭제(DELETE)될 때 이러한 변경 사항을 식별하고 추적하여, 다른 시스템이나 프로세스가 이 변경 내역을 활용할 수 있도록 하는 기술적 방법론 또는 패턴의 집합입니다.
쉽게 말하자면 데이터베이스의 변경 내역을 실시간으로 구독하는 알람 시스템이라고 이해하면 좋을 것 같습니다.
이렇게 캡처된 변경 데이터는 실시간 데이터 복제, 데이터 통합, 백업 및 재해 복구 시스템 구축, 비즈니스 인텔리전스(BI, Business Intelligence) 분석을 위한 실시간 데이터 공급, 데이터 레이크로의 데이터 전송 등 다양한 목적으로 활용됩니다.
CDC의 주요 구현 방식
Section titled “CDC의 주요 구현 방식”CDC를 구현하는 방식에는 크게 3가지가 있으며, 당연하게도 각 방식마다 장단점이 존재합니다.
타임스탬프(Timestamp) 기반 방식
Section titled “타임스탬프(Timestamp) 기반 방식”타임 스탬프 기반 방식은 테이블에 LAST_UPDATED_AT과 같은 마지막 수정 시간을 기록하는 컬럼을 추가하는 방식입니다.
이 컬럼을 기준으로 특정 시간 이후에 변경된 데이터를 주기적으로 조회하여 어떤 변경 사항이 있는지 확인하는 방식이죠.
구현은 비교적 간단하지만 데이터 삭제(DELETE)를 감지하기 어렵고 변경이 매우 빈번한 경우 일부 변경을 놓칠 수 있으며, 실시간성이 떨어지는 단점이 있어 최근에는 잘 사용되지 않습니다.
데이터베이스 트리거(Trigger) 기반 방식
Section titled “데이터베이스 트리거(Trigger) 기반 방식”데이터베이스 트리거 기반 방식은 데이터베이스 테이블에 INSERT, UPDATE, DELETE 작업이 발생할 때마다 자동으로 실행되는 트리거를 설정하는 방식입니다.
이렇게 설정된 트리거가 변경된 데이터의 내역을 별도의 변경 이력 테이블 같은 곳에 기록하는 방식이죠.
데이터베이스 트리거 기반 방식은 변경 사항을 놓치지 않고 비교적 정확하게 잡아낼 수 있지만, 모든 테이블에 트리거를 생성하고 관리해야 하는 부담이 있습니다.
또한, 트리거가 운영 데이터베이스 내에서 직접 동작하므로 데이터베이스 자체에 부하를 줄 수 있다는 단점이 있습니다.
트랜잭션 로그(Transaction Log) 스캐닝 방식
Section titled “트랜잭션 로그(Transaction Log) 스캐닝 방식”트랜잭션 로그 스캐닝 방식은 현재 가장 많이 사용되는 방식입니다.
대부분의 데이터베이스 시스템이 내부적으로 모든 데이터 변경 작업의 내역을 순서대로 기록하는 트랜잭션 로그 파일(MySQL의 바이너리 로그(binlog), PostgreSQL의 WAL(Write-Ahead Log))이 존재하는데요, 이 파일을 직접 읽어 변경 사항을 분석하는 방식입니다.
이 방식은 운영 데이터베이스에 직접적인 조회 부하를 거의 주지 않으면서, 삭제된 내용을 포함한 모든 변경 사항을 안정적으로 감지할 수 있습니다.
또한 개발자의 실수로 관련 로직이 누락될 걱정도 없으며, 변경 사항이 즉시 기록되므로 실시간 처리에 가장 유리한 방식이죠.
대표적으로 Debezium과 같은 오픈소스 CDC 도구들이 이 방식을 활용하여 다양한 데이터베이스의 변경 로그를 읽고, 이를 변경 이벤트로 만들어 Apache Kafka와 같은 메시지 큐 시스템으로 전달합니다.
그러면 다른 마이크로서비스나 데이터 파이프라인이 이 Kafka 토픽을 구독하여 변경된 데이터를 실시간으로 소비할 수 있게 되죠.
CDC 도입의 핵심적인 이유
Section titled “CDC 도입의 핵심적인 이유”CDC를 도입하게 되는 핵심적인 이유는, 일반적으로 대규모 서비스가 단일 시스템으로 운영되기보다는 각기 다른 역할을 수행하는 여러 마이크로서비스, 외부 연동 시스템, 데이터 분석 플랫폼 등으로 복잡하게 얽혀 구성되는 경우가 많기 때문입니다.
예를 들어, 전자상거래 플랫폼에서 고객이 상품을 주문하고 결제를 완료했다고 가정해 봅시다.
글 초반에 언급했듯이 주문 완료라는 하나의 이벤트는 단순히 주문 데이터베이스에 기록되는 것에서 끝나지 않죠. 아래의 내용이 같이 일어나야 합니다.
- 실시간 알림: 고객에게는 주문 확정 알림(이메일, SMS 등)이 즉시 발송되어야 합니다.
- 재고 관리: 해당 상품의 재고는 실시간으로 차감되어 다른 고객이 품절된 상품을 주문하는 상황을 막아야 합니다.
- 물류 시스템 연동: 물류팀에서는 새로운 배송 요청을 즉시 인지하고 준비를 시작해야 합니다.
- 데이터 분석: 마케팅팀이나 데이터 분석팀은 실시간으로 발생하는 주문 데이터를 통해 프로모션 효과를 분석하거나 고객 행동 패턴을 파악할 수 있어야 합니다.
만약 이러한 과정에서 데이터 동기화가 지연되거나 누락된다면 어떻게 될까요?
고객은 주문 상태를 제때 알 수 없어 불안해하고, 품절된 상품이 계속 판매되어 고객 불만과 운영 비효율을 초래하며, 물류 처리가 늦어져 배송 지연이 발생할 수 있습니다.
과거에는 이러한 문제를 해결하기 위해 각 애플리케이션(주문, 알림, 재고, 물류 등)이 변경 사항을 인지하고 다른 시스템의 API를 직접 호출하거나, 메시지 큐(Message Queue)에 직접 이벤트를 발행하는 등의 추가적인 개발 리소스를 사용해야 했습니다.
혹은 주기적으로 원본 데이터베이스를 조회하여 변경분을 가져오는 배치(batch) 방식을 사용했지만 이는 실시간성을 보장하기 어렵고, 운영 데이터베이스에 반복적인 조회 부하를 주어 전체 시스템 성능에 악영향을 미칠 수 있었습니다.
때문에 CDC, 특히 트랜잭션 로그 스캐닝 방식을 도입하기 시작했고, 위에서 언급한 복잡성과 부담을 크게 줄일 수 있게 되었습니다.
CDC 도입 시 주의사항
Section titled “CDC 도입 시 주의사항”변경 데이터 캡처(CDC)를 도입할 때 꼭 확인하면 좋은 사항이 크게 4가지가 있습니다.
CDC 시스템의 성능 영향 및 자원 사용량 예측
Section titled “CDC 시스템의 성능 영향 및 자원 사용량 예측”CDC 솔루션 자체도 하나의 소프트웨어이므로 시스템 자원(CPU, 메모리, 네트워크 등)을 소모합니다.
특히, 데이터 변경량이 매우 많은 운영 환경에서는 CDC 프로세스가 원본 데이터베이스나 연관 시스템에 예상치 못한 성능 부하를 유발할 수 있습니다.
따라서 도입 전 충분한 성능 테스트를 통해 CDC 시스템이 사용할 자원량을 예측하고, 피크 타임의 부하를 견딜 수 있는지, 병목 현상이 발생하지는 않을지 등을 반드시 확인해야 합니다.
데이터베이스 스키마 변경 시 대응 전략 수립
Section titled “데이터베이스 스키마 변경 시 대응 전략 수립”운영 중인 데이터베이스의 테이블 구조나 컬럼 속성(스키마)은 비즈니스 요구사항에 따라 언제든지 변경될 수 있습니다.
이때, 스키마 변경이 CDC 파이프라인에 어떤 영향을 미치는지, 변경 사항이 어떻게 자동으로 감지되고 적용되는지에 대한 명확한 대응 전략과 절차를 수립해야 합니다.
만약 스키마 변경에 제대로 대응하지 못하면 CDC 프로세스가 중단되거나 잘못된 데이터를 전송하여 데이터 불일치 문제가 생길 수 있습니다.
초기 데이터 동기화(스냅샷)의 부담과 영향 최소화
Section titled “초기 데이터 동기화(스냅샷)의 부담과 영향 최소화”CDC를 통해 실시간 변경분을 스트리밍하기 전에 일반적으로 원본 데이터베이스의 전체 데이터를 복제하는 초기 스냅샷 과정이 필요합니다.
만약 원본 데이터의 양이 방대할 경우엔 이 스냅샷 과정이 상당한 시간과 시스템 자원을 소모하며, 운영 시스템의 서비스 응답성에 영향을 줄 수 있습니다.
따라서 스냅샷 작업 시간, 시스템 부하, 네트워크 사용량 등을 사전에 철저히 예측하고, 서비스 영향이 적은 시간대를 선택하거나 점진적인 스냅샷 방법을 고려하는 등 그 영향을 최소화할 방안을 마련해야 합니다.
데이터베이스 로그 보존 정책과 CDC의 연관성 검토 (로그 기반 CDC의 경우)
Section titled “데이터베이스 로그 보존 정책과 CDC의 연관성 검토 (로그 기반 CDC의 경우)”트랜잭션 로그 스캐닝 방식의 CDC는 데이터베이스의 로그 파일에 전적으로 의존합니다.
만약 데이터베이스 서버의 로그 보존 기간이 너무 짧게 설정되어 있거나 로그 파일이 예상치 못하게 삭제될 경우엔, CDC 시스템이 변경 사항을 제대로 읽어가지 못해 데이터 유실이 발생할 수도 있습니다.
따라서 CDC 시스템의 안정적인 운영을 위해 데이터베이스 로그가 충분한 기간 동안 안전하게 보존되도록 정책을 수립해야합니다.
이러한 고려사항들을 사전에 충분히 검토하고 대비책을 마련한다면, CDC 도입으로 인한 예상치 못한 문제를 최소화하고 그 효과를 극대화할 수 있을 것입니다.
변경 데이터 캡처(CDC)는 데이터베이스의 변경 사항을 실시간으로 추적하고 전파하는 매우 유용한 기술입니다.
특히 트랜잭션 로그 스캐닝 방식은 운영 시스템의 부하를 최소화하면서 안정적으로 변경을 감지할 수 있어 현대적인 데이터 아키텍처에서 핵심적인 역할을 수행하죠.
CDC를 통해 얻은 실시간 변경 이벤트는 단순히 데이터를 복제하는 것을 넘어, 시스템 전체를 이벤트 기반 아키텍처(EDA, Event-Driven Architecture)로 발전시키는 데 중요한 역할을 할 수 있습니다.
이 글을 통해 데이터 가치를 실시간으로 활용하고, 더 나은 의사결정과 서비스를 제공할 수 있는 기회가 되면 좋겠습니다.