Quelle est la différence entre SQS et SNS ?

SQS est bon pour extraire des messages. SNS est bon pour envoyer des messages. Utilisez SQS si : le découplage des applications est nécessaire en autorisant le traitement asynchrone parallèle, un seul abonné est nécessaire. Utilisez SNS si : le même message doit être traité de plusieurs manières, l'envoi de SMS / e-mail hors de la boîte est pratique.

Choisissez EventBridge si : Vous souhaitez créer une application qui réagit aux événements des applications SaaS, des services AWS ou des applications personnalisées. Vous souhaitez publier des messages à plusieurs abonnés et utiliser les données d'événement elles-mêmes pour faire correspondre les cibles intéressées par certains modèles (filtrage basé sur le contenu : en créant des règles qui s'appliquent à l'ensemble du corps de l'événement/du contenu du message). Vous souhaitez une prise en charge de la transformation des entrées en fonction de vos besoins. Vous souhaitez configurer des événements planifiés à l'aide de la syntaxe cron Unix populaire. Vous souhaitez utiliser des fonctionnalités uniques telles que les capacités de découverte de schéma intégrées, les événements d'archivage et de relecture, etc. Vous voulez beaucoup plus de cibles et une intégration avec une plus grande variété de services en tant que cible. EventBridge est le seul service événementiel qui s'intègre directement aux partenaires SaaS tiers. Choisissez SNS si : Vous souhaitez créer une application qui réagit aux messages à haut débit ou à faible latence publiés par d'autres applications ou microservices. Vous souhaitez publier des messages à plusieurs abonnés en une seule action (très grande diffusion, des milliers ou des millions de terminaux). Vous souhaitez un ordre strict des messages (premier entré, premier sorti) (avec FIFO Topics). Vous souhaitez publier et consommer des lots de messages. Vous voulez des abonnements de livraison intégrés pour les points de terminaison SMS, e-mail, push mobile et HTTP (qu'EventBridge ne fournit pas).

c Message retention Kinesis — Stores records for 24 hours by default, can retain streaming data for up to 7 days SQS — Can configure message retention period from 1 minute to 14 days, default is 4 days Message retry Kinesis — No delivery guarantee, service consuming data can retry as long as data is present, consumer doesn’t remove data, ordering is also guaranteed in case of re-drive items SQS — At-least-once delivery guarantee, continues to republish unacknowledged message until the message reaches max age as per Message Retention Period Failure handling Kinesis — No Dead Letter Queue (DLQ) out of the box, every application that consumes the stream has to deal with failure on its own SQS — If consumer fails to process message within visibility timeout, the message is sent to a configured DLQ and can be received again in SQS Number of consumers Kinesis — Supports multiple consumers capabilities, same data records can be processed at the same time by multiple consumers or different time by the same consumer SQS — Supports only single consumer at a time, once a message has been acknowledged it’s deleted from the queue Ordering of records Kinesis — Supports in-order processing within a shard however, no kind of ordering between shards can be guaranteed SQS — Standard SQS queue doesn’t guarantee in-order processing however FIFO queues support it but with limitations Routing of records Kinesis — Related records can be routed to the same record processor SQS — No support for routing Other AWS services support Kinesis — Can send stream records directly to services such as Amazon S3, Amazon Redshift, Amazon ElasticSearch, Splunk, AWS Lambda SQS — Other services can be integrated through AWS Lambda Sample use-cases Kinesis — Log and Event Data Collection, Real-time Analytics, Mobile Data Capture, Internet of Things Data Feed SQS — Application integration, Decouple microservices, Decouple live user requests from intensive background work, Batch messages for future processing

Entity Type SQS : Queue (similar to JMS, MSMQ). SNS : Topic-Subscriber (Pub/Sub system). Message consumption SQS : Pull Mechanism — Consumers poll messages from SQS. SNS : Push Mechanism — SNS pushes messages to consumers. Persistence SQS : Messages are persisted for some duration is no consumer available. The retention period value is from 1 minute to 14 days. The default is 4 days. SNS : No persistence. Whichever consumer is present at the time of message arrival, get the message and the message is deleted. If no consumers available then the message is lost. In SQS the message delivery is guaranteed but in SNS it is not. Consumer Type SQS : All the consumers are supposed to be identical and hence process the messages in exact same way. SNS : All the consumers are (supposed to be) processing the messages in different ways.

AWS SNS, SQS, Kinesis Data Streams: lequel choisir ?

AWS messaging solutions SQS, SNS, EventBridge, Kinesis Data Streams Firehose

Dans une architecture serverless, les “Messaging services” sont nécessaires pour permettre aux solutions (applications, logiciels) de communiquer entre elles, et d’échanger des données. Sur AWS, plusieurs de ces services sont disponibles. Nous vous présentons les 4 principaux : Amazon Simple Queue service (Amazon SQS), Amazon Simple Notification Service (Amazon SNS), Amazon EventBridge et Kinesis Data Streams / Firehose. Zoom sur le type de transfert d’information proposé (file d’attente, notification, bus d’événements & streams) et sur leur fonctionnement.

« AWS messaging solutions » : notre table des matières

“Messaging services” : à quoi servent-ils sur AWS ?
Quand utiliser Amazon Simple Queue Service (SQS) ?
Quand utiliser Amazon Simple Notification Service (SNS) ?
Quand utiliser Amazon EventBridge ?
Quand utiliser Amazon Kinesis Data Streams / Firehose ?

“Messaging services” : à quoi servent-ils sur AWS ?

Sur le cloud AWS, les “Messaging services” permettent à différents systèmes (logiciels, applications et appareils finaux) de communiquer et d’échanger des informations, et ce, même s’ils n’utilisent pas les mêmes langages de programmation, et s’ils sont installés sur des plateformes différentes.

Ces services sont primordiaux dans une architecture serverless. En effet, la plupart d’entre elles utilisent une combinaison de différents services AWS, microservices et fonctions AWS Lambda. Sans ces solutions, impossible pour elles de se transmettre les données nécessaires à la production.

Sur Amazon Web Services, il en existe plusieurs, chacun ayant des fonctionnalités bien précises. Avant d’en choisir un, nous vous conseillons de faire le point sur vos besoins et vos objectifs. Quel type de transfert d’informations souhaitez-vous mettre en place entre vos différents systèmes ?

Dans cet article, nous vous proposons de découvrir les quatre modèles de transfert d’information les plus utilisés par les développeurs : les files d’attente, les notifications, et les bus d’événements. Sur AWS, ces modèles sont fournis respectivement par les services Amazon SQS, Amazon SNS, Amazon EventBridge et Kinesis Data Streams / Firehose. Ces 4 services sont entièrement gérés et hautement disponibles, il n’y a donc pas d’infrastructure à gérer. Ils vous permettent de publier des messages via le kit AWS SDK et d’appeler des fonctions en tant que cibles.

Quand utiliser Amazon Simple Queue Service (AWS SQS) ?

Quand et comment utiliser Amazon Simple Queue Service (SQS)

Type de transfert d’information : file d’attente

SQS fournit des files d’attente pour vos applications Serverless. Vous pouvez utiliser une file d’attente pour envoyer, stocker et recevoir des messages entre différents composants logiciels.

SQS propose un traitement asynchrone des messages. Chaque message ne doit être traité qu’une seule fois par une seule instance de consommateur (Lambda ou parc de machines EC2).

Quantité et durée de traitement de message : nombre de messages illimité / 14 jours

SQS évolue de manière élastique, il n’y a pas de limite au nombre de messages par file d’attente. Le service conserve pendant 14 jours les messages jusqu’à ce qu’ils soient traités par un consommateur en aval (Lambda ou parc de machines EC2).

SQS propose deux types de files d’attente de messages :

Les files d’attente standard offrent un débit maximal, respectent l’ordre dans la mesure du possible et livrent les messages au moins une fois.
Les files d’attente FIFO sont conçues pour garantir que les messages sont traités uniquement une fois, dans l’ordre dans lequel ils sont envoyés.

Comment créer une file d’attente SQS
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/create-queue-cloudformation.html

Pour en savoir + | https://aws.amazon.com/fr/sqs/

Quand utiliser Amazon Simple Notification Service (AWS SNS) ?

Quand et comment utiiser Amazon Simple Notification Service (SNS)

Type de transfert d’information : communication vers des applications ou des personnes

SNS est un service de messagerie utile pour une communication d’application à application (A2A) et d’application à personne (A2P).

Relation one-to-many

Ce service propose une relation one-to-many. Ainsi, un message peut être envoyé à plusieurs consommateurs. Ce comportement est appelé fan-out. Un sujet SNS peut avoir jusqu’à 12 500 000 abonnés, offrant des capacités de diffusion hautement évolutives.

En utilisant les rubriques Amazon SNS, vos systèmes d’édition peuvent envoyer des messages vers des systèmes d’abonnés, y compris les files d’attente Amazon SQS, les fonctions AWS Lambda et les points de terminaison HTTP/S, pour un traitement parallèle, sans oublier Amazon Kinesis Data Firehose.

Service push

La fonctionnalité A2P vous permet d’envoyer des messages aux utilisateurs à l’échelle via SMS, Mobile Push et e-mail. À la différence de SQS, SNS ne conserve pas les messages, donc s’il n’y a pas d’abonnés pour une rubrique, le message est rejeté.

Comment filtrer les messages publiés vers des rubriques avec Amazon Simple Notification Service (SNS) et Amazon Simple Queue Service (SQS) |
https://aws.amazon.com/fr/getting-started/hands-on/filter-messages-published-to-topics/

Pour en savoir + | https://aws.amazon.com/fr/sns/

Quand utiliser Amazon EventBridge ?

comment et pourquoi utiliser Amazon EventBridge

Type de transfert d’information : bus d’événements

EventBridge connecte les services AWS, les fournisseurs de logiciels en tant que service (SaaS) et vos propres applications à l’aide d’événements. Un événement est un signal indiquant que l’état d’un système a changé, par exemple, le changement d’état d’un ticket de support client. Les clients peuvent intégrer à leurs propres applications AWS des microservices, des applications SaaS et des applications personnalisées sous la forme de sources d’événements qui publient des événements dans un bus d’événements.

Architectures basées sur les événements

EventBridge simplifie le processus de création d’architectures basées sur les événements. Vous pouvez filtrer et transformer les messages entrants au niveau du service et acheminer les événements vers plusieurs cibles, y compris les fonctions Lambda.

Écriture de code personnalisé

EventBridge simplifie la connexion d’applications. Vous pouvez ajouter, filtrer, transformer et délivrer des événements sans écrire de code personnalisé. Le registre de schémas EventBridge stocke une collection de schémas d’événements faciles à trouver et vous permet de télécharger des liaisons de code pour ces schémas dans votre IDE afin de représenter l’événement sous la forme d’un objet fortement typé dans votre code.

Comment créer un schéma Amazon EventBridge |
https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-create.html

Pour en savoir + | https://aws.amazon.com/fr/eventbridge/

Quand utiliser Amazon Kinesis Data Streams / Firehose ?

Pourquoi et comment utiliser Amazon Kinesis Data Streams

Type de transfert d’information : flux de données

Amazon Kinesis facilite la collecte, le traitement et l’analyse de données en streaming en temps réel, afin d’obtenir rapidement des informations stratégiques et de réagir rapidement. Avec Amazon Kinesis, vous pouvez intégrer des données en temps réel, les analyser à mesure de leur réception et réagir instantanément au lieu d’attendre que toutes les données soient collectées pour démarrer leur traitement.

2 types flux de données

Kinesis Data Streams est un service de streaming de données en temps réel, capable de capturer en continu plusieurs gigaoctets de données par seconde à partir de centaines de milliers de sources (clics de sites Web, flux d’événements de bases de données, transactions financières, flux de médias sociaux, journaux informatiques, événements de localisation). Les données collectées sont disponibles en millisecondes pour permettre l’utilisation d’analyses en temps réel telles que les tableaux de bord en temps réel, la détection des anomalies en temps réel, la tarification dynamique
Kinesis Data Firehose est le moyen le plus simple de capturer, transformer et charger des flux de données dans des magasins de données AWS pour des analyses en temps quasi réel avec des outils d’aide à la décision existants. Il peut capturer, transformer et diffuser des données de streaming vers Amazon S3, Amazon Redshift, Amazon Elasticsearch Service, des points de terminaison HTTP génériques et des fournisseurs de services tels que Datadog, New Relic, MongoDB et Splunk. Il peut également regrouper, compresser, transformer et chiffrer vos flux de données avant de les charger, ce qui réduit l’espace de stockage utilisé et renforce la sécurité.

Pour en savoir + | https://aws.amazon.com/fr/kinesis/

Choisir un service de messagerie approprié n’est pas toujours simple !

Dans certains cas, il vous sera nécessaire de combiner deux de ces services ou +.

N’hésitez pas à consulter la documentation AWS de chaque service.

Et si vous souhaitez être accompagné sur leur mise en place, contactez-nous !

Vous souhaitez franchir le pas ? N’hésitez pas à contacter l’équipe de Premaccess.