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 d'interrogation dédiées pour vos mappages de sources d'événements Amazon SQS. La fonction Lambda et la file d'attente Amazon SQS doivent être Région AWS identiques, bien qu'elles puissent être différentes. Comptes AWS

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 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 le mappage de votre source d'événements pour inclure les défaillances d'éléments de lot dans la réponse de votre fonction, soit utiliser l'DeleteMessageAPI pour supprimer les messages de la file d'attente au fur et à mesure que 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é en mode provisionné évolue 3 fois plus vite (jusqu'à 1 000 appels simultanés par minute) et prend en charge une simultanéité 16 fois supérieure (jusqu'à 20 000 appels simultanés) par rapport à la capacité de mappage des sources d'événements Amazon SQS par défaut. Nous vous recommandons d'utiliser le mode provisionné pour les charges de travail basées sur les événements Amazon SQS soumises à des exigences de performance strictes, telles que les sociétés de services financiers traitant les flux de données du 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 avec les joueurs en direct. L’utilisation du mode alloué génère des coûts supplémentaires. Pour connaître les tarifs détaillés, consultez la section AWS Lambda des prix.

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, avec une valeur par défaut de 2. La plage de valeurs acceptées pour le nombre maximum de sondeurs d'événements (MaximumPollers) est comprise entre 2 et 2 000, avec une valeur par défaut de 200. MaximumPollers doit être supérieur ou égal à MinimumPollers.

Déterminer les sondeurs d'événements requis

Pour estimer le nombre de sondeurs 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 indicateurs suivants 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.

Vous pouvez d'abord 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 fournissez une capacité suffisante pour répondre à vos besoins de trafic de pointe.

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 moyenne des événements de 3 Ko, une durée de fonctionnement 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 prendra en charge environ 100 événements par seconde (EPS). Par conséquent, vous devez définir un nombre minimum de sondeurs à 10 pour répondre de manière adéquate à vos besoins de pointe en matière de trafic. Si votre charge de travail présente les mêmes caractéristiques mais avec une durée de fonctionnement moyenne d'une seconde, chaque sondeur ne prendra en charge que 10 EPS, ce qui vous obligera à configurer au moins 100 sondeurs pour prendre en charge 1 000 événements par seconde avec une faible latence.

Nous 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 votre capacité de sondeurs d'événements, tenez compte des pics de trafic potentiels et envisagez de définir une valeur de minimumPollers légèrement supérieure au minimum calculé pour créer 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 de la capacité, nous vous recommandons de tester votre charge de travail spécifique afin de déterminer l'EPS réel que chaque enquêteur peut piloter.

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

Vous pouvez configurer le mode provisionné pour le mappage de vos sources d'é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 Métriques 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"
        }
    ]
}