Optimisation des Partitions Kafka pour la Scalabilité et le Débit

Le nombre de partitions Kafka est l'un de ces paramètres qui semblent simples jusqu'à ce que vous deviez vivre avec. Trop peu de partitions et les consommateurs ne peuvent pas monter en charge. Trop de partitions et les brokers passent plus de temps à gérer les métadonnées, les rééquilibrages prennent plus de temps et le bruit opérationnel augmente.

Il n'existe pas de meilleur nombre universel. Un topic de paiements, un topic de flux de clics et un topic d'état client compacté ont des besoins d'ordonnancement, des tailles de messages, des paramètres de rétention et des comportements de consommation différents. La question utile n'est pas « Quel est le meilleur nombre de partitions ? » mais « De combien de partitions avons-nous besoin pour le débit, l'ordonnancement et la croissance de ce topic sans créer de surcharge inutile pour le broker ? »

Comprendre les Partitions Kafka

À la base, un topic Kafka est divisé en une ou plusieurs partitions. Chaque partition est un journal ordonné en ajout seul. Les partitions sont l'unité de parallélisme dans Kafka :

Les producteurs écrivent dans les partitions : Un producteur peut choisir une partition directement, utiliser une clé ou laisser le partitionneur distribuer les enregistrements.
Les consommateurs lisent à partir des partitions : Chaque consommateur dans un groupe de consommateurs se voit attribuer une ou plusieurs partitions à lire exclusivement. Cela garantit que les messages au sein d'une partition sont traités dans l'ordre par une seule instance de consommateur dans ce groupe.
Les brokers hébergent les partitions : Les brokers Kafka stockent les leaders et les réplicas. Un topic avec plusieurs partitions peut répartir le stockage et le trafic entre les brokers.

Caractéristiques Clés des Partitions :

Ordonnées au sein d'une partition : Les messages dans une seule partition sont toujours ordonnés. Les consommateurs d'un groupe maintiennent cet ordre.
Non ordonnées entre les partitions : Il n'y a pas d'ordre garanti des messages entre différentes partitions du même topic.
Parallélisme : Dans un groupe de consommateurs, le nombre utile de consommateurs actifs pour un topic ne peut pas dépasser le nombre de partitions. Les consommateurs supplémentaires restent inactifs pour ce topic.

Facteurs Influençant le Nombre de Partitions

Plusieurs facteurs critiques doivent être évalués lors de la décision du nombre de partitions pour un topic Kafka :

1. Exigences de Débit (Producteurs et Consommateurs)

Débit du producteur : Plus de partitions peuvent répartir les écritures entre les brokers, mais seulement si les leaders sont équilibrés et que les producteurs distribuent bien les enregistrements. Un topic avec une clé et une seule clé chaude peut toujours surcharger une partition.
Débit du consommateur : Si un seul consommateur peut traiter 2 000 messages par seconde et que le topic atteint un pic à 20 000 messages par seconde, vous avez besoin d'assez de partitions pour exécuter suffisamment de consommateurs dans le groupe. Le nombre exact dépend de la vitesse mesurée du consommateur, pas de suppositions.

2. Objectifs de Scalabilité

Croissance future : Kafka permet d'augmenter les partitions, mais réduire le nombre de partitions n'est pas une opération normale en place. Vous créez généralement un nouveau topic et migrez.
Rééquilibrage : L'ajout de partitions peut déclencher des rééquilibrages de groupes de consommateurs. Avec des consommateurs occupés, cela peut temporairement ralentir ou interrompre le traitement.
Comportement des clés : L'augmentation du nombre de partitions modifie le mappage clé-partition pour de nombreux producteurs utilisant le comportement de partitionnement par défaut. Cela peut surprendre les systèmes qui supposaient qu'une clé restait toujours sur la même partition au fil du temps.

3. Ressources du Broker

Disque : Plus de partitions signifient plus de segments de journal et plus de fichiers à gérer, surtout avec la réplication.
Réseau : La réplication et les extractions des consommateurs ajoutent du trafic. Le problème n'est pas seulement le nombre de topics, mais aussi les réplicas, la rétention, la taille des messages et le fan-out des consommateurs.
CPU et mémoire : Les brokers, les contrôleurs et les clients paient tous une certaine surcharge pour un grand nombre de partitions. Les versions modernes de Kafka gèrent mieux les grands clusters que les anciennes, mais le nombre de partitions reste un travail de planification de capacité.

4. Exigences d'Ordonnancement des Messages

Ordonnancement basé sur la clé : Si l'ordonnancement est critique et que vous utilisez une clé de message, les enregistrements avec la même clé vont généralement dans la même partition. Cela donne un ordre par clé, pas un ordre à l'échelle du topic. Une clé chaude atterrit toujours sur une seule partition et peut créer un goulot d'étranglement pour un consommateur.
Pas d'ordonnancement strict : Si un ordonnancement strict des messages n'est pas une exigence, vous pouvez distribuer les messages plus librement entre les partitions, en priorisant le débit et le parallélisme.

