Architettura per MLOps con TensorFlow Extended, Vertex AI Pipelines e Cloud Build

Last reviewed 2023-01-20 UTC

Questo documento descrive l'architettura complessiva di un sistema di machine learning (ML) che utilizza le librerie TensorFlow Extended (TFX). Descrive inoltre come configurare un'integrazione continua (CI), una distribuzione continua (CD) e un addestramento continuo (CT) per il sistema di ML utilizzando Cloud Build e Vertex AI Pipelines.

In questo documento, i termini sistema ML e pipeline ML si riferiscono alle pipeline di addestramento dei modelli ML, anziché alle pipeline di scoring o previsione dei modelli.

Questo documento è rivolto a data scientist e ML engineer che vogliono adattare le loro pratiche CI/CD per portare le soluzioni ML in produzione su Google Cloud e che vogliono contribuire a garantire la qualità, la manutenibilità e l'adattabilità delle loro pipeline ML.

Questo documento tratta i seguenti argomenti:

• Capire CI/CD e automazione nel ML.
• Progettazione di una pipeline ML integrata con TFX.
• Orchestrazione e automazione della pipeline ML utilizzando Vertex AI Pipelines.
• Configurazione di un sistema CI/CD per la pipeline ML utilizzando Cloud Build.

MLOps

Per integrare un sistema ML in un ambiente di produzione, devi orchestrare
i passaggi nella pipeline ML. Inoltre, devi automatizzare l'esecuzione della pipeline per l'addestramento continuo dei tuoi modelli. Per sperimentare con nuove idee e funzionalità, devi adottare pratiche CI/CD nelle nuove implementazioni delle pipeline. Le seguenti sezioni forniscono una panoramica generale di CI/CD e CT in ML.

Automazione di pipeline ML

In alcuni casi d'uso, il processo manuale di addestramento, convalida e deployment di modelli ML può essere sufficiente. Questo approccio manuale funziona se il team gestisce solo pochi modelli ML che non sono stati riaddestrati o non vengono modificati di frequente. In pratica, però, i modelli spesso si rompono quando vengono distribuiti nel mondo reale perché non riescono ad adattarsi ai cambiamenti nelle dinamiche degli ambienti o ai dati che le descrivono.

Affinché il tuo sistema di ML si adatti a questi cambiamenti, devi applicare le seguenti tecniche MLOps:

• Automatizza l'esecuzione della pipeline di ML per riaddestrare nuovi modelli sulla base di nuovi dati al fine di acquisire eventuali pattern emergenti. Il CT verrà discusso più avanti in questo documento nella sezione ML con Vertex AI Pipelines.
• Configura un sistema di distribuzione continua per eseguire frequentemente il deployment di nuove implementazioni dell'intera pipeline ML. CI/CD viene discusso più avanti in questo documento nella sezione Configurazione di CI/CD per ML su Google Cloud.

Puoi automatizzare le pipeline di produzione ML per riaddestrare i modelli con nuovi dati. Puoi attivare la pipeline on demand, in base a una pianificazione, alla disponibilità di nuovi dati, al peggioramento delle prestazioni del modello, a cambiamenti significativi nelle proprietà statistiche dei dati o in base ad altre condizioni.

Confronto tra pipeline CI/CD e CT

La disponibilità di nuovi dati è un trigger per riaddestrare il modello ML. La disponibilità di una nuova implementazione della pipeline ML (che comprende una nuova architettura del modello, feature engineering e iperparametri) è un altro importante fattore per il riesecuzione della pipeline ML. Questa nuova implementazione della pipeline ML funge da nuova versione del servizio di previsione dei modelli, ad esempio un microservizio con un'API REST per la pubblicazione online. La differenza tra i due casi è la seguente:

• Per addestrare un nuovo modello ML con nuovi dati, viene eseguita la pipeline CT di cui è stato eseguito il deployment in precedenza. Non viene eseguito il deployment di nuove pipeline o nuovi componenti; alla fine della pipeline viene fornito solo un nuovo servizio di previsione o un modello appena addestrato.
• Per addestrare un nuovo modello ML con una nuova implementazione, viene eseguito il deployment di una nuova pipeline tramite una pipeline CI/CD.

