Architecture Kafka expliquée : Composants principaux et leurs rôles

L'architecture Kafka peut sembler confuse au premier abord car le même système gère le stockage, le streaming, la réplication et la progression des consommateurs. Une fois que vous séparez les parties principales, le modèle devient beaucoup plus simple : les producteurs écrivent des enregistrements dans des partitions de sujets, les courtiers stockent ces partitions, et les consommateurs lisent les enregistrements par décalage.

Ce guide explique les composants principaux de Kafka et comment ils fonctionnent ensemble dans un cluster réel.

Courtiers : Les serveurs Kafka

Un cluster Kafka est composé d'un ou plusieurs courtiers. Un courtier est un serveur Kafka qui stocke les données de partition et gère les requêtes des clients, producteurs et consommateurs.

Lorsqu'un producteur envoie un enregistrement, il écrit sur le courtier qui dirige actuellement la partition cible. Lorsqu'un consommateur lit des enregistrements, il les récupère auprès du courtier qui sert cette partition. Dans les configurations normales, chaque courtier gère de nombreuses partitions provenant de nombreux sujets.

Ajouter des courtiers peut augmenter la capacité de stockage et répartir le trafic, mais cela ne résout pas automatiquement tous les goulots d'étranglement. Vous avez également besoin de suffisamment de partitions, d'un placement équilibré des répliques, de disques sains et de capacité réseau.

Sujets : Flux nommés d'enregistrements

Un sujet est un flux nommé d'enregistrements, comme commandes, paiements ou activite_utilisateur. Les producteurs écrivent dans des sujets, et les consommateurs s'abonnent à des sujets.

Un sujet est divisé en partitions. Chaque partition est un journal append-only ordonné. Kafka garantit l'ordre des enregistrements au sein d'une seule partition, pas sur l'ensemble du sujet.

Ce détail est important. Si tous les événements pour un client doivent être traités dans l'ordre, utilisez une clé stable comme client_id. Le partitionneur par défaut de Kafka utilise la clé pour choisir une partition, donc les enregistrements avec la même clé vont normalement dans la même partition.

Partitions et décalages

Chaque enregistrement dans une partition reçoit un décalage. Le décalage est un nombre qui identifie la position de l'enregistrement dans cette partition.

Par exemple, un sujet nommé commandes avec trois partitions pourrait ressembler à ceci :

commandes-0 : décalage 0, décalage 1, décalage 2
commandes-1 : décalage 0, décalage 1
commandes-2 : décalage 0, décalage 1, décalage 2, décalage 3

Les décalages ne sont significatifs qu'à l'intérieur de leur propre partition. Le décalage 3 dans commandes-2 n'est pas lié au décalage 3 dans une autre partition.

Les partitions offrent le parallélisme à Kafka. Plus de partitions permettent à plus de consommateurs dans le même groupe de consommateurs de travailler en même temps, jusqu'à un consommateur actif par partition au sein de ce groupe.

Réplication et leaders

Kafka utilise la réplication pour maintenir les données disponibles lorsqu'un courtier tombe en panne. Chaque partition peut avoir plusieurs répliques sur différents courtiers.

Une réplique est le leader. Les producteurs et les consommateurs communiquent normalement avec le leader pour cette partition. Les autres répliques sont des suiveurs. Les suiveurs copient les données du leader et restent prêts à prendre le relais si le leader tombe en panne.

Le facteur de réplication contrôle le nombre de copies que Kafka conserve. Un facteur de réplication de 3 signifie que Kafka stocke trois copies de chaque partition sur trois courtiers, lorsque suffisamment de courtiers sont disponibles.

Vous pouvez créer un sujet comme ceci :

kafka-topics.sh --create \
  --topic activite_utilisateur \
  --bootstrap-server localhost:9092 \
  --partitions 3 \
  --replication-factor 3

Cette commande nécessite un cluster avec au moins trois courtiers. Sur une configuration locale à un seul courtier, utilisez un facteur de réplication de 1.

Producteurs : Applications qui écrivent des événements

Les producteurs envoient des enregistrements aux sujets Kafka. Un enregistrement peut inclure une clé, une valeur, un horodatage et des en-têtes.

Le producteur demande d'abord au cluster des métadonnées pour savoir quel courtier dirige chaque partition. Ensuite, il envoie les enregistrements directement au bon courtier.

La fiabilité du producteur dépend fortement de paramètres tels que :

Paramètre	Ce qu'il affecte
acks	Combien d'accusés de réception du courtier sont requis avant qu'une écriture soit considérée comme réussie
retries	Si le producteur réessaie les échecs transitoires
enable.idempotence	Aide à éviter les doublons causés par les nouvelles tentatives du producteur
compression.type	Réduit l'utilisation du réseau et du disque pour de nombreuses charges de travail

