Cloud Dataflow zum Verarbeiten extern gehosteter Nachrichten von Kafka verwenden

In diesem Artikel werden wichtige netzwerkbezogene Probleme behandelt, die bei der Verwendung von Dataflow und KafkaIO zur Verarbeitung von Nachrichten zu berücksichtigen sind. Kafka befindet sich in diesem Fall außerhalb von Google Cloud. Sie verarbeiten die Nachrichten jedoch mit Dataflow innerhalb von Google Cloud. Seit dem Release der Kafka Apache Beam-Transformation können Sie Nachrichten von Kafka mit den leistungsstarken Lösungen Apache Beam und Dataflow verarbeiten. Die folgende Abbildung zeigt ein beliebtes Szenario: Sie verwenden Dataflow zur Verarbeitung der Nachrichten, wobei Kafka entweder lokal oder in einer anderen öffentlichen Cloud wie Amazon Web Services (AWS) gehostet wird.

Diagramm: Kafka-Nachrichten außerhalb von Google Cloud verarbeiten

Netzwerktopologie

Sie haben verschiedene Konnektivitätsoptionen, um Ressourcen in Google Cloud mit Ressourcen außerhalb von Google Cloud zu verknüpfen.

In Google Cloud ist Dedicated Interconnect die beste Option für eine vorhersagbare Leistung und Zuverlässigkeit. Die Einrichtung kann jedoch länger dauern, da die neuen Verbindungen durch Dritte bereitgestellt werden müssen. Wenn Sie eine VPN-basierte Topologie verwenden, sollten Sie ein VPN mit hohem Durchsatz erstellen. Sowohl Dedicated Interconnect als auch IPsec-VPN bieten Ihnen direkten Zugriff auf RFC 1918-IP-Adressen in Ihrer Virtual Private Cloud (VPC), was Ihre Kafka-Konfiguration vereinfachen kann. Mit einer Topologie auf Basis einer öffentlichen IP-Adresse können Sie schnell starten, da nur wenig Netzwerkarbeit erforderlich ist.

In beiden Topologien empfiehlt es sich, die Konnektivität zu prüfen. Senden und lesen Sie Nachrichten hierfür von einem Kafka-Client auf einer separaten Compute Engine-Instanz im selben Subnetzwerk, in dem sich auch Ihre Dataflow-Instanzen befinden.

Eine weitere wichtige Überlegung für Streamverarbeitungs-Arbeitslasten betrifft die Latenz. Wählen Sie eine Google Cloud-Region für Ihre Dataflow-Bereitstellung in der Nähe Ihres Kafka-Clusters aus. Tipps zum Optimieren der Netzwerkleistung erhalten Sie im Blog 5 steps to better GCP network performance.

Freigegebener RFC 1918-Adressraum

In diesem Abschnitt wird die im folgenden Diagramm dargestellte Netzwerktopologie erläutert.

Diagramm: Freigegebener RFC 1918-Adressraum

Dataflow-Subnetzwerk angeben

Normalerweise startet Dataflow Instanzen in Ihrem standardmäßigen VPC-Netzwerk. Dies funktioniert, wenn Sie den extern gehosteten Kafka-Cluster über öffentliche IP-Adressen erreichen können. In einer privaten Netzwerktopologie mit explizit in Cloud Router definierten Routen, die Subnetzwerke in Google Cloud mit diesem Kafka-Cluster verbinden, müssen Sie die Standorte Ihrer Dataflow-Instanzen besser steuern können. Sie können mit Dataflow die Ausführungsparameter network und subnetwork wie in diesem Codebeispiel gezeigt konfigurieren:

mvn compile exec:java \
    -Dexec.mainClass=your-pipeline-java-class \
    -Dexec.args="--project=your-gcp-project
    --network=your-dataflow-network \
    --subnetwork=your-dataflow-subnet \
    --runner=DataflowRunner"

Achten Sie darauf, dass das entsprechende Subnetzwerk über genügend IP-Adressen verfügt, damit Dataflow Instanzen beim horizontalen Skalieren starten kann. Wenn Sie zum Starten der Dataflow-Instanzen ein separates Netzwerk erstellen, ist außerdem wichtig, dass Sie eine Firewallregel haben, die TCP-Traffic zwischen allen virtuellen Maschinen im Projekt zulässt. Im Standardnetzwerk ist diese Firewallregel bereits konfiguriert.

Kommunikation zwischen Dataflow und Kafka

Konfigurieren Sie Kafka wie gewohnt in einer privaten Netzwerktopologie und folgen Sie den Best Practices für Verfügbarkeit, Sicherheit und Langlebigkeit.

Öffentlicher IP-Adressraum

Das folgende Diagramm zeigt eine Beispielarchitektur für das sichere Hosting eines Clusters von drei Kafka-Brokern, auf die Sie über das öffentliche Internet zugreifen können.

Diagramm: Öffentlicher IP-Adressraum

Dataflow-Konfiguration

Da der Traffic über das öffentliche Internet erfolgt, müssen Sie kein Netzwerk und kein Subnetzwerk konfigurieren. Bei einer privaten Netzwerktopologie können Sie jedoch das Netzwerk und das Subnetzwerk angeben, solange eine Route vom Dataflow-Netzwerk zu den öffentlichen IP-Adressen des entsprechenden Kafka-Clusters vorhanden ist.

Kafka-Konfiguration

Die Architektur im vorherigen Diagramm nutzt die Terminologie der Standardkonvention in Kafka-Dokumentation und -Konfiguration (Secure Sockets Layer, SSL), aber die Architektur verwendet tatsächlich Transport Layer Security (TLS), um den Traffic zwischen externen Clients und Kafka zu sichern, und Klartext für die Kommunikation zwischen den Brokern. Wenn sich der Kafka-Listener an eine Netzwerkschnittstelle bindet, die sowohl für die interne als auch für die externe Kommunikation verwendet wird, ist die Konfiguration des Listeners unkompliziert. In vielen Szenarien, beispielsweise bei der Bereitstellung auf AWS, unterscheiden sich jedoch die extern veröffentlichten Adressen der Kafka-Broker im Cluster von den internen Netzwerkschnittstellen, die Kafka verwendet. In solchen Fällen können Sie das advertised.listeners-Attribut verwenden, das in diesem Beispiel-Snippet von server.properties angezeigt wird:

# Configure protocol map
listener.security.protocol.map=INTERNAL:PLAINTEXT,EXTERNAL:SSL
# Use plaintext for inter-broker communication inter.broker.listener.name=INTERNAL
# Specify that Kafka listeners should bind to all local interfaces listeners=INTERNAL://0.0.0.0:9092,EXTERNAL://0.0.0.0:9093
# Separately, specify externally visible address advertised.listeners=INTERNAL://kafkabroker-n.mydomain.com:9092,EXTERNAL://kafkabroker-n.mydomain.com:9093

In dieser Konfiguration stellen externe Clients eine Verbindung über Port 9093 über einen "SSL"-Kanal her und interne Clients verbinden sich über einen Klartextkanal über Port 9092. Wenn Sie unter advertised.listeners eine Adresse angeben, verwenden Sie DNS-Namen (in diesem Beispiel kafkabroker-n.mydomain.com), die für externen und internen Traffic in dieselbe Instanz aufgelöst werden. Öffentliche IP-Adressen funktionieren eventuell nicht, da die Adressen möglicherweise für den internen Traffic nicht richtig aufgelöst werden.

Weitere Informationen