Kafka Sizing & Scaling: Hardware-Anforderungen und Strategien zur Skalierung

Man braucht kein riesiges Cluster, um Kafka produktiv zu betreiben. Wir räumen mit Hardware-Mythen auf und zeigen, wie man mit 3 Brokern effizient startet und sauber skaliert.

Von Anatoly Zelenin

Wenn man sich in die Dokumentationen von Kafka-Anbietern einliest, könnte man meinen, dass man gigantische Mengen an Hardware benötigt, um einen Kafka-Cluster aufzubauen. Die Realität ist zum Glück eine andere. Denn Kafka kann mit erstaunlich wenig Ressourcen ziemlich viel erreichen.

In diesem Post besprechen wir sinnvolle Minimalanforderungen und Skalierungsmöglichkeiten.

Der häufigste Fehler: Die Clients

Bevor wir über Hardware sprechen, ein wichtiger Hinweis vorab: Oft liegt eine hohe Ressourcenlast gar nicht an den Kafka Brokern selbst, sondern an fehlkonfigurierten Clients.

Schlechte Batch-Sizes oder unnötig aggressive Polling-Intervalle können einen Cluster in die Knie zwingen, egal wie viel Hardware man darauf wirft. Prüfe also zuerst deine Clients, bevor du den Cluster vergrößerst.

Im Artikel Apache Kafka Clients richtig konfigurieren findest du mehr Informationen zur richtigen Konfiguration der Clients.

Controller

Wir empfehlen stets, mit drei dedizierten Controller-Knoten zu starten.

Auch wenn es technisch möglich ist, Controller und Broker in der gleichen JVM laufen zu lassen, macht die Trennung eine spätere Skalierung deutlich einfacher und den Betrieb stabiler.

Üblicherweise reichen drei Controller-Knoten auch für größere Kafka Cluster vollständig aus. Sie sind relativ genügsam:

  • Start: 1-2 GB RAM und 0,5 CPU-Kerne reichen für den Anfang völlig.

  • Storage: 10 GB Speicherplatz werden eine sehr lange Zeit reichen.

  • Peak: Selbst in einem stark belasteten Kafka-Cluster benötigen die Controller maximal 4-8 GB RAM und 1-2 CPU-Kerne.

Die Anzahl der Controller hat keinen Einfluss auf die Performance, sondern ausschließlich auf die Zuverlässigkeit des Quorums. Bei drei Controllern kann einer ausfallen, ohne dass es zu Einschränkungen kommt. Bei fünf Controllern können zwei ausfallen. Unserer Meinung nach reichen für die allermeisten Anwendungsfälle drei Controller vollständig aus.

Hinweis: Die Regeln hier gelten sowohl für den modernen KRaft-Modus als auch für ältere ZooKeeper-Setups.

Broker

Bei den eigentlichen Brokern ist die Sache etwas komplexer. Hier müssen wir Speicher, RAM, CPU und Netzwerk betrachten.

Storage

Ganz wichtig ist es, den Brokern schnellen und latenzarmen Speicher zur Verfügung zu stellen. Kafka reagiert empfindlich auf Latenzspikes beim Schreiben auf die Festplatte.

Hände weg von NFS & Co.!

Vermeide langsamen netzwerkbasierten Speicher wie NFS, GlusterFS oder Portworx. Die schwankenden Latenzen führen früher oder später fast immer zu Stabilitätsproblemen.

Nutze stattdessen: iSCSI-Volumes, schnellen Cloud-Block-Storage oder idealerweise lokalen SSD-Speicher.

Die Festplattengröße richtet sich simpel nach den zu erwartenden Datenmengen und dem Replication Factor.

  • Formel: Tägliches Ingest × Aufbewahrungszeit (Retention) × Replication Factor

  • Beispiel: Werden am Tag 10 GB produziert und sollen 7 Tage aufbewahrt werden, benötigen wir im Cluster insgesamt 210 GB Speicherplatz. Auf drei Broker aufgeteilt bedeutet, dass jeder Broker mindestens 70 GB Speicherplatz benötigt.

RAM (Arbeitsspeicher)

Kafka Broker nutzen RAM auf zweierlei Art:

  1. JVM Heap: Für die Anwendung selbst.

  2. Page Cache: Als Pufferspeicher auf Betriebssystemebene.