Pour les données importantes, acks=all est courant car le leader attend les répliques synchronisées avant d'accuser réception de l'écriture. Le comportement exact dépend également des paramètres du courtier tels que min.insync.replicas.

Consommateurs et groupes de consommateurs

Les consommateurs lisent les enregistrements des sujets. La plupart des consommateurs en production fonctionnent au sein d'un groupe de consommateurs.

Au sein d'un groupe de consommateurs, Kafka attribue chaque partition à un seul consommateur actif à la fois. C'est ainsi que Kafka permet de mettre à l'échelle le traitement tout en préservant l'ordre au sein de chaque partition.

Par exemple, si commandes a trois partitions et que votre service a trois consommateurs dans le même groupe, chaque consommateur peut traiter une partition. Si vous ajoutez un quatrième consommateur au même groupe, un consommateur restera inactif car il n'y a que trois partitions à attribuer.

Différents groupes de consommateurs obtiennent des lectures indépendantes. Votre service de facturation et votre service d'analyse peuvent tous deux lire le sujet commandes sans se voler des enregistrements.

Décalages et progression des consommateurs

Les consommateurs suivent la progression en validant les décalages. Kafka stocke les décalages validés pour les groupes de consommateurs dans un sujet interne nommé __consumer_offsets.

Si un consommateur plante et redémarre, il utilise le décalage validé pour reprendre. Le moment de la validation affecte le comportement de traitement :

Moment de la validation	Résultat possible
Valider avant la fin du traitement	Un plantage peut sauter des enregistrements
Valider après la fin du traitement	Un plantage peut retraiter des enregistrements

De nombreux systèmes choisissent un traitement au moins une fois : traiter l'enregistrement, puis valider le décalage. Cela peut créer des doublons après un plantage, donc les écritures en aval doivent être idempotentes lorsque c'est possible.

Métadonnées du cluster : ZooKeeper et KRaft

Les anciens clusters Kafka utilisent Apache ZooKeeper pour gérer les métadonnées du cluster et l'élection du contrôleur. De nombreuses installations existantes fonctionnent encore de cette manière.

Les déploiements Kafka plus récents peuvent utiliser le mode KRaft, le quorum de métadonnées intégré de Kafka. Dans les clusters KRaft, Kafka ne dépend plus de ZooKeeper pour la gestion des métadonnées.

Lorsque vous lisez d'anciens tutoriels Kafka, vérifiez s'ils supposent ZooKeeper ou KRaft. Les commandes, les fichiers de configuration et les étapes opérationnelles peuvent différer.

Comment un enregistrement se déplace dans Kafka

Un flux typique d'écriture et de lecture ressemble à ceci :

1. Un producteur se connecte à un courtier d'amorçage et récupère les métadonnées.
2. Le producteur choisit une partition en fonction de la clé de l'enregistrement ou de la stratégie de partitionnement.
3. Le producteur envoie l'enregistrement au courtier leader pour cette partition.
4. Le leader ajoute l'enregistrement à son journal et les suiveurs le répliquent.
5. Le leader accuse réception de l'écriture en fonction du paramètre acks du producteur.
6. Un consommateur interroge la partition et reçoit les enregistrements à partir de son décalage actuel.
7. Le consommateur traite les enregistrements et valide les décalages pour son groupe de consommateurs.

Ce flux explique pourquoi Kafka peut prendre en charge à la fois le traitement en temps réel et la relecture. Les consommateurs ne suppriment pas les enregistrements lorsqu'ils les lisent.

Rétention : Kafka conserve les données selon une politique

Kafka n'est pas une file d'attente traditionnelle où un message disparaît dès qu'un consommateur le lit. Kafka conserve les enregistrements en fonction des paramètres de rétention.

Les paramètres courants des sujets incluent :

retention.ms=604800000
retention.bytes=10737418240

retention.ms contrôle la rétention basée sur le temps. retention.bytes contrôle la rétention basée sur la taille. Le nettoyage réel dépend également des paramètres de segment et de la configuration du courtier.

Certains sujets utilisent la compaction de journal au lieu de, ou en plus de, la rétention basée sur la suppression. La compaction conserve la dernière valeur pour chaque clé, ce qui est utile pour les sujets de type état comme les profils utilisateur ou les modifications de configuration.

Ce qu'il faut retenir

L'architecture de Kafka est construite autour de journaux partitionnés. Les courtiers stockent les partitions, les producteurs écrivent sur les leaders de partition, les consommateurs lisent par décalage, et les groupes de consommateurs répartissent le travail entre les partitions.

Lorsque vous concevez un sujet Kafka, réfléchissez à l'ordre, au nombre de partitions, au facteur de réplication, à la rétention et au comportement du groupe de consommateurs ensemble. Ces choix façonnent la façon dont votre système évolue, se remet des pannes et rejoue les anciens événements.