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


164

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?

Réponses:


59

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


7
FYI docs.aws.amazon.com/AWSSimpleQueueService/latest/… SQS FIFO ne fonctionne pas avec SNS
détruisez-tout

80

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.


2
FYI: vous pouvez conserver Kinesis pendant 7 jours maximum.
Didier A.

30
Récemment, AWS a annoncé SQS FIFO [ docs.aws.amazon.com/AWSSimpleQueueService/latest/… qui peut servir à la chronologie des messages.
VijeshJain

4
commentaire super mineur - ne serait probablement pas utiliser le mot spliten SNS split the message to multiple SQSscar il ne se dégrade pas les messages en morceaux mais recopie vers plusieurs destinations.
Mobigital

2
Kinesis n'est pas adapté aux cas d'utilisation de fan-out (pub-sub) en raison des limites du nombre de lecteurs par fragment / seconde. Bien que cela ne soit pas pertinent pour l'enquête initiale, quiconque compte sur la mise à l'échelle de Kinesis à n-lecteurs devrait prendre ce fait en considération. forums.aws.amazon.com/message.jspa?messageID=760351
codeasone

2
La garantie de commande de Kinesis est par partition et non par flux. Une fois que vous avez plus d'un fragment, l'ensemble du flux n'aura aucune garantie sur la commande. Pour une file d'attente SQS, lorsque le débit est relativement faible, il est presque FIFO. Ce n'est que lorsque votre débit augmente, que l'ordre est moins suivi. Ceci concerne les files d'attente SQS classiques, pas les files d'attente FIFO.
yoroto

54

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.


11
En ce qui concerne votre explication sur le SQS. Vous pouvez réaliser un moyen facile d'envoyer le même message à plusieurs SQS en ayant un SNS devant eux.
Roee Gavirel

8
app -> sujet sns ---> sqs1, sqs2, sqs3 ...?
kartik

4
Oui, je parlais exactement de cette approche.
Roee Gavirel

@RoeeGavirel qu'en est-il des limitations de demande / seconde pour l'api sns?
Barbaros Alp

@BarbarosAlp - Je ne connais que la limitation des SMS (messages texte mobiles) qui est hors sujet ici. voici la
Roee Gavirel

43

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é.


Avec la file d'attente FIFO SQS, nous aurions les messages classés au fur et à mesure qu'ils sont envoyés. Est-ce que cela rend SQS similaire à Kinesis sur cet aspect?
Andy Dufresne

1
@AndyDufresne: cela couvre bien le scénario où l'ordre est important. Dans le cas (1) ci-dessus, vous souhaiterez peut-être traiter les commandes "dans l'ordre". Ainsi, si vous êtes en rupture de stock, les commandes ultérieures sont rejetées ou retardées. La sémantique FIFO ne résout pas le problème de la relativité fondamentale (groupement).
Konstantin Triger

35

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.


34

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.


Comment recevez-vous le message? Voulez-vous dire supprimer?
NeverEndingQueue

Oui, essentiellement. Dire que vous avez terminé avec ce message
Matthew Curry

15

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


1
-1 Pas d'accord. Bien que Kinesis puisse déclencher lambda, cela ne présente aucun avantage par rapport à un lambda SQS programmé. Ce dernier évoluera de manière transparente (c'est-à-dire que si cela prend plus d'une minute, une seconde lambda sera lancée). Le prix est par temps de calcul donc pas de différence appréciable non plus. Et si vous avez besoin de plus de 5 lambdas simultanés, ajoutez simplement plusieurs déclencheurs programmés à quelques secondes d'intervalle (en utilisant cron). Ce n'est pas une raison d'utiliser Kinesis sur SNS / SQS.
Steven de Salas

5
Je ne suis pas sûr d'être d'accord avec le désaccord;] - vous pouvez programmer un lambda / minute, ce qui vous limiterait au traitement par lots des messages arrivés à cet intervalle. Kinesis vous permettrait de lire les messages immédiatement. Ou est-ce que j'ai mal compris?
Moszi

