Fünf Fallstricke bei der Skalierbarkeit, die Sie bei Ihrer Kafka-Anwendung vermeiden sollten

Apache Kafka ist eine leistungsstarke und hoch skalierbare Event-Streaming-Plattform. Um das volle Potenzial von Kafka auszuschöpfen, ist es erforderlich, das Design Ihrer Anwendung sorgfältig zu planen. Es kann leicht vorkommen, dass Kafka-Anwendungen entwickelt werden, die eine unzureichende Leistung aufweisen oder letztendlich an ihre Skalierbarkeitsgrenzen stoßen. Seit 2015 bietet IBM den IBM Event Streams-Service an, einen vollständig verwalteten Apache Kafka-Service, der auf IBM Cloud ausgeführt wird. Seitdem hat der Service vielen Kunden sowie Teams innerhalb von IBM dabei geholfen, Skalierbarkeits- und Leistungsprobleme mit den von ihnen geschriebenen Kafka-Anwendungen zu lösen.

Dieser Artikel beschreibt einige der häufigsten Probleme von Apache Kafka und enthält Empfehlungen, wie Sie Skalierbarkeitsprobleme bei Ihren Anwendungen vermeiden können.

1. Minimierung der Wartezeiten für Netzwerk-Roundtrips

Bestimmte Kafka-Operationen funktionieren so, dass der Client Daten an den Broker sendet und auf eine Antwort wartet. Ein kompletter Roundtrip kann 10 Millisekunden dauern. Das klingt zwar schnell, beschränkt Sie jedoch auf maximal 100 Operationen pro Sekunde. Daher wird empfohlen, solche Operationen nach Möglichkeit zu vermeiden. Glücklicherweise bieten Kafka-Clients Möglichkeiten, diese Roundtrip-Zeiten zu umgehen. Sie müssen lediglich sicherstellen, dass Sie diese Vorteile nutzen.

Tipps zur Maximierung des Durchsatzes:

1. Überprüfen Sie nicht jede gesendete Nachricht, ob sie erfolgreich zugestellt wurde. Die API von Kafka ermöglicht es Ihnen, das Senden einer Nachricht von der Überprüfung, ob die Nachricht erfolgreich vom Broker empfangen wurde, zu entkoppeln. Das Warten auf die Empfangsbestätigung einer Nachricht kann zu einer Latenzzeit beim Netzwerk-Roundtrip in Ihrer Anwendung führen. Versuchen Sie daher, diese nach Möglichkeit zu minimieren. Das könnte bedeuten, dass Sie so viele Nachrichten wie möglich senden, bevor Sie überprüfen, ob sie alle empfangen wurden. Oder es könnte bedeuten, dass Sie die Überprüfung der erfolgreichen Nachrichtenzustellung an einen anderen Ausführungs-Thread innerhalb Ihrer Anwendung delegieren, damit dieser parallel zum Senden weiterer Nachrichten ausgeführt werden kann.
2. Verfolgen Sie die Verarbeitung jeder Nachricht nicht mit einem Offset-Commit. Das (synchrone) Festlegen von Offsets wird als Netzwerk-Roundtrip mit dem Server implementiert. Entweder führen Sie Offsets weniger häufig durch oder Sie verwenden die asynchrone Offset-Commit-Funktion, um zu vermeiden, dass Sie für jede verarbeitete Nachricht die Kosten für diesen Roundtrip tragen müssen. Beachten Sie jedoch, dass weniger häufige Offset-Commits dazu führen können, dass bei einem Ausfall Ihrer Anwendung mehr Daten erneut verarbeitet werden müssen.

Wenn Sie das oben Genannte gelesen haben und sich gefragt haben: „Oh je, wird das meine Anwendung nicht komplexer machen?“, lautet die Antwort: Ja, das wird es wahrscheinlich. Es besteht ein Kompromiss zwischen Durchsatz und Komplexität der Anwendung. Was die Netzwerk-Roundtrip-Zeit zu einer besonders heimtückischen Herausforderung macht, ist die Tatsache, dass nach Erreichen dieser Grenze umfangreiche Anwendungsänderungen erforderlich sein können, um weitere Durchsatzverbesserungen zu erzielen.

2. Längere Bearbeitungszeiten nicht mit Versäumnissen der Verbraucher verwechseln

