Azure Key Vault 제한 지침Azure Key Vault throttling guidance

제한은 리소스의 과용을 방지하기 위해 Azure 서비스에 대한 동시 호출 수를 제한하는 사용자 시작 프로세스입니다.Throttling is a process you initiate that limits the number of concurrent calls to the Azure service to prevent overuse of resources. Azure Key Vault(AKV)는 많은 양의 요청을 처리하도록 설계되었습니다.Azure Key Vault (AKV) is designed to handle a high volume of requests. 매우 많은 수의 요청이 발생할 경우 클라이언트의 요청을 제한하면 AKV 서비스의 최적의 성능 및 안정성을 유지하는 데 도움이 됩니다.If an overwhelming number of requests occurs, throttling your client's requests helps maintain optimal performance and reliability of the AKV service.

제한 한도는 시나리오에 따라 다릅니다.Throttling limits vary based on the scenario. 예를 들어, 대용량 쓰기를 수행하는 경우 읽기만 수행하는 경우보다 제한 가능성이 높습니다.For example, if you are performing a large volume of writes, the possibility for throttling is higher than if you are only performing reads.

Key Vault가 한도를 처리하는 방법How does Key Vault handle its limits?

Key Vault의 서비스 제한은 리소스의 오용을 방지 하 고 모든 Key Vault 클라이언트에 대해 서비스 품질을 보장 합니다.Service limits in Key Vault prevent misuse of resources and ensure quality of service for all of Key Vault's clients. 서비스 임계값이 초과 되 면 해당 클라이언트에서 일정 기간 동안 추가 요청을 제한 하는 Key Vault HTTP 상태 코드 429 (너무 많은 요청)을 반환 하 고 요청이 실패 합니다.When a service threshold is exceeded, Key Vault limits any further requests from that client for a period of time, returns HTTP status code 429 (Too many requests), and the request fails. Key Vault에서 추적 하는 제한 제한에 429 수를 반환 하는 실패 한 요청입니다.Failed requests that return a 429 count towards the throttle limits tracked by Key Vault.

Key Vault는 원래 배포 시 암호를 저장 하 고 검색 하는 데 사용 하도록 설계 되었습니다.Key Vault was originally designed to be used to store and retrieve your secrets at deployment time. 전 세계에서 진화 하 고 Key Vault는 런타임에 암호를 저장 하 고 검색 하는 데 사용 되 고 있으며, 응용 프로그램 및 서비스에서 데이터베이스와 같은 Key Vault를 사용 하려고 합니다.The world has evolved, and Key Vault is being used at run-time to store and retrieve secrets, and often apps and services want to use Key Vault like a database. 현재 한도는 높은 처리량 속도를 지원 하지 않습니다.Current limits do not support high throughput rates.

