Améliorez les fonctions d'événement Lambda à l'aide des extensions Lambda

Vous pouvez utiliser les extensions Lambda pour améliorer vos fonctions d'événement Lambda. Par exemple, utilisez les extensions Lambda pour intégrer les fonctions d'événement à vos outils de surveillance, d'observabilité, de sécurité et de gouvernance préférés. Vous pouvez choisir parmi un vaste éventail d’outils fournis par des partenaires AWS Lambda, ou créer vos propres extensions Lambda.

Lambda prend en charge les extensions externes et internes. Une extension externe s'exécute en tant que processus indépendant dans l'environnement d'exécution et continue de s'exécuter une fois que l'appel de la fonction d'événement est entièrement traité. Comme les extensions s'exécutent en tant que processus distincts, vous pouvez les écrire dans une langue différente de celle de la fonction d'événement. Tous les Exécutions de la fonction d'événement Lambda prennent en charge des extensions.

Une extension interne s’exécute dans le cadre du processus de runtime. Votre fonction d'événement accède aux extensions internes à l'aide de scripts wrapper ou de mécanismes en cours de processus tels que. JAVA_TOOL_OPTIONS Pour plus d’informations, consultez Modification de l’environnement d’exécution.

Vous pouvez ajouter des extensions à une fonction d'événement à l'aide de la console Lambda, du AWS Command Line Interface (AWS CLI) ou des services et outils d'infrastructure en tant que code (IaC) tels que CloudFormation, AWS Serverless Application Model (AWS SAM) et Terraform.

Vous êtes facturé pour le temps d’exécution que l’extension consomme (par incréments de 1 ms). Aucun coût n’est facturé pour l’installation de vos propres extensions. Pour obtenir des informations sur la tarification des extensions, consultez Tarification AWS Lambda. Pour obtenir des informations sur la tarification des extensions de partenaires, consultez les sites web de ces partenaires. Consultez AWS Lambda partenaires d'extensions pour obtenir la liste des extensions partenaires officielles.

Rubriques

• Environnement d’exécution

• Impact sur les performances et les ressources

• Permissions

• Configuration des extensions Lambda

• AWS Lambda partenaires d'extensions

• Utilisation de l’API d’extensions Lambda pour créer des extensions

• Accès aux données de télémétrie en temps réel pour les extensions à l’aide de l’API de télémétrie

Environnement d’exécution

Lambda invoque votre fonction d'événement dans un environnement d'exécution, qui fournit un environnement d'exécution sécurisé et isolé. L'environnement d'exécution gère les ressources nécessaires à l'exécution de votre fonction d'événement et fournit un support du cycle de vie pour l'exécution et les extensions de la fonction événementielle.

Le cycle de vie de l’environnement d’exécution comprend les phases suivantes :

• Init : au cours de cette phase, Lambda crée ou libère un environnement d’exécution avec les ressources configurées, télécharge le code pour la fonction et toutes les couches, initialise les extensions, initialise l’exécution et exécute le code d’initialisation de la fonction (code en dehors du gestionnaire principal). La phase Init se produit soit lors de la première invocation, soit avant invocations de fonctions si vous avez activé la simultanéité approvisionnée.

  La phase Init est fractionnée en trois sous-phases : Extension init, Runtime init et Function init. Ces sous-phases garantissent que toutes les extensions et l’exécution accomplissent leurs tâches de configuration avant l’exécution du code de la fonction.

  Lorsque SnapStart est activé, la phase Init se produit lorsque vous publiez une version de la fonction. Lambda enregistre un instantané de l’état de la mémoire et du disque de l’environnement d’exécution initialisé, fait persister l’instantané chiffré et le met en cache pour un accès à faible latence. Si vous avez un hook d’environnement d’exécution avant le point de contrôle, le code s’exécute alors à la fin de la phase Init.

• Restore(SnapStart uniquement) : Lorsque vous appelez une SnapStartfonction pour la première fois et que celle-ci prend de l'ampleur, Lambda reprend les nouveaux environnements d'exécution à partir de l'instantané persistant au lieu d'initialiser la fonction à partir de zéro. Si vous avez un hook d’exécution après restauration, le code s’exécute à la fin de la phase Restore. Vous êtes facturé pour la durée des hooks d’exécution après restauration. L’exécution doit se charger et les hooks d’exécution après restauration doivent se terminer dans le délai imparti (10 secondes). Sinon, vous obtiendrez un SnapStartTimeoutException. Lorsque la phase Restore se termine, Lambda invoque le gestionnaire de fonction (Phase d’invocation).

• Invoke : au cours de cette phase, Lambda invoque le gestionnaire de la fonction. Une fois l’exécution de la fonction terminée, Lambda se prépare à gérer une autre invocation de fonction.

• Shutdown: cette phase se déclenche si la fonction Lambda ne reçoit aucune invocation pendant un certain temps. Au cours de la phase Shutdown, Lambda arrête l’exécution, alerte les extensions pour les laisser s’arrêter proprement, puis supprime l’environnement. Lambda envoie à chaque extension un événement Shutdown indiquant que l’environnement est sur le point d’être arrêté.

Au cours de la phase Init, Lambda extrait des couches contenant des extensions dans le répertoire /opt dans l’environnement d’exécution. Lambda recherche des extensions dans le répertoire /opt/extensions/, interprète chaque fichier comme un fichier d’amorçage exécutable pour le lancement de l’extension, puis démarre toutes les extensions en parallèle.

Impact sur les performances et les ressources

La taille des extensions de votre fonction événementielle est prise en compte dans la limite de taille du package de déploiement. Pour une archive de fichier .zip, la taille totale décompressée de la fonction d'événement et de toutes les extensions ne peut pas dépasser la limite de taille du package de déploiement décompressé de 250 Mo.

Les extensions peuvent avoir un impact sur les performances de votre fonction d'événement car elles partagent les ressources de la fonction d'événement telles que le processeur, la mémoire et le stockage. Par exemple, si une extension effectue des opérations de calcul intensives, la durée d'exécution de votre fonction événementielle peut augmenter.

Chaque extension doit terminer son initialisation avant que Lambda n'appelle la fonction d'événement. Par conséquent, une extension qui consomme un temps d'initialisation important peut augmenter la latence de l'invocation de la fonction d'événement.

Pour mesurer le temps supplémentaire nécessaire à l'extension après l'exécution de la fonction d'événement, vous pouvez utiliser la métrique de la PostRuntimeExtensionsDuration fonction. Pour mesurer l’augmentation de la mémoire utilisée, vous pouvez utiliser la métrique MaxMemoryUsed. Pour comprendre l'impact d'une extension spécifique, vous pouvez exécuter différentes versions de vos fonctions événementielles côte à côte.

Note

La métrique MaxMemoryUsed est l’une des métriques collectées par Lambda Insights et non une métrique native Lambda.

Permissions

Les extensions ont accès aux mêmes ressources que les fonctions événementielles. Les extensions étant exécutées dans le même environnement que la fonction d'événement, les autorisations sont partagées entre la fonction d'événement et l'extension.

Pour une archive de fichier .zip, vous pouvez créer un CloudFormation modèle afin de simplifier la tâche consistant à associer la même configuration d'extension, y compris les autorisations Gestion des identités et des accès AWS (IAM), à plusieurs fonctions d'événement.