Beherrschen Sie die Multi-Cluster-Bereitstellung und -Replikation mit Kafka

Kurzer Überblick über Apache Kafka und häufige Anwendungsfälle, aktuelle Tools zur Skalierung von Multi-Cluster-Bereitstellungen und Konnektivitätslösungen zur Vereinfachung von Multi-Cluster-Bereitstellungen.

Inhaltsverzeichnis

• Was ist Kafka?

• Kafka und Kubernetes

• Der Fall für Multi-Cluster-Kafka

• Multi-Cluster-Kafka

  • Ausgedehnte Cluster – Synchrone Replikation
  • Verbundene Cluster – Asynchrone Replikation

• Abschluss

  
  

Was ist Kafka?

Apache Kafka, allgemein einfach als Kafka bekannt, ist eine Open-Source-Event-Streaming-Plattform, die von der Apache Software Foundation verwaltet wird. Ursprünglich bei LinkedIn konzipiert, wurde Apache Kafka gemeinsam von Jay Kreps , Neha Narkhede und Jun Rao erstellt und anschließend 2011 als Open-Source-Projekt veröffentlicht . Wiki-Seite

Heute ist Kafka eine der beliebtesten Event-Streaming-Plattformen, die für die Verarbeitung von Echtzeit-Datenfeeds entwickelt wurde. Es wird häufig zum Aufbau skalierbarer, fehlertoleranter und leistungsstarker Streaming-Datenpipelines verwendet.

Die Verwendungsmöglichkeiten von Kafka werden ständig erweitert, wobei die fünf häufigsten Fälle von Brij Pandey im nebenstehenden Bild schön illustriert werden.

Als kurze Einführung ist es wichtig, die Komponenten der Kafka-Plattform und ihre Funktionsweise zu verstehen.

Kafka fungiert als verteilte Event-Streaming-Plattform, die für die effiziente Verarbeitung von Echtzeit-Datenfeeds konzipiert ist. Es basiert auf dem Publish-Subscribe-Messaging-Modell und folgt einer verteilten und fehlertoleranten Architektur. Es verwaltet eine persistente, geordnete und partitionierte Folge von Datensätzen, die als „Themen“ bezeichnet werden. Produzenten schreiben Daten zu diesen Themen und Konsumenten lesen daraus. Dies ermöglicht die Entkopplung zwischen Datenproduzenten und -konsumenten und ermöglicht es mehreren Anwendungen, denselben Datenstrom unabhängig voneinander zu konsumieren.

Zu den Hauptbestandteilen von Kafka gehören:

1. Themen und Partitionen: Kafka organisiert Daten in Themen. Jedes Thema ist ein Datenstrom und die Daten innerhalb eines Themas sind in mehrere Partitionen aufgeteilt. Jede Partition ist eine geordnete, unveränderliche Folge von Datensätzen. Partitionen ermöglichen horizontale Skalierbarkeit und Parallelität, indem sie die Verteilung von Daten auf mehrere Kafka-Broker ermöglichen.

   
   

2. Produzenten : Produzenten sind Anwendungen, die Daten zu Kafka-Themen schreiben. Sie veröffentlichen Datensätze zu bestimmten Themen, die dann in den Partitionen des Themas gespeichert werden. Produzenten können Datensätze explizit an eine bestimmte Partition senden oder Kafka erlauben, die Partition mithilfe einer Partitionierungsstrategie zu bestimmen.

   
   

3. Verbraucher : Verbraucher sind Anwendungen, die Daten aus Kafka-Themen lesen. Sie abonnieren ein oder mehrere Themen und verbrauchen Datensätze aus den Partitionen, denen sie zugewiesen sind. Verbrauchergruppen werden zum Skalieren des Verbrauchs verwendet, und jede Partition innerhalb eines Themas kann nur von einem Verbraucher innerhalb einer Gruppe genutzt werden. Dadurch können mehrere Verbraucher parallel arbeiten, um die Daten aus verschiedenen Partitionen desselben Themas zu verarbeiten.

   
   

