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

Last reviewed 2024-06-11 UTC

Questo documento descrive l'architettura complessiva di un sistema di machine learning (ML) utilizzando le librerie TensorFlow Extended (TFX). Inoltre, illustra come configurare un'integrazione continua (CI), una distribuzione continua (CD) e un addestramento continuo (CT) per il sistema 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 punteggio o previsione dei modelli.

Questo documento è rivolto a data scientist e ML engineer che vogliono adattare le proprie 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:

• Comprendere CI/CD e automazione nel ML.
• Progettazione di una pipeline ML integrata con TFX.
• Orchestrare e automatizzare la 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 tua pipeline ML. Inoltre, devi automatizzare l'esecuzione della pipeline per l'addestramento continuo dei modelli. Per sperimentare nuove idee e funzionalità, devi adottare pratiche di CI/CD nelle nuove implementazioni delle pipeline. Le sezioni seguenti forniscono una panoramica ad alto livello di CI/CD e CT in ML.

Automazione di pipeline ML

In alcuni casi d'uso, il processo manuale di addestramento, convalida e deployment dei modelli ML può essere sufficiente. Questo approccio manuale funziona se il team gestisce solo alcuni modelli ML che non sono riaddestrati o che non vengono modificati di frequente. In pratica, tuttavia, i modelli spesso si guastano quando vengono implementati nel mondo reale perché non si adattano ai cambiamenti nelle dinamiche degli ambienti o ai dati che descrivono tali dinamiche.

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

• Automatizza l'esecuzione della pipeline ML per riaddestrare nuovi modelli con nuovi dati e acquisire eventuali pattern emergenti. CT verrà discusso più avanti in questo documento nella sezione ML con Vertex AI Pipelines.
• Imposta un sistema di distribuzione continua per eseguire frequentemente il deployment di nuove implementazioni dell'intera pipeline ML. CI/CD viene discussa più avanti in questo documento nella sezione Configurazione 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, in base alla disponibilità di nuovi dati, al peggioramento delle prestazioni del modello, in caso di modifiche significative alle proprietà statistiche dei dati o in base ad altre condizioni.

Pipeline CI/CD a confronto con pipeline CT

