Création d'un environnement d'exécution personnalisé pour AWS Lambda - AWS Lambda
ExigencesImplémentation du flux de réponses dans un environnement d’exécution personnaliséCréation d'environnements d'exécution personnalisés pour les instances gérées 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.

Création d'un environnement d'exécution personnalisé pour AWS Lambda

Vous pouvez implémenter un AWS Lambda environnement d'exécution dans n'importe quel langage de programmation. Un environnement d’exécution est un programme qui exécute la méthode de gestionnaire d’une fonction Lambda lors de l’invocation de la fonction. Vous pouvez inclure le runtime dans le package de déploiement de votre fonction ou le distribuer dans une couche. Lorsque vous créez la fonction Lambda, choisissez un environnement d’exécution uniquement pour le système d’exploitation (la famille d’exécution provided).

Note

La création d’un environnement d’exécution personnalisé est un cas d’utilisation avancé. Si vous recherchez des informations sur la compilation vers un binaire natif ou sur l'utilisation d'un off-the-shelf environnement d'exécution tiers, consultezQuand utiliser les environnements d’exécution réservés aux systèmes d’exploitation de Lambda.

Pour une présentation détaillée du processus de déploiement d’un environnement d’exécution personnalisé, voir Tutoriel : création d’un environnement d’exécution personnalisé.

Exigences

Les environnements d’exécution personnalisés doivent effectuer certaines tâches d’initialisation et de traitement. Une exécution exécute le code d’installation de la fonction, lit le nom du gestionnaire à partir d’une variable d’environnement et lit les événements d’invocation à partir de l’API d’exécution Lambda. L’environnement d’exécution transmet les données d’événements au gestionnaire de la fonction, et renvoie la réponse du gestionnaire à Lambda.

Tâches d’initialisation

Les tâches d’initialisation sont exécutées une seule fois par instance de la fonction pour préparer l’environnement à la gestion des invocations.

  • Récupérer les paramètres – Lecture des variables d’environnement pour obtenir des détails sur la fonction et l’environnement.

    • _HANDLER – Emplacement du gestionnaire, issu de la configuration de la fonction. Le format standard est file.method, où file est le nom du fichier sans extension et method est le nom d’une méthode ou fonction qui est définie dans le fichier.

    • LAMBDA_TASK_ROOT – Répertoire contenant le code de la fonction.

    • AWS_LAMBDA_RUNTIME_API – Hôte et port de l’API d’exécution.

    Pour obtenir la liste complète des variables disponibles, consultez Variables d’environnement d’exécution définies.

  • Initialiser la fonction – Charger le fichier de gestionnaire et exécuter tout code global ou statique qu’il contient. Les fonctions doivent créer des ressources statiques telles que des clients de kit SDK et des connexions de base de données une seule fois, puis les réutiliser pour plusieurs invocations.

  • Gérer les erreurs : si une erreur se produit, appelez l’API erreur de l’initialisation et quittez immédiatement.

L’initialisation est comptabilisée dans le délai d’attente et la durée d’exécution facturés. Lorsqu’une exécution déclenche l’initialisation d’une nouvelle instance de votre fonction, vous pouvez voir le temps d’initialisation dans les journaux et le suivi AWS X-Ray.

Exemple journal
REPORT RequestId: f8ac1208... Init Duration: 48.26 ms   Duration: 237.17 ms   Billed Duration: 300 ms   Memory Size: 128 MB   Max Memory Used: 26 MB

Traitement des tâches

