Meilleures pratiques pour les clients d'Apache Kafka

Disponibilité des producteurs

• Paramétré retries pour demander au producteur de réessayer d'envoyer les messages ayant échoué lors du basculement du broker. Nous recommandons une valeur d'entier maximum ou une valeur élevée similaire pour la plupart des cas d'utilisation. Ne pas le faire mettra fin à la haute disponibilité de Kafka.

• Définissez delivery.timeout.ms pour spécifier la limite supérieure du temps total entre l'envoi d'un message et la réception d'un accusé de réception de la part du courtier. Cela doit refléter les exigences commerciales relatives à la durée de validité d'un message. Définissez la limite de temps suffisamment longue pour permettre un nombre suffisant de nouvelles tentatives pour terminer l'opération de basculement. Nous recommandons une valeur de 60 secondes ou plus pour la plupart des cas d'utilisation.

• request.timeout.msRéglée au maximum, une seule demande doit attendre avant qu'un renvoi ne soit tenté. Nous recommandons une valeur de 10 secondes ou plus pour la plupart des cas d'utilisation.

• Définissez retry.backoff.ms pour configurer le délai entre les nouvelles tentatives afin d'éviter les tempêtes de nouvelles tentatives et l'impact sur la disponibilité. Nous recommandons une valeur minimale de 200 ms pour la plupart des cas d'utilisation.

• Paramétrez acks=all pour configurer une durabilité élevée ; cela doit être conforme à une configuration côté serveur de RF=3 et min.isr=2 pour garantir que toutes les partitions de l'ISR accusent réception de l'écriture. Lors d'un seul courtier hors ligne, c'est lemin.isr, c'est-à-dire2.

Disponibilité pour les consommateurs

• Paramétré auto.offset.reset sur latest initialement pour les groupes de consommateurs nouveaux ou recréés. Cela évite le risque d'ajouter de la charge au cluster en consommant l'intégralité de la rubrique.

• Réglez auto.commit.interval.ms lors de l'utilisationenable.auto.commit. Nous recommandons une valeur minimale de 5 secondes pour la plupart des cas d'utilisation afin d'éviter tout risque de charge supplémentaire.

• Implémentez la gestion des exceptions dans le code de traitement des messages du consommateur pour gérer les erreurs transitoires, par exemple un disjoncteur ou une mise en veille avec arrêt exponentiel. Ne pas le faire peut entraîner le blocage de l'application, ce qui peut entraîner un rééquilibrage excessif.

• Paramétrez isolation.level pour contrôler la façon de lire les messages transactionnels :

  Nous vous recommandons de toujours définir read_uncommitted implicitement par défaut. Cela est absent de certaines implémentations clientes.

  Nous recommandons une valeur de read_uncommitted lors de l'utilisation du stockage hiérarchisé.

• Réglez client.rack pour utiliser la réplique lue la plus proche. Nous vous recommandons de régler le paramètre sur le az id afin de minimiser les coûts liés au trafic réseau et la latence. Consultez la section Réduisez les coûts liés au trafic réseau de vos clients Amazon MSK grâce à Rack Awareness.

Rééquilibres de consommation

• Définissez une valeur supérieure session.timeout.ms à l'heure de démarrage d'une application, y compris toute instabilité de démarrage implémentée. Nous recommandons une valeur de 60 secondes pour la plupart des cas d'utilisation.

• Réglez heartbeat.interval.ms pour affiner la façon dont le coordinateur du groupe considère un consommateur comme étant en bonne santé. Nous recommandons une valeur de 10 secondes pour la plupart des cas d'utilisation.

• Définissez un hook d'arrêt dans votre application pour fermer proprement le consommateur sur SIGTERM, plutôt que de vous fier aux délais de session pour identifier le moment où un consommateur quitte un groupe. Les applications Kstream peuvent être définies internal.leave.group.on.close sur une valeur de. true

• Définissez group.instance.id une valeur distincte au sein du groupe de consommateurs. Idéalement, un nom d'hôte, un identifiant de tâche ou un identifiant de pod. Nous vous recommandons de toujours définir ce paramètre pour des comportements plus déterministes et une meilleure corrélation des client/server journaux lors du dépannage.

• Définissez group.initial.rebalance.delay.ms une valeur correspondant à la durée moyenne de déploiement. Cela met fin aux rééquilibres continus pendant le déploiement.

• Configurez partition.assignment.strategy pour utiliser des assignateurs persistants. Nous recommandons l'un StickyAssignor ou l'autreCooperativeStickyAssignor.

Performance du producteur

• Réglez linger.ms pour contrôler la durée pendant laquelle un producteur attend le remplissage d'un lot. Les petits lots sont coûteux en termes de calcul pour Kafka car ils se traduisent par un plus grand nombre de threads et I/O d'opérations à la fois. Nous recommandons les valeurs suivantes.

  Une valeur minimale de 5 ms pour tous les cas d'utilisation, y compris une faible latence.

  Nous recommandons une valeur plus élevée de 25 ms, pour la plupart des cas d'utilisation.

  Nous vous recommandons de ne jamais utiliser une valeur de zéro dans les cas d'utilisation à faible latence. (Une valeur nulle entraîne généralement une latence indépendamment de la surcharge d'E/S).

