Dépannage des goulots d'étranglement de performance courants dans Kafka : Un guide pratique

Le travail de performance Kafka devient compliqué quand chaque ralentissement est qualifié de problème Kafka. Parfois, le courtier est saturé. Parfois, les producteurs envoient de petits enregistrements non compressés. Parfois, les consommateurs attendent une base de données et Kafka n'est que le messager. Un passage de dépannage utile commence par localiser où le temps est passé : envoi du producteur, ajout et réplication du courtier, récupération du consommateur, ou traitement applicatif après la récupération.

Ce guide est conçu pour ce type d'investigation. Il se concentre sur les symptômes observables, les causes probables et les changements qui valent la peine d'être testés un par un.

Comprendre les métriques de performance Kafka

Avant de plonger dans le dépannage, il est essentiel de comprendre les métriques clés qui indiquent la santé des performances. Surveiller ces métriques régulièrement vous aidera à repérer les anomalies tôt :

• Métriques du courtier :
  • BytesInPerSec et BytesOutPerSec : Mesure le taux de données entrantes et sortantes. Des valeurs élevées peuvent indiquer une charge importante, tandis que des valeurs faibles peuvent suggérer un goulot d'étranglement ailleurs.
  • RequestQueueTimeMs : Temps moyen qu'une requête attend dans la file d'attente des requêtes. Des valeurs élevées indiquent une surcharge du courtier.
  • NetworkProcessorAvgIdlePercent : Pourcentage de temps pendant lequel les threads réseau sont inactifs. Un faible pourcentage indique une charge d'E/S réseau élevée.
  • LogFlushRateAndTimeMs : Mesure les opérations de vidage sur disque. Une latence élevée ici impacte directement la réplication du producteur et du suiveur.
  • UnderReplicatedPartitions : Nombre de partitions avec moins de réplicas que souhaité. Cela peut indiquer un retard de réplication et une perte de données potentielle.
• Métriques du producteur :
  • RecordBatchSize : Taille moyenne des lots d'enregistrements. De grands lots peuvent améliorer le débit mais augmenter la latence.
  • RecordSendRate : Nombre d'enregistrements envoyés par seconde.
  • CompressionRate : Efficacité de la compression. Des taux plus élevés signifient moins de données transférées.
• Métriques du consommateur :
  • FetchRate : Nombre de requêtes de récupération par seconde.
  • BytesConsumedPerSec : Données consommées par seconde.
  • OffsetLagMax : Le retard de décalage maximum pour un groupe de consommateurs. C'est un indicateur critique de la performance du consommateur.
• Métriques des métadonnées du contrôleur : Sur les clusters basés sur ZooKeeper, surveillez la latence des requêtes ZooKeeper et la santé de la connexion. Sur les clusters basés sur KRaft, surveillez la santé du quorum du contrôleur et la latence des requêtes de métadonnées. Les noms exacts des métriques varient selon la version de Kafka et la pile de surveillance.

Scénarios de goulots d'étranglement courants et solutions

1. Limitations de débit

Un débit limité peut se manifester par une ingestion ou une consommation lente des données, impactant la vitesse globale de vos flux d'événements.

1.1. Bande passante réseau insuffisante

• Symptômes : BytesInPerSec ou BytesOutPerSec élevés approchant les limites de l'interface réseau, débit lent du producteur/consommateur.
• Diagnostic : Surveillez l'utilisation du réseau sur les courtiers, les producteurs et les consommateurs. Comparez avec la bande passante disponible.
• Solutions :
  • Mettre à l'échelle le réseau : Mettez à niveau les interfaces réseau ou les NIC sur les machines des courtiers.
  • Distribuer la charge : Ajoutez plus de courtiers pour distribuer le trafic réseau. Assurez-vous que les sujets sont partitionnés de manière appropriée entre les courtiers.
  • Optimiser la sérialisation : Utilisez des formats de sérialisation efficaces (par exemple, Avro, Protobuf) plutôt que des formats moins efficaces (par exemple, JSON).
  • Compression : Activez la compression côté producteur (Gzip, Snappy, LZ4, Zstd) pour réduire la quantité de données envoyées sur le réseau. Par exemple, configurez votre producteur :

  # producer.properties
  compression.type=snappy
  

1.2. Goulots d'étranglement d'E/S disque

