Geavanceerde aanvraagbeperking met Azure API Management

Van toepassing op: Alle API Management-lagen

De mogelijkheid om binnenkomende aanvragen te beperken, is een belangrijke rol van Azure API Management. API Management stelt API-providers in staat om hun API's te beschermen tegen misbruik en waarde te creëren voor verschillende API-productlagen door het aantal aanvragen of het totale aantal aanvragen/overgedragen gegevens te beheren. In dit artikel wordt beschreven hoe u quotum- en frequentiebeperking maakt en toepast.

Frequentielimieten en quota

Frequentielimieten en quota worden voor verschillende doeleinden gebruikt.

Limieten voor tarieven

Frequentielimieten worden meestal gebruikt om te beschermen tegen korte en intense volume-bursts. Als u bijvoorbeeld weet dat uw back-endservice een knelpunt heeft in de database wanneer oproepvolumes hoog zijn, kunt u een rate-limit-by-key beleid instellen om grote oproepvolumes niet toe te staan.

Voor back-ends van taalmodellen kunt u een llm-token-limit beleid instellen om het aantal tokens te beperken dat per minuut door uw back-end wordt verwerkt. Dit beleid helpt u te beschermen tegen plotselinge pieken in tokengebruik die kunnen leiden tot hogere kosten, resources uitputten of de prestaties verlagen.

Klassieke versus v2-lagen

API Management implementeert snelheidsbeperking anders, afhankelijk van of uw exemplaar zich in een van de klassieke of v2-servicelagen bevindt:

• Klassieke lagen maken gebruik van een glijdend venster-algoritme.

• V2-lagen maken gebruik van een bucket-algoritme voor tokens dat efficiënter is en overeenkomt met snelheidsbeperking in Azure Resource Manager.

Hoewel het algehele gedrag van snelheidsbeperking vergelijkbaar is in api management-lagen, zijn de verschillen in de implementatie van invloed op bepaalde gebruiksgegevens van beleidsregels voor frequentiebeperking, zoals rate-limit-by-key en llm-token-limit.

Quota

Quota worden meestal gebruikt om gespreksfrequenties gedurende een langere periode te beheren. Ze kunnen bijvoorbeeld het totale aantal oproepen instellen dat een bepaalde abonnee binnen een bepaalde maand kan doen. Als u inkomsten genereert met uw API, kunt u ook quota's anders instellen voor abonnementen op basis van lagen. Een abonnement op de Basic-laag kan bijvoorbeeld niet meer dan 10.000 aanroepen per maand maken, maar een Premium-laag kan mogelijk elke maand 100.000.000 aanroepen doen.

In API Management worden frequentielimieten doorgaans sneller doorgegeven op de knooppunten om te beschermen tegen pieken. Daarentegen wordt gebruiksquotumgegevens op langere termijn gebruikt, zodat de implementatie anders is.

Beperking op basis van producten

API-providers kunnen frequentiebeperkingsmogelijkheden gebruiken die zijn afgestemd op een bepaald abonnement om limieten toe te passen voor de ontwikkelaars die zich hebben geregistreerd om hun API te gebruiken. Deze vorm van beperking helpt echter niet, bijvoorbeeld bij het beperken van individuele eindgebruikers van de API. Het is mogelijk dat één gebruiker van de toepassing van de ontwikkelaar het volledige quotum verbruikt en voorkomt dat andere klanten van de ontwikkelaar de toepassing kunnen gebruiken. Daarnaast kunnen verschillende klanten die een groot aantal aanvragen genereren, de toegang tot incidentele gebruikers beperken.

Aangepaste snelheidsbeperking op basis van sleutels

Het beleid voor frequentielimiet per sleutel en quota per sleutel biedt een flexibelere oplossing voor verkeerscontrole. Met deze beleidsregels kunt u expressies definiëren om de sleutels te identificeren die worden gebruikt om het gebruik van verkeer bij te houden. Deze techniek wordt geïllustreerd in de volgende voorbeelden.

Snelheidsbeperking van IP-adressen

Het volgende beleid beperkt één CLIENT-IP-adres tot slechts 10 aanroepen per minuut en dwing een totaal van 1.000.000 aanroepen en 10.000 kilobytes bandbreedte per maand af:

<rate-limit-by-key  calls="10"
          renewal-period="60"
          counter-key="@(context.Request.IpAddress)" />

