Amazon DocumentDB Serverless로 가변 워크로드를 설계하는 방법

피크 용량을 계속 유지해야 했던 문서형 DB의 문제

2025년 7월 31일 AWS는 Amazon DocumentDB Serverless를 정식 출시했다. 기존 Amazon DocumentDB는 클러스터 인스턴스 유형과 수를 직접 정하는 방식이어서, 안정적인 대용량 워크로드에는 적합하지만 트래픽의 일중 편차가 크거나 간헐적 급증이 있는 환경에서는 유휴 용량 비용이 남는다.

DocumentDB Serverless는 이런 가변 워크로드를 대상으로 온디맨드 자동 확장을 제공한다. 에이전틱 AI, 이벤트 기반 마이크로서비스, 개발·테스트 환경처럼 수요를 예측하기 어려운 상황에서 사용할 수 있으며, 피크 용량을 미리 프로비저닝하는 방식과 비교해 최대 90%의 비용 절감을 목표로 한다.

DCU가 수요에 맞춰 용량을 바꾸는 방식

DCU(DocumentDB Capacity Unit)는 약 2GiB 메모리와 이에 상응하는 CPU 및 네트워킹을 묶은 용량 단위다. 최소 0.5 DCU부터 최대 256 DCU까지 설정할 수 있고, 시스템은 CPU·메모리·네트워크 사용률을 추적해 현재 부하에 맞는 용량을 판단한다.

⤢✕

작은 용량에서는 0.5 DCU 단위로 세밀하게 증가하고, 현재 용량이 커질수록 더 큰 단위로 확장한다. 수백 배 수준의 갑작스러운 트래픽 증가에도 수십 초 이내에 충분한 용량을 확보하는 것을 목표로 한다.

유휴 상태에서 다시 활성화될 때도 동작을 고려해야 한다. 시스템은 최소 1.0–2.5 DCU 또는 설정된 MaxCapacity가 그보다 낮다면 해당 값까지 즉시 스케일업한다. 완전히 0으로 축소되는 일부 서버리스 서비스와 달리, 초기 응답 지연과 유휴 상태 과금 사이의 균형을 택한 방식이다.

MongoDB 호환성을 검증하며 서버리스로 옮기기

DocumentDB Serverless는 기존 Amazon DocumentDB와 동일한 MongoDB 호환 API를 제공한다. MongoDB 5.0 이상과 호환되는 드라이버를 사용할 수 있고, 읽기 복제본, Performance Insights, I/O-Optimized 스토리지, AWS 서비스 연동도 지원한다.

다만 MongoDB와 DocumentDB의 동작이 모두 같은 것은 아니다. 집계 파이프라인 스테이지, 일부 명령과 옵션, 트랜잭션, 멀티-도큐먼트 ACID, 일부 인덱스 유형에서는 차이가 생길 수 있다. 예를 들어 텍스트 인덱스의 일부 기능은 차이가 발생할 수 있으므로, 전환 전에 애플리케이션 수준의 테스트가 필요하다.

기존 프로비저닝 클러스터는 데이터 마이그레이션 없이 인스턴스 유형 전환 방식으로 서버리스화할 수 있다.

⤢✕

AWS가 권장하는 흐름은 기존 클러스터에 서버리스 인스턴스를 리더로 추가한 뒤, 실제 읽기 트래픽에서 DCU 변동 패턴을 관찰하는 것이다. 이후 DocumentDB 페일오버 메커니즘으로 해당 인스턴스를 Writer로 승격하고, 클라이언트 엔드포인트를 바꾸지 않은 채 프로비저닝 인스턴스를 제거한다.

연결 수와 읽기 부하를 따로 다루기

Lambda 같은 무상태 컴퓨팅 레이어와 연결하면 커넥션 폭발이 발생하기 쉽다. AWS는 이를 위해 경량 MongoDB 커넥션 풀러인 mongobetween을 제공한다. 다수의 인입 연결을 DocumentDB 클러스터로 향하는 적은 수의 연결 풀로 다중화해 커넥션 수를 제어한다.

풀 설정에서는 다음 항목을 함께 봐야 한다.

minPoolSize: 기본 트래픽을 처리할 최소 커넥션을 미리 확보한다.
maxWaitTime: 풀이 고갈됐을 때 빠르게 실패(fail fast)할 수 있도록 충분히 짧게 설정한다.
재시도 로직(retry logic): 일시적인 스케일 전환 구간에서 발생할 수 있는 연결 오류에 대비한다.

