API 제한 오류 문제 해결

  • 아티클

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

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

Azure의 정문인 Azure Resource Manager 들어오는 모든 API 요청에 대한 인증 및 우선 유효성 검사 및 제한을 수행합니다. 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 호출 속도 및 제한 오류 분석기

문제 해결 기능의 미리 보기 버전은 컴퓨팅 리소스 공급자의 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 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.