Utilizzo di Cloud Dataflow per elaborare messaggi esterni ospitati da Kafka

Questo articolo illustra i problemi principali relativi al networking da tenere in considerazione quando si utilizzano Dataflow e KafkaIO per elaborare i messaggi. In questo caso, Kafka è al di fuori di Google Cloud, ma utilizzi Dataflow per elaborare i messaggi all'interno di Google Cloud. Con il rilascio della trasformazione di Kafka Apache Beam, puoi utilizzare la potenza di Apache Beam e Dataflow per elaborare i messaggi di Kafka. La figura seguente illustra uno scenario popolare: utilizzi Dataflow per elaborare i messaggi, in cui Kafka è ospitato on-premise o in un altro cloud pubblico come Amazon Web Services (AWS).

Elaborazione dei messaggi Kafka al di fuori di Google Cloud

Topologia di rete

Hai a disposizione diverse opzioni di connettività per collegare le risorse su Google Cloud con risorse esterne a Google Cloud.

Su Google Cloud, Dedicated Interconnect è l'opzione migliore per prestazioni e affidabilità prevedibili, ma può richiedere più tempo perché le terze parti devono eseguire il provisioning dei nuovi circuiti. Se utilizzi una topologia basata su VPN, ti consigliamo di configurare una VPN ad alta velocità effettiva. Sia Dedicated Interconnect che IPsec VPN ti danno accesso diretto agli indirizzi IP RFC 1918 nel tuo cloud privato virtuale (VPC), permettendo di semplificare la configurazione di Kafka. Con una topologia basata su IP pubblico, puoi iniziare rapidamente perché è necessario svolgere poco lavoro di networking.

In entrambe le topologie, è consigliabile convalidare la connettività inviando e leggendo i messaggi da un client Kafka su un'istanza Compute Engine separata nella stessa sottorete delle istanze Dataflow.

La latenza è anche un aspetto importante per i carichi di lavoro di elaborazione dei flussi. Scegli un'area geografica di Google Cloud per il tuo deployment Dataflow nelle vicinanze del tuo cluster Kafka. Per suggerimenti su come ottimizzare le prestazioni della rete, consulta 5 passaggi per migliorare le prestazioni della rete Google Cloud.

Spazio di indirizzi RFC 1918 condiviso

Questa sezione illustra la topologia di rete mostrata nel diagramma seguente.

Spazio di indirizzi RFC 1918 condiviso

Specifica di una subnet Dataflow

Per impostazione predefinita, Dataflow avvia le istanze nella tua rete VPC predefinita, che funziona se puoi raggiungere il tuo cluster Kafka ospitato esternamente tramite indirizzi IP pubblici. In una topologia di rete privata con route definiti esplicitamente nel router Cloud, che collegano le subnet in Google Cloud a quel cluster Kafka, hai bisogno di un maggiore controllo sulla posizione delle istanze Dataflow. Puoi utilizzare Dataflow per configurare i parametri di esecuzione network e subnetwork, come mostrato in questo esempio di codice:

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"

Assicurati che la subnet corrispondente disponga di indirizzi IP sufficienti per consentire a Dataflow di avviare le istanze mentre tenta di fare lo scale out. Inoltre, quando crei una rete separata per avviare le istanze di Dataflow, assicurati di avere una regola firewall che consenta il traffico TCP tra tutte le macchine virtuali del progetto. Questa regola firewall è già configurata nella rete predefinita.

Comunicazione tra Dataflow e Kafka

In una topologia di rete privata, configura Kafka come faresti normalmente e segui le best practice per disponibilità, sicurezza e durabilità.

Spazio indirizzo IP pubblico

Il seguente diagramma mostra un'architettura di esempio per l'hosting sicuro di un cluster di tre broker Kafka a cui puoi accedere tramite la rete Internet pubblica.

Spazio indirizzo IP pubblico

Configurazione Dataflow

Poiché il traffico passa attraverso la rete Internet pubblica, non è necessario configurare una rete e una subnet. Tuttavia, nel caso di una topologia di rete privata, puoi specificare la rete e la subnet, a condizione che esista una route dalla rete Dataflow agli indirizzi IP pubblici del cluster Kafka corrispondente.

Configurazione Kafka

L'architettura mostrata nel diagramma precedente utilizza la terminologia delle convenzioni standard nella documentazione e nella configurazione di Kafka (Secure Sockets Layer (SSL), ma in realtà utilizza Transport Layer Security (TLS), per proteggere il traffico tra client esterni e Kafka e utilizza testo non crittografato per le comunicazioni tra intermediari. Quando il listener Kafka si collega a un'interfaccia di rete utilizzata per le comunicazioni sia interne sia esterne, la configurazione del listener è semplice. Tuttavia, in molti scenari, ad esempio durante il deployment su AWS, gli indirizzi dei intermediari Kafka pubblicizzati nel cluster sono diversi dalle interfacce di rete interne utilizzate da Kafka. In questi scenari, puoi utilizzare la proprietà advertised.listeners mostrata in questo snippet server.properties di esempio:

# 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 questa configurazione, i client esterni si connettono utilizzando la porta 9093 tramite un canale "SSL e i client interni si connettono utilizzando la porta 9092 attraverso un canale di testo non criptato. Quando specifichi un indirizzo in advertised.listeners, utilizza i nomi DNS (kafkabroker-n.mydomain.com, in questo esempio) che risolvono la stessa istanza sia per il traffico esterno che per quello interno. L'uso di indirizzi IP pubblici potrebbe non funzionare perché gli indirizzi potrebbero non riuscire per risolvere il traffico interno.

Passaggi successivi