Pourquoi devrais-je utiliser Amazon Kinesis et non SNS-SQS?

J'ai un cas d'utilisation où il y aura un flux de données à venir et je ne peux pas le consommer au même rythme et j'ai besoin d'un tampon. Cela peut être résolu en utilisant une file d'attente SNS-SQS. J'ai appris que le Kinesis résout le même objectif, alors quelle est la différence? Pourquoi devrais-je préférer (ou ne pas préférer) Kinesis?

En apparence, ils sont vaguement similaires, mais votre cas d'utilisation déterminera quel outil est approprié. OMI, si vous pouvez vous en tirer avec SQS, alors vous devriez - s'il fait ce que vous voulez, ce sera plus simple et moins cher, mais voici une meilleure explication de la FAQ AWS qui donne des exemples de cas d'utilisation appropriés pour les deux outils. vous aider à décider:

FAQ

Gardez à l'esprit que cette réponse était correcte pour juin 2015

Après avoir étudié le problème pendant un moment, en ayant la même question en tête, j'ai trouvé que SQS (avec SNS) est préférable pour la plupart des cas d'utilisation, à moins que l'ordre des messages ne soit important pour vous (SQS ne garantit pas le FIFO sur les messages).

Il y a 2 avantages principaux pour Kinesis:

1. vous pouvez lire le même message depuis plusieurs applications
2. vous pouvez relire les messages au cas où vous en auriez besoin.

Les deux avantages peuvent être obtenus en utilisant SNS en tant que répartiteur vers SQS. Cela signifie que le producteur du message n'envoie qu'un seul message à SNS, puis le SNS répartit le message vers plusieurs SQS, un pour chaque application consommateur. De cette façon, vous pouvez avoir autant de consommateurs que vous le souhaitez sans penser à la capacité de partitionnement.

De plus, nous avons ajouté un autre SQS qui est abonné au SNS qui conservera les messages pendant 14 jours. Dans le cas normal, personne ne lit depuis ce SQS mais en cas de bogue qui nous donne envie de rembobiner les données, nous pouvons facilement lire tous les messages de ce SQS et les renvoyer au SNS. Alors que Kinesis ne fournit qu'une rétention de 7 jours.

En conclusion, SNS + SQS est beaucoup plus simple et fournit la plupart des fonctionnalités. OMI, vous avez besoin d'un argumentaire vraiment solide pour choisir Kinesis.

Kinesis prend en charge plusieurs capacités de consommateurs, ce qui signifie que les mêmes enregistrements de données peuvent être traités en même temps ou à des heures différentes dans les 24 heures chez différents consommateurs, un comportement similaire dans SQS peut être obtenu en écrivant dans plusieurs files d'attente et les consommateurs peuvent lire à partir de plusieurs files d'attente. Cependant, réécrire dans plusieurs files d'attente ajoutera une latence de sous secondes {quelques millisecondes} dans le système.

Deuxièmement, Kinesis offre une capacité de routage pour acheminer sélectivement les enregistrements de données vers différentes partitions à l'aide d'une clé de partition qui peut être traitée par des instances EC2 particulières et peut permettre le calcul de micro-lots {Comptage et agrégation}.

Travailler sur n'importe quel logiciel AWS est facile, mais avec SQS, c'est le plus simple. Avec Kinesis, il est nécessaire de provisionner suffisamment de partitions à l'avance, en augmentant dynamiquement le nombre de partitions pour gérer la charge de pointe et en diminuant pour réduire les coûts également nécessaires à la gestion. c'est la douleur dans Kinesis, aucune telle chose n'est requise avec SQS. SQS est évolutif à l'infini.

La sémantique de ces technologies est différente car elles ont été conçues pour prendre en charge différents scénarios:

• SNS / SQS: les éléments du flux ne sont pas liés les uns aux autres
• Kinesis: les éléments du flux sont liés les uns aux autres

Comprenons la différence par l'exemple.

