SQS vs RabbitMQ
Je dois créer une file d'attente pour le traitement. La file d'attente elle-même est relativement peu volumineuse. Il pourrait y avoir environ 1 000 écrit par heure. L'exécution de chaque tâche peut prendre environ une minute et est traitée presque dès que l'élément est ajouté à la file d'attente.
Existe-t-il une raison quelconque pour laquelle je pourrais vouloir implémenter RabbitMQ au lieu de quelque chose disponible tel qu'Amazon SQS? Quelles sont les raisons pour lesquelles une application aurait besoin de son propre système de mise en file d'attente au lieu de quelque chose comme SQS?
Pour commencer, Amazon SQS est une pseudo-file d'attente, ce qui signifie que la livraison de chaque message (si elle atteint la file d'attente) est garantie, mais pas de la manière FIFO), ce qui se produit généralement dans une file d'attente.
Si l'ordre des messages est important pour vous et que vous souhaitez que la file d'attente fonctionne de manière FIFO, la documentation d'Amazon SQS indique de le gérer dans la logique de votre application, car les messages d'Amazon SQS vous atteindre hors séquence.
Par rapport à cela, autant que je sache, vous pouvez implémenter des files d'attente de travailleurs dans RabbitMQ. Si cela vous empêche d'implémenter le séquencement des messages en file d'attente au niveau de l'application, cette option serait préférable.
Voici quelques facteurs pour vous aider à décider lequel choisir:
Séquence de messages en file d'attente comme mentionné ci-dessus.
Vous pouvez configurer votre propre serveur avec RabbitMQ, mais pas dans le cas d'Amazon SQS, le coût est donc impliqué ici.
La mise en place de votre propre serveur nécessitera une bonne connaissance du sujet afin que vous ne laissiez aucun coin vierge. Ce n'est pas le cas avec Amazon SQS, car il est assez rapide de démarrer avec.
Votre propre serveur RabbitMQ implique des coûts de maintenance ultérieurs, ce qui n’est pas le cas avec Amazon SQS.
Mises à jour:
- Amazon SQS prend désormais en charge les files d'attente FIFO).
SQS serait ma préférence sur RabbitMQ, voici pourquoi.
- SQS est un service géré. Ainsi, vous n'avez pas à vous soucier des aspects opérationnels de l'exploitation d'un système de messagerie, notamment de l'administration, de la sécurité, de la surveillance, etc. Amazon le fera pour vous et fournira une assistance en cas de problème.
- SQS est élastique et peut s’adapter à des débits/volumes très importants (illimité selon AWS;))
- La disponibilité de SQS contient beaucoup de 9 et est supportée par Amazon, ce qui est une chose de moins à prendre en compte dans votre application.
Cependant, RabbitMQ pourrait fournir des temps de réponse plus rapides pour les options de vente et d’obtention, généralement dans des dizaines de milliers de TPS de mes tests. Pour que SQS fournisse ce type de débit, vous devez évoluer horizontalement avec plusieurs instances. Donc, si vous recherchez des options de moins de 5 ms, RabbitMQ pourrait être une option à envisager, car j’ai constaté un temps de vente proche de 20 ms à 30 ms de mes tests SQS à 1 000 TPS, ce qui est légèrement supérieur à RabbitMQ.
Nous venons de déplacer notre infrastructure de messagerie d'ActiveMQ vers SQS et nous ne pouvons être plus heureux. Nous avons constaté que cela coûtait moins cher que de maintenir notre propre cluster ActiveMQ dans le cloud.
J'espère que cela t'aides! Tiens nous au courant de comment ça se passe..
J'ai effectivement utilisé les deux dans un environnement commercial avec raisonnable.
La réponse courte est qu'à moins de cas particuliers, il est préférable d'utiliser AWS SQS. (Vous pouvez aller au bas pour un résumé simple)
Codage (lien): RabbitMQ et AWS SQS ont tous deux des bibliothèques établies et de nombreux exemples.
Délai de visibilité (SQS): SQS propose une solution, RabbitMQ est une notion plus large de délai de visibilité. Dans RabbitMQ, si un consommateur meurt avant d'acquitter, les messages sont remis dans la file d'attente. Mais SQS a une notion plus large de délai de visibilité qui n’est pas liée à un appelant spécifique. Ainsi, vous pouvez commencer une unité de travail, définir la visibilité avec un délai d’attente prolongé (jusqu’à 12 heures), déconnecter, demander à un autre travailleur de terminer et de l’accepter. Dans ma conception, nous avons largement exploité ce potentiel et éliminé tout service/stockage supplémentaire pour gérer des charges utiles potentiellement importantes en cours de traitement.
Traitement des lettres mortes (RabbitMQ - par un "lièvre") SQS fournit des informations de base sur les lettres mortes, appelées "stratégie de rediffusion" qui transfère les messages dans la file d'attente des lettres mortes (une autre file d'attente). C'est basique et n'a qu'une notion du nombre de messages. RabbitMQ dispose d'échanges de lettres mortes qui fournissent des messages envoyés au DLE lorsqu'ils expirent. Mais c’est un peu discutable car l’idée de "Si vous ne regardez pas vos services et que vos messages expirent, alors cela atterrira dans le DLE". C'est une légère victoire pour RabbitMQ car je trouve cet argument contre-intuitif. Pourquoi voudriez-vous surveiller votre file d'attente et non vos services? (Si quelque chose, c'est l'inverse)
Administration (SQS): Il n’ya pas d’administration à SQS. Vous ne payez que pour les appels d'API. Tous les maux de tête habituels tels que les correctifs de sécurité du système d'exploitation/des applications, la montée (ajout de nœuds supplémentaires), le disque sont gérés par les équipes AWS. Il est également compatible avec FedRamp (à l'usage du gouvernement). C'est vraiment un système d'installation et d'oubli. RabbitMQ nécessite des correctifs de système d’exploitation/services habituels, des AMI, des clusters, un renforcement de la sécurité, etc. Bien que cela soit extrêmement rare, les AMI peuvent tomber en panne, ou doivent parfois être déplacées, de sorte que les clusters sont nécessaires. SQS élimine tous ces maux de tête.
COÛT (SQS): un seul appel d'API SQS peut inclure un "lot allant jusqu'à 10 messages/une taille de 256 Ko" et une "interrogation longue" peut réduire considérablement le coût. En outre, il existe des stratégies telles que la compression des messages pour en envoyer des dizaines (certains prétendent des centaines ou plus) à des messages pouvant être envoyés en une seule charge utile pour réduire davantage les coûts. Et ceci avant que nous prenions en compte le temps passé par les utilisateurs à surveiller/corriger/corriger les problèmes. SQS est également idéal pour les "projets poc", car s’il reste inactif, il n’ya aucun coût.
FIFO (TIE): En 2016, AWS a introduit le support FIFO avec un coût supplémentaire d'environ 0,01 USD/million d'appels d'api (0,05 USD vs 0,04 USD par million d'alls API - avant remises). Vous pouvez choisir d'utiliser FIFO ou pas. Pour les non-FIFO, nous voyons rarement des messages en double.
Stockage (SQS): AWS ne facture pas de stockage, mais vous disposez d'une limite de 14 jours. Sur RabbitMQ, vous devrez allouer, développer et gérer de l’espace disque nécessitant une capacité de stockage maximale, ainsi que des tampons supplémentaires. C'est juste plus de maux de tête.
Métriques (SQS): SQS fournit des métriques prêtes à l'emploi. Et bien que vous puissiez les ajouter à AWS, c'est plus de travail.
Local dev (cravate): La plupart des magasins modernes aiment avoir un environnement local. Plusieurs options permettent maintenant aux dockers de RabbitMQ et SQS.
Débit élevé/message très volumineux (RabbitMQ - en quelque sorte) Lorsque vous appuyez sur SQS> 1 000 requêtes/s, la latence de SQS augmente. Il existe plusieurs stratégies pour le contourner. Mais je trouve que ces cas sont extrêmement rares car la plupart des tâches peuvent être partitionnées en plusieurs files d'attente. Mais pour ces types de cas où 100k/sec est requis, je pense que Kafka est meilleur. (Nous utilisons également Kafka dans mon travail)). avoir une seule unité de travail nécessitant plus de 1000 requêtes/seconde avec une faible latence. * Voir plus bas pour cette explication
Résumé: Si vous allez être dans AWS et que vous voulez vous marier avec AQS, alors SQS est une évidence. Mais vous devriez lire car il y a des choses importantes à considérer.
La stratégie classique de RabbitMQ (et d’autres files d’attente) consiste à créer plusieurs types de files d’attente optimisés pour certains types de travail. Réglez ensuite chacune de ces files et regroupez les travaux similaires en un petit nombre (souvent très volumineux). SQS n'ayant pas de charge administrative, il est en fait préférable d'allouer une file d'attente dédiée à chaque travail. Ce faisant, cela permet d’échelle mais élimine également la saturation de la file d’attente (travail gênant saturant la file d’attente et noyant d’autres travailleurs), permettant une meilleure vue du travail (mesures par défaut), etc.
La nouvelle stratégie a permis à mes équipes d’avoir une meilleure vision de la répartition du travail. L'époque de la "mise à niveau de l'instance pour plus de charge" est révolue. Dans le passé, nous observions un pic important inexpliqué qui aurait des effets secondaires sur d’autres services ou nous devinions simplement que les chiffres cumulés paraissaient corrects ". Maintenant que le trafic est séparé, nous avons en fait découvert de nombreux problèmes qui étaient passés inaperçus auparavant et nous pouvons clairement expliquer le volume du trafic acheminé où. Et s'il est très possible d'implémenter des métriques et des outils, SQS fournit tout cela immédiatement.
RabbitMQ devrait encore être sérieusement considéré
- Very large legacy code base that uses RabbitMQ with extensive tooling and knowledgeable support staff
- Messages that needs to be in the same work stream for > 14 days
- Very large messages that has very low latency requirements with it
- Cloud agnostic code base requirements. If you must run your code on other platforms (e.g. Azure/Google/bare metal), then SQS is not an option
- Large volume of data for a single pipeline that can't be broke up and other solutions (e.g. Kafka) are not viable. But at a super large volume, Kafka is a lot faster. While SQS will Push large payloads to S3, you are now incurring additional cost.