Kafka ou SNS ou autre chose ?

Question

Désolé si c'est une question de débutant. Mais j'essaie de comprendre ce que je dois utiliser. D'après ce que j'ai compris, Kafka est :

Apache Kafka est un système de messagerie distribué de type "publish-subscribe".

Et SNS est aussi un système de pub/sub.

Mon objectif est d'utiliser un système de messagerie de file d'attente sur AWS avec une application qui sera distribuée sur plusieurs serveurs (à propos, le langage principal est Python). Et parce que c'est sur Amazon, ma première idée était d'utiliser SNS et SQS. Mais ensuite, j'ai vu beaucoup de gens utiliser Kafka sur AWS. Quels sont les avantages de l'un par rapport à l'autre ?

Answer 1

Les cas d'utilisation de Kafka y Amazon SQS / Amazon SNS sont très différentes.

Kafka, comme vous l'avez écrit, est un système distribué de publication et d'abonnement. Il est conçu pour des débits très élevés, traitant des milliers de messages par seconde. Bien sûr, vous devez le configurer et le mettre en cluster pour vous-même. Il prend en charge plusieurs lecteurs, qui peuvent "rattraper" le flux de messages à tout moment (tant que les messages sont encore sur le disque). Vous pouvez l'utiliser à la fois comme une file d'attente (en utilisant des groupes de consommateurs) et comme un sujet.

Une caractéristique importante est qu'il n'est pas possible d'accuser sélectivement réception des messages comme étant "traités" ; la seule option est d'accuser réception de tous les messages jusqu'à un certain décalage.

SQS/SNS d'autre part :

• aucune installation/aucune maintenance
• soit une file d'attente (SQS) ou un sujet (SNS)
• diverses limitations (sur la taille, la durée de vie d'un message, etc.)
• débit limité : il est possible d'effectuer des requêtes par lots et des requêtes simultanées, mais l'obtention de débits élevés serait coûteuse.
• Je ne suis pas sûr que les messages soient répliqués, mais la garantie de livraison au moins une fois dans SQS le suggère.
• Le SNS intègre des notifications par e-mail, SMS, SQS et HTTP. Avec Kafka, vous devrez probablement le coder vous-même.
• pas de concept de "flux de messages".

Dans l'ensemble, je dirais donc que SQS/SNS est bien adapté aux tâches plus simples et aux charges de travail avec un volume de messages plus faible.

Answer 2

Il s'agit d'un compromis classique :

Outils AWS (SQS, SNS)

Il vous sera plus facile de les configurer et de les intégrer au reste de votre architecture, surtout si la plupart de celle-ci fonctionne déjà sur AWS. Ils seront aussi probablement moins chers au début, car ils ont un bon modèle de paiement au fur et à mesure, mais le coût n'évoluera pas aussi bien, vous devez donc y penser.

Apache Kafka

Ici, vous utilisez un modèle PUB/SUB distribué très populaire (pas à la mode) (c'est important si vous pensez que vous allez beaucoup évoluer). De nos jours, ce modèle semble avoir la préférence, car il est très courant d'exécuter des analyses sur les données qui passent par les tuyaux, et généralement avec une architecture SOA, vous pouvez avoir une multitude de petits services qui consomment les messages et font leur travail, sans que les données soient retirées de la file d'attente. Vous obtenez également un lot d'options de configuration, de sorte qu'en fonction de votre cas d'utilisation, vous pouvez l'adapter à vos besoins. Cela signifie plus de travail, mais un service plus optimisé à terme.

Résumé

Il s'agit là d'un compromis classique entre la rapidité et la facilité de développement et la meilleure solution, très modulaire et personnalisée, qui comporte plus de frais généraux pour la première mise en œuvre mais qui évolue mieux.

Conseils personnels

Si vous êtes en train de prototyper quelque chose, privilégiez la vitesse de développement, donc les outils AWS. Si vos besoins sont figés et nécessitent une échelle importante, prenez définitivement le temps d'utiliser kafka. Je suis également un grand partisan de l'utilisation de logiciels libres pour améliorer le monde, mais ce n'est pas le principal argument à utiliser.

Answer 3

Les points mentionnés ci-dessus sont vraiment utiles, en plus de ce qui précède.

1. Il est très difficile de faire du multi-tenant SQS/SNS, il n'y a peut-être pas de moyen de créer une file d'attente séparée pour chaque locataire (très difficile à maintenir).
2. Kafka peut être mis en cluster, il est connecté aux applications et aux bases de données en temps réel et fournit un accès clé/valeur aux données. La période de rétention pour chaque message, la distribution et la réplication sont des avantages plus importants -- Alors que SQS est plus une boîte noire, envoie un message et le récepteur, reçoit la marque qu'il a traité et supprimé.