Procédure de traitement par Lambda des enregistrements provenant de sources d’événements basées sur des flux et des files d’attente - 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.

Procédure de traitement par Lambda des enregistrements provenant de sources d’événements basées sur des flux et des files d’attente

Un mappage des sources d’événements est une ressource Lambda qui lit des éléments à partir de services basés sur des flux et des files d’attente et qui invoque une fonction avec des lots d’enregistrements. Dans le cadre d’un mappage des sources d’événements, des ressources appelées sondeurs d’événements interrogent activement les nouveaux messages et invoquent des fonctions. Par défaut, Lambda adapte automatiquement les sondeurs d’événements, mais pour certains types de sources d’événements, vous pouvez utiliser le mode alloué pour contrôler le nombre minimum et maximum de sondeurs d’événements dédiés votre mappage des sources d’événements.

Les services suivants utilisent des mappages des sources d’événements pour invoquer des fonctions Lambda :

Avertissement

Les mappages des sources d’événements Lambda traitent chaque événement au moins une fois, et le traitement des enregistrements peut être dupliqué. Pour éviter les problèmes potentiels liés à des événements dupliqués, nous vous recommandons vivement de rendre votre code de fonction idempotent. Pour en savoir plus, consultez Comment puis-je rendre ma fonction Lambda idempotente ? dans le Centre de connaissances AWS.

Différence entre les mappages de sources d’événements et les déclencheurs directs

Certains Services AWS peuvent invoquer directement des fonctions Lambda à l’aide de déclencheurs. Ces services envoient des événements à Lambda, et la fonction est invoquée aussitôt que l’événement spécifié se produit. Les déclencheurs sont adaptés aux événements discrets et au traitement en temps réel. Lorsque vous créez un déclencheur à l’aide de la console Lambda, celle-ci interagit avec le service AWS correspondant pour configurer la notification d’événement sur ce service. Le déclencheur est en fait stocké et géré par le service qui génère les événements, et non par Lambda. Voici quelques exemples de services qui utilisent des déclencheurs pour invoquer des fonctions Lambda :

Les mappages des sources d’événements sont des ressources Lambda créées et gérées au sein du service Lambda. Les mappages des sources d’événements sont conçus pour traiter de gros volumes de données en streaming ou de messages provenant de files d’attente. Le traitement par lots des enregistrements d’un flux ou d’une file d’attente est plus efficace que le traitement individuel des enregistrements.

Comportement de traitement par lots

Par défaut, un mappage de source d’événements regroupe des enregistrements dans une même charge utile que Lambda envoie à votre fonction. Pour optimiser le comportement du traitement par lots, vous pouvez configurer une fenêtre de traitement par lots (MaximumBatchingWindowInSeconds) et une taille de lot (BatchSize). Une fenêtre de traitement par lots représente l’intervalle de temps maximal pour collecter des enregistrements dans une même charge utile. La taille d’un lot est le nombre maximal d’enregistrements dans un même lot. Lambda invoque votre fonction en présence de l’un des trois critères suivants :

  • La fenêtre de traitement par lots atteint sa valeur maximale. Le comportement par défaut de la fenêtre de traitement par lots varie selon la source d’événement spécifique.

    • Pour les sources d’événements Kinesis, DynamoDB et Amazon SQS : la fenêtre de traitement par lot par défaut est de 0 seconde. Cela signifie que Lambda invoque votre fonction dès que des enregistrements sont disponibles. Pour définir une fenêtre de traitement par lots, configurez MaximumBatchingWindowInSeconds. Vous pouvez configurer ce paramètre à n’importe quelle valeur comprise entre 0 et 300 secondes par incréments d’1 seconde. Si vous configurez une fenêtre de traitement par lots, la fenêtre suivante commence dès que l’invocation de fonction précédente est terminée.

    • Pour les sources d’événements Amazon MSK, Apache Kafka autogérées, Amazon MQ et Amazon DocumentDB : la fenêtre de traitement par lots par défaut est de 500 ms. Vous pouvez configurer MaximumBatchingWindowInSeconds à n’importe quelle valeur comprise entre 0 et 300 secondes par incréments de secondes. Une fenêtre de traitement par lots commence dès l’arrivée du premier registre.

      Note

      Étant donné que vous ne pouvez modifier MaximumBatchingWindowInSeconds que par incréments de secondes, vous ne pouvez pas revenir à la fenêtre de traitement par lots par défaut de 500 ms après l’avoir modifiée. Pour restaurer la fenêtre de traitement par lots par défaut, vous devez créer un mappage de source d’événement.

  • La taille du lot est atteinte. La taille minimale du lot est de 1. La taille par défaut et la taille maximale du lot dépendent de la source d’événement. Pour plus d’informations sur ces valeurs, consultez la spécification de BatchSize pour l’opération d’API CreateEventSourceMapping.

  • La taille de la charge utile atteint 6 Mo. Vous ne pouvez pas modifier cette limite.

