Benchmarking von Apache Kafka: Leistung pro Preis

In diesem Artikel stelle ich eine Studie vor, in der Umgebungen für Apache Kafka verglichen werden. Das ultimative Ziel besteht darin, das effektivste Setup zu finden und das beste Preis-Leistungs-Verhältnis zu erzielen.

Unsere Datenplattform bietet verwaltete Dienste zum Erstellen analytischer Plattformen für große Datensätze und konkurriert mit anderen Marktlösungen. Um wettbewerbsfähig zu bleiben, führen wir regelmäßig interne Studien durch, um unsere Stärken zu identifizieren und zu verbessern und so bessere Angebote zu erzielen. Dieser Artikel stellt eine solche Studie vor. Derzeit unterstützt unsere Plattform AWS und GCP als Cloud-Anbieter. Beide bieten mehrere Rechengenerationen und zwei CPU-Architekturen (x86 mit Intel und AMD sowie ARM). Ich vergleiche diese Setups mithilfe verschiedener Java Virtual Machines (JVMs), um die Leistung neuer Versionen auf neueren Prozessoren zu bewerten.

Wenn Sie ein TL;DR möchten: ARM ist der Hammer. Moderne, teure Architektur bedeutet nicht immer „besser“. Sie können direkt zu den Ergebnissen springen oder weitermachen, um mehr über die Methodik und den Aufbau herauszufinden.

Methodik

Ich habe überlegt, die Leistung mit unserem eigenen Dienst zu testen, wollte sie aber in verschiedenen Umgebungen vergleichen, die wir noch nicht unterstützt haben. Ich wollte neue virtuelle Maschinen, Regionen und sogar andere Cloud-Anbieter ausprobieren. Also habe ich mit der Implementierung eines Spielzeugprojekts begonnen, das Baseline-Kafka mit verschiedenen Basis-Container-Images verwendet. Auf diese Weise kann ich Benchmark-Tools auf bestimmter Hardware ausführen und die Leistung messen.

Ich möchte verschiedene Konfigurationen testen, um die interessantesten Ergebnisse zu ermitteln. Dazu verwende ich die Idee der Testmatrix, um erste Ergebnisse zu filtern. Ich werde diese Ergebnisse mithilfe von Tools wie perf und eBPF eingehend analysieren, um die Leistung weiter zu verbessern.

Testfälle

Beschreiben wir zunächst die Testziele. Ich habe viel Erfahrung mit OpenJDK JVM, aber heute gibt es viele Alternativen von Microsoft, Amazon und anderen Unternehmen. Amazon Correto beispielsweise enthält zusätzliche Funktionen und Patches, die für AWS optimiert sind. Da die meisten unserer Kunden AWS verwenden, wollte ich Amazon Correto in die Tests einbeziehen, um zu sehen, wie diese JVMs auf dieser Plattform funktionieren.

Für den ersten Vergleich habe ich diese Versionen ausgewählt:

• OpenJDK 11 (für einen retrospektiven Vergleich, obwohl es veraltet ist)
• OpenJDK 17 (die aktuell verwendete JVM)
• Amazon Coretto 11.0.22-amzn (ein alternativer retrospektiver Vergleich)
• Amazon Coretto 17.0.10-amzn (eine Alternative zu unserer aktuellen Version)
• Amazon Coretto 21.0.2-amzn (eine neuere LTS-Version, die besser sein sollte)

Nachdem die Versionen definiert waren, habe ich einige Skripte vorbereitet, um Kafka-Images mit Amazon Correto und OpenJDK zu erstellen.

Bildeinstellungen

Für die Benchmarktests habe ich die Kafka-Einstellungen geändert, um mich auf bestimmte Leistungsmetriken zu konzentrieren. Ich wollte verschiedene Kombinationen von [JVM] x [Instanztyp] x [Architektur] x [Cloudprovider] testen, daher war es wichtig, die Auswirkungen der Netzwerkkonnektivität und der Festplattenleistung zu minimieren. Dies habe ich erreicht, indem ich Container mit tmpfs zur Datenspeicherung ausgeführt habe:

 podman run -ti \ --network=host \ --mount type=tmpfs,destination=/tmp \ kfbench:3.6.1-21.0.2-amzn-arm64

Natürlich ist dieses Setup nicht für die Produktion gedacht, aber die Isolierung der CPU- und Speicherengpässe war notwendig. Am besten ist es, Netzwerk- und Festplatteneinflüsse aus den Tests zu entfernen. Andernfalls würden diese Faktoren die Ergebnisse verfälschen.

