적용 대상: 
NoSQL MongoDB
Azure Cosmos DB의 처리량 재배포 기능을 사용하면 물리적 파티션 간에 프로비저닝된 처리량을 재배포할 수 있습니다. 이 문서에서는 파티션 간 Azure Cosmos DB 처리량 재배포에 대한 일반적인 질문과 대답을 제공합니다.
이 기능을 사용할 수 있는 리소스는 무엇인가요?
이 기능은 MongoDB 계정에 대한 SQL 및 API에 대해서만 지원됩니다. 전용 처리량(수동 또는 자동 스케일링)이 있는 공유 처리량 데이터베이스 및 컨테이너/컬렉션에 대해 지원됩니다. 이 기능은 서버리스 계정에 적용되지 않습니다.
미리 보기 기능에 등록하려면 어떻게 해야 하나요?
미리 보기에 등록할 필요가 없습니다. 이 기능을 사용하려면 Azure PowerShell 또는 Azure CLI 명령을 사용하여 리소스의 실제 파티션 전체에 처리량을 재배포하기만 하면 됩니다.
Azure PowerShell 및 Azure CLI에서 이 기능을 지원하는 Azure Cosmos DB 기능 버전은 무엇인가요?
실제 파티션에서 RU/s를 재배포하는 기능은 Azure PowerShell의 미리 보기 버전(버전 2.0.2-미리 보기 이상)[https://www.powershellgallery.com/packages/Az.CosmosDB/2.0.2-preview] 및 최신 미리 보기 버전의 Azure CLI에서만 지원됩니다.
한 요청에서 변경할 수 있는 물리적 파티션의 최대 수는 몇 개인가요?
- 단일 요청에 포함할 수 있는 원본 및 물리적 파티션의 최대 수는 각각 20개입니다.
- 각 요청에서 하나 이상의 원본과 하나의 대상 물리적 파티션을 제공해야 합니다. 원본 파티션에는 대상 파티션에 재배포할 수 있는 충분한 RU/s가 있어야 합니다.
- 각 대상 물리적 파티션에 대해 원하는 RU/s는 10,000RU/s 또는 전체 리소스의 총 RU/s를 초과할 수 없습니다. 원하는 RU/s가 전체 리소스의 RU/s보다 큰 경우 RU/s를 재배포하기 전에 먼저 전체 RU/s를 늘립니다.
파티션 간에 처리량을 재배포하기 위해 호출할 수 있는 빈도에 제한이 있나요?
분당 최대 5개 요청을 수행하여 파티션 간에 처리량을 재배포할 수 있습니다.
전체 RU/s를 변경하면 내 RU/s 배포는 어떻게 되나요?
RU/s를 낮추면 각 물리적 파티션은 새 RU/s(
current throughput fraction * new RU/s)의 동일한 비율을 가져옵니다. 예를 들어, 3개 물리적 파티션 및 6,000RU/s가 포함된 컬렉션이 있다고 가정해 보겠습니다. 3,000RU/s로 스케일 다운합니다.스케일 다운 전(6,000RU/s) 스케일 다운 후(3,000RU/s) 총 RU/s의 비율 P0: 1,000RU/s P0: 500RU/s 1/6 P1: 4,000RU/s P1: 2000RU/s 2/3 P2: 1,000RU/s P2: 500RU/s 1/6 RU/s를 늘리면 각 실제 파티션의 RU/s =
MIN(current throughput fraction * new RU/s, 10,000 RU/s)가 됩니다. 실제 분할의 RU/s는 10,000RU/s를 초과할 수 없습니다.예를 들어, 3개 물리적 파티션 및 6,000RU/s가 포함된 컬렉션이 있다고 가정해 보겠습니다. 최대 12,000RU/s로 스케일 업합니다.
스케일 업 전(6,000RU/s) 스케일 업 후(12,000RU/s) 총 RU/s의 비율 P0: 1,000RU/s P0: 20,00RU/s 1/6 P1: 4,000RU/s P1: 8,000RU/s 2/3 P2: 1,000RU/s P2: 2,000RU/s 1/6
내 컨테이너의 전체 RU/s와 모든 실제 파티션의 RU/s 합계 간에 불일치가 표시되는 이유는 무엇인가요?
이 불일치는 단일 파티션에 대한 전체 RU/s가 스케일 업할 때, 즉
(current RU/s per partition * new container RU/s)/(old container RU/s)가 10,000RU/s보다 큰 경우 발생할 수 있습니다. 이 불일치는currentNumberOfPartitions * 10,000 RU/s를 초과하도록 RU/s를 늘려 파티션 분할을 트리거하거나 파티션 분할을 트리거하지 않고 RU/s를 늘릴 때 발생할 수 있습니다.스케일 업 후에 처리량을 균등하게 재배포하는 것이 좋습니다. 그렇지 않으면 프로비전한(비용이 청구되는) 모든 RU/s를 사용하지 못할 수 있습니다.
이 시나리오가 리소스에 적용되는지 확인하려면 Azure Monitor 메트릭을 사용합니다. ProvisionedThroughput(수동 처리량을 사용하는 경우) 또는 AutoscaleMaxThroughput(자동 스케일링을 사용하는 경우) 메트릭의 값을 PhysicalPartitionThroughput 메트릭 값에 비교합니다. PhysicalPartitionThroughput 값이 각 ProvisionedThroughput 또는 AutoscaleMaxThroughput보다 작은 경우 RU/s를 균등 배포로 재설정한 후 재배포하거나, 리소스 처리량을 PhysicalPartitionThroughput 값으로 낮춥니다.
예를 들어, 3개 물리적 파티션 및 6,000RU/s가 포함된 컬렉션이 있다고 가정해 보겠습니다. 최대 24,000RU/s로 스케일 업합니다. 스케일 업 후 모든 파티션의 총 처리량은 18,000RU/s에 불과합니다. 이 배포는 24,000RU/s에 대한 요금이 청구되는 동안 18,000RU/s의 유효 처리량만 얻을 수 있음을 의미합니다. RU/s가 동일하게 재배포되므로 각 파티션에서 8,000RU/s를 얻게 되며, 필요에 따라 RU/s를 다시 재배포할 수 있습니다. 전체 RU/s를 18,000RU/s로 낮추도록 선택할 수도 있습니다.
스케일 업 전(6,000RU/s) 최대 24,000RU/s로 스케일 업 후(유효 RU/s = 18,000RU/s) 총 RU/s의 비율 P0: 1,000RU/s P0: 4,000RU/s 1/6 P1: 4,000RU/s P1: 10,000RU/s(파티션은 10,000RU/s를 초과할 수 없음) 2/3 P2: 1,000RU/s P2: 4,000RU/s 1/6