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à.
Runtime Python per istanze gestite Lambda
Il runtime Lambda utilizza più processi Python per gestire richieste simultanee. Ogni richiesta simultanea viene eseguita in un processo separato con il proprio spazio di memoria e inizializzazione. Ogni processo gestisce una richiesta alla volta, in modo sincrono. I processi non condividono direttamente la memoria, quindi le variabili globali, le cache a livello di modulo e gli oggetti singleton sono isolati tra le richieste simultanee.
Configurazione della concorrenza
Il numero massimo di richieste simultanee che Lambda invia a ciascun ambiente di esecuzione è controllato dall'PerExecutionEnvironmentMaxConcurrencyimpostazione nella configurazione della funzione. Questa è un'impostazione opzionale e il valore predefinito varia a seconda del runtime. Per i runtime di Python, l'impostazione predefinita è 16 richieste simultanee per vCPU, oppure è possibile configurare un valore personalizzato. Questo valore determina anche il numero di processi utilizzati dal runtime Python. Lambda regola automaticamente il numero di richieste simultanee fino al valore massimo configurato in base alla capacità di ciascun ambiente di esecuzione di assorbire tali richieste.
Importante
L'uso della concorrenza basata sui processi significa che ogni processo di runtime worker esegue la propria inizializzazione. L'utilizzo totale della memoria è uguale alla memoria per processo moltiplicata per il numero di processi concorrenti. Se si caricano librerie o set di dati di grandi dimensioni e la concorrenza è elevata, si dispone di un ingombro di memoria elevato. In base al carico di lavoro, potrebbe essere necessario regolare il CPU-to-memory rapporto o utilizzare un'impostazione di concorrenza inferiore per evitare di superare la memoria disponibile. Puoi utilizzare la MemoryUtilization metrica in per tenere traccia del consumo CloudWatch di memoria.
Creazione di funzioni per la concorrenza multipla
Grazie al modello multi-concorrenza basato sui processi, le funzioni di Lambda Managed Instances che utilizzano i runtime Python non accedono contemporaneamente alle risorse in memoria da più richiami. Non è necessario applicare pratiche di codifica per la sicurezza della concorrenza in memoria.
Directory /tmp condivisa
La /tmp directory è condivisa tra tutte le richieste simultanee nell'ambiente di esecuzione. Le scritture simultanee sullo stesso file possono causare il danneggiamento dei dati, ad esempio se un altro processo sovrascrive il file. Per risolvere questo problema, implementa il blocco dei file condivisi o utilizza nomi di file univoci per processo o per richiesta per evitare conflitti. Ricordati di pulire i file non necessari per evitare di esaurire lo spazio disponibile.
Registrazione dei log
L'interlacciamento dei log (voci di log provenienti da richieste diverse che vengono interlacciate nei log) è normale nei sistemi con più concorrenti.
Le funzioni che utilizzano Lambda Managed Instances utilizzano sempre il formato di registro JSON strutturato introdotto con controlli di registrazione avanzati. Configurazione dei controlli di registrazione avanzati per le funzioni Lambda Questo formato include ilrequestId, che consente di correlare le voci di registro a una singola richiesta. Quando si utilizza il logging modulo della libreria standard Python in Lambda, requestId viene automaticamente incluso in ogni voce di registro. Per ulteriori informazioni, consulta Utilizzo dei controlli di registrazione avanzati Lambda con Python.
Contesto della richiesta
context.aws_request_idDa utilizzare per accedere all'ID della richiesta corrente.
Con Python runtimes, puoi utilizzare la variabile di _X_AMZN_TRACE_ID ambiente per accedere all'ID di X-Ray traccia con Lambda Managed Instances. L'ID di X-Ray traccia viene propagato automaticamente quando si utilizza l'SDK. AWS
Utilizzato context.get_remaining_time_in_millis() per rilevare i timeout. Per ulteriori informazioni, consulta Gestione e ripristino degli errori.
Esempio: gestione dei timeout
Controlla il tempo rimanente prima di ogni unità di lavoro e interrompi l'elaborazione prima che scada il timeout. Configura in BUFFER_MS base alla durata prevista della prossima parte di lavoro.
BUFFER_MS = 2000 # Configure based on your next chunk of work def handler(event, context): for item in event["items"]: if context.get_remaining_time_in_millis() < BUFFER_MS: return {"statusCode": 206, "body": "Timeout approaching, stopping early"} process_item(item) return {"statusCode": 200, "body": "Done"}
Esempio: propagazione delle scadenze alle chiamate a valle
Quando effettui chiamate ai servizi downstream, propaga il tempo rimanente sotto forma di timeout per evitare il blocco delle chiamate di rete che potrebbero durare più a lungo della chiamata. L'SDK boto3 non supporta i timeout per richiesta su un client esistente, quindi è necessario creare un client con il timeout desiderato. Per le funzioni ad alto rendimento, valuta se un timeout fisso configurato al momento dell'inizializzazione è più appropriato rispetto alla creazione del client per richiesta.
import boto3 from botocore.config import Config def handler(event, context): remaining = context.get_remaining_time_in_millis() / 1000 timeout = max(1, remaining - 0.5) s3 = boto3.client("s3", config=Config(read_timeout=timeout, connect_timeout=timeout)) response = s3.get_object(Bucket="my-bucket", Key="my-key") return {"statusCode": 200, "body": "Done"}
Inizializzazione e arresto
L'inizializzazione della funzione avviene una volta per processo. È possibile che vengano visualizzate voci di registro ripetute se la funzione emette registri durante l'inizializzazione.
Per le funzioni Lambda con estensioni, l'ambiente di esecuzione emette un segnale SIGTERM durante l'arresto. Questo segnale viene utilizzato dalle estensioni per attivare attività di pulizia, come lo svuotamento dei buffer. È possibile iscriversi agli eventi SIGTERM per attivare attività di pulizia delle funzioni, come la chiusura delle connessioni al database. Per ulteriori informazioni sul ciclo di vita dell'ambiente di esecuzione, consulta Comprendere il ciclo di vita dell’ambiente di esecuzione Lambda.
Versioni di dipendenza
Lambda Managed Instances richiede le seguenti versioni minime del pacchetto:
-
Powertools for AWS Lambda (Python): versione 3.23.0 o successiva
Powertools per AWS Lambda (Python)
Powertools for AWS Lambda (Python) è compatibile con Lambda Managed Instances e fornisce utilità per la registrazione, la traccia, le metriche e altro ancora. Per ulteriori informazioni, consulta Powertools for Lambda (Python). AWS
Fasi successive
-
Esamina il runtime Java per le istanze gestite Lambda
-
Esamina il Node.js runtime per Lambda Managed Instances
-
Esamina il runtime .NET per le istanze gestite Lambda
-
Scopri come scalare le istanze gestite Lambda