Amazon DocumentDB 모범 사례

Amazon DocumentDB(MongoDB 호환)를 사용하여 작업하는 모범 사례를 알아보십시오. 이 섹션은 새로운 모범 사례가 확인되는 대로 지속적으로 업데이트됩니다.

기본 운영 지침

다음은 Amazon DocumentDB로 작업할 때 모든 사용자가 따라야 하는 기본 운영 지침입니다. Amazon DocumentDB 서비스 수준 계약에 다음 지침을 따르도록 명시되어 있습니다.

• 두 개의 가용 영역에 두 개 이상의 Amazon DocumentDB 인스턴스로 구성된 클러스터를 배포하십시오. AWS 프로덕션 워크로드의 경우 3개의 가용 영역에 3개 이상의 Amazon DocumentDB 인스턴스로 구성된 클러스터를 배포하는 것이 좋습니다.

• 명시된 서비스 제한 내에서 서비스를 사용하십시오. 자세한 정보는 아마존 DocumentDB 할당량 및 한도을 참조하세요.

• 메모리, CPU, 연결 및 스토리지 사용량을 모니터링합니다. 시스템 성능 및 가용성을 유지하는 데 도움이 되도록 사용 패턴이 변경되거나 배포 용량에 가까워지면 CloudWatch Amazon에서 알리도록 설정하십시오.

• 용량 한도에 도달할 경우 인스턴스를 확장합니다. 애플리케이션의 예상치 못한 수요 증가를 수용할 수 있는 충분한 컴퓨팅 리소스(예: RAM, CPU)를 사용하여 인스턴스를 프로비저닝해야 합니다.

• 복구 시점 목표에 맞춰 백업 보존 기간을 설정합니다.

• 클러스터의 장애 조치를 테스트하여 사용 사례 절차에 소요되는 시간을 파악하십시오. 자세한 정보는 Amazon DocumentDB 장애 조치을 참조하세요.

• 복제본 집합 모드(Amazon DocumentDB에 복제 세트로 연결 참조)에서 클러스터 엔드포인트(Amazon DocumentDB 엔드포인트 참조)를 사용하여 Amazon DocumentDB 클러스터에 연결함으로써 장애 조치가 애플리케이션에 미치는 영향을 최소화합니다.

• 애플리케이션의 읽기 일관성 요구 사항을 충족하면서 읽기 확장성을 최대화하는 드라이버 읽기 기본 설정을 선택합니다. secondaryPreferred 읽기 기본 설정은 복제본 읽기를 활성화하고, 더 많은 작업을 수행할 수 있도록 기본 인스턴스를 비웁니다. 자세한 정보는 읽기 기본 설정 옵션을 참조하세요.

• 네트워크 및 데이터베이스 오류가 발생하는 경우 복원력을 발휘하도록 애플리케이션을 설계합니다. 일시적인 오류와 지속적인 오류를 구별하기 위해 드라이버의 오류 메커니즘을 사용합니다. 적절한 경우 지수 백오프 메커니즘을 사용하여 일시적인 오류를 다시 시도합니다. 재시도 논리를 구현할 때 애플리케이션에서 데이터 일관성을 고려해야 합니다.

• 모든 프로덕션 클러스터 또는 중요한 데이터가 있는 클러스터에 대해 클러스터 삭제 보호를 활성화합니다. Amazon DocumentDB 클러스터를 삭제하기 전에 최종 스냅샷을 생성합니다. 로 AWS CloudFormation리소스를 배포하는 경우 종료 보호를 활성화하십시오. 자세한 정보는 종료 방지 및 삭제 방지을 참조하세요.

• Amazon DocumentDB 클러스터를 생성할 때 --engine-version은 기본적으로 최신 주요 엔진 버전에 대해 기본적으로 설정되는 선택 사항 파라미터입니다. 현재 주요 엔진 버전은 4.0.0입니다. 새 주요 엔진 버전이 출시되면 –engine-version의 기본 엔진 버전은 이전 주요 엔진 버전을 반영하도록 업데이트됩니다. 따라서 프로덕션 워크로드, 특히 스크립팅, 자동화 또는 AWS CloudFormation 템플릿에 의존하는 워크로드의 경우 --engine-version을 의도한 메이저 버전으로 명시적으로 지정하는 것이 좋습니다.

