Procedure consigliate per l'utilizzo AWS Lambda delle funzioni

Di seguito sono indicate le best practice per l'utilizzo di AWS Lambda.

Per ulteriori informazioni sulle best practice per le applicazioni Lambda, consulta Progettazione delle applicazioni in Serverless Land. Puoi anche contattare il team del tuo AWS account e richiedere una revisione dell'architettura.

Codice della funzione

• Separare il gestore Lambda dalla logica principale. In questo modo è possibile creare una funzione di cui è più semplice eseguire l'unit test. In Node.js, l'aspetto è analogo al seguente:

  exports.myHandler = function(event, context, callback) {
  	var foo = event.foo;
  	var bar = event.bar;
  	var result = MyLambdaFunction (foo, bar);
  
  	callback(null, result);
  }
  
  function MyLambdaFunction (foo, bar) {
  	// MyLambdaFunction logic here
  }

• Sfruttare il riutilizzo del contesto di esecuzione per migliorare le prestazioni della funzione. Inizializzare i client SDK e le connessioni al database all'esterno del gestore di funzioni e memorizzare localmente nella cache gli asset statici nella directory /tmp. Le chiamate successive elaborate dalla stessa istanza della funzione possono riutilizzare queste risorse. Ciò consente di risparmiare sui costi riducendo i tempi di esecuzione delle funzioni.

  Per evitare potenziali perdite di dati tra le chiamate, non utilizzare il contesto di esecuzione per archiviare dati utente, eventi o altre informazioni con implicazioni di sicurezza. Se la funzione si basa su uno stato mutabile che non può essere archiviato in memoria all'interno del gestore, considerare la possibilità di creare una funzione separata o versioni separate di una funzione per ogni utente.

• Utilizzare una direttiva keep-alive per mantenere le connessioni persistenti. Lambda elimina le connessioni inattive nel tempo. Se si tenta di riutilizzare una connessione inattiva quando si richiama una funzione, si verificherà un errore di connessione. Per mantenere la connessione persistente, utilizzare la direttiva keep-alive associata al runtime. Per un esempio, vedere Riutilizzo delle connessioni con Keep-Alive in Node.js.

• Utilizzare le variabili di ambiente per passare i parametri operativi alla funzione. Se ad esempio si scrive in un bucket Amazon S3 anziché impostare come hard-coded il nome del bucket in cui si esegue la scrittura, configurare tale nome come una variabile di ambiente.

• Controllare le dipendenze nel pacchetto di distribuzione della funzione. L'ambiente di AWS Lambda esecuzione contiene diverse librerie come l' AWS SDK per i runtime Node.js e Python (un elenco completo è disponibile qui:). Runtime Lambda Per abilitare il set di caratteristiche e aggiornamenti della sicurezza più recenti, Lambda aggiorna periodicamente tali librerie. Tali aggiornamenti possono introdurre lievi modifiche al comportamento della funzione Lambda. Per mantenere il controllo completo delle dipendenze utilizzate dalla funzione, inserire tutte le dipendenze nel pacchetto di implementazione.

• Ridurre al minimo le dimensioni del pacchetto di implementazione al fine di soddisfare le esigenze di runtime. In questo modo viene ridotta la quantità di tempo necessaria per il download del pacchetto e per la relativa decompressione prima dell'invocazione. Per le funzioni create in Java o.NET Core, evita di caricare l'intera libreria AWS SDK come parte del pacchetto di distribuzione. Utilizzare invece in modo selettivo i moduli che prelevano i componenti dell'SDK necessari (ad esempio i moduli SDK Dynamo DB e Amazon S3 e le librerie di base Lambda).

• Ridurre il tempo necessario a Lambda per decomprimere i pacchetti di distribuzione creati in Java inserendo i file .jar della dipendenza in una directory /lib separata. Questo metodo è più rapido rispetto all'inserimento di tutto il codice della funzione in un unico file .jar con un elevato numero di file .class. Per istruzioni, consulta Distribuisci funzioni Lambda per Java con archivi di file .zip o JAR.

