Managed Service for Apache Kafka – Übersicht

Managed Service for Apache Kafka ist ein Google Cloud Dienst, mit dem Sie sichere, skalierbare Open-Source-Apache Kafka-Cluster ausführen können. Auf dieser Seite finden Sie einen Überblick darüber, was der Dienst für Sie automatisiert und vereinfacht. Weitere Informationen zu Apache Kafka finden Sie auf der Apache Kafka-Website.

Einfache Größenanpassung und Skalierung

Wenn Sie die Größe eines Managed Service for Apache Kafka-Clusters festlegen oder ihn skalieren möchten, müssen Sie nur die Gesamtzahl der vCPUs und die RAM-Größe für den Cluster festlegen. Die Verwaltung von Brokern, einschließlich des Speichers, erfolgt vollständig automatisch. Um den Anforderungen von Clients gerecht zu werden, können Sie die vCPU- und andere Ressourcennutzung überwachen und nach oben oder unten anpassen.

Wenn Sie die Anzahl der vCPUs und die RAM-Größe festlegen, werden Broker automatisch in der Größe angepasst und bereitgestellt. Wenn für die Erhöhung der Clustergröße ein neuer Broker erforderlich ist, kann der Dienst Partitionen automatisch zwischen Brokern neu ausgleichen.

Broker-Bereitstellung

Wenn Sie die gesamte vCPU- und RAM-Größe für den Cluster konfigurieren, stellt der Dienst neue Broker bereit und skaliert vorhandene Broker. Bei einer typischen Clusterkonfiguration werden die Gesamtgröße von vCPU und RAM gleichmäßig auf alle Broker aufgeteilt. Das bedeutet, dass auch Bruchteile von vCPUs pro Broker zulässig sind, es muss jedoch mindestens eine vCPU pro Broker vorhanden sein. Alle Cluster werden auf drei Zonen verteilt. Das bedeutet, dass mindestens 3 vCPUs und 3 GiB RAM pro Cluster erforderlich sind.

Wenn Sie die Clustergröße erhöhen, werden Broker vertikal auf bis zu 15 vCPUs pro Broker skaliert. Wenn dieses Limit erreicht ist, werden neue Broker erstellt. Wenn Sie die Clustergröße verringern, werden vorhandene Broker auf eine einzelne vCPU skaliert, aber nicht gelöscht.

Die maximale Brokergröße kann sich jederzeit ändern. Dieses Limit wurde festgelegt, um eine lineare Skalierung des Broker-Durchsatzes mit der Anzahl der vCPUs zu ermöglichen.

Skalierungsalgorithmus

Die Anzahl der Broker wird durch die gesamte vCPU- oder Arbeitsspeicherkapazität des Clusters bestimmt. Das Skalierungsverhältnis beträgt 1 Broker für jeweils 15 vCPUs oder 120 GiB an Ressourcen, je nachdem, was zu einer größeren Anzahl von Brokern führt. Das Verhältnis von vCPU zu Arbeitsspeicher (vCPU:GiB) muss zwischen 1:1 und 1:8 liegen. Die Broker sind gleichmäßig auf die drei Zonen verteilt, mit einem maximalen Unterschied von einem.

Wenn Sie beispielsweise einen Cluster mit 70 vCPUs und 130 GiB RAM sowie einem Replikationsfaktor von 3 konfigurieren, wird die Anzahl der Broker so berechnet:

Berechnen Sie die Anzahl der Broker, die für vCPUs erforderlich sind: ceiling(70 vCPUs / 15 vCPUs) = 5 Broker
Berechnen Sie die Anzahl der Broker, die für den Arbeitsspeicher erforderlich sind: ceiling(130 GiB / 120 GiB) = 2 Broker.

In diesem Szenario hat der Cluster fünf Broker, da die Anzahl der Broker durch die Anzahl der vCPUs bestimmt wird. Zwei der drei Zonen haben jeweils zwei Broker und die letzte Zone hat einen Broker.

Speicherverwaltung