인스턴스 크기 조정

Amazon DocumentDB에서 인스턴스 크기를 선택할 때 가장 중요한 요소 중 하나는 캐시에 사용할 RAM 용량입니다. Amazon DocumentDB는 RAM의 3분의 1을 자체 서비스를 위해 예약합니다. 즉, 캐시에 사용할 수 있는 인스턴스 RAM은 3분의 2뿐입니다. 작업 집합(즉, 데이터 및 인덱스)을 메모리에 저장할 수 있는 충분한 RAM이 있는 인스턴스 유형을 선택하는 것이 Amazon DocumentDB 성능면에서 가장 좋습니다. 인스턴스 크기를 적절히 조정하면 전반적인 성능을 최적화하고 잠재적으로 I/O 비용을 최소화하는 데 도움이 됩니다. 타사 Amazon DocumentDB 크기 계산기를 사용하여 특정 워크로드의 인스턴스 크기를 추정할 수 있습니다.

애플리케이션의 작업 집합이 메모리에 맞는지 확인하려면 로드 중인 클러스터의 각 인스턴스에 CloudWatch 대해 Amazon BufferCacheHitRatio 사용 현황을 모니터링하십시오.

이 BufferCacheHitRatio CloudWatch 지표는 인스턴스의 메모리 캐시에서 제공되는 데이터 및 인덱스의 비율 (스토리지 볼륨 대비) 을 측정합니다. 일반적으로 작업 집합 메모리에서 데이터를 읽는 것이 저장소 볼륨에서 읽는 것보다 빠르고 비용 효율적이므로 BufferCacheHitRatio의 값은 가능한 한 높아야 합니다. BufferCacheHitRatio를 가능한 한 100%에 가깝게 유지하는 것이 바람직하지만 달성 가능한 최상의 가치는 애플리케이션의 액세스 패턴과 성능 요구 사항에 따라 달라집니다. BufferCacheHitRatio를 가능한 한 최대로 유지하려면 인덱스와 작업 데이터 세트가 메모리에 맞을 수 있을 만큼 충분한 RAM으로 클러스터의 인스턴스를 프로비저닝하는 것이 좋습니다.

인덱스가 메모리에 맞지 않으면 BufferCacheHitRatio가 더 낮게 표시될 수 있습니다. 디스크에서 계속 읽으면 추가 I/O 비용이 발생하며 메모리에서 읽는 것만큼의 성능을 얻을 수 없습니다. BufferCacheHitRatio 비율이 예상보다 낮으면 클러스터가 메모리의 작업 집합 데이터에 맞게 더 많은 RAM을 제공할 수 있도록 인스턴스 크기를 늘립니다. 인스턴스 클래스를 확장하여 BufferCacheHitRatio가 급격히 증가하면 애플리케이션의 작업 집합이 메모리에 맞은 것입니다. 규모 조정 작업 후 BufferCacheHitRatio가 더 이상 대폭 증가하지 않을 때까지 계속 확장합니다. 인스턴스의 지표 모니터링에 대한 자세한 내용은 Amazon DocumentDB 지표 단원을 참조하십시오.

워크로드 및 지연 시간 요구 사항에 따라 애플리케이션이 정상 상태 사용 중에는 더 높은 BufferCacheHitRatio 값을 가질 수 있지만 전체 컬렉션을 스캔해야 하는 분석 쿼리가 인스턴스에서 실행되므로 주기적으로 BufferCacheHitRatio 딥을 수행할 수 있습니다. BufferCacheHitRatio의 이러한 주기적 딥은 스토리지 볼륨에서 작업 집합 데이터를 버퍼 캐시로 다시 채워야 하는 후속 쿼리에 대해 더 높은 지연 시간으로 나타날 수 있습니다. 프로덕션에 워크로드를 배포하기 전에 성능 특성 및 BufferCacheHitRatio를 이해하려면 먼저 대표적인 프로덕션 워크로드를 사용하여 사전 프로덕션 환경에서 워크로드를 테스트하는 것이 좋습니다.

