Pianifica la 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 fondamentali 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 prestazioni e affidabilità. Questa pagina illustra varie considerazioni di pianificazione per le pipeline Dataflow, tra cui:

• Le aspettative di prestazioni per le pipeline, compresi gli standard di misurabilità
• Integrazione delle tue pipeline con origini dati, sink e altri sistemi connessi
• Regionalizzazione di pipeline, origini e sink
• Sicurezza, ad esempio crittografia dei dati e networking privato

Definire e misurare gli SLO

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

• Aggiornamento dei dati: genera il 90% dei suggerimenti sui prodotti derivanti dall'attività sul sito web dell'utente che si è verificata non più di 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 registrazione 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à agli SLO. Gli SLI sono metriche quantificabili che indicano il livello di efficacia del sistema rispetto a 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 dagli eventi di attività utente'utente e se lo SLI registra un ritardo di 4 minuti tra l'ora dell'evento e il momento in cui viene elaborato, i suggerimenti non prendono in considerazione l'attività sul sito web di un utente precedente a quattro minuti. Se una pipeline che elabora i flussi di dati supera una latenza di sistema di 4 minuti, lo SLO non è soddisfatto.

Poiché i componenti di sistema oltre la pipeline influiscono sullo SLO, è importante acquisire una gamma di SLI che descrivono le prestazioni complessive del sistema oltre a quelle della pipeline stessa, incluse le metriche che descrivono l'integrità end-to-end del sistema. Ad esempio, la tua pipeline Dataflow potrebbe calcolare i risultati con un ritardo accettabile, ma potrebbe verificarsi un problema di prestazioni con un sistema downstream che ha un impatto 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 indicati nel libro Site Reliability Engineering come i formati più comuni di SLO di aggiornamento dei dati delle pipeline:

• X% di dati elaborati in Y [secondi, giorni, minuti]. Questo SLO si riferisce alla percentuale di dati elaborati in un determinato periodo di tempo. È comunemente usato 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 nei passaggi di elaborazione delle chiavi in relazione al tempo di esecuzione della pipeline trascorso. Puoi scegliere un passaggio che legge un set di dati di input e un altro passaggio che elabora ogni elemento dell'input. Un esempio di SLO è "Per il gioco Shave the Yak, il 99% delle attività degli utenti che hanno un impatto sui punteggi dei giocatori viene preso in considerazione 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. Viene comunemente utilizzato per le pipeline in modalità flusso che elaborano i dati da origini illimitate. Per questo tipo di SLO, utilizza metriche che indicano il tempo impiegato dalla pipeline per elaborare i dati. Due possibili metriche sono l'età dell'elemento non elaborato meno recente, ovvero da quanto tempo un articolo non elaborato è rimasto nella coda o l'età dell'elemento elaborato più di recente. Un esempio di SLO è "I suggerimenti sui prodotti vengono generati da attività utente che non risalgono a più di 5 minuti".

• Il job della pipeline viene completato correttamente entro X [secondi, giorni, minuti]. Questo SLO fissa una scadenza per il completamento corretto ed è comunemente utilizzato per le pipeline batch che elaborano i dati da origini dati limitate. Questo SLO richiede il tempo totale trascorso della pipeline e lo stato di completamento del job, oltre ad altri indicatori che indicano la riuscita del job, come la percentuale di elementi elaborati che generano errori. Un esempio di SLO è "Gli ordini dei clienti del giorno lavorativo corrente vengono elaborati entro le 9:00 del giorno successivo".

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

Correttezza dei dati

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

• Test delle unità e test di integrazione, che è possibile automatizzare mediante l'integrazione continua.

• Test della pipeline end-to-end, 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 in genere comporta la misurazione della correttezza su un determinato periodo di tempo. Ad esempio:

• In base al singolo job, meno del X% degli elementi di input contiene errori dei 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 di elettricità, meno del 3% delle letture contiene errori di immissione dati".
• In una finestra di spostamento di X minuti, meno dello 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 dei contatori di elettricità 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 errore sono i dati non corretti a causa di uno schema in un formato non corretto o i dati non rientrano in un intervallo valido.

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

Isolamento dei dati e bilanciamento del carico

L'isolamento dei dati comporta 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 alta priorità. 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 9:00 del giorno lavorativo successivo.

Se la piattaforma di pagamento è conforme a questi SLO, i clienti potranno visualizzare i pagamenti finalizzati ad alta priorità in 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, hai a disposizione le seguenti opzioni:

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

