Azure Cosmos DB의 자동 크기 조정 프로비전된 처리량 FAQ

적용 대상: NoSQL MongoDB Cassandra Gremlin 테이블

Azure Cosmos DB는 자동 크기 조정 프로비전된 처리량을 사용하여 사용량에 따라 데이터베이스 또는 컨테이너의 RU/s(초당 요청 단위)를 자동으로 관리하고 스케일링합니다. 이 문서에서는 Azure Cosmos DB의 자동 크기 조정에 대한 일반적인 질문에 대답합니다.

Azure Cosmos DB에서 자동 크기 조정과 autopilot의 차이점은 무엇인가요?

자동 크기 조정 또는 자동 크기 조정 프로비전된 처리량은 이전에 autopilot이라고 불렸던 Azure Cosmos DB 기능의 새로운 이름입니다. 최신 릴리스의 자동 크기 조정에서는 프로그래밍 방식 지원과 사용자 지정 최대 RU/s를 설정하는 기능을 포함하여 여러 가지 새 기능이 추가되었습니다.

이전 autopilot 계층 모델에서 만든 데이터베이스나 컨테이너는 어떻게 되나요?

이전 계층 모델에서 만든 리소스는 자동으로 새 자동 크기 조정 사용자 지정 최대 RU/s 모델에서 지원됩니다. 계층의 상한이 새 최대 RU/s가 되며, 이를 통해 동일한 크기 조정 범위가 생성됩니다.

예를 들어 이전에 400~4,000RU/s 사이에서 크기 조정되는 계층을 선택한 경우 데이터베이스 또는 컨테이너는 이제 4,000RU/s의 최대 RU/s를 갖는 것으로 표시되고 400~4,000RU/s 사이에서 스케일링됩니다. 고객은 워크로드에 맞게 최대 RU/s를 사용자 지정 값으로 변경할 수 있습니다.

자동 크기 조정의 진입점 RU/s는 얼마인가요?

2022년 4월부터 최대 RU/가 1000RU/s(100RU/s~1000RU/s 사이에서 스케일링)인 자동 크기 조정을 설정할 수 있습니다. 스케일링 범위를 200~2,000RU/s 또는 300~3,000RU/s로 설정할 수도 있습니다. 이전에는 진입점이 400~4000RU/s였습니다.

처리량 요구 사항은 낮지만 최대 RU/s까지 스케일링할 가능성이 있는 워크로드에는 이 구성을 사용하는 것이 좋습니다.

자동 크기 조정은 트래픽 증가에 따라 얼마나 빠르게 스케일 업되나요?

자동 크기 조정을 사용하면 시스템이 수신 트래픽에 따라 0.1×Tmax~Tmax 범위 내에서 처리량(RU/s) T를 스케일 업 또는 T를 스케일 다운합니다. 크기 조정은 언제든지 자동으로 또한 즉각적으로 진행되므로 지연 없이 프로비전된 Tmax까지 사용할 수 있습니다.

시스템이 현재 크기 조정된 RU/s는 어떻게 확인하나요?

Azure Monitor 메트릭을 사용하여 프로비전된 자동 크기 조정 최대 RU/s와 시스템이 스케일링된 현재 처리량(RU/s)을 모두 모니터링할 수 있습니다.

자동 크기 조정은 어떻게 가격이 책정되나요?

매시간마다 시스템이 해당 시간 내에 크기 조정된 최고 처리량 T에 대한 요금이 청구됩니다. 해당 시간 동안 리소스에 요청이 없거나 리소스가 0.1 × Tmax를 초과하여 스케일링되지 않은 경우 적어도 0.1 × Tmax에 대한 요금이 청구됩니다. 자세한 내용은 Azure Cosmos DB 가격 책정 페이지를 참조하세요.

자동 크기 조정은 청구서에 어떻게 표시되나요?

단일 쓰기 지역 계정에서 100RU/s당 자동 크기 조정 요금은 표준(수동) 프로비전된 처리량 요금의 1.5배입니다. 청구서에는 기존의 표준 프로비전된 처리량 미터가 표시됩니다. 이 미터의 수량에 1.5를 곱합니다. 예를 들어 시스템이 특정 시간 동안 최고 6,000RU/s까지 스케일링되었다면 해당 시간 동안 60 x 1.5 = 90단위에 대한 미터 요금이 청구됩니다.