BufferCacheHitRatio는 인스턴스별 지표이므로 기본 인스턴스와 복제본 인스턴스 간에 읽기가 분산되는 방식에 따라 동일한 클러스터 내의 여러 인스턴스가 서로 다른 BufferCacheHitRatio 값을 가질 수 있습니다. 작업 워크로드가 분석 쿼리를 실행한 후 작업 집합 캐시를 다시 채울 때 발생하는 대기 시간 증가를 주기적으로 처리할 수 없는 경우 일반 작업 워크로드의 버퍼 캐시를 분석 질의의 버퍼 캐시와 분리해야 합니다. 운영 쿼리를 기본 인스턴스로, 분석 쿼리는 복제본 인스턴스로만 전송하여 BufferCacheHitRatio를 완전히 격리할 수 있습니다. 또한 일정 비율의 일반 쿼리가 해당 복제본에서 실행되고 영향을 받을 수 있음을 이해하고 분석 쿼리를 특정 복제본 인스턴스로 전송하여 부분 격리를 수행할 수도 있습니다.

적합한 BufferCacheHitRatio 값은 사용 사례 및 애플리케이션 요구 사항에 따라 다릅니다. 이 지표에는 최고 또는 최소 값이 하나도 없습니다. 비용 및 성능 측면에서 일시적으로 낮은 BufferCacheHitRatio의 절충이 허용되는지 여부만 결정할 수 있습니다.

인덱스 작업

인덱스 작성

Amazon DocumentDB로 데이터를 가져올 때, 대규모 데이터 세트를 가져오기 전에 인덱스를 생성해야 합니다. Amazon DocumentDB 인덱스 도구를 사용하여 실행 중인 MongoDB 인스턴스 또는 mongodump 디렉터리에서 인덱스를 추출하고, Amazon DocumentDB 클러스터에서 해당 인덱스를 생성할 수 있습니다. 마이그레이션에 대한 자세한 지침은 Amazon DocumentDB로 마이그레이션 단원을 참조하십시오.

인덱스 선택성

중복 값 수가 컬렉션에 있는 총 문서 수의 1% 미만인 필드로 인덱스 생성을 제한하는 것이 좋습니다. 예를 들어 컬렉션에 100,000개의 문서가 포함되어 있는 경우, 동일한 값이 1000회 이하로 나타나는 필드에만 인덱스를 생성하세요.

고유 값이 많은 인덱스를 선택하면(즉, 카디널리티가 높음) 필터 작업에서 적은 수의 문서를 반환하므로 인덱스 스캔 중에 우수한 성능을 얻을 수 있습니다. 높은 카디널리티 인덱스의 예는 같음 조건자가 최대 하나의 문서를 반환하도록 보장하는 고유 인덱스입니다. 낮은 카디널리티의 예로는 부울 필드에 대한 인덱스와 요일에 대한 인덱스가 있습니다. 성능 저하로 인해 낮은 카디널리티 인덱스는 데이터베이스의 쿼리 최적화 프로그램에 의해 선택될 가능성이 낮습니다. 동시에 낮은 카디널리티 인덱스는 디스크 스페이스 및 I/O와 같은 리소스를 계속 사용합니다. 일반적으로 일반적인 값 빈도가 전체 컬렉션 크기의 1% 이하인 필드의 인덱스를 대상으로 해야 합니다.

또한 일반적으로 필터로 사용되는 필드에만 인덱스를 생성하고, 사용하지 않는 인덱스를 정기적으로 찾는 것이 좋습니다. 자세한 정보는 인덱스 사용량을 분석하고 사용하지 않는 인덱스를 식별하려면 어떻게 해야 하나요?을 참조하세요.

인덱스가 데이터 작성에 미치는 영향

인덱스는 컬렉션의 모든 문서를 스캔할 필요가 없으므로 쿼리 성능을 향상할 수 있지만 이러한 개선 시에 다른 불리함이 따를 수 있습니다. 컬렉션의 각 인덱스에 대해 문서가 삽입, 업데이트 또는 삭제될 때마다 데이터베이스는 컬렉션을 업데이트하고 컬렉션의 각 인덱스에 필드를 기록해야 합니다. 예를 들어 컬렉션에 9개의 인덱스가 있는 경우 데이터베이스는 클라이언트에 작업을 승인하기 전에 10개의 쓰기를 수행해야 합니다. 따라서 인덱스가 추가될 때마다 쓰기 지연 시간, I/O가 추가되고 전체 활용도가 높은 스토리지가 증가합니다.