Die Speicherverwaltung ist automatisiert. In den meisten Fällen sind Sie dafür verantwortlich, die Aufbewahrungsdauer für einzelne Themen festzulegen, um die Kosten zu kontrollieren oder Ihre Richtlinien zur Datenaufbewahrung zu erfüllen. Sie müssen keine persistenten Datenträger bereitstellen und verwalten.

Der Dienst basiert auf mehrstufigem Speicher (KIP-405). Bei Tiered Storage werden vorab bereitgestellte Persistent Disk-Volumes, die an Broker angehängt sind, mit praktisch unbegrenztem Objektspeicher kombiniert.

Der Dienst weist jeder vCPU mindestens 100 GiB nichtflüchtige SSD-Speicher zu, um Leistung, Verfügbarkeit und Kosten in Einklang zu bringen. Ihnen werden 100 GiB pro vCPU in Rechnung gestellt, obwohl die tatsächliche Festplattengröße pro Broker diesen Wert überschreiten kann. Die Größe des Laufwerks pro Broker wird nie verringert, auch wenn der Cluster herunterskaliert wird.

Jeder Partitions-Leader puffert Nachrichten in Segmentdateien auf diesen persistenten Festplatten. Nachdem ein Segment gerollt wurde, wird es in den persistenten Objektspeicher verschoben, der von regionalem Cloud Storage unterstützt wird. Die Größe dieser Segmentdateien wird durch die Einstellungen log.roll.ms und log.segment.bytes festgelegt.

Diese Details sind zwar hilfreich, um die Funktionsweise zu verstehen, der Speicher wird jedoch vom Dienst verwaltet. Die spezifischen Konfigurationen, z. B. die Menge an Persistent Disk-Kapazität pro vCPU, sind Implementierungsdetails, die sich ändern können. Sie haben keinen direkten Zugriff auf Cloud Storage-Buckets, die für den persistenten Speicher verwendet werden.

Neuausgleich

Damit neu bereitgestellte Broker zur Aufrechterhaltung der Leistung beitragen können, muss ein Teil des Traffics von bestehenden Brokern auf diese neuen Maschinen verlagert werden. Um dies zu vereinfachen, können Sie die automatische Neuausrichtung aktivieren.

Wenn die automatische Neuausrichtung aktiviert ist und ein neuer Broker bereitgestellt wird, werden die Partitionen von vorhandenen Brokern automatisch neu ausgerichtet. Das mehrstufige Speichermodell sorgt dafür, dass nur eine relativ geringe Menge an Daten auf neue Broker kopiert werden muss, was das Neuausgleichen beschleunigt.

Der Algorithmus für den Ausgleich basiert auf der Anzahl der Partitionen. Der tatsächliche Traffic, der von den einzelnen Partitionen bereitgestellt wird, wird nicht berücksichtigt.

Flexibles Netzwerk

Der Dienst macht einen Cluster sicher über jede VPC zugänglich. Dazu gehört der Zugriff über mehrere VPCs, Projekte und Regionen hinweg.

Um das Netzwerk für einen Cluster zu konfigurieren, geben Sie die Subnetze an, in denen der Cluster zugänglich ist. Der Dienst stellt private IP-Adressen für die Bootstrap-Server und Broker in jedem Subnetz bereit. Außerdem wird privates Cloud DNS mit URLs für jede IP-Adresse eingerichtet. Die Bootstrap-Server haben einen Load-Balancer, sodass es pro Cluster eine einzelne Bootstrap-URL gibt. Die URLs sind in allen VPCs gleich, sodass Clientkonfigurationen in allen Umgebungen einheitlich sein können.

Diese Flexibilität wird durch Private Service Connect (PSC) erreicht. Für jede IP-Adresse, die einem Cluster zugewiesen ist, ist ein PSC-Endpunkt erforderlich. Die Endpunkte werden automatisch bereitgestellt.

Cluster sichern

Der Dienst bietet die folgenden Funktionen für die Sicherheit der Cluster: Authentifizierung, Autorisierung, Verschlüsselung, Patchen und Ressourcenisolation. Außerdem werden nicht authentifizierte und unverschlüsselte Verbindungen und Speicher nicht zugelassen.

Authentifizierung