Ich habe das Benchmark-Tool auf derselben Instanz verwendet, um minimale Latenz und höhere Reproduzierbarkeit sicherzustellen. Ich habe auch Tests ohne Host-Netzwerk-Konfigurationen und mit cgroup-isolierten virtuellen Netzwerken durchgeführt, aber diese führten nur zu unnötiger Latenz und erhöhter CPU-Auslastung für die Paketweiterleitung.

Obwohl tmpfs den Speicher dynamisch zuweist und Fragmentierung und Latenz verursachen kann, war es für unseren Test ausreichend. Ich hätte stattdessen Ramdisk verwenden können, das den Speicher statisch zuweist und diese Probleme vermeidet, aber tmpfs war einfacher zu implementieren und lieferte trotzdem die Erkenntnisse, die wir wollten. Für unsere Zwecke war es die richtige Balance.

Darüber hinaus habe ich einige zusätzliche Kafka-Einstellungen angewendet, um Daten häufiger aus dem Speicher zu entfernen:

 ############################# Benchmark Options ############################# # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.bytes # Chaged from 1GB to 256MB to rotate files faster log.segment.bytes = 268435456 # https://kafka.apache.org/documentation/#brokerconfigs_log.retention.bytes # Changed from -1 (unlimited) to 1GB evict them because we run in tmpfs log.retention.bytes = 1073741824 # Changed from 5 minutes (300000ms) to delete outdated data faster log.retention.check.interval.ms=1000 # Evict all data after 15 seconds (default is -1 and log.retention.hours=168 which is ~7 days) log.retention.ms=15000 # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.delete.delay.ms # Changed from 60 seconds delay to small value to prevent memory overflows log.segment.delete.delay.ms = 0

Hier ist eine Zusammenfassung der Änderungen:

• Die Protokollaufbewahrungszeit wird auf 15 Sekunden eingestellt, um Daten schneller zu entfernen, und die Protokollaufbewahrungsgröße ist auf 1 GB begrenzt, um den Speicher in tmpfs zu verwalten. Die Protokollsegmentgröße wird ebenfalls auf 256 MB geändert, um Dateien schneller zu rotieren
• Das Intervall für die Aufbewahrungsprüfung wird auf 1 Sekunde reduziert, um alte Daten schnell zu löschen
• Die Segmentlöschverzögerung wird auf 0 gesetzt, um Speicherprobleme zu vermeiden

Diese Konfiguration ist nicht für den Produktionseinsatz geeignet, aber für unsere Benchmarktests wichtig, da sie die Auswirkungen irrelevanter Faktoren reduziert.

Instanztypen

Bei DoubleCloud unterstützen wir zum Zeitpunkt der Erstellung dieses Artikels die folgenden Hauptgenerationen von Rechenressourcen:

• s1-Familie : m5a-Instanzen (wobei i1 m5 mit Intel-Prozessoren darstellt)
• s2-Familie : m6a-Instanzen (wobei i2 m6i mit Intel-Prozessoren darstellt)
• sg1-Familie : GCP n2-Standardinstanzen mit AMD Rome-Prozessoren

Für Graviton-Prozessoren unterstützen wir:

• g1-Familie : m6g-Instanzen (Graviton 2)
• g2-Familie : m7g-Instanzen (Graviton 3)

Zusätzlich habe ich t2a-Instanzen auf GCP als Alternative zu Graviton auf Ampere Altra getestet. Wir bieten diese unseren Kunden aufgrund der begrenzten regionalen Unterstützung von AWS nicht an, aber ich habe sie in die Benchmarks aufgenommen, um die Leistung zu vergleichen. Diese könnten eine gute Option sein, wenn Sie sich in einer der „richtigen“ Regionen befinden.

Benchmark-Tool

Für das Benchmarking habe ich ein leichtgewichtiges Tool entwickelt, das auf der Bibliothek und Beispielen von Franz-Go basiert. Dieses Tool sättigt Kafka effizient, ohne selbst zum Flaschenhals zu werden.

Obwohl librdkafka für seine Zuverlässigkeit und Popularität bekannt ist, habe ich es aufgrund potenzieller Probleme mit cgo gemieden.

Prüfen

