Explorer les limites de bande passante de Kafka sur Dropbox

L'utilisation généralisée des technologies de pile Apache est une tendance évidente. Et Kafka est à la pointe de la popularité: aujourd'hui, les gens qui connaissent un tel courtier de messages dépassent peut-être le nombre de ceux qui ont l'habitude de voir le mot Franz à côté du mot Kafka.

Nous-mêmes utilisons activement cette technologie dans nos projets. Mais c'est toujours intéressant, mais comment ça marche pour les autres? Et c'est doublement intéressant si ce n'est pas seulement un exemple tiré de la pratique de quelqu'un, mais des tests ciblés de la technologie. Par conséquent, nous avons traduit un article récent qui explique comment Dropbox a recherché empiriquement les limites des opportunités et des limites d'endurance chez Kafka. Et a trouvé ce qu'il voulait.

Explorer les limites de bande passante de Kafka sur Dropbox
Apache Kafka est une solution populaire pour le streaming distribué et le traitement séquentiel de grandes quantités de données. Il est largement utilisé dans l'industrie de haute technologie et Dropbox ne fait pas exception. Kafka joue un rôle important dans la structure des données de bon nombre de nos systèmes distribués critiques - analyse des données, apprentissage automatique, surveillance, récupération et traitement des flux (Cape) (et ce ne sont que quelques-uns).

Chez Dropbox, les clusters Kafka sont gérés par l'équipe Jetstream, dont la responsabilité principale est de fournir des services de haute qualité liés à Kafka. Comprendre la limite de bande passante de Kafka dans l'infrastructure Dropbox est essentiel pour prendre les bonnes décisions sur la façon d'allouer les ressources dans différents cas d'utilisation, et c'était l'un des objectifs prioritaires de l'équipe. Nous avons récemment créé une plate-forme de test automatisée pour y parvenir. Et dans cette publication, nous aimerions partager notre méthode et les résultats.

Plateforme de test

La figure ci-dessus montre les paramètres de notre plateforme de test pour cette étude. Nous utilisons Spark pour héberger les clients Kafka, ce qui nous permet de produire et de consommer du trafic dans un volume arbitraire. Nous avons créé trois clusters Kafka de tailles différentes, de sorte que le réglage de la taille du cluster a été littéralement réduit à rediriger le trafic vers un autre point. Kafka a créé un sujet pour la production et la consommation de trafic de test. Pour plus de simplicité, nous avons réparti uniformément le trafic entre tous les courtiers. Pour ce faire, nous avons créé un sujet de test avec le nombre de sections dix fois le nombre de courtiers. Chaque courtier dirige exactement 10 sections. Comme l'écriture dans une section est séquentielle, trop peu de sections allouées par courtier peuvent conduire à une écriture compétitive, ce qui limite la bande passante. Nos expériences ont montré que 10 est un bon nombre pour éliminer les difficultés de goulot d'étranglement associées à l'enregistrement concurrentiel.

En raison de la nature distribuée de notre infrastructure, nos clients sont situés dans diverses régions des États-Unis. Étant donné que notre trafic de test est nettement inférieur à la limite des canaux de jonction Dropbox, nous pouvons supposer avec confiance que cette limite de trafic interrégional est également applicable au trafic local.

Qu'est-ce qui affecte la charge?

De nombreux facteurs peuvent affecter la charge du cluster Kafka: le nombre de producteurs, le nombre de groupes de consommateurs, le décalage initial des consommateurs, le nombre de messages par seconde, la taille de chaque message, le nombre de sujets et de sections concernés. Et ce ne sont que quelques-uns d'entre eux. Le degré de liberté dans le réglage des paramètres est élevé. Ainsi, nous devons trouver les facteurs dominants afin de réduire la complexité des tests à un niveau acceptable.

Nous avons examiné diverses combinaisons de paramètres que nous avons trouvées appropriées. Nous sommes arrivés à la conclusion sans surprise que les facteurs dominants à prendre en compte sont les principales composantes de la charge: le nombre de messages produits par seconde (s / s) et le nombre d'octets par message (b / s).

Modèle de trafic

Nous avons adopté une approche formelle pour comprendre les limites de Kafka. Il existe un espace de trafic associé pour un cluster Kafka particulier. Chaque point de cet espace multidimensionnel correspond à un état de trafic unique applicable à Kafka et présenté comme un vecteur de paramètres: <s / s, b / s, # producteurs, # groupes de consommateurs, # thèmes, ...>. Tous les états de trafic qui n'entraînent pas de congestion KafKa forment un sous-espace fermé dont la surface limitera le cluster Kafka.

Pour notre premier test, nous avons choisi s / s et b / s comme paramètres principaux et réduit l'espace de trafic à un plan bidimensionnel. Les limites du trafic autorisé forment des zones de suivi claires. La détection de la limite de Kafka dans notre cas équivaut à déterminer les valeurs limites de cette zone.

Automatisation des tests

Afin de fixer les limites avec une précision suffisante, il a été nécessaire d'effectuer des centaines de tests avec différents paramètres - ce qui serait extrêmement irrationnel à faire manuellement. Par conséquent, nous avons développé un algorithme qui vous permet d'effectuer toutes les expériences sans intervention humaine.

Taux de congestion

Il est très important de trouver un ensemble d'indicateurs qui vous permettent d'évaluer par programme l'état de Kafka. Nous avons examiné un large éventail d'indicateurs possibles et nous nous sommes basés sur le petit échantillon suivant:

• un simple flux d'E / S est inférieur à 20%: cela signifie que le pool de flux de travail utilisé par Kafka pour traiter les demandes des clients est trop occupé et ne peut pas faire face aux tâches entrantes.
• modification de l'ensemble des répliques synchronisées (ISR) de plus de 50%: cela signifie que lors de l'utilisation du trafic pendant 50% du temps observé, au moins un courtier n'a pas le temps de dupliquer les données reçues de son leader.

Les mêmes indicateurs sont utilisés dans Jetstream pour surveiller l'état de Kafka et servir de premiers signaux d'alarme de surcharge de cluster.

Trouver des frontières

Pour déterminer une valeur limite, nous fixons b / s, puis changeons s / s pour amener Kafka en surcharge. Il est possible de déterminer la valeur s / s limite lorsque nous connaissons la valeur s / s sûre et qu'elle est proche, mais qu'elle provoque déjà une surcharge. Parmi ces deux, la valeur s / s sûre est prise comme valeur limite. Comme indiqué ci-dessous, la ligne des valeurs limites est formée en fonction des résultats de tests similaires avec différents indicateurs b / s:



Il convient de noter qu'au lieu de réguler directement s / s, nous avons expérimenté avec un nombre différent de fabricants ayant la même vitesse de production, notée np. Le fait est que le traitement par lots des messages complique le contrôle de la vitesse de production d'un seul fabricant. Un changement dans le nombre de fabricants, en revanche, vous permet de modifier linéairement le trafic. Selon nos premières recherches, une simple augmentation du nombre de fabricants ne créera pas de différence notable dans la charge sur Kafka.

Pour commencer, nous trouvons une valeur de limite distincte en utilisant une recherche binaire. La recherche commence par une très large plage np [0, max], où max est la valeur qui entraînera nécessairement une surcharge. À chaque itération, une valeur moyenne est sélectionnée pour créer du trafic. Si Kafka est surchargé avec cette valeur, alors cette valeur moyenne devient la nouvelle borne supérieure; sinon, il devient une nouvelle borne inférieure. Le processus de recherche s'arrête lorsque la plage est suffisamment réduite. Ensuite, nous considérons les indicateurs s / s, qui sont liés à la limite inférieure établie des valeurs de limite.

Résultat



Comme vous pouvez le voir dans le diagramme ci-dessus, nous définissons les valeurs limites pour Kafka de différentes tailles. Sur la base des résultats, nous sommes arrivés à la conclusion que le débit maximal possible de l'infrastructure Dropbox est de 60 Mo / s par courtier.

Il convient de souligner qu'il s'agit d'une limite conservatrice, car le contenu de nos messages de test était aussi aléatoire que possible afin de réduire l'effet de la compression des messages internes dans Kafka. Lorsque le trafic atteint sa limite, le lecteur et le réseau sont pleinement utilisés. Dans les scripts de travail, les messages Kafka correspondent généralement à un certain modèle, car ils sont souvent formés par des algorithmes similaires. Cela offre des opportunités importantes pour optimiser la compression des messages. Nous avons testé un scénario extrême, lorsque les messages se composent d'un seul caractère, et enregistré un débit beaucoup plus élevé, car le disque et le réseau ne sont plus un goulot d'étranglement.

En outre, ces indicateurs de débit sont corrects si au moins 5 groupes de consommateurs sont abonnés au sujet testé. En d'autres termes, la largeur de bande d'enregistrement indiquée est atteinte lorsque la largeur de bande de lecture est 5 fois supérieure. Lorsque le nombre de groupes de consommateurs dépasse 5, la bande passante d'enregistrement commence à diminuer à mesure que le réseau devient un goulot d'étranglement. Étant donné que le rapport entre le trafic de lecture et d'écriture est bien inférieur à 5 dans les cas où des clusters de production Dropbox sont utilisés, la bande passante obtenue s'étend à tous les clusters de production.

Ce résultat vous aidera à mieux planifier les ressources pour le futur Kafka. Par exemple, si nous voulons autoriser jusqu'à 20% de tous les courtiers à travailler hors ligne, la bande passante maximale sécurisée d'un courtier doit être de 60 Mo / s * 0,8 ~ = 50 Mo / s. Ce nombre peut désormais être utilisé pour déterminer la taille du cluster, en fonction du débit prévu des futurs cas d'utilisation.

Outils pour les travaux futurs

La plateforme et le testeur automatisé seront des outils précieux pour l'équipe Jetstream dans ses futurs travaux. Lorsque nous passons à un nouveau matériel, modifions la configuration du réseau ou mettons à jour la version de Kafka, nous pouvons simplement réexécuter ces tests et obtenir de nouvelles données sur les limites autorisées de la nouvelle configuration. Nous pouvons appliquer la même méthodologie pour étudier d'autres facteurs qui peuvent affecter les performances de Kafka de diverses manières. Enfin, la plateforme peut servir de banc d'essai Jetstream pour simuler de nouvelles options de trafic ou reproduire des problèmes dans un environnement isolé.

Pour résumer

Dans cet article, nous avons présenté notre approche systématique pour comprendre les limites de Kafka. Il est important de noter que nous avons obtenu ces résultats sur la base de l'infrastructure Dropbox, de sorte que nos chiffres peuvent ne pas être applicables à d'autres installations Kafka en raison de la différence dans les conditions matérielles, logicielles et réseau. Nous espérons que la méthodologie présentée ici pourra aider les lecteurs à comprendre leurs propres systèmes.