• Symptômes : Métriques LogFlushRateAndTimeMs élevées, opérations de lecture/écriture disque lentes, producteurs et suiveurs en retard.
• Diagnostic : Surveillez l'utilisation des E/S disque (IOPS, débit) sur les machines des courtiers. Kafka repose fortement sur les écritures séquentielles sur disque.
• Solutions :
  • Disques plus rapides : Utilisez des SSD ou des disques NVMe plus rapides pour les journaux Kafka. Assurez un nombre d'IOPS et un débit adéquats pour votre charge de travail.
  • Configuration RAID : Utilisez des configurations RAID qui favorisent les performances d'écriture (par exemple, RAID 0, RAID 10), mais soyez conscient des compromis en matière de redondance.
  • Disques séparés : Distribuez les journaux Kafka sur plusieurs disques physiques pour paralléliser les opérations d'E/S.
  • Ajuster log.flush.interval.messages et log.flush.interval.ms : Ces paramètres contrôlent la fréquence à laquelle les journaux sont vidés sur le disque. Bien que des valeurs plus grandes puissent améliorer le débit en réduisant la fréquence des vidages, elles augmentent le risque de perte de données si un courtier tombe en panne avant le vidage.
  • Soyez prudent avec les compromis de durabilité : Les paramètres de vidage du courtier et les acks du producteur affectent le niveau de risque de défaillance que vous acceptez. Réduire les attentes de durabilité peut réduire la latence dans certaines charges de travail, mais cela devrait être une décision commerciale avec un modèle de défaillance documenté, et non un réglage occasionnel.

1.3. Ressources insuffisantes du courtier (CPU/Mémoire)

• Symptômes : Utilisation élevée du CPU sur les courtiers, RequestQueueTimeMs élevé, NetworkProcessorAvgIdlePercent faible.
• Diagnostic : Surveillez l'utilisation du CPU et de la mémoire sur les machines des courtiers.
• Solutions :
  • Mise à l'échelle verticale : Augmentez le nombre de cœurs CPU ou la RAM sur les instances de courtier existantes.
  • Mise à l'échelle horizontale : Ajoutez plus de courtiers au cluster. Assurez-vous que les sujets sont bien partitionnés pour distribuer la charge.
  • Ajuster le tas JVM : Ajustez la taille du tas JVM pour les courtiers Kafka. Un tas trop petit peut entraîner des pauses fréquentes du garbage collection, tandis qu'un tas trop grand peut également causer des problèmes. Un point de départ courant est de 6 Go ou 8 Go pour de nombreuses charges de travail.
  • Décharger les opérations : Évitez d'exécuter d'autres applications gourmandes en ressources sur les machines des courtiers Kafka.

2. Latence élevée

Une latence élevée signifie un délai notable entre le moment où un événement est produit et celui où il est consommé.

2.1. Latence du producteur

• Symptômes : Les producteurs signalent des valeurs élevées de request.timeout.ms ou delivery.timeout.ms atteintes.
• Diagnostic : Analysez les configurations du producteur et les conditions réseau.
• Solutions :
  • Paramètre acks : acks=all attend les réplicas synchronisés requis et est généralement le bon choix lorsque la durabilité est importante. Associez-le à un min.insync.replicas raisonnable, généralement supérieur à 1 sur les sujets de production répliqués. acks=1 peut réduire l'attente, mais il accepte plus de risque de perte lors de défaillances de courtier.
  • linger.ms : Définir linger.ms sur une petite valeur (par exemple, 0-10 ms) envoie les messages immédiatement, réduisant la latence mais augmentant potentiellement la surcharge des requêtes. L'augmenter regroupe plus de messages, améliorant le débit mais augmentant la latence.
  • batch.size : Des tailles de lot plus grandes améliorent le débit mais peuvent augmenter la latence. Ajustez ce paramètre en fonction de vos exigences de latence.
  • Réseau : Assurez des chemins réseau à faible latence entre les producteurs et les courtiers.
  • Charge du courtier : Si les courtiers sont surchargés, les requêtes des producteurs s'accumuleront.

2.2. Latence du consommateur (retard de décalage)