• Ridurre la complessità delle dipendenze. Preferire framework più semplici che si caricano velocemente all'avvio del contesto di esecuzione. Preferire ad esempio l'utilizzo di framework di inserimento di dipendenze Java, come Dagger o Guice, rispetto a framework più complessi come Spring Framework.

• Evitare di utilizzare codice ricorsivo nella funzione Lambda in base al quale la funzione chiama automaticamente se stessa finché non vengono soddisfatti determinati criteri arbitrari. Ciò potrebbe provocare un volume non desiderato di invocazioni della funzione e un aumento dei costi. Se questa operazione viene eseguita in modo accidentale, impostare immediatamente il limite di esecuzioni simultanee della funzione sul valore 0 per interrompere tutte le invocazioni alla funzione mentre si aggiorna il codice.

• Non utilizzare API non documentate e non pubbliche nel codice della funzione Lambda. Per i runtime AWS Lambda gestiti, Lambda applica periodicamente aggiornamenti di sicurezza e funzionalità alle API interne di Lambda. Questi aggiornamenti API interni potrebbero essere incompatibili con le versioni precedenti, causando conseguenze indesiderate come errori di chiamata se la funzione ha una dipendenza su queste API non pubbliche. Consulta il riferimento all'API per un elenco di API disponibili pubblicamente.

• Scrivi un codice idempotente. La scrittura di un codice idempotente per le tue funzioni garantisce che gli eventi duplicati vengano gestiti allo stesso modo. Il tuo codice dovrebbe convalidare correttamente gli eventi e gestire con garbo gli eventi duplicati. Per ulteriori informazioni, consulta Come posso rendere idempotente la mia funzione Lambda?.

• Evita di usare la cache DNS Java. Le funzioni Lambda memorizzano già nella cache le risposte DNS. Se utilizzi un'altra cache DNS, potrebbero verificarsi dei timeout di connessione.

  La java.util.logging.Logger classe può abilitare indirettamente la cache DNS JVM. Per sovrascrivere le impostazioni predefinite, imposta networkaddress.cache.ttl su 0 prima dell'inizializzazione. logger Esempio:

  public class MyHandler {
    // first set TTL property
    static{
     java.security.Security.setProperty("networkaddress.cache.ttl" , "0");
    }
   // then instantiate logger
    var logger = org.apache.logging.log4j.LogManager.getLogger(MyHandler.class);
  }

  Per evitare errorinetworkaddress.cache.negative.ttl, consigliamo di impostare su 0. UnknownHostException È possibile impostare questa proprietà per una funzione Lambda con la variabile di AWS_LAMBDA_JAVA_NETWORKADDRESS_CACHE_NEGATIVE_TTL=0 ambiente.

  La disabilitazione della cache DNS JVM non disabilita la cache DNS gestita da Lambda.

Configurazione della funzione

• La verifica delle prestazione della funzione Lambda è una fase fondamentale per garantire la scelta della configurazione delle dimensioni di memoria ottimali. Ogni aumento delle dimensioni di memoria determina un aumento equivalente della CPU disponibile per la funzione. L'utilizzo della memoria per la tua funzione è determinato per ogni richiamo e può essere visualizzato in Amazon. CloudWatch A ogni invocazione, verrà creata una voce REPORT:, come illustrato di seguito:

  REPORT RequestId: 3604209a-e9a3-11e6-939a-754dd98c7be3	Duration: 12.34 ms	Billed Duration: 100 ms Memory Size: 128 MB	Max Memory Used: 18 MB

  Se si analizza il campo Max Memory Used:, è possibile determinare se per la funzione è necessaria una maggiore quantità di memoria o se ne è stata riservata una quantità eccessiva.

  Per trovare la configurazione di memoria giusta per le tue funzioni, ti consigliamo di utilizzare il progetto open source AWS Lambda Power Tuning. Per ulteriori informazioni, consulta AWS Lambda Power Tuning on. GitHub

  Per ottimizzare le prestazioni della funzione, è inoltre consigliabile distribuire librerie in grado di sfruttare Advanced Vector Extensions 2 (AVX2). Ciò consente di elaborare carichi di lavoro complessi, tra cui l'inferenza di machine learning, l'elaborazione di elementi multimediali, l'elaborazione HPC (High Performance Computing), le simulazioni scientifiche e la modellazione finanziaria. Per ulteriori informazioni, vedere Creazione di AWS Lambda funzioni più veloci con AVX2.

