Kafka ou Artemis : Comment bien choisir son broker de messages ?

Comparaison entre deux grands types de brokers suivant les cas d’usage et les contraintes rencontrés.

Système de communication asynchrone, de quoi s’agit-il ?

C’est un Système qui interroge un serveur sans attendre de réponse immédiate de sa part. Le client et le serveur n’ont pas besoin d’être disponibles au même moment.

Vous avez dit « broker de messages » ?

Une communication asynchrone ne peut se faire sans la présence d’un MOM (Message Oriented Middleware) entre le client et le serveur.  Un tel middleware va permettre de mettre en attente les messages envoyés par le client en direction du serveur, et inversement.

Le stockage et le routage des messages sont les principales fonctionnalités d’un MOM. C’est ce rôle de MOM que vont remplir les brokers de messages. Il en existe deux grands types. Certains brokers utilisent une implémentation à base de queues, quand d’autres privilégient le système de Publish/Subscribe.

Apache Artemis et les queues, ou le principe du First In First Out

Apache Artemis utilise le système de queues. Avec ce type d’Architecture, un message envoyé par un expéditeur est transmis dans une queue, où il est stocké et conservé jusqu’à qu’il soit consommé par un destinataire. Ce dernier va devoir lire la queue pour accéder au message. Le principe du First In First Out s’applique. Par conséquent, le message consommé sera celui arrivé en premier dans la queue. Cela garantie le fait que l’ordre soit conservé dans l’envoi de messages.

Après avoir consommé le message, le destinataire envoie un accusé de réception au broker qui va alors supprimer le message de la queue. Ainsi, un même message ne peut être lu qu’une seule fois et par un seul destinataire. C’est ce qu’on appelle le principe du Read Once Only Once. Seule exception, si le Système « tombe » entre la consommation du message et l’envoi de l’accusé de réception, le message sera persisté et pourra être consommé par un autre destinataire.

Apache Artemis supporte l’API JMS (Java Message Service) afin de s’interfacer avec des applications Java, et également de nombreux protocoles de messagerie comme AMQP (Advanced Message Queuing Protocol), STOMP (Streaming Text Oriented Message Protocol) ou MQTT (Message Queue Telemetry Transport).

Mais qu’est-ce qui se cache derrière Artemis ? Artemis propose deux grands fonctionnements possibles pour la haute disponibilité.

Le premier, la réplication, implique que les serveurs maîtres et les serveurs esclaves ne partagent pas le même espace de stockage. Les données sont alors synchronisées de façon synchrone entre les serveurs maîtres et les serveurs esclaves tout au long du fonctionnement du broker. Cela peut engendrer des latences lors d’un fonctionnement normal, mais en cas d’indisponibilité du serveur maître, le serveur esclave a immédiatement à sa disposition l’ensemble des données et peut ainsi être opérationnel sans délai.

Le deuxième mode, appelé « shared store » diffère de la réplication, dans le sens où les serveurs maîtres et les serveurs esclaves partagent le même espace de stockage. Si aucune latence n’est enregistrée lors d’un fonctionnement normal, du fait de l’absence d’échange de messages entre les serveurs maîtres et les serveurs esclaves, ces derniers seront obligés de charger l’ensemble des données en cas de failover des serveurs maîtres. Cela engendrera inexorablement un délai parfois non négligeable lors du failover.

Une approche différente avec Apache Kafka et le Publish/Subscribe

Avec Apache Kafka, un producteur de messages doit publier son message au sein d’un topic, tandis qu’un consommateur doit s’abonner à un topic pour pouvoir lire les messages. C’est ce qu’on appelle le Publish/Subscribe.

Apache Kafka ne supprime pas le message du topic une fois que celui-ci a été lu par un consommateur. Ainsi, plusieurs consommateurs peuvent lire le même message. La durée de vie du message dans le topic est paramétrable.

Le principe du Read Once Only Once est maintenant implémenté dans Apache Kafka. Il est donc possible, comme dans Artemis, de n’autoriser la lecture d’un message qu’une seule fois et par un seul consommateur.

Les topics sont divisés en plusieurs partitions, afin de garantir un débit en écriture et en lecture important. Le nombre de partitions est configurable pour chaque topic. Plus le besoin de rapidité en écriture et en lecture sera grand, plus le nombre de partitions par topic devra être élevé. Chaque partition est répliquée sur plusieurs serveurs pour obtenir une bonne résistance aux pannes et assurer un fonctionnement en haute disponibilité.

Contrairement à Artemis, il n’y a pas de garantie d’ordre d’arrivée des messages au sein d’un même topic.

Un message envoyé est toujours placé à la fin d’une partition. Apache Kafka lui attribue un offset qui correspond à son rang dans la partition. Depuis la version 0.8 (Décembre 2013), la gestion des états de consommation, c’est-à-dire l’offset du dernier message consommé, peut être faite par le consommateur ou le producteur, selon le paramétrage choisi. Plusieurs consommateurs, ayant des états de consommations différents, peuvent lire en même temps les messages d’une partition donnée.

Un message envoyé dans un topic ayant une durée de vie fixée, le consommateur devra être opérationnel durant cette durée de vie s’il souhaite avoir accès au message.


