Utilisation de Lambda avec Amazon SQS

Vous pouvez utiliser une fonction Lambda pour traiter les messages figurant dans une file d’attente Amazon Simple Queue Service (Amazon SQS). Lambda prend en charge à la fois les files d’attente standard et les files d’attente FIFO (premier entré, premier sorti) pour les mappages des sources d’événements. Vous pouvez également utiliser le mode provisionné pour allouer des ressources de sondage dédiées à vos mappages de sources d'événements Amazon SQS. La fonction Lambda et la file d'attente Amazon SQS doivent être identiques Région AWS, bien qu'elles puissent être différentes. Comptes AWS

Pour un exemple de fonction qui traite les messages Amazon SQS, consultezDidacticiel : utilisation de Lambda avec Amazon SQS. Pour le traitement intercomptes, consultezDidacticiel : utilisation d’une file d’attente Amazon SQS entre comptes en tant que source d’événement. Pour obtenir la liste complète des options de configuration, consultez Paramètres Lambda pour les mappages des sources d’événement Amazon SQS.

Lorsque vous traitez des messages Amazon SQS, vous devez implémenter une logique de réponse partielle de lot afin d’éviter que les messages traités avec succès soient de nouveau essayés en cas d’échec de certains messages d’un lot. L'utilitaire Batch Processor de Powertools for AWS Lambda simplifie cette implémentation en gérant automatiquement la logique de réponse partielle par lots, en réduisant le temps de développement et en améliorant la fiabilité.

Comprendre le comportement d’interrogation et de traitement par lots pour les mappages des sources d’événements Amazon SQS

Avec les mappages des sources d’événements Amazon SQS, Lambda interroge la file d’attente et invoque votre fonction de manière synchrone avec un événement. Chaque événement peut contenir un lot de plusieurs messages provenant de la file d’attente. Lambda reçoit ces événements un lot à la fois, et invoque votre fonction une fois pour chaque lot. Après que la fonction a traité un lot avec succès, Lambda supprime ses messages de la file d’attente.

Quand Lambda reçoit un lot, les messages restent dans la file d’attente mais sont masqués pendant toute la durée du délai de visibilité de la file d’attente. Si votre fonction traite tous les messages d’un lot avec succès, Lambda supprime les messages depuis la file d’attente. Par défaut, si votre fonction rencontre une erreur lors du traitement d’un lot, tous les messages de ce lot redeviennent visibles dans la file d’attente une fois le délai de visibilité expiré. Pour cette raison, le code de votre fonction peut traiter le même message plusieurs fois sans effets secondaires involontaires.

Pour empêcher Lambda de traiter un message plusieurs fois, vous pouvez soit configurer votre mappage de source d'événements pour inclure les échecs d'éléments par lots dans la réponse de votre fonction, soit utiliser l'DeleteMessageAPI pour supprimer les messages de la file d'attente lorsque votre fonction Lambda les traite correctement.

Pour de plus amples informations sur les paramètres de configuration pris en charge par Lambda pour les mappages des sources d’événements SQS, consultez Création d’un mappage des sources d’événements SQS.

Utilisation du mode provisionné avec les mappages de sources d'événements Amazon SQS