• Définissez batch.size pour contrôler la taille du lot envoyé au cluster. Nous vous recommandons de l'augmenter à une valeur de 64 Ko ou 128 Ko.

• Réglez ce buffer.memory paramètre lorsque vous utilisez des lots de plus grande taille. Nous recommandons une valeur de 64 Mo pour la plupart des cas d'utilisation.

• Défini send.buffer.bytes pour contrôler la mémoire tampon TCP utilisée pour recevoir des octets. Nous recommandons une valeur de -1 pour permettre au système d'exploitation de gérer cette mémoire tampon lors de l'exécution d'un producteur sur un réseau à latence élevée.

• Définissez compression.type pour contrôler la compression des lots. Nous recommandons que lz4 ou zstd exécutent un producteur sur un réseau à latence élevée.

Performance pour les consommateurs

• Définissez fetch.min.bytes cette option pour contrôler la taille d'extraction minimale à valider afin de réduire le nombre d'extractions et la charge du cluster.

  Nous recommandons une valeur minimale de 32 octets pour tous les cas d'utilisation.

  Nous recommandons une valeur supérieure de 128 octets pour la plupart des cas d'utilisation.

• Définissez fetch.max.wait.ms pour déterminer combien de temps votre consommateur attendra avant que fetch.min.bytes ne soit ignoré. Nous recommandons une valeur de 1 000 ms pour la plupart des cas d'utilisation.

• Nous recommandons que le nombre de consommateurs soit au moins égal au nombre de partitions pour améliorer le parallélisme et la résilience. Dans certains cas, vous pouvez choisir d'avoir un nombre de consommateurs inférieur au nombre de partitions pour les sujets à faible débit.

• Défini receive.buffer.bytes pour contrôler la mémoire tampon TCP utilisée pour recevoir des octets. Nous recommandons une valeur de -1 pour permettre au système d'exploitation de gérer cette mémoire tampon lors de l'exécution d'un client sur un réseau à latence élevée.

Connexions client

Le cycle de vie des connexions a un coût en termes de calcul et de mémoire sur un cluster Kafka. Un trop grand nombre de connexions créées à la fois entraîne une charge qui peut avoir un impact sur la disponibilité d'un cluster Kafka. Cet impact sur la disponibilité peut souvent amener les applications à créer encore plus de connexions, provoquant ainsi une panne en cascade, entraînant une panne complète. Un nombre élevé de connexions peut être atteint lorsqu'elles sont créées à un taux raisonnable.

Nous recommandons les mesures d'atténuation suivantes pour gérer les taux de création de connexions élevés :

• Assurez-vous que le mécanisme de déploiement de vos applications ne redémarre pas d'un seul producers/consumers coup, mais de préférence par lots plus petits.

• Au niveau de la couche application, le développeur doit s'assurer qu'un jitter aléatoire (veille aléatoire) est effectué avant de créer un client administrateur, un client producteur ou un client consommateur.

• Sur SIGTERM, lors de la fermeture de la connexion, une veille aléatoire doit être exécutée pour s'assurer que tous les clients Kafka ne sont pas fermés en même temps. Le sommeil aléatoire doit se situer dans le délai imparti avant que SIGKILL ne se produise.

  Exemple Exemple A (Java)

  sleepInSeconds(randomNumberBetweenOneAndX);
                          this.kafkaProducer = new KafkaProducer<>(this.props);

  Exemple Exemple B (Java)

  Runtime.getRuntime().addShutdownHook(new Thread(() -> {
      sleepInSeconds(randomNumberBetweenOneAndTwentyFive);
      kafkaProducer.close(Duration.ofSeconds(5));
  });

• Au niveau de la couche application, le développeur doit s'assurer que les clients ne sont créés qu'une seule fois par application selon un modèle singleton. Par exemple, lorsque vous utilisez lambda, le client doit être créé dans une portée globale et non dans le gestionnaire de méthodes.

• Nous recommandons que le nombre de connexions soit surveillé dans le but d'être stable. La connexion creation/close /shift est normale pendant les déploiements et le basculement des courtiers.

Indicateurs relatifs aux producteurs

• débit d'octets

• taux d'envoi record

• nombre moyen d'enregistrements par demande

• acks-latency-avg

• moyenne de latence des demandes

• requête-latency-max

• taux d'erreur d'enregistrement

• taux de réessais record

• taux d'erreur

Indicateurs de consommation

• taux de consommation d'enregistrements

• débit d'octets consommés

• taux de récupération

• records-lag-max

• taux d'erreur d'enregistrement

• taux d'erreur de récupération

• taux de sondage

• moyenne de latence de rééquilibrage

• taux d'engagement

Métriques communes

• taux de fermeture de connexion

• taux de création de connexions

• nombre de connexions