La disponibilità di nuovi dati è un trigger per riaddestrare il modello ML. La disponibilità di una nuova implementazione della pipeline ML (tra cui nuova architettura del modello, feature engineering e iperparametri) è un altro importante trigger per eseguire nuovamente la 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 nuovi componenti ML quando sono disponibili nuove implementazioni e approvate per vari ambienti (come 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 per queste pipeline è il seguente:

• Se viene adottata una nuova implementazione, una pipeline CI/CD di successo 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 sezioni seguenti illustrano come progettare un sistema ML integrato utilizzando TensorFlow Extended (TFX) per impostare 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 ML. Questa pipeline TFX è progettata per attività di ML scalabili e ad alte prestazioni. Queste attività includono la modellazione, l'addestramento, la convalida, l'inferenza di distribuzione e la gestione dei deployment. Le librerie delle chiavi di TFX sono le seguenti:

• TensorFlow Data Validation (TFDV): utilizzato per rilevare anomalie nei dati.
• TensorFlow Transform (TFT): utilizzato per la pre-elaborazione dei dati e il feature engineering.
• TensorFlow Estimator e Keras: utilizzati per creare e addestrare modelli ML.
• TensorFlow Model Analysis (TFMA): utilizzato per la valutazione e l'analisi del modello ML.
• TensorFlow Serving (TFServing): utilizzato per gestire modelli 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 tramite una pipeline automatizzata:

1. Estrazione dei dati: il primo passaggio consiste nell'estrazione dei nuovi dati di addestramento dalle relative 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 dei dati previsto (non elaborato). Lo schema dei dati viene creato e corretto durante la fase di sviluppo, prima del deployment del sistema. I passaggi di convalida dei dati rilevano anomalie relative alla distribuzione dei dati e ai disallineamenti dello schema. Gli output di questo passaggio sono le eventuali anomalie e la decisione di eseguire o meno i passaggi downstream.
3. Trasformazione dei dati: una volta convalidati, i dati vengono suddivisi e preparati per l'attività di ML mediante l'esecuzione di 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, generalmente 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 dal 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'ottimizzazione degli 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 distribuzione 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 che non funziona. Questa valutazione garantisce che il modello venga promosso per la pubblicazione solo se soddisfa i criteri di qualità. I criteri possono includere prestazioni eque in vari sottoinsiemi di dati (ad esempio, dati demografici e località) e prestazioni migliorate rispetto ai modelli precedenti o a un modello di benchmark. L'output di questo passaggio è un insieme di metriche delle prestazioni e la decisione di promuovere il modello in produzione.
6. Distribuzione del modello per la previsione: una volta convalidato, il modello appena addestrato viene distribuito come microservizio per fornire previsioni online utilizzando la pubblicazione di TensorFlow. 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 la gestione del 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 vasta scala su una piattaforma affidabile. Il seguente diagramma mostra in che modo viene eseguito ogni passaggio della pipeline TFX ML utilizzando un servizio gestito su Google Cloud, che garantisce agilità, affidabilità e prestazioni su larga scala.

Figura 3. Sistema ML basato su TFX su Google Cloud.

La tabella seguente descrive i servizi chiave Google Cloud mostrati nella figura 3:

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

• Dataflow è un servizio completamente gestito, serverless e affidabile per eseguire pipeline 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 della trasformazione dei dati.
  • Valutazione del modello su un set di dati di grandi dimensioni.
  • Metriche di calcolo su diversi aspetti del set di dati di valutazione.
• Cloud Storage è uno spazio di archiviazione ad alta disponibilità e durevole per oggetti binari di grandi dimensioni. Cloud Storage ospita gli artefatti prodotti durante l'esecuzione della pipeline di 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 addestrare modelli ML su larga scala. Puoi eseguire job di addestramento dei modelli con container predefiniti 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 bayesiana per l'ottimizzazione degli iperparametri.
• Vertex AI Prediction è un servizio gestito per eseguire previsioni batch utilizzando modelli addestrati e previsioni online eseguendo il deployment dei tuoi modelli come microservizi 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 delle caratteristiche o dell'attribuzione delle caratteristiche.
• Vertex AI Model Registry consente di gestire il ciclo di vita dei modelli ML. Puoi modificare la versione dei modelli importati e visualizzarne le metriche delle prestazioni. Un modello può quindi essere utilizzato per le previsioni batch o eseguirne il deployment per la pubblicazione online con Vertex AI Prediction

Orchestrare il sistema ML utilizzando Vertex AI Pipelines

Questo documento spiega come progettare un sistema ML basato su TFX e come eseguire ogni componente del sistema su larga scala in Google Cloud. Tuttavia, hai bisogno di uno strumento di orchestrazione per collegare tra loro questi diversi componenti del sistema. Lo strumento 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 nella fase di sviluppo e produzione:

• Durante la fase di sviluppo, l'orchestrazione aiuta i data scientist a eseguire l'esperimento di ML, invece di 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 ti consente di orchestrare e automatizzare le pipeline di ML in cui ogni componente della pipeline può essere eseguito containerizzato su Google Cloud o altre piattaforme cloud. I parametri della pipeline e gli artefatti generati vengono archiviati automaticamente su Vertex ML Metadata, il 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ù passaggi.\
• Un SDK Python per la definizione e la manipolazione di 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 attività o componenti ML containerizzati. Un componente della pipeline è un codice autonomo pacchettizzato come immagine Docker. Un componente esegue un passaggio nella pipeline. Prende argomenti di input e produce artefatti.
• Una specifica della sequenza delle attività ML, definita tramite un linguaggio specifico per il dominio (DSL) Python. La topologia del flusso di lavoro viene definita implicitamente collegando gli output di un passaggio upstream agli input di un passaggio a valle. Un passaggio nella definizione della pipeline richiama un componente nella pipeline. In una pipeline complessa, i componenti possono essere eseguiti più volte in loop o condizionali.
• Un set 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 pipeline. Per richiamare un componente nella pipeline, devi creare un'operazione del componente. Puoi creare un'operazione del 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 è destinato all'iterazione rapida in un ambiente di blocco note. Puoi creare un componente leggero dalla funzione Python utilizzando la funzione kfp.components.create_component_from_func o il @componente decorator.

• 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 delle pipeline Kubeflow in termini di argomenti, URL dell'immagine container Docker da eseguire e output. Le operazioni dei componenti vengono create automaticamente dai file componenti.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 della tua organizzazione e riutilizzati in diverse orchestrazioni della pipeline.

• Utilizzo dei componenti predefiniti di Google Cloud: l'SDK dei componenti di Google Cloud Pipeline 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 altri servizi.

Puoi anche utilizzare la TFX Pipeline DSL e utilizzare i componenti TFX. Un componente TFX incapsula la funzionalità dei metadati. Il driver fornisce i metadati all'esecutore eseguendo una query sull'archivio dei 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 pipeline TFX in un file YAML compatibile con Vertex AI Pipelines utilizzando tfx.orchestration.experimental.KubeflowV2DagRunner. Quindi puoi 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 (distribuito) e job Dataflow.

Figura 5. Vertex AI Pipelines richiamando i servizi gestiti 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 si limitano 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 job SparkML, AutoML e altri carichi di lavoro di calcolo.

La containerizzazione delle attività in Vertex AI Pipelines offre i seguenti vantaggi:

• Disaccoppia l'ambiente di esecuzione dal runtime del codice.
• Fornisce riproducibilità del codice nell'ambiente di sviluppo e di produzione, perché gli elementi che testi sono gli stessi in produzione.
• Isola ogni componente della pipeline; ognuno può avere la propria versione del runtime, linguaggi e librerie diverse.
• Aiuta con la composizione di pipeline complesse.
• Si integra con Vertex ML Metadata per la tracciabilità e la riproducibilità di esecuzioni e artefatti della 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 descritti nella sezione sull'automazione delle pipeline ML.

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

Figura 6. Diagramma di flusso che mostra vari trigger per Vertex AI Pipelines usando Pub/Sub e Cloud Functions

Nella figura 6 puoi vedere un esempio su 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 sottoscrittore di Pub/Sub e viene attivato in base ai nuovi messaggi. Qualsiasi servizio che desideri attivare l'esecuzione della pipeline può semplicemente pubblicare nell'argomento Pub/Sub corrispondente. Nell'esempio precedente sono presenti tre servizi di pubblicazione:

• Cloud Scheduler pubblica i messaggi in base a una pianificazione, quindi attiva la pipeline.
• Cloud Composer pubblica messaggi come parte 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 ai log che soddisfano alcuni criteri di filtro. Puoi configurare i filtri per rilevare l'arrivo di nuovi dati o persino avvisi di inclinazione e deviazione generati dal servizio Vertex AI Model Monitoring.

Configurazione di CI/CD per ML su Google Cloud

Vertex AI Pipelines ti consente di orchestrare i sistemi di ML che prevedono più passaggi, tra cui la pre-elaborazione dei dati, l'addestramento e la valutazione dei modelli e il deployment dei modelli. Nella fase di esplorazione della data science, Vertex AI Pipelines aiuta a sperimentare rapidamente l'intero sistema. Nella fase di produzione, Vertex AI Pipelines consente di automatizzare l'esecuzione della pipeline in base ai nuovi dati per addestrare o riaddestrare 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 è Cloud Build. Cloud Build può importare il 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 passaggi di build supportati forniti da Cloud Build o scrivere i tuoi passaggi di build.

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

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

Puoi utilizzare le sostituzioni delle variabili di configurazione per definire le variabili di ambiente in fase di 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 attivatori sono $PROJECT_ID e $BUILD_ID. Le sostituzioni sono utili per le variabili il cui valore non è noto fino alla fase di compilazione o 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:

• Codice sorgente del flusso di lavoro delle pipeline Python in cui è definito il flusso di lavoro della pipeline
• Il codice sorgente dei componenti della pipeline Python e i file delle specifiche dei componenti corrispondenti per i vari componenti della pipeline, come convalida dei dati, trasformazione dei dati, addestramento del modello, valutazione del modello e pubblicazione del modello.
• i Dockerfile necessari per creare immagini container Docker, uno per ogni componente della pipeline.
• L'unità Python e i test di integrazione per testare i metodi implementati nel componente e nella pipeline complessiva.
• Altri script, tra cui il file cloudbuild.yaml, trigger di test e deployment della pipeline.
• I 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 dal proprio ambiente di data science al ramo di sviluppo.

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

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

1. Il repository di 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 statica del codice, 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 dell'immagine viene aggiornato in ciascuno dei file component.yaml 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 è stato caricato in Artifact Registry.
9. (Facoltativo) Esegui la pipeline con i valori parametro come parte 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 MLOps end-to-end pronto per la produzione che include CI/CD con Cloud Build, consulta la nostra guida ufficiale su GitHub.

Ulteriori considerazioni

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

• Per l'ambiente di data science, puoi utilizzare una macchina locale o Vertex AI Workbench.
• Puoi configurare la pipeline automatizzata di Cloud Build per saltare i trigger, ad esempio se vengono modificati solo i file di documentazione o i blocchi note della sperimentazione.
• Puoi eseguire la pipeline per i test di integrazione e regressione come test di build. Prima di eseguire il deployment della pipeline nell'ambiente di destinazione, puoi utilizzare il metodo wait() per attendere il completamento dell'esecuzione della pipeline inviata.
• In alternativa a Cloud Build, puoi utilizzare altri sistemi di compilazione come Jenkins. Un deployment pronto all'uso di Jenkins è disponibile su Google Cloud Marketplace.
• Puoi configurare la pipeline per il deployment automatico in diversi ambienti, tra cui sviluppo, test e gestione temporanea, in base a diversi trigger. Inoltre, puoi eseguire il deployment in particolari ambienti manualmente, ad esempio in pre-produzione o produzione, in genere dopo aver ottenuto l'approvazione di una release. Puoi avere più routine di creazione per trigger diversi o ambienti di destinazione diversi.
• Puoi utilizzare Apache Airflow, un noto framework di orchestrazione e pianificazione, per flussi di lavoro per uso generico, che puoi eseguire utilizzando il servizio Cloud Composer completamente gestito. Per ulteriori informazioni su come orchestrare le pipeline di dati con Cloud Composer e Cloud Build, consulta Creazione 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, eseguine 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 prestazioni migliori di quello attuale, puoi configurarlo per gestire tutto il traffico. In caso contrario, il sistema di pubblicazione esegue il rollback al modello attuale.

Passaggi successivi

• Scopri di più sulla distribuzione continua in stile GitHub 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. Visita il nostro Cloud Architecture Center.