Le seguenti sezioni descrivono in dettaglio ciascuna opzione.

Utilizza un'unica pipeline per la distribuzione in SLO misti

Il seguente diagramma illustra un'unica pipeline utilizzata per elaborare i pagamenti con priorità elevata e standard. La pipeline riceve notifica 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 una singola pipeline è che semplifica i requisiti operativi, in quanto devi gestire una sola origine dati e pipeline. Dataflow utilizza le funzionalità di ottimizzazione automatica per eseguire il job nel modo più rapido ed efficiente possibile.

Uno svantaggio di una singola pipeline è che non può dare priorità ai pagamenti con priorità elevata rispetto a quelli 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 e distribuire le risorse in base a SLO specifici. Il seguente diagramma illustra questo approccio.

I pagamenti con priorità elevata 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 BigQuery per scrivere i risultati elaborati.

Isolare i dati in pipeline diverse presenta alcuni vantaggi. Per pubblicare pagamenti con priorità elevata contro SLO più rigidi, 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 Worker Dataflow, l'utilizzo di macchine più grandi e l'abilitazione della scalabilità automatica. Isolare gli articoli con priorità elevata in una coda di elaborazione separata può anche ridurre i ritardi nell'elaborazione se si verifica un afflusso improvviso di pagamenti con priorità standard.

Quando utilizzi più pipeline per isolare e bilanciare il carico dei dati provenienti da origini in modalità batch e flusso, il modello di programmazione Apache Beam consente alle pipeline ad alta priorità (in modalità flusso) 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 per origini dati e sink

Per elaborare i dati, una pipeline di dati deve essere integrata con altri sistemi. Questi sistemi sono indicati come 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 arricchire i dati, applicare filtri o chiamare la logica di business esterna in una fase di elaborazione.

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

• Scalabilità dei 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 assicurarti che la pipeline e i suoi componenti soddisfino i tuoi target di prestazioni, consulta la documentazione delle best practice per i sistemi esterni che stai utilizzando. Puoi anche semplificare la pianificazione della capacità dell'infrastruttura utilizzando i servizi Google Cloud che offrono scalabilità integrata. Per maggiori informazioni, consulta Utilizzo di origini e sink gestiti di Google Cloud in questa pagina.

• Scelta del formato dei dati: alcuni formati di dati potrebbero essere più veloci da leggere rispetto ad altri. Ad esempio, l'utilizzo di formati di dati che supportano le letture parallelizzabili, come Avro, di solito è più veloce rispetto all'utilizzo di file CSV con ritorni a capo incorporati nei campi ed è più veloce dell'utilizzo di file compressi.

• Località dei dati e topologia di rete: le caratteristiche di prossimità geografica e networking di origini dati e sink in relazione alla pipeline di dati potrebbero influire sulle prestazioni. Per ulteriori informazioni, consulta la sezione Considerazioni regionali in questa pagina.

Chiamate di servizi esterni

Le chiamate ai servizi esterni dalla pipeline comportano overhead per chiamata che possono 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 I/O di Apache Beam 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, o limitano la frequenza delle chiamate, ad esempio il numero di richieste al secondo.

Poiché Dataflow mette in parallelo il lavoro su più worker, troppo traffico può sovraccaricare un servizio esterno o esaurire le quote disponibili. Quando viene utilizzata la scalabilità automatica, Dataflow potrebbe tentare di compensare aggiungendo worker per eseguire un passaggio 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 saperne di più, consulta Limitare le dimensioni dei batch e le chiamate simultanee a servizi esterni.

Usa 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à offrendo scalabilità integrata, prestazioni coerenti, quote e limiti che soddisfano la maggior parte dei requisiti. Devi comunque conoscere le diverse quote e limiti per le operazioni della pipeline. Dataflow stesso 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 è necessaria 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 influire sulla progettazione, lo sviluppo e il monitoraggio della pipeline. Pub/Sub e BigQuery sono 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 distribuzione di messaggi da e verso le tue pipeline di dati in modalità flusso. Puoi utilizzare la console Google Cloud per visualizzare l'utilizzo delle quote di 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 quell'argomento eseguendo il deployment di ogni pipeline nel proprio progetto. In questa configurazione, ogni pipeline utilizza un account di servizio basato su progetti diverso per consumare 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, il che consente alle pipeline di Dataflow di 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 i casi d'uso di flussi), per eseguire ulteriori pipeline di test sugli stessi dati e per abilitare gli aggiornamenti delle pipeline.