Eine nützliche Funktion von Kafka ist, dass es die „Lebendigkeit” der konsumierenden Anwendungen überwacht und alle Anwendungen trennt, die möglicherweise ausgefallen sind. Das funktioniert, indem der Broker verfolgt, wann jeder konsumierende Client zuletzt „poll“ aufgerufen hat (Kafkas Begriff für die Anforderung weiterer Nachrichten). Wenn ein Client nicht häufig genug abfragt, geht der Broker, mit dem er verbunden ist, davon aus, dass ein Fehler aufgetreten ist, und trennt die Verbindung. Auf diese Weise können Clients, bei denen keine Probleme auftreten, einspringen und die Arbeit des ausgefallenen Clients übernehmen.

Leider kann der Kafka-Broker bei diesem Schema nicht zwischen einem Client, der für die Verarbeitung der empfangenen Nachrichten viel Zeit benötigt, und einem Client, der tatsächlich ausgefallen ist, unterscheiden. Stellen Sie sich eine konsumierende Anwendung vor, die in einer Schleife 1) einen Abfrage aufruft und einen Stapel von Nachrichten zurückerhält oder 2) jede Nachricht im Stapel verarbeitet, wobei die Verarbeitung jeder Nachricht 1 Sekunde dauert.

Wenn dieser Verbraucher Pakete von 10 Nachrichten empfängt, dann beträgt der Abstand zwischen den Abfrageaufrufen ungefähr 10 Sekunden. Standardmäßig erlaubt Kafka eine Zeitspanne von bis zu 300 Sekunden (5 Minuten) zwischen den Abfragen, bevor die Verbindung zum Client getrennt wird, sodass in diesem Szenario alles reibungslos funktionieren würde. Aber was passiert an einem besonders arbeitsreichen Tag, wenn sich Nachrichten zu dem Thema, das die Anwendung verarbeitet, ansammeln? Anstatt nur 10 Nachrichten von jedem Poll-Aufruf zurückzuerhalten, erhält Ihre Anwendung 500 Nachrichten (dies ist standardmäßig die maximale Anzahl von Datensätzen, die durch einen Poll-Aufruf zurückgegeben werden können). Das würde zu einer ausreichenden Verarbeitungszeit für Kafka führen, um zu entscheiden, dass die Anwendungsinstanz ausgefallen ist, und die Verbindung zu trennen. Das sind schlechte Nachrichten.

Es wird Sie freuen zu erfahren, dass es noch schlimmer kommen kann. Es ist möglich, dass eine Art Rückkopplungsschleife entsteht. Da Kafka beginnt, Clients zu trennen, weil sie nicht häufig genug abfragen, gibt es weniger Instanzen der Anwendung, die Nachrichten verarbeiten können. Die Wahrscheinlichkeit, dass es zu einem erheblichen Rückstau an Nachrichten zu diesem Thema kommt, steigt. Dadurch steigt auch die Wahrscheinlichkeit, dass mehr Kunden große Mengen an Nachrichten erhalten und zu lange benötigen, um diese zu verarbeiten. Schließlich geraten alle Instanzen der konsumierenden Anwendung in eine Neustartschleife, und es wird keine nützliche Arbeit mehr verrichtet.

Welche Maßnahmen können Sie dagegen ergreifen?

1. Die maximale Zeitspanne zwischen Abfragen kann mithilfe der Kafka-Consumer-Konfiguration „max.poll.interval.ms“ konfiguriert werden. Die maximale Anzahl von Nachrichten, die bei einer einzelnen Abfrage zurückgegeben werden können, ist ebenfalls über die Konfiguration „max.poll.records“ konfigurierbar. Als Faustregel gilt: Reduzieren Sie den Wert „max.poll.records“ in den Einstellungen, um „max.poll.interval.ms“ zu erhöhen, da Kafka bei einem großen maximalen Abfrageintervall länger braucht, um Verbraucher zu identifizieren, die tatsächlich ausgefallen sind.
2. Kafka- Nutzer können auch angewiesen werden, den Nachrichtenfluss anzuhalten und wieder aufzunehmen. Durch das Anhalten des Konsums wird verhindert, dass die Poll-Methode Nachrichten zurückgibt, aber der Timer, mit dem festgestellt wird, ob der Client ausgefallen ist, wird dennoch zurückgesetzt. Das Anhalten und Wiederaufnehmen ist eine nützliche Taktik, wenn Sie sowohl a) erwarten, dass die Verarbeitung einzelner Nachrichten möglicherweise viel Zeit in Anspruch nimmt, als auch b) möchten, dass Kafka einen Client-Ausfall während der Verarbeitung einer einzelnen Nachricht erkennen kann.
3. Ignorieren Sie nicht die Nützlichkeit der Kafka-Client-Metriken. Das Thema Metriken könnte einen ganzen Artikel füllen, aber in diesem Zusammenhang stellt der Verbraucher Metriken sowohl für die durchschnittliche als auch für die maximale Zeit zwischen Abfragen bereit. Die Überwachung dieser Metriken kann dabei helfen, Situationen zu identifizieren, in denen ein nachgeschaltetes System der Grund dafür ist, dass die Verarbeitung jeder von Kafka empfangenen Nachricht länger als erwartet dauert.

