L’avenir de Zookeeper dans une architecture Kafka

Introduction

Qu’est-ce qu’Apache Zookeeper ?

Zookeeper est un service réparti sur plusieurs nœuds, à l’origine créé par Yahoo pour accéder facilement à leurs applications, et est devenu par la suite open source. Il permet de gérer et coordonner un cluster de machines, c’est-à-dire qu’il fournit un service de configuration et de synchronisation distribuée. La principale motivation de Zookeeper est de décharger les applications distribuées la responsabilité de mettre en œuvre leurs propres services de coordinations à partir de zéro. Plus de détails sur Zookeeper.

Quels sont les principaux rôles de Zookeeper dans l’infrastructure Kafka ?

Aujourd’hui la présence de Zookeeper est primordiale dans l’écosystème Kafka(cf. Schéma-2).

La surveillance du cluster

À travers des heartbeats réguliers de chaque broker, Zookeeper est capable de savoir quel broker vient d’arriver dans le cluster et quel broker est tombé. Ce mécanisme lui permet de maintenir à jour la liste des brokers disponibles dans le cluster.

Le stockage

• La persistance des informations de configurations

Il sauvegarde les configurations de tous les topics, le nombre de partition, l’ensemble des paramètres de replications (in-sync-replicas) pour chaque topic, l’emplacement de tous les replicas.

• La gestion des ACLs

Zookeeper stocke et maintient à jour les ACLs pour tous les topics afin d’avoir des contrôles d’accès sur les données du cluster.

• Le stockage des informations d’authentification SASL/SCRAM

Kafka utilise également Zookeeper pour le stockage des données d’authentification SCRAM.

La gestion des quotas

Les quotas sont nécessaires pour Kafka car ils permettent de prévenir les consommations excessives des ressources des brokers. Ils mettent des limites et empêchent certains clients de saturer, voire bloquer d’autres clients et les brokers. Ces quotas sont sauvegardés sur Zookeeper.

L’élection d’un broker contrôleur

Le contrôleur est l’une des entités les plus importantes de l’écosystème Kafka. Il a la responsabilité de maintenir la relation broker leader-follower sur toutes les partitions. Si un nœud s’arrête pour une raison quelconque, le contrôleur doit élire un nouveau leader pour chaque replicas leader sur le nœud disparu. Ainsi, chaque fois qu’un nœud contrôleur s’arrête, Zookeeper peut élire un nouveau contrôleur et il peut également être assuré qu’à un moment donné, il n’y a qu’un seul contrôleur et tous les nœuds follower sont d’accord sur cela.

Quelles sont les limites de Zookeeper dans Kafka et les motivations de sa suppression par la communauté Kafka ?

La gestion des métadonnées dans Zookeeper

Avant de rentrer dans les détails, comprenons d’abord les notions de contrôleur Kafka et de « Zookeeper watch ».

• Qu’est-ce qu’un nœud contrôleur dans Kafka ?

Un contrôleur est un broker comme tous les autres brokers du cluster Kafka avec quelques responsabilités supplémentaires. Il a en charge la gestion des partitions, le suivi des replicas et des autres brokers. Ainsi il assure le rééquilibrage des partitions et l’attribution de nouveaux leaders de partitions. Il doit y en avoir qu’un seul dans un cluster Kafka.

• Qu’est-ce qu’un « Zookeeper watch » ?

Le contrôleur est informé des changements dans Zookeeper à travers les événements « Zookeeper watch ». Il s’agit essentiellement d’un abonnement à certaines données dans ZooKeeper. Lorsque ces données changent, ZooKeeper en informera tous ceux qui y sont abonnés(cf. Schéma-3 ). Les Zookeeper watch sont essentielles pour Kafka, car ils servent d’entrée pour le contrôleur.

Les limites de la gestion des métadonnées Kafka dans Zookeeper sont essentiellement :

Le décalage entre l’état du contrôleur et l’état des autres brokers

Il peut arriver que le contrôleur envoie des modifications de certains leaders de partitions sur les brokers et que certains d’entre eux ne reçoivent pas toutes les modifications malgré plusieurs tentatives du contrôleur. Conséquence, on se retrouve avec un déphasage entre l’état du contrôleur et l’état d’autres brokers du cluster.

Le décalage entre l’état du contrôleur et l’état de Zookeeper

