Pianifica la tua pipeline Dataflow

Questa pagina spiega importanti considerazioni per pianificare la pipeline di dati prima di iniziare lo sviluppo del codice. Data pipelines spostano i dati da un sistema all'altro e sono spesso componenti critici dei sistemi informativi aziendali. Le prestazioni e l'affidabilità della pipeline di dati possono influire su questi sistemi più ampi e sull'efficacia con cui vengono soddisfatti i requisiti aziendali.

Se pianifichi le pipeline di dati prima di svilupparle, puoi migliorarne le prestazioni e l'affidabilità. Questa pagina spiega varie considerazioni sulla pianificazione per le pipeline Dataflow, tra cui:

• Aspettative relative alle prestazioni delle pipeline, inclusi gli standard di misurabilità
• Integrazione delle pipeline con origini dati, sink e altri sistemi connessi
• Regionalizzazione di pipeline, origini e sink
• Sicurezza, come la crittografia dei dati e il networking privato

Definire e misurare gli SLO

Una misura importante delle prestazioni è il livello di efficacia della pipeline di soddisfare i requisiti aziendali. Gli obiettivi del livello di servizio (SLO) forniscono definizioni tangibili delle prestazioni che puoi confrontare con le soglie accettabili. Ad esempio, puoi definire i seguenti SLO di esempio per il tuo sistema:

• Aggiornamento dei dati: genera il 90% dei suggerimenti sui prodotti in base all'attività sul sito web dell'utente che si è verificata non oltre 3 minuti fa.

• Correttezza dei dati: in un mese di calendario, meno dello 0,5% delle fatture dei clienti contiene errori.

• Isolamento dei dati/bilanciamento del carico: entro un giorno lavorativo, elabora tutti i pagamenti con priorità elevata entro 10 minuti dalla presentazione e completa i pagamenti con priorità standard entro il giorno lavorativo successivo.

Puoi utilizzare gli indicatori del livello del servizio (SLI) per misurare la conformità degli SLO. Gli SLI sono metriche quantificabili che indicano in che misura il tuo sistema soddisfa un determinato SLO. Ad esempio, puoi misurare lo SLO di aggiornamento dei dati di esempio utilizzando come SLI l'età dell'attività utente elaborata più di recente. Se la pipeline genera suggerimenti da eventi di attività utente e se lo SLI segnala un ritardo di 4 minuti tra l'ora dell'evento e quella in cui viene elaborato, i suggerimenti non prendono in considerazione l'attività sul sito web di un utente risalente a prima di 4 minuti. Se una pipeline che elabora flussi di dati supera una latenza di sistema di 4 minuti, sai che lo SLO non è soddisfatto.

Poiché i componenti del sistema al di fuori della pipeline influiscono sullo SLO, è importante acquisire una serie di SLI che descrivono le prestazioni complessive del sistema al di là delle prestazioni della pipeline stessa, incluse le metriche che descrivono l'integrità end-to-end del tuo sistema. Ad esempio, la pipeline Dataflow potrebbe calcolare i risultati con un ritardo accettabile, ma potrebbe verificarsi un problema di prestazioni con un sistema downstream che influisce su SLO più ampi.

Per ulteriori informazioni sugli SLO importanti da considerare, consulta il libro Site Reliability Engineering.

Aggiornamento dei dati

L'aggiornamento dei dati si riferisce all'usabilità dei dati in relazione alla loro età. I seguenti SLO di aggiornamento dei dati sono menzionati nel libro Site Reliability Engineering come sLO di aggiornamento dei dati della pipeline più comuni:

• X% dei dati elaborati in Y [secondi, giorni, minuti]. Questo SLO si riferisce alla percentuale di dati elaborati in un determinato periodo di tempo. È comune utilizzato per le pipeline batch che elaborano origini dati limitate. Le metriche per questo tipo di SLO sono le dimensioni dei dati di input e di output nelle fasi di elaborazione chiave rispetto al runtime della pipeline trascorso. Puoi scegliere un passaggio che legge un set di dati di input e un altro passaggio per l'elaborazione di ogni elemento dell'input. Un esempio di SLO è "Per il gioco Shave the Yak, il 99% delle attività degli utenti che influiscono sui punteggi dei giocatori viene conteggiato entro 30 minuti dal completamento della partita".

• I dati meno recenti non risalgono a più di X [secondi, giorni, minuti]. Questo SLO si riferisce all'età dei dati prodotti dalla pipeline. Di solito viene utilizzato per le pipeline in modalità flusso che elaborano dati da origini illimitate. Per questo tipo di SLO, utilizza le metriche che indicano il tempo necessario alla pipeline per elaborare i dati. Due possibili metriche sono la data dell'elemento non elaborato meno recente, ovvero la durata della permanenza di un elemento non elaborato nella coda o l'età dell'elemento elaborato più di recente. Un esempio di SLO è "I suggerimenti sui prodotti vengono generati da un'attività utente non precedente a 5 minuti".

• Il job della pipeline viene completato correttamente entro X [seconds, days, minutes]. Questo SLO imposta una scadenza per il completamento corretto ed è comune utilizzato per le pipeline batch che elaborano i dati da origini delimitate. Questo SLO richiede il tempo totale trascorso dalla pipeline e lo stato di completamento del job, oltre ad altri indicatori che indicano l'esito positivo del job, come la percentuale di elementi elaborati che generano errori. Un esempio di SLO è "Gli ordini dei clienti nel giorno lavorativo in corso vengono elaborati entro le 09:00 del giorno successivo".

Per informazioni sull'utilizzo di Cloud Monitoring per misurare l'aggiornamento dei dati, consulta Metriche dei job di Dataflow.

Correttezza dei dati

Per correttezza dei dati si intende che i dati sono privi di errori. Puoi determinare la correttezza dei dati in diversi modi, tra cui:

• Test delle unità e test di integrazione, che puoi automatizzare utilizzando l'integrazione continua.

• Test end-to-end della pipeline, che puoi eseguire in un ambiente di preproduzione dopo che la pipeline ha superato i test delle unità e di integrazione. Puoi automatizzare i test della pipeline end-to-end utilizzando la distribuzione continua.

• Pipeline in esecuzione in produzione, quando utilizzi il monitoring per osservare le metriche relative alla correttezza dei dati.

Per le pipeline in esecuzione, la definizione di un target di correttezza dei dati di solito comporta la misurazione della correttezza in un determinato periodo di tempo. Ad esempio:

• In base al singolo job, meno del X% degli elementi di input contiene errori relativi ai dati. Puoi utilizzare questo SLO per misurare la correttezza dei dati per le pipeline in modalità batch. Un esempio di SLO è: "Per ogni job batch giornaliero per elaborare le letture del contatore elettrico, meno del 3% delle letture contiene errori di inserimento dati".
• In una finestra di spostamento di X minuti, meno del Y% degli elementi di input contiene errori nei dati. Puoi utilizzare questo SLO per misurare la correttezza dei dati per le pipeline in modalità flusso. Un esempio di SLO è "Meno del 2% delle letture del contatore elettrico nell'ultima ora contiene valori negativi".

Per misurare questi SLO, utilizza le metriche su un periodo di tempo adeguato per accumulare il numero di errori per tipo. Esempi di tipi di errori sono i dati non corretti a causa di uno schema non corretto o che non rientrano in un intervallo valido.

Per informazioni sull'utilizzo di Cloud Monitoring per misurare la correttezza dei dati, consulta Metriche dei job di Dataflow.

Isolamento dei dati e bilanciamento del carico

