Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Bonnes pratiques
Cette rubrique décrit certaines des meilleures pratiques à suivre lors de l'utilisation d'AmazonMSK.
Dimensionnez correctement votre cluster : nombre de partitions par agent
Le tableau suivant indique le nombre recommandé de partitions (y compris les réplicas de leader et de suiveur) par agent.
| Taille du courtier | Nombre recommandé de partitions (y compris les réplicas de leader et de suiveur) par agent |
|---|---|
kafka.t3.small |
300 |
kafka.m5.large ou kafka.m5.xlarge |
1 000 |
kafka.m5.2xlarge |
2000 |
kafka.m5.4xlarge, kafka.m5.8xlarge, kafka.m5.12xlarge, kafka.m5.16xlarge ou kafka.m5.24xlarge |
4000 |
kafka.m7g.large ou kafka.m7g.xlarge |
1 000 |
kafka.m7g.2xlarge |
2000 |
kafka.m7g.4xlarge, kafka.m7g.8xlargekafka.m7g.12xlarge, ou kafka.m7g.16xlarge |
4000 |
Si le nombre de partitions par agent dépasse la valeur recommandée et que votre cluster est surchargé, il se peut que vous ne puissiez pas effectuer les opérations suivantes :
-
Mettre à jour la configuration du cluster
-
Mettre à jour le cluster vers une taille de courtier plus petite
-
Associer un AWS Secrets Manager secret à un cluster doté d'une SCRAM authentificationSASL/
Un nombre élevé de partitions peut également entraîner l'absence de métriques Kafka sur CloudWatch et sur le scraping de Prometheus.
Pour obtenir des conseils sur le choix du nombre de partitions, veuillez consulter Apache Kafka prend en charge les 200k partitions par cluster
Dimensionnez correctement votre cluster : nombre d'agents par cluster
Pour déterminer le nombre approprié de courtiers pour votre MSK cluster et comprendre les coûts, consultez la feuille de calcul MSKdes tailles et des prix
Pour comprendre comment l'infrastructure sous-jacente affecte les performances d'Apache Kafka, consultez la section Meilleures pratiques pour dimensionner correctement vos clusters Apache Kafka afin d'optimiser les performances et les coûts
Optimisation du débit du cluster pour les instances m5.4xl, m7g.4xl ou supérieures
Lorsque vous utilisez des instances m5.4xl, m7g.4xl ou supérieures, vous pouvez optimiser le débit du cluster en ajustant les configurations num.io.threads et num.network.threads.
Num.io.threads est le nombre de threads qu'un agent utilise pour traiter les demandes. L'ajout de threads supplémentaires, dans la limite du nombre de CPU cœurs pris en charge pour la taille de l'instance, peut contribuer à améliorer le débit du cluster.
Num.network.threads est le nombre de threads que l'agent utilise pour recevoir toutes les demandes entrantes et renvoyer les réponses. Les threads réseau placent les demandes entrantes dans une file d'attente de demandes pour être traitées par io.threads. La définition de num.network.threads à la moitié du nombre de CPU cœurs pris en charge pour la taille d'instance permet d'utiliser pleinement la nouvelle taille d'instance.
Important
N'augmentez pas num.network.threads sans d'abord augmenter num.io.threads, car cela peut entraîner une congestion liée à la saturation de la file d'attente.
Paramètres recommandés | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Taille d’instance | Valeur recommandée pour num.io.threads | Valeur recommandée pour num.network.threads | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m5.4xl |
16 |
8 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m5.8xl |
32 |
16 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m5.12xl |
48 |
24 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m5.16xl |
64 |
32 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m5.24xl |
96 |
48 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m7g.4xlarge |
16 |
8 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m7g.8xlarge |
32 |
16 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m7g.12xlarge |
48 |
24 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m7g.16xlarge |
64 |
32 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Utilisez la dernière version de Kafka AdminClient pour éviter le problème de non-concordance entre les identifiants des sujets
L'identifiant d'un sujet est perdu (erreur : ne correspond pas à l'identifiant du sujet de la partition) lorsque vous utilisez une AdminClient version de Kafka inférieure --zookeeper à 2.8.0 avec l'indicateur pour augmenter ou réaffecter les partitions de sujet pour un cluster utilisant la version 2.8.0 ou supérieure de Kafka. Notez que l'indicateur --zookeeper est obsolète dans Kafka 2.5 et qu'il est supprimé à partir de Kafka 3.0. Consultez Mise à niveau vers la version 2.5.0 à partir de n'importe quelle version 0.8.x à 2.4.x
Pour éviter toute non-correspondance entre les ID de rubrique, utilisez une version 2.8.0 ou supérieure de client Kafka pour les opérations d'administration de Kafka. Les clients de version 2.5 ou supérieure peuvent également utiliser l'indicateur --bootstrap-servers au lieu de l'indicateur --zookeeper.
Créer des clusters hautement disponibles
Suivez les recommandations suivantes afin que votre MSK cluster soit hautement disponible lors d'une mise à jour (par exemple lorsque vous modifiez la taille du broker ou la version d'Apache Kafka, par exemple) ou lorsqu'Amazon MSK remplace un broker.
-
Configurez un cluster à trois AZ.
-
Assurez-vous que le facteur de réplication (RF) est d'au moins 3. Notez qu'un RF de 1 peut entraîner des partitions hors ligne pendant une mise à jour propagée ; et un RF de 2 peut entraîner une perte de données.
-
Définissez le nombre minimum de répliques synchronisées (minISR) sur RF - 1 au maximum. Un minimum ISR égal à la RF peut empêcher la production sur le cluster lors d'une mise à jour continue. Un minimum ISR de 2 permet aux rubriques répliquées à trois d'être disponibles lorsqu'une réplique est hors ligne.
-
Assurez-vous que les chaînes de connexion client incluent au moins un agent de chaque zone de disponibilité. La présence de plusieurs agents dans la chaîne de connexion d'un client permet le basculement lorsqu'un agent spécifique est hors ligne pour une mise à jour. Pour plus d'informations sur la façon d'obtenir une chaîne de connexion avec plusieurs agents, reportez-vous à la section Obtenir les courtiers bootstrap pour un cluster Amazon MSK.
Surveiller CPU l'utilisation
Amazon vous recommande MSK vivement de maintenir le CPU taux d'utilisation total (défini commeCPU User + CPU System) inférieur à 60 % pour vos courtiers. Lorsque vous disposez d'au moins 40 % du total CPU de votre cluster, Apache Kafka peut redistribuer la CPU charge entre les courtiers du cluster si nécessaire. Cela est par exemple nécessaire lorsqu'Amazon MSK détecte une défaillance d'un courtier et se rétablit en cas de défaillance ; dans ce cas, Amazon MSK effectue une maintenance automatique, telle que l'application de correctifs. Autre exemple : lorsqu'un utilisateur demande une modification de la taille du courtier ou une mise à niveau de version ; dans ces deux cas, Amazon MSK déploie des flux de travail continus qui mettent un courtier hors ligne à la fois. Lorsque des agents dotés de partitions principales se déconnectent, Apache Kafka réaffecte la direction des partitions afin de redistribuer le travail aux autres agents du cluster. En suivant ces bonnes pratiques, vous pouvez vous assurer que votre cluster dispose d'CPUune marge de manœuvre suffisante pour tolérer de tels événements opérationnels.
Vous pouvez utiliser Amazon CloudWatch Metric Math pour créer une métrique composite qui estCPU User + CPU System. Définissez une alarme qui se déclenche lorsque la métrique composite atteint une CPU utilisation moyenne de 60 %. Lorsque cette alarme est déclenchée, mettez le cluster à l'échelle à l'aide de l'une des options suivantes :
-
Option 1 (recommandée) : mettez à jour la taille de votre courtier à la taille supérieure suivante. Par exemple, si la taille actuelle est la suivante
kafka.m5.large, mettez à jour le cluster à utiliserkafka.m5.xlarge. N'oubliez pas que lorsque vous mettez à jour la taille des courtiers dans le cluster, Amazon MSK met les courtiers hors ligne de manière continue et réaffecte temporairement la direction de la partition à d'autres courtiers. Une mise à jour de taille prend généralement 10 à 15 minutes par agent. -
Option 2 : Si certaines rubriques contiennent tous les messages ingérés à partir de producteurs utilisant des écritures circulaires (en d'autres termes, les messages ne sont pas saisis et les commandes ne sont pas importantes pour les consommateurs), étendez votre cluster en ajoutant des agents. Ajoutez également des partitions aux rubriques existantes avec le débit le plus élevé. Ensuite, utilisez
kafka-topics.sh --describepour vous assurer que les partitions nouvellement ajoutées sont attribuées aux nouveaux agents. Le principal avantage de cette option par rapport à la précédente réside dans le fait que vous pouvez gérer les ressources et les coûts de manière plus précise. En outre, vous pouvez utiliser cette option si la CPU charge dépasse de manière significative 60 %, car cette forme de mise à l'échelle n'entraîne généralement pas d'augmentation de la charge pour les courtiers existants. -
Option 3 : étendez votre cluster en ajoutant des agents, puis réattribuez les partitions existantes à l'aide de l'outil de réattribution de partitions nommé
kafka-reassign-partitions.sh. Toutefois, si vous utilisez cette option, le cluster devra dépenser des ressources pour répliquer les données d'un agent à l'autre après la réaffectation des partitions. Par rapport aux deux options précédentes, cela peut augmenter considérablement la charge sur le cluster dans un premier temps. Par conséquent, Amazon MSK ne recommande pas d'utiliser cette option lorsque le taux d'CPUutilisation est supérieur à 70 %, car la réplication entraîne une CPU charge et un trafic réseau supplémentaires. Amazon recommande d'utiliser cette option MSK uniquement si les deux options précédentes ne sont pas réalisables.
Autres recommandations :
-
Surveillez CPU l'utilisation totale par courtier en tant que proxy pour la répartition de la charge. Si les courtiers ont une CPU utilisation toujours inégale, cela peut être le signe que la charge n'est pas uniformément répartie au sein du cluster. Amazon MSK recommande d'utiliser le régulateur de vitesse pour gérer en permanence la répartition de la charge via l'attribution de partitions.
-
Surveiller la latence de production et de consommation. La latence de production et de consommation peut augmenter de façon linéaire avec CPU l'utilisation.
-
JMXintervalle de récupération : si vous activez la surveillance ouverte avec la fonction Prometheus, il est recommandé d'utiliser un intervalle de récupération de 60 secondes ou plus (scrape_interval : 60s) pour la configuration de votre hôte Prometheus (prometheus.yml). La réduction de l'intervalle de récupération peut entraîner une CPU utilisation élevée de votre cluster.
Surveiller l'espace disque
Pour éviter de manquer d'espace disque pour les messages, créez une CloudWatch alarme qui surveille la KafkaDataLogsDiskUsed métrique. Lorsque la valeur de cette mesure atteint ou dépasse 85 %, effectuez une ou plusieurs des actions suivantes :
-
Utilisez Dimensionnement automatique. Vous pouvez également augmenter manuellement le stockage des agents, comme décrit dans Mise à l'échelle manuelle.
-
Réduisez la période de rétention des messages ou la taille du journal. Pour de plus amples informations sur la procédure à utiliser, veuillez consulter Ajuster les paramètres de rétention des données.
-
Supprimer les rubriques inutilisées.
Pour plus d'informations sur la configuration et l'utilisation des alarmes, consultez la section Utilisation d'Amazon CloudWatch Alarms. Pour une liste complète des MSK statistiques Amazon, consultezSurveillance d'un MSK cluster Amazon.
Ajuster les paramètres de rétention des données
La consommation de messages ne les supprime pas du journal. Pour libérer régulièrement de l'espace disque, vous pouvez spécifier explicitement une période de rétention, c'est-à-dire la durée de conservation des messages dans le journal. Vous pouvez également spécifier une taille de journal de rétention. Lorsque la période de rétention ou la taille du journal de rétention sont atteintes, Apache Kafka commence à supprimer les segments inactifs du journal.
Pour spécifier une stratégie de rétention au niveau du cluster, définissez un ou plusieurs des paramètres suivants : log.retention.hours, log.retention.minutes, log.retention.ms, ou log.retention.bytes. Pour plus d’informations, consultez Configurations MSK personnalisées.
Vous pouvez également spécifier des paramètres de rétention au niveau de la rubrique :
-
Pour spécifier une période de rétention par rubrique, utilisez la commande suivante.
kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-nameTopicName--add-config retention.ms=DesiredRetentionTimePeriod -
Pour spécifier une taille de journal de rétention par rubrique, utilisez la commande suivante.
kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-nameTopicName--add-config retention.bytes=DesiredRetentionLogSize
Les paramètres de rétention que vous spécifiez au niveau de la rubrique ont priorité sur les paramètres de niveau cluster.
Accélération de la récupération du journal après un arrêt incorrect
Après un arrêt incorrect, le redémarrage d'un agent peut prendre un certain temps, car il procède à la récupération du journal. Par défaut, Kafka n'utilise qu'un seul thread par répertoire de journal pour effectuer cette récupération. Par exemple, si vous avez des milliers de partitions, la récupération du journal peut prendre des heures. Pour accélérer la récupération du journal, il est recommandé d'augmenter le nombre de threads à l'aide de la propriété de configuration num.recovery.threads.per.data.dir. Vous pouvez le régler sur le nombre de CPU cœurs.
Surveiller la mémoire Apache Kafka
Nous vous recommandons de surveiller la mémoire utilisée par Apache Kafka. Dans le cas contraire, le cluster risque de devenir indisponible.
Pour déterminer la quantité de mémoire utilisée par Apache Kafka, vous pouvez surveiller la métrique HeapMemoryAfterGC. HeapMemoryAfterGC est le pourcentage de mémoire de tas totale qui est utilisée après le récupérateur de mémoire. Nous vous recommandons de créer une CloudWatch alarme qui agit lorsque les HeapMemoryAfterGC augmentations sont supérieures à 60 %.
Les étapes que vous pouvez suivre pour réduire l'utilisation de la mémoire varient. Elles dépendent de la façon dont vous configurez Apache Kafka. Par exemple, si vous utilisez la diffusion de messages transactionnels, vous pouvez réduire la valeur transactional.id.expiration.ms de votre configuration Apache Kafka de 604800000 ms à 86400000 ms (de 7 jours à 1 jour). Cela permet de réduire l'empreinte mémoire de chaque transaction.
N'ajoutez pas de MSK non-courtiers
Pour les clusters ZooKeeper basés, si vous utilisez ZooKeeper les commandes Apache pour ajouter des courtiers, ces courtiers ne sont pas ajoutés à votre MSK cluster et votre Apache ZooKeeper contiendra des informations incorrectes sur le cluster. Cela peut entraîner une perte de données. Pour les opérations de cluster prises en charge, reportez-vous à la section Amazon MSK : comment ça marche.
Utilisation du chiffrement en transit
Pour de plus amples informations sur le chiffrement en transit et sur la façon de l'activer, veuillez consulter Chiffrement en transit.
Réaffecter les partitions
Pour déplacer des partitions vers différents brokers sur le même cluster, vous pouvez utiliser l'outil de réaffectation de partition nommé kafka-reassign-partitions.sh. Par exemple, après avoir ajouté de nouveaux courtiers pour étendre un cluster ou pour déplacer des partitions afin de supprimer des courtiers, vous pouvez rééquilibrer ce cluster en réattribuant des partitions aux nouveaux courtiers. Pour de plus amples informations sur l'ajout de brokers à un cluster, veuillez consulter Expansion d'un MSK cluster Amazon. Pour plus d'informations sur la manière de supprimer des courtiers d'un cluster, consultezSupprimer un courtier d'un MSK cluster Amazon. Pour de plus amples informations sur l'outil de réaffectation de partition, veuillez consulter Expansion de votre cluster
