Environnement d’exécution 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.

Environnement d’exécution Lambda

Lambda invoque votre fonction 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. 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.

L’exécution de la fonction communique avec Lambda à l’aide de l’API d’exécution. Les extensions communiquent avec Lambda à l’aide de l’API d’extensions. Les extensions peuvent également recevoir des messages de journal et d’autres télémétries de la fonction en utilisant l’API de télémétrie.

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

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

L’exécution 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 d’un environnement d’exécution Lambda

La phase Init est suivie d’un ou plusieurs invocations de fonction. Lorsqu’il n’y a pas de demande d’invocations, Lambda lance la phase Shutdown.

Chaque phase commence par un événement que Lambda envoie à l’exécution et à toutes les extensions enregistrées. L’exécution et chaque extension indiquent la fin de l’opération en envoyant une demande d’API Next. Lambda gèle l’environnement d’exécution lorsque l’exécution de chaque extension est terminée, et qu’il n’y a pas d’é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 de l’exécution (Runtime init)

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

  • Exécutez tous les hooks beforeCheckpoint d'exécution (Lambda uniquement SnapStart )

La phase Init se termine lorsque l’exécution 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 de la première invocation de fonction avec le délai d’attente de fonction configuré.

Lorsque Lambda 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’exécution beforeCheckpoint, le code s’exécute à la fin de la phase Init.

Note

Le délai d'expiration de 10 secondes ne s'applique pas aux fonctions qui utilisent la simultanéité provisionnée ou. SnapStart Pour la simultanéité et les SnapStart fonctions configurées, votre code d'initialisation peut s'exécuter pendant 15 minutes maximum. Le délai d’attente est de 130 secondes ou le délai d’expiration de la fonction configurée (900 secondes au maximum), la valeur la plus élevée étant retenue.

Lorsque vous utilisez la simultanéité provisionnée, Lambda initialise l’environnement d’exécution lorsque vous configurez les paramètres du PC pour une fonction. Lambda garantit également que les environnements d’exécution initialisés sont toujours disponibles avant les invocations. Vous pouvez constater des écarts entre les phases d’initialisation et d’invocation de votre fonction. En fonction de la configuration d’environnement d’exécution et de mémoire de votre fonction, vous pouvez également constater une variabilité de latence est possible lors de la première invocation dans un environnement d’exécution initialisé.

Pour les fonctions utilisant la simultanéité à la demande, Lambda peut occasionnellement initialiser les environnements d’exécution avant les demandes d’invocation. Lorsque cela se produit, vous pouvez également observer un intervalle de temps inattendu entre les phases d’initialisation et d’invocation de votre fonction. Nous vous recommandons de ne pas dépendre de ce comportement.

Échecs pendant la phase d’initialisation

Si une fonction se bloque ou expire pendant la phase Init, Lambda émet des informations d’erreur dans le journal INIT_REPORT.

Exemple — Journal INIT_REPORT pour le délai d’expiration
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout
Exemple — Journal INIT_REPORT en cas d’échec de l’extension
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash

Si la Init phase est réussie, Lambda n'émet pas le INIT_REPORT journal, sauf s'il est activé. SnapStart SnapStart les fonctions émettent toujoursINIT_REPORT. Pour plus d’informations, consultez Surveillance pour Lambda SnapStart.

Phase de restauration (Lambda uniquement SnapStart )

Lorsque vous appelez une SnapStartfonction pour la première fois et que celle-ci évolue, 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 afterRestore(), le code s’exécute à la fin de la phase Restore. Vous êtes facturé pour la durée des hooks d’exécution afterRestore(). L’exécution (JVM) doit se charger et les hooks d’exécution afterRestore() 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).

Échecs pendant la phase de restauration

Si la phase Restore échoue, Lambda émet des informations d’erreur dans le journal RESTORE_REPORT.

Exemple — Journal RESTORE_REPORT pour le délai d’expiration
RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout
Exemple — Journal RESTORE_REPORT en cas d’échec du hook d’exécution
RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError

Pour plus d’informations sur le journal RESTORE_REPORT, consultez Surveillance pour Lambda SnapStart.

Phase d’invocation