모든 작업 집합 메모리를 유지하려면 클러스터 인스턴스의 크기를 적절하게 조정해야 합니다. 이에 따라 스토리지 볼륨에서 인덱스 페이지를 지속적으로 읽을 필요가 없으므로 성능에 부정적인 영향을 미치고 I/O 비용이 증가합니다. 자세한 정보는 인스턴스 크기 조정을 참조하세요.

최상의 성능을 얻으려면 일반 쿼리의 성능을 향상하는 데 필요한 인덱스만 추가하여 컬렉션의 인덱스 수를 최소화합니다. 워크로드는 다양하지만 컬렉션당 인덱스 수를 5 이하로 유지하는 것이 좋습니다.

누락된 인덱스 식별

누락된 인덱스를 식별하고 제거하는 작업을 정기적으로 수행하는 것이 좋습니다. 자세한 내용은 누락된 인덱스는 어떻게 식별하나요? 단원을 참조하십시오.

사용되지 않는 인덱스 식별

사용되지 않는 인덱스를 식별하고 제거하는 작업을 정기적으로 수행하는 것이 좋습니다. 자세한 내용은 인덱스 사용량을 분석하고 사용하지 않는 인덱스를 식별하려면 어떻게 해야 하나요? 단원을 참조하십시오.

보안 모범 사례

보안 모범 사례를 위해 AWS Identity and Access Management (IAM) 계정을 사용하여 Amazon DocumentDB API 작업, 특히 Amazon DocumentDB 리소스를 생성, 수정 또는 삭제하는 작업에 대한 액세스를 제어해야 합니다. 이러한 리소스로는 클러스터, 보안 그룹 및 파라미터 그룹을 들 수 있습니다. 또한 IAM을 사용하여 클러스터 복원 백업과 같은 일반적인 관리 작업을 수행하는 작업을 제어해야 합니다. IAM 역할을 생성할 때 최소 권한 원칙을 사용합니다.

• 역할 기반 액세스 제어와 함께 최소 권한을 적용합니다.

• Amazon DocumentDB 리소스를 관리하는 각 사용자에게 개별 IAM 계정을 할당합니다. AWS 계정 루트 사용자를 사용하여 Amazon DocumentDB 리소스를 관리하지 마십시오. 자신을 포함한 모든 사람을 위한 IAM 사용자를 생성합니다.

• 각 IAM 사용자에게 각자의 임무를 수행하는 데 필요한 최소 권한 집합을 부여합니다.

• IAM 그룹을 사용해 여러 사용자에 대한 권한을 효과적으로 관리합니다. IAM에 대한 자세한 내용은 IAM 사용 설명서를 참조하십시오. IAM 모범 사례에 대한 자세한 내용은 IAM 모범 사례를 참조하십시오.

• IAM 자격 증명을 정기적으로 교체합니다.

• Amazon DocumentDB의 AWS 시크릿을 자동으로 교체하도록 Secrets Manager를 구성하십시오. 자세한 내용은 Secrets Manager 사용 설명서의 AWS Secrets Manager 보안 암호 교체 및 Amazon DocumentDB의 암호 순환AWS 섹션을 참조하십시오.

• 각 Amazon DocumentDB 사용자에게 각자의 임무를 수행하는 데 필요한 최소 권한 집합을 부여합니다. 자세한 정보는 역할 기반 액세스 제어를 사용한 데이터베이스 액세스을 참조하세요.

• 전송 계층 보안 (TLS) 을 사용하여 전송 중인 데이터를 암호화하고 저장된 데이터를 암호화하십시오. AWS KMS

비용 최적화

다음 모범 사례는 Amazon DocumentDB를 사용할 때 비용을 관리하고 최소화하는 데 도움이 될 수 있습니다. 요금 정보는 Amazon DocumentDB(MongoDB 호환) 요금 및 Amazon DocumentDB(MongoDB 호환) FAQ를 참조하십시오.

