피드로 돌아가기
InfoQInfoQ
Database

5.5 nines 신뢰성 확보를 위한 MongoDB Zero-Downtime 데이터 이동 플랫폼 구축

Presentation: Stripe’s Docdb: How Zero-Downtime Data Movement Powers Trillion-Dollar Payment Processing

Jimmy Morzaria2026년 4월 30일29advanced

Context

초기 MongoDB 단일 샤드 구조에서 데이터 증가에 따라 수천 개의 샤드로 확장하며 관리 복잡도 증가. 기존 수동 관리 방식의 'Pet' 모델로는 Petabytes급 데이터와 5M+ QPS를 처리하는 5.5 nines 신뢰성 유지가 불가능한 한계 직면.

Technical Solution

  • 데이터 이동 자동화를 통한 'Herd' 방식의 인프라 확장 모델 전환
  • 내부 개발한 Database Proxy 및 Routing Metadata Service를 통한 Sharding 추상화로 MongoDB 기본 mongos 의존성 제거
  • Snapshot 기반 Bulk Ingestion과 Write Replication 단계를 분리한 데이터 마이그레이션 파이프라인 설계
  • 서비스 중단 없는 데이터 이동을 위해 Source와 Target 간의 실시간 복제 및 검증 프로세스 구현
  • 과도한 Retry로 인한 시스템 부하 방지를 위해 Proxy 레이어에서 최적화된 재시도 전략 적용
  • Aggregation Pipeline 사용을 배제하여 단순하고 예측 가능한 쿼리 경로 유지

Impact

  • 연간 $1.4 Trillion 규모의 결제 처리 인프라 지원
  • 2,000개 이상의 Database Shard로 확장하여 Petabytes급 데이터 분산 처리
  • 타겟 샤드당 하루 평균 1.5TB ~ 2TB의 데이터 Bulk Ingestion 성능 확보
  • 5M+ QPS 처리 환경에서 5.5 nines(99.9995%)의 고가용성 달성

Key Takeaway

대규모 데이터베이스 확장 시 벤더 제공의 기본 Sharding 기능에 의존하기보다, 자체 Proxy 레이어를 통해 라우팅 제어권을 확보함으로써 Zero-Downtime 마이그레이션과 유연한 확장성을 동시에 달성할 수 있음.


- 데이터 마이그레이션 시 Bulk Load 단계와 Incremental Replication 단계를 명확히 분리하여 설계했는가 - DB 엔진의 기본 라우터(mongos 등) 대신 자체 Proxy를 통해 트래픽 제어 및 Retry 전략을 커스터마이징할 수 있는가 - 인프라 관리 모델을 개별 서버 관리(Pet)에서 자동화된 플릿 관리(Herd)로 전환하기 위한 추상화 계층이 존재하는가

원문 읽기