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

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.