AWS DocumentDB 엔드포인트 구조와 권한 체계
AWS DocumentDB는 클라우드 네이티브 문서 데이터베이스로, 컴퓨팅과 스토리지를 분리한 독특한 아키텍처를 통해 고가용성과 확장성을 제공합니다. 가장 중요한 발견은 DocumentDB가 인스턴스 역할(프라이머리/레플리카)에 따라 쓰기 권한을 엄격히 제한하며, 이는 연결 방법과 무관하게 적용된다는 점입니다.
클러스터 엔드포인트와 읽기 엔드포인트의 차이점
DocumentDB는 세 가지 유형의 엔드포인트를 제공하며, 각각 다른 목적과 동작 방식을 가집니다.
클러스터 엔드포인트 (Cluster Endpoint)
클러스터 엔드포인트는 현재 프라이머리 인스턴스로 자동 연결되며 읽기와 쓰기 작업을 모두 지원합니다. 장애 조치(failover) 시 DNS CNAME 레코드가 자동으로 새로운 프라이머리 인스턴스를 가리키도록 변경되어, 일반적으로 30초 이내에 재연결이 완료됩니다. 형식은 sample-cluster.cluster-123456789012.us-east-1.docdb.amazonaws.com:27017과 같습니다.
읽기 엔드포인트 (Reader Endpoint)
읽기 엔드포인트는 사용 가능한 레플리카 인스턴스 간에 연결을 분산시키는 읽기 전용 엔드포인트입니다. 새로운 연결 요청마다 로드 밸런싱 알고리즘을 통해 레플리카 중 하나로 라우팅되며, 레플리카가 사용 불가능해지면 남은 레플리카로 연결이 재분배됩니다. 형식은 sample-cluster.cluster-ro-123456789012.us-east-1.docdb.amazonaws.com:27017입니다.
인스턴스 엔드포인트 (Instance Endpoint)
각 인스턴스는 고유한 엔드포인트를 가지며, 특정 인스턴스에 직접 연결할 수 있습니다. 그러나 장애 조치 시 인스턴스 역할이 변경될 수 있어 애플리케이션 사용에는 권장되지 않습니다.
개별 인스턴스 직접 접속 시 권한
인스턴스 레벨에서 쓰기 권한이 결정되는 것이 DocumentDB의 핵심 특징입니다. 연결 방법이 아닌 인스턴스의 역할이 권한을 결정합니다.
프라이머리 인스턴스에 직접 연결하면 읽기와 쓰기 작업을 모두 수행할 수 있습니다. 반면 레플리카 인스턴스에 직접 연결하면 읽기만 가능하며, 쓰기 시도 시 명시적인 오류 메시지가 반환됩니다. 이는 DocumentDB의 아키텍처적 제약사항으로, 단일 프라이머리 인스턴스만이 쓰기 작업을 처리하도록 설계되었기 때문입니다.
쓰기 작업은 3개의 가용 영역에 걸친 6개의 스토리지 사본 중 과반수에 기록되어야 승인되며, 이는 MongoDB의 {w:3, j:true} 쓰기 일관성과 동등한 수준입니다.
DocumentDB 클러스터 아키텍처
DocumentDB는 스토리지와 컴퓨팅을 분리한 클라우드 네이티브 아키텍처를 채택했습니다. 이는 전통적인 MongoDB와 가장 큰 차이점 중 하나입니다.
스토리지 레이어
클러스터 볼륨은 단일 가상 볼륨으로, 3개의 가용 영역에 걸쳐 데이터의 6개 사본을 유지합니다. 10GB 세그먼트로 데이터를 분할하며, 10GB에서 128TiB까지 자동으로 확장됩니다. 인스턴스 수와 관계없이 동일한 내구성을 제공하며, 지속적인 모니터링과 자동 복구 기능을 갖추고 있습니다.
컴퓨팅 레이어
클러스터당 0~16개의 인스턴스를 배포할 수 있으며, 하나의 프라이머리 인스턴스와 최대 15개의 레플리카 인스턴스로 구성됩니다. 모든 인스턴스는 동일한 클러스터 볼륨을 공유하지만, 프라이머리 인스턴스만이 쓰기 작업을 처리합니다. 인스턴스는 가용 영역에 자동으로 분산 배치되며, 클러스터 내에서 서로 다른 크기의 인스턴스를 혼용할 수 있습니다.
장애 조치 메커니즘
프라이머리 인스턴스 장애 감지 시 자동으로 레플리카 중 하나가 승격됩니다. 승격 우선순위는 0~15의 티어로 구성 가능하며(0이 가장 높음), 동일한 우선순위를 가진 경우 가장 큰 인스턴스가 선택됩니다. 클러스터 엔드포인트는 자동으로 새 프라이머리를 가리키도록 업데이트되어 애플리케이션 영향을 최소화합니다.
엔드포인트 사용 시 모범 사례
AWS는 명확한 엔드포인트 사용 지침을 제공합니다. 대부분의 애플리케이션은 레플리카 세트 모드(replicaSet=rs0)로 클러스터 엔드포인트를 사용해야 합니다. 이는 자동 장애 조치, 토폴로지 검색, 읽기 선호도 설정을 지원합니다.
워크로드별 권장사항
쓰기 중심 워크로드의 경우 클러스터 엔드포인트를 독점적으로 사용하고 프라이머리 인스턴스 크기를 확장합니다. 읽기 중심 워크로드는 secondaryPreferred 읽기 선호도와 함께 클러스터 엔드포인트를 사용하여 레플리카에 읽기를 분산시킵니다. 분석 쿼리와 같은 특수한 경우에만 더 큰 레플리카 인스턴스에 직접 연결하여 운영 워크로드와 격리할 수 있습니다.
연결 관리 최적화
MongoDB 클라이언트는 싱글톤 객체로 생성하고, 쿼리 패턴에 맞는 연결 풀 크기를 설정해야 합니다. AWS Lambda의 경우 핸들러 함수 외부에서 클라이언트를 초기화하여 연결을 재사용합니다. 인스턴스당 최대 4,500개의 연결을 지원하며, 연결 한도의 80%에서 CloudWatch 알람을 설정하는 것이 권장됩니다.
성능 최적화
DocumentDB는 인스턴스 RAM의 1/3을 서비스용으로 예약하므로, 실제 캐시로 사용 가능한 메모리는 2/3입니다. BufferCacheHitRatio 지표를 모니터링하여 100%에 가깝게 유지하고, 컬렉션당 인덱스를 5개 이하로 제한하며, 높은 카디널리티(중복 값 1% 미만) 필드만 인덱싱합니다.
MongoDB와의 주요 차이점
DocumentDB는 MongoDB와 호환성을 제공하지만 약 35%의 API 호환성만을 지원하며, 여러 중요한 차이점이 있습니다.
아키텍처적 차이
MongoDB의 전통적인 스토리지-컴퓨팅 결합 아키텍처와 달리, DocumentDB는 이를 분리하여 즉각적인 확장과 더 나은 내구성을 제공합니다. DocumentDB의 쓰기 내구성은 고정되어 있으며 변경할 수 없는 반면, MongoDB는 구성 가능한 쓰기 일관성 레벨을 제공합니다.
기능적 제한사항
DocumentDB는 admin 데이터베이스를 지원하지 않으며, MapReduce와 많은 집계 파이프라인 단계가 누락되어 있습니다. 트랜잭션은 DocumentDB 4.0 이상에서 지원되지만 제한사항이 있으며, MongoDB 집계 연산자의 약 50%만 지원됩니다. 전체 MongoDB 기능이 필요한 경우 MongoDB Atlas를 고려해야 합니다.
비용 최적화 차이
DocumentDB에서는 I/O 작업이 비용의 91%를 차지할 수 있으므로, TTL 인덱스 대신 롤링 컬렉션을 사용하고, 4KB 미만의 작은 쓰기를 배치 처리하여 I/O를 최적화하는 것이 중요합니다. I/O 집약적 워크로드(전체 비용의 25% 이상)의 경우 I/O 최적화 스토리지 사용을 고려해야 합니다.
결론
AWS DocumentDB의 엔드포인트 시스템은 고가용성과 확장성을 위해 정교하게 설계되었습니다. 인스턴스 레벨에서 쓰기 권한을 엄격히 제어하며, 대부분의 애플리케이션은 자동 장애 조치와 로드 분산을 위해 클러스터 엔드포인트를 사용해야 합니다.