Amazon DocumentDB 서버리스 조정 구성

DocumentDB 서버리스 클러스터의 조정 용량 범위 선택

Amazon DocumentDB 클러스터에 Amazon DocumentDB 서버리스 인스턴스를 추가하기 전에 클러스터에 ServerlessV2ScalingConfiguration 파라미터 세트도 있어야 합니다.

ServerlessV2ScalingConfiguration 파라미터는 클러스터에 있는 모든 서버리스 인스턴스의 서버리스 조정 용량 범위를 정의하는 두 값으로 구성됩니다.

• MinCapacity - 클러스터에 있는 DocumentDB 서버리스 인스턴스의 최소 조정 용량입니다.

• MaxCapacity - 클러스터에 있는 DocumentDB 서버리스 인스턴스의 최대 크기 조정 용량입니다.

DocumentDB 서버리스 클러스터에 대한 MinCapacity 설정 선택

항상에 대해 0.5를 선택하려고 합니다MinCapacity. 이 값을 사용하면 인스턴스가 완전히 유휴 상태일 때 활성 상태를 유지하면서 최소 용량으로 축소할 수 있습니다. 그러나 해당 클러스터를 사용하는 방법과 구성하는 기타 설정에 따라 가장 효과적인 최소 용량은 다를 수도 있습니다. 최소 용량 설정을 선택할 때는 다음 요소를 고려하세요.

• DocumentDB 서버리스 인스턴스의 조정 속도는 현재 용량에 따라 달라집니다. 현재 용량이 높을수록 더 빠르게 확장할 수 있습니다. 인스턴스를 매우 높은 용량으로 빠르게 확장해야 하는 경우 최소 용량을 조정 속도가 요구 사항을 충족하는 값으로 설정하는 것이 좋습니다.

• 일반적으로 특히 높거나 낮은 워크로드를 예상하여 인스턴스의 인스턴스 클래스를 수정하는 경우 해당 경험을 사용하여 동등한 DocumentDB 서버리스 용량 범위를 대략적으로 추정할 수 있습니다. 프로비저닝된 Amazon DocumentDB 인스턴스 유형의 메모리 크기를 확인하려면 섹션을 참조하세요인스턴스 제한.

  예를 들어 클러스터의 워크로드가 낮을 때 db.r6g.xlarge 인스턴스 클래스를 사용한다고 가정해 보겠습니다. 해당 인스턴스 클래스의 메모리는 32GiB입니다. 따라서 16MinCapacity의를 지정하여 거의 동일한 용량으로 축소할 수 있는 서버리스 인스턴스를 설정할 수 있습니다. 이는 각 DCU가 약 2GiB의 메모리에 해당하기 때문입니다. 인스턴스 사용률이 낮은 db.r6g.xlarge 경우가 있을 경우 인스턴스가 더 축소되도록 약간 더 낮은 값을 지정할 수 있습니다.

• 인스턴스에 버퍼 캐시에 일정량의 데이터가 있을 때 애플리케이션이 가장 효율적으로 작동하는 경우 자주 액세스하는 데이터를 저장할 수 있을 만큼 메모리가 충분히 큰 최소 DCU 설정을 지정하는 것이 좋습니다. 그렇지 않으면 서버리스 인스턴스가 더 낮은 메모리 크기로 축소될 때 버퍼 캐시에서 일부 데이터가 제거됩니다. 그런 다음 인스턴스가 다시 확장되면 시간이 지남에 따라 정보가 버퍼 캐시로 다시 읽힙니다. 데이터를 버퍼 캐시로 다시 가져오는 I/O의 양이 많은 경우 더 높은 최소 DCU 값을 선택하는 것이 더 효과적일 수 있습니다. 자세한 내용은 인스턴스 크기 조정 단원을 참조하십시오.

• DocumentDB 서버리스 인스턴스가 특정 용량에서 대부분 실행되는 경우 해당 기준보다 낮지만 너무 낮지 않은 최소 용량 설정을 지정하는 것이 좋습니다. 서버리스 인스턴스는 현재 용량이 필요한 용량보다 크게 낮지 않을 때 확장할 양과 속도를 가장 효과적으로 추정할 수 있습니다.

