Pianifica la pipeline Dataflow

Questa pagina illustra considerazioni importanti per la pianificazione della 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 di informazioni aziendali. Le prestazioni e l'affidabilità della tua pipeline di dati possono influire su questi sistemi più ampi e sull'efficacia con cui vengono soddisfatti i requisiti della tua attività.

Se pianifichi le pipeline di dati prima di svilupparle, puoi migliorarne le prestazioni e l'affidabilità. Questa pagina illustra vari aspetti di pianificazione per le pipeline Dataflow, tra cui:

• Aspettative di rendimento per le pipeline, inclusi gli standard per la misurabilità
• Integrazione delle pipeline con origini dati, destinazioni e altri sistemi collegati
• Regionalizzazione di pipeline, origini e sink
• Sicurezza, ad esempio crittografia dei dati e reti private

Definire e misurare gli SLO

Un'importante misura del rendimento è il grado di soddisfazione della pipeline rispetto ai requisiti della tua attività. Gli obiettivi del livello di servizio (SLO) forniscono definizioni concrete delle prestazioni che puoi confrontare con le soglie accettabili. Ad esempio, potresti definire i seguenti SLO di esempio per il tuo sistema:

• Aggiornamento dei dati: genera il 90% dei consigli sui prodotti dall'attività dell'utente sul sito web avvenuta non più tardi 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/load balancing: entro un giorno lavorativo, elabora tutti i pagamenti con priorità elevata entro 10 minuti dalla loro impostazione 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 con cui il sistema soddisfa un determinato SLO. Ad esempio, puoi misurare lo SLO di aggiornamento dei dati di esempio utilizzando l'età dell'attività utente elaborata più di recente come SLI. Se la pipeline genera consigli dagli eventi di attività utente e se l'SLI segnala un ritardo di 4 minuti tra l'ora dell'evento e l'ora di elaborazione dell'evento, i consigli non prendono in considerazione l'attività dell'utente sul sito web precedente ai 4 minuti. Se una pipeline che elabora i dati in streaming supera una latenza del sistema di 4 minuti, significa che lo SLO non è soddisfatto.

Poiché i componenti di sistema oltre la pipeline influiscono sullo SLO, è importante acquisire una serie di SLI che descrivano il rendimento complessivo del sistema oltre a quello della pipeline stessa, incluse le metriche che descrivono lo stato end-to-end del sistema. Ad esempio, la pipeline Dataflow potrebbe calcolare i risultati con un ritardo accettabile, ma potrebbe verificarsi un problema di prestazioni con un sistema a valle che influisce su SLO più ampi.

Per ulteriori informazioni sugli SLO importanti da prendere in considerazione, consulta il libro Site Reliability Engineering.

Aggiornamento dei dati

L'aggiornamento dei dati si riferisce all'usabilità dei dati in relazione alla loro età. Nel libro Site Reliability Engineering vengono indicati come formati SLO di aggiornamento dei dati della pipeline più comuni i seguenti SLO di aggiornamento dei dati:

• X% dei dati elaborati in Y [secondi, giorni, minuti]. Questo SLO fa riferimento alla percentuale di dati elaborati in un determinato periodo di tempo. Viene spesso 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 tempo di esecuzione della pipeline trascorso. Puoi scegliere un passaggio che legga un set di dati di input e un altro passaggio che elabori ogni elemento dell'input. Un esempio di SLO è "Per il gioco Shave the Yak, il 99% delle attività utente che influiscono sui punteggi dei giocatori viene preso in considerazione entro 30 minuti dal completamento della partita".

• I dati più vecchi non risalgono a più di X [secondi, giorni, minuti]. Questo SLO si riferisce alla data di creazione dei dati prodotti dalla pipeline. Viene comunemente utilizzato per le pipeline di streaming che elaborano i 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 più vecchio, ovvero il tempo di permanenza di un elemento non elaborato nella coda, o la data dell'elemento elaborato più di recente. Un esempio di SLO è: "I consigli sui prodotti vengono generati dall'attività utente risalente a non più di 5 minuti prima."

• Il job della pipeline viene completato correttamente entro X [secondi, giorni, minuti]. Questo SLO imposta una scadenza per il completamento e viene comunemente utilizzato per le pipeline batch che elaborano i dati da origini di dati limitate. Questo SLO richiede il tempo di esecuzione totale della pipeline e lo stato di completamento del job, oltre ad altri indicatori che indicano il successo del job, ad esempio la percentuale di elementi elaborati che generano errori. Un esempio di SLO è "Gli ordini dei clienti effettuati nel 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 Metriche dei job Dataflow.

Correttezza dei dati