다중 쓰기 지역의 계정에서 100RU/s당 자동 크기 조정 요금은 표준(수동) 프로비전된 다중 쓰기 지역 처리량의 요금과 동일합니다. 청구서에는 기존의 다중 쓰기 지역 미터가 표시됩니다. 요금이 동일하므로 자동 크기 조정을 사용하더라도 표준 처리량과 동일한 수량이 표시됩니다.

자동 크기 조정 기능은 예약된 용량에 적용되나요?

예. 단일 쓰기 지역의 계정에 대해 예약된 용량을 사용하면 자동 크기 조정 리소스에 대한 예약 할인이 1.5 x 특정 지역 요율로 미터 사용량에 적용됩니다. 예를 들어 예약된 용량을 사용하여 10,000개의 자동 크기 조정 RU/s를 지원하려는 경우 전체적으로 15,000RU/s의 예약 용량 구매를 계획해야 합니다.

다중 쓰기 지역 예약된 용량은 자동 크기 조정 프로비전된 처리량과 표준(수동) 프로비전된 처리량에서 동일하게 적용됩니다. 자세한 내용은 Azure Cosmos DB 예약 용량을 참조하세요.

자동 크기 조정은 Azure Cosmos DB 무료 계층에서 작동하나요?

예. 무료 계층에서는 데이터베이스 또는 컨테이너에 자동 크기 조정 처리량을 사용할 수 있습니다. 자세한 내용은 무료 계층 청구가 자동 크기 조정에 적용되는 방식을 참조하세요.

모든 API에 대해 자동 크기 조정이 지원되나요?

예. 자동 크기 조정은 NoSQL, Gremlin, Table, Cassandra 및 MongoDB를 비롯한 모든 API를 지원합니다.

다중 쓰기 지역 계정에 대해 자동 크기 조정이 지원되나요?

예. 최대 RU/s는 Azure Cosmos DB 계정에 추가된 각 지역에서 사용할 수 있습니다.

새 데이터베이스 또는 컨테이너에서 자동 크기 조정을 사용하려면 어떻게 해야 하나요??

기존 데이터베이스 또는 컨테이너에서 자동 크기 조정을 사용할 수 있나요?

예. 자동 크기 조정과 표준(수동) 프로비전된 처리량 사이에 전환할 수도 있습니다. 현재 모든 API의 경우 Azure Portal, Azure CLI 또는 PowerShell을 사용하여 이러한 작업을 수행할 수 있습니다. 설계상, Azure Cosmos DB 클라이언트 SDK 또는 Azure Resource Manager 템플릿을 사용하여 수동 프로비전된 처리량과 자동 크기 조정 간에 마이그레이션할 수 없습니다. 그러나 클라이언트 SDK 또는 Azure Resource Manager 템플릿을 사용하여 새 자동 크기 조정 리소스를 만들고 기존 자동 크기 조정 리소스의 최대 RU/s를 변경할 수 있습니다.

자동 크기 조정과 표준(수동) 프로비전된 처리량 간의 마이그레이션은 어떻게 이루어지나요?

개념적으로 처리량 유형 변경은 2단계 프로세스입니다. 먼저 자동 크기 조정 또는 수동 프로비전된 처리량을 사용하도록 처리량 설정을 변경하는 요청을 보냅니다. 두 경우 모두 시스템이 현재 처리량 설정 및 스토리지에 따라 초기 RU/s 값을 자동으로 확인하여 설정합니다. 이 단계를 수행하는 동안에는 사용자가 제공한 RU/s 값이 허용되지 않습니다. 그런 다음, 업데이트가 완료되면 워크로드에 맞게 RU/s를 변경할 수 있습니다.

표준(수동) 프로비전된 처리량에서 자동 크기 조정으로 마이그레이션

컨테이너의 경우 다음 수식을 사용하여 초기 자동 크기 조정 최대 RU/s를 추정합니다.

MAX(1,000, current manual provisioned RU/s, maximum RU/s ever provisioned / 10, storage in GB × 10)(가장 가까운 1000 RU/s로 반올림)

실제 초기 자동 크기 조정 최대 RU/s는 계정 구성에 따라 다를 수 있습니다.

