Lo sviluppo della pipeline prevede diverse fasi e attività, come lo sviluppo del codice, il test e la distribuzione in produzione. Questo documento spiega:
- Considerazioni sull'integrazione e la distribuzione continua (CI/CD) per supportare build, test e deployment delle pipeline automatizzati in ambienti diversi.
- le 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 frequentemente il codice in un repository condiviso, il che è utile per le applicazioni che cambiano molto, come i siti web che vengono aggiornati di frequente. Sebbene le pipeline di dati in genere 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 dei difetti e riduce la probabilità che le regressioni entrino nel codebase.
L'automazione dei test è una parte importante dell'CI. Se viene combinata con la copertura di test appropriata, l'automazione dei test esegue la tua suite di test su ogni commit di codice. Il tuo server CI può funzionare insieme a uno strumento di automazione della build come Maven per eseguire la tua suite di test come uno o più passaggi della pipeline CI. Puoi pacchettizzare il codice che supera correttamente i test delle unità e di integrazione negli artefatti di deployment da cui vengono avviate le pipeline. Questa build è nota come build con passaggio.
Il numero e i tipi di artefatti di deployment creati da una build di passaggio variano a seconda di come vengono avviate le pipeline. Utilizzando l'SDK Java Apache Beam, puoi pacchettizzare il codice della pipeline in un file JAR a esecuzione automatica. Puoi quindi archiviare il file JAR in un bucket ospitato nel progetto per un ambiente di deployment, ad esempio il progetto Google Cloud di preproduzione o produzione. Se utilizzi i modelli classici (un tipo di esecuzione con modelli), gli artefatti di deployment includono un file modello JSON, il file JAR della pipeline e un modello di metadati facoltativo. Puoi quindi eseguire il deployment degli artefatti in diversi ambienti di deployment utilizzando la distribuzione continua, come spiegato nella sezione seguente.
Distribuzione e deployment continui
La distribuzione continua (CD) copia gli artefatti di deployment in uno o più ambienti di deployment pronti per essere avviati manualmente. In genere, gli artefatti creati dal server CI vengono sottoposti a deployment in uno o più ambienti di pre-produzione per l'esecuzione di test end-to-end. L'ambiente di produzione viene aggiornato se tutti i test end-to-end hanno esito positivo.
Per le pipeline batch, il deployment continuo può avviare direttamente la pipeline come un nuovo job Dataflow. In alternativa, altri sistemi possono utilizzare gli artefatti 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 job batch.
Il deployment delle pipeline in modalità flusso può essere più complesso rispetto alle pipeline batch, di conseguenza può essere più difficile da automatizzare tramite il deployment continuo. Ad esempio, potrebbe essere necessario determinare come sostituire o aggiornare una pipeline di inserimento flussi esistente. Se non riesci ad aggiornare una pipeline o se scegli di non aggiornarla, puoi utilizzare altri metodi, come il coordinare più job Dataflow, per ridurre al minimo o evitare interruzioni dell'attività.
Identità e ruoli richiesti per CI/CD
La pipeline CI/CD interagisce con diversi sistemi per creare, testare ed eseguire il deployment delle pipeline. Ad esempio, la tua pipeline deve poter accedere al tuo repository di codice sorgente. Per abilitare queste interazioni, assicurati che la pipeline disponga delle identità e dei ruoli appropriati. Le seguenti attività della pipeline potrebbero anche richiedere alla pipeline di avere identità e ruoli specifici.
Test di integrazione con servizi esterni, tra cui Google Cloud
Quando utilizzi l'esecuzione diretta per eseguire test ad hoc o di integrazione del sistema, la pipeline utilizza le credenziali di Google Cloud CLI per utilizzare le origini dati e i sink di 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 artefatti in diversi ambienti di deployment
Se possibile, utilizza credenziali univoche per ogni ambiente (in modo efficace per ogni progetto) e limita l'accesso alle risorse di conseguenza.
Utilizza account di servizio univoci per ogni progetto per leggere e scrivere gli artefatti di deployment nei bucket di archiviazione. A seconda che la pipeline utilizzi o meno un modello, il processo di deployment potrebbe dover archiviare più artefatti in un'area intermedia. Ad esempio, la creazione e la gestione temporanea di un modello Dataflow richiedono le autorizzazioni per scrivere gli artefatti di deployment necessari per avviare la pipeline, come il file del modello della pipeline, in un bucket Cloud Storage.
Deployment di pipeline in diversi ambienti di deployment
Se possibile, utilizza account di servizio univoci per ogni progetto per accedere alle risorse Google Cloud e gestirle all'interno del progetto, nonché per accedere a Dataflow stesso.
L'account di servizio che utilizzi per creare e gestire i job Dataflow deve avere 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 richiede l'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 pipeline --serviceAccount.
Se non specifichi un account di servizio 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, poiché l'account di servizio predefinito di Compute Engine di solito ha un insieme più ampio di autorizzazioni rispetto a quelle necessarie per i job Dataflow.
Negli scenari di produzione, consigliamo di utilizzare account di servizio separati per la gestione dei job di Dataflow e per l'account di servizio worker, in modo da offrire una sicurezza migliore rispetto all'uso di un singolo account di servizio. Ad esempio, l'account di servizio utilizzato per creare job Dataflow potrebbe non aver bisogno di accedere a origini dati e sink o di 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 di job vengono concesse le autorizzazioni per gestire (inclusa la creazione) dei job Dataflow.
Esempio di pipeline CI/CD
Il seguente diagramma fornisce una visione generale e indipendente dallo strumento di CI/CD per le pipeline di dati. Inoltre, il diagramma mostra la relazione tra le attività di sviluppo, gli ambienti di deployment e gli esecutori delle pipeline.
Il diagramma illustra le seguenti fasi:
Sviluppo del codice: durante lo sviluppo del codice, uno sviluppatore esegue il codice della pipeline in locale utilizzando l'esecuzione diretta. Inoltre, gli sviluppatori utilizzano un ambiente sandbox per l'esecuzione di pipeline ad hoc utilizzando Dataflow Runner.
Nelle pipeline CI/CD tipiche, 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.
Creazione e test: il processo di integrazione continua compila il codice della pipeline, quindi esegue i test delle unità e trasforma i test di integrazione utilizzando l'esecuzione diretta. È anche possibile eseguire test di integrazione del sistema facoltativi, che includono i test di integrazione con origini e sink esterni utilizzando piccoli set di dati di test.
Se i test hanno esito positivo, il processo CI archivia gli artefatti di deployment, che potrebbero includere file JAR, immagini Docker e metadati del modello, necessari per lanciare la pipeline in località accessibili al processo di distribuzione continua. A seconda dei tipi di artefatti di deployment generati, potresti utilizzare Cloud Storage e Artifact Registry per archiviare i diversi tipi di artefatti.
Distribuzione e deployment: il processo di distribuzione continua copia gli artefatti di deployment in un ambiente di preproduzione o rende questi artefatti disponibili per l'utilizzo all'interno di quell'ambiente. Gli sviluppatori possono eseguire manualmente test end-to-end utilizzando Dataflow Runner oppure possono utilizzare il deployment continua per avviare il test automaticamente. In genere, un approccio al deployment continuo è più facile da abilitare per le pipeline in modalità batch che per le pipeline in modalità flusso. Poiché le pipeline batch non vengono eseguite continuamente, è più facile sostituirle con una nuova release.
Il processo di aggiornamento delle pipeline in modalità flusso può essere semplice o complesso ed è necessario testare gli aggiornamenti nell'ambiente di pre-produzione. Le procedure di aggiornamento potrebbero non essere sempre coerenti tra le release. Ad esempio, una pipeline potrebbe cambiare in modo tale da rendere impossibili gli aggiornamenti in loco. Per questo motivo, a volte è difficile automatizzare gli aggiornamenti della pipeline usando il deployment continuo.
Se tutti i test end-to-end vengono superati, puoi copiare gli artefatti di deployment o renderli disponibili nell'ambiente di produzione come parte del processo di distribuzione continua. Se la nuova pipeline aggiorna o sostituisce una pipeline in modalità flusso esistente, utilizza le procedure testate nell'ambiente di pre-produzione per eseguire il deployment della nuova pipeline.
Esecuzione di job non basati su modelli ed esecuzione di job basata su modelli
Puoi creare un job Dataflow utilizzando l'SDK Apache Beam direttamente da un ambiente di sviluppo. Questo tipo di job è chiamato job senza modelli. Sebbene questo approccio sia conveniente per gli sviluppatori, potresti preferire separare le attività di sviluppo ed esecuzione delle pipeline. Per effettuare questa separazione, puoi utilizzare i modelli Dataflow, che ti consentono di archiviare in un'area intermedia ed eseguire le tue pipeline come attività indipendenti. Dopo la creazione temporanea di un modello, gli altri utenti, inclusi gli utenti non sviluppatori, possono eseguire i job dal modello utilizzando Google Cloud CLI, la console Google Cloud o l'API REST di 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 grafico di esecuzione seriale JSON come modello. L'SDK Apache Beam ospita il file del modello in una posizione di Cloud Storage, insieme alle eventuali dipendenze richieste dal codice della pipeline.
- Modelli flessibili: gli sviluppatori utilizzano Google Cloud CLI per pacchettizzare la pipeline come immagine Docker, che viene quindi archiviata in Artifact Registry. Viene inoltre generato e archiviato automaticamente un file delle specifiche del modello flessibile in una località di Cloud Storage specificata dall'utente. Il file delle specifiche del modello flessibile contiene metadati che descrivono come eseguire il modello, ad esempio i parametri della pipeline.
Oltre alle funzionalità dei modelli Flex descritte nella documentazione collegata, i modelli flessibili offrono alcuni vantaggi rispetto ai modelli classici per la gestione dei modelli.
- Con i modelli classici, più artefatti, come i file JAR, possono essere archiviati in una posizione temporanea di Cloud Storage, ma senza funzionalità per la gestione di più artefatti. mentre un modello flessibile viene incapsulato all'interno di un'immagine Docker. L'immagine pacchettizza tutte le dipendenze, a parte la specifica FlexTemplate, necessarie per la pipeline, in un unico artefatto di deployment gestito da Artifact Registry.
- Puoi usare le funzionalità di gestione delle immagini Docker per i tuoi modelli flessibili. Ad esempio, puoi condividere in modo sicuro i modelli flessibili concedendo le autorizzazioni pull (e facoltativamente push) ad Artifact Registry e utilizzare i tag immagine Docker per le diverse versioni dei modelli flessibili.
Gli sviluppatori possono utilizzare i modelli classici e i modelli flessibili per avviare job in un progetto diverso da quello proprietario del registro e del bucket di archiviazione che ospita gli asset del modello oppure solo il bucket di archiviazione se utilizzi i modelli classici. Questa funzionalità è utile se devi isolare l'elaborazione dei dati di più clienti in progetti e job di pipeline diversi. Con i modelli flessibili, puoi specificare anche diverse versioni di un'immagine Docker da utilizzare all'avvio di una pipeline. Questa funzionalità semplifica la sostituzione graduale delle pipeline batch o delle pipeline in modalità flusso 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 dei runner per ottimizzare l'utilizzo delle risorse, il che può migliorare le prestazioni e ridurre i costi:
- Streaming Engine: Streaming Engine sposta l'esecuzione di pipeline in modalità flusso dai worker delle VM a un servizio dedicato. I vantaggi includono una migliore reattività della scalabilità automatica, riduzioni delle risorse VM worker utilizzate e aggiornamenti automatici dei servizi senza rideployment. In alcuni casi, puoi anche ridurre l'utilizzo delle risorse utilizzando l'elaborazione at-least-once per i casi d'uso che tollerano i duplicati. È consigliabile abilitare Streaming Engine per le pipeline in modalità flusso. La funzionalità è abilitata per impostazione predefinita quando utilizzi le versioni più recenti dell'SDK Java Apache Beam o dell'SDK Python.
- Dataflow shuffling: Dataflow Shuffle sposta le operazioni di shuffling per le pipeline in modalità batch dai worker VM a un servizio dedicato. I vantaggi includono un'esecuzione più rapida per la maggior parte delle pipeline batch, un consumo di risorse ridotto da parte delle VM worker, una migliore reattività della scalabilità automatica e una maggiore tolleranza agli errori. Ti consigliamo di abilitare Dataflow shuffling per le pipeline in modalità batch. La funzionalità viene attivata per impostazione predefinita utilizzando l'SDK Java Apache Beam e l'SDK Python più recente.
- Pianificazione flessibile delle risorse (FlexRS): FlexRS riduce i costi dell'elaborazione batch utilizzando tecniche di pianificazione avanzate, il servizio Dataflow Shuffle e una combinazione di istanze VM prerilasciabile e VM normali.
Aggiorna pipeline in modalità flusso in produzione
Consulta Eseguire l'upgrade di una pipeline in modalità flusso.
Durata di un job Dataflow
Un job Dataflow attraversa un ciclo di vita rappresentato da vari stati del job.
Per eseguire un job Dataflow, invialo a una regione.
Il job viene quindi instradato a un backend Dataflow disponibile in una delle zone all'interno della regione. Prima di assegnare un backend, Dataflow verifica che tu disponga di quota e autorizzazioni sufficienti per eseguire il job. Una volta completati questi controlli preflight e assegnato un backend, il job passa allo stato JOB_STATE_PENDING. Per i job FlexRS, l'assegnazione del backend potrebbe essere ritardata a un momento futuro e questi job hanno lo stato JOB_STATE_QUEUED.
Il backend assegnato prende 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 shuffling, il servizio cerca anche di garantire che le VM del backend Dataflow e dei worker si trovino nella stessa zona per evitare il traffico tra zone.
Dopo l'avvio, i worker Dataflow richiedono il lavoro dal backend Dataflow. Il backend è responsabile della suddivisione del lavoro in blocchi caricabili in contemporanea, denominati gruppi, distribuiti tra i worker. Se i worker non sono in grado di gestire il lavoro esistente e se la scalabilità automatica è abilitata, il backend avvia più worker per gestire il lavoro. Allo stesso modo, se vengono avviati più worker del necessario, alcuni vengono arrestati.
Dopo l'avvio dei worker Dataflow, il backend Dataflow agisce come piano di controllo per orchestrare l'esecuzione del job. Durante l'elaborazione, il piano dati del job esegue operazioni di shuffling come GroupByKey, CoGroupByKey e Combine.
Per le operazioni di shuffling, i job utilizzano una delle seguenti implementazioni del piano dati:
- Il piano dati viene eseguito sui worker Dataflow e i dati di shuffling vengono archiviati su dischi permanenti.
- Il piano dati viene eseguito come servizio, esternamente alle VM worker. Questa implementazione ha due varianti, che dovrai specificare al momento della creazione del job: Dataflow shuffling per le pipeline in modalità batch e Streaming Engine per le pipeline in modalità flusso. Lo shuffling basato su servizi migliora notevolmente le prestazioni e la scalabilità delle operazioni di data shuffling rispetto allo shuffling 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
eliminati,
a meno che non si verifichi un errore del job. I job batch si interrompono automaticamente al termine
dell'intera elaborazione o se si verifica un errore irreversibile. A seconda di come viene interrotto il job, Dataflow imposta lo stato del job su uno dei vari stati del terminale, 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 utilizzi 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 tue pipeline non abbiano dipendenze critiche tra regioni. Se hai una pipeline con dipendenza critica dai servizi provenienti da più regioni, un errore in una di queste regioni può influire sulla pipeline. Per evitare questo problema, esegui il deployment in più regioni per ridondanza e backup.
Crea snapshot 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 modalità flusso in un'altra zona o regione. Puoi quindi avviare la rielaborazione 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 del Recovery Time Objective (RTO).
Per ulteriori informazioni sugli snapshot Dataflow, consulta Utilizzare gli snapshot Dataflow.
Gestire gli errori di invio del job
Puoi inviare job Dataflow non modello utilizzando l'SDK Apache Beam. Per inviare il job, esegui la pipeline utilizzando Dataflow Runner, specificato come parte delle opzioni della pipeline. L'SDK Apache Beam mette in evidenza 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'APItemplates.
Potresti vedere diversi errori restituiti da Dataflow, che indicano un errore del job sia per i job modello che per quelli non modello. Questa sezione tratta i diversi tipi di errori di invio dei job e le best practice per gestirli o ridurli.
Riprova a inviare i job dopo errori temporanei
Se un job non viene avviato a causa di un problema del servizio Dataflow, riprova alcune volte. Un nuovo tentativo riduce i problemi temporanei del servizio.
Riduci gli errori a livello di zona specificando una regione dei worker
Dataflow offre disponibilità a livello regionale ed è disponibile in più regioni. Quando un utente invia un job a una regione senza specificare esplicitamente una zona, Dataflow instrada il job a una zona della regione specificata in base alla disponibilità delle risorse.
L'opzione consigliata per il posizionamento del job è specificare una regione dei worker utilizzando il flag --region anziché il flag --zone, se possibile. Questo passaggio consente a Dataflow di fornire un ulteriore livello di tolleranza agli errori per le pipeline, scegliendo automaticamente la zona migliore per il job. I job che specificano una zona esplicita non offrono questo vantaggio e non riusciranno se si verificano problemi all'interno della zona. Se l'invio di un job non riesce a causa di un problema a livello di zona, spesso puoi risolvere il problema riprovando a eseguire il job senza specificare esplicitamente una zona.
Riduci gli errori a livello di regione archiviando i dati in più regioni
Se un'intera regione non è disponibile, prova il job in un'altra regione. È importante considerare la disponibilità dei dati in caso di errore dei job nelle varie regioni. Per proteggerti da errori relativi a 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 località con più regioni di BigQuery per set di dati o bucket di due regioni e più regioni di Cloud Storage. Se una regione non è più disponibile, puoi eseguire nuovamente la pipeline in un'altra regione in cui sono disponibili i dati.
Per un esempio di utilizzo di servizi multiregionali con Dataflow, consulta Alta disponibilità e ridondanza geografica.
Gestire gli errori delle pipeline in esecuzione
Dopo che un job viene inviato e accettato, le uniche operazioni valide per il job sono le seguenti:
- annulla per job batch
- aggiorna, svuota o annulla per job di flusso dei dati
Non puoi modificare la località dei job in esecuzione dopo aver inviato il job. Se non utilizzi FlexRS, i job di solito iniziano a elaborare i dati pochi minuti dopo l'invio. L'avvio dell'elaborazione dei dati nei job FlexRS può richiedere fino a sei ore.
Questa sezione illustra gli errori nell'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 ripetuti quattro volte. Dataflow termina il job quando un singolo bundle ha avuto esito negativo per quattro volte. Questa procedura consente di risolvere molti problemi temporanei. Tuttavia, se si verifica un errore prolungato, il limite massimo di nuovi tentativi viene solitamente raggiunto rapidamente, consentendo un rapido errore del job.
Per il monitoraggio e la gestione degli incidenti, configura regole di avviso in modo da rilevare i job non riusciti. Se un job non va a buon fine, controlla i log del job per identificare gli errori del job causati da elementi di lavoro non riusciti che hanno superato il limite di nuovi tentativi.
Per i job di inserimento di flussi, Dataflow tenta a tempo indeterminato gli elementi di lavoro non riusciti. Il job non viene terminato. Tuttavia, il job potrebbe bloccarsi finché il problema non viene risolto. Crea criteri di monitoraggio per rilevare segni di una pipeline in stallo, come un aumento della latenza di sistema e una diminuzione dell'aggiornamento dei dati. Implementa il logging degli errori nel codice della pipeline per identificare i blocchi della pipeline causati da elementi di lavoro che presentano errori ripetuti.
Riavvia i job in una zona diversa se si verifica un'interruzione a livello di zona
Dopo l'avvio di un job, i worker Dataflow che eseguono il codice utente sono vincolati a una singola zona. Un'interruzione del servizio a livello di zona influisce spesso sui job Dataflow, a seconda dell'entità dell'interruzione.
Per interruzioni che interessano solo i backend Dataflow, viene eseguita la migrazione automatica di questi ultimi a una zona diversa dal servizio gestito, in modo che possano continuare il job. Se il job utilizza Dataflow shuffling, il backend non può essere spostato tra le zone. Se si verifica una migrazione backend Dataflow, i job potrebbero essere temporaneamente bloccati.
Se si verifica un'interruzione di zona, è probabile che i job in esecuzione non vadano a buon fine o si blocchino finché la disponibilità della zona non verrà ripristinata. Se una zona non è più disponibile per un lungo periodo, interrompi i job (annulla per i job batch e scarica per i job di flusso), quindi riavviala per consentire a Dataflow di scegliere una nuova zona integro.
Riavvia i job batch in una regione diversa in caso di interruzione regionale
Se si verifica un'interruzione a livello di regione in una regione in cui sono in esecuzione i job Dataflow, i job potrebbero non riuscire o arrestarsi. Per i job batch, riavvia il job in un'altra regione, se possibile. È importante assicurarsi che i dati siano disponibili in regioni diverse.
Mitigare le interruzioni a livello di regione utilizzando l'alta disponibilità o il failover
Per i job di elaborazione in modalità flusso, a seconda della tolleranza di errore e del budget per l'applicazione, hai diverse opzioni per ridurre gli errori. In caso di interruzione di una regione, la soluzione più semplice ed economica è attendere il termine dell'interruzione. 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 trattano le opzioni disponibili.
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 consumino gli stessi dati. Le stesse origini dati devono essere disponibili in entrambe le regioni. Le applicazioni downstream che dipendono dall'output di queste pipeline devono essere in grado di passare da un output all'altro da queste due regioni. A causa della duplicazione delle risorse, questa opzione comporta il costo più elevato rispetto ad altre opzioni. Per un deployment di esempio, consulta la sezione Alta disponibilità e ridondanza geografica.
Failover: sensibile alla latenza con alcune potenziali perdite di dati
Se la tua applicazione può tollerare una potenziale perdita di dati, rendi disponibile l'origine dati in modalità flusso in più regioni. Ad esempio, con Pub/Sub, gestisci due sottoscrizioni indipendenti per lo stesso argomento, una per ogni regione. In caso di interruzione di una regione, avvia una pipeline sostitutiva in un'altra regione e fai in modo che la pipeline utilizzi i dati dell'abbonamento di backup.
Riproduci l'abbonamento di backup a un momento appropriato per mantenere al minimo la perdita di dati senza sacrificare la latenza. Le applicazioni downstream devono sapere come passare all'output della pipeline in esecuzione, come con l'opzione ad alta disponibilità. Questa opzione utilizza meno risorse rispetto all'esecuzione di pipeline duplicate, poiché solo i dati vengono duplicati.
Alta disponibilità e ridondanza geografica
Puoi eseguire più pipeline in modalità flusso in parallelo per l'elaborazione dei dati ad alta disponibilità. Ad esempio, puoi eseguire due job di inserimento di flussi paralleli in diverse aree geografiche, garantendo ridondanza geografica e tolleranza di errore per l'elaborazione dei dati.
Considerando la disponibilità geografica di origini dati e sink, puoi utilizzare pipeline end-to-end in una configurazione multiregionale a disponibilità elevata. Il seguente diagramma mostra un deployment di esempio.
Il diagramma mostra il seguente flusso:
Pub/Sub viene eseguito nella maggior parte delle regioni del mondo. Ciò consente al servizio di offrire un accesso rapido e globale ai dati, dandoti la possibilità di controllare dove sono archiviati i messaggi. Pub/Sub può archiviare automaticamente i messaggi pubblicati nella regione di Google Cloud più vicina ai sottoscrittori oppure puoi configurarla in modo da utilizzare una regione o un insieme di regioni specifico mediante i criteri di archiviazione dei messaggi.
Pub/Sub recapita quindi i messaggi ai sottoscrittori in tutto il mondo, indipendentemente da dove sono archiviati. I client Pub/Sub non devono necessariamente conoscere le località dei server a cui si connettono, perché i meccanismi di bilanciamento del carico globale indirizzano il traffico al data center Google Cloud più vicino dove sono archiviati i messaggi.
Dataflow viene eseguito in specifiche regioni di Google Cloud. Eseguendo pipeline parallele in regioni Google Cloud separate, puoi isolare i tuoi job dagli errori che interessano una singola regione. Il diagramma mostra due istanze della stessa pipeline, ciascuna in esecuzione in una regione Google Cloud separata.
BigQuery fornisce località di set di dati a livello di una o più regioni. Se scegli una località a più regioni, 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 separato.