L'isolamento dei dati prevede la segmentazione dei dati per attributo, che può semplificare il bilanciamento del carico. Ad esempio, in una piattaforma di elaborazione dei pagamenti online, puoi segmentare i dati in modo che i singoli pagamenti abbiano priorità standard o priorità elevata. La tua pipeline può quindi utilizzare il bilanciamento del carico per garantire che i pagamenti con priorità elevata vengano elaborati prima dei pagamenti con priorità standard.

Immagina di definire i seguenti SLO per l'elaborazione dei pagamenti:

• I pagamenti con priorità elevata vengono elaborati entro 10 minuti.
• I pagamenti con priorità standard vengono elaborati entro le 09:00 del giorno lavorativo successivo.

Se la piattaforma di pagamento è conforme a questi SLO, i clienti possono visualizzare i pagamenti finalizzati ad alta priorità su una dashboard dei report man mano che vengono completati. Al contrario, i pagamenti standard potrebbero non essere visualizzati nella dashboard fino al giorno successivo.

In questo scenario di esempio, sono disponibili le seguenti opzioni:

• Esegui un'unica pipeline per elaborare i pagamenti con priorità standard e alta.
• Isola e bilancia il carico dei dati in base alle priorità su più pipeline.

Nelle sezioni seguenti viene descritta dettagliatamente ciascuna opzione.

Usa un'unica pipeline per la distribuzione rispetto a SLO misti

Il seguente diagramma illustra un'unica pipeline utilizzata per elaborare i pagamenti con priorità elevata e priorità standard. La pipeline riceve notifiche dei nuovi pagamenti da un'origine dati in modalità flusso, ad esempio un argomento Pub/Sub o un argomento Apache Kafka. Quindi, elabora immediatamente i pagamenti e scrive gli eventi in BigQuery utilizzando gli inserimenti di flussi di dati.

Il vantaggio di un'unica pipeline è che semplifica i requisiti operativi, dato che devi gestire solo un'unica origine dati e una singola pipeline. Dataflow utilizza le funzionalità di ottimizzazione automatica per aiutarti a eseguire il job nel modo più rapido ed efficiente possibile.

Uno svantaggio di un'unica pipeline è che la pipeline condivisa non può dare priorità ai pagamenti ad alta priorità rispetto ai pagamenti con priorità standard e le risorse della pipeline sono condivise tra entrambi i tipi di pagamento. Nello scenario aziendale descritto in precedenza, la pipeline deve mantenere il più rigoroso dei due SLO. In altre parole, la pipeline deve utilizzare lo SLO per i pagamenti ad alta priorità, indipendentemente dalla priorità effettiva dei pagamenti elaborati. Un altro svantaggio è che, in caso di arretrato di lavoro, la pipeline in modalità flusso non è in grado di dare priorità all'elaborazione del backlog in base all'urgenza del lavoro.

Usa più pipeline su misura per SLO specifici

Puoi usare due pipeline per isolare le risorse da distribuire in base a SLO specifici. Il seguente diagramma illustra questo approccio.

I pagamenti ad alta priorità sono isolati in una pipeline in modalità flusso per l'elaborazione prioritaria. I pagamenti con priorità standard vengono elaborati da una pipeline batch eseguita ogni giorno e che utilizza i job di caricamento di BigQuery per scrivere i risultati elaborati.

Isolare i dati in pipeline diverse presenta alcuni vantaggi. Per erogare pagamenti ad alta priorità a fronte di SLO più stringenti, puoi ridurre i tempi di elaborazione assegnando più risorse alla pipeline dedicata ai pagamenti con priorità elevata. Le configurazioni delle risorse includono l'aggiunta di lavoratori Dataflow, l'utilizzo di macchine di dimensioni maggiori e l'abilitazione della scalabilità automatica. Isolare gli elementi con priorità elevata in una coda di elaborazione separata può inoltre ridurre i ritardi nell'elaborazione in caso di un afflusso improvviso di pagamenti con priorità standard.

