Dieses Dokument ist nützlich, wenn Sie die Migration von selbstverwaltetem Apache Kafka zu Pub/Sub in Betracht ziehen, da es Ihnen helfen kann, Funktionen, Preise und Anwendungsfälle zu prüfen und zu berücksichtigen. In jedem Abschnitt wird ein häufiger Kafka-Anwendungsfall beschrieben und es wird eine praktische Anleitung gegeben, wie Sie dieselben Funktionen in Pub/Sub erreichen können.
Übersicht über Pub/Sub
Pub/Sub ist ein asynchroner Nachrichtendienst. Pub/Sub entkoppelt Dienste, die Ereignisse von Diensten erzeugen, die Ereignisse verarbeiten. Sie können Pub/Sub als nachrichtenorientierte Middleware oder Ereignisaufnahme und -übermittlung für Streaminganalyse-Pipelines verwenden. In beiden Szenarien erstellt und sendet eine Publisher-Anwendung Nachrichten zu einem Thema. Abonnentenanwendungen erstellen ein Abo zu einem Thema, um Nachrichten von ihm zu erhalten. Ein Abo ist eine benannte Entität, die für das Interesse an Nachrichten zu einem bestimmten Thema steht.
Pub/Sub wird in allen Google Cloud-Regionen ausgeführt. Pub/Sub leitet den Publisher-Traffic an das nächste Google Cloud-Rechenzentrum weiter, in dem die Datenspeicherung zulässig ist, wie in der Richtlinie zur Ressourcenstandortbeschränkung definiert.
Pub/Sub kann in viele Google Cloud-Dienste eingebunden werden, z. B. Dataflow, Cloud Storage und Cloud Run. Sie können diese Dienste so konfigurieren, dass sie als Datenquellen dienen, die Nachrichten in Pub/Sub veröffentlichen oder als Datensenken, die Nachrichten aus Pub/Sub empfangen.
Übersicht über Kafka
Apache Kafka ist eine verteilte Open Source Ereignisstreaming-Plattform und ermöglicht es Anwendungen, Ereignis-Streams zu veröffentlichen, zu abonnieren, zu speichern und zu verarbeiten. Der Kafka-Server wird als Cluster von Maschinen ausgeführt, mit denen Clientanwendungen Lese-, Schreib- und Verarbeitungsereignisse ausführen. Mit Kafka können Sie Anwendungen entkoppeln, Nachrichten senden und empfangen, Aktivitäten verfolgen, Logdaten zusammenfassen und Streams verarbeiten.
Innerhalb des Kafka-Clusters werden einige Knoten im Cluster als Broker festgelegt. Broker erhalten Nachrichten von Produzenten und speichern sie auf der Festplatte. Gespeicherte Nachrichten werden nach Thema organisiert und über verschiedene Broker im Cluster partitioniert. Neue in einem Thema veröffentlichte Ereignisse werden an das Ende einer Partition des Themas angehängt. Nutzer können dann Nachrichten von Brokern abrufen, die von der Festplatte gelesen und an den Nutzer gesendet werden.
Unterschiede zwischen Kafka und Pub/Sub
Das folgende Diagramm zeigt die Unterschiede der Skalierungsstrategie zwischen Kafka und Pub/Sub:
Im obigen Diagramm stellt jedes M eine Nachricht dar. Die Broker von Kafka verwalten mehrere geordnete Partitionen von Nachrichten, die durch die horizontalen Zeilen mit den Nachrichten dargestellt sind. Nutzer lesen die Nachrichten aus einer bestimmten Partition, deren Kapazität auf dem Computer basiert, auf dem diese Partition gehostet wird. Pub/Sub hat keine Partitionen und Nutzer lesen stattdessen ein Thema, das sich je nach Bedarf automatisch skaliert. Sie konfigurieren jedes Kafka-Thema mit der Anzahl der Partitionen, die Sie für die erwartete Last benötigen. Pub/Sub wird automatisch nach Bedarf skaliert.
Die Funktionen im Vergleich
In der folgenden Tabelle werden Features von Apache Kafka mit Pub/Sub-Features verglichen:
| Apache Kafka | Pub/Sub | |
|---|---|---|
| Nachrichtenreihenfolge | Ja innerhalb von Partitionen | Ja innerhalb von Themen |
| Nachrichten deduplizieren | Ja | Ja mit Dataflow |
| Push-Abos | Nein | Ja |
| Warteschlange für unzustellbare Nachrichten (Warteschlange für nicht verarbeitbare Nachrichten) |
Ab Version 2.0 | Ja |
| Transaktionen | Ja | Nein |
| Nachrichtenspeicher | Nur durch verfügbaren Maschinenspeicher begrenzt | 31 Tage: Ein Thema kann veröffentlichte Nachrichten, einschließlich bestätigter Nachrichten, maximal 31 Tage lang aufbewahren. Dies kann über die Property `message_retention_duration` des Themas konfiguriert werden. |
| Nachricht noch einmal abspielen | Ja | Ja |
| Ort | Lokaler Cluster kann mit MirrorMaker repliziert werden | Globaler verteilter Dienst mit konfigurierbaren Speicherorten für Nachrichten |
| Logging und Monitoring | Selbstverwaltet | Automatisiert mit Cloud Logging und Cloud Monitoring |
| Streamverarbeitung | Ja mit KSQL | Ja mit Dataflow |
Pub/Sub-Nachrichtenspeicher und -wiedergabe
Standardmäßig speichert Pub/Sub unbestätigte Nachrichten bis zu 7 Tage lang. Sie können Pub/Sub-Abos jedoch so konfigurieren, dass bestätigte Nachrichten im Abo bis zu sieben Tage lang aufbewahrt werden, je nach Alter der ältesten Nachricht (bestätigt oder nicht bestätigt). Durch die Aufbewahrung bestätigter Nachrichten können Sie einige oder alle Nachrichten basierend auf einem Zeitstempel noch einmal wiedergeben. Wenn Sie Nachrichten basierend auf einem Zeitstempel wiedergeben, werden alle Nachrichten, die nach dem Zeitstempel empfangen wurden, als nicht bestätigt markiert. Die nicht bestätigten Nachrichten werden dann noch einmal gesendet.
Sie können nach Bedarf Snapshots einzelner Abos erstellen, ohne Ihr Abo vorab konfigurieren zu müssen. Sie können beispielsweise einen Snapshot erstellen, wenn Sie einen neuen Abonnentencode bereitstellen, da Sie diesen möglicherweise wiederherstellen müssen, wenn unerwartete Ereignisse oder fehlerhaften Bestätigungen auftreten.
Integrierte Ausfallsicherheit mit Themen für unzustellbare Nachrichten
Pub/Sub bietet ähnliche Funktionen wie die Fehlerbehandlung in Kafka 2.0 und die Verarbeitung von Themen für unzustellbare Nachrichten in Kafka Connect. Damit Pub/Sub benachrichtigt wird, dass eine Nachricht erfolgreich zugestellt wurde, können Abonnenten von Pub/Sub-Themen Nachrichten bestätigen, die sie empfangen und verarbeiten. Wenn Ihre Abonnenten Nachrichten eine Zeit lang nicht verarbeiten können, kann Pub/Sub diese Nachrichten automatisch an ein Thema für unzustellbare Nachrichten weiterleiten und für später speichern. Sie können die Anzahl der Versuche konfigurieren, die Pub/Sub zur Nachrichtenübermittlung unternimmt, bevor Pub/Sub die Nachricht an das Thema für unzustellbare Nachrichten sendet.
Deduplizieren von Nachrichten in Pub/Sub mit Dataflow
Pub/Sub stellt jede veröffentlichte Nachricht pro Abo mindestens einmal zu. Im Allgemeinen erfordert eine mehrmalige Zustellung, dass der Abonnent bei der Verarbeitung von Nachrichten idempotent ist. Wenn Ihre vorhandenen Abonnenten nicht idempotent ausgeführt werden können, können Sie Dataflow einbinden, um Nachrichten zu deduplizieren. Wenn Ihre Abonnenten viele doppelte Nachrichten erhalten, kann dies darauf hindeuten, dass sie Nachrichten nicht ordnungsgemäß bestätigen können oder dass die Bestätigungsfrist zu kurz ist.
Nachrichtenreihenfolge in Pub/Sub
Wenn Ihre Kafka-Abonnentenanwendungen auf die Nachrichtenreihenfolge angewiesen sind, können Sie diese Anforderung in Pub/Sub unterstützen, wenn Sie Sortierschlüssel verwenden. Derzeit ist die Reihenfolge für Nachrichten garantiert, die in einer bestimmten Region veröffentlicht werden. Damit Sie die Vorteile der Nachrichtenreihenfolge nutzen können, müssen Ihre Publisher und Abonnenten Standortendpunkte verwenden, um Ihre Nachrichten an die richtige Region weiterzuleiten.
Verantwortungsbereiche des selbst gehosteten und des verwalteten Dienstes
In der folgenden Tabelle wird verglichen, welche Funktion mit Kafka selbst gehostet wird und welche Funktion von Google mit Pub/Sub verwaltet wird:
| Apache Kafka | Pub/Sub | |
|---|---|---|
| Verfügbarkeit | Kafka an weiteren Standorten manuell bereitstellen | Wird in allen Google Cloud-Regionen für Hochverfügbarkeit und niedrige Latenz bereitgestellt |
| Notfallwiederherstellung | Eigene Sicherung und Replikation entwerfen und verwalten | Von Google verwaltet |
| Infrastrukturverwaltung | Virtuelle Maschinen (VMs) oder Maschinen manuell bereitstellen und betreiben. Sie müssen eine konsistente Versionierung und Patches beibehalten. | Von Google verwaltet |
| Kapazitätsplanung | Speicher- und Rechenanforderungen im Voraus manuell planen | Von Google verwaltet |
| Support | Keine | Rund um die Uhr verfügbare Mitarbeiter und Support |
Pub/Sub-Größenbeschränkungen und Problemumgehungen
Kafka und Pub/Sub bieten eine gute Leistung bei der Verarbeitung großer Mengen kleiner Nachrichten. Kafka hat keine feste Obergrenze für die Nachrichtengröße und ermöglicht die Konfiguration der erlaubten Nachrichtengröße. Pub/Sub begrenzt Nachrichten auf 10 MB. Sie können größere Nutzlasten indirekt senden, indem Sie zuerst das Objekt in Cloud Storage speichern, wie im folgenden Diagramm dargestellt:
Die vorherige Abbildung zeigt: Wenn der Publisher das Objekt in Cloud Storage speichert, veröffentlicht er eine Nachricht mit der URL für dieses gespeicherte Objekt. Wenn der Abonnent die Nachricht mit der URL empfängt, lädt er die Datei aus Cloud Storage herunter und setzt die Verarbeitung wie gewohnt fort.
Kosten von Kafka und Pub/Sub vergleichen
Die Kosten für die Schätzung und Verwaltung der Kosten in Pub/Sub unterscheiden sich von den Kosten in Kafka. Die Kosten für einen lokalen oder in der Cloud vorhandenen Kafka-Cluster umfassen die Kosten für Maschinen, Laufwerke, Netzwerke, eingehende und ausgehende Nachrichten sowie die Gemeinkosten für die Verwaltung und Wartung dieser Systeme und der zugehörigen Infrastruktur. Bei der Verwaltung eines Kafka-Clusters müssen Maschinen häufig manuell aktualisiert und gepatcht werden. Die Clusterkapazität muss häufig geplant werden. Die Implementierung der Notfallwiederherstellung umfasst eine umfassende Planung und Tests. Sie müssen alle diese verschiedenen Kosten ableiten und zusammenfassen, um Ihre tatsächlichen Gesamtbetriebskosten (TCO) zu ermitteln.
Pub/Sub-Preise umfassen die Datenübertragung von Publishern und Abonnenten sowie die Kosten für die vorübergehende Speicherung nicht bestätigter Nachrichten. Sie zahlen nur für die Ressourcen, die Sie verbrauchen, und ihre Kapazitäten werden automatisch entsprechend den Anforderungen Ihrer Anwendung und des Budgets angepasst.
Architektur der Zuverlässigkeit
Pub/Sub ist ein global verwalteter Dienst, der in allen Google Cloud-Regionen ausgeführt wird. Pub/Sub-Themen sind global, d. h. sie sind von jedem Google Cloud-Standort aus sichtbar und zugänglich. Jede Nachricht wird jedoch in einer einzelnen Google Cloud-Region gespeichert, die dem Publisher am nächsten liegt und von der Richtlinie für Ressourcenstandorte zugelassen ist. Bei einem Thema können Nachrichten also in verschiedenen Regionen innerhalb von Google Cloud gespeichert sein. Pub/Sub ist gegen zonale Ausfälle geschützt. Während eines regionalen Ausfalls können Nachrichten, die in dieser Region gespeichert werden, möglicherweise nicht zugänglich sein, bis der Dienst wiederhergestellt ist. Abhängig von Ihren Verfügbarkeitsanforderungen können Sie bei einem regionalen Ausfall mithilfe von Standortdienstendpunkten eine Failover-Richtlinie implementieren.
Sicherheit und Authentifizierung
Apache Kafka unterstützt mehrere Authentifizierungsmechanismen, darunter eine Authentifizierung auf Basis von Clientzertifikaten, Kerberos, LDAP sowie Nutzername und Passwort. Zur Autorisierung unterstützt Kafka die Verwendung von ACLs (Access Control Lists), um festzulegen, welche Produzenten und Nutzer Zugriff auf welche Themen haben.
Pub/Sub unterstützt die Authentifizierung für Google Cloud-Nutzerkonten und -Dienstkonten. Die detaillierte Zugriffssteuerung auf Pub/Sub-Themen und -Abos wird in Google Cloud (Identity and Access Management, IAM) gesteuert. Pub/Sub-Vorgänge sind ratenbegrenzt, wenn Sie Nutzerkonten verwenden. Wenn Sie Transaktionen mit hohem Volumen durchführen müssen, können Sie Dienstkonten für die Interaktion mit Pub/Sub verwenden.
Migration zu Pub/Sub planen
Bei jeder Migration zu Google Cloud beginnen wir damit, die Arbeitslasten zu bewerten und Ihre Grundlagen zu entwickeln.
Phasenweise Migration mit dem Pub/Sub-Kafka-Connector
Mit dem Pub/Sub Kafka-Connector können Sie Ihre Kafka-Infrastruktur phasenweise zu Pub/Sub migrieren.
Sie können den Pub/Sub-Connector so konfigurieren, dass alle Nachrichten zu bestimmten Themen von Kafka an Pub/Sub weitergeleitet werden. Anschließend können Sie einzelne Abonnentenanwendungen aktualisieren, damit Nachrichten zu diesen Themen von Pub/Sub empfangen werden, während Ihre Publisher-Anwendungen weiterhin Nachrichten in Kafka veröffentlichen. Mit diesem stufenweisen Ansatz können Sie Abonnentenanwendungen iterativ aktualisieren und testen und überwachen, um das Risiko von Fehlern und Ausfallzeiten zu minimieren.
Dieser Abschnitt enthält zwei Diagramme, mit denen Sie diesen Prozess in zwei verschiedenen Phasen visualisieren können. Das folgende Diagramm zeigt die Konfiguration während der Migrationsphase:
Im obigen Diagramm empfangen aktuelle Abonnenten weiterhin Nachrichten von Kafka und Sie aktualisieren die Abonnenten nacheinander, um Nachrichten von Pub/Sub zu erhalten.
Nachdem alle Abonnenten eines bestimmten Themas aktualisiert wurden, um Nachrichten von Pub/Sub zu empfangen, können Sie die Publisher-Anwendungen für dieses Thema aktualisieren, um Nachrichten in Pub/Sub zu veröffentlichen. Anschließend können Sie den Nachrichtenfluss durchgängig prüfen, um die Einrichtung zu prüfen.
Das folgende Diagramm zeigt die Konfiguration, nachdem alle Abonnenten Nachrichten von Pub/Sub empfangen haben:
Im Laufe der Zeit werden alle Ihre Publisher aktualisiert, um sie direkt in Pub/Sub zu veröffentlichen. Anschließend ist die Migration abgeschlossen. Viele Teams verwenden diesen Ansatz, um ihre Anwendungen parallel zu aktualisieren. Kafka kann so lange wie nötig neben Pub/Sub koexistieren, um eine erfolgreiche Migration zu gewährleisten.
Pub/Sub überwachen
Während und nach der Migration von Kafka zu Pub/Sub ist es wichtig, Ihre Anwendungen zu überwachen. Pub/Sub exportiert Messwerte mithilfe von Cloud Monitoring, um Einblicke in die Leistung, Betriebszeit und reibungslose Funktion Ihrer Anwendungen zu ermöglichen. Sie können beispielsweise dafür sorgen, dass Ihre Abonnenten mit dem Nachrichtenfluss Schritt halten, indem Sie die Anzahl nicht zugestellter Nachrichten überwachen. Um nicht zugestellte Nachrichten zu überwachen, erstellen Sie Warnungen, wenn der Zeitstempel der ältesten nicht bestätigten Nachricht einen bestimmten Grenzwert überschreitet. Sie können den Zustand des Pub/Sub-Dienstes auch dadurch selbst überwachen, dass Sie den Messwert "Anzahl der Sendeanfragen" überwachen und die Antwortcodes untersuchen.
Nächste Schritte
- Streamanalysen mit Pub/Sub.
- Pub/Sub API-Referenz.
- Pub/Sub Monitoring-Dokumentation.
- Architektur der Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center