Der Dienst unterstützt zwei Authentifizierungsmethoden: Simple Authentication and Security Layer (SASL) und Mutual TLS (mTLS). Die mTLS-Authentifizierung ist für Cluster verfügbar, die nach dem 24. Juni 2025 erstellt wurden. Alle Verbindungen zu verwalteten Clustern werden mit einem Prinzipal authentifiziert, der eine IAM-Identität mit SASL oder einem Clientzertifikat mit mTLS ist. Bei Verwendung von SASL werden Nutzerkonten, Dienstkonten und föderierte Konten als Hauptkonten unterstützt.

Der Dienst unterstützt keine anderen Protokolle, einschließlich SASL/GSSAPI, SASL/SCRAM-SHA-256 und SASL/SCRAM-SHA-512. Der Dienst lässt auch keine nicht authentifizierten Verbindungen zu.

Autorisierung

Der Dienst verwendet einen mehrschichtigen Ansatz für die Autorisierung. IAM steuert Clusterverwaltungsaktionen wie das Erstellen, Aktualisieren und Löschen von Ressourcen. Die Autorisierung für authentifizierte Principals hängt von der verwendeten Methode ab:

SASL: Hauptkonten, die IAM verwenden, werden überGoogle Cloud IAM-Rollenbindungen oder mit Kafka-ACLs im Cluster autorisiert. Weitere Informationen finden Sie unter SASL-Authentifizierung konfigurieren.
mTLS: Principals, die sich mit mTLS authentifizieren, werden über Kafka-ACLs autorisiert. Weitere Informationen finden Sie unter mTLS-Authentifizierung konfigurieren.

Sie können Kafka-ACLs mit den Google Cloud Tools oder Kafka-Tools von Drittanbietern verwalten. Weitere Informationen zum Konfigurieren von IAM und Kafka-ACLs finden Sie unter Zugriffssteuerung mit IAM und Kafka-ACLs.

Verschlüsselung

Verschlüsselung ist erforderlich. Alle Verbindungen zu Clustern müssen TLS verwenden. Die von den Brokern präsentierten TLS-Zertifikate werden von Public Certificate Authority signiert. Gespeicherte Daten werden immer verschlüsselt. Wählen Sie aus, ob Sie von Google verwaltete oder vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) für die Verschlüsselung ruhender Daten verwenden möchten.

Patchen

Das Serviceteam verfolgt Sicherheitslücken, die im Open-Source-Code entdeckt wurden. Wenn der Dienst Sicherheitslücken erkennt, werden Ihre Cluster automatisch gepatcht.

Ressourcenisolation

Eine weitere Sicherheitsfunktion des Dienstes ist die Ressourcenisolation. Der verwaltete Dienst stellt Cluster in Mandantenprojekten in einer privaten VPC bereit, auf die nicht über öffentliche IP-Adressen zugegriffen werden kann. Jedes Ihrer Projekte hat ein eigenes Mandantenprojekt mit einem eigenen Dienst-Agent-Konto. So wird der Umfang des Zugriffs, der dem Dienst gewährt wird, begrenzt.

Schema-Registry

Um die Koordination zwischen Produzenten und Nutzern zu vereinfachen, enthält Managed Service for Apache Kafka eine Schema-Registry-API. Eine vom Dienst bereitgestellte Registry dient als Repository für Schemas, die von Anwendungen gemeinsam genutzt werden.

Der Dienst implementiert die Confluent Schema Registry REST API, die die Integration in bestehende Kafka-Anwendungen erleichtert. Die Schemaformate Apache Avro und Protocol Buffer (Protobuf) werden unterstützt. JSON wird nicht unterstützt.

Managed Service for Apache Kafka bietet außerdem eine administrative API und ein Toolset zum Verwalten von Schema-Registries und Schemas. Das Toolset umfasst dieGoogle Cloud -Konsole, die gcloud CLI und Clientbibliotheken.

Weitere Informationen zur Schemaregistrierung finden Sie unter Schemaregistrierung – Übersicht.

Datenintegration mit Kafka Connect

