Lo sviluppo della pipeline prevede diverse fasi e attività, come lo sviluppo del codice, i test e la distribuzione in produzione. Questo documento spiega:
- Considerazioni sull'integrazione e la distribuzione continue (CI/CD) per supportare la creazione, i test e il deployment automatizzati della pipeline in ambienti diversi.
- Funzionalità di Dataflow per ottimizzare le prestazioni e l'utilizzo delle risorse in produzione.
- Approcci e punti di osservazione per l'aggiornamento delle pipeline di streaming 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, come i siti web che vengono aggiornati di frequente. Sebbene le pipeline di dati non cambino in genere tanto quanto altri tipi di applicazioni, le praticheCIe continua 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 entrino nel codebase.
L'automazione dei test è una parte importante dellCI;integrazione continua. Se combinata con un'adeguata copertura dei test, 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 build come Maven per eseguire la suite di test come uno o più passaggi della pipeline CI. Puoi creare pacchetti di codice che superano i test delle unità e di integrazione in artefatti di deployment da cui vengono avviate le pipeline. Questa build è definita build superata.
Il numero e i tipi di artefatti di deployment creati da una build riuscita variano a seconda di come vengono avviate le pipeline. Utilizzando l'SDK Apache Beam 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, ad esempio il progetto di preproduzione o produzione Google Cloud . Se utilizzi i modelli classici (un tipo di esecuzione basata su modelli), 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 continuous delivery, 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 implementati 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 vengono superati.
Per le pipeline batch, l'implementazione continua può avviare direttamente la pipeline come 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.
Le pipeline di streaming possono essere più complesse da implementare rispetto alle pipeline batch e pertanto possono essere più difficili da automatizzare utilizzando il deployment continuo. Ad esempio, potresti dover determinare 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, ad esempio 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 pipeline deve accedere al repository del codice sorgente. Per abilitare queste interazioni, assicurati che la pipeline disponga delle identità e dei ruoli corretti. Le seguenti attività della pipeline potrebbero anche richiedere che la pipeline disponga di 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 predefinite dell'applicazione (ADC) per ottenere le credenziali. La configurazione di ADC dipende da dove viene eseguita la pipeline. Per maggiori informazioni, vedi Configurare le credenziali predefinite dell'applicazione.
Assicurati che il account di servizio utilizzato per ottenere le credenziali per le risorseGoogle Cloud a cui accede la pipeline disponga di ruoli e autorizzazioni sufficienti.
Esegui il deployment degli artefatti in ambienti di deployment diversi
Ove possibile, utilizza credenziali univoche per ogni ambiente (in pratica per ogni progetto) e limita l'accesso alle risorse di conseguenza.
Utilizza service account unici per ogni progetto per leggere e scrivere gli artefatti di deployment nei bucket di archiviazione. A seconda che la pipeline utilizzi un modello, il processo di deployment potrebbe richiedere la gestione temporanea di più artefatti. Ad esempio, la creazione e lo staging di un modello Dataflow richiedono le autorizzazioni per scrivere gli artefatti di deployment necessari per avviare la pipeline, ad esempio il file modello della pipeline, in un bucket Cloud Storage.
Esegui il deployment delle pipeline in ambienti di deployment diversi
Se possibile, utilizza service account unici per ogni progetto per accedere e gestire Google Cloud le risorse all'interno del progetto, incluso l'accesso a Dataflow stesso.
Il 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 Service account 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 informazioni dettagliate, consulta la sezione Service account 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 il
service account Compute Engine predefinito.
Ti consigliamo invece di specificare un account di servizio worker gestito dall'utente
per gli ambienti di produzione, perché il service account predefinito di Compute Engine
di solito ha un insieme più ampio di autorizzazioni rispetto a quelle
richieste per i job Dataflow.
Negli scenari di produzione, ti consigliamo di utilizzare service account separati per la gestione dei job Dataflow e per il account di servizio worker, il che offre 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 dover accedere alle origini e ai sink di dati o utilizzare altre risorse utilizzate dalla pipeline. In questo scenario, alaccount di serviziot 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 di job vengono concesse autorizzazioni per gestire (inclusa la creazione) i job Dataflow.
Pipeline CI/CD di esempio
Il seguente diagramma fornisce una visione generale e indipendente dagli strumenti della 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 tipiche, il processo di integrazione continua viene attivato quando uno sviluppatore apporta una modifica al sistema di controllo del codice sorgente, ad esempio quando esegue il push di nuovo codice in un repository.
Compilazione e test: il processo di integrazione continua compila il codice della pipeline ed esegue i test delle unità e i test di integrazione della trasformazione utilizzando Direct Runner. Possono essere eseguiti anche test di integrazione del sistema facoltativi, che includono 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 dei modelli, necessari per avviare la pipeline in posizioni accessibili al processo di continuous delivery. 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 implementazione: il processo di continuous delivery copia gli artefatti di deployment in un ambiente di preproduzione o li rende disponibili per l'uso all'interno di questo ambiente. Gli sviluppatori possono eseguire manualmente test end-to-end utilizzando Dataflow Runner oppure possono utilizzare il deployment continuo per avviare automaticamente il test. In genere, un approccio di deployment continuo è più facile da abilitare per le pipeline batch che per le 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 tale da rendere impossibili gli aggiornamenti sul posto. 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 renderli disponibili per l'ambiente di produzione nell'ambito del processo di continuous delivery. Se la nuova pipeline aggiorna o sostituisce una pipeline di streaming esistente, utilizza le procedure testate nell'ambiente di preproduzione per implementare la nuova pipeline.
Esecuzione di job non basata su modelli e 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 non basato su modello. Sebbene questo approccio sia conveniente per gli sviluppatori, potresti preferire separare le attività di sviluppo ed esecuzione delle pipeline. Per eseguire questa separazione, puoi utilizzare modelli Dataflow, che ti consentono di preparare ed eseguire le pipeline come attività indipendenti. Una volta archiviato un modello, altri utenti, inclusi quelli non sviluppatori, possono eseguire i job dal modello utilizzando Google Cloud CLI, la consoleGoogle 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 serializzato JSON come modello. L'SDK Apache Beam esegue il deployment del file modello in una posizione Cloud Storage, insieme a tutte le dipendenze richieste dal codice della pipeline.
- Modelli flessibili: gli sviluppatori utilizzano Google Cloud CLI per pacchettizzare la pipeline come immagine Docker, che viene poi archiviata in Artifact Registry. Viene inoltre generato automaticamente un file di specifica del modello flessibile e archiviato in una posizione 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 flessibili spiegate nella documentazione collegata, i modelli flessibili offrono vantaggi rispetto ai modelli classici per la gestione dei modelli.
- Con i modelli classici, più artefatti, come i file JAR, potrebbero essere archiviati in una posizione di staging di Cloud Storage, ma senza funzionalità per gestire questi più artefatti. Al contrario, un modello flessibile è incapsulato in un'immagine Docker. Il pacchetto di immagini include tutte le dipendenze, ad eccezione della specifica del modello Flex, necessarie per la pipeline in un unico 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 le autorizzazioni pull (e facoltativamente push) ad Artifact Registry e utilizzare i tag immagine Docker per diverse versioni dei tuoi modelli Flex.
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 o 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 della pipeline diversi. Utilizzando 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 di 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 del runner per ottimizzare l'utilizzo delle risorse, il che può migliorare le prestazioni e ridurre i costi:
- Streaming Engine: Streaming Engine sposta l'esecuzione delle pipeline di streaming all'esterno dei worker VM e in un servizio dedicato. I vantaggi includono una migliore reattività della scalabilità automatica, riduzioni delle risorse VM worker consumate e aggiornamenti automatici del servizio senza nuovo deployment. 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 Apache Beam Java o dell'SDK Python.
- Dataflow Shuffle: Dataflow Shuffle sposta le operazioni di shuffle 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 consumo di risorse ridotto da parte delle VM worker, una migliore reattività della scalabilità automatica e una migliore tolleranza agli errori. L'attivazione di Dataflow Shuffle è consigliata per le pipeline batch. La funzionalità è attivata 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 di VM prerilasciabile e VM normali.
Aggiornare le pipeline di streaming in produzione
Vedi Eseguire l'upgrade di una pipeline di streaming.
Ciclo di vita 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 indirizzato 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. Quando
questi controlli preflight sono completi e un backend è stato assegnato, 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 preleva 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 tenta anche di garantire che il backend Dataflow e le VM worker si trovino nella stessa zona per evitare il traffico tra zone diverse.
Dopo l'avvio, i worker Dataflow richiedono lavoro al backend Dataflow. Il backend è responsabile della suddivisione del lavoro in blocchi parallelizzabili, chiamati bundle, che vengono distribuiti tra i worker. Se i worker non riescono a gestire il lavoro esistente e se la scalabilità automatica è attivata, il backend avvia altri 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 funge da
control plane per orchestrare l'esecuzione del job. Durante l'elaborazione, il data plane del job esegue operazioni di shuffle come GroupByKey, CoGroupByKey e Combine.
I job utilizzano una delle seguenti implementazioni del data plane per le operazioni di shuffle:
- Il piano dei dati viene eseguito sui worker Dataflow e i dati di shuffle vengono archiviati su dischi permanenti.
- Il piano dati viene eseguito come servizio, esternalizzato dalle VM worker. Questa implementazione ha due varianti, che specifichi quando crei il job: Dataflow Shuffle per le pipeline batch e Streaming Engine per le pipeline di streaming. Lo shuffle basato su servizi migliora in modo significativo le prestazioni e la scalabilità delle operazioni di shuffling dei dati rispetto allo shuffle basato sui worker.
I job di streaming che entrano nello 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 quando tutta l'elaborazione è completata o se si verifica un errore non recuperabile. A seconda di come viene arrestato il job, Dataflow imposta lo stato del job su uno dei vari stati terminali, tra cui JOB_STATE_CANCELLED, JOB_STATE_DRAINED o JOB_STATE_DONE.
Best practice per l'affidabilità della pipeline
Questa sezione descrive gli errori che potrebbero verificarsi quando lavori con Dataflow e le best practice per i job Dataflow.
Segui 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 interregionali critiche. Se hai una pipeline che dipende in modo critico da servizi di più regioni, un errore in una di queste regioni può influire sulla tua pipeline. Per evitare questo problema, esegui il deployment in più regioni per la ridondanza e il 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 di streaming in un'altra zona o regione. Puoi quindi avviare il 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 di Recovery Time Objective (RTO).
Per saperne di più sugli snapshot Dataflow, consulta Utilizzare gli snapshot 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 Dataflow Runner, che viene specificato come parte delle opzioni della pipeline. L'SDK Apache Beam archivia i file in un'area intermedia in Cloud Storage, crea un file di richiesta di job e lo invia a Dataflow.
In alternativa, i job creati dai modelli Dataflow utilizzano metodi di invio diversi, che si basano comunemente sull'API Templates.
Potresti visualizzare diversi errori restituiti da Dataflow che indicano l'esito negativo del job per i job basati su modelli e non. Questa sezione descrive diversi tipi di errori di invio dei job e le best practice per gestirli o mitigarli.
Riprova gli invii di job dopo errori temporanei
Se un job non viene avviato a causa di un problema del servizio Dataflow, riprova a eseguirlo più volte. I nuovi tentativi riducono i problemi transitori del servizio.
Mitigare gli errori a livello di zona specificando una regione di worker
Dataflow offre disponibilità regionale ed è disponibile in più regioni. Quando un utente invia un job a una regione senza specificare esplicitamente una zona, Dataflow indirizza 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 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 possibile per il job. I job che specificano una zona esplicita non usufruiscono di questo vantaggio e
non riescono se si verificano problemi all'interno della zona. Se l'invio di un job non riesce a causa di un problema di zona, spesso puoi risolvere il problema riprovando a inviare il job senza specificare esplicitamente una zona.
Mitigare 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 in più regioni. Per proteggerti dai guasti a livello di 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 dual-region e multiregionali di Cloud Storage. 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 multiregionali con Dataflow, vedi Alta disponibilità e ridondanza geografica.
Gestire gli errori nelle pipeline in esecuzione
Una volta inviato e accettato un job, le uniche operazioni valide per il job sono le seguenti:
- annulla per i job batch
- aggiornare, svuotare o annullare 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'elaborazione dei dati dei job FlexRS può richiedere fino a sei ore.
Questa sezione illustra gli errori durante l'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 non riuscito vengono ritentati quattro volte. Dataflow termina il job quando un singolo bundle non è riuscito quattro volte. Questa procedura risolve molti problemi temporanei. Tuttavia, se si verifica un errore prolungato, il limite massimo di tentativi viene in genere 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, controlla 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 esegue nuovi tentativi per gli elementi di lavoro non riusciti indefinitamente. Il job non è terminato. Tuttavia, il job potrebbe bloccarsi finché il problema non viene risolto. Crea norme di monitoraggio per rilevare i segni di una pipeline bloccata, ad esempio un aumento della latenza del sistema e una diminuzione della frequenza di aggiornamento dei dati. Implementa la registrazione degli errori nel codice della pipeline per identificare gli stalli della pipeline causati da elementi di lavoro che non vanno a buon fine ripetutamente.
Riavvia i job in una zona diversa se si verifica un'interruzione zonale
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 zonale, i job Dataflow sono spesso interessati, a seconda dell'entità dell'interruzione.
Per le interruzioni che interessano solo i backend Dataflow, questi vengono migrati automaticamente 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 tra le zone. Se si verifica una migrazione del backend Dataflow, i job potrebbero essere temporaneamente bloccati.
Se si verifica un'interruzione zonale, è 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 lungo periodo, arresta i job (annulla per i job batch e svuota per i job di streaming) e riavviali per consentire a Dataflow di scegliere una nuova zona integra.
Riavvia i job batch in un'altra regione se si verifica un'interruzione a livello regionale
Se si verifica un'interruzione a livello regionale in una regione in cui sono in esecuzione i job Dataflow, i job potrebbero non riuscire o bloccarsi. 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 del servizio a livello regionale utilizzando l'alta disponibilità o il failover
Per i job di streaming, a seconda della tolleranza agli errori e del budget per l'applicazione, hai diverse opzioni per mitigare gli errori. In caso di interruzione regionale, l'opzione più semplice ed economica è attendere la fine 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 illustrano le opzioni.
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 downstream che dipendono dall'output di queste pipeline devono essere in grado di passare dall'output di queste due regioni. A causa della duplicazione delle risorse, questa opzione comporta il costo più elevato rispetto alle altre. Per un esempio di deployment, consulta la sezione Alta affidabilità e ridondanza geografica.
Failover: sensibile alla latenza con potenziale perdita di dati
Se la tua applicazione può tollerare la potenziale perdita di dati, rendi disponibile l'origine dei dati di streaming in più regioni. Ad esempio, utilizzando Pub/Sub, mantieni due abbonamenti indipendenti per lo stesso argomento, uno per ogni regione. Se si verifica un'interruzione regionale, avvia una pipeline di sostituzione in un'altra regione e fai in modo che la pipeline utilizzi i dati dell'abbonamento di backup.
Riproduci l'abbonamento 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 dei dati ad alta disponibilità. Ad esempio, puoi eseguire due job di streaming paralleli in regioni diverse, il che fornisce ridondanza geografica e tolleranza agli errori per l'elaborazione dei dati.
Se prendi in considerazione la disponibilità geografica di origini dati e sink, puoi gestire pipeline end-to-end in una configurazione multiregionale a disponibilità elevata. Il seguente diagramma mostra un esempio di deployment.
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 ai dati globale e rapido, pur lasciandoti il controllo sulla posizione di archiviazione dei messaggi. Pub/Sub può archiviare automaticamente i messaggi pubblicati nella regione Google Cloud più vicina agli abbonati oppure puoi configurarlo in modo che utilizzi una regione o un insieme di regioni specifici utilizzando le policy di archiviazione dei messaggi.
Pub/Sub recapita quindi i messaggi agli abbonati in tutto il mondo, indipendentemente da dove sono archiviati. I client Pub/Sub non devono conoscere le posizioni dei server a cui si connettono, perché i meccanismi di bilanciamento del carico globale indirizzano il traffico al data centerGoogle 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 separata.
BigQuery fornisce località dei set di dati regionali e multiregionali. Quando scegli una località multiregionale, il tuo set di dati si trova in almeno due regioni geografiche. Il diagramma mostra due pipeline separate, ognuna delle quali scrive in un set di dati multiregionale separato.