• Eseguire il test della funzione Lambda per determinare un valore di timeout ottimale. È importante analizzare il tempo di esecuzione della funzione in modo da individuare meglio gli eventuali problemi con un servizio di dipendenza che possa aumentare la simultaneità della funzione oltre le previsioni. Ciò risulta particolarmente utile quando la funzione effettua chiamate di rete a risorse che non sono in grado di gestire il dimensionamento di Lambda.

• Utilizzare le autorizzazioni più restrittive per le impostazioni delle policy IAM. È importante comprendere le risorse e le operazioni necessarie alla funzione Lambda e limitare il ruolo di esecuzione in base a tali autorizzazioni. Per ulteriori informazioni, consulta Gestione delle autorizzazioni in AWS Lambda.

• Acquisire familiarità con Quote di Lambda. Le dimensioni del payload, i descrittori di file e lo spazio /tmp sono aspetti spesso sottovalutati quando si determinano i limiti delle risorse del tempo di esecuzione.

• Eliminare le funzioni Lambda non più utilizzate. In questo modo le funzioni non utilizzate non vengono conteggiate inutilmente ai fini del calcolo del limite delle dimensioni del pacchetto di distribuzione.

• Se si sta usando Amazon Simple Queue Service come origine eventi, verificare che il valore del tempo di invocazione stimato della funzione non superi il valore Visibility Timeout (Timeout visibilità) della coda. Questo vale sia per che. CreateFunctionUpdateFunctionConfiguration

  • Nel caso di CreateFunction, AWS Lambda fallirà il processo di creazione della funzione.

  • Nel caso di UpdateFunctionConfiguration, potrebbe comportare invocazioni duplicate della funzione.

Scalabilità delle funzioni

• Informati sui vincoli di velocità di trasmissione effettiva a monte e a valle. Sebbene le funzioni Lambda si dimensioni perfettamente in base al carico, le dipendenze a monte e a valle potrebbero non avere le stesse capacità di velocità di trasmissione effettiva. Se devi limitare la scalabilità della tua funzione, puoi configurare la concorrenza riservata sulla tua funzione.

• Integra la tolleranza all'acceleratore. Se la tua funzione sincrona subisce una limitazione a causa del traffico che supera la velocità di scalabilità di Lambda, puoi utilizzare le seguenti strategie per migliorare la tolleranza all'acceleratore:

  • Usa timeout, nuovi tentativi e backoff con jitter. L'implementazione di queste strategie semplifica le chiamate ripetute e aiuta a garantire che Lambda possa scalare in pochi secondi per ridurre al minimo le limitazioni da parte dell'utente finale.

  • Utilizza la concorrenza fornita. La concorrenza fornita è il numero di ambienti di esecuzione preinizializzati che Lambda alloca alla tua funzione. Lambda gestisce le richieste in arrivo utilizzando la concorrenza fornita, se disponibile. Lambda può anche scalare la funzione oltre l'impostazione di concorrenza fornita, se necessario. La configurazione della concorrenza fornita comporta costi aggiuntivi per l'account. AWS

Parametri e allarmi

• Usa Utilizzo dei parametri delle funzioni Lambda and CloudWatch Alarms invece di creare o aggiornare una metrica dal codice della funzione Lambda. In questo modo è molto più efficiente eseguire il controllo dello stato delle funzioni Lambda, perché è possibile rilevare tempestivamente i problemi nel processo di sviluppo. È possibile ad esempio configurare un allarme in base alla durata prevista dell'esecuzione della funzione Lambda per individuare colli di bottiglia o latenze attribuibili al codice della funzione.

• Utilizzare la libreria di registrazione e parametri e dimensioni AWS Lambda per rilevare errori di applicazione (ad esempio, ERR, ERROR, WARNING e così via)