• 프로비저닝된 워크로드에 T3 또는 T4g와 같은 소규모 인스턴스 클래스에 비해 메모리 요구 사항이 너무 높은 경우 R5 또는 R6g 인스턴스와 비슷한 메모리를 제공하는 최소 DCU 설정을 선택합니다.

• 특히 지정된 기능과 함께 MinCapacity 사용하려면 다음과 같은 최소값을 사용하는 것이 좋습니다(이러한 권장 사항은 변경될 수 있음).

  • 성능 개선 도우미 - DCUs

• Amazon DocumentDB에서 복제는 스토리지 계층에서 발생하므로 리더 용량은 복제에 직접적인 영향을 미치지 않습니다. 그러나 독립적으로 확장되는 DocumentDB 서버리스 리더 인스턴스의 경우 쿼리 지연 시간을 방지하기 위해 쓰기 집약적인 기간 동안 워크로드를 처리하기에 최소 용량이 충분한지 확인합니다. 승격 티어 2~15의 리더 인스턴스에서 성능 문제가 발생하는 경우 클러스터의 최소 용량을 늘리는 것이 좋습니다. 리더 인스턴스가 라이터와 함께 확장되는지 아니면 독립적으로 확장되는지 변경하는 방법에 대한 자세한 내용은 섹션을 참조하세요서버리스 리더의 승격 계층 보기 및 수정.

  DocumentDB 서버리스 리더 인스턴스가 있는 클러스터가 있는 경우 리더의 승격 계층이 0 또는 1이 아닌 경우 리더는 라이터 인스턴스와 함께 확장되지 않습니다. 이 경우 최소 용량을 낮게 설정하면 과도한 복제 지연이 발생할 수 있습니다. 데이터베이스가 사용 중일 때 리더의 용량이 라이터의 변경 사항을 적용하기에 충분하지 않을 수 있기 때문입니다. 최소 용량을 라이터 인스턴스와 비슷한 양의 메모리 및 CPU를 나타내는 값으로 설정하는 것이 좋습니다.

• DocumentDB 서버리스 인스턴스가 최소 용량에서 최대 용량으로 확장하는 데 걸리는 시간은 최소 DCU 값과 최대 DCU 값의 차이에 따라 달라집니다. 인스턴스의 현재 용량이 크면 DocumentDB 서버리스는 인스턴스가 작은 용량에서 시작할 때보다 더 큰 증분으로 확장됩니다. 따라서 비교적 큰 최대 용량을 지정하고 인스턴스가 대부분의 시간을 해당 용량에 가깝게 소비하는 경우 최소 DCU 설정을 늘리는 것이 좋습니다. 이렇게 하면 유휴 인스턴스가 최대 용량으로 더 빠르게 스케일 업할 수 있습니다.

• 연결 제한, 커서 제한 및 열린 트랜잭션 제한과 같은 특정 인스턴스 제한은 서버리스 인스턴스의 현재 용량에 따라 결정됩니다. 인스턴스의 현재 용량이 작으면 그에 따라 제한도 작아집니다. 서버리스 인스턴스를 MinCapacity 값으로 축소할 때 이러한 제한이 문제가 되는 경우 더 높은 값으로 늘리는 MinCapacity 것이 좋습니다. 자세한 내용은 Amazon DocumentDB 서버리스 인스턴스 제한 단원을 참조하십시오.

• 또한 활성 연결 제한, 커서 제한 및 열린 트랜잭션 제한과 같이 MinCapacity가 1.0DCUs 이하로 설정된 경우 특정 인스턴스 제한은 더 낮은 최대값으로 제한됩니다. 이러한 한도가 워크로드에 충분하지 않은 경우 1.5DCUs 이상의 MinCapacity 값을 사용하십시오. 자세한 내용은 Amazon DocumentDB 서버리스 인스턴스 제한 단원을 참조하십시오.

클러스터의 조정 구성을 수정하는 방법에 대한 지침은 섹션을 참조하세요Amazon DocumentDB 서버리스 관리.

DocumentDB 서버리스 클러스터에 대한 MaxCapacity 설정 선택