4. Broker : Kafka wird als Servercluster ausgeführt, und jeder Server wird als Broker bezeichnet. Broker sind für die Bearbeitung von Lese- und Schreibanfragen von Produzenten und Konsumenten sowie für die Verwaltung der Themenpartitionen verantwortlich. Ein Kafka-Cluster kann über mehrere Broker verfügen, um die Last zu verteilen und Fehlertoleranz sicherzustellen.

   
   

5. Partitionen/Replikation : Um Fehlertoleranz und Datenbeständigkeit zu erreichen, ermöglicht Kafka die Konfiguration der Replikation für Themenpartitionen. Jede Partition kann mehrere Replikate haben, wobei ein Replikat als Leader und die anderen als Follower bestimmt sind. Das Leader-Replikat verarbeitet alle Lese- und Schreibanforderungen für diese Partition, während Follower die Daten vom Leader replizieren, um synchron zu bleiben. Wenn ein Broker mit einer Leader-Replik ausfällt, wird einer der Follower automatisch zum neuen Leader, um einen kontinuierlichen Betrieb sicherzustellen.

   
   

6. Offset-Management : Kafka behält das Konzept der Offsets für jede Partition bei. Ein Offset stellt eine eindeutige Kennung für einen Datensatz innerhalb einer Partition dar. Verbraucher behalten den Überblick über ihren aktuellen Ausgleich und können so im Falle eines Fehlers oder einer Wiederaufbereitung den Konsum an der Stelle fortsetzen, an der sie aufgehört haben.

   
   

7. ZooKeeper : Obwohl ZooKeeper nicht Teil von Kafka selbst ist, wird er häufig zur Verwaltung der Metadaten und zur Koordinierung der Broker in einem Kafka-Cluster verwendet. Es hilft bei der Wahl von Führungskräften, bei Themen- und Partitionsinformationen sowie bei der Verwaltung der Koordinierung von Verbrauchergruppen. [Hinweis: Das Metadatenverwaltungstool Zookeeper wird bald zugunsten von Kafka Raft oder KRaft, einem Protokoll für intern verwaltete Metadaten, eingestellt.]

   
   

Insgesamt machen Kafkas Design und Architektur es zu einer hoch skalierbaren, fehlertoleranten und effizienten Plattform für die Verarbeitung großer Mengen an Echtzeit-Datenströmen. Es ist zu einer zentralen Komponente in vielen datengesteuerten Anwendungen und Dateninfrastrukturen geworden und erleichtert die Datenintegration, Ereignisverarbeitung und Stream-Analyse.

Eine typische Kafka-Architektur würde dann wie folgt aussehen:

Unter Kafka-Clustering versteht man die Praxis, mehrere Kafka-Broker gemeinsam als Gruppe zu betreiben, um einen Kafka-Cluster zu bilden. Clustering ist ein grundlegender Aspekt der Kafka-Architektur und bietet mehrere Vorteile, darunter Skalierbarkeit, Fehlertoleranz und hohe Verfügbarkeit. Ein Kafka-Cluster dient dazu, große Datenströme zu verarbeiten und sicherzustellen, dass das System auch bei Ausfällen betriebsbereit bleibt.

Im Cluster werden Kafka-Themen in mehrere Partitionen unterteilt, um Skalierbarkeit und Parallelität zu erreichen. Jede Partition ist eine linear geordnete, unveränderliche Folge von Datensätzen. Partitionen ermöglichen daher die Verteilung von Daten auf mehrere Broker im Cluster.

Es ist zu beachten, dass ein Kafka-Cluster mindestens aus 3 Kafka-Brokern besteht, die jeweils auf einem separaten Server (virtuell oder physisch) ausgeführt werden können. Die 3-Knoten-Anleitung soll dazu beitragen, ein Split-Brain-Szenario im Falle eines Brokerausfalls zu vermeiden.

Kafka und Kubernetes

Da immer mehr Unternehmen Kafka einführen, besteht auch ein zunehmendes Interesse an der Bereitstellung von Kafka auf Kubernetes.

Tatsächlich zeigt der jüngste Kubernetes in the Wild-Bericht 2023 von Dynatrace, dass über 40 % der großen Unternehmen ihre Open-Source-Messaging-Plattform innerhalb von Kubernetes betreiben – der Großteil davon ist Kafka.

Quelle .

Im selben Bericht wird auch die kühne Behauptung aufgestellt, dass „Kubernetes sich zum ‚Betriebssystem‘ der Cloud entwickelt.“

Daher ist es für Kafka-Administratoren unerlässlich, das Zusammenspiel zwischen Kafka und Kubernetes zu verstehen und zu wissen, wie sie diese entsprechend der Skalierung implementieren können.

Der Fall für Multi-Cluster-Kafka

Das Ausführen eines Kafka-Clusters in einem einzelnen Kubernetes-Cluster-Setup ist recht einfach und ermöglicht theoretisch die erforderliche Skalierbarkeit. In der Produktion kann das Bild allerdings etwas unscharf werden.

Wir sollten die Verwendung des Begriffs Cluster zwischen Kafka und Kubernetes unterscheiden. Eine Kubernetes-Bereitstellung verwendet den Begriff Cluster auch, um eine Gruppierung verbundener Knoten zu bezeichnen, die als Kubernetes-Cluster bezeichnet wird. Wenn die Kafka-Arbeitslast auf Kubernetes bereitgestellt wird, erhalten Sie am Ende einen Kafka-Cluster, der innerhalb eines Kubernetes-Clusters ausgeführt wird. Für unsere Diskussion relevanter ist jedoch, dass Sie möglicherweise auch über einen Kafka-Cluster verfügen, der sich über mehrere Kubernetes-Cluster erstreckt – aus Gründen der Ausfallsicherheit, Leistung und Datensouveränität usw.

Zunächst einmal ist Kafka nicht für Multi-Tenant-Setups konzipiert. Technisch gesehen versteht Kafka Konzepte wie Kubernetes-Namespaces oder Ressourcenisolation nicht. Innerhalb eines bestimmten Themas gibt es keinen einfachen Mechanismus, um Sicherheitszugriffsbeschränkungen zwischen mehreren Benutzergruppen durchzusetzen.

Darüber hinaus können unterschiedliche Workloads unterschiedliche Aktualisierungshäufigkeit und Skalierungsanforderungen haben, z. B. Batch-Anwendung vs. Echtzeit-Anwendung. Die Kombination der beiden Workloads in einem einzigen Cluster könnte negative Auswirkungen haben oder viel mehr Ressourcen verbrauchen als nötig.

Datensouveränität und die Einhaltung gesetzlicher Vorschriften können auch Einschränkungen bei der gemeinsamen Lokalisierung von Daten und Themen in einer bestimmten Region oder Anwendung mit sich bringen.

Ausfallsicherheit ist natürlich eine weitere starke treibende Kraft hinter der Notwendigkeit mehrerer Kafka-Cluster. Während Kafka-Cluster auf Fehlertoleranz von Themen ausgelegt sind, müssen wir dennoch mit einem katastrophalen Ausfall eines gesamten Clusters rechnen. In solchen Fällen ermöglicht die Notwendigkeit eines vollständig replizierten Clusters eine ordnungsgemäße Geschäftskontinuitätsplanung.

Für Unternehmen, die Workloads in die Cloud migrieren oder eine Hybrid-Cloud-Strategie verfolgen, möchten Sie möglicherweise mehrere Kafka-Cluster einrichten und im Laufe der Zeit eine geplante Workload-Migration durchführen, anstatt eine riskante vollständige Kafka-Migration durchzuführen.

Dies sind nur einige der Gründe, warum Unternehmen in der Praxis mehrere Kafka-Cluster erstellen müssen, die dennoch miteinander interagieren müssen.

Multi-Cluster-Kafka

Um mehrere miteinander verbundene Kafka-Cluster zu haben, müssen Schlüsselelemente von einem Cluster auf die anderen Cluster repliziert werden. Dazu gehören die Themen, Offsets und Metadaten. In Kafkas Worten wird diese Vervielfältigung als Spiegelung bezeichnet. Es sind zwei Ansätze für Multi-Cluster-Setups möglich. Gestreckte Cluster oder verbundene Cluster.

Ausgedehnte Cluster – Synchrone Replikation

Ein Stretched Cluster ist ein logischer Cluster, der über mehrere physische Cluster „ausgedehnt“ ist. Themen und Replikate sind über die physischen Cluster verteilt, aber da sie als logische Cluster dargestellt werden, sind sich die Anwendungen selbst dieser Vielfalt nicht bewusst.

Gestreckte Cluster weisen eine starke Konsistenz auf und sind einfacher zu verwalten und zu verwalten. Da Anwendungen nicht wissen, dass mehrere Cluster vorhanden sind, lassen sie sich einfacher auf ausgedehnten Clustern bereitstellen als auf verbundenen Clustern.

Der Nachteil von Stretched Clustern besteht darin, dass eine synchrone Verbindung zwischen den Clustern erforderlich ist. Sie sind nicht ideal für eine Hybrid-Cloud-Bereitstellung und erfordern ein Quorum von mindestens drei Clustern, um ein „Split-Brain“-Szenario zu vermeiden.

Verbundene Cluster – Asynchrone Replikation

Ein verbundener Cluster hingegen wird durch die Verbindung mehrerer unabhängiger Cluster bereitgestellt. Diese unabhängigen Cluster können in verschiedenen Regionen oder Cloud-Plattformen ausgeführt werden und werden individuell verwaltet.

Der Hauptvorteil des Connected-Cluster-Modells besteht darin, dass es bei einem Clusterausfall zu keinen Ausfallzeiten kommt, da die anderen Cluster unabhängig voneinander laufen. Jeder Cluster kann auch für seine spezifischen Ressourcen optimiert werden.

Der größte Nachteil verbundener Cluster besteht darin, dass sie auf einer asynchronen Verbindung zwischen den Clustern beruhen. Themen, die zwischen den Clustern repliziert werden, werden nicht beim Schreiben kopiert, sondern hängen von der letztendlichen Konsistenz ab. Dies kann zu einem möglichen Datenverlust während des asynchronen Spiegelungsprozesses führen.

Darüber hinaus müssen Anwendungen, die über verbundene Cluster hinweg arbeiten, geändert werden, um die mehreren Cluster zu berücksichtigen.

Bevor wir uns mit der Lösung dieses Rätsels befassen, werde ich kurz auf die gängigen Tools auf dem Markt eingehen, um die Kafka-Cluster-Konnektivität zu ermöglichen.

Open Source Kafka selbst wird mit einem Spiegelungstool namens Mirror Maker ausgeliefert.

Mirror Maker dupliziert Themen zwischen verschiedenen Clustern über einen integrierten Produzenten. Auf diese Weise werden Daten zwischen Clustern mit letztendlicher Konsistenz repliziert, ohne jedoch einzelne Prozesse zu unterbrechen.

Es ist wichtig zu beachten, dass das Konzept von Mirror Maker zwar einfach ist, die Einrichtung von Mirror Maker in großem Maßstab jedoch für IT-Organisationen eine ziemliche Herausforderung darstellen kann. Die Verwaltung von IP-Adressen, Namenskonventionen, Anzahl der Replikate usw. muss korrekt erfolgen, sonst könnte es zu einer sogenannten „unendlichen Replikation“ kommen, bei der ein Thema unendlich oft repliziert wird, was schließlich zu einem Absturz führt.

Ein weiterer Nachteil von Mirror Maker ist das Fehlen einer dynamischen Konfiguration von Erlaubt-/Unzulässig-Listen für Updates. Mirror Maker synchronisiert auch die Themeneigenschaften nicht richtig, was das Hinzufügen oder Entfernen von zu replizierenden Themen im großen Maßstab zu betrieblichen Problemen macht. Mirror Maker 2 versucht, einige dieser Herausforderungen zu beheben, aber viele IT-Abteilungen haben immer noch Schwierigkeiten, Mirror Maker richtig einzurichten.

Weitere Open-Source-Tools für die Kafka-Replikation sind Mirus von Salesforce, uReplicator von Uber und angepasstes Flink von Netflix .

Für kommerziell lizenzierte Optionen bietet Confluent zwei Optionen an: Confluent Replicator und Cluster Linking. Confluent Replicator ist im Wesentlichen ein Kafka Connect-Connector, der eine leistungsstarke und belastbare Möglichkeit zum Kopieren von Themendaten zwischen Clustern bietet. Cluster Linking ist ein weiteres intern entwickeltes Angebot, das auf die Replikation in mehreren Regionen unter Beibehaltung von Topic-Offsets abzielt.

Dennoch handelt es sich bei Cluster Linking um ein asynchrones Replikationstool, bei dem Daten Netzwerkgrenzen überschreiten und öffentliche Verkehrswege durchlaufen müssen. Da inzwischen klar sein sollte, dass die Kafka-Replikation eine entscheidende Strategie für Produktionsanwendungen im großen Maßstab ist, stellt sich die Frage, welche Option man wählen sollte.

Einfallsreiche Kafka-Administratoren werden schnell erkennen, dass Sie je nach Anwendungsleistung und Ausfallsicherheitsanforderungen möglicherweise verbundene Cluster und ausgeweitete Cluster oder eine Kombination dieser Bereitstellungen benötigen.

Was jedoch entmutigend ist, sind die exponentiellen Herausforderungen beim Einrichten der Clusterkonfigurationen und deren Verwaltung im großen Maßstab über mehrere Cluster hinweg. Wie lässt sich dieser Albtraum eleganter lösen?

KubeSlice von Avesha ist eine einfache Möglichkeit, das Beste aus beiden Welten herauszuholen. Durch die Schaffung einer direkten Service-Konnektivität zwischen Clustern oder Namespaces macht KubeSlice die manuelle Konfiguration einzelner Konnektivitäten zwischen Kafka-Clustern überflüssig.

Im Kern erstellt KubeSlice ein sicheres, synchrones Layer-3-Netzwerk-Gateway zwischen Clustern; isoliert auf Anwendungs- oder Namespace-Ebene. Sobald dies eingerichtet ist, können Kafka-Administratoren Kafka-Broker in jedem der Cluster bereitstellen.

Jeder Broker verfügt über eine synchrone Konnektivität zu jedem anderen Broker, der über das Slice verbunden ist, auch wenn sich die Broker selbst möglicherweise in separaten Clustern befinden. Dadurch entsteht effektiv ein ausgedehnter Cluster zwischen den Brokern und bietet den Vorteil einer starken Konsistenz und eines geringen Verwaltungsaufwands.

Iss deinen Kuchen und iss ihn auch!

Für diejenigen, die Mirror Maker in ihren Clustern bereitstellen möchten, ist dies mit minimalem Aufwand möglich, da die Konnektivität zwischen den Clustern an KubeSlice delegiert wird. Somit können Kafka-Anwendungen die Vorteile einer synchronen (Geschwindigkeit, Ausfallsicherheit) UND asynchronen (Unabhängigkeit, Skalierung) Replikation in derselben Bereitstellung nutzen und die Funktionen je nach Bedarf kombinieren und anpassen. Dies gilt für Rechenzentren vor Ort, über öffentliche Clouds hinweg oder beliebige Kombinationen davon in einem Hybrid-Setup.

Das Beste daran ist, dass es sich bei KubeSlice um eine unterbrechungsfreie Bereitstellung handelt, sodass bereits bereitgestellte Tools nicht deinstalliert werden müssen. Es geht lediglich darum, einen Slice einzurichten und die Kafka-Bereitstellung diesem Slice hinzuzufügen.

Abschluss

Dieser Blog gab einen kurzen Überblick über Apache Kafka und ging auf einige der häufigsten Anwendungsfälle ein. Wir haben die aktuell verfügbaren Tools zur Skalierung von Kafka-Bereitstellungen über mehrere Cluster hinweg behandelt und die Vor- und Nachteile jedes einzelnen besprochen. Schließlich stellte der Artikel auch Kubeslice vor – die neue Service-Konnektivitätslösung, die Kafka-Multi-Cluster-Bereitstellungen vereinfacht und die Probleme beseitigt, die mit der Konfiguration der Kafka-Replikation über mehrere Cluster hinweg in großem Maßstab verbunden sind.

Ein paar Links, die für Leser nützlich sein könnten:

Ein älterer Blog mit Best Practices zum Ausführen von Kafka auf AWS (vor der Einführung von KubeSlice)

Geführte Einrichtung von KubeSlice

Kafka auf GKE bereitstellen