• Utilizza AWS Cost Anomaly Detection per rilevare attività insolite sul tuo account. Cost Anomaly Detection utilizza il machine learning per monitorare continuamente i costi e l'utilizzo riducendo al minimo i falsi positivi. Cost Anomaly Detection utilizza i dati di AWS Cost Explorer, che hanno un ritardo fino a 24 ore. Di conseguenza, possono essere necessarie fino a 24 ore per rilevare un'anomalia dopo l'utilizzo. Per iniziare a utilizzare Cost Anomaly Detection, è necessario registrarsi per Cost Explorer. Quindi, accedi a Cost Anomaly Detection.

Utilizzo di flussi

• Eseguire il test con dimensioni di batch e record diverse in modo che la frequenza di polling di ogni origine eventi sia regolata in base alla velocità con cui la funzione è in grado di completare l'attività. Il CreateEventSourceMapping BatchSize parametro controlla il numero massimo di record che possono essere inviati alla funzione con ogni chiamata. Una dimensione di batch maggiore può spesso assorbire in modo più efficiente il costo associato all'invocazione in un set di record più grande, aumentando in tal modo il throughput.

  Per impostazione predefinita, Lambda richiama la funzione non appena i record sono disponibili. Se il batch che Lambda legge dall'origine eventi contiene un solo record, Lambda invia solo un record alla funzione. Per evitare di richiamare la funzione con pochi record è possibile, configurando un periodo di batch, chiedere all'origine eventi di memorizzare nel buffer i registri per un massimo di 5 minuti. Prima di richiamare la funzione, Lambda continua a leggere i registri dall'origine eventi fino a quando non ha raccolto un batch completo, fino alla scadenza del periodo di batch o fino a quando il batch non ha raggiunto il limite del payload di 6 MB. Per ulteriori informazioni, consulta Comportamento di batching.

  avvertimento

  Le mappature delle sorgenti degli eventi Lambda elaborano ogni evento almeno una volta e può verificarsi un'elaborazione duplicata dei record. Per evitare potenziali problemi legati agli eventi duplicati, ti consigliamo vivamente di rendere idempotente il codice della funzione. Per ulteriori informazioni, consulta Come posso rendere idempotente la mia funzione Lambda nel Knowledge Center. AWS

• Aumentare il throughput di elaborazione del flusso Kinesis tramite l'aggiunta di shard. Un flusso Kinesis è costituito da uno o più shard. Lambda esegue il polling su ogni shard con al massimo un'invocazione simultanea. Se ad esempio il flusso è composto da 100 shard attivi, saranno presenti al massimo 100 invocazioni di funzioni Lambda in esecuzione simultaneamente. L'aumento del numero di shard determina direttamente l'aumento del numero massimo di invocazioni di funzioni Lambda simultanee e può aumentare il throughput di elaborazione del flusso Kinesis. Se si aumenta il numero di shard in un flusso Kinesis, verificare di avere scelto una chiave di partizione opportuna (consultare l'argomento relativo alle chiavi di partizione) per i dati, in modo che i record correlati appartengano agli stessi shard e che i dati siano distribuiti in modo uniforme.

• Usa Amazon CloudWatch on IteratorAge per determinare se il tuo stream Kinesis è in fase di elaborazione. Ad esempio, configura un CloudWatch allarme con un'impostazione massima su 30000 (30 secondi).

Best practice di sicurezza

• Monitora il tuo utilizzo AWS Lambda in relazione alle migliori pratiche di sicurezza utilizzando. AWS Security Hub Security Hub utilizza controlli di sicurezza per valutare le configurazioni delle risorse e gli standard di sicurezza per aiutarti a rispettare vari framework di conformità. Per ulteriori informazioni sull'utilizzo di Security Hub per valutare le risorse Lambda, consulta AWS Lambda i controlli nella Guida per l' AWS Security Hub utente.

• Monitora i log delle attività di rete Lambda utilizzando Amazon GuardDuty Lambda Protection. GuardDuty La protezione Lambda ti aiuta a identificare potenziali minacce alla sicurezza quando le funzioni Lambda vengono richiamate nel tuo. Account AWS Ad esempio, se una delle tue funzioni richiede un indirizzo IP associato ad attività legate alle criptovalute. GuardDuty monitora i registri delle attività di rete generati quando viene richiamata una funzione Lambda. Per ulteriori informazioni, consulta la protezione Lambda nella Amazon GuardDuty User Guide.