Comparaison des performances entre Apache Kafka et Artemis

Les performances varient énormément en fonction de nombreux facteurs comme les protocoles utilisés, le matériel, la taille des messages ou encore le nombre de producteurs et de consommateurs. Difficile de donner un chiffrage précis sur les capacités d’un broker de messages.

Des consultants Nexworld ont effectué des tests sur Artemis et Apache Kafka, avec les caractéristiques techniques suivantes :

  • 1 VM sous XenServer
  • 2vCPU
  • 8GB RAM
  • Un nœud
  • Messages de 1 Ko

Artemis a pu traiter environ 9 000 messages par seconde, quand Apache Kafka était capable d’en traiter 96 000 par seconde. Les performances de Apache Kafka semblent donc nettement plus élevées que celles d’Artemis.

Kafka est d’ailleurs aujourd’hui utilisé par des entreprises ayant de très fortes contraintes de performance et de volumétrie comme Netflix (700 milliards de messages par jour), Microsoft (400 milliards de messages par jour) ou LinkedIn (800 milliards de messages par jour).


Alors, plutôt Artemis ou plutôt Kafka ?

Le « match » entre les brokers Artemis et Apache Kafka peut s’élargir à celui entre les brokers à base de queues et ceux à base de topics. Le choix d’une solution plutôt qu’une autre dépendra du cas d’usage et du type d’Architecture souhaité.

Les deux brokers Artemis et Apache Kafka gèrent très bien la haute disponibilité.

Le Système à base de queues à l’avantage d’être simple en établissant un flux de communication transparent entre le producteur et le consommateur. Une des caractéristiques de cette solution réside dans le fait qu’un message ne peut être lu que par un seul consommateur. Dans certains cas, cela peut s’avérer fort utile. Il s’agit d’une relation one-to-one entre un producteur et un consommateur, ce qui implique un certain couplage entre les deux. Un couplage qui reste cependant lâche grâce à la présence du MOM. Artemis permet un routage automatique entre ses queues, évitant tout paramétrage « en dur ». De plus, ce broker a vocation à être couplé avec des outils comme Apache Camel, utilisé pour la transformation, l’enrichissement, l’agrégation ou encore le routage de messages entre applications et qui permet l’implémentation des fameux EIP (Entreprise Integration Patterns). C’est d’ailleurs cette association entre Apache Artemis et Apache Camel que nous avons préconisée puis implémentée chez plusieurs de nos clients.

Les topics permettent de mettre en place un flux de communication entre un producteur et plusieurs consommateurs. Le producteur publie les messages au sein d’un topic, tandis que les consommateurs lisent les messages des topics auxquels ils sont abonnés. Si aucun couplage n’existe entre producteurs et consommateurs, il faut savoir gérer l’action de plusieurs consommateurs sur un même message.

En définitive, il faudra préférer un broker comme Artemis si la relation entre producteurs et consommateurs est une relation point-à-point, ne nécessitant pas que plusieurs consommateurs attendent la réception d’un même message. Au contraire, si plusieurs consommateurs ont besoin d’avoir accès au même message, Apache Kafka est une solution plus appropriée.

En termes de performance, Apache Kafka devance largement Artemis, avec des performances de l’ordre de 10 fois supérieures. Toutefois Artemis répondra aux exigences de la plupart des cas d’usage. Le choix n’est donc pas à faire sur ces aspects (sauf cas très particuliers nécessitant une énorme exigence de performance comme des millions de messages par seconde) mais davantage sur le besoin fonctionnel et sur la nature de l’Architecture à mettre en place.

Découvrez notre formation Apache Kafka

Quentin DUSSERE

Quentin DUSSERE

Consultant Nexworld

DÉCOUVREZ COMMENT NOTRE CABINET ACCOMPAGNERA LA TRANSFORMATION DE VOTRE ENTREPRISE

Les consultants Nexworld mettent leur expertise aux services des entreprises qui veulent accélérer leur transformation numérique. Nexworld propose des séminaires adaptée aux besoins et au SI existant de votre entreprise.

Architecture Fast Data : par où commencer ?

Ce n’est plus un secret pour personne, les données sont aujourd’hui porteuses d’un potentiel incroyable avec une quantité toujours plus importante d’année en année. Pourtant, même si les entreprises sont conscientes des masses de données qu’elles ont à leur disposition, la question de savoir comment les exploiter peine toujours à être traitée.

Kafka, pierre angulaire des Architectures Fast Data ?

Comment éviter que le Big Data ne devienne un « Big Mess » ? C’est pour répondre à cette question qu’en 2009 les équipes de LinkedIn, confrontées à des problématiques d’intégration de données auxquelles les outils disponibles ne répondaient pas, élaborent un nouveau bus de messages distribué : Kafka.

Big Data : Splunk versus la Suite Elastic

Avec le Big Data et l’explosion du volume de données, une question s’impose : comment exploiter ces données et en extraire de la valeur ? Deux outils se disputent aujourd’hui la place de leader dans le domaine : Splunk (le propriétaire), et la Suite Elastic (l’open source)