Kafka ist für seine Skalierbarkeit bekannt. Themen können in mehrere Partitionen unterteilt werden, um Arbeitslasten effizient horizontal auf Broker zu verteilen. Ich habe mich jedoch auf die Bewertung der Single-Core-Leistung konzentriert, da wir uns speziell auf das Preis-Leistungs-Verhältnis konzentrieren.

Daher wurden in den Tests Themen mit einzelnen Partitionen verwendet, um die einzelnen Kernfunktionen vollständig zu nutzen.

Jeder Testfall umfasste zwei Typen:

• Synchrone Produktion: wartet auf Nachrichtenbestätigung, ideal für die Messung von Umgebungen mit geringer Latenz, in denen es auf Millisekunden ankommt, wie z. B. Echtzeitanwendungen
• Asynchrone Produktion: puffert Nachrichten und sendet sie in Stapeln, typisch für Kafka-Clients, die nahezu Echtzeitanforderungen mit einer tolerierbaren Latenz von 10-100 ms in Einklang bringen

Ich habe 8 KB große Nachrichten verwendet, also mehr als bei einem durchschnittlichen Kunden, um die Themenpartitions-Threads vollständig zu füllen.

Ergebnisse

Ich präsentiere eine Reihe von Diagrammen, in denen verschiedene Testfälle anhand einer synthetischen Effizienzmetrik verglichen werden, um unterschiedliche Architekturen zu bewerten. Diese Metrik quantifiziert Millionen von Zeilen, die wir in Prozent in den Kafka-Broker aufnehmen können , und ermöglicht so eine unkomplizierte Bewertung der Kosteneffizienz der Architektur.

Es ist wichtig zu wissen, dass die tatsächlichen Ergebnisse aufgrund zusätzlicher Rabatte der Cloud-Anbieter abweichen können. Wann immer möglich, wurden die Tests für beide Cloud-Anbieter in Frankfurt durchgeführt (oder in den Niederlanden, wenn die Optionen für Instanztypen eingeschränkt waren).

Diagramme

In allen Diagrammen verwende ich herkömmliche Namen für Instanzen, die auch ihre Anbieter verwenden. Instanzen werden zuerst nach Cloud-Anbietern (AWS, dann GCP) und dann nach Generation sortiert: von älter zu neuer.

Die vollständigen Ergebnisse, allerdings in Rohform, sind in meinem umfassenden Benchmarking-Blatt verfügbar. Dort finden Sie mehr Daten, als ich in diesem Artikel vorstelle, einschließlich Latenz- und Bandbreitenzahlen und Vergleichsergebnisse verschiedener JVMs.

AWS-Ergebnisse

s1-Familie: langsamste Leistung

Die S1-Instanzen der „1. Generation“ basierend auf der m5a-Generation mit AMD EPYC 7571, die aus dem 3. Quartal 2019 stammen, sind unsere Legacy-Option. Sie sind die am wenigsten effiziente und langsamste unserer Optionen in Frankfurt und kosten bei Bedarf etwa 0,2080 €/Std. Der Übergang zur neueren S2-Familie, die etwa 0,2070 €/Std. kostet, bietet die doppelte Effizienz bei praktisch demselben Preis. Wir empfehlen Kunden, auf diese kostengünstigeren und leistungsstärkeren Optionen umzusteigen, um die Abfragezeiten und die Aufnahmegeschwindigkeit für analytische Anwendungen zu verbessern.

g1-Familie: vergleichbare Effizienz wie s2

Die g1-Familie basiert auf Graviton 2 und hat in der Vergangenheit ein gutes Preis-Leistungs-Verhältnis geboten, aber die neuere s2-Familie mit AMD-Prozessoren erreicht jetzt dasselbe Effizienzniveau für Apache Kafka. Obwohl die g1-Familie eine etwas geringere Bandbreite und einen geringfügigen Preisvorteil bietet, gilt sie im Vergleich zu den neueren Optionen mittlerweile als veraltet.

g2-Familie: Überlegene Effizienz

Die g2-Familie, die von Graviton 3 angetrieben wird, ist aufgrund ihrer überlegenen Effizienz unsere Top-Empfehlung. Sie übertrifft die s2- und i2-Familien in bestimmten Szenarien um bis zu 39 % und bietet eine kostengünstige Lösung in nahezu allen Regionen, was sie ideal für die meisten Apache Kafka-Anwendungsfälle macht. Angesichts der typischen IO-gebundenen Natur von Kafka erweist sich die Optimierung der Recheneffizienz als entscheidend für Kosteneinsparungen. Ich habe einen wachsenden Trend zur Einführung der arm64-Architektur beobachtet, wobei fast die Hälfte unserer Cluster diese neuere Technologie bereits nutzt.

