미리캔버스, Amazon DocumentDB 전환으로 성능 UP! 비용 DOWN!
미리캔버스는 실시간 협업 디자인 플랫폼의 IOPS 병목 현상과 비용 문제 해결을 위해 Amazon DocumentDB로 전환
Amazon DocumentDB는 Aurora 기반 MongoDB 호환 엔진으로, IO-Optimized 스토리지를 통해 IOPS 병목을 근본적으로 해소
전환 결과, DB 응답 속도 50% 개선, Replication Lag 93% 감소, 인프라 비용 30% 절감이라는 괄목할 만한 성과를 달성
Amazon DocumentDB 아키텍처 심층 분석
Amazon DocumentDB는 Amazon Aurora를 기반으로 구축되어, 기존 MongoDB Atlas와는 근본적인 아키텍처 차이를 보인다. 특히, 분산 스토리지(Distributed Storage)를 활용하여 데이터의 내구성과 가용성을 확보한다.
6개의 스토리지 사본(Storage Copies)에 데이터를 저장하며, 4/6 쿼럼(Quorum) 방식으로 쓰기 연산을 처리
리플리카(Replica)는 Primary의 redo log를 직접 읽어, 복제 지연 시간(Replication Lag)을 획기적으로 단축
IO-Optimized 스토리지 구성으로 IOPS 제한 없이 IO 집약적인 워크로드(IO-intensive Workload)를 처리 가능
이러한 아키텍처는 쓰기 성능(Write Performance)과 읽기 일관성(Read Consistency) 사이의 균형을 맞추며, 대규모 트래픽 환경에 적합하다.
MongoDB Atlas vs Amazon DocumentDB: 주요 차이점
MongoDB Atlas와 Amazon DocumentDB는 모두 MongoDB 호환 데이터베이스이지만, 내부 동작 방식과 성능 특성에서 차이를 보인다. 특히, 복제(Replication) 방식과 스토리지 엔진(Storage Engine)의 차이가 두드러진다.
복제 단위(Replication Unit): Atlas는 oplog 기반, DocumentDB는 redo log(LSN 기반)
스토리지 엔진(Storage Engine): Atlas는 WiredTiger, DocumentDB는 Aurora 분산 스토리지
읽기 일관성(Read Consistency): Atlas는 Read Concern 설정, DocumentDB는 MVCC + LSN 기반
이러한 차이로 인해 DocumentDB는 Replication Lag 감소(Replication Lag Reduction), IOPS 병목 해소(IOPS Bottleneck Relief), 쓰기 성능 향상(Write Performance Improvement) 등의 이점을 제공한다.
AWS DMS를 활용한 마이그레이션 전략
미리캔버스는 AWS Database Migration Service(AWS DMS)를 활용하여 MongoDB Atlas에서 Amazon DocumentDB로의 마이그레이션을 수행했다. 무중단 전환은 어려웠지만, DMS의 다양한 기능을 활용하여 데이터 손실 없이 안전하게 마이그레이션을 완료했다.
Full Load: 전체 데이터 적재를 위해 DMS의 Full Load 기능을 사용, 병렬 로딩(Parallel Loading) 설정 최적화
CDC(Change Data Capture): Full Load 이후 변경분을 동기화하기 위해 CDC를 적용, oplog window 확보 및 CDC lag 모니터링
연결 전환(Connection Switching): AWS Secrets Manager를 활용하여 애플리케이션 재배포 없이 DB 연결 정보 변경
마이그레이션 과정에서 인덱스 사전 생성(Index Pre-creation), 병렬 로딩 설정(Parallel Loading Configuration), IO-Optimized 활용(IO-Optimized Utilization) 등의 DMS 베스트 프랙티스를 적용하여 효율성을 높였다.
마이그레이션 중 발생한 문제와 해결 과정
마이그레이션 과정에서 예상치 못한 문제들이 발생했지만, 철저한 분석과 빠른 대처를 통해 문제를 해결하고 시스템 안정성을 확보했다. 특히, CDC(Change Data Capture) 처리량 저하로 인한 데이터 손실 위험에 직면했다.
CDC 처리량 저하: 프로덕션 환경에서 CDC 처리량이 저하되어 changeStream 포지션(ChangeStream Position)이 oplog window보다 뒤쳐짐
긴급 대응: 자체 CDC 시스템 구현, 누락 데이터 유형별 수동 복구
교훈: 프로덕션 수준의 쓰기 부하에서 CDC 처리량 사전 검증, 데이터 감사 체계(Audit Column, 백업 컬렉션) 구축
이러한 경험을 통해 마이그레이션 과정의 위험성을 인지하고, 데이터 손실 방지(Data Loss Prevention)를 위한 다각적인 노력을 기울였다.
운영 안정화를 위한 모니터링 및 인프라 구성
Amazon DocumentDB 운영 안정화를 위해, 인스턴스 구성 및 모니터링 체계를 구축했다. 특히, IO-Optimized 스토리지를 활용하여 IOPS 병목을 해소하고, 시스템 성능을 지속적으로 모니터링했다.
인스턴스 구성: db.r6g.2xlarge 3대 구성, IO-Optimized(iopt1) 스토리지 사용
Failover: 30초 이내 복구 확인, serverSelectionTimeoutMS 설정
모니터링: Amazon CloudWatch Metric Stream을 활용, CPU, IOPS, 메모리 등 핵심 지표 실시간 모니터링
Working Set 대비 RAM 비율: IO-Optimized 모드의 효과를 지속적으로 검증
이러한 노력을 통해 시스템의 가용성을 높이고, 장애 발생 시 빠른 복구(Fast Recovery)를 가능하게 했다.