Comment décider de la taille du cluster Kafka
Je prévois de décider combien de nœuds doivent être présents sur le cluster Kafka. Je ne suis pas sûr des paramètres à prendre en compte. Je suis sûr que cela doit être> = 3 (avec un facteur de réplication de 2 et une tolérance d'échec de 1 nœud).
Quelqu'un peut-il me dire quels paramètres doivent être gardés à l'esprit lors du choix de la taille de la grappe et de leur impact sur la taille?.
Je connais les facteurs suivants, mais je ne sais pas comment cela affecte quantitativement la taille de la grappe. Je sais comment cela affecte qualitativement la taille de la grappe. Existe-t-il un autre paramètre qui affecte la taille du cluster? 1. Replication factor (cluster size >= replication factor)2. Node failure tolerance. (cluster size >= node-failure + 1)
Quelle devrait être la taille de la grappe pour le scénario suivant en tenant compte de tous les paramètres 1. There are 3 topics.2. Each topic has messages of different size. Message size range is 10 to 500kb. Average message size being 50kb.3. Each topic has different partitions. Partitions are 10, 100, 5004. Retention period is 7 days5. There are 100 million messages which gets posted every day for each topic.
Quelqu'un peut-il m'indiquer la documentation pertinente ou tout autre blog susceptible d'en parler? J'ai fait une recherche google mais en vain
Si je comprends bien, obtenir un bon débit de Kafka ne dépend pas uniquement de la taille du cluster; il y a d'autres configurations à prendre en compte. Je vais essayer de partager autant que je peux.
Le débit de Kafka est supposé être linéairement scalable avec le nombre de disques que vous avez. La nouvelle fonctionnalité de plusieurs répertoires de données introduite dans Kafka 0.8 permet aux sujets de Kafka d’avoir différentes partitions sur différentes machines. À mesure que le nombre de partitions augmente considérablement, les chances que le processus d'élection du chef soit plus lent augmentent également, entraînant également un rééquilibrage des consommateurs. C'est quelque chose à considérer et pourrait être un goulot d'étranglement.
Un autre élément clé pourrait être le taux de vidage du disque. Comme Kafka écrit toujours immédiatement toutes les données dans le système de fichiers, plus les données sont souvent vidées sur le disque, plus Kafka sera "lié à la recherche" et plus le débit sera faible. Là encore, un taux de vidage très faible peut entraîner différents problèmes, car dans ce cas, la quantité de données à vider sera importante. Donc, fournir un chiffre exact n’est pas très pratique et je pense que c’est la raison pour laquelle vous n’avez pas pu trouver une réponse aussi directe dans la documentation de Kafka.
Il y aura aussi d'autres facteurs. Par exemple, la taille fetch du consommateur, les compressions, la taille de lot pour les producteurs asynchrones, les tailles de mémoire tampon de socket, etc.
Le matériel et le système d'exploitation joueront également un rôle clé à cet égard, car l'utilisation de Kafka dans un environnement Linux est recommandée en raison de son mécanisme pageCache pour l'écriture de données sur le disque. En savoir plus sur ce sujet ici
Vous voudrez peut-être également examiner comment le comportement de vidage du système d'exploitation joue un rôle clé dans la prise en compte avant de l'adapter réellement à vos besoins. Je pense qu'il est essentiel de comprendre la philosophie de conception, ce qui la rend si efficace en termes de débit et de tolérance aux pannes.
Un peu plus de ressources que je trouve utiles pour creuser
- https://engineering.linkedin.com/kafka/benchmarking-Apache-kafka-2-million-writes-second-three-chree-cheap-machines
- http://blog.liveramp.com/2013/04/08/kafka-0-8-producer-performance-2/
- https://grey-boundary.io/load-testing-Apache-kafka-on-aws/
- https://cwiki.Apache.org/confluence/display/KAFKA/Performance+testing
J'avais récemment travaillé avec Kafka et ce sont mes observations.
Chaque sujet est divisé en partitions et toutes les partitions d'un sujet sont réparties entre des courtiers Kafka. Tout d'abord, ils aident à sauvegarder des sujets dont la taille est supérieure à la capacité d'un seul courtier kafka et augmentent également le parallélisme des consommateurs.
Pour augmenter la fiabilité et la tolérance aux pannes, des réplications des partitions sont effectuées sans augmenter le parallélisme des consommateurs. La règle du pouce est qu'un seul courtier ne peut héberger qu'un seul réplica par partition . Par conséquent, le nombre de courtiers doit être> = Nb de répliques
Toutes les partitions sont réparties sur tous les courtiers disponibles; le nombre de partitions peut être indépendant du nombre de courtiers, mais le nombre de partitions doit être égal au nombre de threads consommateurs d'un groupe de consommateurs (pour obtenir le meilleur débit).
La taille de la grappe doit être déterminée en tenant compte du débit que vous souhaitez atteindre chez le consommateur.
Le total MB/s par courtier serait:
Données/jour = (100 × 10 ^ 6 messages/jour) × 0,5 Mo = 5 To/jour par sujet
Cela nous donne environ 58 Mo/s par courtier. En supposant que les messages soient également répartis entre les partitions, nous obtenons pour le cluster total: 58 Mo/s x 3 Sujets = 178 Mo/s pour tout le cluster.
Maintenant, pour la réplication, vous avez: 1 réplica supplémentaire par sujet. Par conséquent, cela devient 58 Mo/sec/courtier INCOMING en données originales + 58 Mo/sec/courtier OUTGOING en réplication données + 58 Mo/sec/en courtier INCOMING données de réplication.
Cela représente environ ~ 136 Mo/s par entrée de courtier et 58 Mo/s par sortie de courtier.
La charge du système va devenir très importante, sans tenir compte du traitement de flux.
La charge du système peut être gérée en augmentant le nombre de courtiers et en divisant vos sujets en partitions plus spécifiques . Si vos données sont très importantes, vous souhaiterez peut-être un facteur de réplication différent (élevé). La tolérance aux pannes est également un facteur important pour décider de la réplication.
Par exemple, si vous avez des données très importantes, hormis pour les N courtiers actifs (avec les répliques) qui gèrent vos partitions, vous devrez peut-être ajouter des suiveurs en veille dans des zones différentes . très faible latence, vous pouvez alors augmenter encore le nombre de partitions (en ajoutant des clés supplémentaires). Plus vous avez de clés, moins vous aurez de messages de volonté sur chaque partition . Pour une latence faible, vous souhaiterez peut-être un nouveau cluster (avec les réplicas) ne gérant que ce sujet spécial et aucun calcul supplémentaire n'est effectué pour les autres sujets. . Si un sujet n’est pas très important, vous voudrez peut-être réduire le facteur de réplication de ce sujet particulier et être plus élastique face à la perte de données ..___. Lors de la construction d’un cluster Kafka, les machines prenant en charge votre infrastructure capable. Autrement dit, étant donné que le partitionnement est fait avec un style alternatif, vous vous attendez à ce que chaque courtier soit capable de gérer la même charge. Par conséquent, la taille de vos messages n'a pas d'importance.
La charge résultant du traitement du flux aura également un impact direct. Un bon logiciel pour gérer votre moniteur Kafka et gérer vos flux est Objectifs , ce que je préfère personnellement, dans la mesure où il effectue un travail incroyable avec le traitement des flux en temps réel