Wir werden später in diesem Artikel auf das Thema Verbraucherausfälle zurückkommen, wenn wir uns damit befassen, wie sie eine Neugewichtung der Verbrauchergruppen auslösen können und welche disruptiven Auswirkungen dies haben kann.

3. Minimierung der Kosten für inaktive Verbraucher

Unter der Oberfläche funktioniert das vom Kafka-Consumer zum Empfangen von Nachrichten verwendete Protokoll, indem es eine „Fetch“-Anfrage an einen Kafka-Broker sendet. Als Teil dieser Anfrage gibt der Client an, was der Broker tun soll, wenn keine Nachrichten zurückgegeben werden können, einschließlich der Wartezeit, bevor der Broker eine leere Antwort sendet. Standardmäßig weisen Kafka-Konsumenten die Broker an, bis zu 500 Millisekunden (gesteuert durch die Konsumentenkonfiguration „fetch.max.wait.ms“) zu warten, bis mindestens 1 Byte an Nachrichtendaten verfügbar ist (gesteuert durch die Konfiguration „fetch.min.bytes“).

Eine Wartezeit von 500 Millisekunden erscheint zunächst nicht unangemessen. Wenn Ihre Anwendung jedoch Nutzer hat, die größtenteils inaktiv sind, und auf beispielsweise 5.000 Instanzen skaliert wird, bedeutet dies potenziell 2.500 Anfragen pro Sekunde, die keine Aktion ausführen. Jede dieser Anfragen beansprucht CPU-Zeit auf dem Broker für die Verarbeitung und kann im Extremfall die Leistung und Stabilität der Kafka-Clients beeinträchtigen, die nützliche Aufgaben ausführen sollen.

In der Regel besteht Kafkas Ansatz zur Skalierung darin, weitere Broker hinzuzufügen und anschließend die Topic-Partitionen gleichmäßig auf alle Broker, sowohl alte als auch neue, neu zu verteilen. Leider ist dieser Ansatz möglicherweise nicht zielführend, wenn Ihre Clients Kafka mit unnötigen Abrufanfragen überlasten. Jeder Client sendet Abrufanfragen an jeden Broker, der eine Themenpartition verursacht, aus der der Client Nachrichten abruft. Daher ist es möglich, dass selbst nach der Skalierung des Kafka-Clusters und der Neuverteilung der Partitionen die meisten Ihrer Clients weiterhin Abrufanfragen an die meisten Broker senden.

Also, was können Sie tun?

1. Eine Änderung der Kafka-Consumer-Konfiguration kann diesen Effekt verringern. Wenn Sie Nachrichten sofort nach ihrem Eintreffen empfangen möchten, sollte der Wert „fetch.min.bytes” auf der Standardeinstellung 1 belassen werden. Die Einstellung „fetch.max.wait.ms” kann jedoch auf einen höheren Wert erhöht werden, wodurch die Anzahl der Anfragen von inaktiven Verbrauchern reduziert wird.
2. Im weiteren Sinne: Muss Ihre Anwendung möglicherweise Tausende von Instanzen haben, von denen jede nur sehr selten Daten aus Kafka abruft? Dafür kann es sehr gute Gründe geben, aber möglicherweise gibt es auch Möglichkeiten, die Anwendung so zu gestalten, dass Kafka effizienter genutzt wird. Auf einige dieser Überlegungen werden wir im nächsten Abschnitt eingehen.

4. Wählen Sie eine angemessene Anzahl von Themen und Partitionen