Pour que le contrôleur puisse suivre les modifications sur Zookeeper, il faudra qu’il crée des Zookeeper watch (dont le nombre est limité pour des raisons de performance) assignés au données auxquelles il veut suivre. Car aujourd’hui il n’est pas en mesure de suivre ces modifications à partir d’event log de Zookeeper. 

Il est possible qu’entre un événement Zookeeper watch et une lecture par le contrôleur sur un nœud Zookeeper, l’état peut avoir changé par rapport à ce qu’il était lorsque Zookeeper watch a été déclenché à l’origine. Dans certains cas, s’il n’y a pas de Zookeeper watch, le contrôleur peut ne pas être informé du changement du tout, et le redémarrage du contrôleur est souvent le seul moyen de résoudre l’écart.

Quelles sont les perspectives d’évolution de la gestion des métadonnées Kafka ?

• Plutôt que d’être stockées dans un système séparé, les métadonnées doivent être stockées dans Kafka lui-même. Cela évitera tous les problèmes associés aux écarts entre l’état du contrôleur et l’état de Zookeeper.
• Plutôt que d’envoyer des notifications aux brokers, ces derniers devraient simplement consommer les événements de métadonnées des events log. Cela garantit que les changements de métadonnées arriveront toujours dans le même ordre. Les brokers pourront stocker les métadonnées localement dans un fichier. Lorsqu’ils démarrent, ils auront seulement besoin de lire ce qui a changé depuis le contrôleur, pas l’état complet. Cela permettra de prendre en charge plus de partitions avec moins de consommation de processeur.

Zookeeper en tant que système externe à Kafka

En tant que système externe, Zookeeper est une contrainte à l’évolutivité de Kafka. L’unification du système va considérablement améliorer l’expérience de gestion de Kafka et contribuer à élargir son adoption.

Complexité du déploiement et de la configuration

ZooKeeper est un système distinct, avec sa propre syntaxe de fichier de configuration, ses outils de gestion et ses modèles de déploiement. Cela signifie que les administrateurs système doivent apprendre à gérer et déployer deux systèmes distribués distincts afin de déployer Kafka. Cela est une tâche en plus pour les administrateurs.

Risque élevé de faire des erreurs

Etant donné que les configurations Kafka et ZooKeeper sont séparées, il est facile de faire des erreurs. Par exemple, les administrateurs peuvent configurer SASL sur Kafka et penser à tort qu’ils ont sécurisé toutes les données circulant sur le réseau, il serait également nécessaire de configurer la sécurité dans le système ZooKeeper. Dans ce cas précis, unifier les deux systèmes donnerait un modèle de configuration de sécurité uniforme.

Pouvoir tester rapidement Kafka

A l’avenir, il pourrait être possible de prendre en charge un mode Kafka à nœud unique. Cela serait utile pour les personnes souhaitant tester rapidement Kafka sans démarrer plusieurs démons. La suppression de la dépendance à ZooKeeper rend cela possible.

Qu’est ce qui va changer dans l’écosystème Kafka ?

Architecture

Actuellement, un cluster Kafka contient plusieurs nœuds de broker et un système externe de nœuds ZooKeeper (comme le montre la partie gauche du Schéma-4 ). Avec la suppression de Zookeeper, ses nœuds seront remplacés par les nœuds de contrôleur (comme le montre la partie droite du Schéma-4 ). Les nœuds de contrôleur et les nœuds de broker s’exécutent dans des JVM séparés. Les nœuds de contrôleur élisent un leader unique pour la partition de métadonnées. Au lieu que le contrôleur envoie des mises à jour aux brokers, ces derniers extraient les mises à jour des métadonnées du leader.

NB : bien que les processus de contrôleur soient logiquement séparés des processus de broker, ils n’ont pas besoin d’être physiquement séparés. Dans certains cas, il peut être judicieux de déployer certains ou tous les processus de contrôleur sur le même nœud que les processus de broker. Ceci est similaire à la façon dont les processus ZooKeeper peuvent être déployés sur les mêmes nœuds que les brokers Kafka aujourd’hui dans des clusters plus petits. Toutes sortes d’options de déploiement sont possibles, y compris l’exécution dans la même JVM.

Gestion des métadonnées des brokers