Per eseguire rapidamente il deployment di nuove pipeline ML, devi configurare una pipeline CI/CD. Questa pipeline è responsabile del deployment automatico di nuove pipeline e componenti ML quando nuove implementazioni sono disponibili e approvate per vari ambienti (ad esempio sviluppo, test, gestione temporanea, pre-produzione, canary e produzione).

Il seguente diagramma mostra la relazione tra la pipeline CI/CD e la pipeline ML CT.

Figura 1. pipeline CI/CD e ML CT.

L'output di queste pipeline è il seguente:

• Se viene data una nuova implementazione, una pipeline CI/CD riuscita esegue il deployment di una nuova pipeline ML CT.
• Se vengono forniti nuovi dati, una pipeline CT riuscita addestra un nuovo modello e ne esegue il deployment come servizio di previsione.

Progettazione di un sistema ML basato su TFX

Le seguenti sezioni descrivono come progettare un sistema ML integrato utilizzando TensorFlow Extended (TFX) per configurare una pipeline CI/CD per il sistema ML. Sebbene esistano diversi framework per la creazione di modelli ML, TFX è una piattaforma ML integrata per lo sviluppo e il deployment di sistemi ML di produzione. Una pipeline TFX è una sequenza di componenti che implementano un sistema di ML. Questa pipeline TFX è progettata per attività ML scalabili e ad alte prestazioni. Queste attività includono la modellazione, l'addestramento, la convalida, l'inferenza di gestione e la gestione dei deployment. Le librerie chiave di TFX sono le seguenti:

• Convalida dei dati di TensorFlow (TFDV): utilizzata per rilevare le anomalie nei dati.
• TensorFlow Transform (TFT): utilizzato per la pre-elaborazione dei dati e il feature engineering.
• TensorFlow Estimator e Keras: utilizzati per la creazione e l'addestramento di modelli ML.
• TensorFlow Model Analysis (TFMA): utilizzato per la valutazione e l'analisi di modelli ML.
• TensorFlow Serving (TFserving): utilizzato per gestire modelli di ML come API REST e gRPC.

Panoramica del sistema TFX ML

Il seguente diagramma mostra come le varie librerie TFX sono integrate per comporre un sistema ML.

Figura 2. Un tipico sistema ML basato su TFX.

La Figura 2 mostra un tipico sistema ML basato su TFX. I seguenti passaggi possono essere completati manualmente o con una pipeline automatizzata:

1. Estrazione dei dati: la prima cosa da fare è estrarre i nuovi dati di addestramento dalle proprie origini dati. Gli output di questo passaggio sono file di dati utilizzati per l'addestramento e la valutazione del modello.
2. Convalida dei dati: TFDV convalida i dati in base allo schema di dati previsti (non elaborati). Lo schema di dati viene creato e risolto durante la fase di sviluppo, prima del deployment del sistema. I passaggi di convalida dei dati rilevano anomalie relative alla distribuzione dei dati e alle disallineamenti dello schema. Gli output di questo passaggio sono le eventuali anomalie e la decisione di eseguire o meno i passaggi a valle.
3. Trasformazione dei dati: dopo la convalida, i dati vengono suddivisi e preparati per l'attività di ML eseguendo trasformazioni dei dati e operazioni di feature engineering utilizzando TFT. Gli output di questo passaggio sono file di dati per addestrare e valutare il modello, solitamente trasformati in formato TFRecords. Inoltre, gli artefatti di trasformazione prodotti aiutano a costruire gli input del modello e incorporano il processo di trasformazione nel modello salvato esportato dopo l'addestramento.
4. Addestramento e ottimizzazione del modello: per implementare e addestrare il modello ML, utilizza le API tf.estimator o tf.Keras con i dati trasformati prodotti nel passaggio precedente. Per selezionare le impostazioni dei parametri che portano al modello migliore, puoi utilizzare l'accordatore Keras, una libreria di ottimizzazione degli iperparametri per Keras. In alternativa, puoi utilizzare altri servizi come Katib, Vertex AI Vizier o l'accordatore iperparametri di Vertex AI. L'output di questo passaggio è un modello salvato che viene utilizzato per la valutazione e un altro modello salvato che viene utilizzato per la pubblicazione online del modello per la previsione.
5. Valutazione e convalida del modello: quando il modello viene esportato dopo la fase di addestramento, viene valutato su un set di dati di test per valutarne la qualità utilizzando TFMA. TFMA valuta la qualità del modello nel suo complesso e identifica la parte del modello dei dati non in esecuzione. Questa valutazione aiuta a garantire che il modello venga promosso per la pubblicazione solo se soddisfa i criteri di qualità. I criteri possono includere un rendimento equo su vari sottoinsiemi di dati (ad esempio dati demografici e località) e un rendimento migliore rispetto ai modelli precedenti o a un modello di benchmark. L'output di questo passaggio è un insieme di metriche di rendimento e una decisione su se promuovere il modello in produzione.
6. Gestione dei modelli per la previsione: dopo la convalida del modello appena addestrato, viene eseguito il deployment del modello come microservizio per fornire previsioni online utilizzando TensorFlow Serving. L'output di questo passaggio è un servizio di previsione di cui è stato eseguito il deployment del modello ML addestrato. Puoi sostituire questo passaggio archiviando il modello addestrato in un registro dei modelli. Successivamente, viene lanciato un modello separato per il processo CI/CD.

