API 제한 오류 문제 해결

아티클
07/30/2024

적용 대상: ✔️ Linux VM ✔️ Windows VM

Azure Compute 요청은 서비스의 전반적인 성능을 돕기 위해 구독 및 지역별로 제한될 수 있습니다. Microsoft.Compute 네임스페이스에서 리소스를 관리하는 Azure Compute 리소스 공급자(CRP)에 대한 모든 호출이 허용되는 최대 API 요청 속도를 초과하지 않도록 합니다. 이 문서에서는 API 제한, 제한 문제를 해결하는 방법에 대한 세부 정보, 제한을 방지하는 모범 사례를 설명합니다.

Azure Resource Manager 및 리소스 공급자에 의한 제한

Azure의 정문인 Azure Resource Manager는 들어오는 모든 API 요청에 대해 인증, 1차 유효성 검사 및 제한을 수행합니다. Azure Resource Manager 호출 속도 제한 및 관련 진단 응답 HTTP 헤더는 여기에 설명되어 있습니다.

Azure API 클라이언트에서 제한 오류가 발생하면 HTTP 상태는 429 너무 많은 요청입니다. 요청 제한이 Azure Resource Manager 또는 CRP와 같은 기본 리소스 공급자에 의해 수행되는지 이해하려면 GET 요청 및 x-ms-ratelimit-remaining-subscription-writes 비 GET 요청에 대한 응답 헤더를 검사 x-ms-ratelimit-remaining-subscription-reads 합니다. 나머지 호출 수가 0에 도달하면 Azure Resource Manager에서 정의한 구독의 일반 호출 제한에 도달합니다. 모든 구독 클라이언트에 의한 활동은 함께 집계됩니다. 그렇지 않은 경우 제한은 대상 리소스 공급자(요청 URL의 세그먼트에 /providers/<RP> 의해 주소가 지정된 리소스 공급자)에서 가져옵니다.

통화 속도 정보 응답 헤더

헤더	값 형식	예제	설명
x-ms-ratelimit-remaining-resource	`<source RP>/<policy or bucket>;<count>`	Microsoft.Compute/HighCostGet; 159	이 요청의 대상을 포함하여 리소스 버킷 또는 작업 그룹을 포함하는 제한 정책에 대한 나머지 API 호출 수
x-ms-request-charge	`<count>`	1	해당 정책의 제한에 대한 이 HTTP 요청에 대해 호출 수가 "청구"된 횟수입니다. 가장 일반적으로 1입니다. 가상 머신 확장 집합의 크기 조정과 같은 일괄 처리 요청은 여러 개 수를 청구할 수 있습니다.

API 요청에는 여러 제한 정책이 적용될 수 있습니다. 각 정책에 대해 별도의 x-ms-ratelimit-remaining-resource 헤더가 있습니다.

가상 머신 확장 집합 요청을 삭제하는 샘플 응답은 다음과 같습니다.

x-ms-ratelimit-remaining-resource: Microsoft.Compute/DeleteVMScaleSet;107 
x-ms-ratelimit-remaining-resource: Microsoft.Compute/DeleteVMScaleSet;587 
x-ms-ratelimit-remaining-resource: Microsoft.Compute/VMScaleSetBatchedVMRequests;3704 
x-ms-ratelimit-remaining-resource: Microsoft.Compute/VmssQueuedVMOperations;4720

제한 오류 세부 정보

429 HTTP 상태는 일반적으로 호출 속도가 제한에 도달했기 때문에 요청을 거부하는 데 사용됩니다. 컴퓨팅 리소스 공급자의 일반적인 제한 오류 응답은 아래 예제와 같습니다(관련 헤더만 표시).

HTTP/1.1 429 Too Many Requests
x-ms-ratelimit-remaining-resource: Microsoft.Compute/HighCostGet;0
Retry-After: 1200
Content-Type: application/json; charset=utf-8
{
  "code": "OperationNotAllowed",
  "message": "The server rejected the request because too many requests have been received for this subscription.",
  "details": [
    {
      "code": "TooManyRequests",
      "target": "HighCostGet",
      "message": "{\"operationGroup\":\"HighCostGet\",\"startTime\":\"2018-06-29T19:54:21.0914017+00:00\",\"endTime\":\"2018-06-29T20:14:21.0914017+00:00\",\"allowedRequestCount\":300,\"measuredRequestCount\":1238}"
    }
  ]
}

