Erkundung der Bandbreitenbeschränkungen von Kafka für Dropbox

Die weit verbreitete Verwendung von Apache-Stack-Technologien ist ein offensichtlicher Trend. Und Kafka steht an der Spitze der Popularität: Heute überschreiten Menschen, die einen solchen Nachrichtenbroker kennen, vielleicht die Anzahl derer, die es gewohnt sind, das Wort Franz neben dem Wort Kafka zu sehen.

Wir selbst setzen diese Technologie aktiv in unseren Projekten ein. Aber es ist immer interessant, aber wie funktioniert es für andere? Und es ist doppelt interessant, wenn dies nicht nur ein Beispiel aus der Praxis eines Menschen ist, sondern ein gezieltes Testen der Technologie. Aus diesem Grund haben wir kürzlich einen Artikel übersetzt, in dem es darum geht, wie Dropbox empirisch nach Grenzen von Chancen- und Ausdauergrenzen bei Kafka gesucht hat. Und gefunden, was er wollte.

Erkundung der Bandbreitenbeschränkungen von Kafka für Dropbox
Apache Kafka ist eine beliebte Lösung für das verteilte Streaming und die sequentielle Verarbeitung großer Datenmengen. Es ist in der High-Tech-Industrie weit verbreitet, und Dropbox ist keine Ausnahme. Kafka spielt eine wichtige Rolle in der Datenstruktur vieler unserer kritischen verteilten Systeme - Datenanalyse, maschinelles Lernen, Überwachung, Abruf und Stream-Verarbeitung (Cape) (und dies sind nur einige davon).

Bei Dropbox werden Kafka-Cluster vom Jetstream-Team verwaltet, dessen Hauptverantwortung darin besteht, qualitativ hochwertige Dienste im Zusammenhang mit Kafka bereitzustellen. Das Verständnis der Kafka-Bandbreitenbeschränkung innerhalb der Dropbox-Infrastruktur ist entscheidend, um die richtigen Entscheidungen über die Zuweisung von Ressourcen in verschiedenen Anwendungsfällen zu treffen. Dies war eines der vorrangigen Ziele des Teams. Wir haben kürzlich eine automatisierte Testplattform erstellt, um dies zu erreichen. Und in dieser Veröffentlichung möchten wir unsere Methode und die Ergebnisse teilen.

Testplattform

Die obige Abbildung zeigt die Parameter unserer Testplattform für diese Studie. Wir verwenden Spark, um Kafka-Kunden zu hosten, wodurch wir Datenverkehr in einem beliebigen Volumen produzieren und konsumieren können. Wir haben drei Kafka-Cluster unterschiedlicher Größe erstellt, sodass die Optimierung der Clustergröße buchstäblich darauf reduziert wurde, den Datenverkehr an einen anderen Punkt umzuleiten. Kafka hat ein Thema für die Produktion und den Verbrauch von Testverkehr erstellt. Der Einfachheit halber haben wir den Datenverkehr gleichmäßig auf alle Broker verteilt. Zu diesem Zweck haben wir ein Testthema erstellt, bei dem die Anzahl der Abschnitte zehnmal so hoch ist wie die Anzahl der Broker. Jeder Broker führt genau 10 Abschnitte. Da das Schreiben in einen Abschnitt sequentiell erfolgt, können zu wenige Partitionen, die einem Broker zugewiesen sind, zu einem wettbewerbsfähigen Schreiben führen, wodurch die Bandbreite begrenzt wird. Unsere Experimente haben gezeigt, dass 10 eine gute Zahl ist, um die mit der Wettbewerbsaufzeichnung verbundenen Engpassschwierigkeiten zu beseitigen.

Aufgrund der Verteilung unserer Infrastruktur befinden sich unsere Kunden in verschiedenen Regionen der USA. Angesichts der Tatsache, dass unser Testverkehr deutlich unter der Grenze der Dropbox-Amtsleitungskanäle liegt, können wir davon ausgehen, dass diese Grenze des interregionalen Verkehrs auch für den lokalen Verkehr gilt.

Was beeinflusst die Last?

Es gibt viele Faktoren, die die Auslastung des Kafka-Clusters beeinflussen können: die Anzahl der Hersteller, die Anzahl der Verbrauchergruppen, der anfängliche Versatz der Verbraucher, die Anzahl der Nachrichten pro Sekunde, die Größe jeder Nachricht, die Anzahl der beteiligten Themen und Abschnitte. Und das sind nur einige davon. Der Freiheitsgrad bei der Einstellung von Parametern ist hoch. Daher müssen wir die dominierenden Faktoren finden, um die Komplexität des Testens auf ein akzeptables Maß zu reduzieren.

