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 continue (CI/CD) per supportare la creazione automatica di build, test e deployment di pipeline in ambienti diversi.
- le funzionalità di Dataflow per ottimizzare le prestazioni e l'uso delle risorse in produzione.
- Approcci e watchpoint 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 il codice in un repository condiviso frequentemente, il che è utile per le applicazioni che cambiano molto, ad esempio i siti web che vengono aggiornati di frequente. Sebbene le pipeline di dati di solito non cambino tanto come altri tipi di applicazioni, le pratiche di CI offrono molti vantaggi per lo sviluppo della pipeline. Ad esempio, l'automazione dei test fornisce un feedback rapido in caso di difetti e riduce la probabilità che le regressioni entrino nel codebase.
L'automazione dei test è una parte importante della CI. Una volta combinata con la copertura dei test appropriata, l'automazione dei test esegue la suite di test su ogni commit di codice. Il tuo server CI può funzionare in combinazione con uno strumento di automazione delle build 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 artefatti di deployment da cui vengono avviate le pipeline. Questa build è detta build di 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. Con 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 modelli classici (un tipo di esecuzione con modello), gli artefatti 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 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 che sono pronti per essere avviati manualmente. In genere, il deployment degli artefatti creati dal server CI viene eseguito 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, se 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 e, di conseguenza, può essere più difficile automatizzare utilizzando il deployment continuo. Ad esempio, potresti dover determinare come sostituire o aggiornare una pipeline di inserimento flussi esistente. Se non puoi aggiornare una pipeline o se scegli di non aggiornarla, puoi utilizzare altri metodi come il coordinazione di più job Dataflow per ridurre al minimo o prevenire l'interruzione dell'attività.
Identità e ruoli richiesti per CI/CD
La tua pipeline CI/CD interagisce con diversi sistemi per creare, testare ed eseguire il deployment delle pipeline. Ad esempio, la tua pipeline deve accedere al repository del codice sorgente. Per abilitare queste interazioni, assicurati che la pipeline abbia le identità e i ruoli corretti. 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 l'esecuzione di test ad hoc o di integrazione del sistema, la pipeline utilizza le credenziali di Google Cloud CLI per utilizzare origini dati e 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 abbia ruoli e autorizzazioni sufficienti.
Esegui il deployment degli artefatti in diversi ambienti di deployment
Se possibile, utilizza credenziali univoche per ogni ambiente (effettivamente per ogni progetto) e limita l'accesso alle risorse di conseguenza.
Usa account di servizio univoci per ogni progetto per leggere e scrivere artefatti di deployment nei bucket di archiviazione. A seconda che la pipeline utilizzi un modello, il processo di deployment potrebbe dover preparare più artefatti. Ad esempio, la creazione e la gestione temporanea di un modello Dataflow richiedono autorizzazioni per scrivere gli artefatti di deployment necessari per avviare la pipeline, come il file del modello della pipeline, in un bucket Cloud Storage.
esegui il deployment delle 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, 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 job Dataflow deve avere 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 di --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.
Consigliamo invece di specificare un account di servizio worker gestito dall'utente per gli ambienti di produzione, perché l'account di servizio predefinito di Compute Engine di solito dispone di un insieme più ampio di autorizzazioni rispetto alle autorizzazioni necessarie per i job Dataflow.
In scenari di produzione, consigliamo di utilizzare account di servizio separati per la gestione dei job Dataflow e per l'account di servizio worker, offrendo una maggiore sicurezza rispetto all'utilizzo 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 altro account di servizio per la creazione dei job vengono concesse le autorizzazioni per gestire (compresa la creazione) dei job Dataflow.
Pipeline CI/CD di esempio
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 localmente il codice della pipeline utilizzando Direct Runner. Inoltre, gli sviluppatori utilizzano un ambiente sandbox per l'esecuzione ad hoc della pipeline 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 eseguendo 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 i test di integrazione della trasformazione utilizzando Direct Runner. È possibile eseguire anche test di integrazione del sistema facoltativi, che includono test di integrazione con origini e sink esterni che utilizzano set di dati di test di piccole dimensioni.
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 avviare la pipeline in località accessibili al processo di distribuzione continua. A seconda dei tipi di artefatti di deployment generati, puoi 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 pre-produzione o rende questi artefatti disponibili per l'uso all'interno di tale ambiente. Gli sviluppatori possono eseguire manualmente test end-to-end utilizzando Dataflow Runner oppure utilizzare il deployment continuo per avviare il test automaticamente. In genere, un approccio di deployment continuo è più facile da abilitare per le pipeline batch che per le pipeline in modalità flusso. Poiché le pipeline batch non vengono eseguite in modo continuo, è più facile
Il processo di aggiornamento delle pipeline in modalità flusso potrebbe essere semplice o complesso e dovresti 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 tale da rendere impossibili gli aggiornamenti in loco. Per questo motivo, a volte è difficile automatizzare gli aggiornamenti della pipeline utilizzando 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 di inserimento flussi esistente, per eseguire il deployment della nuova pipeline utilizza le procedure testate nell'ambiente di preproduzione.
Esecuzione di job non basati su modelli ed esecuzione di job basati su modelli
Puoi creare un job Dataflow utilizzando l'SDK Apache Beam direttamente da un ambiente di sviluppo. Questo tipo di job è chiamato job non basato su modelli. 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 i modelli Dataflow, che ti consentono di organizzare ed eseguire le pipeline come attività indipendenti. Dopo l'impostazione temporanea di un modello, altri utenti, inclusi i non 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 grafico di esecuzione serializzata JSON come modello. L'SDK Apache Beam posiziona 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. Inoltre, viene generato automaticamente e archiviato un file delle specifiche del modello flessibile in un percorso di Cloud Storage specificato 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à del modello Flex spiegate nella documentazione collegata, i modelli Flex offrono vantaggi per la gestione dei modelli rispetto ai modelli classici.
- Con i modelli classici, è possibile che più artefatti, come i file JAR, vengano archiviati in una posizione temporanea di Cloud Storage, ma senza alcuna funzionalità per la gestione di questi vari artefatti. Un modello flessibile è invece incapsulato in un'immagine Docker. L'immagine pacchettizza tutte le dipendenze, ad eccezione delle specifiche del modello flessibile, necessarie per la pipeline in un artefatto di deployment gestito da Artifact Registry.
- Puoi usare le funzionalità di gestione delle immagini Docker per i modelli flessibili. Ad esempio, puoi condividere in modo sicuro i modelli flessibili concedendo le autorizzazioni di pull (e facoltativamente push) ad Artifact Registry e utilizzare i tag immagine Docker per 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 per più clienti in diversi progetti e job della pipeline. Con i modelli flessibili, puoi specificare versioni diverse di un'immagine Docker da usare quando avvii una pipeline. Questa funzionalità semplifica la sostituzione graduale delle pipeline batch o delle pipeline in modalità flusso su 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 dell'esecutore per ottimizzare l'utilizzo delle risorse, il che può migliorare le prestazioni e ridurre i costi:
- Streaming Engine: Streaming Engine trasferisce l'esecuzione di pipeline in modalità flusso dai worker VM a un servizio dedicato. I vantaggi includono una migliore reattività della scalabilità automatica, le riduzioni delle risorse utilizzate per le VM worker e gli aggiornamenti automatici del servizio senza rideployment. In alcuni casi, puoi anche ridurre l'utilizzo delle risorse tramite l'elaborazione "at-least-once" per 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 si utilizzano le ultime versioni dell'SDK Java di Apache Beam o dell'SDK Python.
- Dataflow Shuffle: Dataflow Shuffle sposta le operazioni di shuffling per le pipeline in batch dai worker delle VM a un servizio dedicato. I vantaggi includono un'esecuzione più rapida per la maggior parte delle pipeline batch, un consumo ridotto di risorse da parte delle VM worker, una migliore reattività della scalabilità automatica e una maggiore tolleranza agli errori. L'abilitazione di Dataflow Shuffle è consigliata per le pipeline batch. La funzionalità è abilitata per impostazione predefinita utilizzando l'SDK Java di Apache Beam e l'SDK Python più recente.
- Pianificazione flessibile delle risorse (FlexRS): FlexRS riduce i costi di elaborazione batch utilizzando tecniche di pianificazione avanzate, il servizio Dataflow Shuffle e una combinazione di istanze VM prerilasciabile e VM normali.
Aggiorna pipeline di flusso in produzione
Consulta Eseguire l'upgrade di una pipeline di inserimento flussi.
Durata di un job Dataflow
Un job Dataflow attraversa un ciclo di vita rappresentato da vari stati dei 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 disponi di quota e autorizzazioni sufficienti per eseguire il job. Una volta completati questi controlli preflight e stato 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 entrano nello stato JOB_STATE_QUEUED.
Il backend assegnato seleziona 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 le VM worker e del backend Dataflow si trovino nella stessa zona per evitare il traffico tra zone.
Una volta avviati, i worker Dataflow richiedono il lavoro al backend Dataflow. Il backend è responsabile della suddivisione del lavoro in blocchi parallelizzabili, denominati bundle, 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 un numero maggiore di worker per gestire il lavoro. Analogamente, se vengono avviati più worker del necessario, alcuni vengono arrestati.
Dopo l'avvio dei worker Dataflow, il backend di Dataflow funge da 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.
I job utilizzano una delle seguenti implementazioni del piano dati per le operazioni di shuffle:
- Il piano dati viene eseguito sui worker Dataflow e lo shuffling dei dati viene archiviato su dischi permanenti.
- Il piano dati viene eseguito come servizio, esternamente alle VM worker. Questa implementazione ha due varianti, che devi specificare al momento della creazione del job: Dataflow Shuffle per le pipeline batch e Streaming Engine per le pipeline in modalità flusso. Lo shuffle basato su servizi migliora significativamente le prestazioni e la scalabilità delle operazioni di shuffling dei dati rispetto allo shuffle basato su worker.
I job di flussi di dati in stato JOB_STATE_RUNNING continuano a essere eseguiti
a tempo indeterminato fino a quando 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 irreversibile. A seconda di come viene arrestato 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 lavori con 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 critiche tra regioni. Se hai una pipeline che ha una dipendenza critica dai servizi di 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 pipeline, puoi ridurre al minimo il tempo RTO (Recovery Time Objective).
Per ulteriori informazioni sugli snapshot Dataflow, consulta Utilizzare gli snapshot Dataflow.
Gestire gli errori di invio del job
Per inviare job Dataflow non modello usa l'SDK Apache Beam. Per inviare il job, esegui la pipeline utilizzando il runner Dataflow, specificato come parte delle opzioni della pipeline. L'SDK Apache Beam mette in pausa i file in Cloud Storage, crea un file di richiesta di job e invia il file a Dataflow.
In alternativa, i job creati dai modelli Dataflow utilizzano diversi metodi di invio, che in genere si basano sull'API dei modelli.
Dataflow potrebbe restituire diversi errori che indicano un errore nel job modello e non. Questa sezione illustra i diversi tipi di errori di invio dei job e le best practice per gestirli o risolverli.
Riprova a inviare i job in caso di errori temporanei
Se un job non viene avviato a causa di un problema del servizio Dataflow, riprova a eseguire il job alcune volte. Un nuovo tentativo riduce i problemi temporanei del servizio.
Mitigazione degli errori a livello di zona specificando una regione 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 worker
utilizzando il flag --region
anziché il flag --zone quando possibile. Questo passaggio consente a Dataflow di fornire un ulteriore livello di tolleranza di errore 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 di zona, spesso puoi risolvere il problema riprovando il job senza specificare una zona in modo esplicito.
Riduci gli errori a livello di regione archiviando i dati in più regioni
Se un'intera regione non è disponibile, prova a eseguire il job in un'altra. È importante considerare la disponibilità dei dati quando i job hanno esito negativo in più regioni. Per proteggerti da errori di 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 BigQuery località con più regioni per i set di dati o bucket 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 nelle pipeline in esecuzione
Dopo che un job è stato inviato e accettato, le uniche operazioni valide per il job sono le seguenti:
- annulla per job batch
- aggiorna, svuota o annulla per i job di flussi di dati
Non puoi modificare la località dei job in esecuzione dopo averli inviati. Se non utilizzi FlexRS, i job in genere iniziano a elaborare i dati pochi minuti dopo l'invio. L'avvio dell'elaborazione dei dati può richiedere fino a sei ore.
Questa sezione illustra gli errori dei job in esecuzione 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 ritentati quattro volte. Dataflow termina il job quando un singolo bundle ha avuto esito negativo per quattro volte. Questo processo risolve molti problemi temporanei. Tuttavia, se si verifica un errore prolungato, il limite massimo di nuovi tentativi viene in genere raggiunto rapidamente, il che consente un rapido errore del job.
Per il monitoraggio e la gestione degli incidenti, configura le regole di avviso per rilevare i job non riusciti. Se un job non va a buon fine, controlla i log dei job per identificare gli errori causati da elementi di lavoro non riusciti che hanno superato il limite di nuovi tentativi.
Per i job di flussi, Dataflow ritenta gli elementi di lavoro non riusciti a tempo indeterminato. Il job non è stato interrotto. Tuttavia, il job potrebbe bloccarsi fino alla risoluzione del problema. Crea criteri di monitoraggio per rilevare segnali di una pipeline bloccata, 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 non risolvono il problema.
Riavvia 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. Se si verifica un'interruzione a livello di zona, spesso i job Dataflow subiscono un'interruzione.
Per le interruzioni che interessano solo i backend Dataflow, viene eseguita la migrazione automatica dei backend in una zona diversa dal servizio gestito, in modo che possano continuare il job. Se il job utilizza Dataflow Shuffle, il backend non può essere spostato da una zona all'altra. Se si verifica una migrazione backend Dataflow, i job potrebbero essere temporaneamente bloccati.
Se si verifica un'interruzione a livello di zona, è probabile che i job in esecuzione non vadano a buon fine o si blocchino finché la disponibilità della zona non viene ripristinata. Se una zona non è più disponibile per un lungo periodo, interrompi i job (annulla per i job batch e scaricali per quelli in modalità flusso), quindi riavviali per consentire a Dataflow di scegliere una nuova zona integro.
Riavvia job batch in una regione diversa se si verifica un'interruzione a livello di regione
Se si verifica un'interruzione a livello di regione in una 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.
Mitigare le interruzioni a livello di regione utilizzando l'alta disponibilità o il failover
Per i job di flussi di dati, a seconda della tolleranza di errore e del budget dell'applicazione, sono disponibili diverse opzioni per la mitigazione degli errori. Per un'interruzione regionale, l'opzione più semplice e conveniente è attendere la fine dell'interruzione. Tuttavia, se l'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 descrivono 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 parallele 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 downstream che dipendono dall'output di queste pipeline devono essere in grado di passare dall'output alle due regioni. A causa della duplicazione delle risorse, questa opzione comporta il costo più elevato rispetto ad altre opzioni. Per un esempio di deployment, consulta la sezione Alta disponibilità e ridondanza geografica.
Failover: sensibile alla latenza con una potenziale perdita di dati
Se l'applicazione è in grado di tollerare una potenziale perdita di dati, rendi disponibile l'origine di dati in modalità flusso in più regioni. Ad esempio, utilizzando Pub/Sub, gestisci due sottoscrizioni 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 utilizzi i dati dell'abbonamento di backup.
Ripeti l'abbonamento di backup a un periodo appropriato 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 ad alta disponibilità. Questa opzione utilizza meno risorse rispetto all'esecuzione di pipeline duplicate, perché solo i dati sono duplicati.
Disponibilità elevata e ridondanza geografica
Puoi eseguire più pipeline di flusso in parallelo per l'elaborazione dei dati ad alta disponibilità. Ad esempio, puoi eseguire due job di flussi di dati paralleli in regioni diverse, garantendo ridondanza geografica e tolleranza di errore per l'elaborazione dei dati.
Considerando la disponibilità geografica di origini dati e sink, puoi utilizzare le pipeline end-to-end in una configurazione multiregionale ad alta disponibilità. 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, perciò il servizio offre un accesso rapido e globale ai dati, consentendoti al contempo di controllare dove vengono archiviati i messaggi. Pub/Sub può archiviare automaticamente i messaggi pubblicati nella regione Google Cloud più vicina ai sottoscrittori oppure puoi configurarlo in modo che utilizzi una regione o un insieme di regioni specifiche con i criteri di archiviazione dei messaggi.
Pub/Sub consegna quindi i messaggi ai sottoscrittori in tutto il mondo, indipendentemente da dove sono archiviati. Non è necessario che i client Pub/Sub siano a conoscenza delle 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 in cui sono archiviati i messaggi.
Dataflow viene eseguito in regioni specifiche di Google Cloud. 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 separata.
BigQuery fornisce località di set di dati a livello di una o più regioni. Quando scegli una località con 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.