항상 최대 DocumentDB 서버리스 용량 설정에 대해 높은 값을 선택하려고 합니다. 최대 용량이 크면 인스턴스가 집약적인 워크로드를 실행할 때 가장 많이 확장할 수 있습니다. 낮은 값은 예기치 않은 요금의 가능성을 방지합니다. 해당 클러스터를 사용하는 방법과 구성하는 기타 설정에 따라 가장 효과적인 값은 원래 생각했던 것보다 높거나 낮을 수 있습니다. 최대 용량 설정을 선택할 때는 다음 요소를 고려하세요.

• 최대 용량은 최소 용량보다는 커야 합니다. 최대 및 최소 용량은 동일하게 설정할 수 있습니다. 그러나 이 경우 용량은 절대 확장하거나 축소되지 않습니다. 따라서 최소 및 최대 용량에 대해 동일한 값을 사용하는 것은 테스트 상황 외에는 적절하지 않습니다.

• 최대 용량은 최소 1.0DCUs여야 하며 최대 256DCUs여야 합니다.

• 서버리스 인스턴스의 규모 조정 및 리소스 사용량을 모니터링하는 것이 좋습니다. 서버리스 인스턴스가 최대 용량으로 자주 확장되고 리소스 제약 조건에 도달하는 경우(예: 지표가 DCUUtilization 100.0인 경우) 더 높은 MaxCapacity 값을 선택하는 것이 좋습니다. 자세한 내용은 Amazon DocumentDB 서버리스 모니터링 단원을 참조하십시오.

• 일반적으로 특히 워크로드가 높거나 낮을 것으로 예상하여 프로비저닝된 인스턴스의 인스턴스 클래스를 수정하는 경우 해당 경험을 사용하여 동등한 DocumentDB 서버리스 용량 범위를 추정할 수 있습니다. 프로비저닝된 Amazon DocumentDB 인스턴스의 메모리 크기를 확인하려면 섹션을 참조하세요인스턴스 제한.

  예를 들어 클러스터의 워크로드가 높을 때 db.r6g.4xlarge 인스턴스 클래스를 사용한다고 가정해 보겠습니다. 해당 인스턴스 클래스에는 128GiB의 메모리가 있습니다. 따라서 최대 DCU 설정을 64로 지정하여 거의 동일한 용량으로 확장할 수 있는 서버리스 인스턴스를 설정할 수 있습니다. 이는 각 DCU가 약 2GiB의 메모리에 해당하기 때문입니다. 인스턴스에 워크로드를 효과적으로 처리하기에 충분한 용량이 없는 경우 db.r6g.4xlarge 인스턴스가 더 멀리 확장되도록 약간 더 높은 값을 지정할 수 있습니다.

• 데이터베이스 사용량에 예산 한도가 있는 경우 모든 서버리스 인스턴스가 항상 최대 용량으로 실행되더라도 해당 한도 내에 유지되는 값을 선택합니다. 클러스터에 서버리스 인스턴스가 n개 있는 경우 클러스터가 언제든지 사용할 수 있는 이론적 최대 서버리스 용량은 클러스터의 최대 DCU 설정의 n배입니다. (예를 들어 일부 리더가 라이터와 독자적으로 확장하는 경우 실제 소비량은 더 적을 수 있습니다.)

• 서버리스 리더 인스턴스를 사용하여 라이터 인스턴스에서 일부 읽기 전용 워크로드를 오프로드하는 경우 더 낮은 최대 용량 설정을 선택할 수 있습니다. 이렇게 하면 클러스터에 단일 인스턴스만 포함된 것처럼 각 리더 인스턴스를 확장할 필요가 없습니다.

• 애플리케이션에서 잘못 구성된 데이터베이스 파라미터터 또는 비효율적인 쿼리로 인한 과도한 사용을 방지하는 경우를 가정해 보겠습니다. 이 경우 설정할 수 있는 절대 최대값보다 낮은 최대 용량 설정을 선택하여 우발적인 남용을 방지할 수 있습니다.

