Architecture Kafka : Brokers, Topics et Partitions
Kafka est un système distribué par conception. Comprendre son architecture permet de mieux l'utiliser, le configurer et le débugger.
Cet article explique les trois composants fondamentaux : les brokers, les topics et les partitions.
Vue d'ensemble de l'architecture
Un déploiement Kafka typique ressemble à ceci :
┌─────────────────────────────────────────────────────────────┐
│ CLUSTER KAFKA │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Broker 1 │ │ Broker 2 │ │ Broker 3 │ │
│ │ │ │ │ │ │ │
│ │ ┌───────┐ │ │ ┌───────┐ │ │ ┌───────┐ │ │
│ │ │Topic A│ │ │ │Topic A│ │ │ │Topic A│ │ │
│ │ │ P0 │ │ │ │ P1 │ │ │ │ P2 │ │ │
│ │ └───────┘ │ │ └───────┘ │ │ └───────┘ │ │
│ │ │ │ │ │ │ │
│ │ ┌───────┐ │ │ ┌───────┐ │ │ ┌───────┐ │ │
│ │ │Topic B│ │ │ │Topic B│ │ │ │Topic B│ │ │
│ │ │ P0 │ │ │ │ P1 │ │ │ │ P0 │ │ │
│ │ └───────┘ │ │ └───────┘ │ │ └───────┘ │ │
│ └───────────┘ └───────────┘ └───────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
▲ │
│ │
Producteurs Consommateurs
Brokers
Qu'est-ce qu'un broker ?
Un broker est un serveur Kafka. C'est le composant qui :
- Reçoit les messages des producteurs
- Stocke les messages sur disque
- Sert les messages aux consommateurs
Chaque broker est identifié par un ID unique (entier) dans le cluster.
Cluster de brokers
Un cluster Kafka est un ensemble de brokers qui travaillent ensemble. Les avantages d'avoir plusieurs brokers :
| Avantage | Description |
|---|---|
| Capacité | Plus de brokers = plus de stockage et de throughput |
| Résilience | Si un broker tombe, les autres continuent |
| Distribution | La charge est répartie entre les brokers |
En production, un cluster comporte généralement 3 à 12 brokers minimum.
Le contrôleur
Un des brokers est élu contrôleur du cluster. Ses responsabilités :
- Gérer les assignments de partitions
- Détecter les pannes de brokers
- Élire les nouveaux leaders de partitions
Si le contrôleur tombe, un autre broker est automatiquement élu.
Topics
Définition
Un topic est une catégorie ou un flux de messages. C'est l'abstraction principale avec laquelle les applications interagissent.
Caractéristiques d'un topic :
- Identifié par un nom unique dans le cluster
- Peut recevoir des messages de plusieurs producteurs
- Peut être lu par plusieurs consommateurs
- Les messages sont ordonnés (au sein d'une partition)
Conventions de nommage
Les noms de topics suivent généralement des conventions :
# Par domaine métier
orders
payments
user-events
# Avec préfixe d'environnement
prod.orders
staging.orders
# Avec namespace d'équipe
team-checkout.orders
team-analytics.clickstream
Caractères autorisés : lettres, chiffres, points, tirets, underscores.
Rétention des messages
Contrairement aux files de messages traditionnelles, Kafka conserve les messages même après lecture. La durée de rétention est configurable :
| Configuration | Valeur par défaut | Description |
|---|---|---|
retention.ms |
604800000 (7 jours) | Durée maximale de conservation |
retention.bytes |
-1 (illimité) | Taille maximale du topic |
Les messages sont supprimés quand l'une des limites est atteinte.
Partitions
Le concept de partition
Une partition est une subdivision d'un topic. C'est le mécanisme qui permet à Kafka d'être scalable et parallélisable.
Topic "orders" avec 3 partitions :
┌─────────────────────────────────────────────────────────────┐
│ Partition 0: │ msg0 │ msg3 │ msg6 │ msg9 │ ... │
├─────────────────────────────────────────────────────────────┤
│ Partition 1: │ msg1 │ msg4 │ msg7 │ msg10 │ ... │
├─────────────────────────────────────────────────────────────┤
│ Partition 2: │ msg2 │ msg5 │ msg8 │ msg11 │ ... │
└─────────────────────────────────────────────────────────────┘
Pourquoi des partitions ?
Les partitions apportent trois bénéfices majeurs :
1. Parallélisme Plusieurs consommateurs peuvent lire différentes partitions simultanément. Plus de partitions = plus de parallélisme possible.
2. Scalabilité Les partitions sont distribuées sur plusieurs brokers. Ajouter des brokers permet de distribuer plus de partitions.
3. Ordering garanti L'ordre des messages est garanti au sein d'une partition. Les messages envoyés avec la même clé vont dans la même partition.
Offsets
Chaque message dans une partition a un offset : un identifiant séquentiel unique.
Partition 0 :
┌────┬────┬────┬────┬────┬────┬────┐
│ 0 │ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │ ← Offsets
├────┼────┼────┼────┼────┼────┼────┤
│msg │msg │msg │msg │msg │msg │msg │ ← Messages
└────┴────┴────┴────┴────┴────┴────┘
Les offsets sont :
- Immuables : une fois assigné, un offset ne change jamais
- Séquentiels : toujours croissants au sein d'une partition
- Locaux : chaque partition a sa propre séquence d'offsets
Les consommateurs utilisent les offsets pour tracker leur position de lecture.
Distribution des messages
Comment Kafka décide dans quelle partition envoyer un message ?
| Stratégie | Condition | Comportement |
|---|---|---|
| Clé spécifiée | key != null |
hash(key) % nb_partitions |
| Pas de clé | key == null |
Round-robin ou sticky partitioner |
| Partition explicite | Spécifiée par le producteur | Partition indiquée |
Important : Les messages avec la même clé vont toujours dans la même partition, garantissant leur ordre relatif.
Réplication
Facteur de réplication
Chaque partition peut être répliquée sur plusieurs brokers. Le facteur de réplication définit le nombre de copies.
Topic "orders" avec replication-factor=3 :
Broker 1 Broker 2 Broker 3
┌──────────┐ ┌──────────┐ ┌──────────┐
│ P0 (L) │ │ P0 (F) │ │ P0 (F) │
│ P1 (F) │ │ P1 (L) │ │ P1 (F) │
│ P2 (F) │ │ P2 (F) │ │ P2 (L) │
└──────────┘ └──────────┘ └──────────┘
(L) = Leader (F) = Follower
Leaders et followers
Pour chaque partition :
- Un seul leader : reçoit toutes les lectures et écritures
- Zéro ou plusieurs followers : répliquent les données du leader
Si le leader tombe en panne, un follower est automatiquement promu leader.
ISR (In-Sync Replicas)
L'ISR est l'ensemble des répliques qui sont synchronisées avec le leader. Une réplique est "in-sync" si :
- Elle a répliqué tous les messages du leader
- Elle a envoyé un heartbeat récemment
Seules les répliques dans l'ISR peuvent devenir leader en cas de panne.
Choisir le nombre de partitions
Critères de décision
Le nombre de partitions impacte directement les performances :
| Plus de partitions | Moins de partitions |
|---|---|
| Plus de parallélisme | Moins de overhead |
| Plus de throughput | Meilleure latence |
| Plus de consommateurs possibles | Failover plus rapide |
| Plus de fichiers ouverts | Moins de mémoire utilisée |
Recommandations
Règle générale : Commencer avec un nombre modéré et augmenter si nécessaire.
# Topics à faible volume
partitions = 3-6
# Topics à volume moyen
partitions = 6-12
# Topics à très haut volume
partitions = 12-50+
Formule de base pour le throughput cible :
partitions >= max(throughput_cible / throughput_par_partition,
nombre_consommateurs_max)
Résumé
| Composant | Rôle | Points clés |
|---|---|---|
| Broker | Serveur Kafka | Stockage, réception, envoi des messages |
| Topic | Catégorie de messages | Nommé, configurable, multi-producteurs/consommateurs |
| Partition | Subdivision d'un topic | Parallélisme, ordering local, offsets |
| Réplication | Copies des partitions | Tolérance aux pannes, leader/followers |
Prochaines étapes
Maintenant que vous comprenez l'architecture, passez aux articles suivants :
- Producers & Consumers : Comment envoyer et lire des messages
- Consumer Groups : Traitement parallèle et gestion des offsets
Cet article fait partie de la série "Fondamentaux Kafka" qui explique les concepts de base de manière progressive et accessible.