Optimisation des performances de Kafka avec exemples pratiques : guide pratique pour opérateurs

Introduction

Les problèmes de performance de Kafka s'annoncent rarement. Ils se manifestent par une latence p99 qui grimpe après un déploiement, des consommateurs qui prennent du retard pendant les pics de trafic, ou des brokers qui se mettent en pause pour le ramasse-miettes au pire moment. Optimiser Kafka sans base de référence, c'est avancer à l'aveugle ; optimiser avec une base de référence mais sans plan de reprise, c'est jouer à la roulette. Ce guide suit une approche structurée : observer d'abord, modifier un seul élément à la fois, vérifier le résultat et savoir comment revenir en arrière.

Nous supposons Apache Kafka 3.x sous Linux, géré avec les outils shell standard (kafka-configs.sh, kafka-producer-perf-test.sh et autres). La même logique s'applique à Confluent Platform, Strimzi et MSK, mais les chemins des commandes et les valeurs par défaut peuvent différer. Chaque exemple utilise des paramètres fictifs comme $BROKER et $TOPIC pour éviter de coller des détails réels de cluster. Ne réutilisez pas les commandes aveuglément, surtout celles qui modifient la configuration du broker ou la rétention des topics.

Le flux de travail de cet article suit le cycle de vie d'un problème de performance : inventorier l'environnement, modifier la configuration en toute sécurité, vérifier avec des métriques, diagnostiquer les pannes et suivre une liste de contrôle opérationnelle. En chemin, nous aborderons les pièges les plus courants : mal interpréter acks, ignorer le retard des consommateurs, surprovisionner les partitions et optimiser à partir d'idées reçues plutôt que de mesures.

Inventaire des versions et de l'environnement

Avant de toucher à un réglage, sachez ce que vous utilisez. Les différentes versions de Kafka modifient les valeurs par défaut, déprécient des options et corrigent des bogues de performance. Par exemple, unclean.leader.election.enable était true par défaut avant la version 2.4 et false après ; exécuter un ancien client contre un nouveau broker peut silencieusement utiliser d'anciens paramètres par défaut. Consignez les informations suivantes dans un runbook, pas dans votre tête :

# Version du broker
kafka-broker-api-versions.sh --bootstrap-server $BROKER | head -n 1

# Configuration du topic
kafka-configs.sh --bootstrap-server $BROKER --entity-type topics --entity-name $TOPIC --describe

# Configuration du broker (broker unique)
kafka-configs.sh --bootstrap-server $BROKER --entity-type brokers --entity-name 0 --describe

La sortie attendue pour la première commande ressemble à $BROKER:9092 (id: 0 rack: null) -> (...). Si la commande se bloque ou renvoie une TimeoutException, le broker n'est pas joignable depuis votre hôte, ce qui est un prérequis pour toutes les étapes suivantes.

Enregistrez la topologie de déploiement : nombre de brokers, nombre de partitions pour les topics critiques, facteur de réplication et si vous utilisez la sensibilisation aux racks. Un cluster avec trois brokers et un topic de 30 partitions a un profil d'optimisation très différent d'une machine de développement avec un seul broker. Notez les valeurs actuelles avec un horodatage. Plus tard, quand kafka-topics.sh --describe affichera une partition supplémentaire ou un min.insync.replicas différent, vous saurez ce qui a changé.

Les limites de privilèges comptent aussi. Utilisez uniquement des informations d'identification capables de lire les configurations pour l'observation. Les modifications de configuration nécessitent des droits d'administration du broker, et si vous êtes sur MSK, la politique AWS IAM doit autoriser kafka:AlterConfig sur le cluster. Gardez des profils séparés en lecture seule et en écriture pour qu'un --alter accidentel ne passe pas avec des privilèges de production.

Chemin de configuration sûr