Managed Service for Apache Kafka vereinfacht die Datenintegration über Kafka Connect. Kafka Connect bietet mehrere integrierte Connector-Plug‑ins, die in Connect-Clustern gehostet werden. Diese Connectors werden für Migration, Sicherung, Notfallwiederherstellung, Hochverfügbarkeit und Datenintegration verwendet. Mit diesen Connectors können Sie Ihre Managed Service for Apache Kafka-Cluster mit verschiedenen Systemen verbinden, darunter andere Kafka-Bereitstellungen und Google Cloud Dienste wie BigQuery, Cloud Storage und Pub/Sub. Kafka Connect bietet eine skalierbare, zuverlässige Datenintegration mit geringerem Betriebsaufwand sowie integriertem Monitoring und Logging.

Weitere Informationen zu Kafka Connect finden Sie in der Kafka Connect-Übersicht.

Cluster mit Hochverfügbarkeit

Ziel des Dienstes ist es, regionale Cluster für geschäftskritische Anwendungen bereitzustellen. Der Dienst schützt Sie vor Ausfällen einzelner Zonen oder Broker.

Dazu werden alle Cluster in einer rack-fähigen Konfiguration mit drei Zonen bereitgestellt. Für die Standardkonfiguration für Themen sind mindestens drei Replikate erforderlich. Durch die Rack-Awareness wird dafür gesorgt, dass Replikate in verschiedenen Zonen erstellt werden. Die standardmäßige Mindestanzahl von synchronisierten Replikaten ist zwei. Das bedeutet, dass Ihr Cluster den vollständigen Verlust einer Zone oder eines Brokers tolerieren kann.

Wenn ein Broker aufgrund eines Software-, Hardware- oder Netzwerkfehlers ausfällt, wird er automatisch ersetzt. Wenn der Dienst einen Brokerfehler erkennt, wird der Broker automatisch neu gestartet, bei Bedarf auf einem anderen Computer. Sobald der Broker verfügbar ist, wird er von Apache Kafka in den Cluster eingebunden. Bei einem vollständigen Zonenausfall ist es möglicherweise nicht möglich, einen neuen Broker zu erstellen. Der Cluster wird jedoch weiter betrieben, solange die anderen beiden Zonen verfügbar bleiben.

Zusätzlich zu diesen spezifischen Funktionen wird der Dienst, der Apache Kafka-Code und die Updates durch eine wachsende Liste interner Tools und Prozesse proaktiv gewartet. Sicherungen von Daten und Metadaten werden auf mehreren Ebenen verwaltet, sodass der Dienst nach vielen menschlichen Fehlern und Softwarefehlern wiederhergestellt werden kann.

Der Dienst bietet keinen Schutz vor regionalen oder Dual-Zone-Ausfällen. Für Anwendungen, die dieses Schutzniveau erfordern, empfehlen wir, zwei separate regionale Cluster auszuführen. Sie können die Daten zwischen zwei Clustern mit Tools wie MirrorMaker 2.0 von Kafka Connect synchronisieren.

Tools für Ihren Verwaltungsstil

Der Dienst soll ein vollständiges Set von Tools für die Verwaltung und Fehlerbehebung von Clustern bieten. Dazu gehören Tools für die Verwaltung, das Monitoring und die Protokollierung.

Der Managed Service for Apache Kafka wird als Google Cloud API bereitgestellt. Das bedeutet, dass Sie Cluster und Clusterressourcen mit REST- und gRPC-APIs verwalten können. Für diese APIs werden mehrere Clients und Schnittstellen bereitgestellt, darunter:

Terraform-Anbieter, wenn Sie den Infrastructure-as-Code-Ansatz bevorzugen.
UI in der Google Cloud Console für die interaktive Arbeit in einem Browser.
Die gcloud CLI für die interaktive Arbeit in einer Shell.
Clientbibliotheken in Java, Python, Go und anderen Sprachen für die benutzerdefinierte Entwicklung und das Scripting.

Zur Überwachung und Fehlerbehebung exportiert der Dienst Messwerte nach Cloud Monitoring. Einige Messwerte sind in der Benutzeroberfläche des Dienstes verfügbar. Ein vollständiger Satz ist in Cloud Monitoring für interaktive Arbeit, das Konfigurieren von Benachrichtigungen und den Export in andere Systeme verfügbar.