• Symptômes : Les consommateurs signalent un OffsetLagMax significatif pour leurs groupes de consommateurs.
• Diagnostic : Surveillez le retard du groupe de consommateurs à l'aide d'outils comme kafka-consumer-groups.sh ou des tableaux de bord de surveillance.
• Solutions :
  • Mettre à l'échelle les consommateurs : Augmentez le nombre d'instances de consommateurs dans un groupe de consommateurs, jusqu'au nombre de partitions pour le sujet. Chaque instance de consommateur ne peut traiter les messages que d'une ou plusieurs partitions, et les partitions ne peuvent pas être partagées par plusieurs consommateurs du même groupe.
  • Augmenter les partitions : Si un sujet a trop peu de partitions pour suivre le rythme d'écriture du producteur, augmentez le nombre de partitions. Remarque : Il s'agit d'un changement permanent qui nécessite une réflexion approfondie car il affecte les consommateurs et les producteurs existants.

  # Exemple pour augmenter les partitions d'un sujet
  kafka-topics.sh --bootstrap-server localhost:9092 --alter --topic mon-sujet --partitions 12
  

  • Optimiser la logique du consommateur : Assurez-vous que la logique de traitement au sein de vos consommateurs est efficace. Évitez les opérations bloquantes ou les tâches de longue durée. Traitez les messages par lots si possible.
  • Configuration de la récupération : Ajustez fetch.min.bytes et fetch.max.wait.ms sur le consommateur. Un fetch.min.bytes plus grand peut améliorer le débit mais augmenter la latence, tandis que fetch.max.wait.ms contrôle combien de temps le consommateur attend les données avant de revenir même si le nombre minimum d'octets n'est pas atteint.
  • Performance du courtier : Si les courtiers sont en difficulté (disque, réseau, CPU), cela impactera directement les requêtes de récupération et le retard du consommateur.

3. Goulots d'étranglement ZooKeeper

Bien que Kafka évolue vers KRaft (Kafka Raft) pour le quorum du contrôleur, de nombreux déploiements dépendent encore de ZooKeeper. Les problèmes de ZooKeeper peuvent paralyser les opérations Kafka.

• Symptômes : Démarrage lent du courtier, problèmes de réaffectation des sujets/partitions, zk_avg_latency élevé, courtiers signalant des erreurs de connexion à ZooKeeper.
• Diagnostic : Surveillez les métriques de performance de ZooKeeper. Vérifiez les journaux ZooKeeper pour les erreurs.
• Solutions :
  • Cluster ZooKeeper dédié : Exécutez ZooKeeper sur des machines dédiées, séparées des courtiers Kafka.
  • Ressources suffisantes : Assurez-vous que les nœuds ZooKeeper disposent de suffisamment de CPU, de mémoire et d'E/S rapides (en particulier des SSD).
  • Réglage de ZooKeeper : Ajustez les paramètres tickTime, syncLimit et initLimit de ZooKeeper en fonction de votre réseau et de la taille de votre cluster.
  • Réduire le trafic ZooKeeper : Minimisez les opérations qui mettent fréquemment à jour ZooKeeper, comme la création/suppression fréquente de sujets ou le basculement agressif du contrôleur.
  • Migrer vers KRaft : Envisagez de migrer vers le mode KRaft pour éliminer la dépendance à ZooKeeper.

Meilleures pratiques pour l'optimisation des performances

• Surveiller en continu : Mettez en œuvre une surveillance et des alertes robustes pour toutes les métriques clés de Kafka et ZooKeeper.
• Ajuster les configurations : Comprenez l'impact de chaque paramètre de configuration et ajustez-les en fonction de votre charge de travail et de votre matériel spécifiques. Commencez par les valeurs par défaut raisonnables et itérez.
• Stratégie de partitionnement : Choisissez un nombre approprié de partitions par sujet. Trop peu peut limiter le parallélisme, tandis que trop peut augmenter la surcharge.
• Sélection du matériel : Investissez dans un matériel approprié, en particulier des disques rapides et une bande passante réseau suffisante, pour vos courtiers Kafka.
• Réglage du producteur et du consommateur : Optimisez batch.size, linger.ms, acks pour les producteurs, et fetch.min.bytes, fetch.max.wait.ms, max.poll.records pour les consommateurs.
• Garder Kafka à jour : Les versions plus récentes apportent souvent des améliorations de performances et des corrections de bugs.
• Tests de charge : Effectuez régulièrement des tests de charge pour simuler le trafic de production et identifier les goulots d'étranglement potentiels avant qu'ils n'impactent les systèmes en direct.

Comment mener une enquête de performance