x86_64-Effizienztrends

Die Tests zeigen, dass jeder neue AMD- oder Intel-Prozessor hinsichtlich Gesamtdurchsatz und Latenzzeit besser wird. Trotzdem haben die Effizienzgewinne bei den neueren m6- und m7-Generationen ein Plateau erreicht. Selbst die m7-Generation bietet zwar möglicherweise in einigen Bereichen geringere Latenzen, erreicht aber laut unseren Tests nicht die Effizienz der g2-Familie.

m7a-Familie: führende Latenzleistung

Die m7a-Familie zeichnet sich durch Anwendungen mit geringer Latenz aus und übertrifft sowohl Intel als auch frühere AMD-Generationen in Bezug auf Durchsatz und Latenz. Obwohl diese Architektur nicht überall verfügbar ist, spiegelt sie AMDs Fortschritte bei der Leistungssteigerung wider. Wenn sie in Ihrer Region verfügbar ist, sollten Sie die m7a-Familie für bessere Ergebnisse in Betracht ziehen.

GCP-Ergebnisse

Effizienzvergleich mit AWS

GCP-Instanzen sind im Allgemeinen weniger effizient als ihre AWS-Alternativen. Das war für mich eine tolle Erkenntnis, da Kunden GCP in der Regel aufgrund seiner Kosteneffizienz bei analytischen Anwendungen bevorzugen, was zu niedrigeren Rechnungen führt. Unsere sg1-Familie verwendet die n2-Standardgeneration, vergleichbar mit der AWS s2-Familie. Mein Versuch, diesen Vergleich auf andere Instanztypen auszudehnen, war jedoch durch die regionale Verfügbarkeit eingeschränkt, insbesondere für die Generationen c3 und n2.

Arm Tau-Prozessoren: Kosteneffizienz

Arm-Instanzen mit GCPs Tau-Prozessoren bieten eine 5-7 % höhere Effizienz als Graviton 2 und sind daher eine vernünftige, kostensparende Option, sofern sie in Ihrer Region verfügbar sind . Obwohl die GCP-Unterstützung für Arm-Instanzen auf vier Regionen beschränkt ist, bietet sie eine vergleichbare Leistung und Effizienz wie die G1-Familie.

Rabatte bei anhaltender Nutzung

Da Apache Kafka-Cluster eine konstante Nutzung der VM aufweisen, sind durch die Nutzung von Sustained Use Discounts bis zu 20 % Preisnachlass möglich. Dadurch sind selbst ältere Rechenleistungsgeräte wie Ampere Altra in puncto Effizienz mit Graviton 3 konkurrenzfähig. Direkte Vergleiche sind hier jedoch schwierig, da möglicherweise zusätzliche AWS-Rabatte gelten.

JVM-Einblicke

Ich dachte, ich würde mit neueren JVM-Versionen auf der ARM-Architektur eine deutliche Verbesserung sehen. Es sieht jedoch so aus, als ob openjdk-11 und corretto-11 bereits ziemlich gut für ARM optimiert sind. Da neuere Versionen von Kafka Java 17 und höher erfordern, bin ich auf Java 17 umgestiegen, was in unseren Benchmarks zu einer Leistungssteigerung von etwa 4-8 % führte.

Darüber hinaus scheint 21.0.2-amzn vielversprechend zu sein, da es bei neueren Instanztypen eine zusätzliche Leistungssteigerung von 10–20 % bietet.

Schlussfolgerungen

Von Zeit zu Zeit führe ich interne Untersuchungen durch, um optimale Lösungen für unsere Produktionscluster zu finden und nützliche Erkenntnisse zu gewinnen. Der Wechsel zur ARM-Architektur ist für Managed Services von Vorteil, da er Geld spart und den Energieverbrauch senkt.

Der Einsatz von ARMs hat sich bereits als vorteilhaft erwiesen und sowohl die Leistung als auch die Kosteneffizienz von Managed Service für Apache Kafka und Managed Service für ClickHouse verbessert. Diese Untersuchung hat dazu beigetragen, unsere Testmatrix zu verfeinern und die effizientesten Umgebungen und Bereiche für weitere Optimierungen zu identifizieren. Wir sind immer am Ball: Wir optimieren und verfeinern hinter den Kulissen und ich teile unser Wissen gerne mit der Community. Bleiben Sie dran!