Key Vault는 원래 Azure Key Vault 서비스 제한에 지정 된 제한에 의해 만들어졌습니다.Key Vault was originally created with the limits specified in Azure Key Vault service limits. 추가 요금을 통해 Key Vault을 최대화 하려면 처리량을 최대화 하기 위한 몇 가지 권장 지침/모범 사례를 참조 하세요.To maximize your Key Vault through put rates, here are some recommended guidelines/best practices for maximizing your throughput:

  1. 제한이 있는지 확인 합니다.Ensure you have throttling in place. 클라이언트는 429의 지 수 백오프 정책을 준수 하 고 아래 지침에 따라 재시도를 수행 해야 합니다.Client must honor exponential back-off policies for 429's and ensure you are doing retries as per the guidance below.
  2. 여러 자격 증명 모음 및 다른 지역 간에 Key Vault 트래픽을 나눕니다.Divide your Key Vault traffic amongst multiple vaults and different regions. 각 보안/가용성 도메인에 대해 별도의 자격 증명 모음을 사용 합니다.Use a separate vault for each security/availability domain. 각각 두 개의 지역에 5 개의 앱이 있는 경우 각각 앱 및 지역에 고유한 비밀을 포함 하는 10 개의 자격 증명 모음을 권장 합니다.If you have five apps, each in two regions, then we recommend 10 vaults each containing the secrets unique to app and region. 모든 트랜잭션 유형에 대 한 구독 전체 제한은 개별 key vault 제한의 5 배입니다.A subscription-wide limit for all transaction types is five times the individual key vault limit. 예를 들어 구독당 HSM-기타 트랜잭션은 구독당 10초 내에 5,000개 트랜잭션으로 제한됩니다.For example, HSM-other transactions per subscription are limited to 5,000 transactions in 10 seconds per subscription. 서비스 또는 앱 내에서 암호를 캐시 하 여 키 자격 증명 모음에 대 한 RPS를 직접 줄이거나 버스트 기반 트래픽을 처리할 수 있습니다.Consider caching the secret within your service or app to also reduce the RPS directly to key vault and/or handle burst based traffic. 또한 서로 다른 지역 간에 트래픽을 분할 하 여 대기 시간을 최소화 하 고 다른 구독/자격 증명 모음을 사용할 수 있습니다.You can also divide your traffic amongst different regions to minimize latency and use a different subscription/vault. 단일 Azure 지역에서 Key Vault 서비스에 구독 제한을 초과 하 여 전송 하지 마세요.Do not send more than the subscription limit to the Key Vault service in a single Azure region.
  3. Azure Key Vault에서 검색 한 암호를 메모리에 캐시 하 고 가능한 경우 메모리에서 다시 사용 합니다.Cache the secrets you retrieve from Azure Key Vault in memory, and reuse from memory whenever possible. 캐시 된 복사의 작동이 중지 되는 경우에만 Azure Key Vault에서 다시 읽습니다 (예: 소스에서 회전 한 경우).Re-read from Azure Key Vault only when the cached copy stops working (e.g. because it got rotated at the source).
  4. Key Vault는 사용자 고유의 서비스 비밀을 위해 설계 되었습니다.Key Vault is designed for your own services secrets. 고객의 암호를 저장 하는 경우 (특히 처리량이 높은 키 저장소 시나리오의 경우) 암호화 된 데이터베이스 또는 저장소 계정에 키를 배치 하 고 Azure Key Vault에 마스터 키만 저장 하는 것이 좋습니다.If you are storing your customers' secrets (especially for high-throughput key storage scenarios), consider putting the keys in a database or storage account with encryption, and storing just the master key in Azure Key Vault.
  5. Key Vault에 대 한 액세스 없이 공개 키 작업을 암호화 하 고, 래핑하고, 확인 하는 작업을 수행할 수 있습니다 .이 작업은 제한의 위험을 줄일 뿐만 아니라, 안정성도 향상 됩니다 (공개 키 자료를 적절 하 게 캐시 하는 동안).Encrypt, wrap, and verify public-key operations can be performed with no access to Key Vault, which not only reduces risk of throttling, but also improves reliability (as long as you properly cache the public key material).
  6. Key Vault를 사용 하 여 서비스에 대 한 자격 증명을 저장 하는 경우 해당 서비스가 Azure AD 인증를 지원 하는지 확인 하 여 직접 인증 합니다.If you use Key Vault to store credentials for a service, check if that service supports Azure AD Authentication to authenticate directly. 이렇게 하면 Key Vault Azure AD 토큰을 사용할 수 있으므로 Key Vault 부하가 줄어들고 안정성이 향상 되 고 코드가 간소화 됩니다.This reduces the load on Key Vault, improves reliability and simplifies your code since Key Vault can now use the Azure AD token. 많은 서비스가 Azure AD 인증을 사용 하 여로 이동 했습니다. Azure 리소스에 대 한 관리 되는 id를 지 원하는 서비스의 현재 목록을 참조 하세요.Many services have moved to using Azure AD Auth. See the current list at Services that support managed identities for Azure resources.
  7. 현재 RPS 한도를 유지 하기 위해 더 오랜 시간 동안 부하/배포의 시차를 고려 합니다.Consider staggering your load/deployment over a longer period of time to stay under the current RPS limits.
  8. 앱이 동일한 암호를 읽어야 하는 여러 노드로 구성 된 경우 한 엔터티가 Key Vault에서 비밀을 읽고 모든 노드로 팬 아웃 하는 팬 아웃 패턴을 사용 하는 것이 좋습니다.If your app comprises multiple nodes that need to read the same secret(s), then consider using a fan out pattern, where one entity reads the secret from Key Vault, and fans out to all nodes. 검색 된 암호를 메모리에만 캐시 합니다.Cache the retrieved secrets only in memory. 위의 내용이 여전히 사용자의 요구를 충족 하지 않는 것으로 확인 되는 경우 아래 표를 입력 하 고 문의 하 여 추가 용량을 추가할 수 있는 용량을 확인 하세요 (아래 예제는 설명 목적 으로만 사용 가능).If you find that the above still does not meet your needs, please fill out the below table and contact us to determine what additional capacity can be added (example put below for illustrative purposes only).
자격 증명 모음 이름Vault name 자격 증명 모음 지역Vault Region 개체 유형 (비밀, 키 또는 인증서)Object type (Secret, Key, or Cert) 작업 *Operation(s)* 키 유형Key Type 키 길이 또는 곡선Key Length or Curve HSM 키 인가요?HSM key? 안정적인 상태 RPS 필요Steady state RPS needed 최고 RPS 필요Peak RPS needed
https://mykeyvault.vault.azure.net/ Key 로그인Sign ECEC P-256P-256 No 200200 10001000

* 가능한 값의 전체 목록은 Azure Key Vault 작업을 참조 하세요.* For a full list of possible values, see Azure Key Vault operations.

