Appel asynchrone - AWS Lambda

Appel asynchrone

Plusieurs services AWS, comme Amazon Simple Storage Service (Amazon S3) et Amazon Simple Notification Service (Amazon SNS), appellent les fonctions de manière asynchrone pour traiter les événements. Lorsque vous appelez une fonction de manière asynchrone, vous n'attendez pas de réponse de la part du code de la fonction. Vous donnez l'événement à Lambda, et Lambda se charge du reste. Vous pouvez configurer la façon dont Lambda gère les erreurs et envoyer les enregistrements d'appel à une ressource en aval pour regrouper les composants de votre application.

Le diagramme suivant montre des clients qui appellent une fonction Lambda de manière asynchrone. Lambda met les événements en file d'attente avant de les envoyer à la fonction.


      Les clients invoquent une fonction de manière asynchrone. Lambda met en file d'attente les événements avant de les envoyer à la fonction.

Pour un appel asynchrone, Lambda place l'événement dans une file d'attente et renvoie une réponse indiquant sa réussite, sans informations supplémentaires. Un processus distinct lit les événements à partir de la file d'attente et les envoie à votre fonction. Pour appeler une fonction de façon asynchrone, définissez le paramètre du type d'appel sur Event.

$ aws lambda invoke --function-name my-function --invocation-type Event --payload '{ "key": "value" }' response.json { "StatusCode": 202 }

Le fichier de sortie (response.json) ne contient pas d'informations, mais il est tout de même créé lorsque vous exécutez cette commande. Si Lambda n’est pas en mesure d'ajouter l'événement à la file d'attente, le message d'erreur s'affiche dans la sortie de la commande.

Lambda gère la file d'attente d'événements asynchrones de la fonction et effectue de nouvelles tentatives en cas d'erreur. Si la fonction renvoie une erreur, Lambda tente de l'exécuter deux nouvelles fois, avec une minute d’attente entre les deux premières tentatives et deux minutes entre la deuxième et la troisième tentatives. Les erreurs de fonction comprennent des erreurs renvoyées par le code de la fonction et des erreurs renvoyées par l’environnement d'exécution de la fonction, comme les délais d'expiration.


      Lambda enregistre chaque tentative dans un sous-segment.

Si la fonction n'a pas suffisamment de simultanéité disponible pour traiter tous les événements, des demandes supplémentaires sont bloquées. Pour les erreurs de limitation (erreur 429) et les erreurs système (série 500), Lambda renvoie l'événement à la file d'attente et tente d'exécuter la fonction à nouveau pour une durée maximale de 6 heures. L'intervalle de nouvelle tentative augmente de manière exponentielle de 1 seconde après la première tentative jusqu’à un maximum de 5 minutes. Toutefois, il peut être plus long si la file d'attente est sauvegardée. Lambda réduit également le débit de lecture des événements à partir de la file d'attente.

L'exemple suivant montre un événement qui a été ajouté avec succès à la file d'attente, mais qui est toujours en attente une heure plus tard en raison de la limitation.


      Les demandes bloquées en attente apparaîtront en attente dans AWS X-Ray.

Même si votre fonction ne renvoie pas d’erreur, elle peut recevoir le même événement plusieurs fois à partir de Lambda, car la file d'attente elle-même est cohérente. Si la fonction ne peut pas à prendre en charge les événements entrants, ils peuvent également être supprimés de la file d'attente sans être envoyés à la fonction. Assurez-vous que le code de votre fonction gère correctement les événements dupliqués et que vous avez suffisamment de simultanéité disponible pour gérer tous les appels.

Lorsque la file d'attente est sauvegardée, les nouveaux événements peuvent expirer avant qu'Lambda n'ait la possibilité de les envoyer à votre fonction. Lorsqu'un événement expire ou échoue à toutes les tentatives de traitement, Lambda le rejette. Vous pouvez configurer la gestion des erreurs pour une fonction afin de réduire le nombre de nouvelles tentatives effectuées par Lambda, ou pour supprimer les événements non traités plus rapidement.

Vous pouvez également configurer Lambda pour envoyer un enregistrement d'appel à un autre service. Lambda prend en charge les destinations suivantes pour l'appel asynchrone.

  • Amazon SQS – File d'attente SQS standard.

  • Amazon SNS – Rubrique SNS.

  • AWS Lambda – Fonction Lambda.

  • Amazon EventBridge – Bus d’événements EventBridge.

L'enregistrement d'appel contient des détails sur la demande et la réponse au format JSON. Vous pouvez configurer des destinations distinctes pour les événements dont le traitement échoue et ceux dont le traitement aboutit. Vous pouvez également configurer une file d'attente SQS ou une rubrique SNS en tant que file d'attente de lettres mortes pour les événements ignorés. Pour les files d'attente de lettres mortes, Lambda envoie uniquement le contenu de l'événement, sans informations supplémentaires sur la réponse.

Configuration de la gestion des erreurs pour les appels asynchrones

Utilisez la console Lambda pour configurer les paramètres de gestion des erreurs sur une fonction, une version ou un alias.