1. Supposons que nous ayons un flux de commandes, pour chaque commande, nous devons réserver du stock et planifier une livraison. Une fois cette opération terminée, nous pouvons supprimer l'article du flux en toute sécurité et commencer à traiter la commande suivante. Nous sommes pleinement terminé avec la commande précédente avant de commencer la suivante.
2. Encore une fois, nous avons le même flux de commandes, mais maintenant notre objectif est de regrouper les commandes par destination. Une fois que nous avons, disons, 10 commandes au même endroit, nous voulons les livrer ensemble (optimisation de la livraison). Maintenant, l'histoire est différente: lorsque nous obtenons un nouvel élément du flux, nous ne pouvons pas terminer le traitement; nous «attendons» plutôt que d'autres articles arrivent pour atteindre notre objectif. De plus, si le processus du processeur tombe en panne, nous devons "restaurer" l'état (donc aucune commande ne sera perdue).

Une fois que le traitement d'un élément ne peut pas être séparé du traitement d'un autre, nous devons avoir la sémantique Kinesis afin de gérer tous les cas en toute sécurité.

Extrait de la documentation AWS :

Nous recommandons Amazon Kinesis Streams pour les cas d'utilisation avec des exigences similaires aux suivantes:

• Routage des enregistrements liés vers le même processeur d'enregistrement (comme dans le streaming MapReduce). Par exemple, le comptage et l'agrégation sont plus simples lorsque tous les enregistrements d'une clé donnée sont acheminés vers le même processeur d'enregistrement.

• Commande des enregistrements. Par exemple, vous souhaitez transférer les données de journal de l'hôte d'application vers l'hôte de traitement / d'archivage tout en conservant l'ordre des instructions de journal.

• Possibilité pour plusieurs applications de consommer le même flux simultanément. Par exemple, vous avez une application qui met à jour un tableau de bord en temps réel et une autre qui archive les données sur Amazon Redshift. Vous voulez que les deux applications consomment les données du même flux simultanément et indépendamment.

• Possibilité de consommer les enregistrements dans le même ordre quelques heures plus tard. Par exemple, vous disposez d'une application de facturation et d'une application d'audit qui s'exécutent quelques heures derrière l'application de facturation. Étant donné qu'Amazon Kinesis Streams stocke les données jusqu'à 7 jours, vous pouvez exécuter l'application d'audit jusqu'à 7 jours après l'application de facturation.

Nous recommandons Amazon SQS pour les cas d'utilisation avec des exigences similaires aux suivantes:

• Sémantique de la messagerie (comme l'acquittement / échec au niveau du message) et le délai d'expiration de la visibilité. Par exemple, vous disposez d'une file d'attente d'éléments de travail et souhaitez suivre la réussite de chaque élément indépendamment. Amazon SQS suit l'accusé de réception / échec, de sorte que l'application n'a pas à maintenir un point de contrôle / curseur persistant. Amazon SQS supprimera les messages ayant reçu un accusé de réception et redistribuera les messages ayant échoué après un délai de visibilité configuré.

• Délai de message individuel. Par exemple, vous avez une file d'attente de travaux et devez planifier des travaux individuels avec un délai. Avec Amazon SQS, vous pouvez configurer des messages individuels avec un délai pouvant aller jusqu'à 15 minutes.

• Augmentation dynamique de la concurrence / du débit au moment de la lecture. Par exemple, vous disposez d'une file d'attente de travail et souhaitez ajouter d'autres lecteurs jusqu'à ce que l'arriéré soit éliminé. Avec Amazon Kinesis Streams, vous pouvez passer à un nombre suffisant de partitions (notez cependant que vous devrez provisionner suffisamment de partitions à l'avance).

• Tirer parti de la capacité d'Amazon SQS à évoluer de manière transparente. Par exemple, vous mettez en mémoire tampon les demandes et les changements de charge en raison de pics de charge occasionnels ou de la croissance naturelle de votre entreprise. Étant donné que chaque demande mise en mémoire tampon peut être traitée indépendamment, Amazon SQS peut évoluer de manière transparente pour gérer la charge sans aucune instruction de provisionnement de votre part.