추가 용량이 승인 되 면 용량 향상의 결과로 다음 사항에 유의 하세요.If additional capacity is approved, please note the following as result of the capacity increases:

  1. 데이터 일관성 모델이 변경 됩니다.Data consistency model changes. 추가 처리량 용량으로 자격 증명 모음을 허용 하는 경우에는 Key Vault 서비스 데이터 일관성이 변경 됩니다 (기본 Azure Storage 서비스를 유지할 수 없어 더 높은 볼륨 RPS를 충족 시키는 데 필요).Once a vault is allow listed with additional throughput capacity, the Key Vault service data consistency guarantee changes (necessary to meet higher volume RPS since the underlying Azure Storage service cannot keep up). 간략하게 설명하자면,In a nutshell:
  2. 허용 목록 사용 안 함: Key Vault 서비스에서 쓰기 작업의 결과를 반영 합니다 (예:Without allow listing : The Key Vault service will reflect the results of a write operation (eg. SecretSet, CreateKey)를 후속 호출에서 즉시 호출 합니다 (예:SecretSet, CreateKey) immediately in subsequent calls (eg. SecretGet, KeySign).SecretGet, KeySign).
  3. 허용 목록 사용 : Key Vault 서비스는 쓰기 작업의 결과를 반영 합니다 (예:With allow listing : The Key Vault service will reflect the results of a write operation (eg. SecretSet, CreateKey) 이후의 호출에서 60 초 이내 (예:SecretSet, CreateKey) within 60 seconds in subsequent calls (eg. SecretGet, KeySign).SecretGet, KeySign).
  4. 클라이언트 코드는 429 재시도에 대해 백오프 정책을 준수 해야 합니다.Client code must honor back-off policy for 429 retries. Key Vault 서비스를 호출 하는 클라이언트 코드는 429 응답 코드를 받을 때 Key Vault 요청을 즉시 다시 시도 하면 안 됩니다.The client code calling the Key Vault service must not immediately retry Key Vault requests when it receives a 429 response code. 여기에 게시 된 Azure Key Vault 제한 지침은 429 Http 응답 코드를 받을 때 지 수 백오프를 적용 하는 것을 권장 합니다.The Azure Key Vault throttling guidance published here recommends applying exponential backoff when receiving a 429 Http response code.

더 높은 제한 한도에 대한 유효한 비즈니스 사례가 있을 경우 Microsoft에 연락해 주세요.If you have a valid business case for higher throttle limits, please contact us.

서비스 한도에 대응하여 앱을 제한하는 방법How to throttle your app in response to service limits

다음은 서비스가 제한 될 때 구현 해야 하는 모범 사례 입니다.The following are best practices you should implement when your service is throttled:

  • 요청당 작업 수를 줄입니다.Reduce the number of operations per request.
  • 요청의 빈도를 줄입니다.Reduce the frequency of requests.
  • 즉시 재시도를 방지합니다.Avoid immediate retries.
    • 모든 요청은 사용량 한도에 누적됩니다.All requests accrue against your usage limits.

앱의 오류 처리를 구현할 때는 HTTP 오류 코드 429를 사용하여 클라이언트 측 제한이 필요한지 감지하세요.When you implement your app's error handling, use the HTTP error code 429 to detect the need for client-side throttling. HTTP 429 오류 코드와 함께 요청이 다시 실패하더라도 Azure 서비스 한도에 도달하게 됩니다.If the request fails again with an HTTP 429 error code, you are still encountering an Azure service limit. 권장되는 클라이언트 측 제한 방법을 계속 사용하여 성공할 때까지 요청을 다시 시도해 보세요.Continue to use the recommended client-side throttling method, retrying the request until it succeeds.

지수 백오프를 구현하는 코드는 다음과 같습니다.Code that implements exponential backoff is shown below.

SecretClientOptions options = new SecretClientOptions()
    {
        Retry =
        {
            Delay= TimeSpan.FromSeconds(2),
            MaxDelay = TimeSpan.FromSeconds(16),
            MaxRetries = 5,
            Mode = RetryMode.Exponential
         }
    };
    var client = new SecretClient(new Uri("https://keyVaultName.vault.azure.net"), new DefaultAzureCredential(),options);
                                 
    //Retrieve Secret
    secret = client.GetSecret(secretName);

클라이언트 c # 응용 프로그램에서이 코드를 사용 하는 것은 간단 합니다.Using this code in a client C# application is straightforward.

HTTP 오류 코드 429가 발생할 경우 지수 백오프 접근법을 사용하여 클라이언트 제한을 시작하세요.On HTTP error code 429, begin throttling your client using an exponential backoff approach:

  1. 1초를 기다렸다가 요청을 다시 시도합니다.Wait 1 second, retry request
  2. 그래도 제한된 경우 2초를 기다렸다가 요청을 다시 시도합니다.If still throttled wait 2 seconds, retry request
  3. 그래도 제한된 경우 4초를 기다렸다가 요청을 다시 시도합니다.If still throttled wait 4 seconds, retry request
  4. 그래도 제한된 경우 8초를 기다렸다가 요청을 다시 시도합니다.If still throttled wait 8 seconds, retry request
  5. 그래도 제한된 경우 16초를 기다렸다가 요청을 다시 시도합니다.If still throttled wait 16 seconds, retry request

이때 HTTP 429 응답 코드가 발생해서는 안 됩니다.At this point, you should not be getting HTTP 429 response codes.

참고 항목See also

Microsoft Cloud의 제한에 대한 더 자세한 소개는 제한 패턴을 참조하세요.For a deeper orientation of throttling on the Microsoft Cloud, see Throttling Pattern.