Environnement d'exécution AWS Lambda - AWS Lambda

Environnement d'exécution AWS Lambda

Lambda appelle votre fonction dans un environnement d'exécution, qui fournit un environnement de runtime sécurisé et isolé. L'environnement d'exécution gère les ressources nécessaires à l'exécution de votre fonction. L'environnement d'exécution prend également en charge le cycle de vie pour l'exécution de la fonction et pour toutes les extensions externes associées à votre fonction.

Le runtime de la fonction communique avec Lambda à l'aide de l'API de runtime. Les extensions communiquent avec Lambda à l'aide de l'API d'extensions. Les extensions peuvent également recevoir des messages de journaux de la fonction en s'abonnant aux journaux à l'aide de l'API Logs.


      Diagramme d'architecture de l'environnement d'exécution.

Lorsque vous créez votre fonction Lambda, vous spécifiez des informations de configuration, telles que la quantité de mémoire disponible et le temps d'exécution maximal autorisé pour votre fonction. Lambda utilise ces informations pour configurer l'environnement d'exécution.

Le runtime de la fonction et chaque extension externe sont des processus qui s'exécutent dans l'environnement d'exécution. Les autorisations, les ressources, les informations d'identification et les variables d'environnement sont partagées entre la fonction et les extensions.

Cycle de vie de l'environnement d'exécution Lambda

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

  • Init : au cours de cette phase, Lambda crée ou débloque un environnement d'exécution avec les ressources configurées, télécharge le code de la fonction et de toutes les couches, initialise les extensions, initialise le runtime, puis exécute le code d'initialisation de la fonction (le code en dehors du gestionnaire principal). La phase Init se produit lors du premier appel ou avant les appels de fonction si vous avez activé la simultanéité allouée.

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

  • Invoke : au cours de cette phase, Lambda appelle le gestionnaire de fonctions. Une fois l'exécution de la fonction terminée, Lambda se prépare à gérer un autre appel de fonction.

  • Shutdown : cette phase est déclenchée si la fonction Lambda ne reçoit aucun appel pendant un certain temps. Au cours de la phase Shutdown, Lambda met fin au runtime, alerte les extensions pour que celles-ci s'arrêtent proprement, puis supprime l'environnement. Lambda envoie un événement Shutdown à chaque extension, ce qui indique à l'extension que l'environnement est sur le point d'être arrêté.


        La phase Init est suivie d'un ou plusieurs appels de fonction. Lorsqu'il n'y a pas de demande d'appel, Lambda lance la phase SHutdown.

Chaque phase commence par un événement que Lambda envoie au runtime et à toutes les extensions enregistrées. Le runtime et chaque extension signalent la fin de l'opération en envoyant une demande d'API Next. Lambda bloque l'environnement d'exécution lorsque le runtime et chaque extension sont terminés et qu'il n'y a aucun événement en attente.

Phase d'initialisation

Dans la phase Init, Lambda effectue trois tâches :

  • Démarrage de toutes les extensions (Extension init)

  • Amorçage du runtime (Runtime init)

  • Exécution du code statique de la fonction (Function init)

La phase Init se termine lorsque le runtime et toutes les extensions signalent qu'elles sont prêtes en envoyant une demande d'API Next. La phase Init est limitée à 10 secondes. Si les trois tâches ne se terminent pas dans les 10 secondes, Lambda relance la phase Init au moment du premier appel de fonction.

Phase d’appel

Lorsqu'une fonction Lambda est appelée en réponse à une demande d'API Next, Lambda envoie un événement Invoke au runtime et à chaque extension.

Le paramètre d'expiration de la fonction limite la durée de l'ensemble de la phase Invoke. Par exemple, si vous définissez le délai d'expiration de la fonction sur 360 secondes, la fonction et toutes les extensions doivent être terminées dans un délai de 360 secondes. Notez qu'il n'y a pas de phase post-appel indépendante. La durée correspond à la somme de tous les temps d'appel (runtime + extensions) et n'est calculée que lorsque l'exécution de la fonction et de toutes les extensions est terminée.

La phase d'appel prend fin lorsque le runtime et toutes les extensions signalent qu'ils ont terminé en envoyant une demande d'API Next.

En cas d'échec lors de la phase Invoke, Lambda réinitialise l'environnement d'exécution. La réinitialisation se comporte comme un événement Shutdown. Tout d'abord, Lambda arrête le runtime. Lambda envoie ensuite un événement Shutdown à chaque extension externe enregistrée. L'événement comprend le motif de l'arrêt. Si un autre événement Invoke entraîne la réutilisation de cet environnement d'exécution, Lambda initialise le runtime et les extensions dans le cadre de l'appel suivant.


          Ceci est mon image.

Phase d'arrêt

Lorsque Lambda est sur le point d'arrêter le runtime, il envoie un événement Shutdown au runtime et à chaque extension externe. Les extensions peuvent utiliser ce temps pour les tâches de nettoyage final. L'événement Shutdown est une réponse à une demande d'API Next.

Durée : l'ensemble de la phase Shutdown est limitée à 2 secondes. Si le runtime ou une extension ne répond pas, Lambda y met fin via un signal (SIGKILL).

Lorsque la fonction et toutes les extensions ont pris fin, Lambda conserve l'environnement d'exécution pendant un certain temps en prévision d'un autre appel de fonction. En effet, Lambda bloque l'environnement d'exécution. Lorsque la fonction est appelée à nouveau, Lambda réactive l'environnement pour la réutilisation. La réutilisation de l'environnement d'exécution a les conséquences suivantes :

  • Les objets déclarés en dehors de la méthode de gestionnaire de la fonction restent initialisés, ce qui fournit une optimisation supplémentaire lorsque la fonction est appelée à nouveau. Par exemple, si la fonction Lambda établit une connexion de base de données, au lieu de rétablir la connexion, la connexion d'origine est utilisée dans les appels suivants. Nous vous recommandons d'ajouter une logique dans votre code pour vérifier s'il existe une connexion avant d'en créer une nouvelle.

  • Chaque environnement d'exécution fournit 512 MB d'espace disque dans le répertoire /tmp. Le contenu du répertoire est conservé lorsque l'environnement d'exécution est gelé, fournissant ainsi un cache temporaire qui peut servir à plusieurs appels. Vous pouvez ajouter du code pour vérifier si le cache contient les données que vous avez stockées. Pour de plus amples informations sur les limites de taille de déploiement, veuillez consulter Quotas Lambda.

  • Les processus en arrière-plan ou les rappels qui ont été initiés par votre fonction Lambda et qui ne sont pas terminés à la fin de la fonction reprennent si Lambda réutilise l'environnement d'exécution. Assurez-vous que les processus d'arrière-plan ou les rappels dans votre code se terminent avant que l'exécution du code ne prenne fin.

Lorsque vous écrivez le code de la fonction, ne partez pas du principe que Lambda réutilise automatiquement l'environnement d'exécution pour les appels de fonction suivants. D'autres facteurs peuvent obliger Lambda à créer un nouvel environnement d'exécution, ce qui peut entraîner des résultats inattendus, tels que des échecs de connexion à la base de données.