Comprendre le cycle de vie de l'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.

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

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.

Rubriques

• Phase d’initialisation

• Échecs pendant la phase d’initialisation

• Phase de restauration (Lambda uniquement SnapStart )

• Phase d’invocation

• Échecs pendant la phase d’invocation

• Phase d’arrêt

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 d'exécution avant le point de contrôle (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’environnement d’exécution avant le point de contrôle, le code s’exécute alors à 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 le INIT_REPORT journal que si la simultanéité SnapStartprovisionnée est activée. SnapStart et les fonctions de simultanéité provisionnées émettent toujours. INIT_REPORT Pour de plus amples informations, veuillez consulter 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 disposez d'un hook d'exécution après restauration, le code s'exécute à la fin de la Restore phase. Vous êtes facturé pour la durée des hooks d'exécution après la restauration. Le runtime doit se charger et les hooks d'exécution après restauration doivent être terminés 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.

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

  Note

  AWS met actuellement en œuvre des modifications du service Lambda. En raison de ces modifications, vous pouvez constater des différences mineures entre la structure et le contenu des messages du journal système et des segments de suivi émis par les différentes fonctions Lambda de votre Compte AWS.

  Si la configuration du journal système de votre fonction est définie sur du texte brut, cette modification affecte les messages de journal capturés dans CloudWatch les journaux lorsque votre fonction rencontre un échec d'appel. Les exemples suivants montrent les sorties des journaux dans les anciens et les nouveaux formats.

  Ces modifications seront mises en œuvre au cours des prochaines semaines, et toutes les fonctions, Régions AWS sauf en Chine et dans les GovCloud régions, seront transférées pour utiliser le nouveau format des messages de journal et des segments de trace.

  Exemple CloudWatch Journalise la sortie du journal (exécution ou crash de l'extension) - ancien style

  START RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Version: $LATEST
  RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Error: Runtime exited without providing a reason
  Runtime.ExitError
  END RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1
  REPORT RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Duration: 933.59 ms Billed Duration: 934 ms Memory Size: 128 MB Max Memory Used: 9 MB

  Exemple CloudWatch Enregistre la sortie du journal (délai d'expiration de la fonction) - ancien style

  START RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Version: $LATEST
  2024-03-04T17:22:38.033Z b70435cc-261c-4438-b9b6-efe4c8f04b21 Task timed out after 3.00 seconds
  END RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21
  REPORT RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Duration: 3004.92 ms Billed Duration: 3000 ms Memory Size: 128 MB Max Memory Used: 33 MB Init Duration: 111.23 ms

  Le nouveau format des CloudWatch journaux inclut un status champ supplémentaire dans la REPORT ligne. Dans le cas d’un incident d’exécution ou d’extension, la ligne REPORT inclut également un champ ErrorType.

  Exemple CloudWatch Journalise la sortie du journal (exécution ou crash de l'extension) - nouveau style

  START RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Version: $LATEST
  END RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd
  REPORT RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Duration: 133.61 ms Billed Duration: 133 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 80.00 ms Status: error Error Type: Runtime.ExitError

  Exemple CloudWatch Enregistre la sortie du journal (délai d'expiration de la fonction) - nouveau style

  START RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Version: $LATEST
  END RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda
  REPORT RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Duration: 3016.78 ms Billed Duration: 3016 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 84.00 ms Status: timeout

• 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 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. 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.

Limite de durée : la durée maximale de la phase Shutdown dépend de la configuration des extensions enregistrées :

• 0 ms : fonction sans extension enregistrée

• 500 ms : fonction avec une extension interne enregistrée.

• 2 000 ms : fonction avec une ou plusieurs extensions externes enregistrées.

Si l’environnement d’exécution ou une extension ne répondent pas à l’événement Shutdown dans cette limite de temps, Lambda met fin au processus à l’aide d’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’environnement d’exécution, même pour les fonctions invoquées en continu. Vous ne devez pas partir du principe que l’environnement d’exécution sera conservé indéfiniment. Pour de plus amples informations, veuillez consulter Intégrer l'apatridie dans les fonctions.

Lorsque la fonction est à nouveau invoquée, Lambda décongèle l'environnement pour le réutiliser. 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.

Démarrages à froid et latence

Lorsque Lambda reçoit une demande pour exécuter une fonction via l'API Lambda, le service prépare d'abord un environnement d'exécution. Au cours de cette phase d'initialisation, le service télécharge votre code, démarre l'environnement et exécute tout code d'initialisation en dehors du gestionnaire principal. Enfin, Lambda exécute le code du gestionnaire.

Dans ce schéma, les deux premières étapes du téléchargement du code et de la configuration de l'environnement sont souvent appelées « démarrage à froid ». Ce délai ne vous est pas facturé, mais cela ajoute de la latence à la durée globale de votre invocation.

Une fois l'invocation terminée, l'environnement d'exécution est gelé. Pour améliorer la gestion des ressources et les performances, Lambda conserve l'environnement d'exécution pendant un certain temps. Pendant ce temps, si une autre demande arrive pour la même fonction, Lambda peut réutiliser l'environnement. Cette deuxième demande se termine généralement plus rapidement, car l'environnement d'exécution est déjà entièrement configuré. C’est ce qu’on appelle un « démarrage à chaud ».

Les démarrages à froid se produisent généralement dans moins de 1 % des invocations. La durée d’un démarrage à froid varie de moins de 100 ms à plus d’une seconde. En général, les démarrages à froid sont plus courants dans les fonctions de développement et de test que dans les charges de travail de production. Cela est dû au fait que les fonctions de développement et de test sont généralement invoquées moins fréquemment.

Réduction des démarrages à froid avec la simultanéité provisionnée

Si vous avez besoin d'heures de démarrage des fonctions prévisibles pour votre charge de travail, la simultanéité provisionnée est la solution recommandée pour garantir la latence la plus faible possible. Cette fonctionnalité pré-initialise les environnements d'exécution, réduisant ainsi les démarrages à froid.

Par exemple, une fonction avec une simultanéité provisionnée de 6 possède 6 environnements d'exécution préchauffés.

Optimisation de l’initialisation statique

L’initialisation statique se produit avant que le code du gestionnaire ne commence à s’exécuter dans une fonction. Il s'agit du code d'initialisation que vous fournissez, qui se trouve en dehors du gestionnaire principal. Ce code est souvent utilisé pour importer des bibliothèques et des dépendances, configurer des configurations et initialiser des connexions à d'autres services.

L'exemple Python suivant montre l'importation et la configuration de modules, ainsi que la création du client Amazon S3 pendant la phase d'initialisation, avant que la lambda_handler fonction ne s'exécute pendant l'appel.

import os
import json
import cv2
import logging
import boto3

s3 = boto3.client('s3')
logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):

  # Handler logic...

Le principal facteur de latence avant l'exécution d'une fonction provient du code d'initialisation. Ce code s'exécute lorsqu'un nouvel environnement d'exécution est créé pour la première fois. Le code d’initialisation n’est pas exécuté à nouveau si une invocation utilise un environnement d’exécution chaud. Les facteurs qui influent sur la latence du code d'initialisation sont notamment les suivants :

• la taille du package de fonctions, en termes de bibliothèques et de dépendances importées, et de couches Lambda ;

• la quantité de code et la tâche d’initialisation ;

• la performance des bibliothèques et des autres services lors de la configuration de connexions et d’autres ressources.

Les développeurs peuvent prendre un certain nombre de mesures pour optimiser la latence d'initialisation statique. Si une fonction comporte de nombreux objets et connexions, vous pouvez peut-être réarchitecturer une seule fonction en plusieurs fonctions spécialisées, Ils sont individuellement plus petits et contiennent chacun moins de code d'initialisation.

Il est important que les fonctions n’importent que les bibliothèques et les dépendances dont elles ont besoin. Par exemple, si vous utilisez Amazon DynamoDB uniquement dans AWS le SDK, vous pouvez avoir besoin d'un service individuel au lieu du SDK complet. Voici trois exemples de comparaison :

// Instead of const AWS = require('aws-sdk'), use:
const DynamoDB = require('aws-sdk/clients/dynamodb')

// Instead of const AWSXRay = require('aws-xray-sdk'), use:
const AWSXRay = require('aws-xray-sdk-core')

// Instead of const AWS = AWSXRay.captureAWS(require('aws-sdk')), use:
const dynamodb = new DynamoDB.DocumentClient()
AWSXRay.captureAWSClient(dynamodb.service)

L'initialisation statique est également souvent le meilleur endroit pour ouvrir des connexions à des bases de données afin de permettre à une fonction de réutiliser les connexions via plusieurs invocations dans le même environnement d'exécution. Cependant, il se peut que vous disposiez d’un grand nombre d’objets qui ne sont utilisés que dans certains chemins d’exécution de votre fonction. Dans ce cas, vous pouvez charger de manière différée des variables dans la portée globale afin de réduire la durée d’initialisation statique.

Évitez les variables globales pour obtenir des informations spécifiques au contexte. Si votre fonction possède une variable globale qui n’est utilisée que pendant la durée de vie d’une seule invocation et qui est réinitialisée pour la prochaine invocation, utilisez une portée de variable locale au gestionnaire. Cela permet non seulement d’éviter les fuites de variables globales lors des invocations, mais également d’améliorer les performances d’initialisation statique.