Amazon SQS est-il un bon outil pour gérer les données d'enregistrement des analyses dans une base de données?

Question

Nous avons quelques serveurs nodejs où les détails et la charge utile de chaque requête doivent être enregistrés dans SQL Server pour la création de rapports et autres analyses métier.

La quantité de demandes et la similarité des besoins entre les serveurs me donne envie d'aborder cela avec un service de journalisation centralisé. Mon premier instinct est d'utiliser quelque chose comme Amazon SQS et de le laisser agir comme un tampon avec SQL Server directement ou de créer un petit serveur de journalisation qui ferait des appels de base de données dirigés par SQS.

Cela semble-t-il un bon usage pour SQS ou est-ce que je manque un outil largement utilisé pour cette tâche?

Answer 1

La solution dépendra vraiment de la quantité de données que vous utilisez, car chaque service a ses limites. Pour ne citer que quelques-uns:

SQS

• Tout d'abord, puisque vous avez affaire à des journaux, vous ne voulez pas double emploi. Dans cet esprit, vous aurez besoin d'un FIFO (first in first out) queue.
• SQS n'invoque vraiment rien. Ce que vous voulez faire ici est de configurer la file d'attente, puis de passer un appel pour envoyer un message via le SDK AWS JS. Ensuite, lorsque vous recevez le message dans votre rappel, obtenez l'ID du message et transmettez ces données à une fonction Lambda invoquée (vous pouvez également les écrire dans NodeJS) qui stocke les informations dont vous avez besoin dans votre base de données.
• Cela dit, il est important de savoir que les messages dans une file d'attente SQS ont une limite de taille:

La taille minimale des messages est 1 octet (1 caractère). Le maximum est 262 144 octets (256 Ko).

Pour envoyer des messages supérieurs à 256 Ko, vous pouvez utiliser la bibliothèque client étendue Amazon SQS pour Java. Cette bibliothèque vous permet d'envoyer un message Amazon SQS contenant une référence à une charge utile de message dans Amazon S3. La taille maximale de la charge utile est de 2 Go.

CloudWatch Journaux

(à ne pas confondre avec le service de surveillance des nuages ​​de haut niveau lui-même, ce qui est plus des mesures d'envoi)

• L'idée ici est que vous soumettez des données d'événement à journaux CloudWatch
• Il a aussi une limite ici:

Taille de l'événement: 256 Ko (maximum). Cette limite ne peut être modifié

• Contrairement SQS, les journaux CloudWatch peuvent être automatisés pour passer les données du journal à Lambda, qui peut alors être écrit sur votre serveur SQL. Les documents AWS explain how to set that up.

S3

configuration simplement un seau et demandez à vos serveurs écrivent des données. La bonne chose ici est que, puisque S3 est destiné à stocker de gros fichiers, vous n'avez vraiment pas à vous soucier des limitations de taille mentionnées précédemment. Seaux S3 ont également des événements qui peuvent trigger lambda functions. Ensuite, vous pouvez continuer à envoyer des données de logo. Si vos données de journal deviennent suffisamment importantes, vous pouvez effectuer une mise à l'échelle de quelque chose comme AWS Batch, qui vous permet d'obtenir un groupe de conteneurs pouvant être utilisé pour traiter les données de journal. Enfin, vous obtenez également une sauvegarde de données. Si votre base de données tombe en panne, vous avez les données du journal stockées dans S3 et pouvez assembler un script pour charger tout sauvegarder. Vous pouvez également utiliser Lifecycle Policies pour migrer des données anciennes vers un stockage à moindre coût ou supprimer directement toutes ces données.