Quando utilizzi più pipeline per isolare e bilanciare il carico dei dati da origini batch e flussi, il modello di programmazione Apache Beam consente alle pipeline ad alta priorità (flussi di dati) e a priorità standard (batch) di condividere lo stesso codice. L'unica eccezione è la trasformazione di lettura iniziale, che legge da un'origine limitata per la pipeline batch. Per maggiori informazioni, consulta Creare librerie di trasformazioni riutilizzabili.

Pianifica origini dati e sink

Per elaborare i dati, una pipeline di dati deve essere integrata con altri sistemi. Questi sistemi sono chiamati sorgenti e sink. Data pipelines leggono i dati dalle origini e scrivono i dati nei sink. Oltre a origini e sink, le pipeline di dati potrebbero interagire con sistemi esterni per l'arricchimento dei dati, l'applicazione di filtri o la chiamata a una logica di business esterna in una fase di elaborazione.

Per la scalabilità, Dataflow esegue in parallelo le fasi della pipeline su più worker. Anche i fattori esterni al codice della pipeline e al servizio Dataflow influiscono sulla scalabilità della pipeline. tra cui:

• Scalabilità di sistemi esterni: i sistemi esterni con cui interagisce la pipeline possono limitare le prestazioni e formare il limite superiore della scalabilità. Ad esempio, un argomento Apache Kafka configurato con un numero insufficiente di partizioni per la velocità effettiva di lettura necessaria può influire sulle prestazioni della pipeline. Per garantire che la pipeline e i suoi componenti soddisfino gli obiettivi di rendimento, consulta la documentazione sulle best practice per i sistemi esterni che utilizzi. Inoltre, puoi semplificare la pianificazione della capacità dell'infrastruttura usando i servizi Google Cloud Per ulteriori informazioni, consulta Utilizzo di origini e sink gestiti di Google Cloud in questa pagina.

• Scelta di formati dei dati: alcuni formati di dati potrebbero essere più veloci da leggere di altri. Ad esempio, l'utilizzo di formati di dati che supportano letture parallele, come Avro, in genere è più veloce dell'utilizzo di file CSV con nuove righe incorporate nei campi ed è più veloce rispetto all'utilizzo di file compressi.

• Posizione dei dati e topologia di rete: la vicinanza geografica e le caratteristiche di networking di origini dati e sink in relazione alla pipeline di dati potrebbero influire sulle prestazioni. Per ulteriori informazioni, consulta Considerazioni per area geografica in questa pagina.

Chiamate ai servizi esterni

La chiamata a servizi esterni dalla pipeline comporta un overhead per chiamata che può ridurre le prestazioni e l'efficienza della pipeline. Se la tua pipeline di dati chiama servizi esterni, per ridurre i costi generali, raggruppa più elementi di dati in singole richieste, se possibile. Molte trasformazioni native di Apache Beam I/O eseguono automaticamente questa attività, tra cui BigQueryIO e le operazioni di inserimento di flussi di dati. Oltre ai limiti di capacità, alcuni servizi esterni applicano anche quote che limitano il numero totale di chiamate in un determinato periodo di tempo, ad esempio una quota giornaliera, oppure limitano la frequenza delle chiamate, ad esempio il numero di richieste al secondo.

Poiché Dataflow mette in parallelo il lavoro su più worker, un eccesso di traffico può sovraccaricare un servizio esterno o esaurire le quote disponibili. Quando si utilizza la scalabilità automatica, Dataflow potrebbe tentare di compensare aggiungendo worker per eseguire un passo lento come una chiamata esterna. L'aggiunta di worker può aumentare ulteriormente la pressione sui sistemi esterni. Assicurati che i sistemi esterni possano supportare i requisiti di carico previsti o limita il traffico dalla pipeline a livelli sostenibili. Per ulteriori informazioni, consulta Limitare le dimensioni dei batch e le chiamate simultanee a servizi esterni.

Utilizza origini e sink gestiti di Google Cloud

