MongoDB와 DynamoDB 비교: 클라우드 네이티브 트레이드오프

AWS DynamoDB와 MongoDB Atlas는 모두 클라우드 NoSQL 데이터베이스이지만 철학은 매우 다릅니다. DynamoDB는 AWS의 완전한 서버리스 NoSQL 서비스로, 관리할 서버가 없고 자동 확장이 지원되며 요청별로 요금이 부과됩니다. MongoDB Atlas는 관리형 클라우드 서비스이지만, 여전히 더 풍부한 운영 제어 기능을 제공하는 서버 클러스터를 기반으로 합니다. 선택은 대체로 인프라를 얼마나 직접 제어하고 싶은지, 쿼리 패턴이 얼마나 복잡한지에 따라 결정됩니다.

DynamoDB는 진정한 서버리스입니다. 선택해야 할 인스턴스도, 클러스터 규모를 결정할 필요도, 복제 세트 구성을 설정할 필요도 없습니다. AWS는 수요에 따라 읽기/쓰기 용량을 자동으로 확장하고, 샤딩을 보이지 않게 처리하며, 어떤 규모에서도 한 자릿수 밀리초의 지연 시간을 보장합니다. 운영 부담을 없애고 AWS와 긴밀하게 통합되기를 원하는 팀(IAM 역할, Lambda 트리거, Streams)에게 DynamoDB는 인프라와 관련된 여러 의사결정 자체를 없애 줍니다.

DynamoDB의 기본 접근 모델은 제한적입니다. 모든 테이블에는 파티션 키가 필수로 있고, 선택 사항인 정렬 키가 있을 수 있습니다. 항목은 파티션 키가 정확히 일치해야 조회되며, 필요하면 정렬 키 범위로 추가 필터링할 수 있습니다. 범용 쿼리 엔진은 없습니다. 임의 쿼리를 실행하려면 테이블 생성 시 설계한 글로벌 보조 인덱스(GSI)를 사용하거나, 비용이 높고 느린 전체 테이블 스캔을 수행해야 합니다. 따라서 Cassandra와 마찬가지로 접근 패턴을 먼저 정하고 스키마를 설계해야 합니다.

MongoDB Atlas는 자체 호스팅 MongoDB와 동일한 풍부한 쿼리 모델을 지원합니다. 여기에는 집계 파이프라인, $lookup 조인, 텍스트 검색, 지리 공간 쿼리, 복합 인덱스를 활용한 임의 필드 필터가 포함됩니다. 새 인덱스를 추가하기만 하면 출시 후에도 쿼리 패턴을 발전시킬 수 있습니다. 요구 사항이 자주 바뀌거나 설계 시점에 완전히 정해지지 않은 애플리케이션에서는 이러한 유연성이 큰 장점입니다.

DynamoDB는 두 가지 가격 책정 모드를 제공합니다. 온디맨드는 읽기/쓰기 요청마다 요금을 지불하는 방식으로, 예측하기 어려운 트래픽에 적합합니다. 프로비저닝은 용량 단위를 미리 예약하는 방식으로, 자동 확장이 적용되는 예측 가능한 작업 부하에서 더 저렴합니다. MongoDB Atlas는 클러스터 계층(인스턴스 크기와 스토리지)에 따라 요금을 부과하므로 부하가 일정할 때는 비용을 더 예측하기 쉽지만 트래픽이 적을 때는 더 비쌉니다. 이벤트 사이에 트래픽이 전혀 없는 급증형 또는 이벤트 기반 작업 부하에서는 DynamoDB의 요청당 과금이 훨씬 저렴할 수 있습니다.

DynamoDB는 더 넓은 AWS 생태계와 기본적으로 통합됩니다. DynamoDB Streams는 변경 이벤트를 생성하여 AWS Lambda 함수를 트리거합니다. AWS 내부에서 작동한다는 점을 제외하면 MongoDB Change Streams와 동일합니다. IAM 인증을 사용하면 별도의 데이터베이스 자격 증명을 관리할 필요가 없습니다. 특정 시점 복구와 백업도 몇 번의 클릭만으로 구성할 수 있습니다. 이미 AWS(Lambda, API Gateway, Cognito, S3)에 깊이 투자한 팀이라면 DynamoDB를 사용함으로써 작업 맥락을 전환하는 부담을 줄일 수 있습니다.