Pendant son exécution, l’environnement d’exécution utilise l’interface d’environnement d’exécution Lambda pour gérer les événements entrants et signaler des erreurs. Après avoir terminé les tâches d’initialisation, l’environnement d’exécution traite les événements entrants dans une boucle. Dans votre code d’exécution, effectuez les étapes suivantes dans l’ordre.

  • Obtenir un événement – Appeler l’API d’invocation suivante pour obtenir l’événement suivant. Le corps de la réponse contient les données de l’événement. Les en-têtes de la réponse contiennent l’ID de la demande et d’autres informations.

  • Propager l’en-tête de suivi – Obtenir l’en-tête de suivi X-Ray à partir de l’en-tête Lambda-Runtime-Trace-Id dans la réponse de l’API. Définissez la variable d’environnement _X_AMZN_TRACE_ID localement avec la même valeur. Le kit SDK X-Ray utilise cette valeur pour connecter les données de suivi entre les services.

  • Créer un objet de contexte – Créer un objet avec des informations de contexte à partir des variables d’environnement et des en-têtes de la réponse de l’API.

  • Invoquer le gestionnaire de fonctions – Transmettre l’événement et l’objet contexte au gestionnaire.

  • Gérer la réponse – Appeler l’API réponse d’invocation pour afficher la réponse du gestionnaire.

  • Gérer les erreurs : si une erreur se produit, appelez l’API erreur de l’invocation.

  • Nettoyage : libérer les ressources inutilisées, envoyer des données à d’autres services ou accomplir des tâches supplémentaires avant de passer à l’événement suivant.

Entrypoint

Le point d’entrée d’un runtime personnalisé est un fichier exécutable nommé bootstrap. Le fichier d’amorçage peut être l’environnement d’exécution, ou il peut invoquer un autre fichier qui crée le runtime. Si la racine de votre package de déploiement ne contient pas de fichier nommé bootstrap, Lambda recherche le fichier dans les couches de la fonction. Si le fichier bootstrap n’existe pas ou n’est pas exécutable, votre fonction renvoie une erreur Runtime.InvalidEntrypoint au moment de l’invocation.

Voici un exemple de bootstrap fichier qui utilise une version groupée de Node.js pour exécuter un JavaScript environnement d'exécution dans un fichier distinct nomméruntime.js.

Exemple bootstrap
#!/bin/sh
    cd $LAMBDA_TASK_ROOT
    ./node-v11.1.0-linux-x64/bin/node runtime.js

Implémentation du flux de réponses dans un environnement d’exécution personnalisé

Pour les fonctions de streaming de réponses, les points de terminaison response et error ont un comportement légèrement modifié qui permet à l’exécution de diffuser des réponses partielles au client et de renvoyer les charges utiles par morceaux. Pour plus d’informations sur le comportement spécifique, consultez ce qui suit :

  • /runtime/invocation/AwsRequestId/response : propage l’en-tête Content-Type de l’environnement d’exécution pour l’envoyer au client. Lambda renvoie la charge utile de la réponse en morceaux via l’encodage de transfert en bloc HTTP/1.1. Le flux de réponse peut avoir une taille maximale de 20 Mio. Pour envoyer le flux de réponse à Lambda, l’environnement d’exécution doit :

    • Définir l’en-tête HTTP Lambda-Runtime-Function-Response-Mode sur streaming.

    • Définissez l’en-tête Transfer-Encoding sur chunked.

    • Écrire la réponse conformément à la spécification d’encodage de transfert en bloc HTTP/1.1.

    • Fermer la connexion sous-jacente après avoir écrit la réponse avec succès.

  • /runtime/invocation/AwsRequestId/error : l’exécution peut utiliser ce point de terminaison pour signaler des erreurs de fonction ou d’exécution à Lambda, qui accepte également l’en-tête Transfer-Encoding. Ce point de terminaison ne peut être appelé qu’avant que l’environnement d’exécution ne commence à envoyer une réponse à l’invocation.

  • Signaler les erreurs en cours de diffusion à l’aide des en-têtes de suivi d’erreur dans /runtime/invocation/AwsRequestId/response. Pour signaler les erreurs qui se produisent après que l’exécution commence à écrire la réponse à l’invocation, l’exécution peut optionnellement attacher des en-têtes de fin HTTP nommés Lambda-Runtime-Function-Error-Type et Lambda-Runtime-Function-Error-Body. Lambda considère cette réponse comme une réponse réussie et transmet les métadonnées d’erreur que l’exécution fournit au client.

    Note

    Pour joindre des en-têtes de fin, l’environnement d’exécution doit définir la valeur de l’en-tête Trailer au début de la demande HTTP. C’est une exigence de la spécification de l’encodage de transfert en bloc HTTP/1.1.

    • Lambda-Runtime-Function-Error-Type : le type d’erreur que l’exécution a rencontré. Cet en-tête se compose d’une valeur de chaîne. Lambda accepte n'importe quelle chaîne, mais nous recommandons un format de. <category.reason> Par exemple, Runtime.APIKeyNotFound.

    • Lambda-Runtime-Function-Error-Body : informations encodées en Base64 sur l’erreur.