L'utilizzo dei servizi gestiti di Google Cloud con la pipeline Dataflow elimina la complessità della gestione della capacità fornendo scalabilità integrata, prestazioni coerenti, quote e limiti che soddisfano la maggior parte dei requisiti. Devi comunque conoscere le quote e i limiti diversi per le operazioni della pipeline. Dataflow impone quote e limiti. Puoi aumentarne alcuni contattando l'assistenza Google Cloud.

Dataflow utilizza le istanze VM di Compute Engine per eseguire i job, quindi hai bisogno di una quota di Compute Engine sufficiente. Una quota di Compute Engine insufficiente può ostacolare la scalabilità automatica della pipeline o impedire l'avvio dei job.

Le parti rimanenti di questa sezione esplorano in che modo quote e limiti diversi di Google Cloud possono influenzare il modo in cui progetti, sviluppi e monitori la pipeline. Pub/Sub e BigQuery sono usati come esempi di origini e sink delle pipeline.

Esempio 1: Pub/Sub

Quando utilizzi Pub/Sub con Dataflow, Pub/Sub fornisce un servizio di importazione di eventi scalabile e durevole per la consegna di messaggi da e verso le tue pipeline di dati in modalità flusso. Puoi utilizzare la console Google Cloud per visualizzare il consumo della quota Pub/Sub e aumentare i limiti di quota. Ti consigliamo di richiedere un aumento della quota se hai una singola pipeline che supera le quote e i limiti per progetto.

Le quote e i limiti di Pub/Sub sono progettati in base all'utilizzo a livello di progetto. In particolare, a publisher e abbonati di progetti diversi vengono assegnate quote di velocità effettiva dei dati indipendenti. Se più pipeline pubblicano o sottoscrivono un singolo argomento, puoi ottenere la velocità effettiva massima consentita per l'argomento eseguendo il deployment di ciascuna pipeline nel proprio progetto. In questa configurazione, ogni pipeline utilizza un diverso account di servizio basato su progetti per utilizzare e pubblicare messaggi.

Nel diagramma seguente, Pipeline 1 e Pipeline 2 condividono la stessa quota di velocità effettiva di sottoscrittore e publisher disponibile per il progetto A. Al contrario, Pipeline 3 può utilizzare l'intera quota di velocità effettiva di sottoscrittore e publisher associata al progetto B.

