Mise à l'échelle de Kafka : Stratégies pour un débit élevé et une faible latence

Mettre à l'échelle Kafka signifie augmenter le débit sans laisser la latence, le retard du consommateur ou la charge du courtier devenir incontrôlables. La plupart du travail de mise à l'échelle se résume aux partitions, au regroupement par lots du producteur, au parallélisme du consommateur, aux ressources du courtier et aux paramètres de réplication.

Il n'existe pas d'interrupteur unique "rendre Kafka plus rapide". Vous devez d'abord trouver le goulot d'étranglement, puis ajuster la partie du pipeline qui limite réellement votre cluster.

Comprendre les piliers de l'évolutivité de Kafka

L'évolutivité de Kafka repose sur plusieurs concepts fondamentaux :

Courtiers : Kafka répartit les partitions de sujets entre les courtiers afin que le stockage, le réseau et la charge CPU puissent être partagés.
Partitions : Une partition est l'unité d'ordonnancement et de parallélisme. Plus de partitions peuvent permettre un plus grand parallélisme du producteur et du consommateur.
Réplication : Chaque partition a un leader et des réplicas followers. La réplication améliore la disponibilité mais ajoute du travail sur le disque et le réseau.
Clients : Les paramètres du producteur et du consommateur sont souvent aussi importants que les paramètres du courtier.

Stratégies pour un débit élevé

Atteindre un débit élevé dans Kafka tourne principalement autour de la maximisation du parallélisme et de l'optimisation du flux de données.

Choisir une stratégie de partitionnement efficace

Le nombre et la conception des partitions sont essentiels pour le débit. Plus de partitions signifient généralement plus de parallélisme, mais il y a des rendements décroissants et des inconvénients potentiels.

Augmenter le nombre de partitions lorsqu'un sujet est saturé. Plus de partitions peuvent répartir la charge d'écriture et de lecture sur plus de courtiers et de consommateurs.
Choisir des clés qui évitent les partitions chaudes. Une clé comme tenant_id peut convenir si les locataires sont similaires, mais un locataire énorme peut surcharger une partition. Dans ce cas, vous pouvez avoir besoin d'une clé composée ou d'une conception de sujet différente.
Ne pas sur-partitionner à la légère. Trop de partitions augmentent les métadonnées, les descripteurs de fichiers, le travail d'élection du leader et le temps de rééquilibrage du consommateur.

Par exemple, si un sujet orders est uniquement indexé par region et que 80 pour cent du trafic provient de us-east, une partition peut devenir chaude. Une clé telle que customer_id ou region.customer_id peut répartir le trafic plus uniformément tout en préservant l'ordonnancement dont votre application a besoin.

Ajuster la configuration du producteur

L'optimisation des paramètres du producteur peut considérablement améliorer le débit d'écriture.

acks : acks=all offre la durabilité la plus forte lorsqu'il est associé à un min.insync.replicas approprié, mais peut ajouter de la latence. acks=1 est plus rapide car seul le leader accuse réception de l'écriture. acks=0 est le plus rapide mais ne donne aucun accusé de réception du courtier.
batch.size et linger.ms : Des lots plus grands réduisent les frais généraux de requête. Un petit linger.ms donne au producteur le temps de remplir les lots, au prix d'un temps d'attente supplémentaire.
Compression : lz4, snappy ou zstd peuvent réduire la pression sur le réseau et le disque. La compression utilise du CPU, alors testez-la avec la forme réelle de vos messages.
max.request.size : Augmentez ceci uniquement lorsque vos lots ou enregistrements légitimes en ont besoin. Vérifiez également les limites côté courtier telles que message.max.bytes et max.message.bytes au niveau du sujet.

Ajuster les ressources et les threads du courtier

Les paramètres du courtier influencent directement l'efficacité avec laquelle ils traitent les données.

num.network.threads : Contrôle les threads qui gèrent les requêtes réseau des clients et des autres courtiers.
num.io.threads : Contrôle les threads utilisés pour les E/S disque et le traitement des requêtes.
num.partitions : Définit le nombre de partitions par défaut pour les sujets nouvellement créés. Il ne redimensionne pas les sujets existants.
log.segment.bytes : Contrôle la taille des segments de journal. La taille des segments affecte le nettoyage de la rétention, le comportement de compaction et la gestion des fichiers.

