Pourquoi devrais-je utiliser Amazon Kinesis et pas 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épond au 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é. Si vous arrivez à vous en sortir 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 AWS FAQ qui donne des exemples d'utilisation appropriée -cases pour les deux outils pour vous aider à décider:
Gardez à l'esprit que cette réponse était correcte pour juin 2015
Après avoir étudié la question pendant un certain temps, ayant la même question à l’esprit, j’ai trouvé que SQS (avec SNS) était préférable dans la plupart des cas d’utilisation, à moins que l’ordre des messages soit important pour vous (SQS ne garantit pas FIFO sur les messages).
Il y a 2 principaux avantages pour Kinesis (1): vous pouvez lire le même message à partir de plusieurs applications et (2) vous pouvez relire les messages si besoin est.
Les deux avantages peuvent être obtenus en utilisant SNS en tant que ventilateur sortant vers SQS. Cela signifie que le producteur du message n'envoie qu'un seul message à SNS. Ensuite, le SNS envoie le message à plusieurs SQS, un pour chaque application cliente. De cette façon, vous pouvez avoir autant que le consommateur que vous voulez sans penser à la capacité de sharding.
De plus, nous avons ajouté un SQS supplémentaire abonné au SNS qui conservera les messages pendant 14 jours. Normalement, personne ne lit 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 facile et offre la plupart des fonctionnalités. OMI, vous avez besoin d’un cas vraiment solide pour choisir Kinesis.
Kinesis prend en charge plusieurs fonctionnalités de consommation, 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 un délai de 24 heures pour 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 sous-seconde {quelques millisecondes} dans le système.
Deuxièmement, Kinesis fournit une capacité de routage pour acheminer des enregistrements de données sélectifs vers différents fragments à l'aide d'une clé de partition pouvant être traitée par des instances EC2 particulières et permettre le calcul de micro-lots {Comptage & 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 fournir suffisamment de fragments à l’avance, d’augmenter de manière dynamique pour gérer la charge des pointes et de réduire les coûts afin de réduire les coûts. Kinesis souffre, SQS n’exige rien de tel. SQS est infiniment évolutif.
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.
- 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 avons entièrement terminé la commande précédente avant de commencer la suivante.
- Encore une fois, nous avons le même flux de commandes, mais notre objectif est maintenant de regrouper les commandes par destination. Une fois que nous avons, par exemple, 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 dans le flux, nous ne pouvons pas terminer le traitement; nous attendons plutôt que d’autres articles nous parviennent pour atteindre notre objectif. De plus, si le processus du processeur tombe en panne, nous devons "restaurer" l'état (afin qu'aucun ordre ne soit perdu).
Une fois que le traitement d'un élément ne peut pas être séparé du traitement d'un autre, nous devons disposer de la sémantique Kinesis afin de traiter tous les cas en toute sécurité.
Extrait de documentation AWS :
Nous recommandons Amazon Kinesis Streams pour les cas d'utilisation dont les exigences sont similaires à celles-ci:
Routage des enregistrements liés vers le même processeur d’enregistrement (comme dans le cas du flux MapReduce en continu). Par exemple, le comptage et l'agrégation sont plus simples lorsque tous les enregistrements d'une clé donnée sont routés vers le même processeur d'enregistrement.
Commande de disques. Par exemple, vous souhaitez transférer les données de journal de l'hôte d'application vers l'hôte de traitement/archivage tout en conservant l'ordre des instructions du 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 dans Amazon Redshift. Vous voulez que les deux applications consomment des données du même flux simultanément et indépendamment.
Possibilité de consommer des 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 après l'application de facturation. Étant donné qu'Amazon Kinesis Streams stocke les données pendant 7 jours maximum, vous pouvez exécuter l'application d'audit jusqu'à 7 jours de retard par rapport à l'application de facturation.
Nous recommandons Amazon SQS pour les cas d'utilisation dont les exigences sont similaires à celles-ci:
Sémantique de la messagerie (telle que accusé de réception/échec au niveau du message) et délai de visibilité. Par exemple, vous avez une file d’éléments de travail et souhaitez suivre de manière indépendante la réussite de chaque élément. Amazon SQS suit l'ack/échec, de sorte que l'application ne doit pas conserver de point de contrôle/curseur persistant. Amazon SQS supprimera les messages reçus 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 retard. Avec Amazon SQS, vous pouvez configurer des messages individuels avec un délai pouvant aller jusqu'à 15 minutes.
Augmentation dynamique de la simultanéité/du débit en lecture. Par exemple, vous avez une file d'attente de travail et souhaitez ajouter plus de lecteurs jusqu'à ce que le backlog soit effacé. Avec Amazon Kinesis Streams, vous pouvez faire évoluer un nombre suffisant de fragments (notez toutefois que vous devez fournir suffisamment de fragments à l'avance).
Exploitation de la capacité d’Amazon SQS à évoluer de manière transparente. Par exemple, vous mettez en mémoire tampon les demandes et les modifications de charge résultant de pointes de charge occasionnelles ou de la croissance naturelle de votre entreprise. Étant donné que chaque demande en mémoire tampon peut être traitée indépendamment, Amazon SQS peut évoluer de manière transparente pour gérer la charge sans instructions de provisioning de votre part.
Le plus gros avantage pour moi est le fait que Kinesis est une file d'attente pouvant être rejouée, contrairement à SQS. Vous pouvez donc avoir plusieurs consommateurs des mêmes messages de Kinesis (ou le même consommateur à des moments différents). Avec SQS, une fois qu'un message a été reçu, il est parti de cette file d'attente. SQS est préférable pour les files d'attente de travailleurs à 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 la gérer en cas d’échec), soit vous devez avoir un Lambda planifié (qui ne peut pas être étendu ou réduit, 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
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 SNS):
- SQS facture par message (chaque Ko de 64 Ko équivaut à une requête).
- Kinesis est facturé par fragment et par heure (1 fragment peut gérer jusqu'à 1 000 messages ou 1 Mo/seconde) et pour la quantité de données que vous avez insérée (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 maximale du message, Kinesis coûtera beaucoup plus que SQS (10,82 USD par mois pour Kinesis contre 0,20 USD par mois pour SQS) . Mais si vous envoyez 1 TB 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 demandes (64 Ko chacune), soit 0,00655 USD par Go. À 1 Go par jour, cela représente un peu moins de 0,20 USD par mois; à 1 TB par jour, cela représente un peu plus de 201 $ par mois.
Kinesis facture 0,014 USD par million de demandes (25 Ko chacune), soit 0,00059 USD par Go. À 1 Go par jour, cela représente moins de 0,02 USD par mois; à 1 TB par jour, c'est environ 18 $ par mois. Cependant, Kinesis facture également 0,015 USD par heure. Vous avez besoin d'au moins 1 fragment pour 1 Mo par seconde. À 1 Go par jour, 1 fragment suffira, ce qui ajoutera 0,36 USD par jour, pour un coût total de 10,82 USD par mois. À 1 TB par jour, vous aurez besoin d'au moins 13 fragments, ce qui ajoute 4,68 USD 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 type de réduction de carte pour la transmission en continu de données. Tandis que SQS ne s’assure pas de cela. Si vous avez des données en streaming qui doivent être agrégées sur une clé, Kinesis s'assure que toutes les données de cette clé vont à un fragment spécifique et que le fragment peut être consommé sur un seul hôte, ce qui facilite l'agrégation sur la clé par rapport à SQS.
J'ajouterai une chose que personne d'autre n'a encore mentionnée: la SQS coûte plusieurs fois plus cher.