Prête à entrer en bourse, la licorne Confluent simplifie le streaming de données avec Apache Kafka

Disponible en open source, Apache Kafka, plateforme distribuée de diffusion de données d’événements en continu, pourrait s’inviter au Nasdaq. Confluent, l’éditeur de sa principale distribution commerciale, a annoncé il y a peu son intention d'entrer en bourse, illustrant l’attrait pour sa distribution on-premise de Kafka (Confluent Platform) mais aussi pour son offre cloud entièrement gérée de l’outil. Baptisée Confluent Cloud, celle-ci est proposée sur la marketplace respective des leaders du cloud AWS, Microsoft Azure et Google Cloud Platform.

Fondé par les concepteurs d'origine de Kafka (développé alors qu’ils travaillaient chez Linkedin), Confluent était valorisée à 4,5 milliards de dollars après son dernier tour de table en avril 2020. La licorne s’est donné pour mission de simplifier le déploiement de cet outil prisé des DevOps et connu pour sa complexité. «Malgré tous les avantages de Kafka, sa technologie est compliquée à déployer. Les clusters Kafka sur site sont difficiles à configurer, mettre à l'échelle et gérer en production. Lors de la mise en place de l'infrastructure sur site pour exécuter Kafka, vous devez provisionner les machines et configurer la plateforme», lit-on sur la page dédiée à l'outil sur le site de Google Cloud.

S’émanciper de Zookeeper

L’une des particularités de Kafka ajoutant à la complexité de son déploiement réside dans sa dépendance avec une autre solution open source: Apache Zookeeper. Les équipes de Confluent, en collaboration avec la communauté open source, souhaitent rectifier le tir en travaillant sur une version de Kafka totalement émancipée de Zookeeper. La mouture 2.8 de Kafka, tout juste publiée, propose une preview de ce mode de fonctionnement basé sur un protocole abrégé KRaft.

Mais pour comprendre le lien entre Kafka et Zookeeper, il convient d’abord d’introduire quelques éléments terminologiques liés à cette plateforme servant à collecter, traiter et stocker des flux continus de données d'événements pour de nombreux cas d’usage applicatif (monitoring des services et applications, gestion du big data généré par l’IoT, analyse de l'engagement client pour l’e-commerce, etc.)

Les bases de l'architecture de Kafka

Les experts du prestataire IT Octo expliquent que Kafka est essentiellement utilisé comme un broker de messages (bus de messages). Plusieurs instances du broker peuvent former un cluster. La façon de catégoriser ou de regrouper les messages est nommée un topic, qui peut lui-même être découpé en plusieurs partitions. «Pour être tolérant à la panne on peut décider de répliquer une partition sur plusieurs brokers. Dans un cluster, il n’y a qu’une seule partition leader à tout moment. Toutes les autres sont des réplicas», soulignent les experts d’Octo. Dans un billet de blog présentant le protocole KRaft, des développeurs de Confluent expliquent que jusqu’ici, Zookeeper était un élément essentiel du code distribué de Kafka, en fournissant le dépôt de métadonnées faisant autorité et contenant les faits les plus importants du système, tels que la localisation des partitions ou encore l'information distinguant les partitions leaders des replicas.

Deux services en un

Les architectures des deux outils sont toutefois différentes. Zookeeper se présente comme une API basée sur un système de déclencheur fichier («filesystem/trigger API»), tandis que Kafka repose sur une architecture en bus («publish–subscribe»). «Cela a conduit ceux qui exploitent le système à régler, configurer, surveiller, sécuriser et raisonner sur la communication et la performance à travers deux implémentations de logs, deux couches réseau et deux implémentations de sécurité, chacune avec des outils et des hooks de monitoring distincts. Cela devenait inutilement complexe», font observer les développeurs de Confluent. Le service remplaçant Zookeeper est décrit comme un «contrôleur de quorum» interne, où toutes les responsabilités en matière de métadonnées sont fusionnées. Rappelons que ce mode est en preview dans la version 2.8 de Kafka. Son implémentation n'étant pas encore complète, elle ne doit pas être utilisée en production.