Azure Key Vault 제한 지침

아티클
02/29/2024

제한은 리소스의 과용을 방지하기 위해 Azure 서비스에 대한 동시 호출 수를 제한하는 사용자 시작 프로세스입니다. Azure Key Vault(AKV)는 많은 양의 요청을 처리하도록 설계되었습니다. 매우 많은 수의 요청이 발생할 경우 클라이언트의 요청을 제한하면 AKV 서비스의 최적의 성능 및 안정성을 유지하는 데 도움이 됩니다.

제한 한도는 시나리오에 따라 다릅니다. 예를 들어, 대용량 쓰기를 수행하는 경우 읽기만 수행하는 경우보다 제한 가능성이 높습니다.

Key Vault가 한도를 처리하는 방법

Key Vault의 서비스 한도는 리소스의 오용을 방지하고 모든 Key Vault 클라이언트의 서비스 품질을 보장합니다. 서비스 임계값이 초과되면 Key Vault는 해당 클라이언트의 추가 요청을 제한하고 HTTP 상태 코드 429(요청이 너무 많음)를 반환하며 요청이 실패합니다. 429를 반환한 실패한 요청은 Key Vault에서 추적하는 제한 한도에 포함되지 않습니다.

Key Vault는 원래 배포 시 비밀을 저장하고 검색하기 위해 설계되었습니다. 세상은 진화했으며 Key Vault는 런타임에 비밀을 저장하고 검색하는 데 사용되고 있으며, 종종 앱과 서비스는 Key Vault를 데이터베이스처럼 사용하려고 합니다. 현재 한도는 높은 처리량 속도를 지원하지 않습니다.

Key Vault는 원래 Azure Key Vault 서비스 제한에 지정된 한도에 의해 만들어졌습니다. Key Vault 처리량 속도를 최대화하려면 처리량을 최대화하기 위한 몇 가지 권장 지침/모범 사례는 다음과 같습니다.

적절한 대역폭 제한을 사용하는지 확인합니다. 클라이언트가 429에 대한 지수 백오프 정책을 준수하고 아래 지침에 따라 다시 시도를 수행하고 있는지 확인해야 합니다.
Key Vault 트래픽을 여러 자격 증명 모음 및 다른 지역으로 나눕니다. 각 보안/가용성 도메인에 대해 별도의 자격 증명 모음을 사용합니다. 두 지역에 각각 5개의 앱이 있는 경우 앱 및 지역에 고유한 비밀이 포함된 자격 증명 모음 10개를 권장합니다. 모든 트랜잭션 유형에 대한 구독 차원의 한도는 개인 키 자격 증명 모음 한도의 5배입니다. 예를 들어 구독당 HSM-기타 트랜잭션은 구독당 10초 내에 5,000개 트랜잭션으로 제한됩니다. 서비스 또는 앱 내에서 비밀을 캐싱하여 Key Vault에 대한 RPS를 직접 줄이거나 버스트 기반 트래픽을 처리하는 것을 고려합니다. 또한 트래픽을 여러 지역으로 나누어 대기 시간을 최소화하고 다른 구독/자격 증명 모음을 사용할 수 있습니다. 단일 Azure 지역의 Key Vault 서비스에 구독 제한보다 많이 보내지 마세요.
Azure Key Vault에서 검색한 비밀을 메모리에 캐시하고 가능하면 메모리에서 다시 사용합니다. 캐시된 복사본이 작동을 멈춘(예: 원본에서 회전되었기 때문에) 경우에만 Azure Key Vault에서 다시 읽습니다.
Key Vault는 사용자 고유의 서비스 비밀을 위해 설계되었습니다. 고객의 비밀을 저장하는 경우(특히 처리량이 높은 키 저장소 시나리오의 경우) 암호화된 데이터베이스 또는 스토리지 계정에 키를 배치하고 Azure Key Vault에는 기본 키만 저장하는 것이 좋습니다.
Key Vault에 대한 액세스 없이 공개 키 작업을 암호화, 래핑 및 확인하여 제한 위험을 줄일 뿐만 아니라 안정성도 향상시킵니다(공개 키 자료를 적절하게 캐시하는 한).
Key Vault를 사용하여 서비스에 대한 자격 증명을 저장하는 경우 해당 서비스가 Microsoft Entra 인증을 지원하여 직접 인증하는지 확인합니다. 이렇게 하면 Key Vault가 Microsoft Entra 토큰을 사용할 수 있으므로 Key Vault의 부하가 줄어들고 안정성이 향상되며 코드가 간소화됩니다. 많은 서비스가 Microsoft Entra 인증을 사용하도록 이동했습니다. Azure 리소스에 대한 관리 ID를 지원하는 서비스에서 현재 목록을 참조하세요.
현재 RPS 한도를 유지하기 위해 오랜 시간 동안 시차를 두고 로드/배포를 수행하는 것이 좋습니다.
앱이 동일한 비밀을 읽어야 하는 여러 노드로 구성된 경우 한 엔터티가 Key Vault에서 비밀을 읽고 모든 노드로 팬 아웃하는 팬 아웃 패턴을 사용하는 것이 좋습니다. 검색된 비밀은 메모리에만 캐시합니다.

서비스 한도에 대응하여 앱을 제한하는 방법

다음은 서비스가 제한될 때 구현해야 하는 모범 사례입니다.

요청당 작업 수를 줄입니다.
요청의 빈도를 줄입니다.
즉시 재시도를 방지합니다.
- 모든 요청은 사용량 한도에 누적됩니다.

앱의 오류 처리를 구현할 때는 HTTP 오류 코드 429를 사용하여 클라이언트 측 제한이 필요한지 감지하세요. HTTP 429 오류 코드와 함께 요청이 다시 실패하더라도 Azure 서비스 한도에 도달하게 됩니다. 권장되는 클라이언트 측 제한 방법을 계속 사용하여 성공할 때까지 요청을 다시 시도해 보세요.

지수 백오프를 구현하는 코드는 다음과 같습니다.

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# 애플리케이션에서 이 코드를 사용하는 것은 간단합니다.

권장되는 클라이언트 측 제한 방법

HTTP 오류 코드 429가 발생할 경우 지수 백오프 접근법을 사용하여 클라이언트 제한을 시작하세요.

1초를 기다렸다가 요청을 다시 시도합니다.
그래도 제한된 경우 2초를 기다렸다가 요청을 다시 시도합니다.
그래도 제한된 경우 4초를 기다렸다가 요청을 다시 시도합니다.
그래도 제한된 경우 8초를 기다렸다가 요청을 다시 시도합니다.
그래도 제한된 경우 16초를 기다렸다가 요청을 다시 시도합니다.

이때 HTTP 429 응답 코드가 발생해서는 안 됩니다.

참고 항목

Microsoft Cloud의 제한에 대한 더 자세한 소개는 제한 패턴을 참조하세요.

Azure Key Vault 제한 지침

Key Vault가 한도를 처리하는 방법

서비스 한도에 대응하여 앱을 제한하는 방법

권장되는 클라이언트 측 제한 방법

참고 항목

추가 리소스