Più pipeline possono leggere da un singolo argomento Pub/Sub utilizzando sottoscrizioni separate all'argomento, in modo che le pipeline Dataflow possano eseguire il pull e la conferma dei messaggi indipendentemente da altri sottoscrittori, ad esempio altre pipeline. Questa funzionalità semplifica la clonazione delle pipeline creando sottoscrizioni Pub/Sub aggiuntive. La creazione di abbonamenti aggiuntivi è utile per creare pipeline di replica per l'alta disponibilità (in genere per casi d'uso di flussi di dati), per eseguire pipeline di test aggiuntive sugli stessi dati e per abilitare gli aggiornamenti delle pipeline.

Esempio 2: BigQuery

La lettura e la scrittura dei dati BigQuery sono supportate dall'SDK Apache Beam per diversi linguaggi, tra cui Java, Python e Go. Quando utilizzi Java, la classe BigQueryIO fornisce questa funzionalità. BigQueryIO supporta due metodi per la lettura dei dati: EXPORT (esportazione della tabella) e DIRECT_READ. I diversi metodi di lettura utilizzano quote di BigQuery diverse.

L'esportazione della tabella è il metodo di lettura predefinito. Funziona come illustrato nel seguente diagramma:

Il diagramma mostra il seguente flusso:

1. BigQueryIO richiama una richiesta di esportazione BigQuery per esportare i dati della tabella. I dati della tabella esportati vengono scritti in una posizione temporanea di Cloud Storage.
2. BigQueryIO legge i dati della tabella dalla posizione temporanea di Cloud Storage.

Le richieste di esportazione di BigQuery sono limitate dalle quote di esportazione. La richiesta di esportazione deve inoltre essere completata prima che la pipeline possa iniziare a elaborare i dati, il che aggiunge ulteriore tempo di esecuzione per il job.

Al contrario, l'approccio di lettura diretta utilizza l'API BigQuery Storage per leggere i dati delle tabelle direttamente da BigQuery. L'API BigQuery Storage fornisce prestazioni di lettura ad alta velocità effettiva per i dati delle righe delle tabelle mediante gRPC. L'utilizzo dell'API BigQuery Storage rende non necessaria la fase di esportazione, evitando così restrizioni della quota di esportazione e riducendo potenzialmente il tempo di esecuzione del job.

Il seguente diagramma mostra il flusso se utilizzi l'API BigQuery Storage. A differenza del flusso che utilizza una richiesta di esportazione di BigQuery, questo flusso è più semplice, perché prevede un solo passaggio di lettura diretta per trasferire i dati dalla tabella alla pipeline.

Anche la scrittura di dati nelle tabelle BigQuery prevede implicazioni di quote proprie. Le pipeline batch che utilizzano i job di caricamento BigQuery consumano diverse quote dei job di caricamento BigQuery che si applicano a livello di tabella e progetto. Allo stesso modo, le pipeline in modalità flusso che utilizzano gli inserimenti di flussi di dati BigQuery utilizzano le quote di inserimento di flussi di dati BigQuery.

Per determinare i metodi più appropriati per leggere e scrivere dati, considera il tuo caso d'uso. Ad esempio, evita di utilizzare i job di caricamento BigQuery per aggiungere in una tabella i dati migliaia di volte al giorno. Usa una pipeline in modalità flusso per scrivere dati quasi in tempo reale in BigQuery. A questo scopo, la pipeline in modalità flusso deve utilizzare gli inserimenti di flussi di dati o l'API StorageWrite.

Considerazioni a livello di regione

Dataflow è offerto come servizio gestito in più regioni Google Cloud Quando scegli una regione da utilizzare per eseguire i tuoi job, considera i seguenti fattori:

• La posizione di origini dati e sink
• Preferenze o limitazioni relative alle località di trattamento dei dati
• Funzionalità di Dataflow offerte solo in regioni specifiche
• La regione utilizzata per gestire l'esecuzione di un determinato job
• La zona utilizzata per i worker del job

L'impostazione della regione utilizzata per il job e per i worker può variare a seconda del job. Per ulteriori informazioni, incluso quando specificare regioni e zone, consulta la documentazione sulle regioni di Dataflow.

Specificando le regioni in cui eseguire i job Dataflow, puoi pianificare in base a considerazioni regionali per l'alta disponibilità e il ripristino di emergenza. Per maggiori informazioni, consulta Alta disponibilità e ridondanza geografica.

Regioni

Le regioni Dataflow archiviano e gestiscono i metadati relativi al job, come le informazioni sul grafico Apache Beam stesso, come i nomi delle trasformazioni. Controllano inoltre i comportamenti dei worker come la scalabilità automatica. Specificare una regione consente di soddisfare le tue esigenze di sicurezza e conformità, la località dei dati e il posizionamento regionale di un job. Per evitare un impatto sulle prestazioni delle chiamate di rete tra regioni, ti consigliamo di utilizzare la stessa regione per il job e per i worker, se possibile.

Worker Dataflow

I job Dataflow utilizzano istanze VM di Compute Engine, chiamate lavoratori Dataflow, per eseguire la pipeline. I job Dataflow possono utilizzare qualsiasi zona di Compute Engine per i worker, incluse le regioni in cui non sono presenti località Dataflow. Specificando una regione dei worker per il lavoro, puoi controllare il posizionamento regionale dei worker. Per specificare una regione o una zona dei worker:

• Se utilizzi gcloud CLI per creare un job da un modello Dataflow, utilizza il flag --worker-region per eseguire l'override della regione worker o il flag --worker-zone per eseguire l'override della zona di worker.
• Se utilizzi l'SDK Java Apache Beam per creare il job, imposta regioni e zone per i worker utilizzando le opzioni pipeline. Utilizza workerRegion per eseguire l'override della regione del worker o workerZone per eseguire l'override della zona del worker.

Per migliorare la latenza e la velocità effettiva di rete, ti consigliamo di creare worker in una regione geograficamente vicina alle origini dati e ai sink. Se non specifichi una regione o una zona per i worker quando crei un job, Dataflow imposta automaticamente una zona che si trova nella stessa regione del job.

Se non utilizzi il servizio Dataflow Shuffle o Streaming Engine, i dati elaborati dal job (ovvero i dati archiviati in qualsiasi oggetto PCollection) risiedono nei worker del job, supponendo che nessun codice utente trasmetta dati all'esterno dei worker. Se è abilitato il servizio Dataflow Shuffle o Streaming Engine, il set di dati distribuito rappresentato da un oggetto PCollection può essere trasmesso tra i worker e questi servizi.

Considerazioni sulla crittografia dei dati

Essendo un servizio completamente gestito, Dataflow cripta automaticamente i dati che si spostano attraverso la pipeline di dati utilizzando chiavi di proprietà di Google e gestite da Google sia per i dati in corso che per i dati at-rest. Anziché utilizzare le chiavi di proprietà di Google e gestite da Google, potresti preferire gestire le tue chiavi di crittografia. In questo caso, Dataflow supporta le chiavi di crittografia gestite dal cliente (CMEK) utilizzando Cloud Key Management Service (KMS). Puoi inoltre utilizzare Cloud HSM, un servizio per modulo di sicurezza hardware (HSM) ospitato nel cloud che consente di ospitare chiavi di crittografia ed eseguire operazioni crittografiche in un cluster di HSM certificati FIPS 140-2 di livello 3.

Quando utilizzi CMEK, Dataflow utilizza la chiave Cloud KMS per criptare i dati, ad eccezione delle operazioni basate sulle chiavi dei dati come windowing, raggruppamento e join. Se le chiavi dei dati contengono dati sensibili, ad esempio informazioni che consentono l'identificazione personale (PII), devi eseguire l'hashing delle chiavi o trasformarle in altro modo prima che possano accedere alla pipeline Dataflow.

Considerazioni sul networking privato

I requisiti di sicurezza e networking potrebbero richiedere che i carichi di lavoro basati su VM, come i job Dataflow, utilizzino solo indirizzi IP privati. Dataflow consente di specificare che i worker usano indirizzi IP privati per tutte le comunicazioni di rete. Se gli IP pubblici sono disabilitati, devi abilitare l'accesso privato Google sulla subnet in modo che i worker Dataflow possano raggiungere le API e i servizi Google.

Ti consigliamo di disabilitare gli IP pubblici per i worker Dataflow, a meno che i job Dataflow non richiedano IP pubblici per accedere alle risorse di rete al di fuori di Google Cloud. La disabilitazione degli IP pubblici impedisce ai worker di Dataflow di accedere alle risorse che si trovano all'esterno della subnet o di accedere alle reti VPC peer. Analogamente, viene impedito l'accesso di rete ai worker VM dall'esterno della subnet o delle reti VPC peer.

Per ulteriori informazioni sull'utilizzo dell'opzione pipeline --usePublicIps per specificare se i worker devono avere solo IP privati, consulta le opzioni della pipeline.

Passaggi successivi

• Sviluppa e testa la pipeline.
• Scopri di più sulla progettazione di flussi di lavoro completi della pipeline.
• Scopri di più sulle pratiche di Site Reliability Engineering (SRE) di Google per le pipeline di elaborazione dati.