Per un esempio su come utilizzare le librerie TFX, consulta il tutorial ufficiale sul componente TFX Keras.

Sistema TFX ML su Google Cloud

In un ambiente di produzione, i componenti del sistema devono essere eseguiti su larga scala su una piattaforma affidabile. Il seguente diagramma mostra come ogni passaggio della pipeline TFX ML viene eseguito utilizzando un servizio gestito su Google Cloud, il che garantisce agilità, affidabilità e prestazioni su larga scala.

Figura 3. basato su TFX su Google Cloud.

La seguente tabella descrive i principali servizi Google Cloud mostrati nella Figura 3:

Passaggio	libreria TFX	Servizio Google Cloud
Estrazione e convalida dei dati	Convalida dei dati di TensorFlow	Dataflow
Trasformazione dei dati	Trasformazione TensorFlow	Dataflow
Addestramento e ottimizzazione del modello	TensorFlow	Formazione su Vertex AI
Valutazione e convalida del modello	Analisi del modello TensorFlow	Dataflow
Pubblicazione del modello per le previsioni	Pubblicazione su TensorFlow	Previsione Vertex AI
Archiviazione dei modelli	NA	Registro dei modelli di Vertex AI

• Dataflow è un servizio completamente gestito, serverless e affidabile per l'esecuzione di pipeline di Apache Beam su larga scala su Google Cloud. Dataflow viene utilizzato per scalare i seguenti processi:
  • Calcolo delle statistiche per convalidare i dati in arrivo.
  • Esecuzione della preparazione e trasformazione dei dati.
  • Valutare il modello su un set di dati di grandi dimensioni.
  • Calcolo di metriche su diversi aspetti del set di dati di valutazione.
• Cloud Storage è uno spazio di archiviazione durevole e a disponibilità elevata per oggetti binari di grandi dimensioni. Cloud Storage ospita artefatti prodotti durante l'esecuzione della pipeline ML, tra cui:
  • Anomalie dei dati (se presenti)
  • Dati e artefatti trasformati
  • Modello esportato (addestrato)
  • Metriche di valutazione del modello
• Vertex AI Training è un servizio gestito per l'addestramento di modelli ML su larga scala. Puoi eseguire job di addestramento di modelli con container di pre-build per TensorFlow, Scikit learn, XGBoost e PyTorch. Puoi anche eseguire qualsiasi framework utilizzando i tuoi container personalizzati. Per la tua infrastruttura di addestramento, puoi utilizzare acceleratori e più nodi per l'addestramento distribuito. È inoltre disponibile un servizio scalabile basato sull'ottimizzazione bayesiano per l'ottimizzazione degli iperparametri
• Vertex AI Prediction è un servizio gestito per eseguire previsioni batch utilizzando i modelli addestrati e previsioni online eseguendo il deployment dei modelli come microservizio con un'API REST. Il servizio si integra anche con Vertex Explainable AI e Vertex AI Model Monitoring per comprendere i tuoi modelli e ricevere avvisi in caso di disallineamento e deviazione dell'attribuzione di caratteristiche o caratteristiche.
• Vertex AI Model Registry consente di gestire il ciclo di vita dei tuoi modelli ML. Puoi eseguire la versione dei modelli importati e visualizzare le relative metriche sul rendimento. Puoi quindi utilizzare un modello per previsioni batch o eseguire il deployment del modello per la pubblicazione online utilizzando Vertex AI Prediction