Pour configurer la gestion des erreurs

  1. Ouvrez la page Fonctions de la console Lambda.

  2. Choisissez une fonction.

  3. Sous Asynchronous invocation (Appel asynchrone), choisissez Edit (Modifier).

  4. 以下を設定します。

    • Maximum age of event (Âge maximal de l'événement) – Durée maximale pendant laquelle Lambda conserve un événement dans la file d'attente d'événements asynchrones (jusqu’à 6 heures).

    • Retry attempts (Nouvelles tentatives) – Nombre de nouvelles tentatives effectuées par Lambda lorsque la fonction renvoie une erreur (entre 0 et 2).

  5. Choisissez Enregistrer.

Lorsqu'un événement d'appel dépasse l'âge maximal ou échoue une fois le nombre maximal de tentatives atteint, Lambda le rejette. Pour conserver une copie des événements supprimés, configurez une destination en cas d'échec.

Configuration des destinations pour les appels asynchrones

Pour envoyer des enregistrements d'appel asynchrone à un autre service, ajoutez une destination à votre fonction. Vous pouvez configurer des destinations distinctes pour les événements dont le traitement échoue et ceux dont le traitement aboutit. Comme les paramètres de gestion des erreurs, vous pouvez configurer des destinations au niveau d'une fonction, d'une version ou d'un alias.

L'exemple suivant montre une fonction qui traite les appels asynchrones. Lorsque la fonction renvoie une réponse de réussite ou se termine sans générer d'erreur, Lambda envoie un enregistrement de l'appel à un bus d'événements EventBridge. Lorsqu'un événement échoue pour toutes les tentatives de traitement, Lambda envoie un enregistrement d'appel à une file d'attente Amazon SQS.


        Lambda envoie les enregistrements d'appel à une destination de bus d'événements ou de file d'attente, selon le résultat.

Pour envoyer des événements à une destination, votre fonction a besoin d’autorisations supplémentaires. Ajoutez une stratégie avec les autorisations requises au rôle d’exécution de votre fonction. Chaque service de destination nécessite une autorisation différente, comme suit :

Ajoutez des destinations à votre fonction dans la console Lambda du concepteur de fonctions.

Pour configurer une destination pour des enregistrements d'appel asynchrone

  1. Ouvrez la page Fonctions de la console Lambda.

  2. Choisissez une fonction.

  3. Sous Designer (Concepteur), choisissez Add destination (Ajouter une destination).

  4. Pour Source, choisissez Asynchronous invocation (Appel asynchrone).

  5. Pour Condition choisissez l'une des options suivantes :

    • On failure (En cas d’échec) – Envoyer un enregistrement lorsque l'événement échoue lors de toutes les tentatives de traitement ou dépasse l'âge maximal.

    • On success (En cas de succès) – Envoyer un enregistrement lorsque la fonction traite avec succès un appel asynchrone.

  6. Pour Type de destination, choisissez le type de ressource qui reçoit l'enregistrement d'appel.

  7. Pour Destination, choisissez une ressource.

  8. Choisissez Enregistrer.

Lorsqu'un appel correspond à la condition, Lambda envoie un document JSON avec des détails sur l'appel à la destination. L'exemple suivant illustre un enregistrement d'appel pour un événement dont le traitement a échoué à trois reprises en raison d'une erreur de fonction.

Exemple enregistrement d'appel

{ "version": "1.0", "timestamp": "2019-11-14T18:16:05.568Z", "requestContext": { "requestId": "e4b46cbf-b738-xmpl-8880-a18cdf61200e", "functionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function:$LATEST", "condition": "RetriesExhausted", "approximateInvokeCount": 3 }, "requestPayload": { "ORDER_IDS": [ "9e07af03-ce31-4ff3-xmpl-36dce652cb4f", "637de236-e7b2-464e-xmpl-baf57f86bb53", "a81ddca6-2c35-45c7-xmpl-c3a03a31ed15" ] }, "responseContext": { "statusCode": 200, "executedVersion": "$LATEST", "functionError": "Unhandled" }, "responsePayload": { "errorMessage": "RequestId: e4b46cbf-b738-xmpl-8880-a18cdf61200e Process exited before completing request" } }

L'enregistrement d'appel contient des détails sur l'événement, la réponse et la raison pour laquelle l'enregistrement a été envoyé.

API de configuration d'appel asynchrone

Pour gérer les paramètres d'appel asynchrone avec l’interface de ligne de commande AWS ou AWS SDK, utilisez les opérations d’API suivantes.

Pour configurer l'appel asynchrone avec l'interface de ligne de commande AWS, utilisez la commande put-function-event-invoke-config. L'exemple suivant montre comment configurer une fonction avec un âge d'événement maximal de 1 heure et aucune nouvelle tentative.

$ aws lambda put-function-event-invoke-config --function-name error \ --maximum-event-age-in-seconds 3600 --maximum-retry-attempts 0 { "LastModified": 1573686021.479, "FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:error:$LATEST", "MaximumRetryAttempts": 0, "MaximumEventAgeInSeconds": 3600, "DestinationConfig": { "OnSuccess": {}, "OnFailure": {} } }

La commande put-function-event-invoke-config remplace toute configuration existante sur la fonction, la version ou l'alias. Pour configurer une option sans en réinitialiser d'autres, utilisez update-function-event-invoke-config. L'exemple suivant configure Lambda pour envoyer un enregistrement à une file d'attente SQS nommée destination lorsqu'un événement ne peut pas être traité.

$ aws lambda update-function-event-invoke-config --function-name error \ --destination-config '{"OnFailure":{"Destination": "arn:aws:sqs:us-east-2:123456789012:destination"}}' { "LastModified": 1573687896.493, "FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:error:$LATEST", "MaximumRetryAttempts": 0, "MaximumEventAgeInSeconds": 3600, "DestinationConfig": { "OnSuccess": {}, "OnFailure": { "Destination": "arn:aws:sqs:us-east-2:123456789012:destination" } } }

Files d'attente de lettres mortes de fonction AWS Lambda

Comme alternative à une destination réservée aux échecs, vous pouvez configurer votre fonction avec une file d'attente de lettres mortes pour enregistrer les événements ignorés en vue d'un traitement ultérieur. Une file d'attente de lettres mortes agit de la même manière qu'une destination réservée aux échecs en ce sens qu'elle est utilisée lorsqu'un événement échoue à toutes les tentatives de traitement ou expire sans être traité. Toutefois, une file d'attente de lettres mortes fait partie d'une configuration spécifique à la version de la fonction. Elle est donc verrouillée lorsque vous publiez une version. Les destinations réservées aux échecs prennent également en charge des cibles supplémentaires et incluent des détails sur la réponse de la fonction dans l'enregistrement d'appel.

Si vous n'avez pas de file d'attente ou de rubrique, créez-en une. Choisissez le type de cible qui correspond à votre cas d'utilisation.

Pour envoyer des événements à une file d'attente ou une rubrique, votre fonction a besoin d’autorisations supplémentaires. Ajoutez une stratégie avec les autorisations requises au rôle d’exécution de votre fonction.

Si la file d'attente ou la rubrique cible est chiffrée avec une clé gérée par le client, le rôle d'exécution doit également être un utilisateur dans la stratégie basée sur les ressources de la clé.

Après avoir créé la cible et mis à jour votre rôle d'exécution de la fonction, ajoutez la file d'attente de lettres mortes à votre fonction. Vous pouvez configurer plusieurs fonctions pour envoyer des événements à la même cible.

Configuration d'une file d'attente de lettres mortes

  1. Ouvrez la page Fonctions de la console Lambda.

  2. Choisissez une fonction.

  3. Sous Asynchronous invocation (Appel asynchrone), choisissez Edit (Modifier).

  4. Définissez DLQ resource (Ressource DLQ) sur Amazon SQS ou Amazon SNS.

  5. Choisissez la file d'attente ou la rubrique cible.

  6. Choisissez Save.

Pour configurer une file d'attente de lettres mortes avec la AWS CLI, utilisez la commande update-function-configuration.

$ aws lambda update-function-configuration --function-name my-function \ --dead-letter-config TargetArn=arn:aws:sns:us-east-2:123456789012:my-topic

Lambda envoie l'événement à la file d'attente de lettres mortes en l'état, avec des informations supplémentaires dans les attributs. Vous pouvez utiliser ces informations pour identifier l'erreur que la fonction a renvoyée ou établir une corrélation entre l'événement et des journaux ou une trace AWS X-Ray.

Attributs de message de file d'attente de lettres mortes

  • RequestID (Chaîne) – ID de la demande d'appel. Les ID de demande apparaissent dans les journaux de la fonction. Vous pouvez également utiliser le kit de développement logiciel X-Ray pour enregistrer l'ID de demande sur un attribut dans le suivi. Vous pouvez ensuite rechercher des traces par ID de demande dans la console X-Ray. Consultez l’exemple de processeur d'erreur.

  • ErrorCode (Nombre) – Le code d'état HTTP.

  • ErrorMessage (Chaîne) – Le premier Ko du message d'erreur.


      Attributs d'événement de file d'attente de lettres mortes dans la console Amazon SQS.

Si Lambda ne peut pas envoyer un message à la file d'attente de lettres mortes, il supprime l'événement et émet la métrique DeadLetterErrors. Cela peut se produire en raison d'un manque d'autorisations ou si la taille totale du message est supérieure à la limite de la file d'attente cible ou rubrique. Par exemple, si une notification Amazon SNS avec un corps proche de 256 KB déclenche une fonction qui génère une erreur, le message peut dépasser la taille maximale autorisée dans la file d'attente de lettres mortes en raison des données d'événement supplémentaires ajoutées par Amazon SNS, combinées aux attributs ajoutés par Lambda.

Si vous utilisez Amazon SQS comme source d'événement, configurez une file d'attente de lettres mortes sur la file d'attente Amazon SQS elle-même et non sur la fonction Lambda. Pour plus d'informations, consultez Utilisation de AWS Lambda avec Amazon SQS.