Modifiez ces paramètres avec des métriques en main. Si les disques sont saturés, plus de threads ne résoudront pas le cluster. Si les files d'attente de requêtes réseau augmentent alors que le CPU est disponible, l'ajustement des threads peut aider.

Stratégies pour une faible latence

Une faible latence dans Kafka signifie souvent minimiser les délais de livraison des messages du producteur au consommateur.

Ajuster les consommateurs pour une faible latence

Les consommateurs sont la dernière étape du pipeline de livraison.

fetch.min.bytes : Des valeurs plus faibles renvoient les données plus tôt mais créent plus de requêtes de récupération.
fetch.max.wait.ms : Des valeurs plus faibles réduisent l'attente lorsque le trafic est faible.
Taille du groupe de consommateurs : Un groupe de consommateurs peut traiter un sujet en parallèle jusqu'au nombre de partitions assignées. Les consommateurs supplémentaires au-delà du nombre de partitions restent inactifs pour ce sujet.
Temps de traitement : Des écritures lentes en base de données en aval, des appels HTTP ou des transformations lourdes provoquent souvent un retard même lorsque Kafka lui-même est sain.

Réduire la distance réseau

La latence réseau entre les producteurs, les courtiers et les consommateurs est un facteur significatif.

Gardez les producteurs, les courtiers et les consommateurs sensibles à la latence proches les uns des autres lorsque c'est possible. Le trafic Kafka inter-régions ajoute de la latence et des modes de défaillance. Si vous avez besoin d'une livraison multi-régions, traitez-la comme un problème de conception de réplication ou de déplacement de données plutôt que d'étirer un cluster à faible latence sur des réseaux distants.

Maintenir les courtiers hors de pression de ressources

Une faible latence dépend de courtiers stables. Surveillez le CPU, l'attente d'E/S disque, le comportement du cache de pages, la saturation du réseau, le ratio d'inactivité du gestionnaire de requêtes et les partitions sous-répliquées. Si le courtier est surchargé, l'ajustement du client ne fait que masquer le symptôme pendant une courte période.

Équilibrer la réplication et la tolérance aux pannes

Bien que la réplication soit principalement pour la tolérance aux pannes, elle impacte les performances et la mise à l'échelle.

Facteur de réplication : Un facteur de réplication de 3 est courant pour les sujets de production car il peut tolérer la perte d'un courtier mieux qu'un seul réplica.
min.insync.replicas : Avec acks=all, cela contrôle combien de réplicas synchronisés doivent accuser réception d'une écriture avant que le producteur obtienne un succès.
Santé de l'ISR : La diminution des ensembles de réplicas synchronisés est un signe d'avertissement. Ils pointent souvent vers des disques lents, des problèmes réseau ou des courtiers surchargés.

Surveiller avant et après chaque changement

Une surveillance continue est essentielle pour identifier les goulots d'étranglement et ajuster les performances.

Suivez le CPU du courtier, les E/S disque, le débit réseau, la latence des requêtes, le débit des partitions, le taux d'erreur de production, les partitions sous-répliquées et le retard du consommateur. Kafka expose beaucoup de ces métriques via JMX, et les équipes les collectent couramment avec Prometheus et Grafana ou une plateforme spécifique à Kafka.

Faites un changement significatif à la fois. Si vous augmentez les partitions, mesurez l'impact du rééquilibrage et le comportement des partitions chaudes. Si vous modifiez le regroupement par lots du producteur, mesurez les percentiles de latence et les taux d'erreur, pas seulement le débit moyen.

À retenir

Mettez à l'échelle Kafka à partir du goulot d'étranglement vers l'extérieur. Commencez par la distribution des partitions et le regroupement par lots du client, puis vérifiez le retard du consommateur, la pression sur le disque et le réseau du courtier, et la santé de la réplication. Un cluster Kafka bien mis à l'échelle n'est pas seulement plus grand ; il a des partitions équilibrées, un comportement client prévisible et suffisamment de marge pour les défaillances.