View a markdown version of this page

Le migliori pratiche per le istanze gestite Lambda - AWS Lambda

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à.

Le migliori pratiche per le istanze gestite Lambda

configurazione del provider di capacità

Separa i provider di capacità in base al livello di affidabilità. Crea diversi provider di capacità per carichi di lavoro con requisiti di sicurezza diversi. Tutte le funzioni di evento Lambda assegnate allo stesso provider di capacità devono essere reciprocamente attendibili, poiché i provider di capacità fungono da limite di sicurezza.

Usa nomi descrittivi. Denominate i fornitori di capacità per indicare chiaramente l'uso previsto e il livello di affidabilità (ad esempioproduction-trusted,dev-sandbox). Questo aiuta i team a comprendere lo scopo e il livello di sicurezza di ciascun fornitore di capacità.

Utilizza più zone di disponibilità. Specificate le sottoreti su più zone di disponibilità durante la creazione di provider di capacità. Lambda lancia tre istanze per impostazione predefinita per la resilienza AZ, garantendo un'elevata disponibilità delle funzioni.

Selezione del tipo di istanza

Consenti a Lambda di scegliere i tipi di istanza. Per impostazione predefinita, Lambda sceglie i tipi di istanza migliori per il tuo carico di lavoro. Ti consigliamo di lasciare che le istanze gestite da Lambda scelgano i tipi di istanza per te, poiché limitare il numero di tipi di istanze possibili potrebbe comportare una minore disponibilità.

Specificate i tipi di istanza per requisiti specifici. Se hai requisiti hardware specifici, imposta i tipi di istanze consentiti su un elenco di istanze compatibili. Ad esempio:

  • Per le applicazioni che richiedono un'elevata larghezza di banda di rete, seleziona diversi tipi di istanze n

  • Per ambienti di test o sviluppo con vincoli di costo, scegli tipi di istanze più piccoli come m7a.large

Configurazione delle funzioni

Scegli le impostazioni di memoria e vCPU appropriate. Seleziona configurazioni di memoria e vCPU che supportano l'esecuzione simultanea della tua funzione. La dimensione minima della funzione supportata è 2 GB e 1 vCPU.

  • Per le applicazioni Python, scegli un rapporto più elevato tra memoria e vCPU (ad esempio 4 a 1 o 8 a 1) a causa del modo in cui Python gestisce la multi-concorrenza

  • Per CPU-intensive operazioni o funzioni che eseguono poco I/O, scegli più di una vCPU

  • Per IO-heavy applicazioni come servizi Web o processi in batch, la multi-concorrenza offre i maggiori vantaggi

Configura la massima concorrenza in modo appropriato. Lambda sceglie impostazioni predefinite ragionevoli per la massima concorrenza che bilanciano il consumo di risorse e la velocità effettiva. Modifica questa impostazione in base all'utilizzo delle risorse della tua funzione:

  • Aumenta la concorrenza massima (fino a 64 per vCPU) se le chiamate alle funzioni utilizzano pochissima CPU

  • Riduci la concorrenza massima se l'applicazione consuma una grande quantità di memoria e pochissima CPU

Tieni presente che gli ambienti di esecuzione con una concorrenza molto bassa potrebbero presentare rallentamenti e difficoltà di scalabilità.

Long-running funzioni

Le funzioni sulle istanze AWS Lambda gestite possono essere eseguite fino a 90 minuti (5.400 secondi) per chiamata per chiamate asincrone e per chiamate di mappatura delle sorgenti di eventi, ad eccezione delle mappature delle sorgenti di eventi Amazon MQ e Amazon DocumentDB, che rimangono limitate a 15 minuti. Anche le chiamate sincrone e la fase di inizializzazione della funzione rimangono limitate a 15 minuti. Per ulteriori informazioni sull'impostazione del timeout, consulta Configurare il timeout della funzione Lambda. Poiché la funzione può funzionare più a lungo, consulta le seguenti considerazioni per i componenti di natura effimera, come le connessioni di rete e le credenziali.

Adatta i timeout di connessione inattivi. Assicurati che i timeout di connessione inattivi su servizi downstream come Amazon RDS ElastiCache, Amazon e API esterne soddisfino l'intera durata della funzione. Se la tua funzione indirizza il traffico attraverso un gateway NAT, invia pacchetti keep-alive per evitare che le connessioni inattive vengano interrotte dopo il timeout di 350 secondi di inattività del gateway NAT.

Rispetta i valori DNS TTL. Rispetta i valori DNS TTL quando risolvi i nomi host esterni. Gli AWS SDK lo gestiscono automaticamente, ma i client HTTP personalizzati potrebbero memorizzare nella cache le risoluzioni DNS oltre il rispettivo TTL.

Aggiorna le credenziali temporanee. Se la tua funzione acquisisce credenziali o token temporanei, verifica che rimangano validi per l'intera durata dell'esecuzione o aggiornali in background.

Design per l'idempotenza. Lambda non garantisce l'elaborazione una sola volta. Man mano che le funzioni durano più a lungo, aumenta la finestra per nuovi tentativi e consegne duplicate. Usa Powertools for AWS Lambda per implementare l'idempotenza per operazioni come pagamenti o scritture di database, in modo che producano lo stesso risultato anche se eseguite più di una volta. Se utilizzi le funzioni durevoli Lambda, i passaggi hanno una semantica di esecuzione almeno una volta: l'SDK di esecuzione durevole salta i passaggi completati durante la riproduzione, ma i passaggi che falliscono prima del checkpoint possono essere eseguiti nuovamente. È possibile utilizzare i nomi di esecuzione come chiavi di idempotenza.