Le changement de performance le plus sûr est celui que vous pouvez annuler en moins d'une minute. Les configurations dynamiques des brokers via kafka-configs.sh prennent effet sans redémarrage et peuvent être annulées tout aussi rapidement. Les configurations statiques dans server.properties nécessitent un redémarrage progressif, ce qui est une opération plus lourde. Préférez les changements dynamiques lorsque l'option le permet.

Un exemple concret : le débit du producteur est limité par l'élection de leader impure lors des redémarrages du broker. Au lieu de basculer globalement unclean.leader.election.enable, vérifiez le paramètre actuel et testez sur un topic de préproduction.

Observez d'abord :

kafka-configs.sh --bootstrap-server $BROKER --entity-type topics --entity-name $TOPIC --describe | grep -i unclean

Sortie attendue : unclean.leader.election.enable=true sensitive=false synonyms={...}. Si la sortie est vide, le topic utilise la valeur par défaut du broker (false dans Kafka 2.4+).

Modifiez un élément ciblé à la fois. Pour autoriser l'élection de leader impure pour un seul topic non critique :

kafka-configs.sh --bootstrap-server $BROKER --alter --entity-type topics --entity-name $TOPIC \
  --add-config unclean.leader.election.enable=true

Vérification :

kafka-configs.sh --bootstrap-server $BROKER --entity-type topics --entity-name $TOPIC --describe

Recherchez unclean.leader.election.enable=true dans la sortie. Le retour en arrière est l'inverse :

kafka-configs.sh --bootstrap-server $BROKER --alter --entity-type topics --entity-name $TOPIC \
  --delete-config unclean.leader.election.enable

Supprimer la dérogation ramène le topic à la valeur par défaut du broker. Rayon d'impact : tout producteur ou consommateur utilisant ce topic peut désormais subir une perte de données lors d'un basculement de leader si les réplicas sont désynchronisés. N'activez cette option que sur les topics où la perte de données est acceptable, comme un flux de télémétrie non critique.

Pour les changements statiques, comme augmenter num.network.threads dans server.properties, prévoyez un redémarrage progressif. Vérifiez la valeur actuelle avec grep num.network.threads $KAFKA_HOME/config/server.properties. Si vous la doublez, surveillez NetworkProcessorAvgIdlePercent avant et après. Si le pourcentage d'inactivité reste proche de 1,0, les threads réseau n'étaient pas le goulot d'étranglement et vous devriez revenir en arrière pour éviter de gaspiller de la mémoire.

Vérification et diagnostic

Une vérification sans base de référence n'est que du bruit. Commencez par les outils de test de performance intégrés avant d'apporter des modifications, puis répétez après. Exécutez un test de débit du producteur sur un topic dédié avec un groupe de consommateurs propre.

kafka-producer-perf-test.sh \
  --topic perf-test \
  --num-records 1000000 \
  --record-size 1024 \
  --throughput -1 \
  --producer-props bootstrap.servers=$BROKER acks=1 linger.ms=10 batch.size=65536

La sortie attendue inclut les enregistrements par seconde, les Mo par seconde et la latence moyenne. Notez les chiffres. Modifiez maintenant une configuration du broker, relancez le même test et comparez. Si le débit chute de plus de 10 % ou si la latence p99 triple, le changement a été nuisible.

Pour diagnostiquer un cluster en production, kafka-consumer-groups.sh est votre premier arrêt. Le retard du consommateur est la métrique la plus utile pour la performance de bout en bout.

kafka-consumer-groups.sh --bootstrap-server $BROKER --describe --group $GROUP

Regardez la colonne LAG. Un retard qui augmente régulièrement signifie que les consommateurs ne peuvent pas suivre. Vérifiez les configurations côté consommateur comme fetch.min.bytes, fetch.max.wait.ms et max.poll.records. Si les consommateurs font de longues pauses pour le ramasse-miettes, augmenter fetch.max.wait.ms peut aider à regrouper plus de données par requête.

Côté broker, kafka-broker-api-versions.sh affiche les connexions actives et les taux de requêtes par API. Pour des métriques approfondies, utilisez JMX avec Prometheus et Grafana. Les métriques critiques du broker incluent :