Quand une fonction Lambda est invoquée en réponse à une demande d’API Next, Lambda envoie un événement Invoke à l’exécution 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-invocation indépendante. La durée correspond à la somme de tous les temps d’invocation (exécution + 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’invocation prend fin lorsque l’exécution et toutes les extensions signalent qu’ils ont terminé en envoyant une demande d’API Next.

Échecs pendant la phase d’invocation

Si la fonction Lambda se bloque ou expire pendant la phase Invoke, Lambda réinitialise l’environnement d’exécution. Le diagramme suivant illustre le comportement de l’environnement d’exécution Lambda en cas d’échec de l’invocation :

Dans le diagramme précédent :

  • La première phase est la phase INIT, qui s’exécute sans erreur.

  • La deuxième phase est la phase INVOKE, qui s’exécute sans erreur.

  • À un moment donné, supposons que votre fonction rencontre un échec d’invocation (tel qu’un dépassement de délai de la fonction ou une erreur d’exécution). La troisième phase, intitulée INVOKE WITH ERROR, illustre ce scénario. Lorsque cela se produit, le service Lambda effectue une réinitialisation. La réinitialisation se comporte comme un événement Shutdown. Lambda commence par arrêter l’exécution, puis envoie un événement Shutdown à chaque extension externe enregistrée. L’événement comprend le motif de l’arrêt. Si cet environnement est utilisé pour une nouvelle invocation, Lambda réinitialise l’extension et l’exécution en même temps que l’invocation suivante.

    Note

    La réinitialisation Lambda n’efface pas le contenu /tmp du répertoire avant la phase d’initialisation suivante. Ce comportement est cohérent avec la phase d’arrêt normale.

  • La quatrième phase représente la phase INVOKE qui suit immédiatement un échec de l’invocation. Ici, Lambda initialise à nouveau l’environnement en relançant la phase INIT. Cela s’appelle une init supprimée. Lorsque des initialisations supprimées se produisent, Lambda ne signale pas explicitement une phase d'initialisation supplémentaire dans Logs. CloudWatch Au lieu de cela, vous pouvez remarquer que la durée dans la ligne REPORT inclut une durée INIT supplémentaire + la durée INVOKE. Supposons, par exemple, que les connexions suivantes s'affichent CloudWatch :

    2022-12-20T01:00:00.000-08:00 START RequestId: XXX Version: $LATEST 2022-12-20T01:00:02.500-08:00 END RequestId: XXX 2022-12-20T01:00:02.500-08:00 REPORT RequestId: XXX Duration: 3022.91 ms Billed Duration: 3000 ms Memory Size: 512 MB Max Memory Used: 157 MB

    Dans cet exemple, la différence entre les horodatages REPORT et START est de 2,5 secondes. Cela ne correspond pas à la durée rapportée de 3022,91 millisecondes, car cela ne prend pas en compte l’INIT supplémentaire (init supprimé) que Lambda a effectué. Dans cet exemple, vous pouvez en déduire que la phase INVOKE réelle a duré 2,5 secondes.

    Pour plus d’informations sur ce comportement, vous pouvez utiliser la API de télémétrie Lambda. L’API de télémétrie émet des événements INIT_START, INIT_RUNTIME_DONE et INIT_REPORT avec phase=invoke chaque fois que des inits supprimés se produisent entre les phases d’invocation.

  • La cinquième phase représente la phase SHUTDOWN, qui s’exécute sans erreur.

Phase d’arrêt

Quand Lambda est sur le point d’arrêter l’exécution, il envoie un événement Shutdown à chaque extension externe enregistrée. Les extensions peuvent utiliser ce temps pour les tâches de nettoyage final. L’événement Shutdown est une réponse à une Nextdemande d’API.

Durée : l’ensemble de la phase Shutdown est limitée à 2 secondes. Si l’exécution ou une extension ne répondent 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’une autre invocation de fonction. Cependant, Lambda met fin aux environnements d'exécution toutes les quelques heures pour permettre les mises à jour et la maintenance de l'exécution, même pour les fonctions invoquées en continu. Vous ne devez pas partir du principe que l'environnement d'exécution persistera indéfiniment. Pour plus d’informations, consultez Intégrer l'apatridie dans les fonctions.

Lorsque la fonction est invoqué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 invoquée à nouveau. Par exemple, si votre 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 invocations suivantes. 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 entre 512 Mo et 10 240 Mo, par incréments de 1 Mo 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 invocations. 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 l’exécution 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.

Intégrer l'apatridie dans les fonctions

Lorsque vous écrivez le code de votre fonction Lambda, considérez l'environnement d'exécution comme étant apatride, en supposant qu'il n'existe que pour un seul appel. Lambda met fin aux environnements d'exécution toutes les quelques heures pour permettre les mises à jour et la maintenance de l'exécution, même pour les fonctions invoquées en continu. Initialisez tout état requis (par exemple, récupérer un panier d'achat depuis une table Amazon DynamoDB) lorsque votre fonction démarre. Avant de quitter, apportez des modifications permanentes aux données dans des magasins durables tels qu'Amazon Simple Storage Service (Amazon S3), DynamoDB ou Amazon Simple Queue Service (Amazon SQS). Évitez de vous fier à des structures de données existantes, à des fichiers temporaires ou à des états couvrant plusieurs invocations, tels que des compteurs ou des agrégats. Cela garantit que votre fonction gère chaque appel de manière indépendante.