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.
Meilleures pratiques pour les courtiers Express
Cette rubrique décrit certaines bonnes pratiques à suivre lors de l'utilisation d'Express Brokers. Les courtiers Express sont préconfigurés pour garantir une disponibilité et une durabilité élevées. Vos données sont réparties dans trois zones de disponibilité par défaut, la réplication est toujours définie sur 3 et la réplication synchronisée minimale est toujours définie sur 2. Il reste toutefois quelques facteurs à prendre en compte pour optimiser la fiabilité et les performances de votre cluster.
Client-side considérations
La disponibilité et les performances de votre application dépendent non seulement des paramètres côté serveur, mais également des paramètres du client.
Configurez vos clients pour une haute disponibilité. Dans un système distribué tel qu'Apache Kafka, il est essentiel de garantir une haute disponibilité pour maintenir une infrastructure de messagerie fiable et tolérante aux pannes. Les courtiers se déconnecteront pour les événements planifiés et imprévus, tels que les mises à niveau, les correctifs, les pannes matérielles et les problèmes de réseau. Un cluster Kafka tolère un courtier hors ligne, c'est pourquoi les clients de Kafka doivent également gérer le basculement des courtiers avec élégance. Consultez tous les détails dans les recommandations de bonnes pratiques pour les clients d'Apache Kafka.
Exécutez des tests de performance pour vérifier que les configurations de vos clients vous permettent d'atteindre vos objectifs de performance, même lorsque nous redémarrons les courtiers en période de pointe. Vous pouvez redémarrer les courtiers de votre cluster à partir de la console MSK ou à l'aide des API MSK.
Server-side considérations
Rubriques
Right-size votre cluster : nombre de courtiers par cluster
Il est facile de choisir le nombre de courtiers pour votre Express-based cluster. Chaque courtier Express est doté d'une capacité de débit définie pour l'entrée et la sortie. Vous devez utiliser cette capacité de débit comme principal moyen de dimensionner votre cluster (puis prendre en compte d'autres facteurs tels que le nombre de partitions et de connexions, abordés ci-dessous).
Par exemple, si votre application de streaming a besoin de 45 Mo/s de capacité d'entrée (écriture) et de 90 Mo/s de sortie (lecture) de données, vous pouvez simplement utiliser 3 courtiers express.m7g.large pour répondre à vos besoins en matière de débit. Chaque courtier express.m7g.large gérera 15 Mo/s d'entrée et 30 Mo/s de sortie. Consultez le tableau suivant pour connaître les limites de débit recommandées pour chaque taille de courtier Express. Si votre débit dépasse les limites recommandées, les performances peuvent se dégrader et vous devez réduire votre trafic ou faire évoluer votre cluster. Si votre débit dépasse les limites recommandées et atteint le quota par courtier, MSK limitera le trafic de vos clients pour éviter toute nouvelle surcharge.
Vous pouvez également utiliser notre feuille de calcul
Le tableau suivant répertorie le débit maximum recommandé par courtier pour chaque taille d'instance.
| Taille d’instance | Entrée (Mo/s) | Sortie (Mo/s) |
|---|---|---|
|
|
15,6 | 31,2 |
|
|
31,2 | 62,5 |
|
|
62,5 | 125,0 |
|
|
124,9 | 249,8 |
|
|
250,0 | 500,0 |
|
|
375,0 | 750,0 |
|
|
500,0 | 1000,0 |
Surveiller l'utilisation de l'UC
Nous vous recommandons de maintenir l'utilisation totale du processeur pour vos courtiers (définie comme utilisateur du processeur + système de processeur) à moins de 60 %. Lorsque vous disposez d'au moins 40 % de l'UC totale de votre cluster, Apache Kafka peut redistribuer la charge de l'UC entre les agents du cluster si nécessaire. Cela peut être nécessaire en raison d'événements planifiés ou imprévus. Un exemple d'événement planifié est une mise à niveau de la version d'un cluster au cours de laquelle MSK met à jour les courtiers d'un cluster en les redémarrant un par un. Un exemple d'événement imprévu est une panne matérielle chez un courtier ou, dans le pire des cas, une panne AZ affectant tous les courtiers d'une zone de classement. Lorsque les courtiers dotés de répliques de leads de partition se déconnectent, Apache Kafka réaffecte la direction des partitions pour redistribuer le travail aux autres courtiers du cluster. En suivant cette bonne pratique, vous pouvez vous assurer que votre cluster dispose d'une marge de manœuvre suffisante pour tolérer de tels événements opérationnels.
Vous pouvez utiliser l'utilisation d'expressions mathématiques avec CloudWatch des métriques dans le Guide de CloudWatch l'utilisateur Amazon pour créer une métrique composite qui est la suivante : utilisateur du processeur et système du processeur. Définissez une alarme qui se déclenche lorsque la métrique composite atteint une utilisation moyenne de l'UC de 60 %. Lorsque cette alarme est déclenchée, mettez le cluster à l'échelle à l'aide de l'une des options suivantes :
Option 1 : mettez à jour la taille de votre courtier pour passer à la taille supérieure suivante. 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éattribue temporairement la direction de la partition à d'autres courtiers.
Option 2 : développez votre cluster en ajoutant des courtiers, puis en réaffectant les partitions existantes à l'aide de l'outil de réattribution de partitions nommé.
kafka-reassign-partitions.sh
Autres recommandations
Surveillez l'utilisation totale de l'UC par agent en tant que proxy pour la répartition de la charge. Si les courtiers ont constamment une utilisation inégale du processeur, cela peut être le signe que la charge n'est pas uniformément répartie au sein du cluster. Nous vous recommandons d'utiliser le régulateur de vitesse pour gérer en permanence la répartition de la charge via l'attribution des partitions.
Surveiller la latence de production et de consommation. La latence de production et de consommation peut augmenter de façon linéaire en fonction de l'utilisation de l'UC.
Intervalle de scrape JMX : si vous activez la surveillance ouverte avec la fonction Prometheus, il est recommandé d'utiliser un intervalle de scrape de 60 secondes ou plus (
scrape_interval: 60s) pour la configuration de votre hôte Prometheus ().prometheus.ymlLa réduction du Scrape Interval peut entraîner une utilisation élevée de l'UC sur votre cluster.
Right-size votre cluster : nombre de partitions par courtier Express
Si vous avez des cas d'utilisation à partition élevée et à faible débit où vous avez un nombre de partitions plus élevé, mais que vous n'envoyez pas de trafic sur toutes les partitions, vous pouvez empaqueter plus de partitions par courtier, à condition d'avoir effectué suffisamment de tests et de tests de performances pour valider que votre cluster reste sain avec le nombre de partitions le plus élevé. Si le nombre de partitions par broker dépasse la valeur maximale autorisée et que votre cluster est surchargé, vous ne pourrez pas effectuer les opérations suivantes :
-
Mettre à jour la configuration du cluster
-
Mettez à jour le cluster pour réduire la taille du courtier
-
Associer un AWS Secrets Manager secret à un cluster doté d'une SASL/SCRAM authentification
Un cluster surchargé avec un grand nombre de partitions peut également entraîner l'absence de métriques Kafka sur CloudWatch et sur le scraping de Prometheus. Cet effet est aggravé par le nombre élevé de groupes de consommateurs, car chaque combinaison de groupe de consommateurs, de sujet et de partition donne lieu à une entrée de décalage suivie. Les groupes de consommateurs vides (groupes sans consommateurs actifs) contribuent également à ces frais généraux. Apache Kafka conserve les offsets pour ces groupes jusqu'à ce que la période de rétention définie par offsets.retention.minutes expire, ou jusqu'à ce que vous supprimiez explicitement le groupe. Pour remédier à ce problème, surveillez le nombre total de vos groupes de consommateurs et supprimez les groupes de consommateurs non utilisés.
Pour obtenir des conseils sur le choix du nombre de partitions, veuillez consulter Apache Kafka prend en charge les 200k partitions par cluster
Pour plus d'informations sur le nombre de partitions recommandé (y compris les répliques de base et de suiveur) pour chaque courtier Express, consultez. Quota de partition d'Express Broker Le nombre de partitions recommandé n'est pas appliqué et constitue une bonne pratique pour les scénarios dans lesquels vous envoyez du trafic sur toutes les partitions thématiques provisionnées.
Surveiller le nombre de connexions
Les connexions des clients à vos courtiers consomment des ressources système telles que la mémoire et le processeur. En fonction de votre mécanisme d'authentification, vous devez vous assurer que vous respectez les limites applicables. Pour gérer les tentatives en cas d'échec des connexions, vous pouvez définir le paramètre de configuration reconnect.backoff.ms côté client. Par exemple, si vous souhaitez qu'un client réessaie de se connecter au bout d'une seconde, définissez surreconnect.backoff.ms. 1000 Pour plus d'informations sur la configuration des nouvelles tentatives, consultez la documentation d'Apache Kafka.
| Dimension | Quota |
|---|---|
|
Nombre maximum de connexions TCP par courtier (contrôle d'accès IAM) |
3000 |
|
Nombre maximal de connexions TCP par courtier (IAM) |
100 par seconde |
|
Nombre maximum de connexions TCP par courtier (non-IAM) |
MSK n'impose pas de limites de connexion pour l'authentification non IAM. Vous devez toutefois surveiller d'autres indicateurs tels que l'utilisation du processeur et de la mémoire pour vous assurer de ne pas surcharger votre cluster en raison de connexions excessives. |
Réaffecter les partitions
Pour déplacer des partitions vers différents courtiers sur le même cluster MSK Provisioned, vous pouvez utiliser l'outil de réaffectation de partitions nommé. kafka-reassign-partitions.sh Nous vous recommandons de ne pas réaffecter plus de 20 partitions en un seul kafka-reassign-partitions appel pour garantir la sécurité des opérations. Par exemple, après avoir ajouté de nouveaux courtiers pour développer un cluster ou pour déplacer des partitions afin de supprimer des courtiers, vous pouvez rééquilibrer ce cluster en réaffectant des partitions aux nouveaux courtiers. Pour plus d'informations sur la façon d'ajouter des courtiers à un cluster MSK Provisioned, consultez. Augmentez le nombre de courtiers dans un cluster Amazon MSK Pour plus d'informations sur la manière de supprimer des courtiers d'un cluster MSK Provisioned, consultez. Supprimer un agent d’un cluster Amazon MSK Pour de plus amples informations sur l'outil de réaffectation de partition, veuillez consulter Expansion de votre cluster
