본 게시글은 미리디의 김민석, 이효성, 노정훈님과 함께 작성하였습니다. 미리디의 미리캔버스 소개 ⇩ 미리디의 미리캔버스는 “누구나 쉽게, 함께 만드는 디자인” 이라는 철학 아래, 프레젠테이션부터 SNS 카드뉴스, 유튜브 썸네일, 포스터까지 일상의 모든 시각 콘텐츠를 브라우저 하나로 만들 수 있는 실시간 협업 디자인 플랫폼을 운영하고 있습니다. 기획자와 마케터가 같은 슬라이드를 동시에 수정하고, 팀원이 실시간으로 댓글을 달며 피드백을 주고받는 […] ||
본 게시글은 미리디의 김민석, 이효성, 노정훈님과 함께 작성하였습니다.
미리디의 미리캔버스 소개
⇩
미리디의 미리캔버스는 “누구나 쉽게, 함께 만드는 디자인” 이라는 철학 아래, 프레젠테이션부터 SNS 카드뉴스, 유튜브 썸네일, 포스터까지 일상의 모든 시각 콘텐츠를 브라우저 하나로 만들 수 있는 실시간 협업 디자인 플랫폼을 운영하고 있습니다.
기획자와 마케터가 같은 슬라이드를 동시에 수정하고, 팀원이 실시간으로 댓글을 달며 피드백을 주고받는 순간들 미리캔버스는 디자이너가 아니어도 누구나 전문적인 결과물을 만들 수 있도록 협업의 문턱을 낮추고 있습니다.
이러한 실시간 다중 사용자 편집 환경을 안정적으로 지원하기 위해서는, 수많은 사용자의 편집 이벤트를 밀리초 단위로 처리할 수 있는 데이터베이스 인프라가 핵심입니다. 기존에는 MongoDB Atlas를 사용하고 있었으나, 서비스가 성장하면서 IOPS 병목과 비용 문제에 직면했습니다. 이 블로그에서는 MongoDB Atlas에서 Amazon DocumentDB(withMongoDB compatibility)로 전환하면서 마주한 기술적 도전과 해결 과정, 그리고 실제 성과를 공유합니다.
전환 배경
IOPS 병목
MongoDB Atlas는 스토리지 볼륨 기반으로 IOPS가 제한됩니다. 저희 환경에서는 약 3,000 IOPS가 상한이었고, WiredTiger 스토리지 엔진의 dirty cache flush와 checkpoint 과정에서 이 한계에 자주 도달했습니다. 1분마다 수행되는 체크포인트 작업으로 IOPS 스파이크가 발생하면 쓰로틀링으로 인한 복제 지연이 뒤따랐고, 이는 사용자 경험에 직접적인 영향을 미쳤습니다. 평균적인 쓰기 워크로드 수준에서 provisioned IOPS 옵션을 선택하기에는 불필요한 비용 증가로 판단했습니다.
전환 목표
이러한 배경에서 다음 세 가지 목표를 설정하고 Amazon DocumentDB를 전환 대상으로 검토하기 시작했습니다.
IOPS 병목 근본적 해소
AWS 네이티브 서비스와의 통합 강화
인프라 비용 최적화
Amazon DocumentDB 아키텍처 이해
전환을 결정하기 전에 가장 먼저 이해해야 했던 것은, Amazon DocumentDB가 “managed MongoDB”가 아니라 Amazon Aurora 기반의 MongoDB 호환 엔진이라는 점입니다.
스토리지 아키텍처
Amazon DocumentDB는 Amazon Aurora와 동일한 분산 스토리지를 사용합니다. 데이터는 3개 가용 영역(AZ)에 걸쳐 6개의 복사본으로 저장되며, 쿼럼 기반으로 내구성을 보장합니다.
쓰기: 6개 복사본 중 4개에 기록되면 ACK (4/6 쿼럼)
읽기: 6개 중 3개에서 읽어 일관성 확인 (3/6 쿼럼)
각 AZ에 2개씩 — Full Segment(페이지+로그)와 Tail Segment(로그만)로 구성
⇩
[Figure 1] Amazon DocumentDB 스토리지 아키텍처 다이어그램
이 쿼럼 모델은 동기식 복제(가장 느린 스토리지 사본이 전체를 지연)와 비동기식 복제(장애 시 데이터 유실 가능)의 절충안입니다. 6개 사본 중 4개만 응답하면 쓰기가 완료되므로 응답이 느린 2개의 사본은 무시할 수 있고, 4개에 확실히 기록되므로 1~2개 사본에 장애가 발생해도 데이터는 안전합니다.
AZ 하나가 통째로 장애를 겪더라도(해당 AZ의 스토리지 사본 2개 손실) 나머지 4개 사본으로 쓰기가 가능하고, 거기서 추가로 1개가 더 장애가 나도 3개 사본으로 읽기가 가