Wenn Sie bereits Erfahrung mit anderen Publish-Subscribe-Systemen haben (z. B. Message Queuing Telemetry Transport, kurz MQTT), könnten Sie erwarten, dass Kafka-Themen sehr leichtgewichtig und nahezu kurzlebig sind. Das ist jedoch nicht der Fall. Kafka ist mit einer Vielzahl von Themen, die in Tausenden gemessen werden, wesentlich besser vertraut. Es wird auch erwartet, dass Kafka-Themen relativ langlebig sind. Praktiken wie das Erstellen eines Themas, um eine einzelne Antwortnachricht zu empfangen, und das anschließende Löschen des Themas sind bei Kafka unüblich und spielen die Stärken von Kafka nicht aus.

Planen Sie stattdessen Themen mit einer langen Lebensdauer. Möglicherweise teilen sie sich die Lebensdauer einer Anwendung oder einer Aktivität. Versuchen Sie auch, die Anzahl der Themen auf Hunderte oder vielleicht wenige Tausend zu begrenzen. Dies erfordert möglicherweise eine andere Sichtweise darauf, welche Nachrichten zu einem bestimmten Thema verschachtelt sind.

Eine häufig gestellte Frage lautet: „Wie viele Partitionen sollte mein Thema haben?“ Traditionell wird empfohlen, die Anzahl eher hoch anzusetzen, da das Hinzufügen von Partitionen nach der Erstellung eines Themas die Partitionierung der vorhandenen Daten in diesem Thema nicht verändert (und somit Auswirkungen auf Verbraucher haben kann, die auf die Partitionierung angewiesen sind, um die Reihenfolge der Nachrichten innerhalb einer Partition zu gewährleisten). Dies ist ein guter Ratschlag. Dennoch möchten wir einige zusätzliche Überlegungen vorschlagen:

1. Für Themen, bei denen ein Durchsatz in MB/Sekunde zu erwarten ist oder bei denen der Durchsatz mit der Skalierung Ihrer Anwendung steigen könnte, empfehlen wir dringend, mehr als eine Partition zu verwenden, damit die Last auf mehrere Broker verteilt werden kann. Der Event Streams-Dienst führt Kafka stets mit einem Vielfachen von 3 Brokern aus. Zum Zeitpunkt der Erstellung dieses Artikels verfügt er über maximal 9 Broker, jedoch ist eine Erhöhung dieser Anzahl in der Zukunft möglich. Wenn Sie für die Anzahl der Partitionen in Ihrem Thema ein Vielfaches von 3 wählen, kann diese gleichmäßig auf alle Broker verteilt werden.
2. Die Anzahl der Partitionen in einem Thema stellt die Obergrenze dafür dar, wie viele Kafka-Konsumenten Nachrichten aus dem Thema sinnvoll mit Kafka-Konsumentengruppen teilen können (mehr dazu später). Wenn Sie einer Konsumentengruppe mehr Konsumenten hinzufügen, als es Partitionen im Thema gibt, bleiben einige Konsumenten inaktiv und konsumieren keine Nachrichtendaten.
3. Es ist grundsätzlich nichts gegen Themen mit einer einzigen Partition einzuwenden, solange Sie absolut sicher sind, dass diese niemals einen erheblichen Nachrichtenverkehr erhalten werden, oder Sie nicht auf die Reihenfolge innerhalb eines Themas angewiesen sind und bereit sind, später weitere Partitionen hinzuzufügen.

5. Die Neugewichtung von Verbrauchergruppen kann überraschend disruptive Auswirkungen haben.

Die meisten Kafka-Anwendungen, die Nachrichten verarbeiten, nutzen die Funktionen der Kafka-Verbrauchergruppen, um zu koordinieren, welche Clients welche Themenpartitionen verarbeiten. Sollten Ihre Erinnerungen an Verbrauchergruppen etwas unklar sein, finden Sie hier eine kurze Zusammenfassung der wichtigsten Punkte:

• Verbrauchergruppen koordinieren eine Gruppe von Kafka-Clients so, dass zu jedem Zeitpunkt nur ein Client Nachrichten von einer bestimmten Themenpartition empfängt. Das ist nützlich, wenn Sie die Nachrichten zu einem Thema auf mehrere Instanzen einer Anwendung verteilen müssen.
• Wenn ein Kafka-Client einer Verbrauchergruppe beitritt oder eine Verbrauchergruppe verlässt, der er zuvor beigetreten war, wird die Verbrauchergruppe neu ausbalanciert. In der Regel treten Clients einer Verbrauchergruppe bei, wenn die Anwendung, zu der sie gehören, gestartet wird, und verlassen sie, wenn die Anwendung heruntergefahren, neu gestartet oder abgestürzt wird.
• Wenn eine Gruppe neu ausbalanciert wird, werden die Themenpartitionen unter den Mitgliedern der Gruppe neu verteilt. Wenn beispielsweise ein Client einer Gruppe beitritt, können einigen Clients, die bereits in der Gruppe sind, Themenpartitionen entzogen werden (oder in der Terminologie von Kafka „widerrufen“ werden), um sie dem neu beitretenden Client zuzuweisen. Das Gegenteil trifft ebenfalls zu: Wenn ein Client eine Gruppe verlässt, werden die ihm zugewiesenen Themenpartitionen unter den verbleibenden Mitgliedern neu verteilt.

Mit der Entwicklung von Kafka wurden (und werden weiterhin) immer ausgefeiltere Algorithmen zur Neugewichtung entwickelt. In früheren Versionen von Kafka mussten bei einer Neugewichtung einer Verbrauchergruppe alle Clients in der Gruppe den Verbrauch einstellen, die Themenpartitionen wurden unter den neuen Mitgliedern der Gruppe neu verteilt und alle Clients nahmen den Verbrauch wieder auf. Dieser Ansatz hat zwei Nachteile (keine Sorge, diese wurden inzwischen verbessert):

1. Während der Neugewichtung stellen alle Clients in der Gruppe den Empfang von Nachrichten ein. Das hat offensichtliche Auswirkungen auf den Durchsatz.
2. Kafka-Kunden versuchen in der Regel, einen Puffer mit Nachrichten zu verwalten, die noch nicht an die Anwendung übermittelt wurden, und weitere Nachrichten vom Broker abzurufen, bevor der Puffer leer ist. Damit soll verhindert werden, dass die Übermittlung von Nachrichten an die Anwendung ins Stocken gerät, während weitere Nachrichten vom Kafka-Broker abgerufen werden (ja, wie bereits weiter oben in diesem Artikel erwähnt, versucht der Kafka-Client auch, Wartezeiten bei Netzwerk-Roundtrips zu vermeiden). Leider müssen bei einer Neugewichtung, die dazu führt, dass Partitionen von einem Client widerrufen werden, alle gepufferten Daten für die Partition verworfen werden. Ebenso beginnt der Client, wenn bei einer Neugewichtung eine neue Partition einem Client zugewiesen wird, mit dem Puffern von Daten ab dem letzten festgeschriebenen Offset für die Partition, was möglicherweise zu einem Anstieg des Netzwerkdurchsatzes vom Broker zum Client führt. Das liegt daran, dass der Client, dem die Partition neu zugewiesen wurde, die Nachrichtendaten erneut liest, die zuvor von dem Client zwischengespeichert wurden, dem die Partition entzogen wurde.

Neuere Rebalancing-Algorithmen haben erhebliche Verbesserungen erzielt, indem sie, um Kafkas Terminologie zu verwenden, „Stickiness“ und „Cooperation“ hinzugefügt haben:

• „Sticky“-Algorithmen versuchen sicherzustellen, dass nach einer Neugewichtung möglichst viele Gruppenmitglieder dieselben Partitionen behalten, die sie vor der Neugewichtung hatten. Dadurch wird die Menge der gepufferten Nachrichtendaten minimiert, die bei der Neugewichtung verworfen oder erneut aus Kafka gelesen werden.
• „Kooperative“ Algorithmen ermöglichen es Klienten, weiterhin Nachrichten zu empfangen, während eine Neugewichtung stattfindet. Wenn einem Client vor einer Neugewichtung eine Partition zugewiesen wurde und er diese Partition nach der Neugewichtung behält, kann er weiterhin Nachrichten aus Partitionen verarbeiten, die von der Neugewichtung nicht betroffen sind. Dies wirkt synergistisch mit der „Stickiness“, die dafür sorgt, dass Partitionen demselben Client zugewiesen bleiben.