Orchestrare il sistema ML utilizzando le pipeline Vertex AI

Questo documento descrive come progettare un sistema ML basato su TFX e come eseguire ogni componente del sistema su larga scala su Google Cloud. Tuttavia, hai bisogno di un agente di orchestrazione per collegare tra loro questi diversi componenti del sistema. L'agente di orchestrazione esegue la pipeline in sequenza e passa automaticamente da un passaggio all'altro in base alle condizioni definite. Ad esempio, una condizione definita potrebbe eseguire il passaggio di pubblicazione del modello dopo il passaggio di valutazione del modello se le metriche di valutazione soddisfano le soglie predefinite. I passaggi possono anche essere eseguiti in parallelo per risparmiare tempo, ad esempio per convalidare l'infrastruttura di deployment e valutare il modello. L'orchestrazione della pipeline ML è utile sia nella fase di sviluppo che in quella di produzione:

• Durante la fase di sviluppo, l'orchestrazione aiuta i data scientist a eseguire l'esperimento ML, anziché eseguire manualmente ogni passaggio.
• Durante la fase di produzione, l'orchestrazione consente di automatizzare l'esecuzione della pipeline ML in base a una pianificazione o a determinate condizioni di attivazione.

ML con Vertex AI Pipelines

Vertex AI Pipelines è un servizio gestito di Google Cloud che consente di orchestrare e automatizzare le pipeline ML in cui ogni componente della pipeline può essere containerizzato su Google Cloud o altre piattaforme cloud. I parametri della pipeline e gli artefatti generati vengono archiviati automaticamente in Vertex ML Metadata, che consente il monitoraggio della derivazione e dell'esecuzione. Il servizio Vertex AI Pipelines è costituito da:

• Interfaccia utente per la gestione e il monitoraggio di esperimenti, job ed esecuzioni.
• Un motore per la pianificazione di flussi di lavoro ML in più fasi.\
• Un SDK Python per definire e manipolare pipeline e componenti.
• Integrazione con [Vertex ML Metadata] per salvare informazioni su esecuzioni, modelli, set di dati e altri artefatti.

Quanto segue costituisce una pipeline eseguita su Vertex AI Pipelines:

• Un insieme di componenti o attività ML containerizzate. Un componente della pipeline è un codice autonomo pacchettizzato come immagine Docker. Un componente esegue un solo passaggio della pipeline. Prende argomenti di input e produce artefatti.
• Una specifica della sequenza delle attività ML, definita tramite un linguaggio specifico del dominio (DSL) Python. La topologia del flusso di lavoro è definita implicitamente collegando gli output di un passaggio a monte agli input di un passaggio a valle. Un passaggio della definizione della pipeline richiama un componente. In una pipeline complessa, i componenti possono essere eseguiti più volte in loop oppure in modo condizionale.
• Un insieme di parametri di input della pipeline, i cui valori vengono passati ai componenti della pipeline, inclusi i criteri per filtrare i dati e la posizione in cui archiviare gli artefatti prodotti dalla pipeline.

Il seguente diagramma mostra un grafico di esempio di Vertex AI Pipelines.

Figura 4. Un grafico di esempio di Vertex AI Pipelines.

SDK Kubeflow Pipelines

L'SDK Kubeflow Pipelines consente di creare componenti, definirne l'orchestrazione ed eseguirli come una pipeline. Affinché un componente venga richiamato nella pipeline, devi creare un'operazione componente. Puoi creare un'operazione componente utilizzando i seguenti metodi:

• Implementazione di un componente Python leggero: questo componente non richiede la creazione di una nuova immagine container per ogni modifica al codice ed è progettato per l'iterazione rapida in un ambiente blocco note. Puoi creare un componente leggero dalla funzione Python utilizzando la funzione kfp.components.create_component_from_func o il decoratore@component.