<quota-by-key calls="1000000"
          bandwidth="10000"
          renewal-period="2629800"
          counter-key="@(context.Request.IpAddress)" />

Als alle clients op internet een uniek IP-adres hebben gebruikt, kan dit een effectieve manier zijn om het gebruik door de gebruiker te beperken. Het is echter waarschijnlijk dat meerdere gebruikers één openbaar IP-adres delen omdat ze via een NAT-apparaat toegang hebben tot internet. Voor API's die niet-geverifieerde toegang toestaan, is het gebruik IpAddress mogelijk de beste optie.

Beperking van gebruikersidentiteitstoegang

Als een eindgebruiker is geverifieerd, kunt u een beperkingssleutel genereren op basis van informatie die de gebruiker op unieke wijze identificeert:

<rate-limit-by-key calls="10"
    renewal-period="60"
    counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt()?.Subject)" />

In dit voorbeeld ziet u hoe u de autorisatieheader extraheert, converteert naar een JWT object en het onderwerp van het token gebruikt om de gebruiker te identificeren. Vervolgens wordt die waarde gebruikt als de snelheidsbeperkingssleutel. Als de gebruikersidentiteit wordt opgeslagen in de JWT als een van de andere claims, kan die waarde in plaats daarvan worden gebruikt.

Gecombineerd beleid

Hoewel throttlingbeleid op basis van gebruikers meer controle biedt dan throttlingbeleid op basis van een abonnement, is er nog steeds waarde in het combineren van beide benaderingen. Voor api's met inkomsten is beperking per productabonnementssleutel (limiet aantal aanroepen per abonnement en gebruiksquotum instellen per abonnement) een uitstekende manier om kosten te implementeren die zijn gebaseerd op gebruiksniveaus. De nauwkeurigere controle om het beperken per gebruiker is aanvullend en voorkomt dat het gedrag van een gebruiker de ervaring van een andere verslechtert.

Clientgestuurde begrenzing

Wanneer de beperkingssleutel wordt gedefinieerd via een beleidsexpressie, kiest de API-provider hoe de beperking wordt bepaald. Een ontwikkelaar wil echter mogelijk bepalen hoe ze hun eigen klanten beperken. De API-provider kan dit type besturingselement inschakelen door een aangepaste header in te voeren zodat de clienttoepassing van de ontwikkelaar de sleutel kan doorgeven aan de API:

<rate-limit-by-key calls="100"
          renewal-period="60"
          counter-key="@(request.Headers.GetValueOrDefault("Rate-Key",""))"/>

Met deze techniek kan de clienttoepassing van de ontwikkelaar bepalen hoe de snelheidsbeperkingssleutel moet worden gemaakt. De clientontwikkelaars kunnen hun eigen tarieflagen maken door sets sleutels toe te wijzen aan gebruikers en het sleutelgebruik te roteren.

Overwegingen voor meerdere regio's of toegangspunten

Beleid voor snelheidslimiet zoals rate-limit, rate-limit-by-key, azure-openai-token-limit, en llm-token-limit gebruiken tellers op het niveau van de API Management-gateway. Daarom heeft in multi-regionimplementaties van API Management elke regionale gateway een afzonderlijke teller, en worden snelheidslimieten afzonderlijk afgedwongen voor elke regio. Op dezelfde manier worden er in API Management-exemplaren met werkruimten limieten afzonderlijk gehandhaafd voor elke werkruimtegateway.

Quotabeleid zoals quota en quota-by-key zijn globaal, wat betekent dat er één teller wordt gebruikt op het niveau van het API Management-exemplaar.

Samenvatting

API Management biedt frequentie- en quotumbeperking voor het beveiligen en toevoegen van waarde aan uw API-service. Beperkingsbeleid met aangepaste bereikregels bieden nauwkeurige controle over deze beleidsregels om uw klanten in staat te stellen nog betere toepassingen te bouwen. In de voorbeelden in dit artikel wordt het gebruik van dit beleid gedemonstreerd door snelheidsbeperkingssleutels te maken met client-IP-adressen, gebruikersidentiteit en door de client gegenereerde waarden. U kunt echter veel andere onderdelen van het bericht gebruiken, zoals gebruikersagent, URL-padfragmenten en berichtgrootte.

Verwante inhoud

• Frequentielimiet en quotumbeleid