Kafka ou SNS ou autre chose?
Désolé s'il s'agit d'une question pour débutant. Mais j'essaie de comprendre ce que je dois utiliser. Pour autant que je comprends Kafka est:
Apache Kafka est un système de messagerie de publication-abonnement distribué.
Et SNS est également un système 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 quelques serveurs. Par ailleurs (le langage principal est Python). Et parce que c'est sur Amazon, ma première pensée a été d'utiliser SNS et SQS. Mais j'ai vu beaucoup de gens utiliser Kafka sur AWS. Quels sont les avantages les uns par rapport aux autres?
Les cas d'utilisation pour Kafka et Amazon SQS / Amazon SNS sont très différents.
Kafka, comme vous l'avez écrit, est un système de publication-abonnement distribué. Il est conçu pour un débit très élevé, traitant des milliers de messages par seconde. Bien sûr, vous devez le configurer et le regrouper par vous-même. Il prend en charge plusieurs lecteurs, qui peuvent "rattraper" le flux de messages à tout moment (enfin, tant que les messages sont toujours sur le disque). Vous pouvez l'utiliser à la fois comme file d'attente (à l'aide de groupes de consommateurs) et comme sujet.
Une caractéristique importante est que vous ne pouvez pas reconnaître sélectivement les messages comme "traités"; la seule option est d'acquitter tous les messages jusqu'à un certain décalage.
SQS/SNS d'autre part:
- aucune configuration/aucun entretien
- soit une file d'attente (SQS) ou un sujet (SNS)
- diverses limitations (taille, durée de vie d'un message, etc.)
- débit limité: vous pouvez effectuer des requêtes par lots et simultanées, mais atteindre des débits élevés serait coûteux
- Je ne sais pas si les messages sont répliqués; cependant, la livraison garantie au moins une fois dans SQS le suggère
- SNS a des notifications pour les e-mails, SMS, SQS, HTTP intégrés. Avec Kafka, vous devrez probablement le coder vous-même
- pas de concept de "flux de messages"
Donc, dans l'ensemble, je dirais que SQS/SNS sont bien adaptés aux tâches et charges de travail plus simples avec un volume de messages inférieur.
Il s'agit d'un compromis classique:
Outils AWS (SQS, SNS)
Celles-ci seront plus faciles à configurer et à intégrer avec le reste de votre architecture, surtout si la plupart d'entre elles fonctionnent déjà sur AWS. Il sera également probablement moins cher au début, car ils ont un bon modèle de rémunération au fur et à mesure, mais le coût ne sera pas aussi élevé, alors vous devez y penser.
Apache Kafka
Ici, vous utilisez un modèle PUB/SUB très populaire (pas à la mode) distribué (ce qui est important si vous pensez que vous allez beaucoup évoluer). De nos jours, ce modèle semble être bien préféré, car l'exécution d'analyses sur les données passant par les canaux est très courante, et généralement avec une architecture SOA vous pouvez avoir une multitude de petits services consommant les messages et faire leur travail, sans que les données soient supprimées de la file d'attente. Vous obtenez également un lot d'options de configuration, donc en fonction de votre cas d'utilisation, vous pouvez affiner les données selon vos besoins. Cela signifie plus de travail , mais un service plus optimisé sur la route.
Sommaire
Il s'agit d'un compromis classique entre la vitesse de développement et la facilité de développement par rapport à la meilleure solution, très modulaire et personnalisée, qui a plus de frais généraux pour la première mise en œuvre mais évolue mieux.
Conseils personnels
Si vous prototypez 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 certainement le temps d'utiliser Kafka. Je suis également un grand partisan de l'utilisation de open-source-rend-le-monde meilleur, mais ce n'est pas le plus grand argument à utiliser.