Wir haben verschiedene Kombinationen von Parametern untersucht, die wir für geeignet befunden haben. Wir kamen zu dem nicht überraschenden Schluss, dass die Hauptfaktoren, die berücksichtigt werden sollten, die Hauptkomponenten der Last sind: die Anzahl der pro Sekunde (s / s) erzeugten Nachrichten und die Anzahl der Bytes pro Nachricht (b / s).

Verkehrsmodell

Wir haben einen formalen Ansatz gewählt, um die Grenzen von Kafka zu verstehen. Es gibt einen verwandten Verkehrsraum für einen bestimmten Kafka-Cluster. Jeder Punkt in diesem mehrdimensionalen Raum entspricht einem eindeutigen Verkehrszustand, der für Kafka gilt und als Vektor von Parametern dargestellt wird: <s ​​/ s, b / s, # Produzenten, # Verbrauchergruppen, # Themen, ...>. Alle Verkehrszustände, die nicht zu einer Überlastung von KafKa führen, bilden einen geschlossenen Unterraum, dessen Oberfläche den Kafka-Cluster begrenzt.

Für unseren ersten Test haben wir s / s und b / s als Hauptparameter gewählt und den Verkehrsraum auf eine zweidimensionale Ebene reduziert. Die Grenzen des zulässigen Verkehrs bilden klare Verfolgungsbereiche. Die Erkennung der Kafka-Grenze entspricht in unserem Fall der Bestimmung der Grenzwerte dieses Bereichs.

Testautomatisierung

Um die Grenzen mit ausreichender Genauigkeit festzulegen, mussten Hunderte von Tests mit verschiedenen Parametern durchgeführt werden - was manuell äußerst irrational wäre. Aus diesem Grund haben wir einen Algorithmus entwickelt, mit dem Sie alle Experimente ohne menschliches Eingreifen durchführen können.

Überlastungsrate

Es ist sehr wichtig, eine Reihe von Indikatoren zu finden, mit denen Sie den Status von Kafka programmgesteuert bewerten können. Wir haben eine Vielzahl möglicher Indikatoren untersucht und uns für die folgende kleine Stichprobe entschieden:

• Ein einfacher E / A-Stream liegt unter 20%. Dies bedeutet, dass der von Kafka zur Verarbeitung von Clientanforderungen verwendete Workflow-Pool zu voll ist und eingehende Aufgaben nicht bewältigen kann.
• Änderung des Satzes synchronisierter Replikate (ISR) um mehr als 50%: Dies bedeutet, dass mindestens ein Broker keine Zeit hat, um die von seinem Leader empfangenen Daten zu duplizieren, wenn er 50% der beobachteten Zeit Datenverkehr verwendet.

Dieselben Indikatoren werden in Jetstream verwendet, um den Status von Kafka zu überwachen und als erste Alarmsignale für eine Clusterüberlastung zu dienen.

Grenzen finden

Um einen Grenzwert zu bestimmen, korrigieren wir b / s und ändern dann s / s, um Kafka zur Überlastung zu bringen. Es ist möglich, den Grenz-S / S-Wert zu bestimmen, wenn wir den sicheren S / S-Wert kennen und nahe daran sind, aber bereits eine Überlastung verursachen. Von diesen beiden wird der sichere s / s-Wert als Grenzwert verwendet. Wie unten gezeigt, wird die Linie der Grenzwerte gemäß den Ergebnissen ähnlicher Tests mit verschiedenen Indikatoren b / s gebildet:



Es ist erwähnenswert, dass wir, anstatt s / s direkt zu regulieren, mit einer anderen Anzahl von Herstellern experimentiert haben, die die gleiche Produktionsgeschwindigkeit haben, bezeichnet mit np. Die Stapelverarbeitung von Nachrichten erschwert die Kontrolle über die Produktionsgeschwindigkeit eines einzelnen Herstellers. Im Gegensatz dazu können Sie durch Ändern der Anzahl der Hersteller den Datenverkehr linear ändern. Nach unseren frühen Untersuchungen wird eine einfache Erhöhung der Anzahl der Hersteller keinen merklichen Unterschied in der Belastung von Kafka bewirken.

