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 eine Übersicht 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 anpassen 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 automatisiert. Um den Anforderungen der Clients gerecht zu werden, können Sie die vCPU- und andere Ressourcennutzung beobachten und nach Bedarf anpassen.
Wenn Sie die Anzahl der vCPUs und die RAM-Größe festlegen, automatisiert der Dienst die Größenanpassung und Bereitstellung von Brokern. Wenn für die Erhöhung der Clustergröße ein neuer Broker erforderlich ist, kann der Dienst Partitionen automatisch zwischen Brokern neu ausgleichen.
Brokerbereitstellung
Wenn Sie die Gesamtzahl der vCPUs und die RAM-Größe für den Cluster konfigurieren, stellt der Dienst neue Broker bereit und skaliert vorhandene Broker. Bei einer typischen Clusterkonfiguration werden die Gesamtzahl der vCPUs und die RAM-Größe gleichmäßig auf alle Broker aufgeteilt. Das bedeutet, dass auch vCPU-Anzahlen mit Nachkommastellen pro Broker zulässig sind. Es ist jedoch mindestens eine vCPU pro Broker erforderlich. 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 die Broker vertikal auf bis zu 15 vCPUs pro Broker skaliert. Sobald dieses Limit erreicht ist, erstellt der Dienst neue Broker. Wenn Sie die Clustergröße verringern, werden vorhandene Broker auf eine einzelne vCPU herunterskaliert, aber nicht gelöscht.
Die maximale Brokergröße kann sich jederzeit ändern. Dieses Limit wurde festgelegt, um eine lineare Skalierung des Brokerdurchsatzes mit der Anzahl der vCPUs beizubehalten.
Skalierungsalgorithmus
Die Anzahl der Broker wird durch die Gesamtzahl der vCPUs oder die Speicherkapazität des Clusters bestimmt. Das Skalierungsverhältnis beträgt 1 Broker für jeweils 15 vCPUs oder 120 Gibibyte (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 werden gleichmäßig auf die drei Zonen verteilt, mit einer maximalen Differenz 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:
Anzahl der Broker berechnen, die für vCPUs erforderlich sind:
ceiling(70 vCPUs / 15 vCPUs)= 5 BrokerAnzahl der Broker berechnen, die für den Arbeitsspeicher erforderlich sind:
ceiling(130 GiB / 120 GiB)= 2 Broker
In diesem Szenario hat der Cluster 5 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 müssen Sie die Aufbewahrungszeit für einzelne Themen festlegen, um die Kosten zu kontrollieren oder Ihre Richtlinien zur Datenaufbewahrung einzuhalten. Sie müssen keine nichtflüchtigen Speicher bereitstellen und verwalten.
Der Dienst basiert auf mehrstufigem Speicher (KIP-405). Mehrstufiger Speicher kombiniert vorab bereitgestellte nichtflüchtige Speicher-Volumes, die mit Brokern verbunden sind, mit praktisch unbegrenztem Objektspeicher.
Der Dienst weist jeder vCPU mindestens 100 GiB nichtflüchtige SSD Speicher zu, um Leistung, Verfügbarkeit und Kosten auszugleichen. Ihnen werden 100 GiB pro vCPU in Rechnung gestellt, obwohl die tatsächliche Laufwerkgröße pro Broker diesen Wert übersteigen kann. Die Größe des Laufwerks pro Broker wird nie reduziert, auch wenn der Cluster herunterskaliert wird.
Jeder Partitionsleiter puffert Nachrichten in Segmentdateien auf diesen nichtflüchtigen Speichern. Nachdem ein Segment rotiert wurde, wird es in den nichtflüchtigen 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 nützlich, um den Dienst zu verstehen, aber der Speicher wird vom Dienst verwaltet. Die spezifischen Konfigurationen, z. B. die Menge der nichtflüchtigen Speicherkapazität pro vCPU, sind Implementierungsdetails, die sich ändern können. Sie haben keinen direkten Zugriff auf Cloud Storage-Buckets, die für nichtflüchtigen Speicher verwendet werden.
Neuausgleich
Damit neu bereitgestellte Broker zur Aufrechterhaltung der Leistung beitragen können, muss ein Teil des Traffics von vorhandenen Brokern auf diese neuen Maschinen verschoben werden. Um dies zu vereinfachen, können Sie den automatischen Neuausgleich aktivieren.
Wenn der automatische Neuausgleich aktiviert ist, gleicht der Dienst die Partitionen von vorhandenen Brokern automatisch neu aus, wenn ein neuer Broker bereitgestellt wird. Das mehrstufige Speichermodell stellt sicher, dass nur eine relativ geringe Datenmenge auf neue Broker kopiert werden muss, wodurch der Neuausgleich beschleunigt wird.
Der Neuausgleichsalgorithmus basiert auf der Anzahl der Partitionen. Der tatsächliche Traffic, der von jeder Partition bereitgestellt wird, wird nicht berücksichtigt.
Flexibles Netzwerk
Der Dienst ermöglicht den sicheren Zugriff auf einen Cluster von jeder VPC aus. Dazu gehört der Zugriff von mehreren VPCs, Projekten und Regionen aus.
Wenn Sie das Netzwerk für einen Cluster konfigurieren möchten, 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.
Dieses Maß an Flexibilität wird durch Private Service Connect (PSC) erreicht. Für jede IP-Adresse, die für einen Cluster zugewiesen wird, 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 nicht verschlü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 Principal authentifiziert, der eine IAM-Identität mit SASL oder ein Clientzertifikat mit mTLS ist. Bei Verwendung von SASL werden Nutzerkonten, Dienstkonten und Konten mit Föderation als Principals unterstützt.
Der Dienst unterstützt keine anderen Protokolle, einschließlich SASL/GSSAPI, SASL/SCRAM-SHA-256 und SASL/SCRAM-SHA-512. Außerdem sind nicht authentifizierte Verbindungen nicht zulässig.
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: Principals, die IAM verwenden, werden über Google Cloud IAM-Rollenbindungen oder mit Kafka-ACLs auf dem 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
Die 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 Dienstteam 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 Dienstagenten Konto. So wird der Umfang des Zugriffs, der dem Dienst gewährt wird, begrenzt.
Schema-Registry
Um die Koordination zwischen Produzenten und Konsumenten 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 vorhandene 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 Verwaltungs-API und ein Toolset zum Verwalten von Schema-Registries und Schemas. Das Toolset umfasst die Google Cloud Konsole, die gcloud CLI und Clientbibliotheken.
Weitere Informationen zur Schema-Registry finden Sie in der Übersicht zur Schema-Registry.
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, einschließlich anderer Kafka-Bereitstellungen und Google Cloud Diensten 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 Übersicht zu Kafka Connect.
Cluster mit Hochverfügbarkeit
Ziel des Dienstes ist es, regionale Cluster für geschäftskritische Anwendungen bereitzustellen. Insbesondere schützt der Dienst 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 des Themas sind mindestens drei Replikate erforderlich. Rack-Awareness sorgt dafür, dass Replikate in verschiedenen Zonen erstellt werden. Die standardmäßige Mindestanzahl synchroner Replikate beträgt 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 Netzwerkausfalls ausfällt, wird er automatisch ersetzt. Wenn der Dienst einen Broker-Ausfall erkennt, wird er automatisch neu gestartet, bei Bedarf auf einer anderen Maschine. Nachdem der Broker verfügbar ist, integriert Apache Kafka ihn in den Cluster. Bei einem vollständigen Zonenausfall ist es möglicherweise nicht möglich, einen neuen Broker zu erstellen. Der Cluster wird jedoch weiter ausgeführt, solange die anderen beiden Zonen verfügbar sind.
Zusätzlich zu diesen spezifischen Funktionen wird die Integrität des Dienstes, des Apache Kafka-Codes und der Updates proaktiv durch eine wachsende Liste interner Tools und Prozesse aufrechterhalten. Sicherungen von Daten und Metadaten werden auf mehreren Ebenen verwaltet, sodass der Dienst viele menschliche Fehler und Softwareausfälle beheben kann.
Der Dienst bietet keinen Schutz vor regionalen oder Dual-Zonen-Ausfällen. Für Anwendungen, die dieses Schutzniveau erfordern, empfehlen wir die Ausführung von zwei separaten regionalen Clustern. 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 bietet eine vollständige Reihe von Tools für Ihren Stil der Clusterverwaltung und Fehlerbehebung. Dazu gehören Tools für Verwaltung, Monitoring und Logging.
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 Google Cloud Konsole 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.
Für Monitoring und Fehlerbehebung exportiert der Dienst Messwerte nach Cloud Monitoring. Einige der Messwerte sind in der Dienst-UI verfügbar. Eine vollständige Reihe ist in Cloud Monitoring für die interaktive Arbeit, das Konfigurieren von Benachrichtigungen und den Export in andere Systeme verfügbar.
Der Dienst exportiert außerdem Brokerlogs nach Cloud Logging. Diese 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 automatisch kritische Sicherheitslücken.
Updates der zugrunde liegenden Infrastruktur, einschließlich des Betriebssystems und der Orchestrierungsebenen, erfolgen kontinuierlich und automatisch. Broker werden mit einem Rolling Restart aktualisiert, ohne dass es zu Ausfallzeiten für den Cluster kommt.
Der Dienst führt kein automatisches Upgrade des Apache Kafka-Codes, der auf den Brokern ausgeführt wird, auf neue Nebenversionen durch.
Transparente Kosten
Das Preismodell für Managed Service for Apache Kafka ähnelt den Gebühren, die anfallen wenn Sie Apache Kafka selbst auf 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). Nichtflüchtiger Speicher und vCPU kosten mit Managed Service for Apache Kafka mehr als wenn Sie ein ähnliches System selbst einrichten. Im Gegensatz dazu sind die Preise für Datenübertragung und lokalen Speicher zwischen Managed Service for Apache Kafka und selbstverwaltetem Kafka ähnlich. Weitere Informationen zu den Preisen finden Sie unter Preise für Managed Service for Apache Kafka.
Kompatibel, da wir Apache Kafka ausführen
Managed Service for Apache Kafka führt dieselbe Open-Source-Software aus, 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
zstdwird nicht unterstützt. Unterstützte Werte fürcompression.typesindlz4,gzip,snappyunduncompressed.Sie können Brokerkonfigurationen zwar jederzeit mit dem Aktualisierungsmodus
read-onlyändern, diese Änderungen werden jedoch erst wirksam, wenn die Broker neu gestartet werden. Neustarts erfolgen regelmäßig im Rahmen der Wartungs- und Upgrade-Prozesse von Google. Es gibt jedoch keinen festen Zeitplan und keine Möglichkeit, sie manuell auszulösen. Daher können Sie nicht steuern, wann diese Änderungen wirksam werden. Beispiele fürread-only-Konfigurationen sindauto.create.topics.enableundbackground.threads. Für Updates von Konfigurationen mit dem Aktualisierungsmoduscluster-wide, z. B.message.max.bytes, sind keine Neustarts erforderlich und sie werden sofort wirksam.Einige Brokerkonfigurationsparameter werden vom Dienst verwaltet und können nicht aktualisiert werden. Dazu gehören
broker.idund speicherbezogene Einstellungen wieremote.log.storage.system.enable.
Nächste Schritte
- Managed Service for Apache Kafka-Cluster erstellen.
- Nachrichten mit einem Managed Service for Apache Kafka-Cluster senden und empfangen.
- Beschränkungen von Managed Service for Apache Kafka ansehen
- Informationen zu den Preisen für Managed Service for Apache Kafka