L'accuratezza dei dati si riferisce all'assenza di errori nei dati. Puoi determinare l'esattezza dei dati tramite diversi mezzi, tra cui:

• Test di unità e test di integrazione, che puoi automatizzare utilizzando 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 di unità e integrazione. Puoi automatizzare i test della pipeline end-to-end utilizzando la distribuzione continua.

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

Per le pipeline in esecuzione, la definizione di un target di accuratezza dei dati in genere comporta la misurazione dell'accuratezza in un determinato periodo di tempo. Ad esempio:

• Su base job, meno del X% degli elementi di input contiene errori nei dati. Puoi utilizzare questo SLO per misurare l'accuratezza dei dati per le pipeline in batch. Un esempio di SLO è "Per ogni job batch giornaliero per l'elaborazione delle letture del contatore dell'elettricità, meno del 3% delle letture contiene errori di inserimento dei dati".
• In un intervallo mobile di X minuti, meno del Y% degli elementi inseriti contiene errori nei dati. Puoi utilizzare questo SLO per misurare l'accuratezza dei dati per le pipeline di streaming. 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 per un periodo di tempo adeguato per accumulare il numero di errori per tipo. Alcuni esempi di tipi di errori sono i dati incorrect a causa di uno schema con formato non valido 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 prevede il loro segmentamento in base all'attributo, il 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. La pipeline può quindi utilizzare il bilanciamento del carico per garantire che i pagamenti con priorità elevata vengano elaborati prima di quelli con priorità standard.

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

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

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

In questo scenario di esempio, hai le seguenti opzioni:

• Esegui una singola pipeline per elaborare i pagamenti con priorità standard e prioritaria.
• Isola e esegui il bilanciamento del carico dei dati in base alle priorità in più pipeline.

Le sezioni seguenti descrivono in dettaglio ogni opzione.

Utilizzare una singola pipeline per soddisfare SLO misti

Il diagramma seguente mostra una singola pipeline utilizzata per elaborare i pagamenti sia con priorità elevata sia con priorità standard. La pipeline riceve una notifica di nuovi pagamenti da un'origine dati in streaming, ad esempio un argomento Pub/Sub o un argomento Apache Kafka. Quindi, elabora immediatamente i pagamenti e scrive gli eventi in BigQuery utilizzando inserimenti di flussi di dati.

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

Uno svantaggio di una singola pipeline è che non può dare la 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 un backlog di lavoro, la pipeline di inserimento flussi non è in grado di dare la priorità all'elaborazione del backlog in base all'urgenza del lavoro.

Utilizza più pipeline personalizzate per SLO specifici

Puoi utilizzare due pipeline per isolare le risorse e eseguire il caricamento in base a SLO specifici. Il seguente diagramma illustra questo approccio.

I pagamenti ad alta priorità vengono isolati in una pipeline di streaming per l'elaborazione con priorità. I pagamenti con priorità standard vengono elaborati da una pipeline batch che viene eseguita quotidianamente e che utilizza i job di caricamento di BigQuery per scrivere i risultati elaborati.

L'isolamento dei dati in pipeline diverse presenta dei vantaggi. Per eseguire pagamenti con priorità elevata in base a 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 worker Dataflow, l'utilizzo di macchine più grandi e l'attivazione dell'autoscaling. L'isolamento degli elementi ad alta priorità in una coda di elaborazione separata può anche attenuare i ritardi di elaborazione in caso di un improvviso afflusso di pagamenti con priorità standard.

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

Pianifica le origini dati e gli sink

Per elaborare i dati, una pipeline di dati deve essere integrata con altri sistemi. Questi sistemi sono denominati origini e sink. Data pipelines leggono i dati dalle origini e li scrivono negli sink. Oltre alle origini e ai destinazioni, le pipeline di dati possono interagire con sistemi esterni per l'arricchimento dei dati, il filtraggio o l'uso di logica di business esterna all'interno di un passaggio di elaborazione.

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

• Scalabilità dei sistemi esterni: i sistemi esterni con cui interagisce la pipeline possono limitare il rendimento e costituire il limite superiore della scalabilità. Ad esempio, un argomento Apache Kafka configurato con un numero insufficiente di partizioni per il throughput di lettura necessario può influire sul rendimento della pipeline. Per contribuire ad assicurare che la pipeline e i relativi componenti soddisfino i tuoi obiettivi di rendimento, consulta la documentazione sulle best practice per i sistemi esterni che utilizzi. Puoi anche semplificare la pianificazione della capacità dell'infrastruttura utilizzando i servizi Google Cloud che offrono scalabilità integrata. Per ulteriori informazioni, consulta Utilizzare origini e destinazioni gestite da Google Cloud in questa pagina.