Zunächst finden wir mithilfe einer binären Suche einen separaten Grenzwert. Die Suche beginnt mit einem sehr großen Bereich np [0, max], wobei max der Wert ist, der notwendigerweise zu einer Überlastung führt. In jeder Iteration wird ein Durchschnittswert ausgewählt, um Verkehr zu erzeugen. Wenn Kafka mit diesem Wert überladen ist, wird dieser Durchschnittswert zur neuen Obergrenze. Andernfalls wird es eine neue Untergrenze. Der Suchvorgang wird beendet, wenn der Bereich ausreichend eingeschränkt ist. Dann betrachten wir die s / s-Indikatoren, die sich auf die festgelegte untere Grenze der Grenzwerte beziehen.

Ergebnis



Wie Sie im obigen Diagramm sehen können, legen wir die Grenzwerte für Kafka unterschiedlicher Größe fest. Basierend auf den Ergebnissen kamen wir zu dem Schluss, dass der maximal mögliche Durchsatz der Dropbox-Infrastruktur 60 Mbit / s pro Broker beträgt.

Es sollte betont werden, dass dies eine konservative Grenze ist, da der Inhalt unserer Testnachrichten so zufällig wie möglich war, um den Effekt der internen Nachrichtenkomprimierung in Kafka zu verringern. Wenn der Datenverkehr an seine Grenzen stößt, sind sowohl das Laufwerk als auch das Netzwerk voll ausgelastet. In Arbeitsskripten entsprechen Kafka-Nachrichten normalerweise einem bestimmten Muster, da sie häufig durch ähnliche Algorithmen gebildet werden. Dies bietet erhebliche Möglichkeiten zur Optimierung der Nachrichtenkomprimierung. Wir haben ein extremes Szenario getestet, in dem Nachrichten aus einem einzelnen Zeichen bestehen und einen viel höheren Durchsatz verzeichnen, da Festplatte und Netzwerk keinen Engpass mehr darstellen.

Darüber hinaus sind diese Durchsatzindikatoren korrekt, wenn mindestens 5 Verbrauchergruppen das getestete Thema abonnieren. Mit anderen Worten wird die angegebene Aufzeichnungsbandbreite erreicht, wenn die Lesebandbreite fünfmal größer ist. Wenn die Anzahl der Verbrauchergruppen 5 überschreitet, beginnt die Aufzeichnungsbandbreite zu sinken, da das Netzwerk zu einem Engpass wird. Da das Verhältnis von Lese- und Schreibverkehr in Fällen, in denen Dropbox-Produktionscluster verwendet werden, viel weniger als 5 beträgt, erstreckt sich die erhaltene Bandbreite auf alle Produktionscluster.

Dieses Ergebnis hilft Ihnen dabei, Ressourcen für zukünftige Kafka besser zu planen. Wenn beispielsweise bis zu 20% aller Broker offline arbeiten sollen, sollte die maximale sichere Bandbreite eines Brokers 60 MB / s * 0,8 ~ = 50 Mb / s betragen. Diese Zahl kann fortan verwendet werden, um die Clustergröße abhängig vom geplanten Durchsatz zukünftiger Anwendungsfälle zu bestimmen.

Werkzeuge für die zukünftige Arbeit

Die Plattform und der automatisierte Tester werden wertvolle Werkzeuge für das Jetstream-Team in ihrer zukünftigen Arbeit sein. Wenn wir auf eine neue Hardware umsteigen, die Netzwerkkonfiguration ändern oder die Version von Kafka aktualisieren, können wir diese Tests einfach erneut ausführen und neue Daten zu den zulässigen Grenzen der neuen Konfiguration abrufen. Wir können dieselbe Methode anwenden, um andere Faktoren zu untersuchen, die die Leistung von Kafka auf verschiedene Weise beeinflussen können. Schließlich kann die Plattform als Jetstream-Testumgebung fungieren, um neue Verkehrsoptionen zu simulieren oder Probleme in einer isolierten Umgebung zu reproduzieren.

Zusammenfassend

In diesem Artikel haben wir unseren systematischen Ansatz zum Verständnis der Grenzen von Kafka vorgestellt. Es ist wichtig zu beachten, dass wir diese Ergebnisse basierend auf der Dropbox-Infrastruktur erzielt haben, sodass unsere Zahlen aufgrund der unterschiedlichen Hardware-, Software- und Netzwerkbedingungen möglicherweise nicht für andere Kafka-Installationen gelten. Wir hoffen, dass die hier vorgestellte Methodik den Lesern helfen kann, ihre eigenen Systeme zu verstehen.