Le diagramme suivant illustre ces trois conditions. Supposons qu’une fenêtre de traitement par lots commence à t = 7 secondes. Dans le premier scénario, la fenêtre de traitement par lots atteint son maximum de 40 secondes à t = 47 secondes après avoir accumulé 5 enregistrements. Dans le second scénario, la taille du lot atteint 10 avant l’expiration de la fenêtre de traitement par lots, de sorte que la fenêtre de traitement par lots se termine plus tôt. Dans le troisième scénario, la taille maximale de la charge utile est atteinte avant l’expiration de la fenêtre de traitement par lots, de sorte que la fenêtre de traitement par lots se termine plus tôt.

La fenêtre de traitement par lots expire lorsque le temps maximum est atteint, que la taille du lot est atteinte ou que les données utiles atteignent 6 Mo

Nous vous recommandons de tester différentes tailles de lots et d’enregistrements afin que la fréquence d’interrogation de chaque source d’événement soit adaptée à la rapidité avec laquelle votre fonction est en mesure d’accomplir sa tâche. Le paramètre BatchSize CreateEventSourceMapping contrôle le nombre maximal de registres qui peuvent être envoyés à votre fonction lors de chaque invocation. Une taille de lot plus grande peut souvent absorber plus efficacement l’invocation sur un plus large ensemble d’enregistrements, ce qui accroît votre débit.

Lambda envoi le prochain lot pour traitement sans attendre que les extensions configurées soient terminées. En d’autres termes, vos extensions peuvent continuer à s’exécuter pendant que Lambda traite le prochain lot d’enregistrements. Cela peut causer des problèmes de limitation si vous enfreignez l’un des paramètres ou l’une des limites de simultanéité de votre compte. Pour détecter s’il s’agit d’un problème éventuel, surveillez vos fonctions et vérifiez si vous observez des métriques de simultanéité plus élevées que prévu pour votre mappage des sources d’événements. En raison de la brièveté des intervalles entre les invocations, Lambda peut brièvement signaler une utilisation simultanée supérieure au nombre de partitions. Cela peut être vrai même pour les fonctions Lambda sans extensions.

Par défaut, si votre fonction renvoie une erreur, le mappage de la source d’événements retraite l’ensemble du lot jusqu’à ce que la fonction réussisse ou que les éléments du lot arrivent à expiration. Pour s’assurer d’un traitement dans l’ordre, le mappage de la source d’événement met en pause le traitement dans la partition concernée jusqu’à la résolution de l’erreur. 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. Les erreurs de service ou les limitations où le lot n’atteint pas votre fonction ne comptent pas dans les tentatives de réessai. Vous pouvez également configurer le mappage des sources d’événements pour qu’il envoie un enregistrement d’invocation à une destination lorsqu’il rejette un lot d’événements.

Mode alloué

Les mappages des sources d’événements Lambda utilisent des sondeurs d’événements pour interroger votre source d’événements à la recherche de nouveaux messages. Par défaut, Lambda gère le dimensionnement automatique de ces sondeurs en fonction du volume des messages. Lorsque le trafic de messages augmente, Lambda augmente automatiquement le nombre de sondeurs d’événements pour gérer la charge, et le réduit lorsque le trafic diminue.

En mode alloué, vous pouvez optimiser le débit de votre mappage des sources d’événements en définissant des limites minimales et maximales pour le nombre de sondeurs d’événements alloués. Lambda adapte ensuite votre mappage des sources d’événements entre le nombre minimum et maximum de sondeurs d’événements de manière réactive. Ces sondeurs d’événements alloués sont dédiés à votre mappage des sources d’événements, améliorant ainsi votre capacité à gérer des pics d’événements imprévisibles.

Dans Lambda, un sondeur d’événements est une unité de calcul capable de gérer jusqu’à 5 Mbit/s de débit. À titre de référence, supposons que votre source d’événement produise des données utiles moyennes de 1 Mo et que la durée d’exécution moyenne des fonctions soit de 1 seconde. Si ls données utiles ne subissent aucune transformation (telle que le filtrage), un seul sondeur peut prendre en charge un débit de 5 Mbit/s et 5 invocations Lambda simultanées. L’utilisation du mode alloué génère des coûts supplémentaires. Pour les estimations de prix, consultez la Tarification d’AWS Lambda.

Le mode alloué n’est pris en charge que pour Amazon MSK et Apache Kafka autogéré. Alors que les paramètres de simultanéité vous permettent de contrôler la mise à l’échelle de votre fonction, le mode alloué vous permet de contrôler le débit de votre mappage des sources d’événements. Pour garantir des performances optimales, vous devrez peut-être ajuster les deux paramètres indépendamment. Pour plus d’informations sur la configuration du mode alloué, reportez-vous aux sections suivantes :

Après avoir configuré le mode alloué, vous pouvez observer l’utilisation des sondeurs d’événements pour votre charge de travail en surveillant la métrique ProvisionedPollers. Pour en savoir plus, consultez Métriques de mappage des sources d’événements.

API de mappage de la source d’événement

Pour gérer une source d’événement à l’aide de la AWS Command Line Interface (AWS CLI) ou d’un AWS SDK, vous pouvez utiliser les opérations d’API suivantes :