• Scelta dei formati dei dati: la lettura di alcuni formati dei dati potrebbe essere più rapida rispetto ad altri. Ad esempio, l'utilizzo di formati di dati che supportano letture parallelizzabili, come Avro, è in genere più veloce rispetto all'utilizzo di file CSV con interruzioni di riga incorporate nei campi e rispetto all'utilizzo di file compressi.

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

Chiamate a servizi esterni

La chiamata di servizi esterni dalla pipeline comporta costi aggiuntivi per chiamata che possono diminuire il rendimento e l'efficienza della pipeline. Se la pipeline di dati chiama servizi esterni, per ridurre i costi generali, raggruppa più elementi di dati in singole richieste, se possibile. Molte trasformazioni I/O native 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 di chiamata, ad esempio il numero di richieste al secondo.

Poiché Dataflow esegue il parallelismo del lavoro su più worker, un volume eccessivo di traffico può sopraffare 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 lavoratori può aumentare la pressione sui sistemi esterni. Assicurati che i sistemi esterni possano supportare i requisiti di carico previsti o limita il traffico della pipeline a livelli sostenibili. Per ulteriori informazioni, consulta Limitare le dimensioni dei batch e le chiamate simultanee ai servizi esterni.

Utilizzare origini e destinazioni gestite da Google Cloud

L'utilizzo dei servizi gestiti di Google Cloud con la pipeline Dataflow rimuove la complessità della gestione della capacità fornendo scalabilità integrata, prestazioni coerenti e quote e limiti che soddisfano la maggior parte dei requisiti. Devi comunque essere a conoscenza di quote e limiti diversi per le operazioni della pipeline. Dataflow stesso impone quote e limiti. Puoi aumentare alcune di queste contattando l'assistenza Google Cloud.

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

Le restanti parti di questa sezione illustrano in che modo le diverse quote e i limiti di Google Cloud possono influire sulla progettazione, sullo sviluppo e sul monitoraggio della pipeline. Pub/Sub e BigQuery vengono utilizzati come esempi di origini e destinazioni della pipeline.

Esempio 1: Pub/Sub

Quando utilizzi Pub/Sub con Dataflow, Pub/Sub fornisce un servizio di importazione di eventi scalabile e duraturo per la pubblicazione di messaggi verso e dalle pipeline di dati in streaming. Puoi utilizzare la console Google Cloud per visualizzare il consumo delle quote Pub/Sub e aumentare i limiti di quota. Ti consigliamo di richiedere un aumento della quota se una singola pipeline 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. Nello specifico, publisher e sottoscrittori in progetti diversi ricevono quote indipendenti per il throughput dei dati. Se più pipeline pubblicano o si iscrivono a un singolo argomento, puoi ottenere il throughput massimo consentito per quell'argomento implementando ogni pipeline in un proprio progetto. In questa configurazione, ogni pipeline utilizza un account di servizio basato su progetto diverso per consumare e pubblicare i messaggi.

Nel seguente diagramma, la pipeline 1 e la pipeline 2 condividono la stessa quota di throughput per abbonati ed editori disponibile per il progetto A. Al contrario, la pipeline 3 può utilizzare l'intera quota di throughput di abbonati ed editori associata al progetto B.

