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.

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. 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 .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'SqlConnectionobjet 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<string> items = new List<string>();
    private static Dictionary<string, object> cache = new Dictionary<string, object>();

    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<string> items = new ConcurrentBag<string>();
    private static ConcurrentDictionary<string, object> cache = new ConcurrentDictionary<string, object>();

    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. Ce format inclut lerequestId, ce qui permet de corréler les entrées du journal à une seule demande. Lorsque vous utilisez l'context.Loggerobjet pour générer des journaux, ceux-ci requestId sont automatiquement inclus dans chaque entrée de journal. Pour plus d'informations, consultez la section Utilisation des contrôles de journalisation avancés Lambda avec .NET.

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_IDenvironnement avec les instances gérées par Lambda. Le X-Ray Trace ID est automatiquement propagé lors de l'utilisation du AWS SDK.

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 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, voir Comprendre le cycle de vie de l'environnement d'exécution Lambda.

Versions de dépendance

Les instances gérées Lambda nécessitent les versions de package minimales suivantes :

Outils électriques pour AWS Lambda (.NET)

Powertools for AWS Lambda (.NET) AWS et Distro OpenTelemetry for - Instrumentation DotNet for ne prennent actuellement pas en charge les instances gérées par Lambda.

Étapes suivantes