Création d'environnements d'exécution personnalisés pour les instances gérées Lambda

Les instances gérées Lambda utilisent la même API d'exécution que les fonctions Lambda (par défaut). Cependant, il existe des différences majeures dans la manière dont les environnements d'exécution personnalisés doivent être mis en œuvre pour prendre en charge le modèle d'exécution simultanée des instances gérées.

Gestion des demandes simultanées

La principale différence lors de la création d'environnements d'exécution personnalisés pour les instances gérées est la prise en charge des appels simultanés. Contrairement aux fonctions Lambda (par défaut) où le moteur d'exécution traite un appel à la fois, les instances gérées peuvent traiter plusieurs appels simultanément au sein d'un même environnement d'exécution.

Votre environnement d'exécution personnalisé doit :

  • Support des /next demandes simultanées : le moteur d'exécution peut effectuer plusieurs appels simultanés à l'API d'appel suivante, jusqu'à la limite spécifiée par la variable d'AWS_LAMBDA_MAX_CONCURRENCYenvironnement.

  • Gérer les /response demandes simultanées : plusieurs invocations peuvent appeler simultanément l'API de réponse à l'appel.

  • Mettez en œuvre une gestion des demandes adaptée aux threads : assurez-vous que les appels simultanés n'interfèrent pas les uns avec les autres en gérant correctement les ressources et les états partagés.

  • Utiliser une demande unique IDs : suivez chaque appel séparément à l'aide de l'Lambda-Runtime-Aws-Request-Iden-tête pour faire correspondre les réponses aux demandes correspondantes.

Modèle de mise en œuvre

Un modèle d'implémentation typique pour les environnements d'exécution des instances gérées implique la création de threads de travail ou de processus pour gérer les invocations simultanées :

  1. Lire la limite de simultanéité : lors de l'initialisation, lisez la variable d'AWS_LAMBDA_MAX_CONCURRENCYenvironnement pour déterminer le nombre d'appels simultanés à prendre en charge.

  2. Créer un pool de travailleurs : initialisez un pool de travailleurs (threads, processus ou tâches asynchrones) égal à la limite de simultanéité.

  3. Boucle de traitement des travailleurs — Chaque travailleur indépendamment :

    • Appels /runtime/invocation/next pour obtenir un événement d'invocation

    • Invoque le gestionnaire de fonctions avec les données de l'événement

    • Publie la réponse sur /runtime/invocation/AwsRequestId/response

    • Répète la boucle

Considérations supplémentaires

  • Format de journalisation : les instances gérées ne prennent en charge que le format de journal JSON. Assurez-vous que votre environnement d'exécution respecte la variable d'AWS_LAMBDA_LOG_FORMATenvironnement et utilise uniquement le format JSON. Pour de plus amples informations, veuillez consulter Configuration des formats de journal JSON et en texte brut.

  • Ressources partagées : soyez prudent lorsque vous utilisez des ressources partagées telles que le /tmp répertoire avec des invocations simultanées. Mettez en place des mécanismes de verrouillage appropriés pour éviter les conditions de course.

Pour plus d'informations sur les environnements d'exécution des instances gérées Lambda, consultez. Comprendre l'environnement d'exécution des instances gérées Lambda