Modifiez une couche à la fois. Si les producteurs sont lents, vérifiez d'abord les métriques du producteur telles que la latence des requêtes, la taille des lots, le taux de compression, les tentatives et l'épuisement du tampon. Si les courtiers sont lents, vérifiez le temps de file d'attente des requêtes, le pourcentage d'inactivité des threads réseau, l'attente disque, la pression du cache de pages, les partitions sous-répliquées et la stabilité du contrôleur. Si les consommateurs sont lents, vérifiez le retard par partition, le temps de traitement par lot, la latence des dépendances en aval et la fréquence des rééquilibrages.

Un exemple réel : un sujet de commandes montre un retard croissant après une campagne marketing. Le CPU du courtier est correct, les écritures disque sont correctes et les tentatives du producteur sont normales. kafka-consumer-groups.sh --describe montre qu'une partition a la majeure partie du retard. Cela pointe loin de la capacité du courtier et vers un déséquilibre de partition. Si les enregistrements sont indexés par ID client et qu'un grand client génère la plupart des événements, l'ajout de consommateurs n'aidera pas cette partition car une partition est toujours attribuée à un seul consommateur du groupe. Vous devrez peut-être modifier la stratégie d'indexation pour les données futures, diviser la charge de travail par sujet ou accélérer ce chemin de consommateur.

Un autre exemple : toutes les partitions prennent du retard ensemble, et les journaux du consommateur montrent des appels à une API de paiement prenant plusieurs secondes. Le réglage de la récupération Kafka ne résoudra pas cela. Vous avez besoin soit d'une concurrence bornée à l'intérieur du consommateur, d'une file d'attente entre Kafka et la dépendance lente, d'écritures en masse, ou d'une décision produit concernant la contre-pression et les tentatives.

Un bon réglage Kafka est principalement une mesure disciplinée. Gardez une base de référence, faites un changement, testez la charge avec des tailles et des clés d'enregistrement réalistes, puis comparez la latence p95 et p99 ainsi que le débit. La latence moyenne peut sembler correcte alors qu'un petit nombre de partitions sont déjà en retard.

Ce que je vérifie avant de modifier la configuration

Avant de régler Kafka, j'aime prouver que le goulot d'étranglement est réellement dans Kafka. Choisissez un chemin lent et tracez-le de bout en bout. Pour un événement produit, combien de temps le producteur passe-t-il à attendre la fin de l'envoi ? Combien de temps avant que l'enregistrement n'apparaisse dans le sujet ? Combien de temps avant que le consommateur ne le récupère ? Combien de temps le consommateur passe-t-il après la récupération ? Ces quatre chiffres évitent beaucoup de modifications de configuration aléatoires.

Si le temps d'envoi du producteur est élevé, inspectez le regroupement, la compression, les tentatives, les acks, delivery.timeout.ms et la latence des requêtes du courtier. Si l'ajout du courtier est lent, inspectez le disque, le réseau, le turnover ISR, les événements du contrôleur et les files d'attente de requêtes. Si la récupération du consommateur est rapide mais que le traitement est lent, arrêtez de régler les threads du courtier et regardez le code de l'application. Si tout est rapide jusqu'à une écriture en base de données en aval, Kafka n'est pas le goulot d'étranglement.

Voici un modèle réaliste. Une équipe voit une latence de bout en bout élevée et augmente la mémoire du courtier. Rien ne change. Ensuite, ils vérifient le timing du consommateur et découvrent que chaque message effectue trois appels HTTP sérialisés. Kafka livrait les lots rapidement ; le consommateur passait la plupart de son temps à attendre en dehors du cluster. La correction utile était une concurrence bornée, des délais d'attente et un chemin de lettres mortes pour les échecs répétés en aval.

Un autre modèle courant est celui des petits lots de producteur. Un service envoie un petit enregistrement JSON à la fois sans linger ni compression. Le CPU du courtier augmente, la surcharge réseau augmente et le débit est médiocre même si aucune machine ne semble complètement saturée. Un petit linger.ms, un batch.size plus grand et un format de sérialisation plus rapide peuvent améliorer le débit plus que l'ajout de courtiers. Les bonnes valeurs dépendent de la tolérance à la latence, alors testez-les avec des tailles d'enregistrement réelles au lieu de copier les valeurs par défaut d'un autre système.

Les changements de performance les plus sûrs sont réversibles et mesurables. Les paramètres côté client sont généralement plus faciles à annuler que les changements de nombre de partitions. Les changements de compression sont généralement plus faciles à tester que les changements matériels. Les augmentations de partitions peuvent être utiles, mais elles affectent l'ordre et la distribution future des clés, elles méritent donc plus d'attention qu'un changement de réglage normal côté client.