Le plus grand avantage pour moi est le fait que Kinesis est une file d'attente rejouable, et SQS ne l'est pas. Ainsi, vous pouvez avoir plusieurs consommateurs des mêmes messages de Kinesis (ou le même consommateur à des moments différents) alors qu'avec SQS, une fois qu'un message a été acquitté, il est sorti de cette file d'attente. SQS est mieux pour les files d'attente de travail à cause de cela.

Autre chose: Kinesis peut déclencher un Lambda, contrairement à SQS. Donc, avec SQS, vous devez soit fournir une instance EC2 pour traiter les messages SQS (et y faire face en cas d'échec), soit vous devez avoir un Lambda planifié (qui n'augmente ni ne diminue - vous n'en obtenez qu'un par minute) .

Edit: Cette réponse n'est plus correcte. SQS peut déclencher directement Lambda à partir de juin 2018

https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html

Les modèles de tarification sont différents, donc selon votre cas d'utilisation, l'un ou l'autre peut être moins cher. En utilisant le cas le plus simple (sans compter SNS):

• SQS facture par message (chaque 64 Ko compte pour une demande).
• Kinesis facture par partition par heure (1 partition peut gérer jusqu'à 1000 messages ou 1 Mo / seconde) et également pour la quantité de données que vous insérez (tous les 25 Ko).

En branchant les prix actuels et en ne tenant pas compte du niveau gratuit, si vous envoyez 1 Go de messages par jour à la taille de message maximale, Kinesis coûtera beaucoup plus cher que SQS (10,82 $ / mois pour Kinesis contre 0,20 $ / mois pour SQS) . Mais si vous envoyez 1 To par jour, Kinesis est un peu moins cher (158 $ / mois contre 201 $ / mois pour SQS).

Détails: SQS facture 0,40 USD par million de requêtes (64 Ko chacune), soit 0,00655 USD par Go. À 1 Go par jour, c'est un peu moins de 0,20 USD par mois; à 1 To par jour, cela représente un peu plus de 201 $ par mois.

Kinesis facture 0,014 USD par million de requêtes (25 Ko chacune), soit 0,00059 USD par Go. À 1 Go par jour, c'est moins de 0,02 USD par mois; à 1 To par jour, c'est environ 18 $ par mois. Cependant, Kinesis facture également 0,015 USD par heure de partition. Vous avez besoin d'au moins 1 partition par 1 Mo par seconde. À 1 Go par jour, 1 fragment suffira, ce qui ajoutera 0,36 USD de plus par jour, pour un coût total de 10,82 USD par mois. À 1 To par jour, vous aurez besoin d'au moins 13 fragments, ce qui ajoute 4,68 USD supplémentaires par jour, pour un coût total de 158 USD par mois.

Kinesis résout le problème de la partie de carte dans un scénario typique de réduction de carte pour la diffusion de données. Bien que SQS ne s'en assure pas. Si vous avez des données de streaming qui doivent être agrégées sur une clé, Kinesis s'assure que toutes les données de cette clé vont à une partition spécifique et la partition peut être consommée sur un seul hôte, ce qui facilite l'agrégation sur la clé par rapport à SQS.

J'ajouterai une autre chose que personne d'autre n'a mentionnée - SQS est plusieurs ordres de grandeur plus cher.

Cas d'utilisation de Kinesis

• Collecte de données de journaux et d'événements
• Analyse en temps réel
• Capture de données mobiles
• Flux de données «Internet des objets»

Cas d'utilisation SQS

• Intégration d'applications
• Découplage des microservices
• Allouer des tâches à plusieurs nœuds de calcul
• Découpler les demandes des utilisateurs en direct du travail en arrière-plan intensif
• Messages par lots pour traitement futur