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.
Recommences pour les fonctions durables de Lambda
Les fonctions durables offrent des fonctionnalités de nouvelle tentative automatique qui rendent vos applications résilientes aux défaillances transitoires. Le SDK gère les nouvelles tentatives à deux niveaux : les nouvelles tentatives par étapes pour les défaillances de la logique métier et les nouvelles tentatives du backend pour les défaillances d'infrastructure.
Étape 2 : nouvelles tentatives
Lorsqu'une exception non détectée se produit au cours d'une étape, le SDK réessaie automatiquement l'étape en fonction de la stratégie de nouvelle tentative configurée. Les nouvelles tentatives d'étape sont des opérations à points de contrôle qui permettent au SDK de suspendre l'exécution et de la reprendre ultérieurement sans perdre la progression.
Comportement des nouvelles tentatives
Le tableau suivant décrit la manière dont le SDK gère les exceptions en quelques étapes :
| Scénario | Qu'est-ce qui se passe | Impact du mesurage |
|---|---|---|
| Exception en phase avec les tentatives de nouvelle tentative restantes | Le SDK crée un point de contrôle pour la nouvelle tentative et suspend la fonction. Lors de l'appel suivant, l'étape recommence avec le délai d'attente configuré. | 1 opération + taille de la charge utile d'erreur |
| Exception en cours d'étape sans aucune tentative de nouvelle tentative | L'étape échoue et génère une exception. Si le code de votre gestionnaire ne détecte pas cette exception, l'exécution complète échoue. | 1 opération + taille de la charge utile d'erreur |
Lorsqu'une étape doit être réessayée, le SDK vérifie l'état de nouvelle tentative et quitte l'appel Lambda si aucune autre tâche n'est en cours d'exécution. Cela permet au SDK d'implémenter des délais d'attente sans consommer de ressources de calcul. La fonction reprend automatiquement après la période d'arrêt.
Configuration des stratégies de nouvelle tentative par étapes
Configurez des stratégies de nouvelle tentative pour contrôler la manière dont les étapes gèrent les échecs. Vous pouvez spécifier le nombre maximum de tentatives, les intervalles d'attente et les conditions de nouvelle tentative. Pour une référence complète des aides à la stratégie de nouvelle tentative, des préréglages et des stratégies personnalisées, voir Retries dans la documentation du SDK Durable Execution.
Exceptions en dehors des marches
Lorsqu'une exception non détectée se produit dans le code de votre gestionnaire mais en dehors de toute étape, le SDK marque l'exécution comme ayant échoué. Cela garantit que les erreurs dans la logique de votre application sont correctement capturées et signalées.
| Scénario | Qu'est-ce qui se passe | Impact du mesurage |
|---|---|---|
| Exception dans le code du gestionnaire en dehors de toute étape | Le SDK marque l'exécution comme FAILED et renvoie l'erreur. L'exception n'est pas automatiquement réessayée. | Erreur concernant la taille de la charge utile |
Pour activer la nouvelle tentative automatique pour le code sujet aux erreurs, complétez-le en une étape avec une stratégie de nouvelle tentative. Les étapes permettent une nouvelle tentative automatique avec un backoff configurable, tandis que le code en dehors des étapes échoue immédiatement.
Rétentatives d'invocation
Les nouvelles tentatives au niveau d'appel sont gérées différemment selon la manière dont la fonction durable Lambda est tentée d'être invoquée. Le tableau suivant décrit la manière dont les différents types d'invocation peuvent influencer les nouvelles tentatives de niveau d'appel.
| Types d’invocation | Qu'est-ce qui se passe |
|---|---|
| Invocation synchrone | Lambda ne réessaie pas automatiquement l'invocation en cas d'erreur lors de l'exécution durable de la fonction. Les nouvelles tentatives en cas d'échec d'invocation dépendent de la source de l'appel synchrone. Par exemple, à l'aide du AWS SDK, InternalFailure et ThrottlingException sont automatiquement réessayés par défaut. |
| invocation asynchrone | Si l'exécution d'une fonction durable échoue (par exemple, si elle passe au statut FAILED, STOPPED ou TIMED_OUT), Lambda ne réessaie pas l'exécution. Ceci est différent des fonctions Lambda standard, dans lesquelles Lambda réessaie la fonction en cas d'échec d'invocation asynchrone. Le MaximumRetryAttempts paramètre pour les appels asynchrones ne s'applique pas aux exécutions durables. Si vous configurez une file d'attente de lettres mortes (DLQ) pour la fonction, Lambda envoie l'événement déclencheur à la DLQ. |
| ESM (mappage des sources d'événements) | Par défaut, Lambda réessaie l'intégralité du lot jusqu'à ce qu'il réussisse. Pour les sources de flux (DynamoDB et Kinesis), vous pouvez configurer le nombre maximal de tentatives que Lambda effectue lorsque votre fonction renvoie une erreur. Consultez la section « Traitement par lots des mappages de sources d'événements ». Pour Amazon SQS ESM, vous pouvez configurer le nombre maximum de nouvelles tentatives via un DLQ sur la file d'attente Amazon SQS d'origine. Consultez la section Configuration d'Amazon SQS ESM. À titre de meilleure pratique, vous pouvez envisager une DLQ au niveau de la fonction et Lambda envoie l'événement déclencheur défaillant à la DLQ. Voir la fonction DLQ. |
| Déclenchement direct | Cela dépend du « déclencheur ». Par exemple, Lambda traite les fonctions déclenchées par les notifications d'événements Amazon S3 de manière asynchrone. Consultez Traiter les notifications d'événements Amazon SQS avec Lambda. Lambda traite les fonctions déclenchées par les notifications d'événements Amazon SNS de manière asynchrone. Consultez la section Invoquer des fonctions Lambda avec les notifications Amazon SNS. Le comportement des nouvelles tentatives d'invocation asynchrone est indiqué ci-dessus dans l'entrée du tableau « Invocation asynchrone ». Si Amazon SNS ne peut pas atteindre Lambda ou si le message est rejeté, Amazon SNS effectue de nouvelles tentatives à intervalles croissants pendant plusieurs heures. Pour plus de détails, consultes Fiabilité |
Réessais dans le backend
Les nouvelles tentatives du backend se produisent lorsque Lambda rencontre des défaillances d'infrastructure, des erreurs d'exécution ou lorsque le SDK ne peut pas communiquer avec le service d'exécution durable. Lambda réessaie automatiquement ces échecs pour aider vos fonctions durables à se rétablir après des problèmes d'infrastructure transitoires.
Scénarios de nouvelle tentative du backend
Lambda réessaie automatiquement votre fonction lorsqu'il rencontre les scénarios suivants :
-
Erreurs de service internes : lorsque Lambda ou le service d'exécution durable renvoie une erreur 5xx, indiquant un problème de service temporaire.
-
Limitation : lorsque votre fonction est limitée en raison de limites de simultanéité ou de quotas de service.
-
Délais : lorsque le SDK ne parvient pas à atteindre le service d'exécution durable dans le délai imparti.
-
Échec de l'initialisation du bac à sable : lorsque Lambda ne peut pas initialiser l'environnement d'exécution.
-
Erreurs d'exécution : lorsque le moteur d'exécution Lambda rencontre des erreurs extérieures au code de votre fonction, telles que des erreurs de mémoire insuffisante ou des blocages de processus.
-
Erreurs de jeton de point de contrôle non valide : lorsque le jeton de point de contrôle n'est plus valide, généralement en raison de changements d'état côté service.
Le tableau suivant décrit la manière dont le SDK gère ces scénarios :
| Scénario | Qu'est-ce qui se passe | Impact du mesurage |
|---|---|---|
| Erreur d'exécution en dehors du gestionnaire durable (OOM, timeout, crash) | Lambda réessaie automatiquement l'invocation. Le SDK rejoue à partir du dernier point de contrôle, en sautant les étapes terminées. | Erreur : taille de la charge utile + 1 opération par nouvelle tentative |
Erreur de service (5xx) ou délai d'attente lors de l'appel/API CheckpointDurableExecution GetDurableExecutionState |
Lambda réessaie automatiquement l'invocation. Le SDK rejoue depuis le dernier point de contrôle. | Erreur : taille de la charge utile + 1 opération par nouvelle tentative |
Limitation (429) ou jeton de point de contrôle non valide lors de l'appel/des API CheckpointDurableExecution GetDurableExecutionState |
Lambda réessaie automatiquement l'invocation avec un retard exponentiel. Le SDK rejoue depuis le dernier point de contrôle. | Erreur : taille de la charge utile + 1 opération par nouvelle tentative |
Erreur client (4xx, sauf 429 et jeton non valide) lorsque/API CheckpointDurableExecution GetDurableExecutionState |
Le SDK marque l'exécution comme échouée. Aucune nouvelle tentative automatique ne se produit car l'erreur indique un problème permanent. | Erreur concernant la taille de la charge utile |
Les nouvelles tentatives du backend utilisent un backoff exponentiel et se poursuivent jusqu'à ce que la fonction réussisse ou que le délai d'exécution soit atteint. Pendant la rediffusion, le SDK ignore les points de contrôle terminés et poursuit l'exécution depuis la dernière opération réussie, garantissant ainsi que votre fonction n'exécute pas à nouveau le travail terminé.
Réessayez les meilleures pratiques
Suivez ces bonnes pratiques lors de la configuration des stratégies de nouvelle tentative :
-
Configurez des stratégies de nouvelle tentative explicites - Ne vous fiez pas au comportement de nouvelle tentative par défaut en production. Configurez des stratégies de nouvelle tentative explicites avec des tentatives maximales et des intervalles d'attente adaptés à votre cas d'utilisation.
-
Utiliser de nouvelles tentatives conditionnelles - Implémentez une
shouldRetrylogique pour ne réessayer que les erreurs transitoires (limites de débit, délais d'attente) et échouer rapidement en cas d'erreur permanente (échec de validation, introuvable). -
Définissez un nombre maximum de tentatives approprié - Équilibre entre résilience et temps d'exécution. Un trop grand nombre de tentatives peut retarder la détection des défaillances, tandis qu'un nombre trop faible peut entraîner des échecs inutiles.
-
Utiliser la temporisation exponentielle - La temporisation exponentielle réduit la charge sur les services en aval et augmente la probabilité de reprise après des défaillances transitoires.
-
Enveloppez le code sujet aux erreurs en plusieurs étapes - Le code en dehors des étapes ne peut pas être automatiquement réessayé. Enveloppez les appels d'API externes, les requêtes de base de données et les autres opérations sujettes aux erreurs en plusieurs étapes grâce à des stratégies de nouvelle tentative.
-
Surveillez les statistiques relatives aux nouvelles tentatives : suivez les opérations de nouvelle tentative par étapes et les échecs d'exécution sur Amazon CloudWatch afin d'identifier des modèles et d'optimiser les stratégies de nouvelles tentatives.