읽기 트래픽이 큰 애플리케이션은 리더 인스턴스를 추가해 Writer와 읽기 부하를 분리할 수 있다. 서버리스 리더도 DCU 기반 자동 확장 대상이므로 읽기 요청이 급증할 때 용량이 함께 조정된다.

⤢✕

에이전틱 AI 워크로드에서는 MCP(Model Context Protocol) 연동을 공식 지원한다. 에이전트가 태스크를 실행하지 않는 시간에는 DCU가 최솟값으로 수렴하고, 복잡한 쿼리나 대용량 데이터 처리가 필요할 때 자동으로 스케일업하는 특성이 이런 접근 패턴과 맞는다.

Atlas Serverless와 비교할 때 보는 기준

비교 항목	Amazon DocumentDB Serverless	MongoDB Atlas Serverless
용량 단위	DCU (2 GiB 메모리 + CPU)	RPU (Read Processing Unit) / WPU
최소 용량	0.5 DCU	지정 없음 (사용량 기반)
최대 용량	256 DCU	제한 없음 (Atlas 기준)
MongoDB 호환성	MongoDB 5.0 이상 API 수준 호환	네이티브 MongoDB (완전 호환)
멀티 클라우드	AWS 전용	AWS, GCP, Azure
AWS 서비스 통합	VPC, IAM, CloudWatch, KMS 네이티브	별도 PrivateLink 구성
벡터 검색	내장 지원	Atlas Vector Search 지원
콜드 스타트	최소 1.0–2.5 DCU 즉시 확보	설정에 따라 다름
비용 절감 잠재력	피크 프로비저닝 대비 최대 90%	사용량에 따라 상이

AWS 중심 아키텍처라면 IAM, VPC, CloudWatch와의 네이티브 통합이 강점이다. 멀티 클라우드 전략이나 순수 MongoDB 기능의 완전성이 우선이면 MongoDB Atlas가 더 적합할 수 있다.

사용량 기반 과금이 유리한 조건

⤢✕

개발·테스트 환경처럼 업무 시간에 사용이 몰리고 야간과 주말에는 거의 유휴 상태인 경우, 특정 세일이나 캠페인에서만 트래픽이 급증하는 이벤트 기반 워크로드, 배치 사이의 유휴 구간이 긴 에이전틱 AI 파이프라인, 초기 트래픽을 예측하기 어려운 신규 서비스가 대표적인 대상이다.

반대로 24시간 안정적인 대용량 트래픽이 지속되면 프로비저닝 방식이 더 비용 효율적일 수 있다. 최소 $30/월은 최솟값이며, 실제 비용은 DCU 사용량과 스토리지, I/O 패턴에 따라 달라진다.

I/O 패턴에 맞춘 스토리지 선택

DocumentDB Serverless는 Standard와 I/O-Optimized 스토리지를 제공한다.

Standard는 I/O 비용이 별도로 청구되는 기본 구성으로, I/O 사용량이 상대적으로 낮을 때 유리하다. I/O-Optimized는 I/O 비용 예측 가능성을 우선하거나 I/O 집약적 워크로드에 맞춰진 구성이다. I/O 비용이 클러스터 총 지출의 25%를 초과하면 더 나은 가격 대비 성능을 제공한다.

복잡한 집계 쿼리와 대량 도큐먼트 스캔이 발생하는 에이전틱 AI 워크로드에서는 I/O-Optimized가 비용 예측성을 높여줄 수 있다.

상한 설정과 관측 지표

CloudWatch에서는 DCU 사용률, 커넥션 수, 쿼리 지연 시간 같은 핵심 지표를 추적할 수 있다. Performance Insights를 연결하면 쿼리 성능 병목을 시각화할 수 있고, DCU 임계값에 CloudWatch 알람을 설정하면 예상하지 못한 트래픽 증가를 빠르게 감지할 수 있다.

운영에서 특히 신경 쓸 값은 MaxCapacity다. 상한이 너무 낮으면 트래픽 급등 때 성능 저하가 생기고, 너무 높으면 비용 통제가 어려워진다. 초기에는 예상 최대치의 1.5–2배로 설정한 후 실측 데이터를 바탕으로 조정하는 방식이 권장된다.

DocumentDB Serverless는 용량 관리 부담을 줄이는 선택지지만, 모든 워크로드에 같은 경제성을 제공하지는 않는다. 트래픽의 변동성, MongoDB 기능 호환성, 멀티 클라우드 필요성, I/O 비중을 함께 비교한 뒤 선택해야 한다.