• 실제 사용자 활동으로 인한 스파이크가 드물지만 발생하는 경우 최대 용량 설정을 선택할 때 이러한 경우를 고려할 수 있습니다. 애플리케이션이 전체 성능과 확장성을 유지하여 계속 실행하는 것이 우선 순위인 경우 정상 사용에서 관찰되는 것보다 더 높은 최대 용량 설정을 지정할 수 있습니다. 활동이 극도로 급증하는 동안 애플리케이션이 감소된 처리량으로 실행되는 것이 괜찮다면 약간 더 낮은 최대 용량 설정을 선택할 수 있습니다. 애플리케이션을 계속 실행하기에 충분한 메모리와 CPU 리소스가 있는 설정을 선택했는지 확인하세요.

• 클러스터에서 각 인스턴스의 메모리 사용량을 늘리는 설정을 켜는 경우 최대 DCU 값을 결정할 때 해당 메모리를 고려하세요. 이러한 설정에는 성능 개선 도우미에 대한 설정이 포함됩니다. 최대 DCU 값을 사용하면 서버리스 인스턴스가 해당 기능을 사용할 때 워크로드를 처리할 수 있을 만큼 충분히 확장할 수 있는지 확인합니다. 메모리 오버헤드를 부과하는 Amazon DocumentDB 기능과 낮은 최대 DCU 설정의 조합으로 인한 문제 해결에 대한 자세한 내용은 메모리 부족 오류 방지 (아래)를 참조하세요.

• 특히 지정된 기능과 함께 MaxCapacity 사용하려면 다음과 같은 최소값을 사용하는 것이 좋습니다(이러한 권장 사항은 변경될 수 있음).

  • 대용량 데이터 볼륨이 있는 클러스터에서 서버리스 인스턴스 생성 - DCUs(클러스터 복원의 일부로 서버리스 인스턴스 생성 포함)

• 연결 제한, 커서 제한 및 열린 트랜잭션 제한과 같은 특정 인스턴스 제한은 인스턴스의 현재 용량에 따라 결정됩니다. 워크로드 MaxCapacity 값을 선택할 때는 이러한 제한 중 하나에 병목 현상이 발생하지 않도록 이러한 인스턴스 제한을 염두에 두어야 합니다. 자세한 내용은 Amazon DocumentDB 서버리스 인스턴스 제한 단원을 참조하십시오.

클러스터의 조정 구성을 수정하는 방법에 대한 지침은 섹션을 참조하세요Amazon DocumentDB 서버리스 관리.

메모리 부족 오류 방지

DocumentDB 서버리스 인스턴스 중 하나가 지속적으로 최대 용량 한도에 도달하면 Amazon DocumentDB는 인스턴스를 호환되지 않는 파라미터 상태로 설정하여이 조건을 표시합니다. 인스턴스의 파라미터 상태가 호환되지 않는 동안에는 일부 작업이 차단됩니다. 예를 들어 엔진 버전을 업그레이드할 수 없습니다. Amazon DocumentDB 인스턴스의 상태에 대한 자세한 내용은 Amazon DocumentDB 인스턴스 상태 모니터링을 참조하세요.

일반적으로 out-of-memory 오류로 인해 인스턴스가 자주 다시 시작되면 인스턴스가이 상태가 됩니다. Amazon DocumentDB는 이러한 유형의 재시작이 발생할 때 이벤트를 기록합니다. 리소스 이벤트를 보려면 섹션을 참조하세요Amazon DocumentDB 이벤트 보기. 성능 개선 도우미와 같은 설정을 켜면 오버헤드로 인해 메모리 사용량이 비정상적으로 높아질 수 있습니다. 인스턴스의 워크로드가 많거나 많은 수의 스키마 객체와 연결된 메타데이터를 관리하여 발생할 수도 있습니다.

메모리 압력이 낮아져 인스턴스가 최대 용량에 매우 자주 도달하지 않는 경우 Amazon DocumentDB는 인스턴스 상태를 다시 사용 가능으로 자동 변경합니다.

이 조건에서 복구하려면 다음 작업 중 일부 또는 전부를 수행할 수 있습니다.