• kafka.network:type=RequestMetrics,name=TotalTimeMs,request=Produce (p99)
• kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec
• kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec
• kafka.controller:type=ControllerStats,name=LeaderElectionRateAndTimeMs
• java.lang:type=GarbageCollector,name=G1 Old Generation,attribute=CollectionTime

Configurez des alertes sur la p99 des requêtes des producteurs au-dessus de 500 ms, le retard des consommateurs au-dessus de 10 000 pour les groupes critiques et le temps de pause du ramasse-miettes au-dessus de 100 ms. Sans cela, vous pilotez à l'aveugle.

Modes de défaillance et récupération

Kafka peut échouer de façons qui ressemblent à des problèmes de performance. Voici trois cas courants et comment s'en remettre.

Délais d'attente des producteurs dus à min.insync.replicas

Si les producteurs reçoivent NotEnoughReplicasException, le cluster rejette les écritures parce que moins de min.insync.replicas brokers sont en vie ou synchronisés. Vérifiez :

kafka-topics.sh --bootstrap-server $BROKER --describe --topic $TOPIC

Si la colonne ISR affiche moins que min.insync.replicas, soit un broker est en panne, soit un réplica est en retard. Récupération : remettez le broker en ligne, ou abaissez temporairement min.insync.replicas sur ce topic (en sachant que vous acceptez une durabilité moindre). Le changement est dynamique et réversible.

Tempêtes de rééquilibrage des groupes de consommateurs

Si les consommateurs rejoignent et quittent le groupe à plusieurs reprises, cherchez si max.poll.interval.ms est dépassé. Une tâche de traitement lente amène le broker à expulser le consommateur. Les journaux afficheront MemberHeartbeatException ou RebalanceInProgressException. Augmentez max.poll.interval.ms et session.timeout.ms pour ce groupe de consommateurs, mais vérifiez d'abord si le traitement est simplement trop lent pour les valeurs par défaut de Kafka. Parfois, la solution est de traiter moins par lot, pas de masquer le rééquilibrage.

Disque plein sur un broker

Un répertoire de journaux plein fait échouer les producteurs avec KafkaStorageException. Vérifiez l'utilisation du disque avec df -h. La récupération dépend de la politique de rétention du topic. Vous pouvez réduire la rétention dynamiquement :

kafka-configs.sh --bootstrap-server $BROKER --alter --entity-type topics --entity-name $TOPIC \
  --add-config retention.ms=3600000

Cela ne conserve que la dernière heure de données. Ensuite, augmentez le disque ou ajoutez plus de brokers. Une fois la pression immédiate retombée, revoyez la politique de rétention pour des valeurs permanentes.

Pour chaque défaillance, le chemin de récupération doit être testé en préproduction avant d'être nécessaire en production. Un plan de récupération qui n'a jamais été exécuté n'est qu'une hypothèse.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant et après tout changement d'optimisation de Kafka. Attribuez un responsable et une fréquence de révision pour chaque élément.

Chaque élément a un seul responsable redevable, pas un comité. La fréquence est explicite : vérifications quotidiennes du disque, examen hebdomadaire du retard, exercices trimestriels de retour en arrière. Si un élément échoue, le responsable est le premier informé.

Pièges courants

Le folklore de l'optimisation de Kafka est plein de pièges. Voici ceux qui font perdre le plus de temps.

Piège 1 : Régler num.partitions trop haut

Pourquoi cela arrive : Plus de partitions signifie plus de parallélisme, non ? Mais chaque partition est une unité de réplication, et trop de partitions augmentent l'utilisation de la mémoire, les descripteurs de fichiers et la latence de bout en bout. Un cluster avec 100 000 partitions peut devenir inutilisable.

Comment éviter : Calculez le débit attendu par partition (généralement 10 à 50 Mo/s) et dimensionnez les partitions en fonction du débit total. Surveillez UnderReplicatedPartitions et la mémoire du broker si vous augmentez les partitions.