Ottimizza le mappature delle sorgenti degli eventi per un'elaborazione più lunga. Per Amazon SQS, imposta il timeout di visibilità della coda su almeno sei volte il timeout della funzione, in modo che Lambda abbia abbastanza tempo per riprovare un batch se la funzione è limitata. Lambda lo convalida quando crei la mappatura dell'origine dell'evento, ma non impedisce modifiche successive alla coda o alla funzione che creano una mancata corrispondenza. Per Amazon Kinesis Data Streams e Amazon DynamoDB Streams, configura la finestra di batch e il fattore di parallelizzazione massimi per tenere conto di tempi di elaborazione più lunghi per batch e abilita la segnalazione parziale degli errori dei batch in modo che vengano ritentati solo i record non riusciti anziché l'intero batch.

Scaling configuration (Configurazione dimensionamento)

Imposta l'utilizzo appropriato delle risorse target. Per impostazione predefinita, Lambda offre un margine di manovra sufficiente per raddoppiare il traffico entro 5 minuti senza acceleratori. Modifica questa impostazione in base alle caratteristiche del carico di lavoro:

  • Per carichi di lavoro molto stabili o applicazioni non sensibili alle limitazioni di velocità, stabilisci l'obiettivo su un livello elevato per ottenere un maggiore utilizzo e ridurre i costi

  • Per i carichi di lavoro con potenziali aumenti di traffico, stabilisci obiettivi di risorse a un livello basso per mantenere un margine di crescita aggiuntivo

Pianifica la crescita del traffico. Se il traffico raddoppia più che nel giro di 5 minuti, potresti riscontrare rallentamenti man mano che Lambda aumenta la scalabilità delle istanze e degli ambienti di esecuzione. Progetta la tua applicazione per gestire le potenziali limitazioni durante i periodi di rapida scalabilità.

Sicurezza

Applica il privilegio minimo per le autorizzazioni. PassCapacityProvider Concedi lambda:PassCapacityProvider le autorizzazioni solo ai fornitori di capacità necessari. Utilizza le autorizzazioni a livello di risorsa per limitare i fornitori di capacità che gli utenti possono assegnare alle funzioni.

Monitora l'utilizzo dei provider di capacità. Utilizzato AWS CloudTrail per monitorare le assegnazioni dei provider di capacità e i modelli di accesso. Questo aiuta a identificare i tentativi di accesso non autorizzati e garantisce la conformità alle politiche di sicurezza.

Separa i carichi di lavoro non affidabili. Non fare affidamento sui contenitori per l'isolamento di sicurezza tra carichi di lavoro non affidabili. Utilizza diversi provider di capacità per separare i carichi di lavoro che non sono reciprocamente affidabili.

Ottimizzazione dei costi

Utilizza le opzioni di prezzo di EC2. Sfrutta i vantaggi di EC2 Savings Plans e Reserved Instances per ridurre i costi. Queste opzioni di prezzo si applicano al calcolo EC2 sottostante (la commissione di gestione del 15% non è scontata).

Ottimizza per carichi di lavoro stazionari. Le istanze gestite Lambda sono più adatte per funzioni stazionarie con traffico prevedibile ad alto volume. Per modelli di traffico a raffica, Lambda (impostazione predefinita) potrebbe essere più conveniente.

Monitora l'utilizzo delle risorse. Tieni traccia delle CloudWatch metriche per comprendere l'utilizzo della CPU e della memoria. Modifica l'allocazione della memoria delle funzioni e la selezione del tipo di istanza in base ai modelli di utilizzo effettivi per ottimizzare i costi.

Monitoraggio e osservabilità

Monitora le metriche dei fornitori di capacità. Tieni traccia delle metriche a livello di capacity provider, tra cui l'utilizzo della CPU e MemoryUtilization vCPUAvailable e verifica che siano disponibili risorse sufficienti MemoryAvailable per i tuoi carichi di lavoro.

Monitora le metriche dell'ambiente di esecuzione. Tieni traccia delle metriche a livello di ambiente di esecuzione, tra cui ExecutionEnvironmentConcurrency e ExecutionEnvironmentConcurrencyLimit per comprendere il comportamento di scalabilità e identificare potenziali limitazioni.

Imposta allarmi. CloudWatch Crea CloudWatch allarmi per le metriche chiave per identificare in modo proattivo i problemi:

  • Utilizzo elevato della CPU o della memoria

  • Bassa capacità disponibile

  • Ci avviciniamo ai limiti di concorrenza

Language-specific considerazioni

Segui le best practice specifiche per ogni lingua. Ogni linguaggio di programmazione gestisce la concorrenza multipla in modo diverso. Consulta le guide specifiche per ogni lingua per consigli dettagliati:

  • Java: utilizza raccolte thread-safe e per lo stato specifico della richiesta AtomicInteger ThreadLocal

  • Node.js: Utilizzalo InvokeStore per tutti gli stati specifici della richiesta ed evita le variabili globali

  • Python: usa nomi di file univoci /tmp con gli ID di richiesta e considera l'isolamento della memoria basato sul processo

  • Rust: usa run_concurrent invece dirun, con la concurrency-tokio funzionalità abilitata. Il gestore deve essere Clone +Send.

Verifica la sicurezza dei thread e i problemi di concorrenza. Prima di passare alla produzione, testate accuratamente le vostre funzioni per verificare eventuali problemi di sicurezza dei thread, le condizioni di gara e il corretto isolamento dello stato in presenza di carichi simultanei.

Fasi successive