Die Broker benötigen selbst in sehr großen Clustern selten mehr als 6 GB Heap (konfiguriert über -Xmx und -Xms). Üblicherweise wird der RAM 50/50% auf den Heap und den Page Cache aufgeteilt bis die 6 GB Heap erreicht sind. Der gesamte restliche RAM wird vom Betriebssystem automatisch als Page Cache für schnellere Schreib- und vor allem Lesevorgänge benutzt. Je mehr Page Cache zur Verfügung steht, desto mehr Anfragen kann Kafka direkt aus dem RAM beantworten, ohne auf die Festplatte zugreifen zu müssen.

CPU & Verhältnis

Für ganz kleine Cluster reicht es oft, mit 1 GB RAM und 512 MB Heap sowie 1 CPU-Core zu starten.

Um ein Gefühl für das richtige Verhältnis zwischen RAM und CPU zu bekommen, lohnt sich ein Blick auf die Memory Optimized Instances von AWS. Eine gute Faustregel ist hier:

RAM in GB = vCPU * 8

Das entspricht zum Beispiel 16 GB RAM bei 2 vCPUs.

Netzwerk

Beim Netzwerk gilt meistens: Nimm, was du kriegen kannst. Kafka profitiert von hoher Bandbreite. Wenn 10 oder sogar 25 Gbit verfügbar sind, nimm sie gerne mit. Achte in Cloud-Umgebungen darauf, dass die Netzwerkbandbreite oft an die Instanzgröße gekoppelt ist – manchmal muss man die Instanz vergrößern, nur um mehr Durchsatz zu erhalten.

Skalierung

Wenn die Last steigt, stellt sich die Frage: Horizontal (mehr Broker) oder vertikal (dickere Server) skalieren?

Vertikale Skalierung ist operativ üblicherweise einfacher, hat aber einen Nachteil: Wenn einer von drei Brokern ausfällt, müssen die verbleibenden zwei plötzlich 50% mehr Last übernehmen (bei Replication Factor 3). Je größer die einzelnen Broker sind, desto härter trifft uns der Ausfall eines Brokers.

Unsere Empfehlung:

Startet mit drei Brokern. Skaliert diese vertikal bis zu 64 GB RAM (und entsprechenden CPUs). Danach würden wir die Anzahl der Broker langsam erhöhen, vielleicht bis etwa 6 Broker.

Spätestens dann sollte man einen sehr genauen Blick auf die Metriken werfen, um den echten Flaschenhals zu finden. Ist es wirklich die CPU? Oder doch das Netzwerk oder Disk-IO? Anhand dieser Analyse entscheidet man, ob mehr Broker oder stärkere Ressourcen sinnvoller sind.

Wichtig: Rebalancing

Beim Hinzufügen von neuen Brokern passiert erstmal nichts. Die Last wird nicht automatisch umverteilt. Das ist der Job von Tools wie Cruise Control, die Partitionen intelligent auf die neuen Knoten verschieben.

Über Anatoly Zelenin
Hallo, ich bin Anatoly! Ich liebe es, bei Menschen das Funkeln in den Augen zu wecken. Als Apache Kafka Experte und Buchautor bringe ich seit über einem Jahrzehnt IT zum Leben - mit Leidenschaft statt Langeweile, mit Erlebnissen statt endlosen Folien.

Weiterlesen

article-image
author Von Anatoly Zelenin
Debezium: Change Data Capture für Apache Kafka

In diesem Post zeigen wir euch, wie ihr mithilfe von Debezium Daten aus verschiedenen Datenbanken zuverlässig und nahezu in Echtzeit nach Kafka importieren könnt. Debezium ist ein Kafka Connect-Plugin, das sich an das interne Log jeder Datenbank anschließen kann, um Änderungen zu erfassen und in Kafka zu schreiben.

Mehr lesen
article-image
author Von Anatoly Zelenin
Daten in einer Microservice-Welt

Von Start-up bis Konzern – immer mehr Unternehmen setzen auf Microservice-Architekturen. In der zweiten Lektion der vierteiligen Blogreihe erfährst du, wie Unternehmen mithilfe von Apache Kafka die Kommunikation zwischen ihren Services vereinfachen.

Mehr lesen
logo

Wir glauben an eine Welt, in der Unternehmen durch Echtzeitdaten intelligenter entscheiden, nachhaltiger handeln und ihre digitale Zukunft aktiv gestalten.

Copyright 2026, Alle Rechte vorbehalten

Kontakt

Adresse

Commit to Flow GmbH
Wiener Platz 11
01069 Dresden

E-Mail Adresse

kontakt@dataflow.academy

Links