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 und zu erstellen. Amazon Correto OpenJDK Bildeinstellungen Für die Benchmarktests habe ich die Kafka-Einstellungen geändert, um mich auf bestimmte Leistungsmetriken zu konzentrieren. Ich wollte verschiedene Kombinationen von 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: [JVM] x [Instanztyp] x [Architektur] x [Cloudprovider] 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 angewendet, um Daten häufiger aus dem Speicher zu entfernen: zusätzliche Kafka-Einstellungen ############################# 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: wird auf 15 Sekunden eingestellt, um Daten schneller zu entfernen, und ist auf 1 GB begrenzt, um den Speicher in tmpfs zu verwalten. wird ebenfalls auf 256 MB geändert, um Dateien schneller zu rotieren Die Protokollaufbewahrungszeit die Protokollaufbewahrungsgröße Die Protokollsegmentgröße Das wird auf 1 Sekunde reduziert, um alte Daten schnell zu löschen Intervall für die Aufbewahrungsprüfung Die wird auf 0 gesetzt, um Speicherprobleme zu vermeiden Segmentlöschverzögerung 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: : m5a-Instanzen (wobei i1 m5 mit Intel-Prozessoren darstellt) s1-Familie : m6a-Instanzen (wobei i2 m6i mit Intel-Prozessoren darstellt) s2-Familie : GCP n2-Standardinstanzen mit AMD Rome-Prozessoren sg1-Familie Für Graviton-Prozessoren unterstützen wir: : m6g-Instanzen (Graviton 2) g1-Familie : m7g-Instanzen (Graviton 3) g2-Familie 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 entwickelt, das auf basiert. Dieses Tool sättigt Kafka effizient, ohne selbst zum Flaschenhals zu werden. Tool der Bibliothek und Beispielen von Franz-Go Obwohl für seine Zuverlässigkeit und Popularität bekannt ist, habe ich es aufgrund potenzieller Probleme mit cgo gemieden. librdkafka 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 verglichen werden, um unterschiedliche Architekturen zu bewerten. Diese Metrik quantifiziert , und ermöglicht so eine unkomplizierte Bewertung der Kosteneffizienz der Architektur. Effizienzmetrik Millionen von Zeilen, die wir in Prozent in den Kafka-Broker aufnehmen können 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 verfügbar. Dort finden Sie mehr Daten, als ich in diesem Artikel vorstelle, einschließlich Latenz- und Bandbreitenzahlen und Vergleichsergebnisse verschiedener JVMs. umfassenden Benchmarking-Blatt 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, . 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. sofern sie in Ihrer Region verfügbar sind Rabatte bei anhaltender Nutzung Da Apache Kafka-Cluster eine konstante Nutzung der VM aufweisen, sind durch die Nutzung 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. von Sustained Use Discounts 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!