Au lieu que le contrôleur envoie les mises à jour aux autres brokers, ces derniers récupèrent les mises à jour du contrôleur actif via la nouvelle API MetadataFetch. Ainsi le broker suivra les offsets des dernières mises à jour qu’il a récupéré et ne demandera que les plus récentes du contrôleur actif. Le broker conservera les métadonnées qu’il a récupérées sur le disque. Cela lui permettra de démarrer très rapidement, même s’il existe des centaines de milliers, voire des millions de partitions.

La plupart du temps, le broker ne devrait avoir besoin que de récupérer les deltas, pas l’état complet. Cependant, si le broker est trop loin derrière le contrôleur actif, ou s’il n’a pas du tout de métadonnées en cache, le contrôleur enverra un snapshot de métadonnées complet plutôt qu’une série de deltas. Le Schéma-5 est une illustration de ce changement.

Autres changements

Tableau comparatif d’autres changements tels que la gestion de l’état du broker, la transition de certaines API existantes vers le contrôleur actif, le remplacement de certains outils qui accèdent directement à Zookeeper vers des API Kafka.

	Le monde actuel	Le monde post-ZooKeeper
Enregistrement de nouveaux brokers	Les brokers s’enregistrent avec le quorum de ZooKeeper	Les brokers s’enregistreront avec le quorum du contrôleur
Suppression du broker dans les métadonnées du cluster	Si un broker perd sa session ZooKeeper, le contrôleur le supprime des métadonnées du cluster	Le contrôleur actif supprime un broker des métadonnées du cluster s’il n’a pas envoyé de heartbeats MetadataFetch depuis suffisamment longtemps.
Appartenance au cluster	Un broker qui peut contacter ZooKeeper mais qui est partitionné du contrôleur continuera à servir les demandes des utilisateurs, mais ne recevra aucune mise à jour des métadonnées. Par exemple, un producteur utilisant acks = 1 pourrait continuer à produire à un broker qui n’était plus leader mais parce qu’il est partitionné du contrôleur, il ne recevait pas la demande “LeaderAndIsrRequest” du contrôleur.	Un broker ne peut pas continuer à être membre du cluster s’il ne peut pas recevoir de mises à jour de métadonnées. Le broker sera supprimé du cluster s’il est partitionné du contrôleur.
Opérations(modifications des configurations, des ACLs, etc…)	ZooKeeper	Contrôleur
Opérations clientes	Les opérations clientes sont envoyées à un broker aléatoire	Les opérations clientes sont envoyées au contrôleur actif
L’accès direct à ZooKeeper	Certains outils et scripts contactent directement ZooKeeper	Ces outils doivent utiliser les API Kafka

Quel est le plan de compatibilité par rapport aux clients Kafka existants ?

Les clients Kafka existants vont continuer à fonctionner, parfois avec des performances un peu dégradées. Dans certains cas par exemple, les brokers peuvent avoir besoin de transmettre les demandes des anciens clients au contrôleur actif.

Pour continuer à assurer la compatibilité, une version « Bridge » de Kafka va être créée(cf. Schéma-6) où la dépendance Zookeeper est isolée. Bien que cette version ne supprime pas Zookeeper, elle éliminera la plupart des points de contact où le reste du système communique avec lui. Ainsi tous les accès à Zookeeper vont être transférés au contrôleur autant que possible. Par conséquent, bien que Zookeeper soit toujours requis pour cette version, ce sera une dépendance bien isolée.

Conclusion

Zookeeper est un outil important dans une architecture distribuée, plus particulièrement dans une infrastructure Kafka. Il permet à Kafka de se passer de certaines tâches liées à la coordination et à la gestion du cluster. Par ailleurs, étant un système externe à l’écosystème Kafka, il présente un frein quant à la gestion d’une infrastructure Kafka, de l’amélioration des performances, etc…

La suppression progressive de Zookeeper permettra à Kafka de continuer à assurer la compatibilité par rapport aux anciennes versions, et ainsi lui permettre d’évoluer pour élargir son adoption.

Merci à vous, laissez vos commentaires et continuons à discuter Kafka 🙂 . Vous pouvez également retrouver nos articles de blog ici.

Merci les “Z” pour vos précieuses relectures !

Références

• https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum
• https://medium.com/@rinu.gour123/role-of-apache-zookeeper-in-kafka-monitoring-configuration-c5bd1a7e4226
• https://zookeeper.apache.org/
• https://kafka.apache.org/

---

Nos formations officielles Confluent