• 해당 월 예상 청구액의 50% 및 75% 임계값으로 결제 알림을 생성합니다. 결제 알림 생성에 대한 자세한 내용은 결제 경보 생성을 참조하십시오.

• Amazon DocumentDB의 아키텍처는 스토리지와 컴퓨팅을 분리하므로 단일 인스턴스 클러스터도 매우 내구성이 높습니다. 클러스터 스토리지 볼륨은 3개의 가용 영역에 걸쳐 6방향으로 데이터를 복제하므로, 클러스터에 있는 인스턴스 수와 상관없이 매우 높은 내구성을 제공합니다. 일반적인 프로덕션 클러스터에는 고가용성을 제공하기 위해 3개 이상의 인스턴스가 있습니다. 그러나 고가용성이 필요하지 않은 경우 단일 인스턴스 개발 클러스터를 사용하여 비용을 최적화할 수 있습니다.

• 개발 및 테스트 시나리오의 경우 더 이상 필요하지 않을 때 클러스터를 중지하고 개발이 다시 시작되면 클러스터를 시작합니다. 자세한 정보는 Amazon DocumentDB 클러스터 중지 및 시작을 참조하세요.

• 데이터가 쓰기, 읽기 및 삭제될 때 TTL과 스트림 변경은 모두 I/O를 발생합니다. 이러한 기능을 활성화했지만 애플리케이션에서 사용하지 않는 경우 이 기능을 비활성화하면 비용이 절감될 수 있습니다.

지표를 통해 성능 문제 식별

리소스 부족이나 기타 일반적인 병목 현상으로 인해 발생하는 성능 문제를 식별하기 위해 Amazon DocumentDB 클러스터에서 사용 가능한 지표를 모니터링할 수 있습니다.

성능 지표 보기

다양한 기간 동안의 평균, 최대, 최소 측정값을 보려면 성능 지표를 정기적으로 모니터링합니다. 이렇게 하면 성능이 저하된 시점을 식별하는 데 도움이 됩니다. 또한 특정 지표 임계값에 대해 Amazon CloudWatch 경보를 설정하여 임계값에 도달하면 알림을 받을 수 있습니다.

성능 문제를 해결하기 위해서는 시스템의 기준 성능을 파악해야 합니다. 새 클러스터를 설정하고 일반 워크로드로 실행한 후 서로 다른 간격(예: 1시간, 24시간, 1주, 2주)으로 모든 성능 지표의 평균값, 최댓값 및 최솟값을 파악하십시오. 이렇게 하면 무엇이 정상인지를 알 수 있습니다. 이렇게 하면 작업의 최고 피크와 최저 피크 시간을 비교할 수 있습니다. 그런 다음 이 정보를 사용하여 성능이 표준 수준 이하로 떨어진 때를 식별할 수 있습니다.

OR를 사용하여 성능 지표를 볼 수 있습니다. AWS Management Console AWS CLI자세한 정보는 CloudWatch 데이터 보기을 참조하세요.

CloudWatch 알람 설정

경보를 설정하려면 Amazon CloudWatch 사용 설명서의 Amazon CloudWatch CloudWatch 경보 사용을 참조하십시오.

성능 지표 평가

인스턴스에는 여러 지표 범주가 있습니다. 허용되는 값을 결정하는 방법은 지표에 따라 다릅니다.

CPU

• CPU 사용률 – 사용된 컴퓨터 처리 용량의 백분율입니다.

메모리

• 여유 메모리 - 인스턴스에서 사용 가능한 RAM을 나타냅니다.

• 스왑 사용량 - 인스턴스에서 스왑 스페이스를 얼마나 많이 사용했는지를 메가바이트 단위로 나타냅니다.

입력/출력 작업

• IOPS 읽기, IOPS 쓰기 – 초당 디스크 읽기 또는 쓰기 작업의 평균 횟수입니다.

• 읽기 지연 시간, 쓰기 지연 시간 – 읽기 또는 쓰기 작업의 평균 시간(밀리초)입니다.

• 읽기 처리량, 쓰기 처리량 – 초당 디스크에서 읽거나 디스크에 쓴 평균 크기(메가바이트)입니다.

