Comment puis-je résoudre les problèmes d'utilisation élevée du processeur sur un ou plusieurs courtiers d'un cluster Amazon MSK ?

Résolution

L'utilisation totale du processeur pour un cluster Amazon MSK est calculée comme la somme des éléments suivants :

• Pourcentage de CPU dans l'espace utilisateur défini par la métrique CPUUser
• Pourcentage de CPU dans l'espace du noyau défini par CPUsystem

Il est recommandé de limiter l'utilisation totale du processeur à moins de 60 % afin que 40 % du processeur de votre cluster soit disponible. Apache Kafka peut redistribuer la charge du processeur entre les courtiers du cluster selon les besoins. En cas, par exemple, de rétablissement d'Amazon MSK suite à la défaillance d'un courtier, le processeur disponible permet d’effectuer une maintenance automatique telle que l'application de correctifs.

Voici quelques-unes des causes les plus courantes d'utilisation élevée du processeur dans votre cluster Amazon MSK :

• Le trafic entrant ou sortant est élevé.
• Le nombre limite de partitions par courtier a été dépassé et a surchargé le cluster.
• Vous utilisez une instance de type T.

Le trafic entrant ou sortant est élevé

Vous pouvez surveiller le trafic entrant et sortant vers le cluster au moyen des métriques BytesInPersec et BytesOutPerSec d'Amazon CloudWatch. Si ces indicateurs ont des valeurs élevées ou sont biaisés, le courtier est sans doute confronté à une utilisation élevée du processeur. Voici plusieurs causes d’un trafic entrant et sortant élevé :

• Le nombre de partitions pour le sujet recevant un trafic élevé n'est pas uniformément réparti entre les courtiers. Ou bien, le producteur n'envoie pas les données de manière uniforme à toutes les partitions. Vérifiez votre clé de partitionnement du producteur et mettez à jour la configuration du cluster en conséquence. Configurez la clé de partition de manière à répartir uniformément les données entre les partitions.
• Le groupe de consommateurs engage très fréquemment des compensations. Le trafic provenant des engagements de compensation se répercute sur le courtier. Vous pouvez alors constater que la valeurMessagesInPerSec est sensiblement élevée pour le courtier leader de la partition thématique _consumer_offset. Il s'agit de la partition sur laquelle la compensation du groupe de consommateurs est engagée. Pour résoudre ce problème, réduisez le nombre de groupes de consommateurs ou augmentez la taille de votre instance.

Le nombre limite de partitions par courtier a été dépassé

Si le nombre de partitions par courtier dépasse la valeur recommandée, votre cluster est surchargé. Le cas échéant, vous ne pourrez sans doute pas effectuer les opérations suivantes :

• Mise à jour de la configuration du cluster.
• Mise à jour de la version d'Apache Kafka pour le cluster.
• Mise à jour du cluster vers un type de courtier plus petit.
• Association d’un secret AWS Secrets Manager à un cluster avec authentification SASL/SCRAM.

Un nombre excessif de partitions entraîne une dégradation des performances pour utilisation élevée du processeur. Cela signifie que chaque partition utilise une certaine quantité de ressources de courtage, y compris en cas de trafic réduit. Pour résoudre ce problème, procédez comme suit :

• Supprimez les rubriques obsolètes ou inutilisées pour ramener le nombre de partitions dans la limite recommandée.
• Augmentez le type d'instance de broker au type pouvant prendre en charge le nombre de partitions nécessaire. Tentez également d'ajouter d'autres courtiers et de réattribuer des partitions.

Notez que les partitions ne sont pas automatiquement réattribuées lorsque vous ajoutez des courtiers. Vous devez exécuter la commande kafka-reassign-partitions. Pour plus d'informations, voir Réattribuer des partitions après avoir modifié la taille du cluster.

Vous utilisez une instance de type T

Notez que les instances de typeT présentent des performances de base avec certaines fonctionnalités modulables. Ces instances vous offrent des performances de base de 20 % d'utilisation du processeur. Si vous dépassez cette valeur, le type d'instance utilise les crédits CPU. Si l'utilisation est inférieure à 20 %, les crédits CPU sont accumulés.

