Instaclustr
28.12.2023, 09:04 Uhr
Apache Kafka: Vier Anti-Patterns und wie man sie verhindert
Der Message Broker Apache Kafka verteilt Schlüssel-Wert-Nachrichten zwischen Anwendungen oder Microservices. Managed-Platform-Anbieter Instaclustr nennt verbreitete Anti-Patterns beim Betrieb von Apache Kafka und wie Entwickler sie verhindern.
(Quelle: apache.org)
Im Herzen von Apache Kafka – dem Kafka-Cluster – arbeiten sogenannte Broker, die die Nachrichten mit Zeitstempel in Topics speichern, zusammenfassen und von denen es immer mehrere Repliken gibt. Diese Verteilung sorgt für Ausfallsicherheit und Skalierbarkeit. Die Topics sind ihrerseits in einzelne Partitionen aufgeteilt. Anwendungen und Microservices, die einen Kafka-Cluster mit Daten füllen, werden Producer genannt, die Empfänger dieser Daten sind die Consumer. Durch die vielen individuell konfigurierbaren Bestandteile von Kafka, ergeben sich auch oft unsinnige Anti-Patterns. Instaclustr nennt vier Beispiele und erklärt, wie Entwickler sie vermeiden.
Viel oder wenig #1: Topics
Erfahrungen haben gezeigt, dass es sich negativ auf die Performance der Skalierbarkeit von Apache Kafka auswirkt, wenn Entwickler zu viele Topics auf ihren Kafka-Clustern erstellen. Topics bestehen aus Partitionen, die quasi die Grundeinheit für die Gleichzeitigkeit in Kafka darstellen: Je mehr Partitionen ein Topic hat, desto mehr Consumer kann es versorgen und desto höher ist der Datendurchsatz. Die klare Empfehlung lautet also, statt 1.000 Topics mit 1.000 Partitionen zu erstellen, lieber die Anzahl der Topics reduzieren und die Partitionen auf sie aufzuteilen.
Erfahrungen haben gezeigt, dass es sich negativ auf die Performance der Skalierbarkeit von Apache Kafka auswirkt, wenn Entwickler zu viele Topics auf ihren Kafka-Clustern erstellen. Topics bestehen aus Partitionen, die quasi die Grundeinheit für die Gleichzeitigkeit in Kafka darstellen: Je mehr Partitionen ein Topic hat, desto mehr Consumer kann es versorgen und desto höher ist der Datendurchsatz. Die klare Empfehlung lautet also, statt 1.000 Topics mit 1.000 Partitionen zu erstellen, lieber die Anzahl der Topics reduzieren und die Partitionen auf sie aufzuteilen.
Viel oder wenig #2: Partitionen
Die Reduktion von Topics und der damit einhergehende Anstieg von Partitionen auf ihnen verbessert den Datendurchsatz. Dieses Vorgehen lässt sich allerdings nicht unendlich weit treiben und hängt sehr von der Menge an Partitionen und den entsprechend zu vermittelnden Schlüssel-Wert-Nachrichten ab: Erstellen Entwickler 1.000 Partitionen in 1.000 Topics ist das nicht sehr performant. Aber 10.000 Partitionen auf ein Topic zu schieben, ist ebenso wenig sinnvoll. Ein detailliertes Benchmarking hat ergeben, dass der sogenannte Sweetspot typischerweise zwischen 10 und 100 Partitionen pro Topic liegt, sofern Apache ZooKeeper verwendet wird. Ein Update für Apache Kafka brachte vor Kurzem den "KRaft Mode", der ZooKeeper ersetzt und die Verarbeitung von Metadaten beschleunigt. Doch auch dann bricht der Durchsatz bei über 1.000 Topics und Partitionen deutlich ein. Die einzige Lösung sind größere Kafka-Cluster.
Die Reduktion von Topics und der damit einhergehende Anstieg von Partitionen auf ihnen verbessert den Datendurchsatz. Dieses Vorgehen lässt sich allerdings nicht unendlich weit treiben und hängt sehr von der Menge an Partitionen und den entsprechend zu vermittelnden Schlüssel-Wert-Nachrichten ab: Erstellen Entwickler 1.000 Partitionen in 1.000 Topics ist das nicht sehr performant. Aber 10.000 Partitionen auf ein Topic zu schieben, ist ebenso wenig sinnvoll. Ein detailliertes Benchmarking hat ergeben, dass der sogenannte Sweetspot typischerweise zwischen 10 und 100 Partitionen pro Topic liegt, sofern Apache ZooKeeper verwendet wird. Ein Update für Apache Kafka brachte vor Kurzem den "KRaft Mode", der ZooKeeper ersetzt und die Verarbeitung von Metadaten beschleunigt. Doch auch dann bricht der Durchsatz bei über 1.000 Topics und Partitionen deutlich ein. Die einzige Lösung sind größere Kafka-Cluster.
Viel oder wenig #3: Cluster
Die Frage nach der richtigen Anzahl an Kafka-Clustern hängt sehr davon ab, wie viele Broker zum Einsatz kommen sollen. Es gibt keine finite Anzahl an möglichen Brokern, aber im Sinne der Performance sollten es keinesfalls Millionen sein. Es gibt durchaus Anwendungsfälle, bei denen es sich lohnt etwa 100 Broker einzusetzen. Das sollte allerdings das absolute Maximum sein, da sonst Ausfälle und Downtimes oder Performance-Probleme auftreten. Um dieses Limit nicht auszureizen, setzen viele Entwickler darauf, Kafka-Cluster aufzusplitten.
Die Frage nach der richtigen Anzahl an Kafka-Clustern hängt sehr davon ab, wie viele Broker zum Einsatz kommen sollen. Es gibt keine finite Anzahl an möglichen Brokern, aber im Sinne der Performance sollten es keinesfalls Millionen sein. Es gibt durchaus Anwendungsfälle, bei denen es sich lohnt etwa 100 Broker einzusetzen. Das sollte allerdings das absolute Maximum sein, da sonst Ausfälle und Downtimes oder Performance-Probleme auftreten. Um dieses Limit nicht auszureizen, setzen viele Entwickler darauf, Kafka-Cluster aufzusplitten.
Viel oder wenig #4: Schlüsselwerte
Der große Vorteil von Apache Kafka ist, dass Schlüssel-Wert-Nachrichten in einer festen Reihenfolge verteilt werden. Das funktioniert allerdings nur innerhalb einer Partition: Nachrichten mit dem gleichen Schlüssel werden an die gleiche Partition geliefert, also in der richtigen Reihenfolge. Ist etwa die Kunden-ID der Schlüssel, sendet Apache Kafka alle Nachrichten, die sich auf diesen Kunden beziehen, an die gleiche Partition und stellt sie in der richtigen Reihenfolge zu. Es ist eine Kunst für sich, die richtige Anzahl an Schlüsselwerten zu erstellen, um Probleme wie ungleichmäßige Verteilung auf den Brokern zu vermeiden. Eine Faustregel, die sich durchgesetzt hat, ist, dass Entwickler rund zwanzig Mal mehr Schlüsselwerte benötigen, als es Partitionen und Consumer gibt. Das heißt bei einer Million Partitionen sollten es 20 Millionen Schlüsselwerte sein.
Der große Vorteil von Apache Kafka ist, dass Schlüssel-Wert-Nachrichten in einer festen Reihenfolge verteilt werden. Das funktioniert allerdings nur innerhalb einer Partition: Nachrichten mit dem gleichen Schlüssel werden an die gleiche Partition geliefert, also in der richtigen Reihenfolge. Ist etwa die Kunden-ID der Schlüssel, sendet Apache Kafka alle Nachrichten, die sich auf diesen Kunden beziehen, an die gleiche Partition und stellt sie in der richtigen Reihenfolge zu. Es ist eine Kunst für sich, die richtige Anzahl an Schlüsselwerten zu erstellen, um Probleme wie ungleichmäßige Verteilung auf den Brokern zu vermeiden. Eine Faustregel, die sich durchgesetzt hat, ist, dass Entwickler rund zwanzig Mal mehr Schlüsselwerte benötigen, als es Partitionen und Consumer gibt. Das heißt bei einer Million Partitionen sollten es 20 Millionen Schlüsselwerte sein.
"Message Broker wie Apache Kafka führen ihre Aufgaben grundsätzlich auch ohne Feintuning zuverlässig aus", erklärt Merlin Walter, Staff Sales Engineer EMEA bei Instaclustr. "Das ist allerdings ein zweischneidiges Schwert, denn was im Kleinen reibungslos funktioniert kann bei entsprechender Skalierung zu einem massiven Leistungseinbruch führen. In der Regel müssen Entwickler immer abwägen, wie viel sie ihren Kafka-Clustern und den auf ihnen laufenden Brokern zumuten können."