MongoDB Atlas는 AWS, Azure, GCP에서 실행되므로 한 클라우드 제공업체에 종속되지 않습니다. AWS와 Azure에 걸쳐 여러 리전에 분산된 클러스터를 배포할 수도 있습니다. 자체 서버에서 실행하는 자체 호스팅 MongoDB는 Atlas와 동작이 동일하므로 클라우드와 온프레미스 환경 사이를 이전할 수 있습니다. DynamoDB는 AWS에서만 사용할 수 있으며, 다른 환경으로 이전하려면 데이터 접근 계층을 다시 작성해야 합니다. 멀티 클라우드 전략이나 규정에 따른 데이터 저장 위치 요구 사항이 있는 조직에는 Atlas의 이식성이 큰 장점입니다.

DynamoDB는 최종 일관성 읽기(기본값: 지연 시간과 비용이 낮음)와 강한 일관성 읽기(지연 시간이 높고 비용이 2배)를 제공합니다. 쓰기 작업은 단일 항목 내에서 항상 강한 일관성을 유지합니다. 또한 DynamoDB는 여러 항목에 걸친 원자적 작업을 위해 트랜잭션(TransactWriteItems / TransactGetItems)을 지원하며, 트랜잭션 하나당 최대 100개의 항목을 처리할 수 있습니다. 이는 MongoDB의 여러 문서에 걸친 트랜잭션과 유사하지만 일반 읽기/쓰기 용량 단위의 두 배로 과금됩니다.

두 데이터베이스 모두 유연하고 스키마가 없는 문서를 지원합니다. DynamoDB 항목의 최대 크기는 400 KB이고, MongoDB 문서의 최대 크기는 16 MB입니다. 미디어 메타데이터가 풍부하거나 긴 텍스트 콘텐츠 또는 큰 중첩 구조를 다뤄야 한다면 MongoDB의 더 큰 문서 크기 제한이 중요합니다. DynamoDB의 400 KB 제한 때문에 큰 페이로드는 분할하거나 S3에 저장하고 DynamoDB에는 참조를 보관해야 하므로 복잡성이 증가합니다. 400 KB 이하의 일반적인 구조화 데이터에서는 이 제한이 문제가 되는 경우가 드뭅니다.

다음과 같은 경우 DynamoDB를 선택하십시오. 팀이 AWS 중심으로 운영되며 인프라 관리를 없애고 싶을 때, 트래픽이 급증형이거나 예측하기 어려울 때(Lambda 기반 API, 이벤트 기반 시스템), 접근 패턴이 단순하고 사전에 명확하게 정의되어 있을 때(키-값 조회와 정렬된 범위 조회), 또는 연결 풀을 관리하지 않고도 Lambda/IAM과 긴밀하게 통합해야 할 때입니다. REST API를 사용하고 DynamoDB에 대해 단순한 CRUD를 수행하는 단일 페이지 애플리케이션은 대표적인 적합 사례입니다.

다음과 같은 경우 MongoDB Atlas를 선택하십시오. 쿼리 패턴이 발전하거나 복잡할 때(집계, 조인, 전문 검색), 팀에 멀티 클라우드 또는 온프레미스 환경 간 이식성이 필요할 때, 문서가 400 KB보다 클 수 있을 때, Atlas Search, Vector Search 또는 Data Federation이 필요할 때, 또는 애플리케이션이 이미 로컬에서 MongoDB를 사용하고 있어 클라우드로 원활하게 이전하고 싶을 때입니다. 풍부한 분석 파이프라인이 핵심 요구 사항인 경우에도 MongoDB가 더 적합합니다.

이 수업에서는 다음을 배웠습니다. DynamoDB의 서버리스 모델과 AWS 중심 통합은 단순하고 사전에 정의된 접근 패턴을 사용하는 급증형 이벤트 기반 작업 부하에 적합합니다. MongoDB Atlas는 DynamoDB가 제공할 수 없는 더 풍부한 쿼리, 더 큰 문서, 멀티 클라우드 이식성을 제공합니다. 핵심적인 절충점은 운영의 단순성과 AWS 종속성(DynamoDB) 대 쿼리 유연성과 클라우드 간 자유(MongoDB)입니다. 다음에는 MongoDB 대신 Neo4j와 같은 그래프 데이터베이스를 언제 사용해야 하는지 살펴보겠습니다.