Lire la file d'attente SQS depuis AWS Lambda
J'ai l'infrastructure suivante:
J'ai une instance EC2 avec un processus NodeJS + Express écoutant des messages sur un port (processus 1). Chaque fois que le processus reçoit un message, il l'envoie dans une file d'attente SQS. Ensuite, un autre processus de la même machine lit la file d'attente en utilisant une interrogation longue (processus 2). Lorsqu'il trouve un message dans la file d'attente, il insère les données dans une base de données MariaDB située sur une instance RDS.
(Juste pour clarifier, les messages sont générés par les utilisateurs, ils envoient un bloc de données pouvant contenir des informations arbitraires au noeud final où le processus 1 est à l'écoute)
Maintenant, je veux mettre le processus qui lit le SQS (process 2) dans une fonction Lambda afin que le processus qui écrit dans la file d'attente et celui qui lit dans la file d'attente soient complètement indépendants. Le problème est que je ne sais pas si cela est possible.
Je sais que les fonctions Lambda sont appelées en réponse à un événement et que les événements actuellement pris en charge sont S3, SNS, SES, DynamoDB, Kinesis, Cognito, CloudWatch et Cloudformation, mais NOT SQS.
Je pensais utiliser des notifications SNS pour appeler la fonction Lambda de sorte que chaque fois qu'un message est envoyé dans la file d'attente, une notification SNS est déclenchée et appelle la fonction Lambda, mais après avoir joué un peu avec elle, je me suis rendu compte qu'il était impossible de Pour créer une notification SNS à partir de SQS, il est uniquement possible d'écrire des notifications SNS dans la file d'attente.
En ce moment, je suis un peu coincé parce que je ne sais pas comment continuer. J'ai l'impression qu'il n'est pas possible de créer cette infrastructure en raison des limitations actuelles des services AWS. Y a-t-il une autre façon de faire ce que je veux ou suis-je dans une impasse?
Pour étendre ma question avec quelques recherches que j'ai faites, ce dépôt github montre comment lire une file d'attente SQS depuis une fonction Lambda mais la fonction lambda ne fonctionne que si elle est lancée à partir de la ligne de commande:
https://github.com/robinjmurphy/sqs-to-lambda
Dans le readme, l'auteur mentionne les éléments suivants:
Mise à jour: Lambda prend désormais en charge les notifications SNS en tant que source d’événement, ce qui rend ce hack tout à fait inutile pour les notifications SNS. Vous cela pourrait quand même vous être utile si vous aimez l’idée d’utiliser un Lambda fonction permettant de traiter des travaux dans une file d'attente SQS.
Mais je pense que cela ne résout pas mon problème, une notification SNS peut appeler la fonction Lambda, mais je ne vois pas comment je peux créer une notification lorsqu'un message est reçu dans la file d'attente SQS.
Merci
Quelques stratégies peuvent être utilisées pour connecter les points, (A) de manière synchrone ou Run-Sleep-Run pour conserver le flux de processus de données entre SNS, SQS et Lambda.
Stratégie 1 : Demandez à une fonction Lambda d’écouter le SNS et de le traiter en temps réel [Veuillez noter qu’une file d’attente SQS peut s’abonner à un sujet SNS - qui aurait peut être utile pour la journalisation/audit/nouvelle tentative de traitement]
Stratégie 2 : Étant donné que vous obtenez des données provenant de la file d’attente SQS. Vous pouvez essayer avec 2 fonctions Lambda [Feeder & Worker].
Feeder serait
scheduled lambda functiondont le travail consiste à prendre des éléments à partir de SQS (le cas échéant) et transmettez-le comme sujet SNS (et continuez à le faire pour toujours)Worker serait lié pour écouter le sujet SNS qui ferait le
actual data processing
Nous pouvons maintenant utiliser les messages SQS pour déclencher les fonctions AWS Lambda. En outre, il n’est plus nécessaire d’exécuter un service d’interrogation de messages ou de créer un mappage SQS vers SNS.
Détails supplémentaires: https://aws.Amazon.com/blogs/aws/aws-lambda-adds-Amazon-simple-queue-service-to-supported-event-sources/
J'ai eu une situation similaire (et ont maintenant une solution de travail déploré). Je l'ai abordé de la manière suivante:
c'est-à-dire publier des événements sur SNS; qui sont ensuite distribués à Lambda et SQS.
REMARQUE: cela ne s'applique pas aux événements qui doivent être traités dans un certain ordre.
Qu'il existe des pièges (avec solutions possibles) tels que:
- condition de course: lambda peut être appelé avant le dépôt des messages dans la file d'attente
- la nature distribuée de la file d'attente SQS peut conduire à ne renvoyer aucun message, même s'il existe un message note1.
La solution dans les deux cas serait de procéder à une interrogation longue de la file d'attente SQS; mais cela rend votre facture lambda plus chère.
note 1
Une interrogation courte est le comportement par défaut lorsqu'un ensemble aléatoire de machines est échantillonné lors d'un appel ReceiveMessage. Cela signifie que seuls les messages des machines échantillonnées sont renvoyés. Si le nombre de messages dans la file d'attente est faible (moins de 1 000), vous obtiendrez probablement moins de messages que vous n'en avez demandé par appel ReceiveMessage. Si le nombre de messages dans la file d'attente est extrêmement faible, vous risquez de ne recevoir aucun message dans une réponse ReceiveMessage particulière; Dans ce cas, vous devez répéter la demande . http://docs.aws.Amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html
AWS SQS est l'un des plus anciens produits d'Amazon, qui ne prend en charge que l'interrogation (longue et courte) jusqu'en juin 2018. Comme indiqué dans cette réponse , AWS SQS prend désormais en charge le déclenchement des fonctions lambda sur les nouveaux messages. arrivée en SQS. Un tutoriel complet à ce sujet est fourni dans ce document .
J'avais l'habitude de traiter ce problème en utilisant différents mécanismes, et voici quelques approches que vous pouvez utiliser.
Vous pouvez développer une application d'interrogation simple dans Lambda et utiliser AWS CloudWatch pour l'appeler toutes les 5 minutes environ. Vous pouvez faire cela presque en temps réel en utilisant des événements CloudWatch pour appeler lambda avec des temps d'arrêt courts. Utilisez ce didacticiel ou ce didacticiel à cette fin. (Cela pourrait coûter plus cher sur Lambdas)
Vous pouvez considérer que SQS est redondant si vous n'avez pas besoin de conserver les messages ni de garantir l'ordre de livraison. Vous pouvez utiliser AWS SNS (service de notification simple) pour appeler directement une fonction lambda et effectuer le traitement requis. Utilisez ce tutoriel à cette fin. Cela se produira en temps réel. Mais le principal inconvénient est le nombre de lambdas pouvant être initiés par région à un moment donné. Veuillez lire this et comprendre la limitation avant de suivre cette approche. Néanmoins, AWS SNS garantit l’ordre de livraison. SNS peut également appeler directement un point de terminaison HTTP et stocker le message dans votre base de données.
Nous avions des exigences similaires, nous avons donc créé une bibliothèque et ouvert son accès afin d'aider SQS to Lambda async. Je ne sais pas si cela répond à votre ensemble particulier d'exigences, mais j'ai pensé qu'il valait la peine d'y jeter un coup d'œil: https://read.iopipe.com/sqs-lambda-teaming-up-92c4096be49c