Più pipeline possono leggere da un singolo argomento Pub/Sub utilizzando sottoscrizioni separate all'argomento, il che consente alle pipeline Dataflow di estrarre e confermare i messaggi indipendentemente da altri sottoscrittori, come altre pipeline. Questa funzionalità semplifica la clonazione delle pipeline creando ulteriori iscrizioni Pub/Sub. La creazione di altri abbonati è utile per creare pipeline di replica per l'alta disponibilità (in genere per i casi d'uso di streaming), per eseguire altre pipeline di test sui medesimi dati e per abilitare gli aggiornamenti delle pipeline.

Esempio 2: BigQuery

La lettura e la scrittura di dati BigQuery è supportata dall'SDK Apache Beam per più linguaggi, tra cui Java, Python e Go. Quando utilizzi Java, la classe BigQueryIO fornisce questa funzionalità. BigQueryIO supporta due metodi per leggere i dati: EXPORT (esportazione di tabelle) e DIRECT_READ. I diversi metodi di lettura consumano quote BigQuery diverse.

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

Il diagramma mostra il seguente flusso:

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

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

Al contrario, l'approccio di lettura diretta utilizza l'API BigQuery Storage per leggere i dati della tabella direttamente da BigQuery. L'API BigQuery Storage offre prestazioni di lettura ad alta velocità per i dati delle righe della tabella utilizzando gRPC. L'utilizzo dell'API BigQuery Storage rende superfluo il passaggio di esportazione, il che evita le limitazioni delle quote di esportazione e potenzialmente riduce il tempo di esecuzione del job.

Il seguente diagramma mostra il flusso se utilizzi l'API BigQuery Storage. Contrariamente al 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 implicazioni per le quote. Le pipeline batch che utilizzano i job di caricamento di BigQuery consumano diverse quote per i job di caricamento di BigQuery che si applicano a livello di tabella e progetto. Analogamente, le pipeline di streaming che utilizzano gli inserimenti di flussi di dati di BigQuery consumano le quote di inserimento di flussi di dati BigQuery.

Per determinare i metodi più appropriati per leggere e scrivere i dati, prendi in considerazione il tuo caso d'uso. Ad esempio, evita di utilizzare i job di caricamento BigQuery per accodare dati migliaia di volte al giorno in una tabella. Utilizza una pipeline di streaming per scrivere dati quasi in tempo reale in BigQuery. A questo scopo, la pipeline di streaming deve utilizzare gli inserimenti in streaming o l'API Storage Write.

Considerazioni regionali

Dataflow è disponibile come servizio gestito in più regioni Google Cloud. Quando scegli una regione da utilizzare per eseguire i job, prendi in considerazione 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

Per un determinato job, l'impostazione della regione che utilizzi per il job e per i worker può essere diversa. 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 le considerazioni regionali per l'alta disponibilità e il ripristino di emergenza. Per maggiori informazioni, consulta Elevata disponibilità e ridondanza geografica.

Regioni

Le regioni Dataflow archiviano e gestiscono i metadati relativi al tuo job, ad esempio informazioni sul grafo Apache Beam stesso, come i nomi delle trasformazioni. Inoltre, controllano i comportamenti dei worker, ad esempio la scalabilità automatica. La specifica di una regione ti aiuta a soddisfare le tue esigenze in termini di sicurezza e conformità, località dei dati e collocamento regionale di un job. Per evitare ripercussioni sulle prestazioni dovute alle chiamate di rete tra regioni, ti consigliamo di utilizzare la stessa regione per il job e per i lavoratori, se possibile.

Worker Dataflow

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

• Se utilizzi l'interfaccia a riga di comando gcloud per creare un job da un modello Dataflow, utilizza il flag --worker-region per eseguire l'override della regione del worker o il flag --worker-zone per eseguire l'override della zona del worker.
• Se utilizzi l'SDK Apache Beam Java per creare il job, imposta le regioni e le zone per i worker utilizzando le opzioni della 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 della rete, ti consigliamo di creare worker in una regione geograficamente vicina alle origini dati e alle destinazioni. Se non specifichi una regione o una zona per i worker quando crei un job, Dataflow imposta automaticamente come impostazione predefinita 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 PCollection oggetto) risiedono nei worker del job, supponendo che nessun codice utente trasmetta dati all'esterno dei worker. Se il servizio Dataflow Shuffle o Streaming Engine è attivato, il set di dati distribuito rappresentato da un oggetto PCollection può essere trasmesso tra i worker e questi servizi.

Considerazioni sulla crittografia dei dati

In qualità di servizio completamente gestito, Dataflow cripta automaticamente i dati che si spostano nella pipeline di dati utilizzando chiavi di proprietà e gestite da Google sia per i dati in transito sia per quelli a riposo. Anziché utilizzare le chiavi di proprietà 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 anche utilizzare Cloud HSM, un servizio per moduli 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 tua chiave Cloud KMS per criptare i dati, tranne che per le operazioni basate su chiavi di dati come finestre, raggruppamenti e unioni. Se le chiavi di dati contengono dati sensibili, come informazioni che consentono l'identificazione personale (PII), devi sottoporre le chiavi ad hashing o trasformarle in altro modo prima che entrino nella pipeline Dataflow.

Considerazioni sul networking privato

I requisiti di rete e sicurezza potrebbero prevedere che i carichi di lavoro basati su VM, come i job Dataflow, utilizzino solo indirizzi IP privati. Dataflow ti consente di specificare che i worker utilizzino indirizzi IP privati per tutte le comunicazioni di rete. Se gli IP pubblici sono disattivati, devi attivare l'accesso privato Google nella sottorete in modo che i worker di Dataflow possano raggiungere le API e i servizi Google.

Ti consigliamo di disattivare gli IP pubblici per i worker di Dataflow, a meno che i tuoi job di Dataflow non richiedano indirizzi IP pubblici per accedere alle risorse di rete al di fuori di Google Cloud. La disattivazione degli IP pubblici impedisce ai worker Dataflow di accedere alle risorse esterne alla subnet o alle reti VPC peer. Analogamente, viene impedito l'accesso alla rete dei worker VM dall'esterno della sottorete o delle reti VPC peer.

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

Passaggi successivi

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