나머지 호출 수가 0인 정책은 제한 오류가 반환되기 때문에 발생합니다. 이 경우에 해당 정책은 HighCostGet입니다. 응답 본문의 전체 형식은 일반적인 Azure Resource Manager API 오류 형식입니다(OData에 따라). 주요 오류 코드 OperationNotAllowed는 컴퓨팅 리소스 공급자가 제한 오류(다른 유형의 클라이언트 오류 중)를 보고하는 데 사용하는 코드입니다. 내부 오류의 속성에는 message 제한 위반의 세부 정보가 포함된 직렬화된 JSON 구조가 포함됩니다.

위에서 설명한 것처럼 모든 제한 오류에는 클라이언트가 요청을 다시 시도하기 전에 대기해야 하는 최소 시간(초)을 제공하는 헤더가 포함 Retry-After 됩니다.

API 호출 속도 및 제한 오류 분석기

문제 해결 기능의 미리 보기 버전은 Compute 리소스 공급자의 API에 대해 사용 가능합니다. 이러한 PowerShell cmdlet은 작업당 시간 간격당 API 요청 속도 및 작업 그룹(정책)당 제한 위반에 대한 통계를 제공합니다.

API 호출 통계는 구독 클라이언트의 동작에 대한 훌륭한 인사이트를 제공하고 제한을 유발하는 호출 패턴을 쉽게 식별할 수 있도록 합니다.

당분간 분석기의 제한 사항은 디스크 및 스냅샷 리소스 종류에 대한 요청 수를 계산하지 않는다는 것입니다(관리 디스크 지원). CRP의 원격 분석에서 데이터를 수집하므로 ARM에서 제한 오류를 식별하는 데 도움이 되지 않습니다. 하지만 이러한 항목은 앞에서 설명한 대로 고유한 ARM 응답 헤더에 따라 쉽게 식별할 수 있습니다.

PowerShell cmdlet은 REST 서비스 API를 사용하고 있습니다. 이 API는 클라이언트에서 직접 호출할 수 있습니다(아직 공식적인 지원은 없지만). HTTP 요청 형식을 보려면 -Debug 스위치를 사용하여 cmdlet을 실행하거나 Fiddler를 사용하여 실행을 스눕합니다.

모범 사례

Azure 서비스 API 오류를 무조건 및/또는 즉시 다시 시도하지 마세요. 일반적으로 클라이언트 코드는 다시 시도할 수 없는 오류가 발생할 때 빠른 재시도 루프에 들어가는 것입니다. 재시도는 결국 대상 작업의 그룹에 대해 허용되는 호출 제한을 소진하고 구독의 다른 클라이언트에 영향을 줍니다.
대용량 API 자동화의 경우 대상 작업 그룹에 사용 가능한 호출 수가 낮은 임계값 아래로 떨어질 때 사전 클라이언트 쪽 자체 제한을 구현하는 것이 좋습니다.
비동기 작업을 추적하는 경우 Retry-After 헤더 힌트를 준수합니다.
클라이언트 코드에 특정 Virtual Machine에 대한 정보가 필요한 경우 포함된 리소스 그룹 또는 전체 구독의 모든 VM을 나열한 다음 클라이언트 쪽에서 필요한 VM을 선택하는 대신 해당 VM을 직접 쿼리합니다.
클라이언트 코드에 특정 Azure 위치의 VM, 디스크 및 스냅샷이 필요한 경우 모든 구독 VM을 쿼리한 다음 클라이언트 쪽 GET /subscriptions/<subId>/providers/Microsoft.Compute/locations/<location>/virtualMachines?api-version=2017-03-30 의 위치별로 필터링하는 대신 위치 기반 형식의 쿼리를 사용합니다. 컴퓨팅 리소스 공급자 지역 엔드포인트에 대한 쿼리입니다.
특히 API 리소스, VM 및 가상 머신 확장 집합을 만들거나 업데이트하는 경우 리소스 URL 자체(provisioningState 기반)에서 폴링을 수행하는 것보다 반환된 비동기 작업이 완료될 때까지 추적하는 것이 훨씬 더 효율적입니다.

다음 단계

Azure의 다른 서비스에 대한 재시도 지침에 대한 자세한 내용은 특정 서비스에 대한 재시도 지침을 참조 하세요.

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나 Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.

다음을 통해 공유