Piège 2 : Utiliser acks=all sans comprendre le coût

Pourquoi cela arrive : acks=all offre la plus forte garantie de durabilité, donc les gens le configurent partout. Mais cela double la latence d'écriture par rapport à acks=1 dans un cluster à trois brokers. Si votre cas d'utilisation peut tolérer la perte des derniers messages lors d'un rare crash de broker, acks=1 peut être approprié.

Comment éviter : Mesurez avec kafka-producer-perf-test.sh sous les deux paramètres. Documentez le compromis dans le runbook du topic.

Piège 3 : Ignorer la configuration de récupération du consommateur

Le fetch.min.bytes=1 par défaut signifie que les consommateurs reçoivent les données dès qu'un seul octet est disponible, ce qui peut entraîner de nombreuses petites requêtes et une utilisation élevée du processeur. Augmenter fetch.min.bytes à 1024 ou plus ajoute un peu de latence mais améliore le débit et réduit la charge du broker.

Comment éviter : Évaluez le débit du consommateur avec différentes valeurs de fetch.min.bytes. Utilisez kafka-consumer-perf-test.sh si disponible, ou un consommateur personnalisé qui mesure les enregistrements par seconde.

Piège 4 : Modifier les configurations du broker sans redémarrer ou vice versa

Certaines configurations ne sont lues qu'au démarrage du broker. Modifier num.io.threads dans server.properties et exécuter kafka-configs.sh --alter ne fait rien, car num.io.threads est en lecture seule à l'exécution. Inversement, changer unclean.leader.election.enable dynamiquement mais s'attendre à ce qu'il s'applique à tous les topics existants sans dérogation par topic est incorrect.

Comment éviter : Consultez la documentation Kafka pour le Update Mode de chaque configuration. Les configurations dynamiques indiquent per-broker ou cluster-wide ; les configurations statiques indiquent read-only. Utilisez kafka-configs.sh --describe pour voir ce qui a réellement pris effet.

Piège 5 : Traiter le retard du consommateur comme un problème à masquer

Si le retard est élevé, certaines personnes augmentent max.poll.records ou diminuent max.poll.interval.ms pour faire rattraper le consommateur plus vite. Mais si le traitement du consommateur est le goulot d'étranglement, cela provoque simplement des rééquilibrages ou des erreurs de mémoire insuffisante. La cause profonde peut être une base de données en aval lente ou une transformation liée au processeur.

Comment éviter : Profilez l'application du consommateur. Utilisez jstack ou un profileur pour voir où le temps est passé. Si c'est dans le code utilisateur, l'optimisation de Kafka ne le résoudra pas.

Conclusion

L'optimisation des performances de Kafka est une boucle : mesurer, modifier, vérifier et se préparer à revenir en arrière. Les commandes de cet article vous donnent la matière première, mais c'est la discipline qui prévient les pannes. L'inventaire par version, les changements de configuration dynamiques lorsque possible, les seuils de métriques avec responsables et les chemins de récupération testés distinguent une séance d'optimisation sereine d'une lutte contre l'incendie.

Prochaine étape : choisissez un topic à faible risque dans votre cluster de préproduction, capturez les configurations actuelles et le débit de base, effectuez un seul changement dynamique (comme unclean.leader.election.enable), relancez le test de performance et comparez. Si les chiffres vont dans la bonne direction, déployez le changement avec une alerte de surveillance liée au responsable. Sinon, supprimez la dérogation et documentez pourquoi.

N'oubliez pas les dépendances : Kafka fonctionne rarement seul. Si vous optimisez Kafka mais écrivez depuis NiFi, lisez via Spark ou archivez vers HDFS, mesurez le chemin de bout en bout, pas seulement le débit du broker. Un cluster Kafka rapide isolément mais lent entre les mains de ses consommateurs n'est pas rapide du tout.