예제 #1: 수동 프로비전된 처리량이 10,000RU/s이고 스토리지가 25GB인 컨테이너가 있습니다. 자동 크기 조정을 사용하도록 설정하면 초기 자동 크기 조정 최대 RU/s는 10,000RU/s이며, 1,000~10,000RU/s 사이에서 스케일링할 수 있습니다.

예제 #2: 수동 프로비전된 처리량이 50,000RU/s이고 스토리지가 25,000GB인 컨테이너가 있습니다. 자동 크기 조정을 사용하도록 설정하면 초기 자동 크기 조정 최대 RU/s는 250,000RU/s이며, 25,000~250,000RU/s 사이에서 스케일링할 수 있습니다.

자동 크기 조정에서 표준(수동) 프로비전된 처리량으로 마이그레이션

초기 수동 프로비전된 처리량은 현재 자동 크기 조정 최대 RU/s와 동일합니다.

예제: 최대 RU/s가 20,000RU/s(2,000~20,000RU/s 사이에서 스케일링)인 자동 크기 조정 데이터베이스 또는 컨테이너가 있습니다. 수동으로 프로비저닝된 처리량을 사용하도록 업데이트하면 초기 처리량은 20,000RU/s입니다.

Azure CLI, PowerShell 또는 Azure Resource Manager를 사용하여 자동 크기 조정을 사용하는 데이터베이스 또는 컨테이너를 관리할 수 있나요?

예. 기존 데이터베이스 또는 컨테이너에서 프로그래밍 방식으로 자동 크기 조정을 사용하도록 설정하려면 Azure CLI 또는 PowerShell을 사용하면 됩니다.

자동 크기 조정을 사용하는 새 데이터베이스 또는 컨테이너를 만들려면 Azure CLI, PowerShell또는 Azure Resource Manager 템플릿을 사용하면 됩니다.

공유 처리량 데이터베이스에 대해 자동 크기 조정이 지원되나요?

예. 공유 처리량 데이터베이스에 자동 크기 조정을 사용하도록 설정하려면 데이터베이스를 만들 때 자동 크기 조정과 처리량 프로비전 옵션을 선택합니다.

자동 크기 조정을 사용할 때 공유 처리량 데이터베이스당 허용되는 컨테이너는 몇 개인가요?

Azure Cosmos DB는 공유 처리량 데이터베이스에서 최대 25개의 컨테이너를 허용합니다. 이 최댓값은 자동 크기 조정 또는 표준(수동) 처리량을 사용하는 데이터베이스에 적용됩니다.

자동 크기 조정은 데이터베이스 일관성 수준에 어떤 영향을 주나요?

자동 크기 조정은 데이터베이스의 일관성 수준에 영향을 미치지 않습니다.

자세한 내용은 일관성 수준을 참조하세요.

각 최대 RU/s 옵션과 관련된 스토리지 제한은 무엇인가요?

각 최대 RU/s의 스토리지 제한(GB)은 데이터베이스 또는 컨테이너의 최대 RU/s를 10으로 나눈 값입니다. 예를 들어 최대 RU/s가 20,000RU/s이면 리소스에서 2,000GB 스토리지를 지원할 수 있습니다.

사용 가능한 최대 RU/s 및 스토리지 옵션은 처리량 프로비전 자동 크기 조정 제한을 참조하세요.

내 최대 처리량과 관련된 스토리지 제한을 초과하면 어떻게 되나요?

데이터베이스 또는 컨테이너의 최대 처리량과 연결된 스토리지 제한을 초과하면 Azure Cosmos DB는 최대 처리량을 해당 스토리지 수준을 지원할 수 있는 그 다음으로 높은 RU/s로 자동 상향합니다.

예를 들어 최대 50,000RU/s(5,000~50,000RU/s 사이에서 스케일링)로 시작하는 경우 최대 5,000GB까지 데이터를 저장할 수 있습니다. 스토리지 크기가 5,001GB로 증가하면 스토리지는 이제 6,000GB이고 새로운 최대 RU/s는 60,000RU/s(6,000~60,000RU/s 사이에서 스케일링)입니다.

데이터베이스 또는 컨테이너에서 최대 RU/s를 변경할 수 있나요?

예. 자세한 내용은 자동 크기 조정 처리량을 프로비전하는 방법을 참조하세요.