Der Dienst exportiert auch Broker-Logs nach Cloud Logging. Sie sind durchsuchbar und können verwendet werden, um logbasierte Messwerte und Benachrichtigungen zu erstellen.

Upgrades und Patches

Managed Service for Apache Kafka-Cluster werden mit Apache Kafka-Version 3.7.1 ausgeführt. Der Dienst patcht kritische Sicherheitslücken automatisch.

Updates der zugrunde liegenden Infrastruktur, einschließlich der Betriebssystem- und Orchestrierungsebenen, erfolgen kontinuierlich und automatisch. Broker werden mit einem Rolling Restart aktualisiert, ohne dass es zu Ausfallzeiten im Cluster kommt.

Der Dienst aktualisiert den auf den Brokern ausgeführten Apache Kafka-Code nicht automatisch auf neue Nebenversionen.

Transparente Kosten

Das Preismodell für Managed Service for Apache Kafka ähnelt den Gebühren, die anfallen, wenn Sie Apache Kafka selbst in Compute Engine ausführen. Sie zahlen für die Ressourcen, die Sie bereitstellen – vCPU, RAM und lokaler Speicher – und nutzen – nichtflüchtiger Speicher und Datenübertragung. Die Kosten für persistenten Speicher und vCPUs sind bei Managed Service for Apache Kafka höher als bei der Einrichtung eines ähnlichen Systems. Im Gegensatz dazu sind die Preise für Datenübertragung und lokalen Speicher bei Managed Service for Apache Kafka und selbstverwaltetem Kafka ähnlich. Weitere Informationen zu den Preisen finden Sie unter Managed Service for Apache Kafka – Preise.

Kompatibel, da wir Apache Kafka ausführen

Schließlich wird im Managed Service for Apache Kafka dieselbe Open-Source-Software ausgeführt, die Sie möglicherweise bereits in Ihrer Umgebung verwenden. Sie müssen den Anwendungscode nicht ändern, um ihn zum Dienst zu migrieren.

Beschränkungen

Für Managed Service for Apache Kafka gelten die folgenden Einschränkungen:

Jeder Cluster muss in jeder der drei Zonen über die gleichen Ressourcen verfügen. Managed Service for Apache Kafka-Cluster mit einer oder zwei Zonen werden nicht unterstützt.
Sie können die Zonen beim Erstellen des Clusters nicht auswählen.
Sie können das Volumen des lokalen Speichers in einem Cluster nicht konfigurieren.
Managed Service for Apache Kafka wird im KRaft-Modus ausgeführt. Der Zookeeper-Modus wird nicht unterstützt.
JMX-APIs für Messwerte werden nicht unterstützt.
Die Themenkomprimierung mit zstd wird nicht unterstützt. Unterstützte Werte für compression.type sind lz4, gzip, snappy und uncompressed.
Sie können die Brokerkonfigurationen mit dem Aktualisierungsmodus read-only jederzeit ändern. Diese Änderungen werden jedoch erst wirksam, wenn die Broker neu gestartet werden. Neustarts erfolgen regelmäßig im Rahmen der Wartungs- und Upgradeprozesse von Google. Es gibt jedoch keinen festgelegten Zeitplan und keine Möglichkeit, sie manuell auszulösen. Daher können Sie nicht festlegen, wann diese Änderungen in Kraft treten. Beispiele für read-only-Konfigurationen sind auto.create.topics.enable und background.threads. Aktualisierungen von Konfigurationen mit dem Aktualisierungsmodus cluster-wide, z. B. message.max.bytes, erfordern keinen Neustart und werden sofort wirksam.
Einige Brokerkonfigurationsparameter werden vom Dienst verwaltet und können nicht aktualisiert werden. Dazu gehören broker.id und speicherbezogene Einstellungen wie remote.log.storage.system.enable.

Nächste Schritte

Apache Kafka® ist eine eingetragene Marke der Apache Software Foundation oder deren Tochtergesellschaften in den USA und/oder anderen Ländern.