5. Scalabilité du Groupe de Consommateurs

Comme mentionné, le nombre de partitions détermine le nombre maximum de consommateurs pouvant lire simultanément à partir d'un topic au sein d'un groupe de consommateurs. Si vous devez augmenter votre consommation en ajoutant plus d'instances de consommateurs, vous devez avoir au moins autant de partitions que le nombre souhaité d'instances de consommateurs.

Une Méthode Pratique pour Choisir un Nombre de Partitions

Voici des stratégies pratiques pour vous aider à déterminer un nombre optimal de partitions :

1. Commencez par une Base de Référence et Surveillez

Une base de référence utile commence par le parallélisme des consommateurs. Si vous prévoyez quatre instances de consommateurs pour ce topic, commencer avec plus de quatre partitions laisse de la place pour le rééquilibrage et la croissance.

Exemple : si vous prévoyez d'exécuter quatre consommateurs, vous pourriez commencer avec huit partitions. Cela permet à chaque consommateur de posséder deux partitions, et vous pouvez ajouter quelques consommateurs supplémentaires avant de repartitionner. C'est un point de départ, pas une règle absolue.

Surveillez en continu votre cluster Kafka et le retard des consommateurs. Si vous observez un retard élevé des consommateurs qui ne peut pas être résolu en ajoutant plus d'instances de consommateurs (parce que vous avez atteint la limite de partitions), c'est un indicateur clair que vous devez augmenter le nombre de partitions.

2. Calculez en Fonction du Débit Attendu

Vous pouvez estimer les partitions nécessaires à partir du débit mesuré :

Formule : Nombre de Partitions = (Débit Total Attendu / Débit par Instance de Consommateur) * Marge
- Débit total attendu : Utilisez le taux de production de pointe, pas la moyenne quotidienne.
- Débit par instance de consommateur : Mesurez votre consommateur réel avec des tailles de messages réelles et des appels en aval.
- Marge : Ajoutez une marge pour les pics et la croissance. Évitez de prétendre que le calcul est exact.

Exemple :

Débit de pointe attendu : 50 000 messages par seconde
Débit d'une seule instance de consommateur : 5 000 messages par seconde
Marge : 1,5x
(50 000 / 5 000) * 1,5 = 15

Dans ce cas, 16 partitions est un point de départ raisonnable et arrondi. Si l'ordonnancement, la capacité du broker ou la distribution des clés s'opposent à ce nombre, ajustez-le.

3. Tenez Compte des Capacités et Limites du Broker

Soyez conscient du nombre total de partitions dans le cluster. Il n'existe pas de nombre sûr de partitions par broker qui s'applique partout. Le matériel, la version de Kafka, le facteur de réplication, la rétention, la taille des messages, la charge du contrôleur et les objectifs de récupération après panne sont tous importants.

Au lieu de traiter « 100 partitions par broker » ou « 1 000 partitions par broker » comme une vérité universelle, suivez les métriques du broker : latence des requêtes, E/S disque, santé du contrôleur, partitions sous-répliquées, pression sur le cache de pages et durée de rééquilibrage. Utilisez les limites testées de votre plateforme si votre organisation en a.

4. Distribution des Clés et Partitions Chaudes

Si vous utilisez des clés de message, analysez la distribution des clés avant de décider que « plus de partitions » résoudra le débit. Quelques clés dominantes peuvent créer des partitions chaudes. Le broker hébergeant le leader travaille plus dur, et le consommateur assigné à cette partition prend du retard.

Solution : Si vous prévoyez des partitions chaudes, envisagez des stratégies comme :
- Utiliser une clé moins asymétrique lorsque l'ordonnancement métier le permet.
- Utiliser une clé composite, comme customer_id:event_type, si cela préserve l'ordonnancement dont vous avez besoin.
- Diviser un flux de travail chaud en un topic séparé.
- Fragmenter délibérément une clé chaude, puis gérer l'ordonnancement à une portée plus étroite.

Augmenter les partitions peut aider à une large distribution. Cela ne divise pas une clé entre plusieurs consommateurs si tous les enregistrements de cette clé doivent rester ordonnés.

Création et Modification de Topics avec des Partitions

Lors de la création d'un nouveau topic, vous spécifiez le nombre de partitions.

Création d'un Topic avec un Nombre Spécifique de Partitions

En utilisant le script kafka-topics.sh :

kafka-topics.sh --create --topic my-high-throughput-topic \
  --bootstrap-server kafka-broker-1:9092,kafka-broker-2:9092 \
  --partitions 16 \
  --replication-factor 3

--partitions 16 : Définit le topic avec 16 partitions.
--replication-factor 3 : Chaque partition aura 3 réplicas sur différents brokers pour la tolérance aux pannes.

Augmentation du Nombre de Partitions sur un Topic Existant