• Creazione del componente riutilizzabile: questa funzionalità richiede che il componente includa una specifica del componente nel file componente.yaml. La specifica del componente descrive il componente alle pipeline di Kubeflow in termini di argomenti, URL dell'immagine container Docker da eseguire e output. Le operazioni dei componenti vengono create automaticamente dai file componente.yaml utilizzando la funzione kfp.components.load_component durante la compilazione della pipeline. I file YAML delle specifiche dei componenti possono essere condivisi all'interno dell'organizzazione e riutilizzati in diverse orchestrazioni della pipeline.

• Utilizzo dei componenti predefiniti di Google Cloud: l'SDK Google Cloud Pipeline Componentis fornisce componenti predefiniti che eseguono vari servizi gestiti su Google Cloud fornendo i parametri richiesti. Questi componenti consentono di eseguire attività utilizzando servizi come BigQuery, Dataflow, Dataproc e Vertex AI. Per facilità d'uso, puoi caricare questi componenti utilizzando l'SDK google_cloud_pipeline_components. Altri componenti predefiniti sono disponibili per l'esecuzione di job su altre piattaforme e servizi.

Puoi anche utilizzare TFX Pipeline DSL e i componenti TFX. Un componente TFX incapsula la funzionalità dei metadati. Il driver fornisce i metadati all'esecutore eseguendo una query sull'archivio metadati. L'editore accetta i risultati dell'esecutore e li archivia nei metadati. Puoi anche implementare il tuo componente personalizzato, che ha la stessa integrazione con i metadati. Puoi compilare le tue pipeline TFX in un YAML compatibile con Vertex AI Pipelines utilizzando tfx.orchestration.experimental.KubeflowV2DagRunner. Puoi quindi inviare il file a Vertex AI Pipelines per l'esecuzione.

Il seguente diagramma mostra come, in Vertex AI Pipelines, un'attività containerizzata può richiamare altri servizi come job BigQuery, job di addestramento Vertex AI (distribuiti) e job di Dataflow.

Figura 5. Vertex AI Pipelines richiama i servizi gestiti di Google Cloud.

Vertex AI Pipelines ti consente di orchestrare e automatizzare una pipeline ML di produzione eseguendo i servizi Google Cloud richiesti. Nella figura 5, Vertex ML Metadata funge da archivio di metadati ML per Vertex AI Pipelines.

I componenti della pipeline non sono limitati all'esecuzione di servizi correlati a TFX su Google Cloud. Questi componenti possono eseguire qualsiasi servizio relativo ai dati e al calcolo, tra cui Dataproc per i job SparkML, AutoML e altri carichi di lavoro di calcolo.

Containerizzare le attività in Vertex AI Pipelines offre i seguenti vantaggi:

• Disaccoppia l'ambiente di esecuzione dal runtime del codice.
• Fornisce la riproducibilità del codice tra l'ambiente di sviluppo e quello di produzione, perché gli elementi sottoposti a test sono gli stessi in produzione.
• Isola ogni componente della pipeline; ciascuno può avere la propria versione del runtime, linguaggi diversi e librerie diverse.
• È utile per la composizione di pipeline complesse.
• Si integra con Vertex ML Metadata per la tracciabilità e la riproducibilità delle esecuzioni e degli artefatti delle pipeline.

Per un'introduzione completa a Vertex AI Pipelines, consulta l'elenco di esempi di blocchi note disponibili.

Attivazione e pianificazione di Vertex AI Pipelines

Quando esegui il deployment di una pipeline in produzione, devi automatizzarne le esecuzioni, a seconda degli scenari discussi nella sezione Automazione delle pipeline ML.

L'SDK Vertex AI consente di utilizzare la pipeline in modo programmatico. La classe google.cloud.aiplatform.PipelineJob include API per la creazione di esperimenti e per il deployment e l'esecuzione di pipeline. Utilizzando l'SDK, puoi quindi richiamare Vertex AI Pipelines da un altro servizio per ottenere trigger basati su scheduler o eventi.

Figura 6. Diagramma di flusso che mostra più trigger per pipeline Vertex AI con Pub/Sub e Cloud Functions

Nella figura 6 puoi vedere un esempio di come attivare il servizio Vertex AI Pipelines per eseguire una pipeline. La pipeline viene attivata utilizzando l'SDK Vertex AI da Cloud Functions. Cloud Functions è un abbonato a Pub/Sub e viene attivato in base ai nuovi messaggi. Qualsiasi servizio che voglia attivare l'esecuzione della pipeline può semplicemente pubblicare nell'argomento Pub/Sub corrispondente. Nell'esempio precedente abbiamo 3 servizi di pubblicazione:

• Cloud Scheduler pubblica i messaggi in base a una pianificazione e, di conseguenza, attiva la pipeline.
• Cloud Composer pubblica messaggi nell'ambito di un flusso di lavoro più ampio, ad esempio un flusso di lavoro di importazione dati che attiva la pipeline di addestramento dopo l'importazione di nuovi dati in BigQuery.
• Cloud Logging pubblica un messaggio in base a log che soddisfano alcuni criteri di filtro. Puoi configurare i filtri per rilevare l'arrivo di nuovi dati o persino avvisi di deviazione e allineamento generati dal servizio Vertex AI Model Monitoring.

Configurazione di CI/CD per ML su Google Cloud

Vertex AI Pipelines consente di orchestrare sistemi ML che prevedono più passaggi, tra cui pre-elaborazione dei dati, addestramento e valutazione dei modelli e deployment dei modelli. Nella fase di esplorazione della data science, Vertex AI Pipelines consente una rapida sperimentazione dell'intero sistema. Nella fase di produzione, Vertex AI Pipelines consente di automatizzare l'esecuzione della pipeline in base a nuovi dati per addestrare o addestrare nuovamente il modello ML.

Architettura CI/CD

Il seguente diagramma mostra una panoramica generale di CI/CD per ML con Vertex AI Pipelines.

Figura 7: panoramica generale di CI/CD con Vertex AI Pipelines.

Il cuore di questa architettura c'è Cloud Build. Cloud Build può importare codice sorgente da Cloud Source Repositories, GitHub o Bitbucket, quindi eseguire una build in base alle tue specifiche e produrre artefatti come container Docker o file tar Python.

Cloud Build esegue la build come una serie di passaggi di build, definiti in un file di configurazione di compilazione (cloudbuild.yaml). Ogni passaggio di build viene eseguito in un container Docker. Puoi utilizzare i passi di build supportati forniti da Cloud Build o scrivere i tuoi passi di build.

Il processo Cloud Build, che esegue il CI/CD richiesto per il tuo sistema ML, può essere eseguito manualmente o tramite trigger di build automatici. I trigger eseguono i passaggi della build configurati ogni volta che viene eseguito il push delle modifiche all'origine della build. Puoi impostare un trigger di build per eseguire la routine di build in caso di modifiche al repository di codice sorgente o per eseguire la routine di build solo quando le modifiche soddisfano determinati criteri.

Inoltre, puoi avere routine di build (file di configurazione di Cloud Build) che vengono eseguite in risposta a diversi trigger. Ad esempio, puoi avere routine di build che vengono attivate quando vengono effettuati commit al ramo di sviluppo o al ramo master.

Puoi utilizzare le sostituzioni delle variabili di configurazione per definire le variabili di ambiente al momento della creazione. Queste sostituzioni vengono acquisite dalle build attivate. Queste variabili includono $COMMIT_SHA, $REPO_NAME, $BRANCH_NAME, $TAG_NAME e $REVISION_ID. Altre variabili non basate su trigger sono $PROJECT_ID e $BUILD_ID. Le sostituzioni sono utili per le variabili il cui valore non è noto fino al momento della build oppure per riutilizzare una richiesta di build esistente con valori di variabili diversi.

Caso d'uso del flusso di lavoro CI/CD

In genere, un repository di codice sorgente include i seguenti elementi:

• Il codice sorgente del flusso di lavoro della pipeline Python in cui viene definito
• Il codice sorgente dei componenti della pipeline Python e i file di specifiche dei componenti corrispondenti per i diversi componenti della pipeline come convalida dei dati, trasformazione dei dati, addestramento del modello, valutazione del modello e pubblicazione del modello.
• Dockerfile necessari per creare immagini container Docker, uno per ogni componente della pipeline.
• Test delle unità Python e di integrazione per testare i metodi implementati nella pipeline complessiva e del componente.
• Altri script, tra cui il file cloudbuild.yaml, trigger di test e deployment della pipeline.
• File di configurazione (ad esempio il file settings.yaml), incluse le configurazioni dei parametri di input della pipeline.
• Notebooks utilizzati per l'analisi esplorativa dei dati, l'analisi dei modelli e la sperimentazione interattiva sui modelli.

