View a markdown version of this page

Courtier hors ligne et basculement du client - Amazon Managed Streaming for Apache Kafka

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.

Courtier hors ligne et basculement du client

Kafka permet la mise en place d'un courtier hors ligne ; un seul courtier hors ligne au sein d'un cluster sain et équilibré qui suit les meilleures pratiques n'aura aucun impact ni ne provoquera d'échec en termes de production ou de consommation. En effet, un autre courtier reprendra la direction de la partition et parce que la bibliothèque client Kafka basculera automatiquement et commencera à envoyer des demandes aux nouveaux courtiers leaders.

Contrat client-serveur

Il en résulte un contrat partagé entre la bibliothèque cliente et le comportement côté serveur ; le serveur doit attribuer avec succès un ou plusieurs nouveaux leaders et le client doit changer de courtier pour envoyer des demandes aux nouveaux responsables en temps opportun.

Kafka utilise des exceptions pour contrôler ce flux :

Un exemple de procédure

  1. Le courtier A passe en mode hors ligne.

  2. Le client Kafka reçoit une exception (généralement une déconnexion réseau ou not_leader_for_partition).

  3. Ces exceptions incitent le client Kafka à mettre à jour ses métadonnées afin de connaître les derniers leaders.

  4. Le client de Kafka recommence à envoyer des demandes aux nouveaux responsables de partition sur d'autres courtiers.

Ce processus prend généralement moins de 2 secondes avec le client Java distribué et les configurations par défaut. Les erreurs côté client sont verbeuses et répétitives mais ne sont pas préoccupantes, comme l'indique le niveau « WARN ».

Exemple : Exception 1

10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Got error produce response with correlation id 864845 on topic-partition msk-test-topic-1-0, retrying (2147483646 attempts left). Error: NETWORK_EXCEPTION. Error Message: Disconnected from node 2

Exemple : Exception 2

10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Received invalid metadata error in produce request on partition msk-test-topic-1-41 due to org.apache.kafka.common.errors.NotLeaderOrFollowerException: For requests intended only for the leader, this error indicates that the broker is not the current leader. For requests intended for any replica, this error indicates that the broker is not a replica of the topic partition.. Going to request metadata update now"

Les clients Kafka résoudront automatiquement ces erreurs en 1 seconde et au plus 3 secondes. Cela se traduit par produce/consume une latence de p99 dans les métriques côté client (généralement des millisecondes élevées dans les années 100). Un délai plus long indique généralement un problème de configuration du client ou de charge du contrôleur côté serveur. Consultez la section de résolution des problèmes.

Un basculement réussi peut être vérifié en vérifiant l'augmentation des LeaderCount indicateurs BytesInPerSec et des indicateurs sur les autres courtiers, ce qui prouve que le trafic et le leadership ont évolué comme prévu. Vous observerez également une augmentation de la UnderReplicatedPartitions métrique, ce qui est attendu lorsque les répliques sont hors ligne avec le Shutdown Broker.

Résolution des problèmes

Le flux ci-dessus peut être perturbé en cas de rupture du contrat client-serveur. Les raisons les plus courantes du problème sont les suivantes :

  • Mauvaise configuration ou utilisation incorrecte des bibliothèques du client Kafka.

  • Comportements par défaut et bogues inattendus dans les bibliothèques clientes tierces.

  • Contrôleur surchargé, ce qui ralentit l'attribution du chef de partition.

  • Un nouveau contrôleur est en cours d'élection, ce qui ralentit l'attribution du chef de partition.

Afin de garantir un comportement correct face à l'échec du leadership, nous recommandons :

  • Les meilleures pratiques côté serveur doivent être suivies pour garantir que le contrôleur broker est dimensionné de manière appropriée afin d'éviter une affectation lente de la direction.

  • Les nouvelles tentatives doivent être activées dans les bibliothèques clientes pour s'assurer que le client gère le basculement.

  • Les bibliothèques clientes doivent avoir configuré retry.backoff.ms (par défaut 100) pour éviter les tempêtes. connection/request

  • Les bibliothèques clientes doivent définir request.timeout.ms et delivery.timeout.ms sur des valeurs conformes au SLA des applications. Des valeurs plus élevées ralentiront le basculement pour certains types de défaillances.

  • Les bibliothèques clientes doivent s'assurer que bootstrap.servers contient au moins 3 courtiers aléatoires pour éviter tout impact sur la disponibilité lors de la découverte initiale.

  • Certaines bibliothèques clientes sont de niveau inférieur à d'autres et s'attendent à ce que le développeur de l'application implémente lui-même la logique des nouvelles tentatives et la gestion des exceptions. Veuillez vous référer à la documentation spécifique à la bibliothèque cliente pour des exemples d'utilisation, et assurez-vous que reconnect/retry la logique correcte est suivie.

  • Nous vous recommandons de surveiller la latence côté client pour les produits, le nombre de demandes réussies et le nombre d'erreurs pour les erreurs non réessayables.

  • Nous avons observé que les anciennes bibliothèques tierces Golang et Ruby restent verbeuses pendant toute la période hors ligne d'un courtier, bien que les requêtes de production et de consommation ne soient pas affectées. Nous vous recommandons de toujours surveiller les indicateurs de votre activité, en plus des indicateurs de réussite et d'erreurs des requêtes, afin de déterminer si vos journaux présentent un impact réel par rapport au bruit.

  • Les clients ne doivent pas s'inquiéter des exceptions transitoires, network/not_leader car elles sont normales, sans impact et attendues dans le cadre du protocole Kafka.

  • Les clients ne doivent pas s' UnderReplicatedPartitions inquiéter car ils sont normaux, sans impact et attendus lors d'un seul courtier hors ligne.