sheelamohanachandran - Fotolia

Actualites

Confluent veut faire passer Kafka à l’ère du multicloud

Le principal contributeur du système de messagerie open source a annoncé des fonctionnalités pour simplifier sa gestion. Kafka évolue lentement, mais sûrement pour répondre aux exigences des organisations utilisatrices du cloud.

Gaétan Raoul
par
Publié le: 25 août 2020

Lors de la conférence virtuelle Kafka Summit 2020, Confluent a déroulé son projet Metamorphosis, une initiative lancée en mai dans le but de simplifier le déploiement et le maintien à l’échelle de la plateforme de streaming de données.

L'éditeur s’apprête à ajouter en disponibilité générale un tiers de stockage et l’auto-équilibrage des clusters à sa plateforme logicielle en version 6.0 (Confluent Platform) et à son service cloud managé (Confluent Cloud). Ces deux fonctionnalités ont été présentées en janvier, puis en mai 2020.

Pour rappel, dans sa forme originelle Apache Kafka disposait d’un système de stockage particulièrement limité, ce qui obligeait à concevoir des pipelines spécifiques vers des lacs de données ou des espaces de stockage objet ainsi qu’à développer plusieurs versions d’une application pour exploiter les informations archivées.

Infinite a été présenté comme la solution pour conserver les données de manière illimitée. Confluent y associe deux tiers de stockage basés sur la KIP 405 (Kafka Improvement Proposals) d’Apache Kafka. Depuis Confluent Platform 5.4, chaque broker dispose de son stockage local et peut être associé avec un bucket Amazon S3.

Une fois qu’un broker atteint son débit limite, les données sont automatiquement archivées au sein du stockage distant. Google Cloud Storage, Azure Blob Storage et les systèmes JBOD ne sont pas encore supportés, mais les responsables du projet assurent que la fonctionnalité doit être agnostique du type de stockage objet.

Avec la version 6.0 de Confluent Platform, le tiers de stockage devra fonctionner avec tous les services mentionnés ci-dessus ainsi qu’avec HDFS. Ce n’est pourtant pas une tâche aisée : Addison Huddy, Group Product Manager chez Confluent, remarque lors d’une séance de questions - réponses que chaque système de stockage objet se comporte différemment. Pour anticiper les difficultés, l’éditeur s’associe avec des fournisseurs de stockage objet dans le cloud et sur site.

De son côté, l’auto-équilibrage des clusters doit automatiser le rééquilibrage des partitions entre les brokers « afin d’optimiser le débit de Kafka et la montée à l’échelle des brokers ». Ce système détecte les nouveaux brokers et attribue automatiquement les ressources de stockage au « bon endroit ». « Si vous ajoutez un broker, le système reconnaît la montée à l’échelle. Si vous le retirez il réduit automatiquement la voilure », vante Addison Huddy. Le temps de latence de rééquilibrage passerait de quelques heures à quelques secondes.

Cluster Linking, le pont multicloud et hybride pour Kafka

Les responsables ont surtout introduit Cluster Linking, un système de mirroring de clusters Kafka basé sur le protocole Kafka broker. Celui doit supprimer le besoin de manipuler des systèmes intermédiaires comme Confluent Replicator ou MirrorMaker.

Confluent ne s’en cache pas : ses clients sont rebutés par la complexité de connecter des clusters Kafka situés dans des centres de données ou des clouds différents. Le fait de déployer le système de messagerie en mode hybride ou en mode multicloud peut provoquer des pertes de données et surtout des problèmes de synchronisation des événements.

Cluster Linking doit répondre à ces difficultés avec un système dont le but est de vérifier que la réplique est « l’exact miroir de la source de donnée ». Cette source de données correspond à un topic. La console de Confluent permettra de choisir les topics à répliquer dans un cluster.

Cela doit permettre de transporter aisément les événements d’un cluster à un autre tout en conservant l’ordre dans lequel les données sont stockées. Les données transmises par le système pub/sub doivent ainsi « voyager » plus facilement d’un centre de données sur site vers des régions Confluent Cloud (plus précisément des clusters gérés via Kubernetes) sur AWS ou Google Cloud.

Cluster Linking fédère des instances Kafka et Confluent Cloud. Cette fonctionnalité serait particulièrement étudiée pour transférer en temps réel des données entre un serveur Confluent ou une instance Apache Kafka vers un ou des espaces Confluent Cloud. Les clusters dans Confluent Cloud peuvent être en principe répliqués de différentes régions d’un cloud.

Techniquement, les informations ne traverseraient qu’une seule fois le réseau et il est possible de limiter le trafic à un seul pipeline.

Seulement, la gestion du réseau de Cluster Linking n’est pas encore idéale. « Avec le Cluster Linking d'aujourd'hui, les connexions proviennent du cluster de destination. Mais cela n'est pas toujours souhaitable, en particulier lorsque la connexion va du cloud public vers un centre de données sur site », reconnaît Ben Stopford Lead Technologist auprès du CTO chez Confluent dans un article de blog.

Bien que le transfert soit automatisé, il faut potentiellement paramétrer le pare-feu de son entreprise. À l’avenir, l’équipe technique déclare qu’il sera possible d’établir les connexions dans un sens ou dans l’autre. Cluster Linking est compatible avec Kafka 2.4 et plus (la version 2.6 est accessible depuis le début du mois d’août). La fonctionnalité est disponible en préversion pour Confluent Platform et Confluent Cloud.

Des fonctionnalités taillées pour les cas d'usage dans le cloud public

Les clients ne réagissent pas de la même manière à ces annonces. Ravi Vankamamidi, directeur technologique chez l’agence de voyage en ligne Expedia, explique utiliser Kafka pour connecter des chatbots et des agents humains pour interagir en langage naturel avec ses clients.

« Nous avions besoin d’assembler des composants de compréhension du langage naturel (NLU), des services de traduction et de l’analytique en temps réel pour en faire un système scalable capable de servir pour plusieurs marques. […] La plateforme de messagerie Kafka et plus particulièrement Confluent Cloud répondait à nos besoins », déclare-t-il.

« Gérer soi-même Kafka n’est pas simple tandis que le service cloud l’est. Cela nous a permis de gagner six mois sur le développement et les équipes ont pu se concentrer sur le produit plutôt que sur l’infrastructure ». Il recommande toutefois de commencer petit pour bâtir l’architecture basée sur les événements.

Le géant américain de la finance Citigroup utilise Kafka sur site pour gérer des milliards de transactions par jour. Après avoir rencontré des difficultés avec l’implémentation du système de messagerie sur Kubernetes, Léon Stiel, directeur chez Citigroup, responsable du programme informatique Electronic Market-Making au niveau mondial, apprécie l’intérêt des technologies présentées, mais ne se voit pas les adopter.

« Nous travaillons dans un environnement hautement régulé et nous déployons Kafka dans un cloud privé. Les nouvelles fonctionnalités sont particulièrement pertinentes dans le cloud public. Je surveille tout de même de près le projet Metamorphosis afin de faciliter le déploiement de cluster sur nos VM et instances privées à l’horizontale, sans Zookeeper comme facteur bloquant », affirme-t-il lors de la conférence virtuelle.

Il évoque ici la difficulté que beaucoup d’entreprises à gérer Apache Zookeeper, l’API de synchronisation des ressources, dont Kafka est toujours dépendant. La proposition KIP 500 dont l’objectif est de gérer les métadonnées de Kafka à l’intérieur des clusters est toujours en développement. La mise en place du protocole correspondant est prévue lors de la sortie d’Apache Kafka 3.0.

Pour approfondir sur SaaS