Esempio 2: BigQuery

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

L'esportazione delle tabelle è il metodo di lettura predefinito. Funziona come mostrato nel seguente schema:

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 località temporanea di Cloud Storage.

Le richieste di esportazione di BigQuery sono limitate dalle quote di esportazione. La richiesta di esportazione deve 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 alla lettura diretta utilizza l'API BigQuery Storage per leggere i dati della tabella direttamente da BigQuery. L'API BigQuery Storage fornisce prestazioni di lettura ad alta velocità effettiva per i dati delle righe di una tabella utilizzando gRPC. L'utilizzo dell'API BigQuery Storage rende superflua la fase di esportazione, il che evita i limiti di quota dell'esportazione e riduce 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 BigQuery, questo flusso è più semplice, in quanto prevede un solo passaggio di lettura diretta per trasferire i dati dalla tabella alla pipeline.

Anche la scrittura di dati nelle tabelle BigQuery ha le proprie implicazioni per le quote. Le pipeline batch che utilizzano i job di caricamento BigQuery utilizzano diverse quote per i job di carico di BigQuery che si applicano a livello di tabella e di progetto. Allo stesso modo, le pipeline di inserimento flussi di dati che utilizzano l'inserimento di flussi di dati BigQuery utilizzano le quote di inserimento di flussi di dati di 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 di BigQuery per aggiungere dati migliaia di volte al giorno a una tabella. Utilizza una pipeline di flussi di dati per scrivere dati quasi in tempo reale in BigQuery. A questo scopo, la pipeline di inserimento di flussi deve utilizzare l'inserimento di flussi di dati o l'API Storage Write.

Considerazioni di carattere regionale

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 restrizioni sulle località di trattamento 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

Per un determinato job, l'impostazione della regione utilizzata per il job e per i worker può essere diversa. Per ulteriori informazioni, anche quando specificare le regioni e le zone, consulta la documentazione sulle regioni Dataflow.

Specificando le regioni in cui eseguire i job Dataflow, puoi pianificare considerazioni a livello di regione per l'alta disponibilità e il ripristino di emergenza. Per saperne di più, consulta Alta disponibilità e ridondanza geografica.

Regioni

Le regioni Dataflow archiviano e gestiscono i metadati relativi al job, ad esempio 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 esigenze di sicurezza e conformità, località dei dati e posizionamento a livello di regione 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 Worker 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 job, 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 oppure il flag --worker-zone per eseguire l'override della zona worker.
• Se utilizzi l'SDK Java Apache Beam per creare il job, imposta regioni e zone per i worker utilizzando le opzioni pipeline. Usa workerRegion per eseguire l'override della regione worker o workerZone per sostituire la zona 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, presupponendo che nessun codice utente trasmetta dati al di fuori dei worker. Se il servizio Dataflow shuffling o Streaming Engine è abilitato, 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 nella tua pipeline di dati utilizzando chiavi di crittografia gestite da Google sia per i dati in transito sia per quelli at-rest. Anziché utilizzare le chiavi di crittografia 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 anche utilizzare Cloud HSM, un servizio per moduli di sicurezza hardware (HSM) ospitati nel cloud che ti consente di ospitare chiavi di crittografia ed eseguire operazioni crittografiche in un cluster di HSM certificati per lo FIPS 140-2 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 unione. Se le chiavi di dati contengono dati sensibili, ad esempio informazioni che consentono l'identificazione personale (PII), devi sottoporre le chiavi ad hashing o trasformarle in altro modo prima che entrino nella pipeline di Dataflow.

Considerazioni sul networking privato

I requisiti di rete e di sicurezza 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 utilizzano indirizzi IP privati per tutte le comunicazioni di rete. Se gli IP pubblici sono disabilitati, devi abilitare l'accesso privato Google nella subnet in modo che i worker di 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 Dataflow di accedere a risorse esterne alla subnet o di accedere alle reti VPC in peering. Allo stesso modo, viene impedito l'accesso alla rete da parte dei worker VM dall'esterno della subnet o delle reti VPC peer.

Per saperne di più sull'utilizzo dell'opzione della pipeline --usePublicIps per specificare se i worker devono avere solo IP privati, consulta Opzioni della pipeline.

Passaggi successivi

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