Trotz dieser Verbesserungen an neueren Rebalancing-Algorithmen werden Sie, wenn Ihre Anwendungen häufig von Rebalancing-Vorgängen der Verbrauchergruppe betroffen sind, weiterhin Auswirkungen auf den gesamten Messaging-Durchsatz feststellen und Netzwerkbandbreite verschwenden, da Clients gepufferte Nachrichtendaten verwerfen und erneut abrufen. Hier sind einige Lösungsvorschläge:

1. Stellen Sie sicher, dass Sie erkennen können, wann ein Rebalancing stattfindet. In großem Maßstab ist das Sammeln und Visualisieren von Metriken die beste Option. In dieser Situation hilft eine Vielzahl von Metrikquellen dabei, ein vollständiges Bild zu erstellen. Der Kafka-Broker verfügt über Metriken sowohl für die Anzahl der an Clients gesendeten Datenbytes als auch für die Anzahl der neu ausbalancierten Verbrauchergruppen. Wenn Sie Metriken aus Ihrer Anwendung oder deren Laufzeit sammeln, die zeigen, wann Neustarts auftreten, kann die Korrelation dieser Daten mit den Broker-Metriken eine weitere Bestätigung dafür liefern, dass das Rebalancing für Sie ein Problem darstellt.
2. Vermeiden Sie unnötige Neustarts von Anwendungen, beispielsweise wenn eine Anwendung abstürzt. Sollten Sie Stabilitätsprobleme mit Ihrer Anwendung feststellen, kann dies zu einer wesentlich häufigeren Neugewichtung als erwartet verursachen. Die Suche in Anwendungsprotokollen nach häufigen Fehlermeldungen, die bei einem Anwendungsabsturz ausgegeben werden, beispielsweise Stacktraces, kann dabei helfen, die Häufigkeit des Auftretens von Problemen zu ermitteln und Informationen zu liefern, die beim Debugging des zugrunde liegenden Problems nützlich sind.
3. Verwenden Sie den optimalen Rebalancing-Algorithmus für Ihre Anwendung? Zum Zeitpunkt der Erstellung dieses Artikels ist der Goldstandard der „CooperativeStickyAssignor“. Standardmäßig wird jedoch (ab Kafka 3.0) der „RangeAssignor“ (und ein früherer Zuweisungsalgorithmus) gegenüber dem kooperativen Sticky Assignor bevorzugt. Die Kafka-Dokumentation beschreibt die erforderlichen Migrationsschritte, damit Ihre Clients den Cooperative Sticky Assignor übernehmen können. Es ist auch erwähnenswert, dass der kooperative Sticky Assignor zwar eine gute Allround-Wahl ist, es jedoch auch andere Assignoren gibt, die auf bestimmte Anwendungsfälle zugeschnitten sind.
4. Sind die Mitglieder einer Verbrauchergruppe festgelegt? Beispielsweise könnten Sie stets vier hochverfügbare und unterschiedliche Instanzen einer Anwendung ausführen. Möglicherweise können Sie die Funktion für statische Gruppenmitgliedschaften von Kafka nutzen. Durch die Zuweisung eindeutiger IDs zu jeder Instanz Ihrer Anwendung können Sie mit der statischen Gruppenmitgliedschaft das Rebalancing vollständig umgehen.
5. Übernehmen Sie den aktuellen Offset, wenn eine Partition aus Ihrer Anwendungsinstanz widerrufen wird. Der Consumer-Client von Kafka stellt einen Listener für Rebalance-Ereignisse bereit. Wenn einer Instanz Ihrer Anwendung eine Partition entzogen werden soll, bietet der Listener die Möglichkeit, einen Offset für die Partition festzulegen, die entfernt werden soll. Der Vorteil einer Offset-Festlegung zum Zeitpunkt der Aufhebung der Partition besteht darin, dass sichergestellt wird, dass das Gruppenmitglied, dem die Partition zugewiesen ist, an diesem Punkt weitermacht, anstatt möglicherweise einige der Nachrichten aus der Partition erneut zu verarbeiten.

Sie sind nun ein Experte für die Skalierung von Kafka-Anwendungen. Wir laden Sie ein, diese Punkte in die Praxis umzusetzen und das vollständig verwaltete Kafka-Angebot auf IBM Cloud zu testen. Bei Schwierigkeiten bei der Einrichtung konsultieren Sie bitte den Leitfaden zum Einstieg und die FAQs.