C'est une opération courante, mais elle a des implications. Kafka permet d'augmenter le nombre de partitions pour un topic. La diminution nécessite une migration vers un autre topic.

En utilisant le script kafka-topics.sh :

kafka-topics.sh --alter --topic my-high-throughput-topic \
  --bootstrap-server kafka-broker-1:9092 \
  --partitions 24

--partitions 24 : Augmente les partitions de my-high-throughput-topic à 24.

Considérations Importantes lors de la Modification des Partitions :

Rééquilibrage des consommateurs : L'augmentation des partitions peut déclencher des rééquilibrages pour les groupes de consommateurs abonnés. Cela peut temporairement interrompre ou ralentir la consommation.
Nouvelles Partitions : Les nouvelles partitions sont ajoutées au topic. Les messages existants ne sont pas repartitionnés.
Mappage des clés : Pour les producteurs avec clés, l'ajout de partitions peut modifier l'endroit où les futurs enregistrements d'une clé sont écrits.
Ressources du broker : Assurez-vous que les brokers ont la capacité pour les leaders et réplicas supplémentaires.

Si l'ordre des clés sur l'ensemble de l'historique est important, soyez prudent. Les enregistrements existants restent dans les anciennes partitions, tandis que les nouveaux enregistrements peuvent être mappés différemment après le changement du nombre de partitions.

Métriques Qui Indiquent que le Nombre de Partitions est Erroné

Le retard du consommateur est le signal évident, mais il ne suffit pas à lui seul. Le retard peut provenir de bases de données en aval lentes, d'un mauvais code de consommateur, de petits paramètres d'extraction, d'une surcharge du broker ou d'un nombre insuffisant de partitions.

Recherchez ces schémas :

Les consommateurs sont sains, mais certaines instances sont inactives car il y a moins de partitions que de consommateurs.
Une partition a un retard beaucoup plus élevé que les autres.
Un broker porte de nombreux leaders de partitions chaudes.
La latence du producteur augmente pendant le trafic de pointe même si le cluster a des brokers de réserve.
Les rééquilibrages prennent suffisamment de temps pour affecter les objectifs de niveau de service.

Pour les groupes de consommateurs :

kafka-consumer-groups.sh --bootstrap-server kafka-broker-1:9092 \
  --describe --group my-consumer-group

Pour la disposition du topic :

kafka-topics.sh --bootstrap-server kafka-broker-1:9092 \
  --describe --topic my-high-throughput-topic

Si une seule partition est en retard, ajouter des consommateurs n'aidera pas à moins que le travail puisse être distribué sur plus de partitions.

Bonnes Pratiques et Pièges

À Faire :

Commencez par des besoins mesurés : Utilisez le nombre prévu de consommateurs, les tests de débit et la capacité du broker.
Alignez-vous sur le parallélisme des consommateurs : Assurez-vous d'avoir suffisamment de partitions pour faire évoluer efficacement vos instances de consommateurs.
Laissez de la place pour la croissance : Ajouter des partitions plus tard est possible, mais pas sans conséquences.
Comprenez la distribution des clés : Si vous utilisez des clés, analysez leur distribution pour éviter les partitions chaudes.
Tirez parti des outils de surveillance Kafka : Utilisez des outils pour suivre les métriques des topics/partitions, le retard des consommateurs et la charge des brokers.

À Ne Pas Faire :

Sur-partitionner : Trop de partitions augmentent la surcharge, peuvent ralentir les rééquilibrages et rendre la récupération après panne plus bruyante.
Sous-partitionner : Limite la scalabilité et le débit, entraînant un retard des consommateurs.
Suivre aveuglément des nombres arbitraires : Utilisez les règles empiriques uniquement comme points de départ.
Oublier la capacité du broker : Assurez-vous que vos brokers peuvent gérer le nombre total de partitions sur tous les topics.
Attendre un ordre parfait entre les partitions : Rappelez-vous que l'ordre n'est garanti qu'au sein d'une partition.

Un Processus de Décision Raisonnable

Pour un nouveau topic, je travaillerais généralement dans cet ordre :

Définir l'exigence d'ordonnancement. Par client ? Par compte ? Pas d'ordre strict ?
Mesurer ou estimer le débit de pointe du producteur et la taille des messages.
Évaluer une instance de consommateur avec des dépendances en aval réalistes.
Choisir les partitions en fonction du parallélisme nécessaire des consommateurs plus une marge de croissance.
Vérifier l'impact total sur le cluster après avoir inclus le facteur de réplication.
Surveiller le retard par partition et la charge du broker après le lancement.

Le nombre de partitions n'est pas un concours de beauté. Un topic banal avec huit partitions bien utilisées est meilleur qu'un topic avec 96 partitions principalement inactives qui ralentit chaque rééquilibrage. Choisissez le plus petit nombre qui vous donne le parallélisme et la marge de croissance dont vous avez réellement besoin.