Surveillez la métrique du solde de crédit du processeur dans Amazon CloudWatch. Les crédits acquis sont accumulés dans le solde créditeur, et déduits du solde créditeur une fois dépensés. La limite maximale du solde créditeur est déterminée par la taille de l'instance. Une fois cette limite atteinte, tous les nouveaux crédits accumulés sont annulés. Pour le type d'instance T2 Standard, les crédits de lancement ne sont pas comptabilisés dans la limite.

Les crédits de processeur indiqués par la métriqueCPUCreditBalance peuvent être dépensés par l'instance pour dépasser son taux d'utilisation du processeur de base. En cas d’instance en cours d'exécution, les crédits de CPUCreditBalance n'expirent pas. En cas d’arrêt d’une instance T4g, T3a ou T3, la valeur CPUCreditBalance est maintenue pendant sept jours. Après ces sept jours, vous perdez tous les crédits accumulés. En cas d’arrêt d’une instance T2, la valeur CPUCreditBalance n’est pas maintenue et vous perdez tous les crédits accumulés. Les mesures de crédit du processeur sont disponibles toutes les cinq minutes.

Surveillez l'utilisation de base du processeur et le solde de crédit de tout cluster exécuté sur des instances de type T. En cas d’utilisation du processeur supérieure à la valeur de référence et d’épuisement des crédits, les performances du cluster sont compromises.

Autres causes

• Nombre élevé de connexions au client : Un pic de l'une des métriques CloudWatch suivantes peut entraîner une augmentation de l'utilisation du processeur défaillant. Pour résoudre ce problème, surveillez ces métriques sur CloudWatch. Réduisez ensuite le nombre de connexions selon vos besoins, ou augmentez le type de courtier.
  • Nombre de connexions
  • Taux de création de connexions
  • Taux de fermeture des connexions
• Le nombre de groupes de consommateurs est élevé : Si le nombre de groupes de consommateurs est élevé (par ex. plus de 1 000), l'utilisation du processeur par le courtier peut augmenter. Une utilisation élevée du processeur peut également se produire si un groupe de consommateurs engage trop fréquemment des compensations. Pour résoudre ce problème, réduisez le nombre de groupes de consommateurs ou augmentez la taille de votre instance.
• Amazon MSK détecte et répare les erreurs d'un courtier : Amazon MSK effectue dans ce cas une opération de maintenance automatique telle que l'application de correctifs, ce qui entraîne une augmentation de l'utilisation du processeur.
• Un utilisateur demande un changement de type de courtier ou une mise à niveau de version : Amazon MSK déploie dans ce cas des flux de travail évolutifs qui entraînent la mise hors ligne d’un courtier à la fois. En cas de déconnexion de courtiers disposant de partitions principales, Apache Kafka réattribue la direction des partitions afin de redistribuer le travail aux autres courtiers du cluster. Surveillez l'utilisation du processeur par ces courtiers et assurez-vous que votre cluster dispose d'une capacité de processeur suffisante à gérer les événements opérationnels.
• L'utilisation du processeur par un ou plusieurs courtiers est élevée du fait d’une distribution asymétrique des données : Si, par exemple, deux courtiers sur six reçoivent davantage d'informations et sont plus sollicités, l’utilisation du processeur est plus élevée. Pour résoudre ce problème, utilisez la technique du round robin en vue d’une répartition correcte des partitions du cluster. Exécutez la commande topic describe pour visualiser le mode de répartition des partitions sur le cluster. Le résultat sera du type suivant :

bin/kafka-topics.sh -bootstrap-server $MYBROKERS --describe --topic my-topic
    Topic:my-topic    PartitionCount:7 ReplicationFactor:3 Configs:
    Topic: my-topic    Partition: 0 Leader: 1 Replicas: 1,3,2 Isr: 1,3,2
    Topic: my-topic    Partition: 1 Leader: 2 Replicas: 2,1,3 Isr: 2,1,3
    Topic: my-topic    Partition: 2 Leader: 3 Replicas: 3,2,1 Isr: 3,2,1
    Topic: my-topic    Partition: 3 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
    Topic: my-topic    Partition: 4 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1
    Topic: my-topic    Partition: 5 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2

• Vous avez activé la surveillance ouverte : L’activation de la surveillance ouverte avec Prometheus et un intervalle de récupération réduit peuvent entraîner l'émission d'un nombre élevé de métriques. L’utilisation du processeur sera supérieure. Pour résoudre ce problème, augmentez l'intervalle de récupération.