요청된 값에 따라 최대 RU/s를 변경할 때, 비동기 작업이 완료될 때까지 4~6시간이 걸릴 수 있습니다. 자세히 알아보기.

최대 RU/s를 늘리려면 어떻게 해야 하나요?

최대 RU/s Tmax를 높이라는 요청을 보낼 때, 선택한 최대 RU/s에 따라 서비스가 더 높은 최대 RU/s를 지원하기 위해 더 많은 리소스를 프로비전합니다. 이 프로세스가 발생하는 동안 기존 워크로드 및 작업에는 영향을 주지 않습니다. 시스템은 새로운 스케일링 범위 0.1×Tmax_new~Tmax_new가 준비될 때까지 데이터베이스 또는 컨테이너를 계속해서 기존 0.1×Tmax~Tmax 사이에서 스케일링합니다.

최대 RU/s를 낮추려면 어떻게 해야 하나요?

최대 RU/s를 낮출 때 설정할 수 있는 최솟값은 MAX(1,000, highest maximum RU/s ever provisioned / 10, current storage in GB × 10)(가장 가까운 1,000RU/s 단위로 반올림)입니다.

예제 #1: 최대 RU/s가 20,000RU/s(2,000~20,000RU/s 사이에서 스케일링)이고 스토리지가 1,500GB인 자동 크기 조정 컨테이너가 있습니다. 최대 RU/s를 가장 낮게 설정할 수 있는 최솟값은 MAX(1,000, 20,000 / 10, 1,500 × 10) = 15,000RU/s(1,500~15,000RU/s 사이에서 스케일링)입니다.

예제 #2: 최대 RU/s가 100,000RU/s이고 스토리지가 100GB인 자동 크기 조정 컨테이너가 있습니다. 최대 RU/s를 최대 150,000RU/s(15,000~150,000RU/s 사이에서 스케일링)로 스케일 업합니다. 이제 최대 RU/s를 가장 낮게 설정할 수 있는 최솟값은 MAX(1,000, 150,000 / 10, 100 × 10) = 15,000RU/s(1,500~15,000RU/s 사이에서 스케일링)입니다.

공유 처리량 데이터베이스의 경우 최대 RU/s를 낮출 때 설정할 수 있는 최솟값은 MAX(1,000, highest maximum RU/s ever provisioned / 10, current storage in GB × 10, 1,000 + (MAX(Container count - 25, 0) × 1,000))(가장 가까운 1,000RU/s 단위로 반올림)입니다.

이러한 수식과 예제는 설정 가능한 최소 자동 크기 조정 최대 RU/s에 적용됩니다. 시스템이 자동으로 스케일링하는 0.1×Tmax~Tmax 범위로 구분됩니다. 최대 RU/s에 관계없이 시스템은 항상 0.1×Tmax~Tmax 사이에서 스케일링됩니다.

TTL은 자동 크기 조정에서 어떻게 작동하나요?

TTL(Time to Live) 연산은 자동 크기 조정의 RU/s 스케일링에 영향을 주지 않습니다. TTL 때문에 사용된 모든 RU는 자동 크기 조정 컨테이너의 요금이 청구되는 RU/s에 포함되지 않습니다.

예를 들어 RU/s가 400~4,000RU/s인 자동 크기 조정 컨테이너는 다음과 같습니다.

  • 시간 1: T=0: 컨테이너에 사용량이 없습니다(TTL 또는 워크로드 요청이 없음). 청구 가능 RU/s는 400RU/s입니다.
  • 시간 1: T=1: TTL이 사용하도록 설정됩니다.
  • 시간 1: T=2: 컨테이너가 요청을 가져오기 시작합니다. 요청이 1초에 1,000RU를 사용합니다. 200RU 상당의 TTL이 사용됩니다. 요금이 청구되는 RU/s는 여전히 1,000RU/s입니다. TTL 삭제가 발생하는 시점과 관계없이 자동 크기 조정 스케일링 논리에 영향을 주지 않습니다.

최대 RU/s는 실제 파티션에 어떻게 매핑되나요?

