이 문서에서는 Azure Resource Manager가 요청을 제한하는 방법을 설명합니다. 한도에 도달하기 전에 남아 있는 요청 수를 추적하는 방법과 한도에 도달했을 때 응답하는 방법을 보여 줍니다.
지역별 속도 제한 및 토큰 버킷 알고리즘
Microsoft는 2024년부터 Azure 구독을 업데이트된 제한 아키텍처로 마이그레이션했습니다. 이제 Azure Resource Manager 인스턴스가 아닌 지역별로 제한 제한이 적용됩니다. 이 새 아키텍처는 토큰 버킷 알고리즘 을 사용하여 API 제한을 관리합니다.
토큰 버킷은 초당 보낼 수 있는 최대 요청 수를 나타냅니다. 최대 요청 수에 도달하면 다시 채우기 속도에 따라 버킷에서 토큰을 사용할 수 있게 되는 속도가 결정됩니다.
업데이트된 한도를 통해 할당량을 새로 고치고 관리하는 것이 더 쉬워졌습니다.
업데이트된 제한은 다음과 같습니다.
| 범위 | 작업 | 버킷 크기 | 초당 다시 채우기 속도 |
|---|---|---|---|
| 구독 | reads | 250 | 이십오 (25) |
| 구독 | 삭제 | 200 | 10 |
| 구독 | 작성합니다 | 200 | 10 |
| 테넌트 | reads | 250 | 이십오 (25) |
| 테넌트 | 삭제 | 200 | 10 |
| 테넌트 | 작성합니다 | 200 | 10 |
구독 한도는 구독당, 서비스 주체당, 작업 유형당 적용됩니다. 각 작업 유형에 대한 개별 서비스 주체 한도의 15배에 해당하는 전역 구독 한도도 있습니다. 글로벌 한도는 모든 서비스 주체에 적용됩니다. 글로벌, 서비스 주체 또는 테넌트별 한도를 초과하면 요청이 제한됩니다.
무료 또는 평가판 고객의 경우 한도가 더 작을 수 있습니다.
예를 들어, 읽기 요청에 대해 250개 토큰의 버킷 크기와 초당 25개 토큰의 다시 채우기 속도이 있다고 가정해 보겠습니다. 1초에 250개의 읽기 요청을 보내면 버킷이 비어 있고 요청이 제한됩니다. 버킷이 최대 용량인 250개 토큰에 도달할 때까지 매초 25개의 토큰이 사용 가능해집니다. 토큰은 사용 가능해지면 사용할 수 있습니다.
*/providers/microsoft.insights/metrics API를 사용하여 메트릭을 읽으면 전체 Azure Resource Manager 트래픽이 상당히 증가하며 구독 제한 이벤트의 일반적인 원인입니다. 이 API를 많이 사용하시는 경우 getBatch API로 전환하는 것이 좋습니다. 단일 REST 요청에서 여러 리소스를 쿼리할 수 있으므로 성능이 개선되고 제한이 줄어듭니다. 작업 변환에 대한 자세한 내용은 메트릭 API에서 getBatch API로 마이그레이션하는 방법을 참조하세요.
이러한 제한 및 아키텍처는 2026년 말까지 모든 소버린 클라우드에도 적용됩니다.
처리 속도가 제한된 요청을 보려면 어떻게 해야 하나요?
제한된 요청 및 기타 Resource Manager 메트릭을 보려면 Azure Resource Manager 메트릭 액세스를 참조하세요.
인스턴스별이 아닌 지역별로 제한이 적용되는 이유는 무엇인가요?
지역마다 Resource Manager 인스턴스 수가 다르기 때문에 인스턴스당 제한을 적용하면 제한 성능이 일관되지 않습니다. 지역별로 제한을 두어 일관적이고 예측 가능한 제한을 구현합니다.
업데이트된 제한 환경이 내 제한에 어떤 영향을 미치나요?
더 많은 요청을 보낼 수 있습니다. 쓰기 요청이 30배 증가했습니다. 삭제 요청이 2.4배 증가했습니다. 읽기 요청이 7.5배 증가했습니다.
백그라운드 작업 제한
ARM(Azure Resource Manager)의 백그라운드 작업은 리소스 배포, 진단 및 시스템 유지 관리와 같은 작업을 지원하기 위해 백그라운드에서 실행되는 자동화된 작업입니다. 이러한 작업은 사용자 요청을 처리하고 서비스 기능을 보장하는 데 필수적입니다. 플랫폼 안정성과 안정성을 유지하기 위해 ARM은 백그라운드 작업 제한을 사용하여 이러한 작업의 부하를 관리합니다.
다음 오류 메시지가 표시되면 백그라운드 작업 제한이 발생하는 시기를 식별할 수 있습니다.
The request for subscription '{0}' could not be processed due to an excessive volume of traffic. Please try again later.
고객은 과도한 백그라운드 프로세스로 인해 속도 제한을 경험할 수 있으며, 이는 빈번한 작업이나 시스템 전반의 활동에 의해 발생할 수 있습니다. 고객은 이러한 작업의 생성 또는 실행을 직접 제어할 수 없지만 잠재적인 제한에 대한 인식이 중요합니다.
소버린 클라우드에 대한 제한
제한은 두 수준에서 발생합니다. Azure Resource Manager가 구독 및 테넌트에 대한 요청을 제한합니다. 요청이 구독 및 테넌트의 제한 한도 하에 있는 경우 Resource Manager는 리소스 공급자에게 요청을 라우팅합니다. 리소스 공급자는 해당 작업에 맞게 조정된 제한을 적용합니다.
요청은 처음에 요청을 보내는 사용자의 지역에서 주체 ID 및 Azure Resource Manager 인스턴스별로 제한됩니다. 해당 지역의 Azure Resource Manager 인스턴스에 대한 요청도 주 사용자 ID 및 시간당 제한됩니다. 요청이 리소스 공급자에 전달되면 요청은 사용자 지역의 Azure Resource Manager 인스턴스가 아닌 리소스의 지역별로 제한됩니다.
비고
리소스 공급자의 제한은 사용자 지역에 있는 Azure Resource Manager 인스턴스의 제한과 다를 수 있습니다.
다음 이미지에서는 요청이 사용자로부터 Azure Resource Manager 및 리소스 공급자로 진행될 때 제한이 적용되는 방식을 보여 줍니다.
구독 및 테넌트 한도
모든 구독 수준 및 테넌트 수준 작업에는 제한이 적용됩니다. 구독 요청은 구독 내의 리소스 그룹 검색과 같이 구독 ID가 전달되는 요청입니다. 예를 들어, https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups?api-version=2022-01-01에 요청을 보내는 것은 구독 수준 작업입니다. 유효한 Azure 위치 검색 등의 테넌트 요청에는 구독 ID가 포함되지 않습니다. 예를 들어, https://management.azure.com/tenants?api-version=2022-01-01에 요청을 보내는 것은 테넌트 수준 작업입니다.
시간당 기본 제한 한도는 다음 표에 나와 있습니다.
| 범위 | 작업 | 제한 |
|---|---|---|
| 구독 | reads | 12,000 |
| 구독 | 삭제 | 15,000 |
| 구독 | 작성합니다 | 1,200 |
| 테넌트 | reads | 12,000 |
| 테넌트 | 작성합니다 | 1,200 |
이러한 제한의 범위는 요청을 하는 보안 주체(사용자 또는 애플리케이션) 및 구독 ID나 테넌트 ID의 범위로 설정됩니다. 둘 이상의 보안 주체가 요청을 하는 경우 구독 또는 테넌트 전체에 적용되는 제한이 시간당 12,000개/1,200개보다 커집니다.
이러한 한도는 각 Azure Resource Manager 인스턴스에 적용됩니다. 모든 Azure 지역에 여러 인스턴스가 있으며 Azure Resource Manager가 모든 Azure 지역에 배포됩니다. 따라서 실제로 제한은 이러한 제한보다 높습니다. 일반적으로 Azure Resource Manager의 여러 인스턴스가 사용자 요청을 처리합니다.
나머지 요청은 응답 헤더 값으로 반환됩니다.
리소스 공급자 제한
리소스 공급자는 자체 제한 한도를 적용합니다. 각 구독 내에서 리소스 공급자는 요청에서 리소스의 지역별로 제한합니다. Resource Manager는 Resource Manager의 인스턴스로 제한되고 각 지역에 여러 Resource Manager 인스턴스가 있기 때문에 리소스 공급자는 이전 섹션의 기본 제한보다 더 많은 요청을 받을 수 있습니다.
이 섹션에서는 광범위하게 사용되는 일부 리소스 공급자의 제한 한도에 대해 설명합니다.
스토리지 제한
다음 제한은 Azure Resource Manager를 Azure Storage 및 스토리지 리소스 공급자와 함께 사용하여 관리 작업을 수행하는 경우에만 적용됩니다. 제한은 요청의 리소스 지역별 구독별로 적용됩니다.
| 리소스 | 제한 |
|---|---|
| Storage 계정 관리 작업(읽기) | 5분당 800 |
| Storage 계정 관리 작업(쓰기) | 초당 10/시간당 1,200 |
| Storage 계정 관리 작업(목록) | 5분당 100 |
네트워크 제한
Microsoft. Network 리소스 공급자는 다음과 같은 제한 한도를 적용합니다.
| 작업(Operation) | 제한 |
|---|---|
| 쓰기/삭제(PUT) | 5분당 1,000개 |
| 읽기(GET) | 5분당 10,000개 |
이러한 일반적인 제한 외에도 Azure DNS에 대한 사용 제한을 참조하세요.
계산 제한
Microsoft Compute는 가상 머신 및 가상 머신 확장 집합 사용자에게 최적의 환경을 제공하기 위해 제한 기능을 구현합니다. 컴퓨팅 제한 한도는 VM, Virtual Machine Scale Sets 및 확장 집합 VM에 대한 제한 정책 및 한도에 대한 포괄적인 정보를 제공합니다.
Azure Resource Graph 제한
Azure Resource Graph는 해당 작업에 대한 요청 수를 제한합니다. 이 문서에서 제한에 도달했을 때 응답하는 방법 및 남은 요청을 결정하는 단계는 Resource Graph에도 적용됩니다. 그러나 Resource Graph는 자체 제한 및 재설정 비율을 설정합니다. 자세한 내용은 Resource Graph 제한 헤더를 참조하세요.
또한 Azure Resource Graph에는 기존 Azure Resource Manager 컨트롤 플레인 GET 및 LIST API와 원활하게 통합하여 리소스 공급자 제한 제한에 도달했을 때 리소스 데이터를 가져오기 위한 추가 메커니즘을 사용하도록 설정하는 솔루션이 있으며, 리소스 데이터 액세스를 위한 강력하고 확장 가능한 솔루션을 제공합니다. 자세한 내용은 ARG GET/LIST API를 참조하세요.
기타 리소스 공급자
기타 리소스 공급자의 제한에 대한 자세한 내용은 다음을 참조하세요.
오류 코드
한도에 도달하면 HTTP 상태 코드 429 너무 많은 요청이 표시됩니다. 응답에는 Retry-After 값이 포함되어 있는데, 이는 애플리케이션이 다음 요청을 보내기 전에 기다려야 하는 시간(초)을 지정합니다. 다시 시도 값이 경과하기 전에 요청을 보내면 요청이 처리되지 않고 새 다시 시도 값이 반환됩니다.
Azure SDK를 사용하는 경우 SDK에 자동 다시 시도 구성이 있을 수 있습니다. 자세한 내용은 Azure 서비스에 대한 다시 시도 지침을 참조하세요.
일부 리소스 공급자는 429를 반환하여 임시 문제를 보고합니다. 문제는 사용자의 요청으로 인해 발생하지 않은 오버로드 조건일 수 있습니다. 또는 대상 리소스나 종속 리소스의 상태에 대한 일시적인 오류일 수도 있습니다. 예를 들어, 네트워크 리소스 공급자는 다른 작업이 대상 리소스를 잠그면 RetryableErrorDueToAnotherOperation 오류 코드와 함께 429를 반환합니다. 오류가 제한 또는 일시적인 상태에서 발생하는지 확인하려면 응답에서 오류 세부 정보를 확인합니다.
나머지 요청
응답 헤더를 검사하여 나머지 요청 수를 확인할 수 있습니다. 읽기 요청은 나머지 읽기 요청 수에 대한 헤더의 값을 반환합니다. 쓰기 요청에는 나머지 쓰기 요청 수에 대한 값이 포함됩니다. 다음 표에서는 해당 값을 검사할 수 있는 응답 헤더를 설명합니다.
| 응답 헤더 | 설명 |
|---|---|
| x-ms-ratelimit-remaining-subscription-deletes | 구독 범위 삭제가 남아 있습니다. 이 값은 삭제 작업에서 반환됩니다. |
| x-ms-ratelimit-remaining-subscription-reads | 구독에 범위가 지정된 나머지 읽기. 이 값은 읽기 작업에서 반환됩니다. |
| x-ms-ratelimit-remaining-subscription-writes | 구독에 범위가 지정된 나머지 쓰기. 이 값은 쓰기 작업에서 반환됩니다. |
| x-ms-ratelimit-remaining-tenant-reads | 테넌트에 범위가 지정된 나머지 읽기. |
| x-ms-ratelimit-remaining-tenant-writes | 테넌트에 범위가 지정된 나머지 쓰기. |
| x-ms-ratelimit-remaining-subscription-resource-requests | 남아 있는 구독 범위 리소스 종류 요청. 이 헤더 값은 서비스가 기본 제한을 재정의하는 경우에만 반환됩니다. Resource Manager는 구독 읽기 또는 쓰기 대신 이 값을 추가합니다. |
| x-ms-ratelimit-remaining-subscription-resource-entities-read | 남아 있는 구독 범위 리소스 종류 컬렉션 요청. 이 헤더 값은 서비스가 기본 제한을 재정의하는 경우에만 반환됩니다. 이 값은 나머지 컬렉션 요청 수를 제공합니다(리소스 나열). |
| x-ms-ratelimit-remaining-tenant-resource-requests | 남아 있는 테넌트 범위 리소스 종류 요청. 이 헤더는 테넌트 수준의 요청에 추가되며, 서비스가 기본 제한을 재정의하는 경우에만 추가됩니다. Resource Manager는 테넌트 읽기 또는 쓰기 대신 이 값을 추가합니다. |
| x-ms-ratelimit-remaining-tenant-resource-entities-read | 테넌트에 범위가 지정된 나머지 리소스 종류 컬렉션 요청. 이 헤더는 테넌트 수준의 요청에만 추가되며, 서비스가 기본 제한을 재정의하는 경우에만 추가됩니다. |
리소스 공급자는 남은 요청에 대한 정보와 함께 응답 헤더를 반환할 수도 있습니다. 계산 리소스 공급자에서 반환하는 응답 헤더에 대한 자세한 내용은 통화 요금 정보 응답 헤더를 참조하세요.
헤더 값 검색
코드 또는 스크립트에서 이러한 헤더 값을 검색하는 것은 임의의 헤더 값을 검색하는 것과 같습니다.
예를 들어 C#에서는 다음 코드로 response로 명명된 HttpWebResponse 개체에서 헤더 값을 검색합니다.
response.Headers.GetValues("x-ms-ratelimit-remaining-subscription-reads").GetValue(0)
PowerShell에서 Invoke-WebRequest 작업의 헤더 값을 검색합니다.
$r = Invoke-WebRequest -Uri https://management.azure.com/subscriptions/{guid}/resourcegroups?api-version=2016-09-01 -Method GET -Headers $authHeaders
$r.Headers["x-ms-ratelimit-remaining-subscription-reads"]
전체 PowerShell 예를 보려면 지정된 구독에 대한 ARM 제한 확인을 참조하세요.
디버깅을 위한 나머지 요청을 보려면 PowerShell cmdlet에 -Debug 매개 변수를 제공합니다.
Get-AzResourceGroup -Debug
응답에는 다음 응답 값을 포함하여 여러 값이 포함되어 있습니다.
DEBUG: ============================ HTTP RESPONSE ============================
Status Code:
OK
Headers:
Pragma : no-cache
x-ms-ratelimit-remaining-subscription-reads: 11999
쓰기 제한을 가져오려면 쓰기 작업을 사용합니다.
New-AzResourceGroup -Name myresourcegroup -Location westus -Debug
응답에는 다음 값을 포함하여 여러 값이 포함되어 있습니다.
DEBUG: ============================ HTTP RESPONSE ============================
Status Code:
Created
Headers:
Pragma : no-cache
x-ms-ratelimit-remaining-subscription-writes: 1199
Azure CLI에서는 더 자세한 옵션을 사용하여 헤더 값을 검색합니다.
az group list --verbose --debug
이 명령은 다음 값을 포함하여 많은 값을 반환합니다.
msrest.http_logger : Response status: 200
msrest.http_logger : Response headers:
msrest.http_logger : 'Cache-Control': 'no-cache'
msrest.http_logger : 'Pragma': 'no-cache'
msrest.http_logger : 'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger : 'Content-Encoding': 'gzip'
msrest.http_logger : 'Expires': '-1'
msrest.http_logger : 'Vary': 'Accept-Encoding'
msrest.http_logger : 'x-ms-ratelimit-remaining-subscription-reads': '11998'
쓰기 제한을 가져오려면 쓰기 작업을 사용합니다.
az group create -n myresourcegroup --___location westus --verbose --debug
이 작업은 다음 값을 포함하여 많은 값을 반환합니다.
msrest.http_logger : Response status: 201
msrest.http_logger : Response headers:
msrest.http_logger : 'Cache-Control': 'no-cache'
msrest.http_logger : 'Pragma': 'no-cache'
msrest.http_logger : 'Content-Length': '163'
msrest.http_logger : 'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger : 'Expires': '-1'
msrest.http_logger : 'x-ms-ratelimit-remaining-subscription-writes': '1199'
다음 단계
- 제한 및 할당량에 대한 자세한 내용은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조하세요.
- 비동기 REST 요청 처리에 대해 알아보려면 Azure 비동기 작업 추적을 참조하세요.