View a markdown version of this page

Runtime Python pour les instances gérées Lambda - AWS Lambda

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.

Runtime Python pour les instances gérées Lambda

L'environnement d'exécution Lambda utilise plusieurs processus Python pour gérer les demandes simultanées. Chaque demande simultanée s'exécute dans un processus distinct avec son propre espace mémoire et son propre initialisation. Chaque processus traite une demande à la fois, de manière synchrone. Les processus ne partageant pas directement la mémoire, les variables globales, les caches au niveau des modules et les objets singleton sont isolés entre les requêtes simultanées.

Configuration de la simultanéité

Le nombre maximum de requêtes simultanées que Lambda envoie à chaque environnement d'exécution est contrôlé par le PerExecutionEnvironmentMaxConcurrency paramètre de la configuration de la fonction. Il s'agit d'un paramètre facultatif et la valeur par défaut varie en fonction de l'exécution. Pour les environnements d'exécution Python, la valeur par défaut est de 16 requêtes simultanées par processeur virtuel, 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 vous avez une simultanéité élevée, votre empreinte mémoire est importante. 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 multi-simultanéité basé sur les processus, les fonctions Lambda Managed Instances utilisant des environnements d'exécution Python n'accèdent pas aux ressources en mémoire simultanément à 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 de 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 pour é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 de journal provenant de différentes demandes sont entrelacées dans les journaux) est normal dans les systèmes multisimultanés.

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, permettant 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 de journal. Pour plus d'informations, consultez la section Utilisation des contrôles de journalisation avancés Lambda avec Python.

Contexte de la requête

context.aws_request_idUtilisez-le pour 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_IDenvironnement pour accéder à l'ID de X-Ray trace avec les instances gérées Lambda. L'ID de X-Ray trace est automatiquement propagé lors de l'utilisation du AWS SDK.

Utilisez-le context.get_remaining_time_in_millis() pour détecter les délais d'attente. Pour plus d’informations, consultez Gestion des erreurs et restauration.

Exemple : gestion des délais

Vérifiez le temps restant avant chaque unité de travail et arrêtez le traitement avant le déclenchement du timeout. Configurez en BUFFER_MS fonction de la durée prévue de votre prochaine partie de travail.

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"}

Exemple : Propagation des délais aux appels en aval

Lorsque vous passez des appels vers des services en aval, répartissez le temps restant sous forme de délai d'attente pour éviter de vous accrocher à des appels réseau qui dureraient plus longtemps que votre appel. Le SDK boto3 ne prend pas en charge les délais d'expiration par demande sur un client existant. Vous devez donc créer un client avec le délai d'expiration souhaité. Pour les fonctions haut débit, déterminez si un délai d'attente fixe configuré lors de l'initialisation est plus approprié que la création d'un client par demande.

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"}

Initialisation et arrêt

L'initialisation de la fonction se produit une fois par processus. Vous pouvez voir des entrées de journal répétées si votre fonction émet des journaux lors de l'initialisation.

Pour les fonctions Lambda dotées d'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 buffers. Vous pouvez vous abonner aux événements SIGTERM pour déclencher des tâches de nettoyage des fonctions, telles que la fermeture des connexions à la base 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.

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

Outils électriques pour AWS Lambda (Python)

Powertools for AWS Lambda (Python) est compatible avec les instances gérées Lambda et fournit des utilitaires pour la journalisation, le suivi, les métriques, etc. Pour plus d'informations, consultez Powertools for AWS Lambda (Python).

Étapes suivantes