Riktlinjer för begränsning i Azure Key Vault
Begränsning är en process som du initierar som begränsar antalet samtidiga anrop till Azure-tjänsten för att förhindra överanvändning av resurser. Azure Key Vault (AKV) är utformat för att hantera en stor mängd begäranden. Om ett överväldigande antal begäranden inträffar bidrar begränsning av klientens begäranden till att upprätthålla optimala prestanda och tillförlitlighet för AKV-tjänsten.
Begränsningsgränserna varierar beroende på scenariot. Om du till exempel utför en stor mängd skrivningar är risken för begränsning högre än om du bara utför läsningar.
Hur hanterar Key Vault sina gränser?
Tjänstbegränsningar i Key Vault förhindrar missbruk av resurser och säkerställer tjänstkvaliteten för alla Key Vault-klienter. När ett tjänsttröskelvärde överskrids begränsar Key Vault alla ytterligare begäranden från klienten, returnerar HTTP-statuskod 429 (för många begäranden) och begäran misslyckas. Misslyckade begäranden som returnerar en 429 räknas inte mot de begränsningsgränser som spåras av Key Vault.
Key Vault utformades ursprungligen för att lagra och hämta dina hemligheter vid distributionstillfället. Världen har utvecklats och Key Vault används vid körning för att lagra och hämta hemligheter, och ofta vill appar och tjänster använda Key Vault som en databas. Aktuella gränser stöder inte höga dataflödeshastigheter.
Key Vault skapades ursprungligen med de gränser som anges i Azure Key Vault-tjänstens gränser. Här följer några rekommenderade riktlinjer/metodtips för att maximera ditt dataflöde för att maximera ditt dataflöde för att maximera dina dataflöden:
- Kontrollera att du har begränsningar på plats. Klienten måste följa exponentiella back-off-principer för 429-talet och se till att du gör återförsök enligt vägledningen nedan.
- Dela upp din Key Vault-trafik mellan flera valv och olika regioner. Använd ett separat valv för varje säkerhets-/tillgänglighetsdomän. Om du har fem appar, var och en i två regioner, rekommenderar vi 10 valv som var och en innehåller hemligheter som är unika för appen och regionen. En prenumerationsomfattande gräns för alla transaktionstyper är fem gånger den enskilda gränsen för nyckelvalv. Till exempel är HSM-andra transaktioner per prenumeration begränsade till 5 000 transaktioner på 10 sekunder per prenumeration. Överväg att cachelagra hemligheten i din tjänst eller app för att även minska RPS direkt till nyckelvalvet och/eller hantera burst-baserad trafik. Du kan också dela upp trafiken mellan olika regioner för att minimera svarstiden och använda en annan prenumeration/valv. Skicka inte mer än prenumerationsgränsen till Key Vault-tjänsten i en enda Azure-region.
- Cachelagra hemligheterna som du hämtar från Azure Key Vault i minnet och återanvänd från minnet när det är möjligt. Läs endast om från Azure Key Vault när den cachelagrade kopian slutar fungera (t.ex. eftersom den roterades vid källan).
- Key Vault är utformat för dina egna tjänstehemligheter. Om du lagrar dina kunders hemligheter (särskilt för viktiga lagringsscenarier med högt dataflöde) bör du överväga att placera nycklarna i en databas eller ett lagringskonto med kryptering och lagra bara den primära nyckeln i Azure Key Vault.
- Kryptera, omsluta och verifiera offentliga nyckelåtgärder kan utföras utan åtkomst till Key Vault, vilket inte bara minskar risken för begränsning, utan även förbättrar tillförlitligheten (så länge du cachelagrar det offentliga nyckelmaterialet korrekt).
- Om du använder Key Vault för att lagra autentiseringsuppgifter för en tjänst kontrollerar du om tjänsten stöder Microsoft Entra-autentisering för att autentisera direkt. Detta minskar belastningen på Key Vault, förbättrar tillförlitligheten och förenklar koden eftersom Key Vault nu kan använda Microsoft Entra-token. Många tjänster har övergått till att använda Microsoft Entra-autentisering. Se den aktuella listan på Tjänster som stöder hanterade identiteter för Azure-resurser.
- Överväg att svindla din belastning/distribution under en längre tidsperiod för att hålla dig under de aktuella RPS-gränserna.
- Om appen består av flera noder som behöver läsa samma hemlighet kan du överväga att använda ett utsugsmönster, där en entitet läser hemligheten från Key Vault och fläktar ut till alla noder. Cachelagras endast hämtade hemligheter i minnet.
Begränsa din app som svar på tjänstbegränsningar
Följande är metodtips som du bör implementera när tjänsten begränsas:
- Minska antalet åtgärder per begäran.
- Minska frekvensen för begäranden.
- Undvik omedelbara återförsök.
- Alla begäranden ackumuleras mot dina användningsgränser.
När du implementerar appens felhantering använder du HTTP-felkoden 429 för att identifiera behovet av begränsning på klientsidan. Om begäran misslyckas igen med en HTTP 429-felkod stöter du fortfarande på en Azure-tjänstgräns. Fortsätt att använda den rekommenderade begränsningsmetoden på klientsidan och försök igen tills den lyckas.
Här är kod som implementerar exponentiell backoff:
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);
Det är enkelt att använda den här koden i ett C#-klientprogram.
Rekommenderad begränsningsmetod på klientsidan
Vid HTTP-felkod 429 börjar du att begränsa klienten med en exponentiell reduktion:
- Vänta 1 sekund och försök igen
- Om begränsningen kvarstår, vänta i 2 sekunder och försök skicka begäran igen
- Om begränsningen kvarstår, vänta i 4 sekunder och försök skicka begäran igen
- Om begränsningen kvarstår, vänta i 8 sekunder och försök skicka begäran igen
- Om begränsningen kvarstår, vänta i 16 sekunder och försök skicka begäran igen
Nu bör du inte få HTTP 429-svarskoder.
Se även
En djupare orientering om begränsning i Microsoft Cloud finns i Begränsningsmönster.