Il y a une énorme différence entre quelques déclencheurs cloudwatch et des centaines lorsque vous devez invoquer le lambda de tirage contre SQS.
Coding Pig

14
Lambda prend désormais en charge SQS comme déclencheur!
sixty4bit

11

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.


Je ne comprends pas complètement pourquoi l'augmentation exponentielle de la taille, ici, est importante. Pouvez-vous creuser un peu plus? Il semble que vous ayez un aperçu que j'aimerais avoir. Edit En fait, en regardant la réponse d'Euguene Feingold, il semble y avoir un débat assez solide à ce sujet (?).
Thomas du

Désolé, j'ai fait quelques erreurs dans mes calculs (corrigées maintenant, j'espère).
John Velonis

d'accord, mais que faire si la taille moyenne de votre message SQS est petite, disons 1 Ko ou moins?
mcmillab

1
@mcmillab SQS facturera la même chose que votre message soit de 1 Ko ou de 64 Ko - voir la page de tarification SQS d'Amazon . Donc, si vos messages ne font que 1 Ko, SQS coûtera 64 fois plus cher que les chiffres que j'ai donnés ci-dessus si vous envoyez la même quantité totale de données. Cependant, une seule demande peut contenir jusqu'à 10 messages, donc si vous êtes en mesure de regrouper les messages, il se peut qu'elle ne soit que 6 fois plus (selon le niveau de remplissage de vos lots).
John Velonis

1
@JohnVelonis Les calculs ci-dessus pour la tarification SQS manquent un élément clé. Une attention particulière est nécessaire pour comprendre comment les demandes SQS sont facturées. 1 requête = 1 action API. Afin de traiter un seul "message", il est nécessaire d'effectuer au moins 3 actions API: 1 envoi + 1 lecture + 1 suppression. D'autres fonctionnalités SQS, telles que la modification de la visibilité, entraîneront davantage d'actions d'API. Ce multiplicateur inattendu est assez désagréable et entraîne généralement un SQS 2 à 10 fois plus cher que Kinesis Streams pour les grands ensembles de données (par exemple, le traitement de 100 millions de messages par mois).
Vlad Poskatcheev

9

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.


5

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


3
Êtes-vous sûr? D'après mes calculs, Kinesis est beaucoup plus cher, mais je n'ai jamais été doué pour utiliser Amazon Simple Price Calculator.
Didier A.

En regardant les exemples de prix actuels sur aws: Kinesis avec 267 millions de messages coûte environ 60 $, tandis que le fait de mettre ce montant de messages via SQS coûterait 107 $. Évidemment, je viens de faire une comparaison très rapide, et cela diffère grandement selon les cas d'utilisation, mais cette réponse devrait certainement mériter un certain crédit.
Moszi

1
Supposons que vous faites un éventail pour dire 2 consommateurs et 100 millions de messages par jour. Le coût SNS est de 50 $ / jour. Le coût SQS est de 40 $ / jour / consommateur ou 80 $ / jour au total. Kinesis coûte 1,4 USD / jour pour les PUT et 0,36 USD / fragment. Même avec 100 fragments (100 Mo / s en entrée, 200 Mo / s en sortie), c'est juste 3,60 $ / jour + 1,40 $ / jour. Donc Kinesis à 4 $ / jour contre SNS / SQS à 130 $ / jour.
Carlos Rendon

@Moszi Comment en êtes-vous arrivé à ce calcul? Une file d'attente SQS standard avec 15000000 messages par mois et 10 Go de transfert de données et de transfert de données ne coûte que 5,60 USD / mois, tandis qu'une charge utile de 256 Ko (SQS max) et ~ 15000000 unités PUT / mois (130 fragments) dans Kinesis coûte 1638,43 USD / mois
simoncpu

3
Je serais intéressé de savoir pourquoi il y a une telle disparité des coûts dans ce fil.
Thomas du

2

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
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.