Nell'esempio seguente, una routine di build viene attivata quando uno sviluppatore esegue il push del codice sorgente al ramo di sviluppo dal proprio ambiente di data science.

Figura 8. Esempio di passi di build eseguiti da Cloud Build.

Come mostrato nella Figura 7, Cloud Build esegue i seguenti passaggi di build:

1. Il repository del codice sorgente viene copiato nell'ambiente di runtime di Cloud Build, nella directory /workspace.
2. Esegui i test delle unità e di integrazione.
3. (Facoltativo) Viene eseguita l'analisi del codice statico, ad esempio Pylint.
4. Se i test vengono superati, vengono create le immagini container Docker, una per ogni componente della pipeline. Le immagini sono taggate con il parametro $COMMIT_SHA.
5. Le immagini container Docker vengono caricate su Artifact Registry.
6. L'URL immagine viene aggiornato in ciascuno dei component.yamlfile con le immagini container Docker create e taggate.
7. Il flusso di lavoro della pipeline viene compilato per produrre il file pipeline.json.
8. Il file pipeline.json viene caricato su Artifact Registry.
9. (Facoltativo) Esegui la pipeline con i valori parametro nell'ambito di un test di integrazione o di un'esecuzione in produzione. La pipeline eseguita genera un nuovo modello e potrebbe anche eseguirne il deployment come API su Vertex AI Prediction.

Per un esempio di MLOps end-to-end pronto per la produzione che includa per CI/CD utilizzando Cloud Build, consulta la nostra guida ufficiale su GitHub.

Ulteriori considerazioni

Quando configuri l'architettura ML CI/CD su Google Cloud, considera quanto segue:

• Per l'ambiente di data science, puoi utilizzare una macchina locale o un Vertex AI Workbench.
• Puoi configurare la pipeline automatizzata di Cloud Build in modo da ignorare i trigger, ad esempio se vengono modificati solo i file della documentazione o i blocchi note dell'esperimento.
• Puoi eseguire la pipeline per i test di integrazione e regressione come test della build. Prima del deployment della pipeline nell'ambiente di destinazione, puoi utilizzare il metodo wait() per attendere il completamento dell'esecuzione della pipeline inviata.
• In alternativa all'utilizzo di Cloud Build, puoi utilizzare altri sistemi di build come Jenkins. Un deployment pronto all'uso di Jenkins è disponibile su Google Cloud Marketplace.
• Puoi configurare la pipeline in modo che venga eseguito automaticamente il deployment in diversi ambienti, inclusi sviluppo, test e gestione temporanea, in base a trigger diversi. Inoltre, puoi eseguire manualmente il deployment in ambienti particolari, ad esempio pre-produzione o produzione, in genere dopo aver ottenuto l'approvazione della release. Puoi avere più routine di creazione per trigger diversi o per ambienti di destinazione differenti.
• Puoi utilizzare Apache Airflow, un popolare framework di orchestrazione e pianificazione, per flussi di lavoro generici, che puoi eseguire utilizzando il servizio Cloud Composer completamente gestito. Per saperne di più su come orchestrare le pipeline di dati con Cloud Composer e Cloud Build, consulta Configurazione di una pipeline CI/CD per il flusso di lavoro di elaborazione dati.
• Quando esegui il deployment di una nuova versione del modello in produzione, esegui il deployment come versione canary per avere un'idea delle sue prestazioni (utilizzo di CPU, memoria e disco). Prima di configurare il nuovo modello per gestire tutto il traffico in tempo reale, puoi anche eseguire test A/B. Configura il nuovo modello per gestire dal 10% al 20% del traffico in tempo reale. Se il nuovo modello ha un rendimento migliore rispetto a quello attuale, puoi configurarlo per gestire tutto il traffico. In caso contrario, il sistema di pubblicazione esegue il rollback al modello corrente.

Passaggi successivi

• Scopri di più sulla distribuzione continua in stile GitOps con Cloud Build.
• Scopri di più sulla configurazione di una pipeline CI/CD per il flusso di lavoro di elaborazione dati.
• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.