Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
REL05-BP02 Richieste Throttle
Usa le richieste di limitazione (della larghezza di banda della rete) per mitigare l'esaurimento delle risorse dovuto ad aumenti imprevisti della domanda. Le richieste inferiori ai tassi di limitazione vengono elaborate, mentre quelle che superano il limite definito vengono rifiutate con un messaggio di risposta che indica che la richiesta è stata limitata.
Risultato desiderato: i picchi di volume di grandi dimensioni dovuti a improvvisi aumenti del traffico dei clienti, attacchi di flooding o tempeste di ripetizioni dei tentativi sono mitigati dalla limitazione (della larghezza di banda della rete) delle richieste, che consente ai carichi di lavoro di continuare la normale elaborazione del volume di richieste supportato.
Anti-pattern comuni:
-
APIi throttles degli endpoint non vengono implementati o vengono lasciati ai valori predefiniti senza considerare i volumi previsti.
-
APIgli endpoint non sono testati in termini di carico o i limiti di throttling non sono testati.
-
Limitazione (della larghezza di banda della rete) dei tassi di richiesta senza considerare le dimensioni o la complessità delle richieste.
-
Verifica delle percentuali massime di richieste o delle dimensioni massime delle richieste, senza però testarle congiuntamente.
-
Le risorse non vengono allocate entro gli stessi limiti stabiliti durante i test.
-
I piani di utilizzo non sono stati configurati o presi in considerazione per gli utenti da applicazione ad applicazione (A2A). API
-
Gli utenti di code con scalabilità orizzontale non hanno configurato le impostazioni di simultaneità massima.
-
La limitazione della velocità per indirizzo IP non è stata implementata.
Vantaggi dell'adozione di questa best practice: i carichi di lavoro che stabiliscono limiti di accelerazione sono in grado di funzionare normalmente ed elaborare correttamente il caricamento delle richieste accettate in presenza di picchi di volume imprevisti. I picchi improvvisi o prolungati di richieste APIs e code vengono limitati e non esauriscono le risorse di elaborazione delle richieste. I limiti di velocità limitano i singoli richiedenti, in modo che volumi elevati di traffico provenienti da un unico indirizzo IP o utente non esauriscano le risorse, con ripercussioni sugli altri utenti. API
Livello di rischio associato se questa best practice non fosse adottata: elevato
Guida all'implementazione
I servizi devono essere progettati per elaborare una capacità nota di richieste; tale capacità può essere stabilita mediante test di carico. Se le percentuali di arrivo delle richieste superano i limiti, la risposta appropriata segnala che una richiesta ha subito la limitazione (della larghezza di banda della rete). Ciò consente all'utente di gestire l'errore e riprovare in un secondo momento.
Quando il servizio richiede un'implementazione della limitazione (della larghezza di banda della rete), prendi in considerazione l'implementazione dell'algoritmo token bucket, in cui un token conta come una richiesta. I token vengono alimentati a una specifica velocità di limitazione (della larghezza di banda della rete) al secondo e svuotati in modo asincrono in base a un token per richiesta.
Algoritmo token bucket.
Amazon API Gateway
Passaggi dell'implementazione
È possibile configurare API Gateway con limiti di limitazione APIs e restituire 429 Too Many Requests errori quando i limiti vengono superati. Puoi utilizzarlo AWS WAF con i tuoi endpoint AWS AppSync e API Gateway per abilitare la limitazione della velocità in base all'indirizzo IP. Inoltre, laddove il sistema può tollerare l'elaborazione asincrona, è possibile inserire i messaggi in una coda o in un flusso per velocizzare le risposte ai client del servizio, il che consente di aumentare i tassi di limitazione (della larghezza di banda della rete).
Con l'elaborazione asincrona, dopo aver configurato Amazon SQS come fonte di eventi per AWS Lambda, puoi configurare la massima concorrenza per evitare che tassi di eventi elevati consumino la quota di esecuzione simultanea dell'account disponibile necessaria per altri servizi del tuo carico di lavoro o account.
Sebbene API Gateway fornisca un'implementazione gestita del token bucket, nei casi in cui non è possibile utilizzare API Gateway, è possibile sfruttare le implementazioni open source specifiche del linguaggio (vedere gli esempi correlati in Risorse) del token bucket per i propri servizi.
-
Comprendi e configura i limiti di limitazione di API Gateway a livello di account per regione, API per fase e API a livello di piano di utilizzo in base alla chiave.
-
Applica le regole AWS WAF di limitazione della velocità
a API Gateway e agli AWS AppSync endpoint per proteggerti dalle inondazioni e bloccare i malintenzionati. IPs Le regole di limitazione della velocità possono essere configurate anche sulle AWS AppSync API chiavi per i consumatori A2A. -
Valuta se hai bisogno di un maggiore controllo della limitazione della velocità rispetto alla limitazione della velocità e AWS AppSync APIs, in tal caso, configura un API Gateway davanti al tuo endpoint. AWS AppSync
-
Quando le SQS code Amazon sono configurate come trigger per i consumatori di code Lambda, imposta la massima concorrenza su un valore che elabora abbastanza da soddisfare i tuoi obiettivi di livello di servizio ma non consuma limiti di concorrenza che influiscono su altre funzioni Lambda. Valuta la possibilità di impostare la simultaneità riservata su altre funzioni Lambda nello stesso account e nella stessa regione quando utilizzi le code con Lambda.
-
Usa API Gateway con integrazioni di servizi native con Amazon SQS o Kinesis per bufferizzare le richieste.
-
Se non puoi usare API Gateway, consulta le librerie specifiche del linguaggio per implementare l'algoritmo token bucket per il tuo carico di lavoro. Controlla la sezione degli esempi e cerca una libreria adatta.
-
Verifica i limiti che intendi impostare o che prevedi di incrementare e documenta i limiti testati.
-
Non aumentare i limiti oltre i valori stabiliti durante i test. Quando si aumenta un limite, verifica che le risorse allocate siano equivalenti o superiori a quelle degli scenari di test prima di applicare l'aumento.
Risorse
Best practice correlate:
Documenti correlati:
Esempi correlati:
Video correlati:
Strumenti correlati:
