Kommentar von Falko Germar-Schwarz, Factor House Kafka im Multi-Cluster-Betrieb – wo Governance und Monitoring an Grenzen stoßen

Die meisten Unternehmen, die heute Apache Kafka einsetzen, betreiben nicht nur einen Cluster, sondern drei oder vier – verteilt auf Produktions-, Disaster-Recovery-, Staging- und regionale Umgebungen. Die Tools, die sie zur Überwachung und Steuerung dieser Cluster verwenden, wurden jedoch für eine einfachere Welt konzipiert: ein Cluster, eine Ansicht, ein Satz von Richtlinien. Die Folge ist eine wachsende Kluft zwischen der Komplexität der Umgebung und dem tatsächlichen Einblick, den die Betreiber in diese haben.

Ein intakter Cluster bedeutet nicht automatisch, dass die Datenplattform intakt ist. Irgendwo weiter unten in der Kette hinkt eine Consumer-Gruppe, die auf replizierte Daten aus einem sekundären Cluster angewiesen ist, seit Stunden hinterher. Es wird kein Alarm ausgelöst. Das Problem liegt nicht in dem Cluster, auf den sich der Admin konzentriert hat.

Das ist ein bekannter Fehlermodus in Kafka-Umgebungen mit mehreren Clustern und verdeutlicht einen Unterschied, den Standard-Observability-Tools selten sichtbar machen. Der Zustand auf Cluster-Ebene und die Integrität des Datenflusses sind unterschiedliche Aspekte. Es ist möglich, dass alle Cluster auf den Dashboards grün angezeigt werden, die Pipelines zwischen ihnen jedoch dennoch gestört sind.

Wie Multi-Cluster-Umgebungen entstehen

Die meisten Multi-Cluster-Kafka-Bereitstellungen sind nicht von Grund auf neu konzipiert worden. Ein zweiter Cluster kam für die Notfallwiederherstellung hinzu, ein dritter zur Trennung von Produktion und Staging, ein vierter im Zuge einer Übernahme, bei der ein Unternehmen seine eigene Infrastruktur einbrachte. Jede dieser Entscheidungen ist zu ihrem jeweiligen Zeitpunkt sinnvoll gewesen, doch jede hat die Komplexität des Betriebs erhöht, mit der sich das Team langfristig auseinandersetzen muss.

Wenn Governance zu einem ernsthaften Problem wird, ist die Topologie bereits etabliert und teilweise undokumentiert. Die Namenskonventionen für Topics haben sich verschoben. Die Replikationskonfiguration befindet sich in einem Runbook, das seit sechs Monaten nicht mehr aktualisiert wurde. Zugriffsrichtlinien wurden manuell zwischen den Clustern kopiert – von jemandem, der inzwischen in ein anderes Team gewechselt ist.

Das ist der typische Ausgangspunkt: keine Greenfield-Architektur mit integrierter Governance, sondern eine Umgebung, die schrittweise gewachsen ist und nun in einem Umfang betrieben wird, für den die ursprünglichen Tools nicht ausgelegt waren. Genau diese Diskrepanz zwischen Tools und Topologie bildet den Kern der Probleme.

Wo Single-Cluster-Tools an ihre Grenzen stoßen

Die meisten Kafka-Überwachungs- und Governance-Tools basieren auf einem Modell mit einzelnen Clustern und zeigen jeweils nur die Broker-Metriken, den Verzögerungsgrad der Consumer-Gruppen, die Topic-Konfigurationen und die ACL-Definitionen für einen einzelnen Cluster an. Das funktioniert so lange, bis sich Ihre Datenflüsse über mehrere Cluster erstrecken. Ab diesem Punkt entstehen systematische Blindstellen.

Lags über Replikationstopologien hinweg: Innerhalb eines einzelnen Clusters lassen sich Latenzen leicht erkennen. Werden Daten mithilfe von MirrorMaker 2 oder ähnlichen Tools zwischen Clustern repliziert, melden die Consumer-Gruppen auf Quell- und Zielseite ihre Verzögerungen jeweils unabhängig voneinander. Da es kein Standard-Tool gibt, das diese Signale miteinander verknüpft, müssen sich die Verantwortlichen das Gesamtbild selbst erschließen.

Abweichungen in der Schema-Registry: In der Regel betreibt jeder Cluster eine eigene Schema-Registry-Instanz, wobei Kompatibilitätsprüfungen lokal durchgesetzt werden. Sind die Register zweier oder mehrerer Cluster nicht mehr synchron, kann ein Produzent, der gültige Daten an der Quelle schreibt, Nachrichten erzeugen, die mit dem Zielschema nicht kompatibel sind. Das bleibt unsichtbar, bis ein Konsument die Deserialisierung nicht mehr durchführen kann.

Es gibt Abweichungen bei ACLs und RBAC: Da Kafka über keinen nativen Mechanismus zur Synchronisierung von ACLs über Cluster hinweg verfügt, muss jede Richtlinienänderung bewusst weitergegeben werden. In der Praxis geschieht das jedoch selten konsistent. Temporäre Wildcard-ACLs bleiben ungeprüft bestehen. Deaktivierte Prinzipale behalten Zugriff auf Repliken. Die Zugriffssituation der Cluster weicht auf eine Weise ab, die sich im Nachhinein nur schwer überprüfen lässt.

Die Protokollierung von Monitoring-Daten ist fragmentiert: Überwachungsprotokolle werden für jeden Cluster separat erstellt und in der Regel an unterschiedliche Ziele weitergeleitet. Um Änderungen clusterübergreifend zu korrelieren, sind eine Protokollaggregation und eine gemeinsame Zeitachse erforderlich. Die meisten Unternehmen erkennen diese Lücke erst, wenn sie einen Vorfall rekonstruieren müssen.

Jeder dieser Fehlerfälle ist für sich genommen beherrschbar. Zusammen beschreiben sie jedoch eine Umgebung, in der den Betreibern die erforderliche clusterübergreifende Transparenz fehlt, um das System als Ganzes zu verstehen.

Unklare Zuständigkeiten als strukturelles Problem

Zu den oben genannten technischen Ausfallursachen kommt ein weiteres, noch schwierigeres Problem hinzu: die Zuständigkeit. In Umgebungen mit mehreren Clustern ist diese selten klar definiert, wodurch unmittelbar Unklarheiten in den Verantwortlichkeiten entstehen.

Betrachten wir ein Topic, das in einem primären Produktionscluster, einem sekundären DR-Cluster, einem Staging-Cluster und einer regionalen Bereitstellung vorhanden ist. Wer ist dafür verantwortlich? Das Team, das es im primären Cluster erstellt hat, könnte sich zuständig sehen. Das Plattformteam könnte sich für die Replikation verantwortlich fühlen. Das regionale Team hat die Konfiguration möglicherweise lokal geändert. Wenn etwas schiefgeht, gibt es keine eindeutig zuständige Stelle.

Die praktischen Konsequenzen sind vorhersehbar. Ein Thema namens „transactions.processed” auf dem Primärcluster kann sich auf einen anderen Datenvertrag beziehen als ein gleichnamiges Thema auf dem regionalen Cluster, das von einem anderen Team erstellt wurde. Wenn diese Cluster über Replikation verbunden sind, tritt die Kollision möglicherweise erst zutage, wenn Daten aus einem Kontext in einem anderen verarbeitet werden.

Die ACL-Governance folgt dem gleichen Muster. Berechtigungen, die zur Einhaltung einer Frist erteilt wurden, sammeln sich über Umgebungen hinweg an und werden selten überprüft, da sie aufgrund des Fehlens einer clusterübergreifenden Audit-Oberfläche nicht sichtbar sind. In regulierten Branchen stellt diese Abweichung ein direktes Compliance-Risiko dar.

Das zugrunde liegende Problem ist struktureller Natur: Multi-Cluster-Kafka wird tendenziell als Sammlung unabhängiger Cluster und nicht als einheitliche Plattform betrieben. Dieses Modell ist aus Governance-Sicht nicht skalierbar.

Was eine gut verwaltete Umgebung auszeichnet

Die Kluft zwischen dem aktuellen Stand der meisten Unternehmen und ihrem angestrebten Ziel ist oft größer, als es den Anschein hat. Eine gut verwaltete Multi-Cluster-Kafka-Umgebung zeichnet sich durch vier Fähigkeiten aus, von denen die meisten Teams keine einzige vollständig umgesetzt haben.

Die erste ist eine einheitliche Übersicht über die Cluster-Landschaft. Betreiber sollten in der Lage sein, Themenkonfigurationen, den Status von Consumer-Gruppen und die Replikationstopologie über alle Cluster hinweg aus einem einzigen Kontext einzusehen. Die meisten Teams erfüllen diese Anforderung, wenn überhaupt, durch Skripte, aus separaten Datenquellen zusammengestellten Dashboards und institutionellem Wissen, das bei bestimmten Personen liegt.

Die zweite Fähigkeit ist die Konsistenz der Richtlinien. ACL- und RBAC-Konfigurationen sollten versioniert und konsistent über alle Cluster hinweg angewendet werden. Zu diesem Zweck gibt es „Policy-as-Code“-Ansätze, deren Einsatz in Kafka-Umgebungen jedoch nach wie vor begrenzt ist. Die nachträgliche Einführung eines konsistenten Richtlinienmodells in gewachsenen Umgebungen erfordert zudem die Entflechtung von Zugriffskonfigurationen, die nie auf Portabilität ausgelegt waren.

Der dritte Punkt betrifft die Schema-Governance an Übergängen zwischen Umgebungen. Wenn Daten zwischen Clustern verschoben werden, sollte die Schemakompatibilität im Rahmen dieses Vorgangs überprüft und nicht einfach vorausgesetzt werden. Die meisten Bereitstellungs-Pipelines enthalten diesen Schritt jedoch nicht.

Der vierte Punkt betrifft die clusterübergreifende Überwachungsfunktion. Konfigurationsänderungen, Anpassungen der Zugriffsrichtlinien und die Zuordnung von Consumer-Gruppen sollten über die gesamte Cluster-Landschaft hinweg anhand einer gemeinsamen Zeitachse nachvollziehbar sein. In Umgebungen, in denen Cluster von verschiedenen Teams verwaltet werden, erfordert dies eine teamübergreifende Koordination, die nur schwer aufrechtzuerhalten ist.

Die meisten erfahrenen Plattformingenieure könnten eine ähnliche Liste erstellen. Das Problem liegt nicht im Wissen, sondern in der Umsetzung. Die Erfüllung dieser Anforderungen bedeutet, die Kafka-Topologie als Plattformthema und nicht als Infrastrukturproblem zu behandeln. Dafür sind klare Zuständigkeiten und abgestimmte Prozesse zwischen den Teams erforderlich. Diese konkurrieren jedoch häufig mit den Prioritäten der Bereitstellung. Wenn Kafka vorwiegend als Transportschicht betrachtet wird, neigt man dazu, Governance-Aufgaben aufzuschieben, bis die Kosten dieser Verzögerung sichtbar werden – in der Regel während eines Vorfalls.

Betriebspraktiken, die sich jetzt einführen lassen

Es gibt mehrere Praktiken, mit denen sich die Multi-Cluster-Governance sinnvoll verbessern lässt, ohne dass eine komplette Neugestaltung der Architektur erforderlich ist.

Cluster Inventory als zentrale Informationsquelle. Darin sollte erfasst werden, welche Cluster existieren, wem sie gehören und wie sie miteinander in Beziehung stehen. Ein strukturiertes Dokument in der Versionskontrolle reicht hierfür aus. Ohne ein solches Dokument hängen die Einbindung neuer Cluster, die Zugriffsprüfung und die Beurteilung der Replikationstopologie ausschließlich vom Wissen der Mitarbeitenden ab.

ACL- und RBAC-Konfigurationen als Code behandeln. Die Definitionen von Zugriffsrichtlinien sollten in der Versionskontrolle gespeichert werden. Änderungen sollten über einen kontrollierten Prozess vorgenommen werden, anstatt sie direkt am Cluster vorzunehmen. So wird ein überprüfbarer Verlauf geschaffen und es ist möglich, die beabsichtigte Richtlinie mit dem tatsächlichen Cluster-Zustand zu vergleichen, wodurch Abweichungen sichtbar werden.

Schemakompatibilität an Übergängen zwischen Clustern sicherstellen. Vor der Überführung eines Schemas ist es ratsam, Kompatibilitätsprüfungen gegen die Ziel-Registry durchzuführen, statt sich allein auf die Quell-Registry zu verlassen. Die meisten Schema-Registry-Instanzen stellen hierfür entsprechende Endpunkte zur Verfügung. In der Praxis wird dieser Schritt häufig übersprungen – bis es in der Produktion zu einem Deserialisierungsfehler kommt.

Audit-Logs clusterübergreifend zusammenführen. Das Weiterleiten von Protokollen an einen gemeinsamen Speicherort ist der einzige zuverlässige Weg, um nachzuvollziehen, welche Änderungen in der gesamten Infrastruktur vorgenommen wurden. Dabei sind mindestens Änderungen an der Cluster- und Topic-Konfiguration, Anpassungen der Zugriffskontrolllisten (ACLs) und das Zurücksetzen von Consumer-Gruppen zu erfassen. Eine proaktive Umsetzung verursacht deutlich weniger Aufwand als eine nachträgliche Aufarbeitung im Zuge eines Audits.

Failover regelmäßig testen und die dabei festgestellten Lücken dokumentieren. Im Laufe der Zeit weichen Offset-Zuordnungen, der Status von Consumer-Gruppen und operative Runbooks von der tatsächlichen Umgebung ab. Geplante Failover-Tests decken diese Lücken auf, bevor sie im Ernstfall sichtbar werden – auch wenn die Tests nur teilweise durchgeführt werden.

Die richtige Beobachtungseinheit

Zwar ist der Cluster eine praktische Betriebseinheit, jedoch die falsche Beobachtungseinheit für die Integrität des Datenflusses. Ein einwandfrei funktionierender Cluster kann dennoch eine Schwachstelle in einer sich über mehrere Cluster erstreckenden Pipeline darstellen. Eine Standardüberwachung wird das nicht aufdecken, bevor es die Konsumenten tun.

Die Unternehmen, die diese Umgebungen am effektivsten betreiben, haben eine bewusste Umstellung vorgenommen. Sie betrachten ihre Cluster-Landschaft als Plattform mit gemeinsamen Governance-Anforderungen und nicht als Sammlung unabhängig verwalteter Infrastrukturen. Diese Umstellung erfordert keine neuen Tools. Vielmehr müssen Topologie, Zugriffsrichtlinien, Schemastatus und Audit-Fähigkeiten als Belange auf Plattformebene mit definierten Zuständigkeiten behandelt werden.

Die in diesem Artikel beschriebenen Ausfallmodi sind keine Randfälle. Sie sind die vorhersehbaren Folgen der Nutzung von Tools für einzelne Cluster in einem Umfang, für den sie nicht ausgelegt sind. Die Frage ist nicht, ob Cluster intakt sind, sondern ob eine ausreichende Transparenz über ihre Grenzen hinweg gewährleistet ist, um zu erkennen, wann die Datenflüsse nicht intakt sind.

(ID:50818988)