• 디스크 대기열 길이 - 디스크에 쓰기 위해 또는 디스크에서 읽기 위해 대기 중인 I/O 작업의 수입니다.

네트워크 트래픽

• 네트워크 수신 처리량, 네트워크 전송 처리량 - 인스턴스에 대한 수신 또는 전송 네트워크 트래픽 속도(초당 메가바이트)입니다.

데이터베이스 연결

• DB 연결 – 인스턴스에 연결된 클라이언트 세션의 수입니다.

일반적으로 성능 지표에 허용되는 값은 기준이 무엇인지 그리고 애플리케이션 무엇을 수행하는지에 따라 다릅니다. 기준과의 일관된 차이 또는 추세를 조사하십시오.

특정 지표 유형에 대한 권장 사항 및 조언은 다음과 같습니다.

• CPU 사용량이 많음 - CPU 사용량이 많을 경우 해당 애플리케이션의 목표(처리량 또는 동시성 등)와 일치하고 예상되는 결과라면 문제가 되지 않을 수 있습니다. CPU 소비가 지속적으로 80%를 초과하는 경우 인스턴스 확장을 고려하십시오.

• 높은 RAM 소비 - FreeableMemory 메트릭이 총 인스턴스 메모리의 10% 이하로 자주 떨어지는 경우 인스턴스 확장을 고려하십시오. DocumentDB 인스턴스의 메모리 사용량이 높을 때 어떤 일이 발생하는지에 대한 자세한 내용은 Amazon DocumentDB 리소스 거버넌스를 참조하십시오.

• 스왑 사용량 - 이 메트릭은 0 또는 그 근처에 있어야 합니다. 스왑 사용량이 많은 경우 인스턴스 확장을 고려하십시오.

• 네트워크 트래픽 - 네트워크 트래픽의 경우 시스템 관리자에게 문의하여 해당 도메인 네트워크 및 인터넷 연결의 예상 처리량을 확인합니다. 처리량이 기대값보다 항상 낮으면 네트워크 트래픽을 검사합니다.

• 데이터베이스 연결 - 인스턴스 성능 저하 및 응답 시간 지연과 함께 사용자 연결 수가 많을 경우 데이터베이스 연결 제한을 고려해 봅니다. 인스턴스에 대한 최적의 사용자 연결 수는 해당 인스턴스 클래스와 수행하는 작업의 복잡성에 따라 다릅니다. 성능 지표와 관련하여 문제가 있을 경우 성능을 향상하기 위해 제일 먼저 할 수 있는 것은, 가장 많이 사용되고 가장 비용이 높은 쿼리를 튜닝하여 시스템 리소스에 대한 부하를 줄일 수 있는지 확인하는 것입니다.

쿼리를 튜닝해도 문제가 지속된다면 문제와 관련된 리소스(CPU, RAM, 디스크 스페이스, 네트워크 대역폭, I/O 용량)가 많은 Amazon DocumentDB 인스턴스 클래스로 업그레이드하는 것이 좋습니다.

쿼리 튜닝

클러스터 성능을 향상하는 제일 좋은 방법 중 하나는 일반적으로 가장 많이 사용하는 쿼리와 리소스를 가장 많이 사용하는 쿼리를 튜닝하여 실행 비용을 낮추는 것입니다.

프로파일러(Amazon DocumentDB 작업 프로파일링 참조)를 사용하여 클러스터에서 수행된 작업의 실행 시간 및 세부 정보를 기록할 수 있습니다. 프로파일러는 개별 쿼리 성능 및 전체 클러스터 성능을 개선하기 위해 클러스터에서 가장 느린 작업을 모니터링하는 경우에 유용합니다.

explain 명령을 사용하여 특정 쿼리에 대한 쿼리 계획을 분석하는 방법을 배울 수도 있습니다. 쿼리 성능을 높이기 위해 이 정보를 사용하여 쿼리나 기본 컬렉션을 수정할 수 있습니다(예: 인덱스 추가).

TTL 및 시계열 워크로드

