Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Runtimes des instances gérées Lambda
Lambda traite les demandes différemment lorsqu'il utilise des instances gérées par Lambda. Au lieu de traiter les demandes de manière séquentielle dans chaque environnement d'exécution, les instances gérées Lambda traitent plusieurs demandes simultanément dans chaque environnement d'exécution. Ce changement de modèle d'exécution signifie que les fonctions utilisant des instances gérées par Lambda doivent tenir compte de la sécurité des threads, de la gestion des états et de l'isolation du contexte, des problèmes qui ne se posent pas dans le modèle de simultanéité unique Lambda (par défaut). En outre, la mise en œuvre de la multisimultanéité varie selon les environnements d'exécution.
## Langues prises en charge
Les instances gérées Lambda peuvent être utilisées avec les langages de programmation et les environnements d'exécution suivants :
+ **Java :** Java 21 et versions ultérieures.
+ **Python :** Python 3.13 et versions ultérieures.
+ **Node.js :** Node.js 22 et versions ultérieures.
+ **.NET :** .NET 8 et versions ultérieures.
+ **Rust :** compatible avec l'environnement d'exécution uniquement pour le système d'exploitation `provided.al2023` et les versions ultérieures.
## Considérations spécifiques à la langue
Chaque langage de programmation implémente la multiconcurrence différemment. Vous devez comprendre comment la multiconcurrence est implémentée dans le langage de programmation que vous avez choisi pour appliquer les meilleures pratiques de simultanéité appropriées.
**Java**
Utilise un processus unique avec des threads du système d'exploitation pour la simultanéité. Plusieurs threads exécutent simultanément la méthode du gestionnaire, ce qui nécessite une gestion sécurisée de l'état et des ressources partagées.
**Python**
Utilise plusieurs processus Python dans lesquels chaque demande simultanée est exécutée dans le cadre d'un processus distinct. Cela protège contre la plupart des problèmes de simultanéité, bien qu'il soit nécessaire de faire attention aux ressources partagées telles que le `/tmp` répertoire.
**Node.js**
Utilise des [threads](https://nodejs.org/api/worker_threads.html) de travail avec une exécution asynchrone. Les demandes simultanées sont réparties entre les threads de travail, et chaque thread de travail peut également traiter les demandes simultanées de manière asynchrone, ce qui nécessite une gestion sûre de l'état et des ressources partagées.
**.NET**
Utilise les tâches .NET avec le traitement asynchrone de plusieurs demandes simultanées. Nécessite une gestion sûre des ressources publiques et partagées.
**Rust**
Utilise un processus unique avec des tâches asynchrones optimisées par [Tokio](https://tokio.rs/). Le gestionnaire doit être `Clone` \$1`Send`.
## Étapes suivantes
Pour obtenir des informations détaillées sur chaque environnement d'exécution, consultez les rubriques suivantes :
+ [Runtime Java pour les instances gérées Lambda](lambda-managed-instances-java-runtime.md)
+ [Runtime Node.js pour les instances gérées Lambda](lambda-managed-instances-nodejs-runtime.md)
+ [Runtime Python pour les instances gérées Lambda](lambda-managed-instances-python-runtime.md)
+ [Environnement d'exécution .NET pour les instances gérées Lambda](lambda-managed-instances-dotnet-runtime.md)
+ [Support Rust pour les instances gérées Lambda](lambda-managed-instances-rust.md)
# Runtime Java pour les instances gérées Lambda
Pour les environnements d'exécution Java, les instances gérées Lambda utilisent les threads du système d'exploitation à des fins de simultanéité. Lambda charge votre objet gestionnaire une fois par environnement d'exécution lors de l'initialisation, puis crée plusieurs threads. Ces threads s'exécutent en parallèle et nécessitent une gestion sûre de l'état et des ressources partagées. Chaque thread partage le même objet de gestionnaire et tous les champs statiques.
## Configuration de la simultanéité
Le nombre maximum de demandes simultanées que Lambda envoie à chaque environnement d'exécution est contrôlé par le `PerExecutionEnvironmentMaxConcurrency` paramètre de configuration de la fonction. Ce paramètre est facultatif et la valeur par défaut varie en fonction du temps d'exécution. Pour les environnements d'exécution Java, la valeur par défaut est de 32 requêtes simultanées par vCPU, ou vous pouvez configurer votre propre valeur. Cette valeur détermine également le nombre de threads utilisés par le moteur d'exécution Java. Lambda ajuste automatiquement le nombre de demandes simultanées jusqu'au maximum configuré en fonction de la capacité de chaque environnement d'exécution à absorber ces demandes.
## Création de fonctions pour la multisimultanéité
Vous devez appliquer les mêmes pratiques de sécurité des threads lorsque vous utilisez des instances gérées Lambda que dans tout autre environnement multithread. Étant donné que l'objet du gestionnaire est partagé entre tous les threads de travail d'exécution, tout état mutable doit être sûr pour les threads. Cela inclut les collections, les connexions aux bases de données et tous les objets statiques modifiés lors du traitement des demandes.
AWS Les clients du SDK sont compatibles avec les threads et ne nécessitent aucune manipulation particulière.
**Exemple : pools de connexions aux bases de données**
Le code suivant utilise un objet de connexion à une base de données statique partagé entre les threads. Selon la bibliothèque de connexion utilisée, cela peut ne pas être sûr pour les threads.
```
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();
}
}
```
Une approche thread-safe consiste à utiliser un pool de connexions. Dans l'exemple suivant, le gestionnaire de fonctions extrait une connexion du pool. La connexion n'est utilisée que dans le cadre d'une seule demande.
```
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();
}
}
```
**Exemple : Collections**
Les collections Java standard ne sont pas sûres pour les threads :
```
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";
}
}
```
Utilisez plutôt des collections adaptées aux threads :
```
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";
}
}
```
## Répertoire /tmp partagé
Le `/tmp` répertoire est partagé entre toutes les demandes simultanées dans l'environnement d'exécution. Les écritures simultanées dans le même fichier peuvent entraîner une corruption des données, par exemple si un autre processus remplace le fichier. Pour résoudre ce problème, implémentez le verrouillage des fichiers partagés ou utilisez des noms de fichiers uniques par thread ou par demande afin d'éviter les conflits. N'oubliez pas de nettoyer les fichiers inutiles pour ne pas épuiser l'espace disponible.
## Logging
L'entrelacement des journaux (les entrées des journaux provenant de différentes demandes sont entrelacées dans des journaux) est normal dans les systèmes multiconcurrents.
Les fonctions utilisant des instances gérées Lambda utilisent toujours le format de journal JSON structuré introduit avec les contrôles de [journalisation avancés](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Ce format inclut le`requestId`, ce qui permet de corréler les entrées du journal à une seule demande. Lorsque vous utilisez l'`LambdaLogger`objet de`context.getLogger()`, `requestId` il est automatiquement inclus dans chaque entrée du journal. Pour plus d'informations, voir[Utilisation des contrôles de journalisation avancés de Lambda avec Java](java-logging.md#java-logging-advanced).
## Contexte de la requête
L'`context`objet est lié au fil de requête. L'utilisation `context.getAwsRequestId()` fournit un accès multithread à l'ID de demande pour la demande en cours.
`context.getXrayTraceId()`À utiliser pour accéder au X-Ray Trace ID. Cela fournit un accès sécurisé à l'ID de trace pour la demande en cours. Lambda ne prend pas en charge la variable d'`_X_AMZN_TRACE_ID`environnement avec les instances gérées par Lambda. Le X-Ray Trace ID est automatiquement propagé lors de l'utilisation du AWS SDK.
`com.amazonaws.services.lambda.runtime.Context.getRemainingTimeInMillis()`À utiliser pour détecter les délais d'expiration. Pour plus d’informations, consultez [Gestion des erreurs et restauration](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
Si vous utilisez des threads virtuels dans votre programme ou si vous créez des threads lors de l'initialisation, vous devrez transmettre tout contexte de demande requis à ces threads.
## Initialisation et arrêt
L'initialisation de la fonction a lieu une fois par environnement d'exécution. Les objets créés lors de l'initialisation sont partagés entre les threads.
Pour les fonctions Lambda avec extensions, l'environnement d'exécution émet un signal SIGTERM lors de l'arrêt. Ce signal est utilisé par les extensions pour déclencher des tâches de nettoyage, telles que le rinçage des tampons. Vous pouvez vous abonner aux événements SIGTERM pour déclencher des tâches de nettoyage des fonctions, telles que la fermeture des connexions aux bases de données. Pour en savoir plus sur le cycle de vie de l'environnement d'exécution, veuillez consulter [Comprendre le cycle de vie de l’environnement d’exécution Lambda](lambda-runtime-environment.md).
## Versions de dépendance
Les instances gérées Lambda nécessitent les versions de package minimales suivantes :
+ AWS SDK pour Java 2.0 : version 2.34.0 ou ultérieure
+ AWS SDK X-Ray pour Java : version 2.20.0 ou ultérieure
+ AWS Distro for OpenTelemetry - Instrumentation pour Java : version 2.20.0 ou ultérieure
+ Powertools pour AWS Lambda (Java) : version 2.8.0 ou ultérieure
## Outils électriques pour AWS Lambda (Java)
Powertools for AWS Lambda (Java) est compatible avec les instances gérées par Lambda et fournit des utilitaires pour la journalisation, le suivi, les métriques, etc. Pour plus d'informations, consultez [Powertools for AWS Lambda (](https://github.com/aws-powertools/powertools-lambda-java)Java).
## Étapes suivantes
+ Vérifiez le [runtime Node.js pour les instances gérées Lambda](lambda-managed-instances-nodejs-runtime.md)
+ Passez [en revue le runtime Python pour les instances gérées Lambda](lambda-managed-instances-python-runtime.md)
+ Passez en revue le [runtime .NET pour les instances gérées Lambda](lambda-managed-instances-dotnet-runtime.md)
+ En savoir plus sur le [dimensionnement des instances gérées Lambda](lambda-managed-instances-scaling.md)
# Runtime Node.js pour les instances gérées Lambda
Pour les environnements d'exécution de Node.js, les instances gérées Lambda utilisent des threads de travail `async` avec une exécution basée sur`await`/pour gérer les demandes simultanées. L'initialisation de la fonction a lieu une fois par thread de travail. Les invocations simultanées sont gérées selon deux dimensions : les threads de travail assurent le parallélisme entre vCPUs, et l'exécution asynchrone assure la simultanéité au sein de chaque thread. Chaque demande simultanée traitée par le même thread de travail partage le même objet de gestionnaire et le même état global, ce qui nécessite un traitement sécurisé dans le cadre de plusieurs demandes simultanées.
## Simultanéité maximum
Le nombre maximum de demandes simultanées que Lambda envoie à chaque environnement d'exécution est contrôlé par le `PerExecutionEnvironmentMaxConcurrency` paramètre de configuration de la fonction. Il s'agit d'un paramètre facultatif, et la valeur par défaut varie en fonction du temps d'exécution. Pour les environnements d'exécution de Node.js, la valeur par défaut est de 64 requêtes simultanées par vCPU, ou vous pouvez configurer votre propre valeur. Lambda ajuste automatiquement le nombre de demandes simultanées jusqu'au maximum configuré en fonction de la capacité de chaque environnement d'exécution à absorber ces demandes.
Pour Node.js, le nombre de demandes simultanées que chaque environnement d'exécution peut traiter est déterminé par le nombre de threads de travail et par la capacité de chaque thread de travail à traiter les demandes simultanées de manière asynchrone. Le nombre par défaut de threads de travail est déterminé par le nombre de v CPUs disponibles, ou vous pouvez configurer le nombre de threads de travail en définissant la variable d'`AWS_LAMBDA_NODEJS_WORKER_COUNT`environnement. Nous recommandons d'utiliser des gestionnaires de fonctions asynchrones, car cela permet de traiter plusieurs demandes par thread de travail. Si votre gestionnaire de fonctions est synchrone, chaque thread de travail ne peut traiter qu'une seule demande à la fois.
## Création de fonctions pour la multisimultanéité
Avec un gestionnaire de fonctions asynchrones, chaque utilisateur d'exécution traite plusieurs demandes simultanément. Les objets globaux seront partagés entre plusieurs demandes simultanées. Pour les objets mutables, évitez d'utiliser un état ou un usage `AsyncLocalStorage` global.
AWS Les clients du SDK sont sécurisés en mode asynchrone et ne nécessitent aucune manipulation particulière.
**Exemple : État global**
Le code suivant utilise un objet global qui est muté dans le gestionnaire de fonctions. Ce n'est pas sécurisé en mode asynchrone.
```
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'initialisation de l'`state`objet dans le gestionnaire de fonctions permet d'éviter un état global partagé.
```
export const handler = async (event, context) => {
let state = {
currentUser: event.userId,
requestData: event.data
};
await processData(state.requestData);
return { user: state.currentUser };
};
```
**Exemple : connexions à la base de données**
Le code suivant utilise un objet client partagé qui est partagé entre plusieurs invocations. Selon la bibliothèque de connexions utilisée, cela peut ne pas être sécurisé en matière de simultanéité.
```
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])
};
};
```
Une approche sûre en matière de simultanéité consiste à utiliser un pool de connexions. Le pool utilise une connexion distincte pour chaque requête de base de données simultanée.
```
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])
};
};
```
## Node.js 22 gestionnaires basés sur des rappels
Lorsque vous utilisez Node.js 22, vous ne pouvez pas utiliser de gestionnaire de fonctions basé sur le rappel avec les instances gérées Lambda. Les gestionnaires basés sur le rappel ne sont pris en charge que pour les fonctions Lambda (par défaut). Pour les environnements d'exécution de Node.js 24 et versions ultérieures, les gestionnaires de fonctions basés sur le rappel sont déconseillés pour les instances Lambda (par défaut) et Lambda Managed Instances.
Utilisez plutôt un gestionnaire de `async` fonctions lorsque vous utilisez des instances gérées Lambda. Pour plus d'informations, voir [Définir le gestionnaire de fonctions Lambda](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html) dans le fichier Node.js.
## Répertoire /tmp partagé
Le `/tmp` répertoire est partagé entre toutes les demandes simultanées dans l'environnement d'exécution. Les écritures simultanées dans le même fichier peuvent entraîner une corruption des données, par exemple si un autre processus remplace le fichier. Pour résoudre ce problème, implémentez le verrouillage des fichiers partagés ou utilisez des noms de fichiers uniques par demande afin d'éviter les conflits. N'oubliez pas de nettoyer les fichiers inutiles pour ne pas épuiser l'espace disponible.
## Logging
L'entrelacement des journaux (les entrées des journaux provenant de différentes demandes sont entrelacées dans des journaux) est normal dans les systèmes multiconcurrents. Les fonctions utilisant des instances gérées Lambda utilisent toujours le format de journal JSON structuré introduit avec les contrôles de [journalisation avancés](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Ce format inclut le`requestId`, ce qui permet de corréler les entrées du journal à une seule demande. Lorsque vous utilisez l'`console`enregistreur, il `requestId` est automatiquement inclus dans chaque entrée du journal. Pour de plus amples informations, voir[Utilisation des contrôles de journalisation avancés de Lambda avec Node.js](nodejs-logging.md#node-js-logging-advanced).
Les bibliothèques de journalisation tierces les plus populaires, telles que [Winston](https://github.com/winstonjs/winston), prennent généralement en charge l'utilisation de la console pour la sortie des journaux.
## Contexte de la requête
L'utilisation `context.awsRequestId` fournit un accès asynchrone à l'ID de demande pour la demande en cours.
`context.xRayTraceId`À utiliser pour accéder au X-Ray Trace ID. Cela fournit un accès simultané à l'ID de trace pour la demande en cours. Lambda ne prend pas en charge la variable d'`_X_AMZN_TRACE_ID`environnement avec les instances gérées par Lambda. Le X-Ray Trace ID est automatiquement propagé lors de l'utilisation du AWS SDK.
`context.getRemainingTimeInMillis()`À utiliser pour détecter les délais d'expiration. Pour plus d’informations, consultez [Gestion des erreurs et restauration](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Initialisation et arrêt
L'initialisation de la fonction a lieu une fois par thread de travail. Des entrées de journal répétées peuvent s'afficher si votre fonction émet des journaux lors de l'initialisation.
Pour les fonctions Lambda avec extensions, l'environnement d'exécution émet un signal SIGTERM lors de l'arrêt. Ce signal est utilisé par les extensions pour déclencher des tâches de nettoyage, telles que le vidage des tampons. Les fonctions Lambda (par défaut) avec extensions peuvent également s'abonner au signal SIGTERM en utilisant. `process.on()` Ceci n'est pas pris en charge pour les fonctions utilisant des instances gérées Lambda car il `process.on()` ne peut pas être utilisé avec les threads de travail. Pour en savoir plus sur le cycle de vie de l'environnement d'exécution, veuillez consulter [Comprendre le cycle de vie de l’environnement d’exécution Lambda](lambda-runtime-environment.md).
## Versions de dépendance
Les instances gérées Lambda nécessitent les versions de package minimales suivantes :
+ AWS SDK pour JavaScript v3 : version 3.933.0 ou ultérieure
+ AWS Kit de développement X-Ray pour Node.js : version 3.12.0 ou ultérieure
+ AWS Distro pour OpenTelemetry - Instrumentation pour JavaScript : version 0.8.0 ou ultérieure
+ Powertools pour AWS Lambda TypeScript () : version 2.29.0 ou ultérieure
## Outils électriques pour AWS TypeScript Lambda ()
Powertools for AWS Lambda TypeScript () est compatible avec les instances gérées par Lambda et fournit des utilitaires pour la journalisation, le suivi, les métriques, etc. Pour plus d'informations, consultez [Powertools for AWS Lambda TypeScript](https://github.com/aws-powertools/powertools-lambda-typescript) ().
## Étapes suivantes
+ Passez en revue l'[environnement d'exécution Java pour les instances gérées Lambda](lambda-managed-instances-java-runtime.md)
+ Passez [en revue le runtime Python pour les instances gérées Lambda](lambda-managed-instances-python-runtime.md)
+ Passez en revue le [runtime .NET pour les instances gérées Lambda](lambda-managed-instances-dotnet-runtime.md)
+ En savoir plus sur le [dimensionnement des instances gérées Lambda](lambda-managed-instances-scaling.md)
# Runtime Python pour les instances gérées Lambda
Le moteur d'exécution Lambda utilise plusieurs processus Python pour gérer les requêtes simultanées. Chaque demande simultanée s'exécute dans le cadre d'un processus distinct avec son propre espace mémoire et son propre processus d'initialisation. Chaque processus traite une demande à la fois, de manière synchrone. Les processus ne partagent pas directement la mémoire, de sorte que les variables globales, les caches au niveau du module et les objets singleton sont isolés entre les demandes simultanées.
## Configuration de la simultanéité
Le nombre maximum de demandes simultanées que Lambda envoie à chaque environnement d'exécution est contrôlé par le `PerExecutionEnvironmentMaxConcurrency` paramètre de configuration de la fonction. Il s'agit d'un paramètre facultatif, et la valeur par défaut varie en fonction du temps d'exécution. Pour les environnements d'exécution Python, la valeur par défaut est de 16 requêtes simultanées par vCPU, ou vous pouvez configurer votre propre valeur. Cette valeur détermine également le nombre de processus utilisés par le moteur d'exécution Python. Lambda ajuste automatiquement le nombre de demandes simultanées jusqu'au maximum configuré en fonction de la capacité de chaque environnement d'exécution à absorber ces demandes.
**Important**
L'utilisation de la simultanéité basée sur les processus signifie que chaque processus de travail d'exécution effectue sa propre initialisation. L'utilisation totale de la mémoire est égale à la mémoire par processus multipliée par le nombre de processus simultanés. Si vous chargez des bibliothèques ou des ensembles de données volumineux et que la simultanéité est élevée, votre encombrement mémoire sera important. En fonction de votre charge de travail, vous devrez peut-être ajuster votre CPU-to-memory ratio ou utiliser un paramètre de simultanéité inférieur pour éviter de dépasser la mémoire disponible. Vous pouvez utiliser la `MemoryUtilization` métrique CloudWatch pour suivre la consommation de mémoire.
## Création de fonctions pour la multisimultanéité
En raison du modèle de multisimultanéité basé sur les processus, les fonctions Lambda Managed Instances utilisant des environnements d'exécution Python n'accèdent pas simultanément aux ressources en mémoire à partir de plusieurs appels. Il n'est pas nécessaire d'appliquer des pratiques de codage pour garantir la sécurité de la simultanéité en mémoire.
## Répertoire /tmp partagé
Le `/tmp` répertoire est partagé entre toutes les demandes simultanées dans l'environnement d'exécution. Les écritures simultanées dans le même fichier peuvent entraîner une corruption des données, par exemple si un autre processus remplace le fichier. Pour résoudre ce problème, implémentez le verrouillage des fichiers partagés ou utilisez des noms de fichiers uniques par processus ou par demande afin d'éviter les conflits. N'oubliez pas de nettoyer les fichiers inutiles pour ne pas épuiser l'espace disponible.
## Logging
L'entrelacement des journaux (les entrées des journaux provenant de différentes demandes sont entrelacées dans des journaux) est normal dans les systèmes multiconcurrents.
Les fonctions utilisant des instances gérées Lambda utilisent toujours le format de journal JSON structuré introduit avec les contrôles de [journalisation avancés](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Ce format inclut le`requestId`, ce qui permet de corréler les entrées du journal à une seule demande. Lorsque vous utilisez le `logging` module de la bibliothèque standard Python dans Lambda, `requestId` il est automatiquement inclus dans chaque entrée du journal. Pour plus d'informations, consultez la section [Utilisation des commandes de journalisation avancées Lambda avec Python](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html#python-logging-advanced).
## Contexte de la requête
Permet `context.aws_request_id` d'accéder à l'ID de demande pour la demande en cours.
Avec les environnements d'exécution Python, vous pouvez utiliser la variable d'`_X_AMZN_TRACE_ID`environnement pour accéder à l'ID de trace X-Ray avec les instances gérées Lambda. Le X-Ray Trace ID est automatiquement propagé lors de l'utilisation du AWS SDK.
`context.get_remaining_time_in_millis()`À utiliser pour détecter les délais d'expiration. Pour plus d’informations, consultez [Gestion des erreurs et restauration](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Initialisation et arrêt
L'initialisation de la fonction a lieu une fois par processus. Des entrées de journal répétées peuvent s'afficher si votre fonction émet des journaux lors de l'initialisation.
Pour les fonctions Lambda avec extensions, l'environnement d'exécution émet un signal SIGTERM lors de l'arrêt. Ce signal est utilisé par les extensions pour déclencher des tâches de nettoyage, telles que le rinçage des tampons. Vous pouvez vous abonner aux événements SIGTERM pour déclencher des tâches de nettoyage des fonctions, telles que la fermeture des connexions aux bases de données. Pour en savoir plus sur le cycle de vie de l'environnement d'exécution, veuillez consulter [Comprendre le cycle de vie de l’environnement d’exécution Lambda](lambda-runtime-environment.md).
## Versions de dépendance
Les instances gérées Lambda nécessitent les versions de package minimales suivantes :
+ Powertools pour AWS Lambda (Python) : version 3.23.0 ou ultérieure
## Powertools pour AWS Lambda (Python)
Powertools for AWS Lambda (Python) est compatible avec les instances gérées par Lambda et fournit des utilitaires pour la journalisation, le suivi, les métriques, etc. Pour plus d'informations, consultez [Powertools for AWS Lambda (Python)](https://github.com/aws-powertools/powertools-lambda-python).
## Étapes suivantes
+ Passez en revue l'[environnement d'exécution Java pour les instances gérées Lambda](lambda-managed-instances-java-runtime.md)
+ Passez en revue [le runtime Node.js pour les instances gérées Lambda](lambda-managed-instances-nodejs-runtime.md)
+ Passez en revue le [runtime .NET pour les instances gérées Lambda](lambda-managed-instances-dotnet-runtime.md)
+ En savoir plus sur le [dimensionnement des instances gérées Lambda](lambda-managed-instances-scaling.md)
# Environnement d'exécution .NET pour les instances gérées Lambda
Pour les environnements d'exécution .NET, les instances gérées Lambda utilisent un seul processus .NET par environnement d'exécution. Plusieurs demandes simultanées sont traitées à l'aide de tâches .NET.
## Configuration de la simultanéité
Le nombre maximum de demandes simultanées que Lambda envoie à chaque environnement d'exécution est contrôlé par le `PerExecutionEnvironmentMaxConcurrency` paramètre de configuration de la fonction. Il s'agit d'un paramètre facultatif, et la valeur par défaut varie en fonction du temps d'exécution. Pour les environnements d'exécution .NET, la valeur par défaut est de 32 requêtes simultanées par vCPU, ou vous pouvez configurer votre propre valeur. Lambda ajuste automatiquement le nombre de demandes simultanées jusqu'au maximum configuré en fonction de la capacité de chaque environnement d'exécution à absorber ces demandes.
## Création de fonctions pour la multisimultanéité
Lorsque vous utilisez des instances gérées Lambda, vous devez appliquer les mêmes pratiques de sécurité en matière de simultanéité que dans tout autre environnement multiconcurrent. Étant donné que l'objet du gestionnaire est partagé entre toutes les tâches, tout état mutable doit être adapté aux threads. Cela inclut les collections, les connexions aux bases de données et tous les objets statiques modifiés lors du traitement des demandes.
AWS Les clients du SDK sont compatibles avec les threads et ne nécessitent aucune manipulation particulière.
**Exemple : pools de connexions aux bases de données**
Le code suivant utilise un objet de connexion à une base de données statique qui est partagé entre des demandes simultanées. L'`SqlConnection`objet n'est pas compatible avec les threads.
```
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();
...
}
}
```
Pour résoudre ce problème, utilisez une connexion distincte pour chaque demande, issue d'un pool de connexions. Les fournisseurs ADO.NET prennent en charge `Microsoft.Data.SqlClient` automatiquement le regroupement de connexions lorsque l'objet de connexion est ouvert.
```
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();
...
}
}
```
**Exemple : Collections**
Les collections .NET standard ne sont pas adaptées aux threads :
```
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";
}
}
```
Utilisez les collections de l'espace de `System.Collections.Concurrent` noms pour des raisons de sécurité en matière de concurrence :
```
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";
}
}
```
## Répertoire /tmp partagé
Le `/tmp` répertoire est partagé entre toutes les demandes simultanées dans l'environnement d'exécution. Les écritures simultanées dans le même fichier peuvent entraîner une corruption des données, par exemple si une autre demande remplace le fichier. Pour résoudre ce problème, implémentez le verrouillage des fichiers partagés ou utilisez des noms de fichiers uniques par demande afin d'éviter les conflits. N'oubliez pas de nettoyer les fichiers inutiles pour ne pas épuiser l'espace disponible.
## Logging
L'entrelacement des journaux (les entrées des journaux provenant de différentes demandes sont entrelacées dans des journaux) est normal dans les systèmes multiconcurrents. Les fonctions utilisant des instances gérées Lambda utilisent toujours le format de journal JSON structuré introduit avec les contrôles de [journalisation avancés](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Ce format inclut le`requestId`, ce qui permet de corréler les entrées du journal à une seule demande. Lorsque vous utilisez l'`context.Logger`objet pour générer des journaux, ceux-ci `requestId` sont automatiquement inclus dans chaque entrée de journal. Pour de plus amples informations, voir[Utilisation des contrôles de journalisation avancés de Lambda avec .NET](csharp-logging.md#csharp-logging-advanced).
## Contexte de la requête
Utilisez la `context.AwsRequestId` propriété pour accéder à l'ID de demande pour la demande en cours.
Utilisez la `context.TraceId` propriété pour accéder au X-Ray Trace ID. Cela fournit un accès simultané à l'ID de trace pour la demande en cours. Lambda ne prend pas en charge la variable d'`_X_AMZN_TRACE_ID`environnement avec les instances gérées par Lambda. Le X-Ray Trace ID est automatiquement propagé lors de l'utilisation du AWS SDK.
`ILambdaContext.RemainingTime`À utiliser pour détecter les délais d'expiration. Pour plus d’informations, consultez [Gestion des erreurs et restauration](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Initialisation et arrêt
L'initialisation de la fonction a lieu une fois par environnement d'exécution. Les objets créés lors de l'initialisation sont partagés entre les demandes.
Pour les fonctions Lambda avec extensions, l'environnement d'exécution émet un signal SIGTERM lors de l'arrêt. Ce signal est utilisé par les extensions pour déclencher des tâches de nettoyage, telles que le vidage des tampons. Vous pouvez vous abonner aux événements SIGTERM pour déclencher des tâches de nettoyage des fonctions, telles que la fermeture des connexions aux bases de données. Pour en savoir plus sur le cycle de vie de l'environnement d'exécution, veuillez consulter [Comprendre le cycle de vie de l’environnement d’exécution Lambda](lambda-runtime-environment.md).
## Versions de dépendance
Les instances gérées Lambda nécessitent les versions de package minimales suivantes :
+ Amazon.Lambda.Core : version 2.7.1 ou ultérieure
+ Amazon Lambda. RuntimeSupport: version 1.14.1 ou ultérieure
+ OpenTelemetry.Instrumentation. AWSLambda: version 1.14.0 ou ultérieure
+ AWSXRayRecorder.Core : version 2.16.0 ou ultérieure
+ AWSSDK.Core : version 4.0.0.32 ou ultérieure
## Outils électriques pour AWS Lambda (.NET)
[Powertools for AWS Lambda (.NET](https://docs.aws.amazon.com/powertools/dotnet/)) [AWS et Distro OpenTelemetry for - Instrumentation DotNet for](https://github.com/aws-observability/aws-otel-dotnet-instrumentation) ne prennent actuellement pas en charge les instances gérées par Lambda.
## Étapes suivantes
+ Passez en revue l'[environnement d'exécution Java pour les instances gérées Lambda](lambda-managed-instances-java-runtime.md)
+ Passez en revue [le runtime Node.js pour les instances gérées Lambda](lambda-managed-instances-nodejs-runtime.md)
+ Passez [en revue le runtime Python pour les instances gérées Lambda](lambda-managed-instances-python-runtime.md)
+ En savoir plus sur le [dimensionnement des instances gérées Lambda](lambda-managed-instances-scaling.md)
# Support Rust pour les instances gérées Lambda
## Configuration de la simultanéité
Le nombre maximum de demandes simultanées que Lambda envoie à chaque environnement d'exécution est contrôlé par le `PerExecutionEnvironmentMaxConcurrency` paramètre de configuration de la fonction. Il s'agit d'un paramètre facultatif, et la valeur par défaut pour Rust est de 8 requêtes simultanées par vCPU, ou vous pouvez configurer votre propre valeur. Cette valeur détermine le nombre de tâches Tokio générées par le moteur d'exécution et est statique pendant toute la durée de vie de l'environnement d'exécution. Chaque travailleur traite exactement une demande en vol à la fois, sans multiplexage par travailleur. Lambda ajuste automatiquement le nombre de demandes simultanées jusqu'au maximum configuré en fonction de la capacité de chaque environnement d'exécution à absorber ces demandes.
## Création de fonctions pour la multisimultanéité
Vous devez appliquer les mêmes pratiques de sécurité des threads lorsque vous utilisez des instances gérées Lambda que dans tout autre environnement multithread. Étant donné que l'objet du gestionnaire est partagé entre tous les threads de travail, tout état mutable doit être sûr pour les threads. Cela inclut les collections, les connexions aux bases de données et tous les objets statiques modifiés lors du traitement des demandes.
Pour activer le traitement des demandes simultanées, ajoutez l'indicateur de `concurrency-tokio` fonctionnalité à votre `Cargo.toml` fichier.
```
[dependencies]
lambda_runtime = { version = "1", features = ["concurrency-tokio"] }
```
Le point `lambda_runtime::run_concurrent(…)` d'entrée doit être appelé depuis un environnement d'exécution Tokio, généralement fourni par l'`#[tokio::main]`attribut de votre fonction principale. La fermeture de votre gestionnaire doit implémenter [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). Cela permet au framework de partager votre gestionnaire entre plusieurs tâches asynchrones en toute sécurité. Si ces limites ne sont pas respectées, votre code ne sera pas compilé.
Lorsque vous avez besoin d'un état partagé entre les invocations (un pool de base de données, une structure de configuration), intégrez-le [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html)et clonez-le dans chaque appel`Arc`.
Tous les AWS SDK pour les clients Rust sont sécurisés en matière de concurrence et ne nécessitent aucune manipulation particulière.
### Exemple : AWS client SDK
L'exemple suivant utilise un client S3 pour télécharger un objet à chaque appel. Le client est cloné directement dans la fermeture sans `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
```
### Exemple : pools de connexions aux bases de données
Lorsque votre gestionnaire a besoin d'accéder à un état partagé tel qu'un client et une configuration, intégrez-le [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html)et clonez-le à chaque appel : `Arc`
```
#[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
```
## Répertoire /tmp partagé
Le `/tmp` répertoire est partagé entre toutes les invocations simultanées dans le même environnement d'exécution. Utilisez des noms de fichiers uniques par appel (par exemple, incluez l'ID de demande) ou implémentez un verrouillage de fichier explicite pour éviter la corruption des données.
## Logging
L'entrelacement des journaux (les entrées des journaux provenant de différentes demandes sont entrelacées dans des journaux) est normal dans les systèmes multiconcurrents. [Les fonctions utilisant des instances gérées Lambda prennent en charge le format de journal JSON structuré via les commandes de journalisation avancées de Lambda.](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) Ce format inclut le`requestId`, ce qui permet de corréler les entrées du journal à une seule demande. Pour de plus amples informations, voir[Implémentation de la journalisation avancée avec la caisse Tracing](rust-logging.md#rust-logging-tracing).
## Contexte de la demande
L'`Context`objet est transmis directement à chaque appel de gestionnaire. Permet `event.context.request_id` d'accéder à l'ID de demande pour la demande en cours.
`event.context.xray_trace_id`À utiliser pour accéder au X-Ray Trace ID. Lambda ne prend pas en charge la variable d'`_X_AMZN_TRACE_ID`environnement avec les instances gérées par Lambda. L'identifiant de trace X-Ray est propagé automatiquement lors de l'utilisation du AWS SDK pour Rust.
`event.context.deadline`À utiliser pour détecter les délais d'invocation : il contient le délai d'invocation en millisecondes.
## Initialisation et arrêt
L'initialisation de la fonction a lieu une fois par environnement d'exécution. Les objets créés lors de l'initialisation sont partagés entre les demandes.
Pour les fonctions Lambda avec extensions, l'environnement d'exécution émet un signal SIGTERM lors de l'arrêt. Ce signal est utilisé par les extensions pour déclencher des tâches de nettoyage, telles que le vidage des tampons. `lambda_runtime`propose une aide pour simplifier la configuration de la gestion progressive des signaux d'arrêt,. [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) Pour en savoir plus sur le cycle de vie de l'environnement d'exécution, veuillez consulter [Comprendre le cycle de vie de l’environnement d’exécution Lambda](lambda-runtime-environment.md).
## Versions de dépendance
Les instances gérées Lambda nécessitent la version minimale du package suivante :
+ `lambda_runtime`: version 1.1.1 ou ultérieure, avec la `concurrency-tokio` fonctionnalité activée
+ La version minimale de Rust prise en charge (MSRV) est 1.84.0.