Data Eng Wiki

How We Cut Our CDC Bill from $3,000 to $150 a Month

12 min read

How We Cut Our CDC Bill from 150 a Month

Author: Sarthak Tripathy (Jimdo) | Source: jimdoverse.com | Published: 2026-08-20

한 줄 요약

70개 샤드 MySQL에 단일 스트림 CDC 모델을 적용하니 인프라가 부하가 아니라 샤드 수에 따라 증가했고, CDC를 데이터베이스를 소유한 팀에 되돌려준 것이 도구 선택만큼이나 큰 개선이었다.

핵심 주장/내용

  • 문제 구조: Jimdo Creator는 고write OLTP에 튜닝된 12개 MySQL 노드에 걸친 약 70개 샤드. CDC 도구는 애플리케이션 테이블을 질의하는 대신 binlog를 읽는데, 샤드 구성에서는 각 노드가 그 위의 모든 샤드 DB를 커버하는 자기 binlog와 자기 오프셋·rotation 동작을 가지므로 CDC 시스템이 그것들을 전부 병렬 추적해야 한다
    • 이 아키텍처의 CDC는 DB 노드당 독립 binlog 스트림을 소비하고, 불균형한 인프라 증가 없이 샤드 수에 따라 옆으로 확장하고, lag나 backpressure 없이 피크 write rate를 따라가고, 스키마 마이그레이션·버전 업그레이드·설정 변경에서 살아남아야 한다
  • DMS가 안 맞게 된 이유:
    • 인프라가 부하가 아니라 샤드 수에 따라 증가했다. 약 70개 샤드에 7개 공유 replication 인스턴스에서 약 70개 DMS CDC 태스크가 돌았고(인스턴스당 약 10샤드), 샤드가 늘면 태스크가 늘고 결국 더 크거나 많은 인스턴스가 필요했다. 결과적으로 거의 유휴 상태인 샤드가 아주 바쁜 샤드와 비슷한 비용을 냈다
    • 청구서 대부분이 예약 용량이었다. 월 약 $3,000의 대부분이 always-on replication 인스턴스에서 왔고, DMS Serverless를 유사 워크로드에 테스트했지만 비용이 여전히 실제 변경 볼륨이 아니라 태스크별 용량을 따라가서 유의미한 절감이 없었다
    • 소유권이 뒤집혀 있었다. Creator 팀이 DB를 소유하고 데이터를 생산하는데 Data Platform 팀이 DMS 태스크와 인프라를 소유했다. Creator가 binlog 파라미터를 바꾸거나 MySQL 업그레이드를 해서 CDC를 깨뜨릴 수 있고, Data Platform은 자기가 만들지도 않았고 예상할 수도 없었던 변경이 유발한 실패를 디버깅해야 했다
    • 일상적 DB 작업이 그것을 깨뜨렸다. 스키마 마이그레이션과 버전 업그레이드가 정기적으로 DMS 태스크를 stall·에러 상태·replication 위치 상실로 밀어넣었고, 복구는 종종 태스크 재시작·전체 reload·팀 간 조율을 의미했다. 70샤드에서 이것이 많은 계획 외 작업으로 쌓였다
  • 대체재의 5가지 요구사항 (우선순위 순):
    1. Producer 소유권 — DB를 소유하고 바꾸는 팀이 CDC의 정확성과 건강을 소유해야 한다. 깨뜨릴 수 있는 사람이 고칠 수 있어야 한다
    2. 샤드 확장성 — 샤드 수가 변해도 샤드당 비용과 복잡도가 평평하게 유지되고 공유 병목이나 중앙 coordinator가 없어야 한다
    3. 운영 단순성 — 큰 always-on replication 서버 없이, 실패 모드가 적고, 복구가 단순
    4. 비용 효율 — 비용이 실제 처리하는 변경 볼륨을 따라가야 한다
    5. 통합 호환성 — 출력이 Kafka에 랜딩해 기존 인제스션·처리 파이프라인에 플러그인
  • 세 후보:
    • AWS DMS — 완전 관리형이고 작거나 샤드되지 않은 DB에는 괜찮다. 이 구성에서는 비용이 샤드 수를 따라 증가하고 always-on 인스턴스가 일을 하며 DB 측 변경이 producer 팀이 볼 수 없는 태스크를 계속 깨뜨렸다. 배제
    • Debezium — 성숙하고 널리 쓰이며 표준화된 이벤트 포맷과 강한 생태계. 문제는 producer에 대한 운영 부담이었다. Debezium 커넥터는 샤드마다 배포·설정·생명주기 관리·모니터링이 필요하고 producer 팀이 운영하는 안정적 Kafka Connect 환경을 원한다. Creator 팀의 일은 Creator 플랫폼을 돌리는 것이고 Kafka Connect estate를 그 접시에 더하는 것은 운영 단순성 요구를 충족하지 못했다. 기술적으로 강하지만 맞지 않는 fit
    • Maxwell — MySQL binlog를 읽어 구조화된 JSON 변경 이벤트를 방출하는 경량 데몬. DB 노드당 인스턴스 하나, 중앙 조율 없음. Kafka 네이티브 출력, 재시작·스키마 변경에 관대, 백필용 내장 bootstrap, 저렴한 운영. 5가지 요구를 모두 충족해 선택
  • 새 아키텍처와 소유권: MySQL 샤드 → Maxwell → Kafka → S3 → Snowflake. 각 홉에 하나의 오너
    • Maxwell이 추출 — DB 노드당 인스턴스 하나가 그 노드 binlog에서 그 위의 모든 샤드 데이터를 읽는다. 12개 인스턴스가 70샤드 전부를 커버. Creator 팀이 Data Platform 지원을 받아 K8s에 배포
    • Kafka가 전송 — 모든 CDC 이벤트가 Kafka에 랜딩. MSK 클러스터는 Cloud Platform 팀이 운영하며 producer와 consumer 사이의 durable 경계
    • Data Platform이 인제스트·모델링 — 전용 EKS의 Kafka Connect가 Kafka → S3, 거기서 Snowflake로
    • CDC를 DB 변경 중에 깨뜨릴 수 있는 팀이 이제 고치는 것을 소유하고, 그것이 모든 인시던트를 느리게 만들던 루프를 닫았다
  • 관측성 — 각 레이어가 자기 책임에 대해 보고: Maxwell(binlog-to-event lag + 노드별 실패·재시작·bootstrap 실행 — 소유한 Creator 팀이 모니터링), Kafka와 커넥터(브로커 건강, consumer lag, 커넥터 에러율), 스토리지와 웨어하우스(인제스션 잡 건강, 마지막 로드 파티션 이후 시간), freshness(지금과 테이블별 최신 이벤트 사이의 격차). 알림 임계가 인제스션 SLA에 매핑 — 일별 파이프라인의 최대 허용 lag 같은 것
    • 거버넌스도 같은 경계를 탄다 — 스트림·스토리지·웨어하우스 객체 접근이 인프라 role과 웨어하우스 RBAC를 통과하고, 전송·저장 중 암호화, 모델링 레이어의 PII 컬럼 마스킹·접근 통제, 감사용 접근 로깅
  • 인시던트 관리: Maxwell이 자기 binlog 위치를 추적하므로 재시작 후 멈춘 곳에서 재개한다. 대부분의 복구가 프로세스 재시작 하나. DMS에서는 stall된 태스크가 두 팀에 걸쳐 조율된 전체 테이블 reload를 의미했고 producer 팀이 언제 집을 수 있느냐에 따라 보통 6시간~3일이 걸렸다
    • 이벤트가 S3에 20일 보존으로 durable하게 랜딩하므로 예상치 못한 문제는 재인제스션 프로젝트가 아니라 replay다. 실패가 격리된다 — 한 노드의 Maxwell이 죽어도 나머지 11개는 무사
    • 백필은 Maxwell 내장 bootstrap이 현재 테이블 상태를 읽어 라이브 변경과 같은 Kafka 경로로 변경 이벤트로 방출한다. 별도 full-load 메커니즘을 만들거나 돌볼 필요가 없다