최대 RU/s를 처음으로 선택하면 Azure Cosmos DB는 최대 RU/s를 10,000RU/s로 나누어 필요한 수만큼 물리적 파티션을 가져와서 프로비전합니다. 각 실제 파티션은 최대 10,000RU/s 및 50GB 스토리지를 지원할 수 있습니다. 스토리지 크기가 커지면 Azure Cosmos DB는 스토리지 증가를 처리하기 위해 파티션을 자동으로 분할하여 더 많은 물리적 파티션을 추가합니다. 스토리지가 연결된 제한을 초과하면 Azure Cosmos DB는 최대 RU/s를 늘립니다.

데이터베이스 또는 컨테이너의 최대 RU/s가 모든 물리적 파티션에 균등하게 분배됩니다. 한 물리적 파티션이 스케일링할 수 있는 총 처리량은 데이터베이스 또는 컨테이너의 최대 RU/s를 물리적 파티션 수로 나눈 값입니다.

수신 요청이 데이터베이스 또는 컨테이너의 최대 RU/s를 초과하면 어떻게 되나요?

사용된 전체 RU/s가 데이터베이스 또는 컨테이너의 최대 RU/s를 초과하는 경우 최대 RU/s를 초과하는 요청은 제한되고 429 상태 코드를 반환합니다. 정규화된 사용률이 100%를 초과하는 요청은 제한됩니다. 정규화된 사용률은 모든 물리적 파티션에서 RU/s 사용률의 최댓값으로 정의됩니다.

예를 들어 최대 처리량이 20,000RU/s이고 물리적 파티션 P_1 및 P_2가 있습니다. 각 파티션은 10,000RU/s로 스케일링할 수 있습니다. 특정 초에 P_1이 6,000RU를 사용하고, P_2가 8,000RU를 사용한 경우 정규화된 사용률은 MAX(6,000 RU / 10,000 RU, 8,000 RU / 10,000 RU) = 0.8입니다.

참고 항목

Azure Cosmos DB 클라이언트 SDK 및 데이터 가져오기 도구(Azure Data Factory, 대량 실행기 라이브러리)는 코드 429 오류가 반환된 후 자동으로 다시 시도하므로, 가끔 코드 429 오류가 발생해도 문제가 되지 않습니다. 코드 429 오류 발생 횟수가 지속적으로 높으면 최대 RU/s를 늘리거나 핫 파티션을 포함하도록 분할 전략을 검토해야 한다는 의미일 수 있습니다.

자동 크기 조정을 사용하도록 설정할 때 제한 또는 속도 제한 오류가 발생할 수 있나요?

예. 다음 두 가지 시나리오에서 코드 429 오류가 발생할 수 있습니다.

첫째, 사용된 전체 RU/s가 데이터베이스 또는 컨테이너의 최대 RU/s를 초과하는 경우 서비스가 적절히 요청을 제한합니다.

둘째, 논리적 파티션 키 값의 요청 수가 다른 파티션 키 값에 비해 과도하게 많은 경우(예: 핫 파티션) 기본 물리적 파티션이 RU/s 예산을 초과할 수 있습니다. 핫 파티션을 방지하려면 스토리지와 처리량을 모두 균등하게 분산하는 우수한 파티션 키를 선택합니다.

예를 들어 최대 처리량 옵션을 20,000RU/s로 선택하고 200GB 스토리지가 있는 경우 물리적 파티션이 4개 있으면 각 물리적 파티션이 최대 5,000RU/s까지 자동 크기 조정될 수 있습니다. 핫 파티션이 특정 논리 파티션 키에 있는 경우 해당 파티션이 있는 기본 물리적 파티션이 5,000RU/s 또는 100% 정규화된 사용률을 초과하면 코드 429 오류가 발생합니다.

자동 크기 조정을 사용할 때 코드 429 오류가 발생한다고 해서 반드시 데이터베이스 또는 컨테이너에 문제가 있는 것은 아닙니다. 일반적으로 프로덕션 워크로드의 경우 요청의 1~5% 사이에서 코드 429 오류가 발생하고 엔드투엔드 대기 시간이 허용되는 경우 오류는 RU/s가 완전히 활용되고 있다는 정상적인 신호입니다. 사용자가 조치할 필요는 없습니다.

429 속도 제한 오류를 해석하고 디버그하는 방법에 대해 자세히 알아보세요.

자동 크기 조정이 최대 RU/s로 크기 조정되지 않는 경우 정규화된 RU/s 사용량이 100%가 될 수 있나요?

예. 자세한 내용은 정규화된 RU/s 모니터링을 참조하세요.