• 클러스터의 최소 DocumentDB 용량 단위(DCU) 값을 변경하여 서버리스 인스턴스의 용량 하한을 늘립니다. 이렇게 하면 유휴 데이터베이스가 클러스터에서 켜진 기능에 필요한 것보다 적은 메모리를 가진 용량으로 축소되는 문제를 피할 수 있습니다. 클러스터의 DCU 설정을 변경한 후 서버리스 인스턴스를 재부팅합니다. 이렇게 하면 Amazon DocumentDB가 상태를 다시 사용 가능으로 재설정할 수 있는지 여부를 평가합니다.

• 클러스터의 최대 DCU 값을 변경하여 서버리스 인스턴스의 용량 상한을 늘립니다. 이렇게 하면 사용량이 많은 데이터베이스가 클러스터 및 데이터베이스 워크로드에서 켜진 기능을 위한 충분한 메모리로 용량을 확장할 수 없는 문제를 피할 수 있습니다. 클러스터의 DCU 설정을 변경한 후 서버리스 인스턴스를 재부팅합니다. 이렇게 하면 Amazon DocumentDB가 상태를 다시 사용 가능으로 재설정할 수 있는지 여부를 평가합니다.

• 메모리 오버헤드가 필요한 구성 설정을 끕니다. 예를 들어 성능 개선 도우미와 같은 기능이 켜져 있지만 사용하지 않는다고 가정해 보겠습니다. 그렇다면 끌 수 있습니다. 또는 클러스터의 최소 및 최대 용량 값을 더 높게 조정하여 이러한 유형의 기능에 사용되는 메모리를 고려할 수 있습니다. 최소 및 최대 용량 설정 선택에 대한 지침은 DocumentDB 서버리스 클러스터의 조정 용량 범위 선택 페이지를 참조하세요.

• 인스턴스의 워크로드를 줄입니다. 예를 들어 클러스터에 리더 인스턴스를 추가하여 읽기 전용 쿼리의 로드를 더 많은 인스턴스에 분산할 수 있습니다.

서버리스 인스턴스가 축소되지 않는 이유는 무엇인가요?

경우에 따라 DocumentDB 서버리스는 데이터베이스에 부하가 없더라도 최소 용량으로 축소되지 않습니다. 원인은 다음과 같습니다.

• 성능 개선 도우미는 리소스 사용량을 늘리고 데이터베이스가 최소 용량으로 축소되지 않도록 할 수 있습니다. 이러한 기능은 다음과 같습니다.

• 리더 인스턴스가 최소값으로 스케일 다운되지 않고 라이터 인스턴스와 동일하거나 더 높은 용량을 유지하는 경우 리더 인스턴스의 우선 순위 계층을 확인합니다. 계층 0 또는 1의 DocumentDB 서버리스 리더 인스턴스는 최소한 라이터 인스턴스만큼 높은 최소 용량으로 유지됩니다. 리더의 우선 순위 등급을 2 이상으로 변경하여 라이터와 별개로 크기를 늘리거나 줄이십시오. 자세한 내용은 Amazon DocumentDB 서버리스 규모 조정 단원을 참조하십시오.

• 데이터베이스 워크로드가 많으면 리소스 사용량이 증가할 수 있습니다.

• 데이터베이스 볼륨이 크면 리소스 사용량이 증가할 수 있습니다. Amazon DocumentDB는 클러스터 관리에 메모리 및 CPU 리소스를 사용합니다. Amazon DocumentDB는 데이터베이스 볼륨이 큰 클러스터를 관리하기 위해 더 많은 CPU와 메모리가 필요합니다. 클러스터의 최소 용량이 클러스터 관리에 필요한 최소 용량보다 작으면 클러스터가 최소 용량으로 스케일 다운되지 않습니다.

• 백그라운드 유지 관리 활동은 주기적으로 리소스 사용량을 늘릴 수 있습니다.

그래도 데이터베이스가 구성된 최소 용량까지 축소되지 않는다면, 데이터베이스를 중지하고 다시 시작하여 시간이 지남에 따라 형성된 메모리 조각을 회수하십시오. 데이터베이스를 중지하고 다시 시작하면 다운타임이 발생하므로 이 작업은 최소한으로 수행하는 것이 좋습니다.