주요 수치 / 사실

  • 월 약 150 미만 (약 5%). warm하게 유지할 replication 서버가 없고, 각 Maxwell 프로세스가 작고 노드 로컬이고 독립적이라 한 노드의 문제가 그 노드에 머문다
  • 2025년 12월 완전 프로덕션 진입 이후 CDC 인시던트가 없었다. Creator 팀이 그 이후 Maxwell을 직접 멈추고 재시작하며 자기 일정으로 DB 업그레이드를 수행했고, Data Platform에서 아무것도 필요하지 않았으며 데이터를 잃지 않았다
  • 엔지니어링 교훈: CDC 도구를 데이터 아키텍처에 맞춰라 — 샤드된 백엔드는 shard-native CDC 아키텍처를 요구하고 70개 독립 binlog에 단일 스트림 모델을 적용하면 불필요한 비용과 운영 복잡도가 생긴다 / CDC를 producer와 함께 두라 — 데이터에 가장 가까운 팀이 정확성과 운영 둘 다 책임져야 하고, 이것이 불필요한 인계를 없애고 인시던트와 DB 마이그레이션 중 피드백 루프를 짧게 한다(이전 아키텍처의 운영 난제 대부분이 여기서 생겼다) / 요구를 충족하는 가장 단순한 도구를 골라라 — Debezium이 더 넓은 기능을 제공하지만 그 추가 능력이 필요하지 않았다 / 소유권을 일찍 정하라
  • 새 아키텍처의 운영 footprint가 DB 노드 수에 따라 증가하고 Creator 플랫폼이 시간이 지나며 샤드를 통합하면 자연히 감소한다
  • 개선을 이끈 세 가지 상보적 결정: 기저 아키텍처에 맞는 도구 선택, 실제 워크로드를 반영하는 비용 모델 채택, 명확한 소유권 경계 확립

관련 위키

Source: 원문 보기

그래프 뷰