Limitazione avanzata delle richieste con Gestione API di Azure

SI APPLICA A: Tutti i livelli di Gestione API

La possibilità di limitare le richieste in ingresso è un ruolo chiave di Gestione API di Azure. Gestione API consente ai provider di API di proteggere le API da abusi e creare valore per diversi livelli di prodotto API controllando la frequenza delle richieste o il totale delle richieste/dati trasferiti. Questo articolo descrive come creare e applicare la limitazione della quota e della velocità.

Limiti e quote di frequenza

Le quote e i limiti di frequenza vengono usate per scopi diversi.

Limiti di velocità

I limiti di velocità vengono in genere usati per proteggersi da picchi di volume brevi e intensi. Ad esempio, se si conosce che il servizio back-end presenta un collo di bottiglia nel database quando i volumi di chiamata sono elevati, è possibile impostare un rate-limit-by-key criterio per impedire volumi di chiamate elevati.

Per i back-end del modello linguistico, è possibile impostare un llm-token-limit criterio per limitare il numero di token elaborati al minuto dal back-end. Questo criterio consente di proteggersi da picchi improvvisi nell'utilizzo dei token che potrebbero comportare un aumento dei costi, un esaurimento delle risorse o una riduzione delle prestazioni.

Livelli classici e v2

Gestione API implementa la limitazione della frequenza in modo diverso a seconda che l'istanza si trova in uno dei livelli di servizio classici o v2:

• I livelli classici usano un algoritmo finestra scorrevole.

• I livelli V2 usano un algoritmo di bucket di token più efficiente e allineato alla limitazione della frequenza in Azure Resource Manager.

Anche se il comportamento complessivo della limitazione della frequenza è simile nei livelli di Gestione API, le differenze nell'implementazione influiscono su alcuni dettagli di utilizzo dei criteri di limitazione della frequenza, ad rate-limit-by-key esempio e llm-token-limit.

Quote

Le quote vengono in genere usate per controllare i tassi di chiamata in un periodo di tempo più lungo. Ad esempio, possono impostare il numero totale di chiamate che un determinato sottoscrittore può effettuare in un mese. Se si monetizza l'API, è anche possibile impostare quote in modo diverso per le sottoscrizioni basate su livelli. Ad esempio, una sottoscrizione di livello Basic potrebbe essere in grado di effettuare non più di 10.000 chiamate al mese, ma un livello Premium potrebbe essere in grado di effettuare 100.000.000 chiamate ogni mese.

In Gestione API i limiti di frequenza vengono in genere propagati più velocemente tra i nodi per proteggersi da picchi. Al contrario, le informazioni sulla quota di utilizzo vengono usate a lungo termine, quindi l'implementazione è diversa.

Limitazione basata sul prodotto

I provider di API possono usare funzionalità di limitazione della frequenza con ambito per una determinata sottoscrizione per applicare limiti agli sviluppatori che hanno effettuato l'iscrizione per usare l'API. Tuttavia, questo tipo di limitazione non è efficace, ad esempio, per limitare l'accesso dei singoli utenti finali all'API. È possibile che un singolo utente dell'applicazione dello sviluppatore usi l'intera quota e impedisca ad altri clienti dello sviluppatore di poter usare l'applicazione. Inoltre, diversi clienti che generano un volume elevato di richieste potrebbero limitare l'accesso a utenti occasionali.

Limitazione basata su chiave personalizzata

I criteri rate-limit-by-key e quota-by-key offrono una soluzione più flessibile per il controllo del traffico. Questi criteri consentono di definire espressioni per identificare le chiavi usate per tenere traccia dell'utilizzo del traffico. Questa tecnica è illustrata negli esempi seguenti.

Limitazione dell'indirizzo IP

I criteri seguenti limitano un singolo indirizzo IP client a sole 10 chiamate ogni minuto e applicano un totale di 1.000.000 chiamate e 10.000 kilobyte di larghezza di banda al mese:

<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)" />

Se tutti i client su Internet utilizzano un indirizzo IP univoco, questo potrebbe essere un modo efficace per limitare l'utilizzo da parte dell'utente. Tuttavia, è probabile che più utenti condividono un singolo indirizzo IP pubblico perché accedono a Internet tramite un dispositivo NAT. Tuttavia, per le API che consentono l'accesso non autenticato, l'uso IpAddress potrebbe essere l'opzione migliore.

Limitazione dell'identità utente

Se un utente finale è autenticato, è possibile generare una chiave di limitazione in base alle informazioni che identificano in modo univoco l'utente:

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

In questo esempio viene illustrato come estrarre l'intestazione Authorization, convertirla in un JWT oggetto e usare l'oggetto del token per identificare l'utente. Usa quindi tale valore come chiave di limitazione della frequenza. Se l'identità utente viene archiviata in JWT come una delle altre attestazioni, è possibile usare tale valore.

Criteri combinati

Sebbene i criteri di limitazione basati sull'utente forniscano un maggiore controllo rispetto ai criteri di limitazione basata su sottoscrizione, esiste comunque un valore nella combinazione di entrambe le funzionalità. Per le API monetizzate, la limitazione in base al codice Product Subscription Key (Limitare la frequenza di chiamata per sottoscrizione e Impostare la quota di utilizzo per sottoscrizione) è un ottimo modo per implementare le tariffe basate sui livelli di utilizzo. Il controllo con granularità maggiore per impostare la limitazione per utente è complementare e impedisce che il comportamento di un utente comprometta l'esperienza di un altro utente.

Limitazione basata su client

Quando la chiave di limitazione viene definita tramite un'espressione di criteri, il provider di API sceglie l'ambito della limitazione. Tuttavia, uno sviluppatore potrebbe voler controllare il modo in cui limita la frequenza delle operazioni dei propri clienti. Il provider di API può abilitare questo tipo di controllo introducendo un'intestazione personalizzata per consentire all'applicazione client dello sviluppatore di comunicare la chiave all'API:

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

Questa tecnica consente all'applicazione client dello sviluppatore di determinare come creare la chiave di limitazione della frequenza. Gli sviluppatori client possono creare i propri livelli di frequenza allocando set di chiavi agli utenti e ruotando l'utilizzo delle chiavi.

Considerazioni per più aree o gateway

I criteri di limitazione della frequenza, ad esempio rate-limit, rate-limit-by-keyazure-openai-token-limit, e llm-token-limit usano i contatori a livello del gateway di Gestione API. Pertanto, nelle distribuzioni in più aree di Gestione API, ogni gateway a livello di area ha un contatore separato e i limiti di frequenza vengono applicati separatamente per ogni area. Analogamente, nelle istanze di Gestione API con aree di lavoro, i limiti vengono applicati separatamente per ogni gateway dell'area di lavoro.

I criteri di quota come quota e quota-by-key sono globali, il che significa che un singolo contatore viene usato a livello dell'istanza di Gestione API.

Riassunto

La gestione delle API fornisce limitazione della velocità e delle quote per proteggere e aggiungere valore al servizio API. I criteri di limitazione con regole di ambito personalizzate forniscono un controllo più dettagliato su tali criteri per consentire ai clienti di creare applicazioni ancora migliori. Gli esempi in questo articolo illustrano l'uso di questi criteri creando chiavi di limitazione della frequenza con indirizzi IP client, identità utente e valori generati dal client. È tuttavia possibile usare molte altre parti del messaggio, ad esempio agente utente, frammenti di percorso URL e dimensioni del messaggio.

Contenuti correlati

• Limiti di frequenza e criteri di quota