TTL 인덱스 만료로 인한 문서 삭제가 최선의 방법입니다. 문서는 특정 기간 내에 삭제될 수 없습니다. 인스턴스 크기, 인스턴스 리소스 사용률, 문서 크기, 전체 처리량, 인덱스 수, 메모리에 인덱스 및 작업 집합이 맞는지 여부와 같은 요소는 모두 만료된 문서가 TTL 프로세스에 의해 삭제되는 시점에 영향을 줄 있습니다.

TTL 모니터가 문서를 삭제하면 삭제할 때마다 IO 비용이 발생하므로 청구 금액이 증가합니다. 처리량과 TTL 삭제율이 증가하면 I/O 사용량 증가로 인해 청구 금액이 더 증가하기 마련입니다. 하지만 TTL 인덱스를 생성하여 문서를 삭제하지 않고 시간을 기준으로 문서를 컬렉션으로 분류하고 더 이상 필요하지 않을 때 해당 컬렉션을 삭제하면 IO 비용이 발생하지 않습니다. 이 방법은 TTL 인덱스를 사용하는 것보다 훨씬 더 비용 효율적일 수 있습니다.

시계열 워크로드의 경우, 롤링 컬렉션이 데이터를 삭제하는 더 효과적인 방법일 수 있고 I/O 사용량이 적기 때문에, TTL 인덱스 대신 롤링 컬렉션을 만드는 것이 좋을 수 있습니다. 대용량 컬렉션(특히 1TB를 초과하는 컬렉션)이 있거나 TTL 삭제 I/O 비용이 우려되는 경우 시간을 기준으로 문서를 컬렉션으로 분할하고 문서가 더 이상 필요하지 않을 때 컬렉션을 삭제하는 것이 좋습니다. 데이터 수집 속도에 따라 하루에 한 번 또는 일주일에 한 번씩 모음을 만들 수 있습니다. 요구 사항은 애플리케이션에 따라 다르지만 몇 개의 큰 컬렉션보다는 더 작은 컬렉션을 사용하는 것이 좋습니다. 이러한 컬렉션을 삭제하는 데는 IO 비용이 발생하지 않으므로 TTL 인덱스를 사용하는 것보다 더 빠르고 비용 효율적일 수 있습니다.

마이그레이션

데이터를 Amazon DocumentDB로 마이그레이션할 때, 데이터를 마이그레이션하기 전에 먼저 Amazon DocumentDB에서 인덱스를 생성하는 것이 가장 좋습니다. 인덱스를 먼저 생성하면 전체 시간을 줄이고 마이그레이션 속도를 높일 수 있습니다. 이렇게 하려면 Amazon DocumentDB 인덱스 도구를 사용하면 됩니다. 마이그레이션에 대한 자세한 내용은 Amazon DocumentDB 마이그레이션 안내서를 참조하십시오.

또한 프로덕션 데이터베이스를 마이그레이션하기 전에 기능, 성능, 운영 및 비용을 고려하여 Amazon DocumentDB에서 애플리케이션을 완전히 테스트하는 것이 좋습니다.

클러스터 파라미터 그룹 작업

클러스터 파라미터 그룹 변경 내용을 프로덕션 클러스터에 적용하기 전에 테스트 클러스터에 적용해 보는 것이 좋습니다. 클러스터 백업에 대한 자세한 내용은 Amazon DocumentDB에서의 백업 및 복원 단원을 참조하십시오.

집계 파이프라인 쿼리

여러 단계로 집계 파이프라인 쿼리를 생성하고 쿼리에 있는 데이터의 하위 집합만 평가하는 경우 $match 단계를 첫 번째 단계 또는 파이프라인의 시작으로 사용합니다. $match 첫 번째를 사용하면 집계 파이프라인 쿼리의 후속 단계에서 처리해야 하는 문서 수가 줄어들어 쿼리 성능이 향상됩니다.

batchInsert 및 batchUpdate

높은 비율의 동시 batchUpdate 작업 batchInsert 및/또는 작업을 수행하고 기본 인스턴스에서 FreeableMemory (CloudWatch 지표) 양이 0이 되면 일괄 삽입 또는 업데이트 워크로드의 동시성을 줄이거나, 워크로드의 동시성을 줄일 수 없는 경우 인스턴스 크기를 늘려 양을 늘릴 수 있습니다. FreeableMemory