Concorrenza, throttling e concorrenza riservata

Lambda aumenta la scalabilità eseguendo più esecuzioni simultanee della funzione, una per ogni evento simultaneo. Quando arrivano 100 richieste nello stesso momento, Lambda esegue 100 istanze parallele della funzione. AWS gestisce automaticamente l'infrastruttura sottostante. Il limite di concorrenza a livello di account è, per impostazione predefinita, di 1.000 esecuzioni simultanee per Regione (un limite flessibile, aumentabile tramite una richiesta di quota del servizio).

La concorrenza si calcola come segue: Concorrenza = richieste al secondo × durata media in secondi. Se la funzione gestisce 500 richieste al secondo e ciascuna richiede 0,2 secondi, sono necessarie 100 esecuzioni simultanee. Comprendere questa formula La aiuta a prevedere se i limiti dell'account sono sufficienti e se è necessario richiedere aumenti della quota prima di un evento ad alto traffico.

Quando Lambda riceve più richieste di quante ne consenta il limite di concorrenza, applica il throttling a quelle in eccesso. Per le invocazioni sincrone (ad esempio, tramite API Gateway), le richieste sottoposte a throttling ricevono immediatamente un errore 429 TooManyRequestsException, che deve essere gestito dal chiamante. Per le invocazioni asincrone (ad esempio, gli eventi S3), Lambda accoda gli eventi e ritenta per un massimo di 6 ore prima di inviarli a una coda di messaggi non recapitabili.

La Reserved Concurrency garantisce un numero specifico di esecuzioni simultanee per una determinata funzione, riservandole dal pool dell'account. Ha due scopi: (1) garantisce la capacità, perché la funzione avrà sempre quel numero di esecuzioni disponibili anche se altre funzioni stanno consumando la quota dell'account; (2) limita la concorrenza, perché la funzione non potrà mai superare la quantità riservata, proteggendo le dipendenze a valle da un sovraccarico.

Uno scenario d'esame importante: una funzione Lambda scrive in un database RDS che ha un limite di 50 connessioni. Senza controlli sulla concorrenza, Lambda potrebbe aumentare la scalabilità fino a centinaia di esecuzioni simultanee ed esaurire tutte le connessioni al database, causando errori per ogni funzione. Impostando la concorrenza riservata su 40, si garantisce che Lambda non superi mai 40 connessioni simultanee al database, proteggendo l'istanza RDS. Si tratta di un modello fondamentale per qualsiasi funzione Lambda che chiami un servizio con un numero limitato di connessioni.

La Provisioned Concurrency pre-inizializza un numero specificato di ambienti di esecuzione Lambda, che sono così pronti a rispondere immediatamente senza un cold start. È fondamentale per le API sensibili alla latenza, per le quali anche un cold start di 100 ms è inaccettabile. La Provisioned Concurrency comporta un costo orario anche quando gli ambienti sono inattivi; la combini quindi con Auto Scaling per adattare i livelli provisioned in base ai modelli di traffico previsti.

Questi due concetti vengono spesso confusi, ma hanno scopi diversi. La Reserved Concurrency limita e garantisce l'allocazione della capacità dal pool dell'account: NON elimina i cold start. La Provisioned Concurrency mantiene pronti gli ambienti di esecuzione per eliminare i cold start: NON impedisce alle altre funzioni di utilizzare lo stesso pool. Utilizzi la concorrenza riservata per limitare il throughput e la Provisioned Concurrency per migliorare la latenza. È possibile usare entrambe sulla stessa funzione.

Lambda non raggiunge istantaneamente la concorrenza massima. Esiste un limite di burst a livello di account (tasso di scalabilità iniziale) che varia in base alla Regione: in genere 3.000 esecuzioni iniziali in burst, seguite da 500 esecuzioni aggiuntive al minuto fino al raggiungimento del limite. Per le applicazioni che prevedono picchi improvvisi e molto elevati (traffico virale, vendite lampo), utilizzi la Provisioned Concurrency per mantenere già pronti ambienti sufficienti, evitando che il limite di burst causi throttling durante il picco iniziale.

Monitori la concorrenza Lambda con queste metriche chiave di CloudWatch:

• ConcurrentExecutions: numero attuale di istanze in esecuzione
• Throttles: numero di invocazioni sottoposte a throttling (dovrebbe essere zero in un sistema integro)
• UnreservedConcurrentExecutions: pool non riservato a livello di account
• ProvisionedConcurrencyUtilization: quantità di capacità provisioned in uso

Imposti allarmi su Throttles per ricevere una notifica prima che il throttling abbia conseguenze sugli utenti finali.

Quando progetta sistemi che invocano Lambda in modo sincrono (API Gateway, chiamate dirette tramite SDK), implementi nel chiamante il backoff esponenziale con jitter. Gli SDK AWS dispongono di una logica di retry integrata, ma per Lambda eseguito tramite API Gateway deve gestire le risposte 429 nell'applicazione client. Per Lambda attivato da SQS, il servizio SQS gestisce autonomamente i retry; imposti adeguatamente il valore di Maximum Receives nella coda di origine e configuri una DLQ per i retry esauriti.

Per Kinesis Data Streams e DynamoDB Streams, la concorrenza Lambda è limitata dal numero di shard (Kinesis) o di partizioni (DynamoDB). Ogni shard o partizione viene elaborato da una sola esecuzione Lambda simultanea. Se dispone di 10 shard Kinesis, Lambda esegue fino a 10 esecuzioni simultanee per quel trigger. Ciò significa che i problemi di throttling con i trigger basati su stream si risolvono generalmente aumentando il numero di shard, anziché aumentando i limiti di concorrenza.

Verifichi la Sua comprensione dei concetti AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha appreso che la Reserved Concurrency garantisce e limita le esecuzioni simultanee di una funzione, proteggendo i servizi a valle e assicurando la disponibilità; la Provisioned Concurrency pre-inizializza gli ambienti per eliminare i cold start nei carichi di lavoro sensibili alla latenza; infine, il throttling si manifesta come errori 429 nelle invocazioni sincrone e come retry accodati in quelle asincrone, e deve essere monitorato con la metrica CloudWatch Throttles. Nella prossima lezione esamineremo Lambda Layers e i pacchetti di distribuzione per gestire grandi quantità di dipendenze.