Bref aperçu d'Apache Kafka et des cas d'utilisation courants, des outils actuels pour faire évoluer les déploiements multi-clusters et des solutions de connectivité pour simplifier les déploiements multi-clusters.  Table des matières  Qu’est-ce que Kafka ?  Kafka et Kubernetes  Les arguments en faveur de Kafka multicluster  Kafka multi-cluster  Clusters étendus - Réplication synchrone  Clusters connectés - Réplication asynchrone  Conclusion  Qu’est-ce que Kafka ?  Communément connue simplement sous le nom de   , Apache Kafka est une plateforme de streaming d'événements open source gérée par Apache Software Foundation. Initialement conçu sur   , Apache Kafka a été créé en collaboration par   ,   et   , puis publié en tant que projet open source en 2011.  Kafka LinkedIn Jay Kreps Neha Narkhede Jun Rao Page Wiki  Aujourd'hui, Kafka est l'une des plateformes de streaming d'événements les plus populaires, conçue pour gérer des flux de données en temps réel. Il est largement utilisé pour créer des pipelines de données en streaming évolutifs, tolérants aux pannes et hautes performances.  Les utilisations de Kafka s'étendent continuellement, avec les 5 principaux cas joliment illustrés par   dans l'image ci-jointe.  Brij Pandey  En guise de brève introduction, il est important de comprendre les composants de la plateforme Kafka et leur fonctionnement.  Kafka fonctionne comme une plateforme de streaming d'événements distribués, conçue pour gérer efficacement les flux de données en temps réel. Il fonctionne sur la base du modèle de messagerie publication-abonnement et suit une architecture distribuée et tolérante aux pannes. Il conserve une séquence persistante, ordonnée et partitionnée d'enregistrements appelés « sujets ». Les producteurs écrivent des données sur ces sujets et les consommateurs les lisent. Cela permet le découplage entre les producteurs et les consommateurs de données et permet à plusieurs applications de consommer indépendamment le même flux de données.   Les composants clés de Kafka incluent :    Kafka organise les données en sujets. Chaque rubrique est un flux d'enregistrements et les données d'une rubrique sont divisées en plusieurs partitions. Chaque partition est une séquence ordonnée et   d'enregistrements. Les partitions permettent l'évolutivité horizontale et le parallélisme en permettant aux données d'être distribuées sur plusieurs courtiers Kafka. Sujets et partitions : immuable    : les producteurs sont des applications qui écrivent des données dans des sujets Kafka. Ils publient des enregistrements sur des sujets spécifiques, qui sont ensuite stockés dans les partitions du sujet. Les producteurs peuvent envoyer explicitement des enregistrements à une partition particulière ou permettre à Kafka de déterminer la partition à l'aide d'une stratégie de partitionnement. Producteurs    : les consommateurs sont des applications qui lisent les données des sujets Kafka. Ils s'abonnent à une ou plusieurs rubriques et consomment les enregistrements des partitions auxquelles ils sont affectés. Les groupes de consommateurs sont utilisés pour faire évoluer la consommation, et chaque partition d'un sujet ne peut être consommée que par un seul consommateur au sein d'un groupe. Cela permet à plusieurs consommateurs de travailler en parallèle pour traiter les données de différentes partitions du même sujet. Consommateurs    : Kafka fonctionne comme un cluster de serveurs, et chaque serveur est appelé un courtier. Les courtiers sont responsables du traitement des demandes de lecture et d'écriture des producteurs et des consommateurs, ainsi que de la gestion des partitions de sujets. Un cluster Kafka peut disposer de plusieurs courtiers pour répartir la charge et garantir la tolérance aux pannes. Courtiers    : Pour obtenir la tolérance aux pannes et la durabilité des données, Kafka permet de configurer la réplication pour les partitions de sujet. Chaque partition peut avoir plusieurs répliques, une réplique étant désignée comme leader et les autres comme suiveurs. La réplique principale gère toutes les demandes de lecture et d'écriture pour cette partition, tandis que les suiveurs répliquent les données du leader pour rester synchronisés. Si un courtier doté d'une réplique leader échoue, l'un des suiveurs devient automatiquement le nouveau leader pour garantir un fonctionnement continu. Partitions/Réplication    : Kafka maintient le concept de décalages pour chaque partition. Un décalage représente un identifiant unique pour un enregistrement dans une partition. Les consommateurs gardent une trace de leur compensation actuelle, ce qui leur permet de reprendre leur consommation là où ils l'avaient laissée en cas de panne ou de retraitement. Gestion des décalages    : Bien qu'il ne fasse pas partie de Kafka lui-même, ZooKeeper est souvent utilisé pour gérer les métadonnées et coordonner les courtiers dans un cluster Kafka. Il facilite l'élection des dirigeants, les informations sur les sujets et les partitions, ainsi que la gestion de la coordination des groupes de consommateurs. [Remarque :     ] ZooKeeper l'outil de gestion des métadonnées Zookeeper sera bientôt supprimé au profit de  , ou KRaft, un protocole pour les métadonnées gérées en interne Kafka Raft  Dans l'ensemble, la conception et l'architecture de Kafka en font une plate-forme hautement évolutive, tolérante aux pannes et efficace pour gérer de grands volumes de flux de données en temps réel. Il est devenu un composant central de nombreuses applications et infrastructures de données basées sur les données, facilitant l'intégration des données, le traitement des événements et l'analyse des flux.     Une architecture Kafka typique serait alors la suivante :  Le clustering Kafka fait référence à la pratique consistant à exécuter plusieurs courtiers Kafka ensemble en tant que groupe pour former un cluster Kafka. Le clustering est un aspect fondamental de l'architecture de Kafka, offrant plusieurs avantages, notamment l'évolutivité, la tolérance aux pannes et la haute disponibilité. Un cluster Kafka est utilisé pour gérer des flux de données à grande échelle et garantir que le système reste opérationnel même en cas de panne.  Dans le cluster, les sujets Kafka sont divisés en plusieurs partitions pour garantir l'évolutivité et le parallélisme. Chaque partition est une séquence d’enregistrements immuables et ordonnés linéairement. Les partitions permettent donc de répartir les données sur plusieurs courtiers du cluster.  Il convient de noter qu'un cluster Kafka minimum est constitué de 3 courtiers Kafka, chacun pouvant être exécuté sur un serveur distinct (virtuel ou physique). Les conseils à 3 nœuds visent à éviter un scénario de partage du cerveau en cas de défaillance d'un courtier.  Kafka et Kubernetes  À mesure que de plus en plus d’entreprises adoptent Kafka, le déploiement de Kafka sur Kubernetes suscite également un intérêt croissant.  En fait, le dernier   de Dynatrace montre que plus de 40 % des grandes organisations gèrent leur plate-forme de messagerie open source au sein de   , la majorité étant Kafka.  rapport Kubernetes in the Wild 2023 Kubernetes    . Source  Le même rapport affirme également avec audace que « Kubernetes est en train de devenir le « système d'exploitation » du cloud.  Il est donc impératif que les administrateurs Kafka comprennent l'interaction entre Kafka et Kubernetes et comment les mettre en œuvre de manière appropriée à grande échelle.  Les arguments en faveur de Kafka multicluster  L'exécution d'un cluster Kafka dans une seule configuration de cluster Kubernetes est assez simple et permet l'évolutivité nécessaire en théorie. En production cependant, le tableau peut devenir un peu trouble.  Il faut distinguer l’utilisation du terme   entre Kafka et Kubernetes. Un déploiement Kubernetes utilise également le terme   pour désigner un regroupement de nœuds connectés, appelé cluster Kubernetes. Lorsque la charge de travail Kafka est déployée sur Kubernetes, vous vous retrouverez avec un cluster Kafka exécuté à l'intérieur d'un cluster Kubernetes, mais plus pertinent pour notre discussion, vous pouvez également avoir un cluster Kafka qui s'étend sur plusieurs clusters Kubernetes - pour la résilience, les performances et la souveraineté des données. etc. cluster cluster  Pour commencer, Kafka n'est pas conçu pour les configurations multi-locataires. En termes techniques, Kafka ne comprend pas des concepts tels que les espaces de noms Kubernetes ou l'isolation des ressources. Au sein d’un sujet particulier, il n’existe pas de mécanisme simple pour appliquer des restrictions d’accès de sécurité entre plusieurs groupes d’utilisateurs.  De plus, différentes charges de travail peuvent avoir des exigences de fréquence de mise à jour et d'échelle différentes, par exemple une application par lots ou une application en temps réel. La combinaison des deux charges de travail en un seul cluster pourrait entraîner des impacts négatifs ou consommer beaucoup plus de ressources que nécessaire.  La souveraineté des données et la conformité réglementaire peuvent également imposer des restrictions sur la colocalisation des données et des sujets dans une région ou une application spécifique.  La résilience est bien sûr un autre moteur important derrière la nécessité de plusieurs clusters Kafka. Même si les clusters Kafka sont conçus pour la tolérance aux pannes des sujets, nous devons néanmoins prévoir une défaillance catastrophique d'un cluster entier. Dans de tels cas, la nécessité d’un cluster entièrement répliqué permet une planification appropriée de la continuité des activités.  Pour les entreprises qui migrent leur charge de travail vers le cloud ou qui ont une stratégie de cloud hybride, vous souhaiterez peut-être configurer plusieurs clusters Kafka et effectuer une migration planifiée de la charge de travail au fil du temps plutôt qu'une migration Kafka risquée à grande échelle.  Ce ne sont là que quelques-unes des raisons pour lesquelles, dans la pratique, les entreprises doivent créer plusieurs clusters Kafka qui doivent néanmoins interagir les uns avec les autres.  Kafka multi-cluster  Afin d'avoir plusieurs clusters Kafka connectés les uns aux autres, les éléments clés d'un cluster doivent être répliqués vers les autres clusters. Ceux-ci incluent les sujets, les compensations et les métadonnées. En termes Kafka, cette duplication est considérée comme du Mirroring. Il existe deux approches de configurations multiclusters possibles.   ou    Clusters étendus clusters connectés.   Clusters étendus - Réplication synchrone  Un cluster étendu est un cluster logique « étendu » sur plusieurs clusters physiques. Les sujets et les réplicas sont répartis sur les clusters physiques, mais comme ils sont représentés comme un cluster logique, les applications elles-mêmes ne sont pas conscientes de cette multiplicité.  Les clusters étendus ont une forte cohérence et sont plus faciles à gérer et à administrer. Étant donné que les applications ignorent l’existence de plusieurs clusters, elles sont plus faciles à déployer sur des clusters étendus que sur des clusters connectés.  L’inconvénient des clusters étendus est qu’ils nécessitent une connexion synchrone entre les clusters. Ils ne sont pas idéaux pour un déploiement de cloud hybride et nécessiteront un quorum d'au moins 3 clusters pour éviter un scénario de « partage du cerveau ».   Clusters connectés - Réplication asynchrone  Un cluster connecté, en revanche, est déployé en connectant plusieurs clusters indépendants. Ces clusters indépendants peuvent fonctionner dans différentes régions ou plates-formes cloud et sont gérés individuellement.  Le principal avantage du modèle de cluster connecté est qu'il n'y a pas de temps d'arrêt en cas de panne de cluster, puisque les autres clusters fonctionnent de manière indépendante. Chaque cluster peut également être optimisé pour ses ressources particulières.  Le principal inconvénient des clusters connectés est qu’ils reposent sur une connexion asynchrone entre les clusters. Les sujets répliqués entre les clusters ne sont pas « copiés lors de l'écriture » mais dépendent plutôt de   Cela peut entraîner une éventuelle perte de données pendant le processus de mise en miroir asynchrone. la cohérence éventuelle.  De plus, les applications qui fonctionnent sur des clusters connectés doivent être modifiées pour prendre en compte les multiples clusters.  Avant d'aborder la solution à cette énigme, je couvrirai brièvement les outils courants sur le marché pour permettre la connectivité du cluster Kafka.  Open Source Kafka lui-même est livré avec un outil de mise en miroir appelé Mirror Maker.   Mirror Maker duplique les sujets entre différents clusters via un producteur intégré. De cette manière, les données sont répliquées de manière croisée entre les clusters avec une cohérence finale, mais sans interrompre les processus individuels.  Il est important de noter que même si Mirror Maker est simple dans son concept, la configuration de Mirror Maker à grande échelle peut être tout un défi pour les organisations informatiques. La gestion des adresses IP, des conventions de dénomination, du nombre de répliques, etc. doit être effectuée correctement, sinon cela pourrait conduire à ce que l'on appelle une « réplication infinie », dans laquelle un sujet est répliqué à l'infini, conduisant à un éventuel crash.  Un autre inconvénient de Mirror Maker est le manque de configuration dynamique des listes autorisées/non autorisées pour les mises à jour. Mirror Maker ne synchronise pas non plus correctement les propriétés des sujets, ce qui en fait un casse-tête opérationnel à grande échelle lors de l'ajout ou de la suppression de sujets à répliquer. Mirror Maker 2 tente de résoudre certains de ces problèmes, mais de nombreux magasins informatiques ont encore du mal à configurer correctement Mirror Maker.  D'autres outils Open Source pour la réplication Kafka incluent Mirus de Salesforce, uReplicator d'Uber et Flink personnalisé de   . Netflix  Pour les options sous licence commerciale, Confluent propose deux options, Confluent Replicator et Cluster Linking. Confluent Replicator est essentiellement un connecteur Kafka Connect qui offre un moyen performant et résilient de copier des données de sujet entre clusters. Cluster Linking est une autre offre, développée en interne et destinée à la réplication multi-régions tout en préservant les décalages thématiques.  Malgré cela, Cluster Linking est un outil de réplication asynchrone dans lequel les données doivent traverser les frontières du réseau et traverser les voies de trafic public. Comme cela devrait être clair maintenant, la réplication Kafka est une stratégie cruciale pour les applications de production à grande échelle, la question est de savoir quelle option choisir.  Les administrateurs Kafka imaginatifs se rendront rapidement compte que vous pourriez avoir besoin de clusters connectés et de clusters étendus, ou d'une combinaison de ces déploiements, en fonction des exigences de performance et de résilience de l'application.  Ce qui est intimidant cependant, ce sont les défis exponentiels liés à la configuration des configurations de cluster et à leur gestion à grande échelle sur plusieurs clusters. Quelle est une manière plus élégante de résoudre ce cauchemar ?    d'Avesha est un moyen simple d'obtenir le meilleur des deux mondes. En créant une   directe entre les clusters ou les espaces de noms, KubeSlice évite d'avoir à configurer manuellement la connectivité individuelle entre les clusters Kafka. KubeSlice connectivité de service  À la base,   crée une passerelle réseau de couche 3 sécurisée et synchrone entre les clusters ; isolé au niveau de l’application ou de l’espace de noms. Une fois cela configuré, les administrateurs Kafka sont libres de déployer des courtiers Kafka dans n'importe lequel des clusters. KubeSlice  Chaque courtier dispose d'une connectivité synchrone avec tous les autres courtiers joints via la tranche, même si les courtiers eux-mêmes peuvent se trouver sur des clusters distincts. Cela crée effectivement un cluster étendu entre les courtiers et offre l'avantage d'une forte cohérence et de faibles frais d'administration.    Prenez votre gâteau et mangez-le aussi !  Pour ceux qui souhaitent déployer Mirror Maker dans leurs clusters, cela peut être fait avec un minimum d'effort puisque la connectivité entre les clusters est déléguée à KubeSlice. Ainsi, les applications Kafka peuvent bénéficier des avantages de la réplication synchrone (vitesse, résilience) ET asynchrone (indépendance, évolutivité) dans le même déploiement avec la possibilité de mélanger et faire correspondre les fonctionnalités selon les besoins. Cela est vrai pour les centres de données sur site, dans les cloud publics ou pour toute combinaison de ceux-ci dans une configuration hybride.   La meilleure partie est que KubeSlice est un déploiement sans interruption, ce qui signifie qu'il n'est pas nécessaire de désinstaller un outil déjà déployé. Il s'agit simplement d'établir une   et d'ajouter le déploiement Kafka sur cette   . tranche tranche  Conclusion  Ce blog a fourni un bref aperçu d'Apache Kafka et a abordé certains des cas d'utilisation les plus courants. Nous avons couvert les outils actuellement disponibles pour faire évoluer les déploiements Kafka sur plusieurs clusters et discuté des avantages/inconvénients de chacun. Enfin, l'article présente également Kubeslice, la solution émergente de connectivité de services qui simplifie les déploiements multiclusters Kafka et supprime les problèmes associés à la configuration de la réplication Kafka sur plusieurs clusters à grande échelle.   Quelques liens que les lecteurs pourraient trouver utiles :    (avant l'introduction de KubeSlice) Un ancien blog sur les meilleures pratiques exécutant Kafka sur AWS   Configuration guidée de KubeSlice   Déployer Kafka sur GKE  Également publié  ici.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

Read My Stories

Cet audio est produit dans la langue originale de l'histoire !

Maîtriser le déploiement et la réplication multi-clusters avec Kafka

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Télégramme : le pont de Crypto Island vers le continent

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Télégramme : le pont de Crypto Island vers le continent

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps