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.
Bonnes pratiques pour la mise en œuvre de réponses partielles par lots
Cette section fournit les meilleures pratiques pour configurer des réponses partielles par lots pour les sources d'événements Amazon SQS.
-
Configurez une file d'attente de lettres mortes pour éviter de créer un anti-modèle snowball dans l'architecture de votre application sans serveur. Pour plus d’informations, consultez la section Éviter les anti-modèles snowball.
-
Configurez le mappage des sources d'événements de votre fonction Lambda pour que seuls les messages ayant échoué soient visibles. Pour ce faire, ajoutez des éléments ReportBatchItemFailuresà la FunctionResponseTypesliste lorsque vous configurez le mappage des sources d'événements. Votre fonction Lambda, lorsqu'elle est invoquée par SQS, doit implémenter des réponses par lots partielles. Pensez à utiliser l'utilitaire Powertools for AWS Lambda Batch Processing, qui traite les messages SQS avec prise en charge intégrée des lots partiels.
Traitement par lots
-
Implémentez des réponses partielles par lots dans votre fonction Lambda invoquée par SQS. Pensez à utiliser l'utilitaire Powertools for AWS Lambda Batch Processing. Cet utilitaire gère le traitement des messages SQS avec prise en charge intégrée des réponses partielles par lots. Pour plus d'informations, consultez la section Signalement des défaillances d'éléments par lots pour les fonctions Lambda à l'aide d'un déclencheur Amazon SQS dans AWS Lambda le manuel du développeur.
Utilitaire Powertools for AWS Lambda Batch Processing
Idempotence
-
Définissez le nombre de fois que vous souhaitez qu'un message soit remis à la file d'attente source avant d'être déplacé vers la file d'attente de lettres mortes. Assurez-vous que la valeur que vous définissez correspond au cas d'utilisation de votre application en identifiant les causes les plus probables de défaillance et leurs délais de restauration estimés. Pour définir le nombre de tentatives, configurez la maxReceiveCountvaleur de la file d'attente source. RedrivePolicy Pour plus d'informations, consultez SetQueueAttributesle manuel Amazon SQS API Reference. Consultez également la section Présentation du redrive des files d'attente en lettres mortes d'Amazon Simple Queue Service vers
les files d'attente source. -
Assurez-vous que votre code Lambda est idempotent et qu'il peut gérer les messages plusieurs fois. Pour implémenter l'idempotencie, pensez à utiliser l'utilitaire Powertools for AWS Lambda Idempotency, qui prépare le code d'une fonction pour prendre en charge les tâches individuelles au sein d'un lot Amazon SQS. Commencez par intégrer ReportBatchItemFailuresle mappage des sources à votre événement. Pour plus d'informations, consultez Implémentation de réponses partielles par lots dans le manuel du AWS Lambda développeur et Comment puis-je empêcher un message Amazon SQS d'appeler ma fonction Lambda
plusieurs fois ?
Utilitaire Powertools for AWS Lambda Idempotency
Métriques
-
Pour intégrer des indicateurs commerciaux dans votre fonction afin de suivre les détails des tâches et les tâches échouées, pensez à utiliser aws-embedded-metricsl'utilitaire Powertools for AWS Lambda Metrics, qui émet des mesures opérationnelles et commerciales lors du traitement des événements SQS au format métrique intégré.
Utilitaire Powertools for AWS Lambda Metrics
-
Si vous utilisez une file d'attente First-In-First-Out (FIFO), votre fonction doit arrêter de traiter les messages après le premier échec et renvoyer tous les messages ayant échoué ou non traités. batchItemFailures Cela permet de préserver l'ordre des messages dans votre file d'attente.
Note
Pour suivre les performances globales d'une application qui utilise un traitement par lots partiel, un suivi des performances au niveau du code est nécessaire. Une fois le traitement par lots configuré, les invocations de la fonction Lambda réussissent généralement quel que soit le résultat du traitement.
Éviter les anti-modèles snowball
Lambda et Amazon SQS ne peuvent pas contrôler les messages que les microservices en amont écrivent dans une file d'attente SQS. Si certains messages ne peuvent pas être traités, Lambda renvoie ces messages non traités à la file d'attente SQS source, sauf si une file d'attente séparée contenant des lettres mortes est configurée. Les messages non traités sont ensuite réessayés par la fonction Lambda. S'il n'existe aucune file d'attente contenant des lettres mortes, le nombre de messages non traités renvoyés à la file d'attente Amazon SQS est finalement supérieur au nombre de messages valides de la file d'attente.
Ce type d'antimodèle boule de neige, dans lequel chaque appel Lambda successif aggrave le problème, peut entraîner les problèmes suivants :
-
Mauvaise expérience utilisateur car les tâches prennent plus de temps que d'habitude à traiter ou ne sont pas traitées du tout
-
Coûts accrus proportionnellement à l'augmentation exponentielle du nombre de messages dans la file d'attente Amazon SQS et de nouvelles tentatives de messages
-
Capacité de calcul Lambda réduite pour l'application ou Compte AWS si les demandes d'invocation de la fonction ne sont pas limitées
Pour éviter de créer un anti-schéma boule de neige lors de la configuration de réponses partielles par lots, il est préférable de créer également une file d'attente de lettres mortes. Cette file d'attente distincte peut stocker les messages qui ne sont pas traités correctement et vous aider à mieux gérer le cycle de vie des messages non traités de votre application.
Pour plus d'informations, consultez Configurer une file d'attente de lettres mortes à l'aide de la console Amazon SQS dans le manuel du développeur Amazon SQS.
