Lo sviluppo della pipeline prevede fasi e attività diverse, come lo sviluppo del codice, i test e l'implementazione in produzione. Questo documento spiega:
- Considerazioni per l'integrazione e la distribuzione continua (CI/CD) per supportare la creazione, i test e il deployment automatizzati della pipeline in diversi ambienti.
- Funzionalità di Dataflow per ottimizzare le prestazioni e l'utilizzo delle risorse in produzione.
- Approcci e punti di controllo per l'aggiornamento delle pipeline in modalità flusso in produzione.
- Best practice per migliorare l'affidabilità della pipeline in produzione.
Integrazione continua
L'integrazione continua (CI) richiede agli sviluppatori di unire spesso il codice in un repository condiviso, il che è utile per le applicazioni che cambiano molto, ad esempio i siti web aggiornati di frequente. Sebbene in genere le pipeline di dati non cambino tanto quanto altri tipi di applicazioni, le pratiche di CI offrono molti vantaggi per lo sviluppo delle pipeline. Ad esempio, l'automazione dei test fornisce un feedback rapido quando vengono rilevati difetti e riduce la probabilità che le regressioni vengano inserite nella base di codice.
L'automazione dei test è una parte importante dellCI;integrazione continua. Se combinata con una copertura dei test appropriata, l'automazione dei test esegue la suite di test su ogni commit del codice. Il server CI può funzionare in combinazione con uno strumento di automazione della compilazione come Maven per eseguire la suite di test come uno o più passaggi della pipeline CI. Puoi pacchettizzare il codice che supera i test delle unità e i test di integrazione negli elementi di deployment da cui vengono lanciate le pipeline. Questa build è indicata come build che supera i test.
Il numero e i tipi di elementi di deployment creati da una compilazione riuscita variano a seconda di come vengono lanciate le pipeline. Con l'SDK Apache Beam per Java, puoi pacchettizzare il codice della pipeline in un file JAR autoeseguibile. Puoi quindi archiviare il file JAR in un bucket ospitato nel progetto per un ambiente di deployment, come il progetto Google Cloud di preproduzione o produzione. Se utilizzi i modelli classici (un tipo di esecuzione basata su modelli), gli elementi di deployment includono un file modello JSON, il file JAR per la pipeline e un modello di metadati facoltativo. Puoi quindi eseguire il deployment degli elementi in diversi ambienti di deployment utilizzando il continuous delivery, come spiegato nella sezione seguente.
Distribuzione e deployment continui
La distribuzione continua (CD) copia gli elementi di deployment in uno o più ambienti di deployment pronti per essere avviati manualmente. In genere, gli elementi creati dal server CI vengono dipiazzati in uno o più ambienti di preproduzione per l'esecuzione di test end-to-end. L'ambiente di produzione viene aggiornato se tutti i test end-to-end vengono superati.
Per le pipeline batch, il deployment continuo può avviare direttamente la pipeline come nuovo job Dataflow. In alternativa, altri sistemi possono utilizzare gli elementi per avviare job batch quando necessario. Ad esempio, puoi utilizzare Cloud Composer per eseguire job batch all'interno di un flusso di lavoro o Cloud Scheduler per pianificare i job batch.
Le pipeline di streaming possono essere più complesse da implementare rispetto alle pipeline batch e quindi più difficili da automatizzare utilizzando il deployment continuo. Ad esempio, potresti dover capire come sostituire o aggiornare una pipeline di streaming esistente. Se non riesci ad aggiornare una pipeline o se scegli di non farlo, puoi utilizzare altri metodi, come il coordinamento di più job Dataflow, per ridurre al minimo o prevenire l'interruzione dell'attività.
Identità e ruoli richiesti per CI/CD
La pipeline CI/CD interagisce con diversi sistemi per creare, testare e eseguire il deployment delle pipeline. Ad esempio, la pipeline deve accedere al repository del codice sorgente. Per abilitare queste interazioni, assicurati che la pipeline abbia le identità e i ruoli appropriati. Anche le seguenti attività della pipeline potrebbero richiedere che la pipeline abbia identità e ruoli specifici.
Test di integrazione con servizi esterni, tra cui Google Cloud
Quando utilizzi Direct Runner per eseguire test ad hoc o test di integrazione di sistema, la pipeline utilizza le credenziali di Google Cloud CLI per utilizzare origini dati e destinazioni Google Cloud oppure le credenziali fornite dalla variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS. Assicurati che l'account di servizio utilizzato per ottenere le credenziali per le risorse Google Cloud a cui accede la pipeline disponga di ruoli e autorizzazioni sufficienti.
Esegui il deployment degli elementi in ambienti di deployment diversi
Se possibile, utilizza credenziali univoche per ogni ambiente (in pratica per ogni progetto) e limita di conseguenza l'accesso alle risorse.
Utilizza account di servizio univoci per ogni progetto per leggere e scrivere gli elementi di deployment nei bucket di archiviazione. A seconda che la pipeline utilizzi un modello, il processo di deployment potrebbe dover eseguire il commit di più elementi. Ad esempio, la creazione e l'implementazione di un modello Dataflow richiedono le autorizzazioni per scrivere in un bucket Cloud Storage gli elementi di deployment necessari per avviare la pipeline, ad esempio il file del modello della pipeline.
Esegui il deployment delle pipeline in ambienti di deployment diversi
Se possibile, utilizza account di servizio univoci per ogni progetto per accedere e gestire le risorse Google Cloud all'interno del progetto, incluso l'accesso a Dataflow stesso.
L'account di servizio che utilizzi per creare e gestire i job Dataflow deve disporre di autorizzazioni IAM sufficienti per la gestione dei job. Per maggiori dettagli, consulta la sezione Account di servizio Dataflow nella pagina Sicurezza e autorizzazioni di Dataflow.
L'account di servizio worker che utilizzi per eseguire i job Dataflow deve disporre dell'autorizzazione per gestire le risorse Compute Engine durante l'esecuzione del job e per gestire l'interazione tra la pipeline Apache Beam e il servizio Dataflow. Per maggiori dettagli, consulta la sezione Account di servizio worker nella pagina Sicurezza e autorizzazioni di Dataflow.
Per specificare un
account di servizio worker gestito dall'utente
per un job, utilizza
l'opzione della pipeline --serviceAccount.
Se non specifichi un account di servizio del worker quando crei un job, Dataflow tenta di utilizzare l'account di servizio predefinito di Compute Engine.
Ti consigliamo invece di specificare un account di servizio worker gestito dall'utente per gli ambienti di produzione, in quanto l'account di servizio predefinito di Compute Engine in genere ha un insieme di autorizzazioni più ampio rispetto a quelle richieste per i job Dataflow.
Negli scenari di produzione, ti consigliamo di utilizzare account di servizio distinti per la gestione dei job Dataflow e per l'account di servizio worker, che offre una maggiore sicurezza rispetto all'utilizzo di un singolo account di servizio. Ad esempio, l'account di servizio utilizzato per creare job di Dataflow potrebbe non dover accedere alle origini dati e alle destinazioni o utilizzare altre risorse utilizzate dalla pipeline. In questo scenario, all'account di servizio worker utilizzato per eseguire i job Dataflow vengono concesse le autorizzazioni per utilizzare le risorse della pipeline. A un account di servizio diverso per la creazione dei job vengono concesse le autorizzazioni per gestire (inclusa la creazione) i job Dataflow.
Esempio di pipeline CI/CD
Il seguente diagramma fornisce una visione generale e indipendente dagli strumenti di CI/CD per le pipeline di dati. Inoltre, il diagramma mostra la relazione tra le attività di sviluppo, gli ambienti di deployment e i runner della pipeline.
Il diagramma mostra le seguenti fasi:
Sviluppo del codice: durante lo sviluppo del codice, uno sviluppatore esegue il codice della pipeline localmente utilizzando Direct Runner. Inoltre, gli sviluppatori utilizzano un ambiente sandbox per l'esecuzione di pipeline ad hoc utilizzando Dataflow Runner.
Nelle pipeline CI/CD standard, il processo di integrazione continua viene attivato quando uno sviluppatore apporta una modifica al sistema di controllo del codice sorgente, ad esempio esegue il push di nuovo codice in un repository.
Compilazione e test: il processo di integrazione continua compila il codice della pipeline, quindi esegue i test delle unità e i test di integrazione delle trasformazioni utilizzando Direct Runner. È possibile eseguire anche test facoltativi di integrazione di sistema, che includono test di integrazione con origini e destinazioni esterne utilizzando piccoli set di dati di test.
Se i test sono riusciti, il processo CI memorizza gli elementi di deployment, che possono includere file JAR, immagini Docker e metadati dei modelli, necessari per avviare la pipeline in posizioni accessibili al processo di distribuzione continua. A seconda dei tipi di elementi di deployment generati, puoi utilizzare Cloud Storage e Artifact Registry per archiviare i diversi tipi di elementi.
Importazione e deployment: il processo di importazione continua copia gli elementi di deployment in un ambiente di preproduzione o li rende disponibili per l'utilizzo in quell'ambiente. Gli sviluppatori possono eseguire manualmente test end-to-end utilizzando Dataflow Runner oppure possono utilizzare il deployment continuo per avviare il test automaticamente. In genere, un approccio di deployment continuo è più facile da attivare per le pipeline batch rispetto alle pipeline di streaming. Poiché le pipeline batch non vengono eseguite continuamente, è più facile sostituirle con una nuova release.
Il processo di aggiornamento delle pipeline di streaming può essere semplice o complesso, e devi testare gli aggiornamenti nell'ambiente di preproduzione. Le procedure di aggiornamento potrebbero non essere sempre coerenti tra le release. Ad esempio, una pipeline potrebbe cambiare in modo da rendere impossibili gli aggiornamenti in situ. Per questo motivo, a volte è difficile automatizzare gli aggiornamenti della pipeline utilizzando il deployment continuo.
Se tutti i test end-to-end hanno esito positivo, puoi copiare gli artefatti di deployment o metterli a disposizione dell'ambiente di produzione nell'ambito del processo di distribuzione continua. Se la nuova pipeline aggiorna o sostituisce una pipeline di streaming esistente, utilizza le procedure testate nell'ambiente di preproduzione per eseguire il deployment della nuova pipeline.
Esecuzione di job senza modello e con modello
Puoi creare un job Dataflow utilizzando l'SDK Apache Beam direttamente da un ambiente di sviluppo. Questo tipo di job è chiamato non basato su modello. Sebbene questo approccio sia pratico per gli sviluppatori, potresti preferire separare le attività di sviluppo ed esecuzione delle pipeline. Per effettuare questa separazione, puoi utilizzare modelli Dataflow, che ti consentono di eseguire il commit e di eseguire le pipeline come attività indipendenti. Dopo aver archiviato un modello, altri utenti, inclusi quelli che non sono sviluppatori, possono eseguire i job dal modello utilizzando Google Cloud CLI, la console Google Cloud o l'API REST Dataflow.
Dataflow offre i seguenti tipi di modelli di job:
- Modelli classici: gli sviluppatori utilizzano l'SDK Apache Beam per eseguire il codice della pipeline e salvare il grafo di esecuzione serializzato in JSON come modello. L'SDK Apache Beam esegue la gestione delle fasi del file modello in una posizione Cloud Storage, insieme a eventuali dipendenze richieste dal codice della pipeline.
- Flex Templates: gli sviluppatori utilizzano Google Cloud CLI per impacchettare la pipeline come immagine Docker, che viene poi archiviata in Artifact Registry. Viene anche generato automaticamente un file di specifiche del modello Flex e archiviato in una posizione Cloud Storage specificata dall'utente. Il file di specifiche del modello flessibile contiene metadati che descrivono come eseguire il modello, ad esempio i parametri della pipeline.
Oltre alle funzionalità dei modelli flessibili spiegate nella documentazione collegata, i modelli flessibili offrono vantaggi rispetto ai modelli classici per la gestione dei modelli.
- Con i modelli classici, è possibile archiviare più artefatti, ad esempio file JAR, in una posizione di staging di Cloud Storage, ma senza funzionalità per gestirli. Un modello flessibile, invece, è incapsulato in un'immagine Docker. L'immagine pacchettizza tutte le dipendenze, ad eccezione della specifica del modello Flex, necessarie per la pipeline in un artefatto di deployment gestito da Artifact Registry.
- Puoi utilizzare le funzionalità di gestione delle immagini Docker per i tuoi modelli flessibili. Ad esempio, puoi condividere in modo sicuro i modelli Flex concedendo autorizzazioni di pull (e facoltativamente di push) a Artifact Registry e utilizzare i tag immagine Docker per versioni diverse dei tuoi modelli Flex.
Gli sviluppatori possono utilizzare i modelli classici e i modelli flessibili per avviare job in un progetto diverso da quello che possiede il registry e il bucket di archiviazione che ospita gli asset dei modelli oppure solo il bucket di archiviazione se utilizzi i modelli classici. Questa funzionalità è utile se devi isolare l'elaborazione dei dati per più clienti in progetti e job di pipeline diversi. Con i modelli flessibili, puoi specificare ulteriormente diverse versioni di un'immagine Docker da utilizzare quando avvii una pipeline. Questa funzionalità semplifica la sostituzione graduale delle pipeline batch o streaming in più progetti quando aggiorni i modelli in un secondo momento.
Funzionalità di Dataflow per ottimizzare l'utilizzo delle risorse
Dataflow fornisce le seguenti funzionalità specifiche per i runner per ottimizzare l'utilizzo delle risorse, il che può migliorare le prestazioni e ridurre i costi:
- Streaming Engine: Streaming Engine trasferisce l'esecuzione delle pipeline di streaming dalle VM worker a un servizio dedicato. I vantaggi includono una maggiore reattività dell'autoscaling, una riduzione delle risorse VM worker consumate e aggiornamenti automatici dei servizi senza il ricollocamento. In alcuni casi, puoi anche ridurre l'utilizzo delle risorse utilizzando l'elaborazione almeno una volta per i casi d'uso che possono tollerare i duplicati. L'abilitazione di Streaming Engine è consigliata per le pipeline in modalità flusso. La funzionalità è abilitata per impostazione predefinita quando utilizzi le versioni più recenti dell'SDK Java o dell'SDK Python di Apache Beam.
- Dataflow Shuffle: Dataflow Shuffle sposta le operazioni di shuffling per le pipeline batch dalle VM worker a un servizio dedicato. I vantaggi includono un'esecuzione più rapida per la maggior parte delle pipeline batch, un minore consumo di risorse da parte delle VM worker, una maggiore reattività della scalabilità automatica e una maggiore tolleranza agli errori. L'attivazione di Dataflow Shuffle è consigliata per le pipeline batch. La funzionalità è attiva per impostazione predefinita utilizzando l'SDK Java Apache Beam e l'SDK Python più recente.
- Flexible Resource Scheduling (FlexRS): FlexRS riduce i costi di elaborazione batch grazie a tecniche di pianificazione avanzate, al servizio Dataflow Shuffle e a una combinazione di istanze VM prerilasciabile e VM normali.
Aggiornare le pipeline in modalità flusso in produzione
Consulta Eseguire l'upgrade di una pipeline di inserimento flussi.
Ciclo di vita di un job Dataflow
Un job Dataflow attraversa un ciclo di vita rappresentato da diversi stati del job.
Per eseguire un job Dataflow, invialo a una
regione.
Il job viene quindi indirizzato a un backend Dataflow disponibile in una delle zone della regione. Prima che Dataflow assegni un backend, verifica che tu disponga di quote e autorizzazioni sufficienti per eseguire il job. Quando
questi controlli preliminari sono stati completati e è stato assegnato un backend, il job
passa a uno stato JOB_STATE_PENDING. Per i job
FlexRS, l'assegnazione del backend potrebbe essere ritardata in un momento successivo e questi job
entrano in uno stato JOB_STATE_QUEUED.
Il backend assegnato recupera il job da eseguire e tenta di avviare i worker Dataflow nel tuo progetto Google Cloud. La zona scelta per le VM worker dipende da una serie di fattori. Per i job batch che utilizzano Dataflow Shuffle, il servizio cerca anche di garantire che il backend di Dataflow e le VM worker si trovino nella stessa zona per evitare il traffico tra zone.
Dopo l'avvio, i worker di Dataflow richiedono lavoro al backend di Dataflow. Il backend è responsabile della suddivisione del lavoro in blocchi parallelizzabili, chiamati bundle, che vengono distribuiti tra i worker. Se i worker non sono in grado di gestire il lavoro esistente e se la scalabilità automatica è attivata, il backend avvia più worker per gestire il lavoro. Analogamente, se vengono avviati più worker del necessario, alcuni vengono chiusi.
Dopo l'avvio dei worker Dataflow, il backend Dataflow funge da piano di controllo per orchestrare l'esecuzione del job. Durante l'elaborazione, il piano di dati del job esegue operazioni di ordinamento casuale come GroupByKey, CoGroupByKey e Combine.
I job utilizzano una delle seguenti implementazioni del piano dati per le operazioni di ordinamento casuale:
- Il piano dati viene eseguito sui worker Dataflow e i dati su cui viene eseguito lo shuffle vengono archiviati su dischi permanenti.
- Il piano dati viene eseguito come servizio, esterno alle VM worker. Questa implementazione ha due varianti, che puoi specificare quando crei il job: Dataflow Shuffle per le pipeline batch e Streaming Engine per le pipeline in modalità flusso. Lo shuffle basato su servizi migliora notevolmente le prestazioni e la scalabilità delle operazioni di ordinamento dei dati rispetto allo shuffle basato su worker.
I job di streaming che entrano in uno stato JOB_STATE_RUNNING continuano a essere eseguiti
indefinitamente finché non vengono
annullati
o
svuotati,
a meno che non si verifichi un errore del job. I job batch si arrestano automaticamente al termine dell'elaborazione o se si verifica un errore non recuperabile. A seconda del modo in cui viene interrotto il job, Dataflow imposta lo stato del job su uno di più stati terminali, tra cui JOB_STATE_CANCELLED, JOB_STATE_DRAINED o JOB_STATE_DONE.
Best practice per l'affidabilità della pipeline
Questa sezione illustra gli errori che potrebbero verificarsi quando si utilizza Dataflow e le best practice per i job Dataflow.
Seguire i principi di isolamento
Un consiglio generale per migliorare l'affidabilità complessiva della pipeline è seguire i principi di isolamento alla base di regioni e zone. Assicurati che le pipeline non abbiano dipendenze tra regioni critiche. Se hai una pipeline con una dipendenza critica dai servizi di più regioni, un guasto in una di queste regioni può influire sulla pipeline. Per evitare questo problema, esegui il deployment in più regioni per la ridondanza e il backup.
Crea snapshot di Dataflow
Dataflow offre una funzionalità di snapshot che fornisce un backup dello stato di una pipeline. Puoi ripristinare lo snapshot della pipeline in una nuova pipeline Dataflow in streaming in un'altra zona o regione. Puoi quindi avviare il rielaborare dei messaggi negli argomenti Pub/Sub o Kafka a partire dal timestamp dello snapshot. Se configuri snapshot regolari delle tue pipeline, puoi ridurre al minimo il tempo di recupero obiettivo (RTO).
Per ulteriori informazioni sugli snapshot di Dataflow, consulta Utilizzare gli snapshot di Dataflow.
Gestire gli errori di invio dei job
Invii job Dataflow non basati su modelli utilizzando l'SDK Apache Beam. Per inviare il job, esegui la pipeline utilizzando il runner Dataflow, che viene specificato nell'ambito delle opzioni della pipeline. L'SDK Apache Beam archivia i file in Cloud Storage, crea un file di richiesta di job e lo invia a Dataflow.
In alternativa, i job creati dai modelli Dataflow utilizzano diversi metodi di invio, che in genere si basano sull'API di modelli.
Potresti visualizzare diversi errori restituiti da Dataflow che indicano l'errore del job per i job basati su modelli e non. Questa sezione discute diversi tipi di errori di invio dei job e le best practice per gestirli o ridurli al minimo.
Riprovare l'invio dei job dopo errori temporanei
Se un job non si avvia a causa di un problema del servizio Dataflow, riprova alcune volte. Il nuovo tentativo riduce i problemi temporanei del servizio.
Riduci gli errori a livello di zona specificando una regione di lavoro
Dataflow offre disponibilità a livello di regione ed è disponibile in più regioni. Quando un utente invia un job a una regione senza specificare esplicitamente una zona, Dataflow inoltra il job a una zona nella regione specificata in base alla disponibilità delle risorse.
L'opzione consigliata per il posizionamento dei job è specificare una regione di worker utilizzando il flag --region anziché il flag --zone, se possibile. Questo passaggio consente a Dataflow di fornire un livello aggiuntivo di tolleranza ai guasti per le pipeline scegliendo automaticamente la zona migliore possibile per il job. I job che specificano una zona esplicita non hanno questo vantaggio e non riescono se si verificano problemi all'interno della zona. Se l'invio di un job non va a buon fine a causa di un problema con la zona, spesso puoi risolvere il problema riprovando a eseguire il job senza specificare esplicitamente una zona.
Riduci al minimo gli errori regionali archiviando i dati in più regioni
Se un'intera regione non è disponibile, prova il job in un'altra regione. È importante pensare alla disponibilità dei dati quando i job non vanno a buon fine nelle varie regioni. Per proteggerti da errori in una singola regione senza copiare manualmente i dati in più regioni, utilizza le risorse Google Cloud che archiviano automaticamente i dati in più regioni. Ad esempio, utilizza le località multiregionali di BigQuery per i set di dati o i bucket Cloud Storage a due regioni e multiregioni. Se una regione non è più disponibile, puoi eseguire di nuovo la pipeline in un'altra regione in cui i dati sono disponibili.
Per un esempio di utilizzo di servizi multi-regionali con Dataflow, consulta Elevata disponibilità e ridondanza geografica.
Gestire gli errori nelle pipeline in esecuzione
Dopo che un job è stato inviato e accettato, le uniche operazioni valide per il job sono le seguenti:
- annulla per i job batch
- Aggiorna, svuota o annulla per i job di streaming
Non puoi modificare la posizione dei job in esecuzione dopo averli inviati. Se non utilizzi FlexRS, in genere i job iniziano a elaborare i dati entro pochi minuti dall'invio. L'avvio dell'elaborazione dei dati dei job FlexRS può richiedere fino a sei ore.
Questa sezione illustra gli errori relativi all'esecuzione dei job e le best practice per gestirli.
Monitora i job per identificare e risolvere i problemi causati da errori temporanei
Per i job batch, i bundle che includono un elemento con errori vengono riprovati quattro volte. Dataflow termina il job quando un singolo bundle ha avuto esito negativo quattro volte. Questa procedura risolve molti problemi temporanei. Tuttavia, se si verifica un errore prolungato, il limite di tentativi massimi viene solitamente raggiunto rapidamente, il che consente al job di non riuscire rapidamente.
Per il monitoraggio e la gestione degli incidenti, configura le regole di avviso per rilevare i job non riusciti. Se un job non viene completato, esamina i log del job per identificare gli errori del job causati da elementi di lavoro non riusciti che hanno superato il limite di tentativi.
Per i job di streaming, Dataflow riprova gli elementi di lavoro non riusciti indefinitamente. Il job non è stato terminato. Tuttavia, il job potrebbe bloccarsi finché il problema non viene risolto. Crea regole di monitoraggio per rilevare i segnali di una pipeline in stallo, ad esempio un aumento della latenza del sistema e una diminuzione dell'aggiornamento dei dati. Implementa la registrazione degli errori nel codice della pipeline per identificare gli arresti anomali della pipeline causati da elementi di lavoro che non vanno a buon fine ripetutamente.
Riavviare i job in un'altra zona in caso di interruzione di servizio a livello di zona
Dopo l'avvio di un job, i worker di Dataflow che eseguono il codice utente sono vincolati a un'unica zona. Se si verifica un'interruzione di servizio zonale, i job Dataflow sono spesso interessati, a seconda dell'entità dell'interruzione.
Per le interruzioni che interessano solo i backend di Dataflow, il servizio gestito esegue automaticamente la migrazione dei backend in un'altra zona in modo che possano continuare il job. Se il job utilizza Dataflow Shuffle, il backend non può essere spostato tra le zone. Se si verifica una migrazione del backend Dataflow, i job potrebbero essere temporaneamente inattivi.
In caso di interruzione di servizio a livello di zona, è probabile che i job in esecuzione non vadano a buon fine o si blocchino fino al ripristino della disponibilità della zona. Se una zona non è disponibile per un periodo di tempo prolungato, arresta i job (annulla per i job batch e svuotamento per i job in streaming) e poi riavviali per consentire a Dataflow di scegliere una nuova zona funzionante.
Riavviare i job batch in un'altra regione in caso di interruzione a livello di regione
Se si verifica un'interruzione a livello di regione in cui sono in esecuzione i job Dataflow, i job possono non riuscire o bloccarsi. Per i job batch, se possibile, riavvia il job in un'altra regione. È importante assicurarsi che i dati siano disponibili in regioni diverse.
Riduci le interruzioni a livello di regione utilizzando l'alta disponibilità o il failover
Per i job in streaming, a seconda della tolleranza agli errori e del budget della tua applicazione, hai a disposizione diverse opzioni per ridurre al minimo gli errori. In caso di interruzione regionale, l'opzione più semplice ed economica è attendere che l'interruzione sia terminata. Tuttavia, se la tua applicazione è sensibile alla latenza o se l'elaborazione dei dati non deve essere interrotta o deve essere ripresa con un ritardo minimo, le sezioni seguenti illustrano le opzioni a tua disposizione.
Alta disponibilità: sensibile alla latenza senza perdita di dati
Se la tua applicazione non può tollerare la perdita di dati, esegui pipeline duplicate in parallelo in due regioni diverse e fai in modo che le pipeline utilizzino gli stessi dati. Le stesse origini dati devono essere disponibili in entrambe le regioni. Le applicazioni a valle che dipendono dall'output di queste pipeline devono essere in grado di passare dall'output di una regione all'altra. A causa della duplicazione delle risorse, questa opzione comporta il costo più elevato rispetto alle altre opzioni. Per un esempio di implementazione, consulta la sezione Elevata disponibilità e ridondanza geografica.
Failover: sensibile alla latenza con potenziale perdita di dati
Se la tua applicazione può tollerare una potenziale perdita di dati, rendi disponibile l'origine dati in streaming in più regioni. Ad esempio, utilizzando Pub/Sub, mantieni due iscrizioni indipendenti per lo stesso argomento, una per ogni regione. Se si verifica un'interruzione a livello di regione, avvia una pipeline sostitutiva in un'altra regione e fai in modo che la pipeline consumi i dati dell'abbonamento di backup.
Riproduci l'iscrizione al backup in un momento opportuno per ridurre al minimo la perdita di dati senza sacrificare la latenza. Le applicazioni downstream devono sapere come passare all'output della pipeline in esecuzione, in modo simile all'opzione di alta disponibilità. Questa opzione utilizza meno risorse rispetto all'esecuzione di pipeline duplicate perché vengono duplicati solo i dati.
Alta disponibilità e ridondanza geografica
Puoi eseguire più pipeline di streaming in parallelo per l'elaborazione di dati ad alta disponibilità. Ad esempio, puoi eseguire due job di streaming in parallelo in regioni diverse, il che fornisce ridondanza geografica e tolleranza ai guasti per l'elaborazione dei dati.
Se prendi in considerazione la disponibilità geografica delle origini dati e degli sink, puoi gestire pipeline end-to-end in una configurazione multiregione ad alta disponibilità. Il seguente diagramma mostra un esempio di implementazione.
Il diagramma mostra il seguente flusso:
Pub/Sub viene eseguito nella maggior parte delle regioni del mondo, il che consente al servizio di offrire un accesso rapido e globale ai dati, garantendo al contempo il controllo sulla posizione in cui vengono archiviati i messaggi. Pub/Sub può archiviare automaticamente i messaggi pubblicati nella regione Google Cloud più vicina agli iscritti oppure puoi configurarlo in modo da utilizzare una regione o un insieme di regioni specifico utilizzando le norme di archiviazione dei messaggi.
Pub/Sub recapita quindi i messaggi agli abbonati di tutto il mondo, indipendentemente da dove sono archiviati. I client Pub/Sub non devono essere a conoscenza delle posizioni dei server a cui si connettono, perché i meccanismi di bilanciamento del carico globale indirizzano il traffico al data center Google Cloud più vicino in cui vengono archiviati i messaggi.
Dataflow viene eseguito in regioni Google Cloud specifiche. Eseguendo pipeline parallele in regioni Google Cloud separate, puoi isolare i job dagli errori che interessano una singola regione. Il diagramma mostra due istanze della stessa pipeline, ciascuna in esecuzione in una regione Google Cloud distinta.
BigQuery fornisce località dei set di dati regionali e multiregionali. Quando scegli una località multiregionale, il set di dati si trova in almeno due regioni geografiche. Il diagramma mostra due pipeline separate, ciascuna delle quali scrive in un set di dati multiregionale distinto.