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 di esecuzione delle istanze gestite Lambda
Lambda elabora le richieste in modo diverso quando utilizza istanze gestite Lambda. Invece di gestire le richieste in sequenza in ogni ambiente di esecuzione, le istanze gestite Lambda elaborano più richieste contemporaneamente all'interno di ciascun ambiente di esecuzione. Questa modifica nel modello di esecuzione significa che le funzioni che utilizzano le istanze gestite Lambda devono considerare la sicurezza dei thread, la gestione dello stato e l'isolamento del contesto, problemi che non sorgono nel modello a concorrenza singola Lambda (predefinito). Inoltre, l'implementazione multi-concorrenza varia da un runtime all'altro.
## Lingue supportate
Le istanze gestite Lambda possono essere utilizzate con i seguenti linguaggi di programmazione e runtime:
+ **Java: Java** 21 e versioni successive.
+ **Python: Python 3.13** e versioni successive.
+ **Node.js:** Node.js 22 e versioni successive.
+ **.NET:** .NET 8 e versioni successive.
+ **Rust:** supportato utilizzando il runtime solo per il sistema operativo `provided.al2023` e versioni successive.
## Considerazioni specifiche sulla lingua
Ogni linguaggio di programmazione implementa la multiconcorrenza in modo diverso. È necessario comprendere come viene implementata la concorrenza multipla nel linguaggio di programmazione prescelto per applicare le migliori pratiche di concorrenza appropriate.
**Java**
Utilizza un unico processo con thread del sistema operativo per la concorrenza. Più thread eseguono il metodo handler contemporaneamente, richiedendo una gestione thread-safe delle risorse statali e condivise.
**Python**
Utilizza più processi Python in cui ogni richiesta simultanea viene eseguita in un processo separato. Ciò protegge dalla maggior parte dei problemi di concorrenza, sebbene sia necessaria attenzione per le risorse condivise come la directory. `/tmp`
**Node.js**
Utilizza [thread di lavoro con esecuzione](https://nodejs.org/api/worker_threads.html) asincrona. Le richieste concorrenti sono distribuite tra i thread di lavoro e ogni thread di lavoro può anche gestire le richieste simultanee in modo asincrono, il che richiede una gestione sicura delle risorse statali e condivise.
**.NET**
Utilizza .NET Tasks con l'elaborazione asincrona di più richieste simultanee. Richiede una gestione sicura delle risorse statali e condivise.
**Rust**
[Utilizza un unico processo con attività asincrone basate su Tokio.](https://tokio.rs/) Il gestore deve essere \$1. `Clone` `Send`
## Fasi successive
Per informazioni dettagliate su ogni runtime, consultate i seguenti argomenti:
+ [Runtime Java per istanze gestite Lambda](lambda-managed-instances-java-runtime.md)
+ [Runtime Node.js per istanze gestite Lambda](lambda-managed-instances-nodejs-runtime.md)
+ [Runtime Python per istanze gestite Lambda](lambda-managed-instances-python-runtime.md)
+ [.NET runtime per istanze gestite Lambda](lambda-managed-instances-dotnet-runtime.md)
+ [Supporto Rust per istanze gestite Lambda](lambda-managed-instances-rust.md)
# Runtime Java per istanze gestite Lambda
Per i runtime Java, le istanze gestite Lambda utilizzano i thread del sistema operativo per la concorrenza. Lambda carica l'oggetto gestore una volta per ambiente di esecuzione durante l'inizializzazione e quindi crea più thread. Questi thread vengono eseguiti in parallelo e richiedono una gestione thread-safe delle risorse statali e condivise. Ogni thread condivide lo stesso oggetto gestore e tutti i campi statici.
## Configurazione della concorrenza
Il numero massimo di richieste simultanee che Lambda invia a ciascun ambiente di esecuzione è controllato dall'impostazione nella configurazione `PerExecutionEnvironmentMaxConcurrency` della funzione. Questa è un'impostazione opzionale e il valore predefinito varia a seconda del runtime. Per i runtime Java, l'impostazione predefinita è 32 richieste simultanee per vCPU, oppure è possibile configurare un valore personalizzato. Questo valore determina anche il numero di thread utilizzati dal runtime Java. Lambda regola automaticamente il numero di richieste simultanee fino al massimo configurato in base alla capacità di ciascun ambiente di esecuzione di assorbire tali richieste.
## Creazione di funzioni per la multiconcorrenza
È necessario applicare le stesse pratiche di sicurezza dei thread quando si utilizzano le istanze gestite Lambda come si farebbe in qualsiasi altro ambiente multithread. Poiché l'oggetto handler è condiviso tra tutti i thread di runtime worker, qualsiasi stato mutabile deve essere thread-safe. Ciò include raccolte, connessioni al database e qualsiasi oggetto statico modificato durante l'elaborazione della richiesta.
AWS I client SDK sono thread-safe e non richiedono una gestione speciale.
**Esempio: pool di connessioni al database**
Il codice seguente utilizza un oggetto di connessione al database statico condiviso tra i thread. A seconda della libreria di connessioni utilizzata, questa potrebbe non essere thread-safe.
```
public class DBQueryHandler implements RequestHandler {
// Single connection shared across all threads - NOT SAFE
private static Connection connection;
public DBQueryHandler() {
this.connection = DriverManager.getConnection(jdbcUrl, username, password);
}
@Override
public String handleRequest(Object input, Context context) {
PreparedStatement stmt = connection.prepareStatement(query);
ResultSet rs = stmt.executeQuery();
// Multiple threads using same connection causes issues
return result.toString();
}
}
```
Un approccio thread-safe consiste nell'utilizzare un pool di connessioni. Nell'esempio seguente, il gestore di funzioni recupera una connessione dal pool. La connessione viene utilizzata solo nel contesto di una singola richiesta.
```
public class DBQueryHandler implements RequestHandler {
private static HikariDataSource dataSource;
public DBQueryHandler() {
HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://localhost:3306/your_database");
dataSource = new HikariDataSource(config); // Create pool once per Lambda container
}
@Override
public String handleRequest(Object input, Context context) {
String query = "SELECT column_name FROM your_table LIMIT 10";
StringBuilder result = new StringBuilder("Data:\n");
// try-with-resources automatically calls close() on the connection,
// which returns it to the HikariCP pool (does NOT close the physical DB connection)
try (Connection connection = dataSource.getConnection();
PreparedStatement stmt = connection.prepareStatement(query);
ResultSet rs = stmt.executeQuery()) {
while (rs.next()) {
result.append(rs.getString("column_name")).append("\n");
}
} catch (Exception e) {
context.getLogger().log("Error: " + e.getMessage());
return "Error";
}
return result.toString();
}
}
```
**Esempio: collezioni**
Le raccolte Java standard non sono thread-safe:
```
public class Handler implements RequestHandler {
private static List items = new ArrayList<>();
private static Map cache = new HashMap<>();
@Override
public String handleRequest(Object input, Context context) {
items.add("list item"); // Not thread-safe
cache.put("key", input); // Not thread-safe
return "Success";
}
}
```
Utilizza invece raccolte thread-safe:
```
public class Handler implements RequestHandler {
private static final List items =
Collections.synchronizedList(new ArrayList<>());
private static final ConcurrentHashMap cache =
new ConcurrentHashMap<>();
@Override
public String handleRequest(Object input, Context context) {
items.add("list item"); // Thread-safe
cache.put("key", input); // Thread-safe
return "Success";
}
}
```
## 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, implementate il blocco dei file per i file condivisi o utilizzate nomi di file univoci per thread o per richiesta per evitare conflitti. Ricordati di ripulire i file non necessari per evitare di esaurire lo spazio disponibile.
## Registrazione dei log
L'interlacciamento dei log (le voci di registro di diverse richieste vengono interlacciate nei log) è normale nei sistemi multi-concorrenti.
[Le funzioni che utilizzano Lambda Managed Instances utilizzano sempre il formato di registro JSON strutturato introdotto con controlli di registrazione avanzati.](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) Questo formato include`requestId`, che consente di correlare le voci di registro a una singola richiesta. Quando si utilizza l'`LambdaLogger`oggetto, `requestId` viene incluso automaticamente in ogni voce di registro. `context.getLogger()` Per ulteriori informazioni, vedere[Utilizzo dei controlli di registrazione avanzati di Lambda con Java](java-logging.md#java-logging-advanced).
## Contesto della richiesta
L'`context`oggetto è associato al thread di richiesta. Using `context.getAwsRequestId()` fornisce un accesso thread-safe all'ID della richiesta corrente.
Utilizzare `context.getXrayTraceId()` per accedere all'ID di traccia X-Ray. Ciò fornisce un accesso thread-safe all'ID di traccia per la richiesta corrente. Lambda non supporta la variabile di `_X_AMZN_TRACE_ID` ambiente con Lambda Managed Instances. L'ID di traccia X-Ray viene propagato automaticamente quando si utilizza l'SDK. AWS
Utilizzato per rilevare i `com.amazonaws.services.lambda.runtime.Context.getRemainingTimeInMillis()` timeout. Per ulteriori informazioni, consulta [Gestione e ripristino degli errori](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
Se utilizzi thread virtuali nel tuo programma o crei thread durante l'inizializzazione, dovrai passare qualsiasi contesto di richiesta richiesto a questi thread.
## Inizializzazione e spegnimento
L'inizializzazione della funzione avviene una volta per ambiente di esecuzione. Gli oggetti creati durante l'inizializzazione vengono condivisi tra i thread.
Per le funzioni Lambda con estensioni, l'ambiente di esecuzione emette un segnale SIGTERM durante lo spegnimento. Questo segnale viene utilizzato dalle estensioni per attivare attività di pulizia, come lo svuotamento dei buffer. È possibile sottoscrivere 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](lambda-runtime-environment.md).
## Versioni di dipendenza
Lambda Managed Instances richiede le seguenti versioni minime del pacchetto:
+ AWS SDK for Java 2.0: versione 2.34.0 o successiva
+ AWS X-Ray SDK per Java: versione 2.20.0 o successiva
+ AWS Distro for OpenTelemetry - Instrumentation for Java: versione 2.20.0 o successiva
+ Powertools for AWS Lambda (Java): versione 2.8.0 o successiva
## Utensili elettrici per AWS Lambda (Java)
Powertools for AWS Lambda (Java) è compatibile con Lambda Managed Instances e fornisce utilità per la registrazione, il tracciamento, le metriche e altro ancora. Per ulteriori informazioni, vedere [Powertools for AWS Lambda (](https://github.com/aws-powertools/powertools-lambda-java)Java).
## Fasi successive
+ Esamina il [runtime di Node.js per le istanze gestite Lambda](lambda-managed-instances-nodejs-runtime.md)
+ [Esamina il runtime Python per le istanze gestite Lambda](lambda-managed-instances-python-runtime.md)
+ Esamina il [runtime di.NET per le istanze gestite da Lambda](lambda-managed-instances-dotnet-runtime.md)
+ Scopri come [scalare le istanze gestite Lambda](lambda-managed-instances-scaling.md)
# Runtime Node.js per istanze gestite Lambda
Per i runtime di Node.js, Lambda Managed Instances utilizza thread di lavoro `async` con esecuzione basata su`await`/per gestire le richieste simultanee. L'inizializzazione della funzione avviene una volta per thread di lavoro. Le chiamate simultanee vengono gestite in due dimensioni: i thread di lavoro forniscono il parallelismo su v e l'esecuzione asincrona fornisce la concorrenza all'interno di CPUs ciascun thread. Ogni richiesta concorrente gestita dallo stesso thread di lavoro condivide lo stesso oggetto del gestore e lo stesso stato globale, il che richiede una gestione sicura in caso di più richieste simultanee.
## Simultaneità massima
Il numero massimo di richieste simultanee che Lambda invia a ciascun ambiente di esecuzione è controllato dall'impostazione nella configurazione `PerExecutionEnvironmentMaxConcurrency` della funzione. Questa è un'impostazione opzionale e il valore predefinito varia a seconda del runtime. Per i runtime di Node.js, l'impostazione predefinita è 64 richieste simultanee per vCPU, oppure è possibile configurare un valore personalizzato. Lambda regola automaticamente il numero di richieste simultanee fino al massimo configurato in base alla capacità di ciascun ambiente di esecuzione di assorbire tali richieste.
Per Node.js, il numero di richieste simultanee che ogni ambiente di esecuzione può elaborare è determinato dal numero di thread di lavoro e dalla capacità di ciascun thread di lavoro di elaborare le richieste concorrenti in modo asincrono. Il numero predefinito di thread di lavoro è determinato dal numero di v CPUs disponibili oppure è possibile configurare il numero di thread di lavoro impostando la variabile di ambiente. `AWS_LAMBDA_NODEJS_WORKER_COUNT` Si consiglia di utilizzare gestori di funzioni asincroni poiché ciò consente l'elaborazione di più richieste per thread di lavoro. Se il gestore di funzioni è sincrono, ogni thread di lavoro può elaborare solo una singola richiesta alla volta.
## Creazione di funzioni per la concorrenza multipla
Con un gestore di funzioni asincrone, ogni runtime worker elabora più richieste contemporaneamente. Gli oggetti globali verranno condivisi tra più richieste simultanee. Per gli oggetti mutabili, evita di usare global state or use. `AsyncLocalStorage`
AWS I client SDK sono asincroni e non richiedono una gestione speciale.
**Esempio: stato globale**
Il codice seguente utilizza un oggetto globale che viene modificato all'interno del gestore della funzione. Questo non è asincrono.
```
let state = {
currentUser: null,
requestData: null
};
export const handler = async (event, context) => {
state.currentUser = event.userId;
state.requestData = event.data;
await processData(state.requestData);
// state.currentUser might now belong to a different request
return { user: state.currentUser };
};
```
L'inizializzazione dell'`state`oggetto all'interno del gestore della funzione evita lo stato globale condiviso.
```
export const handler = async (event, context) => {
let state = {
currentUser: event.userId,
requestData: event.data
};
await processData(state.requestData);
return { user: state.currentUser };
};
```
**Esempio: connessioni al database**
Il codice seguente utilizza un oggetto client condiviso che viene condiviso tra più chiamate. A seconda della libreria di connessioni utilizzata, questo potrebbe non essere sicuro in termini di concorrenza.
```
const { Client } = require('pg');
// Single connection created at init time
const client = new Client({
host: process.env.DB_HOST,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD
});
// Connect once during cold start
client.connect();
exports.handler = async (event) => {
// Multiple parallel invocations share this single connection = BAD
// With multi-concurrent Lambda, queries will collide
const result = await client.query('SELECT * FROM users WHERE id = $1', [event.userId]);
return {
statusCode: 200,
body: JSON.stringify(result.rows[0])
};
};
```
Un approccio sicuro per la concorrenza consiste nell'utilizzare un pool di connessioni. Il pool utilizza una connessione separata per ogni interrogazione simultanea del database.
```
const { Pool } = require('pg');
// Connection pool created at init time
const pool = new Pool({
host: process.env.DB_HOST,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD,
max: 20, // Max connections in pool
idleTimeoutMillis: 30000,
connectionTimeoutMillis: 2000
});
exports.handler = async (event) => {
// Pool gives each parallel invocation its own connection
const result = await pool.query('SELECT * FROM users WHERE id = $1', [event.userId]);
return {
statusCode: 200,
body: JSON.stringify(result.rows[0])
};
};
```
## Gestori basati su callback Node.js 22
Quando si utilizza Node.js 22, non è possibile utilizzare un gestore di funzioni basato su callback con Lambda Managed Instances. I gestori basati su callback sono supportati solo per le funzioni Lambda (predefinite). Per i runtime di Node.js 24 e versioni successive, i gestori di funzioni basati su callback sono obsoleti sia per le istanze gestite Lambda (impostazione predefinita) che per quelle gestite Lambda.
Utilizza invece un gestore di `async` funzioni quando usi Lambda Managed Instances. Per ulteriori informazioni, consulta [Definire il gestore di funzioni Lambda](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html) in Node.js.
## 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, implementate il blocco dei file per i file condivisi o utilizzate nomi di file univoci per richiesta per evitare conflitti. Ricordati di ripulire i file non necessari per evitare di esaurire lo spazio disponibile.
## Registrazione dei log
L'interlacciamento dei log (le voci di registro di diverse richieste vengono interlacciate nei log) è normale nei sistemi multi-concorrenti. [Le funzioni che utilizzano Lambda Managed Instances utilizzano sempre il formato di registro JSON strutturato introdotto con controlli di registrazione avanzati.](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) Questo formato include`requestId`, che consente di correlare le voci di registro a una singola richiesta. Quando si utilizza il `console` logger, `requestId` viene automaticamente incluso in ogni voce di registro. Per ulteriori informazioni, vedere[Utilizzo dei controlli di registrazione avanzati di Lambda con Node.js](nodejs-logging.md#node-js-logging-advanced).
Le librerie di registrazione di terze parti più diffuse, come [Winston](https://github.com/winstonjs/winston), includono in genere il supporto per l'utilizzo della console per l'output dei log.
## Contesto della richiesta
Using `context.awsRequestId` fornisce un accesso sicuro e asincrono all'ID della richiesta corrente.
Utilizzare `context.xRayTraceId` per accedere all'ID di traccia X-Ray. Ciò fornisce un accesso sicuro in termini di concorrenza all'ID di traccia per la richiesta corrente. Lambda non supporta la variabile di `_X_AMZN_TRACE_ID` ambiente con Lambda Managed Instances. L'ID di traccia X-Ray viene propagato automaticamente quando si utilizza l'SDK. AWS
Utilizzato per rilevare i `context.getRemainingTimeInMillis()` timeout. Per ulteriori informazioni, consulta [Gestione e ripristino degli errori](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Inizializzazione e spegnimento
L'inizializzazione della funzione avviene una volta per thread di lavoro. È possibile che vengano visualizzate voci di registro ripetute se la funzione emette log durante l'inizializzazione.
Per le funzioni Lambda con estensioni, l'ambiente di esecuzione emette un segnale SIGTERM durante lo spegnimento. Questo segnale viene utilizzato dalle estensioni per attivare attività di pulizia, come lo svuotamento dei buffer. Le funzioni Lambda (impostazione predefinita) con estensioni possono anche sottoscrivere il segnale SIGTERM utilizzando. `process.on()` Questa funzionalità non è supportata per le funzioni che utilizzano istanze gestite Lambda poiché `process.on()` non può essere utilizzata con i thread di lavoro. Per ulteriori informazioni sul ciclo di vita dell'ambiente di esecuzione, consulta [Comprendere il ciclo di vita dell’ambiente di esecuzione Lambda](lambda-runtime-environment.md).
## Versioni di dipendenza
Lambda Managed Instances richiede le seguenti versioni minime del pacchetto:
+ AWS SDK per JavaScript v3: versione 3.933.0 o successiva
+ AWS X-Ray SDK per Node.js: versione 3.12.0 o successiva
+ AWS Distro for OpenTelemetry - Strumentazione per: versione 0.8.0 o successiva JavaScript
+ Powertools for AWS Lambda TypeScript (): versione 2.29.0 o successiva
## Elettroutensili per AWS TypeScript Lambda ()
Powertools for AWS Lambda TypeScript () è compatibile con Lambda Managed Instances e fornisce utilità per la registrazione, il tracciamento, le metriche e altro ancora. Per ulteriori informazioni, vedete [Powertools for AWS Lambda TypeScript](https://github.com/aws-powertools/powertools-lambda-typescript) ().
## Fasi successive
+ Esamina il [runtime Java per le istanze gestite Lambda](lambda-managed-instances-java-runtime.md)
+ [Esamina il runtime Python per le istanze gestite Lambda](lambda-managed-instances-python-runtime.md)
+ Esamina il [runtime di.NET per le istanze gestite da Lambda](lambda-managed-instances-dotnet-runtime.md)
+ Scopri come [scalare le istanze gestite Lambda](lambda-managed-instances-scaling.md)
# Runtime Python per istanze gestite Lambda
Il runtime Lambda utilizza più processi Python per gestire le richieste simultanee. Ogni richiesta simultanea viene eseguita in un processo separato con spazio di memoria e inizializzazione propri. 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'impostazione nella configurazione `PerExecutionEnvironmentMaxConcurrency` della funzione. Questa è un'impostazione opzionale e il valore predefinito varia a seconda del runtime. Per i runtime Python, l'impostazione predefinita è 16 richieste simultanee per vCPU, oppure puoi configurare il tuo valore. Questo valore determina anche il numero di processi utilizzati dal runtime di Python. Lambda regola automaticamente il numero di richieste simultanee fino al massimo configurato in base alla capacità di ciascun ambiente di esecuzione di assorbire tali richieste.
**Importante**
L'utilizzo 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 simultanei. Se state caricando librerie o set di dati di grandi dimensioni e la concorrenza è elevata, avrete un notevole ingombro di memoria. 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 multiconcorrenza
Grazie al modello multi-concorrenza basato sui processi, le funzioni 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, implementate il blocco dei file per i file condivisi o utilizzate nomi di file univoci per processo o per richiesta per evitare conflitti. Ricorda di ripulire i file non necessari per evitare di esaurire lo spazio disponibile.
## Registrazione dei log
L'interlacciamento dei log (le voci di registro di diverse richieste vengono interlacciate nei log) è normale nei sistemi multi-concorrenti.
[Le funzioni che utilizzano Lambda Managed Instances utilizzano sempre il formato di registro JSON strutturato introdotto con controlli di registrazione avanzati.](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) Questo formato include`requestId`, che consente di correlare le voci di registro a una singola richiesta. Quando usi il `logging` modulo della libreria standard Python in Lambda, `requestId` viene incluso automaticamente in ogni voce di registro. Per ulteriori informazioni, consulta [Usare i controlli di registrazione avanzati Lambda con Python](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html#python-logging-advanced).
## Contesto della richiesta
Utilizzare `context.aws_request_id` per accedere all'ID della richiesta corrente.
Con i runtime Python, puoi usare la variabile di `_X_AMZN_TRACE_ID` ambiente per accedere all'ID di traccia X-Ray con Lambda Managed Instances. L'ID di traccia X-Ray viene propagato automaticamente quando si utilizza l'SDK. AWS
Utilizzato per rilevare i `context.get_remaining_time_in_millis()` timeout. Per ulteriori informazioni, consulta [Gestione e ripristino degli errori](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Inizializzazione e spegnimento
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 lo spegnimento. Questo segnale viene utilizzato dalle estensioni per attivare attività di pulizia, come lo svuotamento dei buffer. È possibile sottoscrivere 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](lambda-runtime-environment.md).
## 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, il tracciamento, le metriche e altro ancora. Per ulteriori informazioni, vedere [Powertools for AWS Lambda (Python)](https://github.com/aws-powertools/powertools-lambda-python).
## Fasi successive
+ Esamina il [runtime Java per le istanze gestite Lambda](lambda-managed-instances-java-runtime.md)
+ Esamina il [runtime di Node.js per le istanze gestite Lambda](lambda-managed-instances-nodejs-runtime.md)
+ Esamina il [runtime di.NET per le istanze gestite Lambda](lambda-managed-instances-dotnet-runtime.md)
+ Scopri come [scalare le istanze gestite Lambda](lambda-managed-instances-scaling.md)
# .NET runtime per istanze gestite Lambda
Per i runtime.NET, le istanze gestite Lambda utilizzano un singolo processo.NET per ambiente di esecuzione. Più richieste simultanee vengono elaborate utilizzando .NET Tasks.
## Configurazione della concorrenza
Il numero massimo di richieste simultanee che Lambda invia a ciascun ambiente di esecuzione è controllato dall'impostazione nella configurazione `PerExecutionEnvironmentMaxConcurrency` della funzione. Questa è un'impostazione opzionale e il valore predefinito varia a seconda del runtime. Per i runtime.NET, l'impostazione predefinita è 32 richieste simultanee per vCPU, oppure è possibile configurare un valore personalizzato. Lambda regola automaticamente il numero di richieste simultanee fino al massimo configurato in base alla capacità di ciascun ambiente di esecuzione di assorbire tali richieste.
## Creazione di funzioni per la multiconcorrenza
È necessario applicare le stesse pratiche di sicurezza della concorrenza quando si utilizzano le istanze gestite Lambda come si farebbe in qualsiasi altro ambiente multi-concorrente. Poiché l'oggetto handler è condiviso tra tutte le attività, qualsiasi stato mutabile deve essere thread-safe. Ciò include raccolte, connessioni al database e qualsiasi oggetto statico modificato durante l'elaborazione della richiesta.
AWS I client SDK sono thread-safe e non richiedono una gestione speciale.
**Esempio: pool di connessioni al database**
Il codice seguente utilizza un oggetto di connessione al database statico che viene condiviso tra richieste simultanee. L'`SqlConnection`oggetto non è thread-safe.
```
public class DBQueryHandler
{
// Single connection shared across threads - NOT SAFE
private SqlConnection connection;
public DBQueryHandler()
{
connection = new SqlConnection("your-connection-string-here");
connection.Open();
}
public string Handle(object input, ILambdaContext context)
{
using var cmd = connection.CreateCommand();
cmd.CommandText = "SELECT ..."; // your query
using var reader = cmd.ExecuteReader();
...
}
}
```
Per risolvere questo problema, utilizzate una connessione separata per ogni richiesta, ricavata da un pool di connessioni. I provider ADO.NET supportano `Microsoft.Data.SqlClient` automaticamente il pool di connessioni quando l'oggetto di connessione viene aperto.
```
public class DBQueryHandler
{
public DBQueryHandler()
{
}
public string Handle(object input, ILambdaContext context)
{
using var connection = new SqlConnection("your-connection-string-here");
connection.Open();
using var cmd = connection.CreateCommand();
cmd.CommandText = "SELECT ..."; // your query
using var reader = cmd.ExecuteReader();
...
}
}
```
**Esempio: raccolte**
Le raccolte .NET standard non sono thread-safe:
```
public class Handler
{
private static List items = new List();
private static Dictionary cache = new Dictionary();
public string FunctionHandler(object input, ILambdaContext context)
{
items.Add(context.AwsRequestId);
cache["key"] = input;
return "Success";
}
}
```
Usa le raccolte dallo spazio dei `System.Collections.Concurrent` nomi per la sicurezza della concorrenza:
```
public class Handler
{
private static ConcurrentBag items = new ConcurrentBag();
private static ConcurrentDictionary cache = new ConcurrentDictionary();
public string FunctionHandler(object input, ILambdaContext context)
{
items.Add(context.AwsRequestId);
cache["key"] = input;
return "Success";
}
}
```
## 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'altra richiesta sovrascrive il file. Per risolvere questo problema, implementate il blocco dei file per i file condivisi o utilizzate nomi di file univoci per richiesta per evitare conflitti. Ricordati di ripulire i file non necessari per evitare di esaurire lo spazio disponibile.
## Registrazione dei log
L'interlacciamento dei log (le voci di registro di diverse richieste vengono interlacciate nei log) è normale nei sistemi multi-concorrenti. [Le funzioni che utilizzano Lambda Managed Instances utilizzano sempre il formato di registro JSON strutturato introdotto con controlli di registrazione avanzati.](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) Questo formato include`requestId`, che consente di correlare le voci di registro a una singola richiesta. Quando si utilizza l'`context.Logger`oggetto per generare registri, `requestId` viene automaticamente incluso in ogni voce di registro. Per ulteriori informazioni, vedere[Utilizzo dei controlli di registrazione avanzati di Lambda con .NET](csharp-logging.md#csharp-logging-advanced).
## Contesto della richiesta
Utilizza la `context.AwsRequestId` proprietà per accedere all'ID della richiesta corrente.
Utilizzate la `context.TraceId` proprietà per accedere all'ID della traccia X-Ray. Ciò fornisce un accesso sicuro per la concorrenza all'ID di traccia per la richiesta corrente. Lambda non supporta la variabile di `_X_AMZN_TRACE_ID` ambiente con Lambda Managed Instances. L'ID di traccia X-Ray viene propagato automaticamente quando si utilizza l'SDK. AWS
Utilizzato per rilevare i `ILambdaContext.RemainingTime` timeout. Per ulteriori informazioni, consulta [Gestione e ripristino degli errori](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Inizializzazione e spegnimento
L'inizializzazione della funzione avviene una volta per ambiente di esecuzione. Gli oggetti creati durante l'inizializzazione vengono condivisi tra le richieste.
Per le funzioni Lambda con estensioni, l'ambiente di esecuzione emette un segnale SIGTERM durante lo spegnimento. Questo segnale viene utilizzato dalle estensioni per attivare attività di pulizia, come lo svuotamento dei buffer. È possibile sottoscrivere 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](lambda-runtime-environment.md).
## Versioni di dipendenza
Lambda Managed Instances richiede le seguenti versioni minime del pacchetto:
+ Amazon.Lambda.Core: versione 2.7.1 o successiva
+ Amazon.Lambda. RuntimeSupport: versione 1.14.1 o successiva
+ OpenTelemetry.Strumentazione. AWSLambda: versione 1.14.0 o successiva
+ AWSXRayRecorder.Core: versione 2.16.0 o successiva
+ AWSSDK.Core: versione 4.0.0.32 o successiva
## Utensili elettrici per AWS Lambda (.NET)
[Powertools for AWS Lambda (.NET](https://docs.aws.amazon.com/powertools/dotnet/)) [AWS e Distro OpenTelemetry for - Instrumentation for DotNet](https://github.com/aws-observability/aws-otel-dotnet-instrumentation) attualmente non supportano le istanze gestite Lambda.
## Fasi successive
+ Esamina il [runtime Java per le istanze gestite Lambda](lambda-managed-instances-java-runtime.md)
+ Esamina il [runtime di Node.js per le istanze gestite Lambda](lambda-managed-instances-nodejs-runtime.md)
+ [Esamina il runtime Python per le istanze gestite Lambda](lambda-managed-instances-python-runtime.md)
+ Scopri come [scalare le istanze gestite Lambda](lambda-managed-instances-scaling.md)
# Supporto Rust per istanze gestite Lambda
## Configurazione della concorrenza
Il numero massimo di richieste simultanee che Lambda invia a ciascun ambiente di esecuzione è controllato dall'impostazione nella configurazione `PerExecutionEnvironmentMaxConcurrency` della funzione. Questa è un'impostazione opzionale e il valore predefinito per Rust è 8 richieste simultanee per vCPU, oppure puoi configurare il tuo valore. Questo valore determina il numero di attività Tokio generate dal runtime ed è statico per tutta la durata dell'ambiente di esecuzione. Ogni lavoratore gestisce esattamente una richiesta in corso alla volta, senza multiplazione per lavoratore. Lambda regola automaticamente il numero di richieste simultanee fino al massimo configurato in base alla capacità di ciascun ambiente di esecuzione di assorbire tali richieste.
## Creazione di funzioni per la multiconcorrenza
È necessario applicare le stesse pratiche di sicurezza dei thread quando si utilizzano le istanze gestite Lambda come si farebbe in qualsiasi altro ambiente multithread. Poiché l'oggetto handler è condiviso tra tutti i thread di lavoro, qualsiasi stato mutabile deve essere thread-safe. Ciò include raccolte, connessioni al database e qualsiasi oggetto statico modificato durante l'elaborazione della richiesta.
Per abilitare la gestione simultanea delle richieste, aggiungi il flag di `concurrency-tokio` funzionalità al tuo `Cargo.toml` file.
```
[dependencies]
lambda_runtime = { version = "1", features = ["concurrency-tokio"] }
```
Il punto di `lambda_runtime::run_concurrent(…)` ingresso deve essere chiamato dall'interno di un runtime Tokio, in genere fornito dall'`#[tokio::main]`attributo sulla funzione principale. La chiusura del gestore deve implementare [https://doc.rust-lang.org/std/clone/trait.Clone.html](https://doc.rust-lang.org/std/clone/trait.Clone.html)\$1. [https://doc.rust-lang.org/std/marker/trait.Send.html](https://doc.rust-lang.org/std/marker/trait.Send.html) Ciò consente al framework di condividere il gestore tra più attività asincrone in modo sicuro. Se questi limiti non vengono soddisfatti, il codice non verrà compilato.
Quando hai bisogno di uno stato condiviso tra le chiamate (un pool di database, una struttura di configurazione), inseriscilo [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html)e clonalo in ogni invocazione. `Arc`
Tutti i client AWS SDK for Rust sono sicuri per la concorrenza e non richiedono una gestione speciale.
### AWS Esempio: client SDK
L'esempio seguente utilizza un client S3 per caricare un oggetto a ogni chiamata. Il client viene clonato direttamente nella chiusura senza: `Arc`
```
let config = aws_config::load_defaults(BehaviorVersion::latest()).await;
let s3_client = aws_sdk_s3::Client::new(&config);
run_concurrent(service_fn(move |event: LambdaEvent| {
let s3_client = s3_client.clone(); // cheap clone, no Arc needed
async move {
s3_client.put_object()
.bucket(&event.payload.bucket)
.key(&event.payload.key)
.body(event.payload.body.into_bytes().into())
.send()
.await?;
Ok(Response { message: "uploaded".into() })
}
}))
.await
```
### Esempio: pool di connessioni al database
Quando il gestore ha bisogno di accedere a uno stato condiviso, ad esempio un client e una configurazione, inseriscilo [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html)e clonalo `Arc` in ogni chiamata:
```
#[derive(Debug)]
struct AppState {
dynamodb_client: DynamoDbClient,
table_name: String,
cache_ttl: Duration,
}
let config = aws_config::load_defaults(BehaviorVersion::latest()).await;
let state = Arc::new(AppState {
dynamodb_client: DynamoDbClient::new(&config),
table_name: std::env::var("TABLE_NAME").expect("TABLE_NAME must be set"),
cache_ttl: Duration::from_secs(300),
});
run_concurrent(service_fn(move |event: LambdaEvent| {
let state = state.clone();
async move { handle(event, state).await }
}))
.await
```
## Directory /tmp condivisa
La `/tmp` directory è condivisa tra tutte le chiamate simultanee nello stesso ambiente di esecuzione. Utilizza nomi di file univoci per ogni chiamata (ad esempio includi l'ID della richiesta) o implementa il blocco esplicito dei file per evitare il danneggiamento dei dati.
## Registrazione dei log
L'interlacciamento dei log (le voci di registro di diverse richieste vengono interlacciate nei log) è normale nei sistemi multi-concorrenti. [Le funzioni che utilizzano Lambda Managed Instances supportano il formato di log JSON strutturato tramite i controlli di registrazione avanzati di Lambda.](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) Questo formato include`requestId`, che consente di correlare le voci di registro a una singola richiesta. Per ulteriori informazioni, vedere[Registrazione avanzata con la cassa Tracing](rust-logging.md#rust-logging-tracing).
## Contesto della richiesta
L'`Context`oggetto viene passato direttamente a ogni chiamata del gestore. Utilizzare `event.context.request_id` per accedere all'ID della richiesta corrente.
Utilizzare `event.context.xray_trace_id` per accedere all'ID di traccia X-Ray. Lambda non supporta la variabile di `_X_AMZN_TRACE_ID` ambiente con Lambda Managed Instances. L'ID di traccia X-Ray viene propagato automaticamente quando si utilizza l' AWS SDK per Rust.
Viene utilizzato `event.context.deadline` per rilevare i timeout: contiene la scadenza della chiamata in millisecondi.
## Inizializzazione e spegnimento
L'inizializzazione della funzione avviene una volta per ambiente di esecuzione. Gli oggetti creati durante l'inizializzazione vengono condivisi tra le richieste.
Per le funzioni Lambda con estensioni, l'ambiente di esecuzione emette un segnale SIGTERM durante lo spegnimento. Questo segnale viene utilizzato dalle estensioni per attivare attività di pulizia, come lo svuotamento dei buffer. `lambda_runtime`offre un aiuto per semplificare la configurazione di una corretta gestione del segnale di spegnimento,. [https://docs.rs/lambda_runtime/latest/lambda_runtime/fn.spawn_graceful_shutdown_handler.html](https://docs.rs/lambda_runtime/latest/lambda_runtime/fn.spawn_graceful_shutdown_handler.html) Per ulteriori informazioni sul ciclo di vita dell'ambiente di esecuzione, consulta [Comprendere il ciclo di vita dell’ambiente di esecuzione Lambda](lambda-runtime-environment.md).
## Versioni di dipendenza
Lambda Managed Instances richiede la seguente versione minima del pacchetto:
+ `lambda_runtime`: versione 1.1.1 o successiva, con la funzionalità abilitata `concurrency-tokio`
+ La versione minima di Rust (MSRV) supportata è 1.84.0.