Pour les charges de travail où vous devez optimiser le débit de votre mappage des sources d’événements, vous pouvez utiliser le mode provisionné. En mode provisionné, vous définissez des limites minimales et maximales pour le nombre de sondeurs d’événements alloués. Ces sondeurs d’événements alloués sont dédiés à votre mappage des sources d’événements et peuvent gérer les pics de messages inattendus grâce à une mise à l’échelle automatique réactive. Le mappage des sources d'événements Amazon SQS configuré avec le mode provisionné évolue 3 fois plus rapidement (jusqu'à 1 000 appels simultanés par minute) et prend en charge une simultanéité 80 fois plus élevée (jusqu'à 100 000 appels simultanés) que la fonctionnalité de mappage des sources d'événements par défaut d'Amazon SQS.

Nous vous recommandons d'utiliser le mode provisionné pour les charges de travail pilotées par des événements Amazon SQS qui ont des exigences de performances strictes, telles que les sociétés de services financiers qui traitent des flux de données de marché, les plateformes de commerce électronique fournissant des recommandations personnalisées en temps réel et les sociétés de jeux gérant les interactions en direct avec les joueurs. L’utilisation du mode alloué génère des coûts supplémentaires. Pour une tarification détaillée, consultez la section AWS Lambda Tarification.

Chaque sondeur d'événements en mode provisionné peut gérer jusqu'à 1 % MB/s du débit, jusqu'à 10 appels simultanés ou jusqu'à 10 appels d'API d'interrogation Amazon SQS par seconde. La plage de valeurs acceptées pour le nombre minimum de sondeurs d'événements (MinimumPollers) est comprise entre 2 et 200, la valeur par défaut étant de 2. La plage de valeurs acceptées pour le nombre maximum de sondeurs d'événements (MaximumPollers) est comprise entre 2 et 10 000, la valeur par défaut étant de 200. MaximumPollers doit être supérieur ou égal à MinimumPollers.

Déterminer les sondages requis pour les événements

Pour estimer le nombre d'interrogateurs d'événements nécessaires pour garantir des performances de traitement des messages optimales lors de l'utilisation du mode provisionné pour SQS ESM, collectez les mesures suivantes pour votre application : pic d'événements SQS par seconde nécessitant un traitement à faible latence, taille moyenne de la charge utile des événements SQS, durée moyenne de la fonction Lambda et taille de lot configurée.

Tout d'abord, vous pouvez estimer le nombre d'événements SQS par seconde (EPS) pris en charge par un sondeur d'événements pour votre charge de travail à l'aide de la formule suivante :

EPS per event poller = 
        minimum(
            ceiling(1024 / average event size in KB),
            ceiling(10 / average function duration in seconds) * batch size, 
            min(100, 10 * batch size)
                )

Ensuite, vous pouvez calculer le nombre minimum de sondeurs requis à l'aide de la formule ci-dessous. Ce calcul garantit que vous disposez d'une capacité suffisante pour répondre à vos besoins de pointe en matière de trafic.

Required event pollers = (Peak number of events per second in Queue) / EPS per event poller

Prenons l'exemple d'une charge de travail avec une taille de lot par défaut de 10, une taille d'événement moyenne de 3 Ko, une durée de fonction moyenne de 100 ms et une exigence de gestion de 1 000 événements par seconde. Dans ce scénario, chaque sondeur d'événements prend en charge environ 100 événements par seconde (EPS). Par conséquent, nous vous recommandons de fixer un nombre minimum de participants à 10 pour répondre de manière adéquate à vos besoins en matière de trafic en période de pointe. Si votre charge de travail présente les mêmes caractéristiques mais que la durée de fonctionnement moyenne est d'une seconde, chaque sondeur ne prend en charge que 10 EPS, ce qui vous oblige à configurer 100 interrogateurs minimum pour prendre en charge 1 000 événements par seconde avec une faible latence.

Nous vous recommandons d'utiliser une taille de lot par défaut de 10 ou plus pour optimiser l'efficacité des sondeurs d'événements en mode provisionné. Des lots de plus grande taille permettent à chaque sondeur de traiter un plus grand nombre d'événements par appel, ce qui améliore le débit et la rentabilité. Lorsque vous planifiez la capacité de sondage de votre événement, tenez compte des pics de trafic potentiels et envisagez de définir une valeur MinimumPollers légèrement supérieure au minimum calculé pour fournir une zone tampon. En outre, surveillez les caractéristiques de votre charge de travail au fil du temps, car les modifications de la taille des messages, de la durée des fonctions ou des modèles de trafic peuvent nécessiter des ajustements de la configuration de votre sondeur d'événements afin de maintenir des performances et une rentabilité optimales. Pour une planification précise des capacités, nous vous recommandons de tester votre charge de travail spécifique afin de déterminer l'EPS réel que chaque enquêteur peut générer.

Configuration du mode provisionné pour le mappage des sources d'événements Amazon SQS

Vous pouvez configurer le mode provisionné pour le mappage des sources de vos événements Amazon SQS à l'aide de la console ou de l'API Lambda.

Vous pouvez configurer le mode provisionné par programmation à l'aide de l'ProvisionedPollerConfigobjet de votre. EventSourceMappingConfiguration Par exemple, la commande UpdateEventSourceMapping CLI suivante configure une MinimumPollers valeur de 5 et une MaximumPollers valeur de 100.

aws lambda update-event-source-mapping \
    --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
    --provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'

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 plus d'informations, consultez la section Mesures de mappage des sources d'événements.

Pour désactiver le mode provisionné et revenir au mode par défaut (à la demande), vous pouvez utiliser la commande UpdateEventSourceMapping CLI suivante :

aws lambda update-event-source-mapping \
    --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
    --provisioned-poller-config '{}'

Pour plus d'informations sur la configuration du mode provisionné, consultezCréation et configuration d’un mappage des sources d’événements Amazon SQS.

Exemple d’événement de message de file d’attente standard

{
    "Records": [
        {
            "messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
            "receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
            "body": "Test message.",
            "attributes": {
                "ApproximateReceiveCount": "1",
                "SentTimestamp": "1545082649183",
                "SenderId": "AIDAIENQZJOLO23YVJ4VO",
                "ApproximateFirstReceiveTimestamp": "1545082649185"
            },
            "messageAttributes": {
                "myAttribute": {
                    "stringValue": "myValue", 
                    "stringListValues": [], 
                    "binaryListValues": [], 
                    "dataType": "String"
                }
            },
            "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
            "eventSource": "aws:sqs",
            "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
            "awsRegion": "us-east-2"
        },
        {
            "messageId": "2e1424d4-f796-459a-8184-9c92662be6da",
            "receiptHandle": "AQEBzWwaftRI0KuVm4tP+/7q1rGgNqicHq...",
            "body": "Test message.",
            "attributes": {
                "ApproximateReceiveCount": "1",
                "SentTimestamp": "1545082650636",
                "SenderId": "AIDAIENQZJOLO23YVJ4VO",
                "ApproximateFirstReceiveTimestamp": "1545082650649"
            },
            "messageAttributes": {},
            "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
            "eventSource": "aws:sqs",
            "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
            "awsRegion": "us-east-2"
        }
    ]
}

Par défaut, Lambda interroge jusqu’à 10 messages à la fois dans votre file d’attente, et envoie ce lot à votre fonction. Pour éviter d’invoquer la fonction avec un petit nombre d’enregistrements, vous pouvez configurer la source d’événement de manière à les mettre en mémoire tampon pendant 5 minutes en configurant une fenêtre de lot. Avant d’invoquer la fonction, Lambda continue d’interroger les messages de la file d’attente standard jusqu’à ce que la fenêtre de lot expire, que le quota de taille des données utiles de l’invocation soit atteint ou que la taille maximale configurée du lot soit atteinte.

Si vous utilisez une fenêtre de lot et que votre file d’attente SQS contient un trafic très faible, Lambda peut attendre 20 secondes avant d’invoquer votre fonction. C’est le cas même si vous définissez une fenêtre de lot inférieure à 20 secondes.

Exemple d’événement de message de file d’attente FIFO

Pour les files d’attente FIFO, les enregistrements contiennent des attributs supplémentaires liés à la déduplication et au séquençage.

{
    "Records": [
        {
            "messageId": "11d6ee51-4cc7-4302-9e22-7cd8afdaadf5",
            "receiptHandle": "AQEBBX8nesZEXmkhsmZeyIE8iQAMig7qw...",
            "body": "Test message.",
            "attributes": {
                "ApproximateReceiveCount": "1",
                "SentTimestamp": "1573251510774",
                "SequenceNumber": "18849496460467696128",
                "MessageGroupId": "1",
                "SenderId": "AIDAIO23YVJENQZJOL4VO",
                "MessageDeduplicationId": "1",
                "ApproximateFirstReceiveTimestamp": "1573251510774"
            },
            "messageAttributes": {},
            "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
            "eventSource": "aws:sqs",
            "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:fifo.fifo",
            "awsRegion": "us-east-2"
        }
    ]
}