Architecture pour les opérations de machine learning avec TensorFlow Extended, Vertex AI Pipelines et Cloud Build

Last reviewed 2024-06-11 UTC

Ce document décrit l'architecture globale d'un système de machine learning (ML) utilisant des bibliothèques TensorFlow Extended (TFX). Il explique également comment configurer une intégration continue (CI pour « continuous integration »), une livraison continue (CD pour « continuous delivery ») et un entraînement continu (CT pour « continuous training ») pour le système de ML à l'aide de Cloud Build et de Vertex AI Pipelines.

Dans ce document, les termes système de ML et pipeline de ML font référence aux pipelines d'entraînement de modèles, plutôt qu'aux pipelines d'attribution de scores ou de prédiction.

Ce document s'adresse aux data scientists et ingénieurs en ML qui souhaitent adapter leurs pratiques de CI/CD afin de transférer les solutions de ML en production sur Google Cloud, ainsi qu'assurer la qualité, la gestion et l'adaptabilité de leurs pipelines de ML.

Ce document traite des sujets suivants :

  • Comprendre les pratiques de CI/CD et l'automatisation dans le cadre du machine learning
  • Concevoir un pipeline de ML intégré avec TFX
  • Orchestrer et automatiser le pipeline de ML à l'aide de Vertex AI Pipelines
  • Configurer un système CI/CD pour le pipeline de ML à l'aide de Cloud Build

Opérations de machine learning (MLOps)

Pour intégrer un système de ML dans un environnement de production, vous devez orchestrer les étapes dans votre pipeline de ML. En outre, vous devez automatiser l'exécution du pipeline pour l'entraînement continu de vos modèles. Pour tester de nouvelles idées et fonctionnalités, vous devez adopter des pratiques de CI/CD dans les nouvelles mises en œuvre des pipelines. Les sections suivantes offrent une vue d'ensemble des approches de CI/CD et de CT dans le cadre du machine learning.

Automatisation des pipelines de ML

Dans certains cas d'utilisation, le processus manuel d'entraînement, de validation et de déploiement des modèles de ML peut être suffisant. Cette approche manuelle fonctionne si votre équipe ne gère que quelques modèles de ML qui ne sont pas ré-entraînés ni modifiés fréquemment. Toutefois, dans la pratique, les modèles se décomposent souvent lorsqu'ils sont déployés en production, car ils ne parviennent pas à s'adapter aux changements dans les dynamiques des environnements ou aux données décrivant ces dynamiques.

Pour que votre système de ML s'adapte à de tels changements, vous devez appliquer les techniques MLOps suivantes :

Vous pouvez automatiser les pipelines de ML en production pour ré-entraîner vos modèles avec de nouvelles données. Vous pouvez déclencher votre pipeline à la demande, selon une programmation que vous avez définie, dès que de nouvelles données sont disponibles, lorsque les performances des modèles se dégradent, lors de changements importants des propriétés statistiques des données, ou en fonction d'autres conditions.

Comparaison des pipelines CI/CD et CT

La disponibilité de nouvelles données est l'un des déclencheurs du réentraînement du modèle de ML. La disponibilité d'une nouvelle mise en œuvre du pipeline de ML (y compris la disponibilité d'une nouvelle architecture de modèle, d'une nouvelle ingénierie des caractéristiques et de nouveaux hyperparamètres) est un autre déclencheur important de la réexécution du pipeline de ML. Cette nouvelle mise en œuvre du pipeline de ML sert de nouvelle version du service de prédiction de modèles (par exemple un microservice avec une API REST pour la diffusion en ligne). La différence entre les deux cas est la suivante :

  • Pour l'entraînement d'un nouveau modèle de ML avec de nouvelles données, le pipeline CT précédemment déployé est exécuté. Aucun nouveau pipeline ni composant n'est déployé. Seul un nouveau service de prédiction ou un nouveau modèle entraîné est diffusé à la fin du pipeline.
  • Pour l'entraînement d'un nouveau modèle de ML avec une nouvelle mise en œuvre, un nouveau pipeline est déployé via un pipeline CI/CD.

Pour déployer rapidement de nouveaux pipelines de ML, vous devez configurer un pipeline CI/CD. Ce pipeline est chargé du déploiement automatique des nouveaux pipelines et composants de ML lorsque de nouvelles mises en œuvre sont disponibles et approuvées pour différents environnements (développement, test, préproduction, Canary et production).

Le schéma suivant illustre la relation entre le pipeline CI/CD et le pipeline CT.

La sortie du pipeline CI/CD est le pipeline CT.

Figure 1 : pipelines CI/CD et CT.

Le résultat de ces pipelines est le suivant :

  • En cas de nouvelle mise en œuvre, un pipeline CI/CD réussi déploie un nouveau pipeline CT.
  • En cas d'utilisation de nouvelles données, un pipeline CT réussi entraîne un nouveau modèle et le déploie en tant que service de prédiction.

Concevoir un système de ML basé sur TFX

Les sections suivantes expliquent comment concevoir un système de ML intégré à l'aide de TensorFlow Extended (TFX) afin de configurer un pipeline CI/CD pour le système de ML. Bien qu'il existe plusieurs frameworks pour la création de modèles de ML, TFX est une plate-forme de ML intégrée dédiée au développement de systèmes de ML et à leur déploiement en production. Un pipeline TFX est une séquence de composants qui mettent en œuvre un système de ML. Ce pipeline TFX est conçu pour des tâches de ML évolutives et hautes performances. Ces tâches incluent la modélisation, l'entraînement, la validation, la diffusion d'inférences et la gestion des déploiements. Les bibliothèques principales de TFX sont les suivantes :

Présentation du système de ML basé sur TFX

Le schéma suivant montre comment les différentes bibliothèques TFX sont intégrées pour composer un système de ML.

Étapes d'un système de ML basé sur TFX.

Figure 2 : un système de ML basé sur TFX classique.

La figure 2 illustre un système de ML basé sur TFX classique. Les étapes suivantes peuvent être effectuées manuellement ou par le biais d'un pipeline automatisé :

  1. Extraction de données : la première étape consiste à extraire les nouvelles données d'entraînement à partir de leurs sources de données. Cette étape permet d'obtenir les fichiers de données nécessaires pour l'entraînement et l'évaluation du modèle.
  2. Validation des données : la bibliothèque TFDV compare les données avec le schéma de données attendu (brut). Le schéma de données est créé et corrigé pendant la phase de développement, avant le déploiement du système. La phase de validation des données concerne la détection des anomalies liées à la distribution des données et aux écarts de schéma. Cette étape permet de détecter les anomalies (le cas échéant) et de déterminer si d'autres étapes doivent être exécutées en aval.
  3. Transformation des données : une fois les données validées, la bibliothèque TFT effectue des transformations de données et des opérations d'ingénierie des caractéristiques afin de diviser les données et de les préparer pour la tâche de ML. Cette étape permet d'obtenir des fichiers de données pour entraîner et évaluer le modèle, généralement transformés au format TFRecords. En outre, les artefacts de transformation produits permettent de construire les entrées du modèle et d'intégrer le processus de transformation dans le modèle enregistré exporté après l'entraînement.
  4. Entraînement et réglage du modèle : pour mettre en œuvre et entraîner le modèle de ML, utilisez l'API tf.estimator ou l'API tf.Keras avec les données transformées générées à l'étape précédente. Pour sélectionner les paramètres qui permettent d'obtenir le meilleur modèle, vous pouvez utiliser Keras Tuner, une bibliothèque de réglages d'hyperparamètres pour Keras. Vous pouvez également utiliser d'autres services, tels queKatib, Vertex AI Vizier ou le réglage des hyperparamètres de Vertex AI. Cette étape permet d'obtenir un modèle enregistré qui est utilisé pour l'évaluation, et un autre modèle enregistré qui est utilisé pour la diffusion en ligne du modèle à des fins de prédiction.
  5. Évaluation et validation du modèle : lorsque le modèle est exporté après l'étape d'entraînement, la bibliothèque TFMA évalue sa qualité par rapport à un ensemble de données de test. Cette bibliothèque évalue la qualité globale du modèle et identifie les parties du modèle de données qui ne sont pas performantes. Cette évaluation permet de garantir que le modèle ne sera diffusé que s'il répond aux critères de qualité. Les critères peuvent inclure des performances équivalentes sur différents sous-ensembles de données (par exemple, des données démographiques et des données d'emplacement), et des performances améliorées par rapport à des modèles précédents ou à un modèle de référence. Cette étape permet d'obtenir un ensemble de métriques de performances et de déterminer si le modèle peut être utilisé en production.
  6. Diffusion du modèle à des fins de prédiction : une fois que le nouveau modèle entraîné est validé, il est déployé en tant que microservice pour diffuser des prédictions en ligne à l'aide de la bibliothèque TensorFlow Serving. Cette étape permet de déployer un service de prédiction pour le modèle de ML entraîné. Vous pouvez remplacer cette étape en stockant le modèle entraîné dans un registre de modèles. Par la suite, un modèle distinct diffusant le processus CI/CD est lancé.

Pour obtenir un exemple d'utilisation des bibliothèques TFX, consultez le tutoriel officiel du composant TFX Keras.

Système de ML basé sur TFX dans Google Cloud

Dans un environnement de production, les composants du système doivent s'exécuter à grande échelle sur une plate-forme fiable. Le schéma suivant illustre l'exécution de chaque étape du pipeline de ML basé sur TFX à l'aide d'un service géré sur Google Cloud, ce qui permet de garantir un niveau d'agilité et de fiabilité élevé et de hautes performances à grande échelle.

Étapes d'un système de ML basé sur TFX dans Google Cloud.

Figure 3 : système de ML basé sur TFX dans Google Cloud.

Le tableau suivant décrit les principaux services Google Cloud présentés dans la figure 3 :

Étape Bibliothèque TFX Service Google Cloud
Extraction et validation des données TensorFlow Data Validation Dataflow
Transformation des données TensorFlow Transform Dataflow
Entraînement et réglage du modèle TensorFlow Vertex AI Training
Évaluation et validation du modèle TensorFlow Model Analysis Dataflow
Diffusion du modèle pour les prédictions TensorFlow Serving Vertex AI Prediction
Stockage de modèles N/A Vertex AI Model Registry
  • Dataflow est un service entièrement géré, sans serveur et fiable permettant d'exécuter des pipelines Apache Beam à grande échelle sur Google Cloud. Dataflow permet de soumettre les processus suivants au scaling :
    • Calcul des statistiques pour valider les données entrantes
    • Préparation et transformation des données
    • Évaluation du modèle sur un ensemble de données volumineux
    • Calcul des métriques sur différents aspects de l'ensemble de données d'évaluation
  • Cloud Storage est un espace de stockage à disponibilité élevée et durable pour les blobs. Cloud Storage héberge les artefacts produits tout au long de l'exécution du pipeline de ML, y compris les éléments suivants :
    • Anomalies des données (le cas échéant)
    • Données et artefacts transformés
    • Modèle exporté (entraîné)
    • Métriques d'évaluation du modèle
  • Vertex AI Training est un service géré permettant d'entraîner des modèles de ML à grande échelle. Vous pouvez exécuter des tâches d'entraînement de modèle avec des conteneurs prédéfinis pour TensorFlow, Scikit-learn, XGBoost et PyTorch. Vous pouvez également exécuter n'importe quel framework à l'aide de vos propres conteneurs personnalisés. Pour votre infrastructure d'entraînement, vous pouvez utiliser des accélérateurs et plusieurs nœuds pour l'entraînement distribué. En outre, un service bayésien évolutif et basé sur l'optimisation est disponible pour le réglage des hyperparamètres.
  • Vertex AI Prediction est un service géré permettant d'exécuter des prédictions par lots à l'aide de vos modèles entraînés et des prédictions en ligne en déployant vos modèles en tant que microservices grâce à une API REST. Le service s'intègre également à Vertex Explainable AI et à Vertex AI Model Monitoring pour comprendre vos modèles et recevoir des alertes en cas de différence ou d'écart d'attribution de caractéristique ou de caractéristique.
  • Vertex AI Model Registry vous permet de gérer le cycle de vie de vos modèles de ML. Vous pouvez gérer les versions de vos modèles importés et afficher leurs métriques de performances. Un modèle peut ensuite être utilisé pour les prédictions par lot ou pour déployer votre modèle pour une diffusion en ligne à l'aide de Vertex AI Prediction

Orchestrer le système de ML à l'aide de Vertex AI Pipelines

Ce document explique comment concevoir un système de ML basé sur TFX et exécuter chaque composant du système à grande échelle sur Google Cloud. Toutefois, vous avez besoin d'un orchestrateur pour connecter les différents composants du système. L'orchestrateur exécute le pipeline sous forme de séquence et passe automatiquement d'une étape à l'autre en fonction des conditions définies. Par exemple, une condition définie peut être l'exécution de l'étape de diffusion du modèle après l'étape d'évaluation du modèle dès lors que les métriques d'évaluation atteignent les seuils prédéfinis. Les étapes peuvent également s'exécuter en parallèle afin de gagner du temps, par exemple pour valider l'infrastructure de déploiement et évaluer le modèle. L'orchestration du pipeline de ML est utile dans les phases de développement et de production :

  • Pendant la phase de développement, l'orchestration permet aux data scientists d'exécuter de manière automatisée les tests de ML au lieu d'effectuer manuellement chaque étape.
  • Pendant la phase de production, l'orchestration permet d'automatiser l'exécution du pipeline de ML en fonction d'une programmation ou de certaines conditions de déclenchement.

ML avec Vertex AI Pipelines

Vertex AI Pipelines est un service géré de Google Cloud qui vous permet d'orchestrer et d'automatiser des pipelines de ML, où chaque composant du pipeline peut être conteneurisé sur Google Cloud ou d'autres plates-formes cloud. Les paramètres et les artefacts de pipeline générés sont automatiquement stockés sur Vertex ML Metadata, ce qui permet la traçabilité et le suivi d'exécution. Le service Vertex AI Pipelines comprend les éléments suivants :

  • Une interface utilisateur permettant de gérer et suivre les tests, les tâches et les exécutions
  • Un moteur permettant de programmer des workflows de ML en plusieurs étapes.\
  • Un SDK Python permettant de définir et manipuler les pipelines et les composants.
  • Intégration avec [Vertex ML Metadata] pour enregistrer des informations sur les exécutions, les modèles, les ensembles de données et d'autres artefacts.

Les éléments suivants constituent un pipeline exécuté sur Vertex AI Pipelines :

  • Un ensemble de tâches de ML conteneurisées, ou des composants. Un composant de pipeline est un code autonome empaqueté sous forme d'image Docker. Un composant effectue une étape dans le pipeline. Il prend des arguments d'entrée et produit des artefacts.
  • Une spécification de la séquence des tâches de ML, définie dans un langage dédié Python. La topologie du workflow est implicitement définie par la connexion des sorties d'une étape en amont aux entrées d'une étape en aval. Une étape de la définition du pipeline appelle un composant dans le pipeline. Dans un pipeline complexe, les composants peuvent s'exécuter plusieurs fois en boucle ou s'exécuter de manière conditionnelle.
  • Un ensemble de paramètres d'entrée de pipeline, dont les valeurs sont transmises aux composants du pipeline, y compris les critères de filtrage des données et l'emplacement de stockage des artefacts produits par le pipeline.

Le schéma suivant montre un exemple de graphique de Vertex AI Pipelines.

Graphique d'un pipeline de ML utilisant Vertex AI Pipelines.

Figure 4. Exemple de graphique de Vertex AI Pipelines.

SDK Kubeflow Pipelines

Le SDK Kubeflow Pipelines vous permet de créer des composants, de définir leur orchestration et de les exécuter en tant que pipeline. Pour qu'un composant soit appelé dans le pipeline, vous devez créer une opération de composant. Pour ce faire, vous pouvez utiliser l'une des méthodes suivantes :

  • Mise en œuvre d'un composant Python léger : ce composant ne nécessite pas la création d'une image de conteneur pour chaque modification de code, et permet de créer des itérations rapides dans un environnement de notebook. Vous pouvez créer un composant léger à partir de votre fonction Python à l'aide de la fonction kfp.components.create_component_from_func ou à l'aide du décorateur @component.

  • Création d'un composant réutilisable : cette fonctionnalité nécessite que votre composant inclut une spécification de composant dans le fichier component.yaml. La spécification du composant décrit le composant en termes d'arguments dans le cadre de Kubeflow Pipelines, l'URL de l'image de conteneur Docker à exécuter et les sorties. Les opérations de composants sont automatiquement créées à partir des fichiers component.yaml à l'aide de la fonction kfp.components.load_component lors de la compilation du pipeline. Les fichiers YAML de spécification de composant peuvent être partagés dans votre organisation et réutilisés dans différentes orchestrations de pipeline.

  • Utilisation de composants Google Cloud prédéfinis : le SDK des composants de pipeline Google Cloud fournit des composants prédéfinis qui exécutent divers services gérés sur Google Cloud en fournissant les paramètres requis. Ces composants vous aident à exécuter des tâches à l'aide de services tels que BigQuery, Dataflow, Dataproc et Vertex AI. Pour faciliter leur utilisation, vous pouvez charger ces composants à l'aide du SDK google_cloud_pipeline_components. D'autres composants prédéfinis sont disponibles pour exécuter des tâches sur d'autres plates-formes et services.

Vous pouvez également utiliser le langage dédié du pipeline TFX et les composants TFX. Un composant TFX encapsule la fonctionnalité de métadonnées. Le pilote fournit les métadonnées à l'exécuteur en interrogeant l'espace de stockage des métadonnées. L'éditeur accepte les résultats de l'exécuteur et les stocke dans les métadonnées. Vous pouvez également mettre en œuvre votre composant personnalisé, qui dispose de la même intégration avec les métadonnées. Vous pouvez compiler vos pipelines TFX dans un fichier YAML compatible avec Vertex AI Pipelines à l'aide de tfx.orchestration.experimental.KubeflowV2DagRunner. Vous pouvez ensuite envoyer le fichier à Vertex AI Pipelines pour exécution.

Le schéma suivant montre comment, dans Vertex AI Pipelines, une tâche en conteneur peut appeler d'autres services tels que des tâches BigQuery, des tâches d'entraînement Vertex AI (distribuées) et des tâches Dataflow.

Architecture Vertex AI Pipelines sur Google Cloud.

Figure 5. Vertex AI Pipelines appelant des services gérés Google Cloud.

Vertex AI Pipelines vous permet d'orchestrer et d'automatiser un pipeline de ML en production en exécutant les services Google Cloud requis. Dans la figure 5, Vertex ML Metadata sert de magasin de métadonnées pour Vertex AI Pipelines.

Les composants de pipeline ne se limitent pas à l'exécution de services liés à TFX sur Google Cloud. Ces composants peuvent exécuter tous les services liés aux données et au calcul, y compris Dataproc pour les tâches SparkML, AutoML et d'autres charges de travail de calcul.

La conteneurisation de tâches dans Vertex AI Pipelines présente les avantages suivants :

  • Elle permet de dissocier l'environnement d'exécution de l'environnement d'exécution de votre code.
  • Elle permet de reproduire le code entre l'environnement de développement et l'environnement de production, car les éléments que vous testez sont identiques en production.
  • Elle permet d'isoler les différents composants du pipeline. Chacun d'entre eux peut utiliser sa propre version de l'environnement d'exécution, différents langages et différentes bibliothèques.
  • Elle permet de composer des pipelines complexes.
  • S'intègre à Vertex ML Metadata pour la traçabilité et la reproductibilité des exécutions et des artefacts de pipelines

Pour obtenir une présentation complète de Vertex AI Pipelines, consultez la liste des exemples de notebooks disponibles.

Déclencher et programmer Vertex AI Pipelines

Lorsque vous déployez un pipeline en production, vous devez automatiser ses exécutions en fonction des scénarios décrits dans la section Automatisation du pipeline de ML.

Le SDK Vertex AI vous permet d'exploiter le pipeline de manière automatisée. La classe google.cloud.aiplatform.PipelineJob inclut des API permettant de créer des tests, mais aussi de déployer et d'exécuter des pipelines. En utilisant le SDK, vous pouvez appeler Vertex AI Pipelines à partir d'un autre service pour obtenir des déclencheurs basés sur un programmeur ou sur des événements.

Déclencheurs Vertex AI Pipelines.

Figure 6. Organigramme illustrant l'utilisation de plusieurs déclencheurs avec Vertex AI Pipelines grâce à Pub/Sub et Cloud Functions

Dans la figure 6, vous pouvez consulter un exemple de déclenchement du service Vertex AI Pipelines pour exécuter un pipeline. Le pipeline est déclenché en utilisant le SDK Vertex AI à partir d'une fonction Cloud. Cloud Functions est abonné à Pub/Sub et déclenché au gré des nouveaux messages. Tout service souhaitant déclencher l'exécution du pipeline peut simplement publier sur le sujet Pub/Sub correspondant. Dans l'exemple ci-dessus, nous avons trois services de publication :

  • Cloud Scheduler publie des messages de manière planifiée et déclenche donc le pipeline.
  • Cloud Composer publie des messages dans le cadre d'un workflow plus important, par exemple un workflow d'ingestion de données qui déclenche le pipeline d'entraînement après l'ingestion de nouvelles données dans BigQuery.
  • Cloud Logging publie un message sur la base de journaux répondant à certains critères de filtrage. Vous pouvez configurer les filtres pour détecter l'arrivée de nouvelles données ou même les alertes d'écarts et de dérives générées par le service Vertex AI Model Monitoring.

Configurer l'intégration continue et la livraison continue pour le machine learning dans Google Cloud

Vertex AI Pipelines vous permet d'orchestrer des systèmes de ML impliquant plusieurs étapes, y compris le prétraitement des données, l'entraînement et l'évaluation des modèles, ainsi que le déploiement des modèles. En data science, Vertex AI Pipelines permet de tester rapidement l'ensemble du système pendant la phase d'exploration. Pendant la phase de production, Vertex AI Pipelines vous permet d'automatiser l'exécution du pipeline en fonction de nouvelles données afin d'entraîner ou de ré-entraîner le modèle de ML.

Architecture CI/CD

Le schéma suivant présente une vue d'ensemble de l'architecture CI/CD dans le cadre du machine learning avec Vertex AI Pipelines.

Architecture CI/CD pour le pipeline de ML avec Vertex AI Pipelines.

Figure 7 : vue d'ensemble de l'architecture CI/CD avec Vertex AI Pipelines.

Au cœur de cette architecture se trouve Cloud Build. Cloud Build peut importer une source depuis Cloud Source Repositories, GitHub ou Bitbucket, puis exécuter une compilation selon vos spécifications et produire des artefacts, tels que des conteneurs Docker ou des fichiers tar Python.

Cloud Build exécute votre compilation sous la forme d'une série d'étapes de compilation, définie dans un fichier de configuration de compilation (cloudbuild.yaml). Chaque étape est exécutée dans un conteneur Docker. Vous pouvez soit utiliser les étapes de compilation compatibles fournies par Cloud Build, soit créer vos propres étapes de compilation.

Le processus Cloud Build, qui effectue l'intégration continue et la livraison continue requises pour votre système de ML, peut être exécuté manuellement ou via des déclencheurs de compilation automatisés. Les déclencheurs exécutent vos étapes de compilation configurées chaque fois que des modifications sont apportées à votre source de compilation. Vous pouvez définir un déclencheur de compilation afin d'exécuter la routine de compilation à chaque fois qu'une modification est apportée au dépôt source, ou exécuter la routine de compilation uniquement lorsque les modifications répondent à certains critères.

En outre, vous pouvez utiliser des routines de compilation (fichiers de configuration Cloud Build) qui sont exécutées en réponse à différents déclencheurs. Par exemple, vous pouvez avoir des routines de compilation qui sont déclenchées lorsque des commits sont effectués sur la branche de développement ou sur la branche principale.

Vous pouvez utiliser des substitutions de variables de configuration pour définir les variables d'environnement au moment de la compilation. Ces substitutions sont capturées à partir des compilations déclenchées. Ces variables incluent $COMMIT_SHA, $REPO_NAME, $BRANCH_NAME, $TAG_NAME et $REVISION_ID. Les autres variables non basées sur un déclencheur sont $PROJECT_ID et $BUILD_ID. Les substitutions sont utiles pour les variables dont la valeur n'est pas connue avant la compilation, ou pour réutiliser une requête de compilation existante avec des valeurs de variables différentes.

Cas d'utilisation du workflow CI/CD

Un dépôt de code source comprend généralement les éléments suivants :

  • Le code source du workflow de pipelines Python, dans lequel le workflow du pipeline est défini.
  • Le code source des composants du pipeline Python et les fichiers de spécification de composant correspondants pour les différents composants du pipeline, tels que la validation des données, la transformation des données, l'entraînement des modèles, l'évaluation des modèles et la diffusion des modèles.
  • Les fichiers Dockerfile requis pour créer des images de conteneurs Docker, à raison d'un par composant du pipeline.
  • Les tests unitaires et d'intégration Python permettant de tester les méthodes mises en œuvre dans le pipeline et le pipeline global
  • D'autres scripts incluant le fichier cloudbuild.yaml, les déclencheurs de test et les déploiements de pipeline.
  • Des fichiers de configuration (par exemple, le fichier settings.yaml) incluant notamment les configurations des paramètres d'entrée du pipeline
  • Des notebooks utilisés pour l'analyse de données exploratoire, l'analyse de modèles et les tests interactifs sur des modèles.

Dans l'exemple suivant, une routine de compilation est déclenchée lorsqu'un développeur soumet du code source sur la branche de développement depuis son environnement de data science.

Exemples d'étapes de compilation.

Figure 8. exemples d'étapes de compilation effectuées par Cloud Build.

Comme illustré dans la figure 7, Cloud Build effectue les étapes de compilation suivantes :

  1. Le dépôt de code source est copié dans l'environnement d'exécution de Cloud Build, dans le répertoire /workspace.
  2. Des tests unitaires et des tests d'intégration sont exécutés.
  3. (Facultatif) Une analyse de code statique est exécutée, telle que Pylint.
  4. Si les tests réussissent, les images de conteneur Docker sont créées à raison d'une par composant du pipeline. Des tags sont ajoutés aux images avec le paramètre $COMMIT_SHA.
  5. Les images de conteneurs Docker sont importées dans Artifact Registry.
  6. L'URL de l'image est mise à jour dans chacun des fichiers component.yaml avec les images de conteneurs Docker créées et taguées.
  7. Le workflow du pipeline est compilé pour produire le fichier pipeline.json.
  8. Le fichier pipeline.json est importé dans Artifact Registry.
  9. (Facultatif) Le pipeline est exécuté avec les valeurs de paramètres dans le cadre d'un test d'intégration ou d'une exécution en production. Le pipeline exécuté génère un nouveau modèle et peut également déployer le modèle en tant qu'API sur Vertex AI Prediction.

Pour obtenir un exemple de MLOps de bout en bout incluant la CI/CD à l'aide de Cloud Build, consultez notre guide officiel sur GitHub

Autres considérations

Lorsque vous configurez l'architecture CI/CD pour le ML sur Google Cloud, tenez compte des points suivants :

  • Pour l'environnement de data science, vous pouvez utiliser une machine locale ou Vertex AI Workbench.
  • Vous pouvez configurer le pipeline Cloud Build automatisé de manière à ignorer les déclencheurs, par exemple, si seuls les fichiers de documentation sont modifiés ou si les notebooks de tests sont modifiés.
  • Vous pouvez exécuter le pipeline en tant que test de compilation pour les tests d'intégration et de régression. Avant de déployer le pipeline dans l'environnement cible, vous pouvez utiliser la méthode wait() pour attendre la fin de l'exécution du pipeline soumis.
  • Au lieu d'utiliser Cloud Build, vous pouvez utiliser d'autres systèmes de compilation, tels que Jenkins. Un déploiement prêt à l'emploi de Jenkins est disponible sur Google Cloud Marketplace.
  • Vous pouvez configurer le pipeline afin qu'il se déploie automatiquement dans différents environnements, y compris les environnements de développement, de test et de préproduction, en fonction de différents déclencheurs. En outre, vous pouvez le déployer manuellement dans des environnements particuliers, tels que la préproduction ou la production, généralement après avoir obtenu une approbation de mise en production. Vous pouvez avoir plusieurs routines de compilation pour différents déclencheurs ou différents environnements cibles.
  • Pour des workflows à usage général, vous pouvez utiliser Apache Airflow, un framework d'orchestration et de programmation populaire. Vous pouvez l'exécuter à l'aide du service entièrement géré Cloud Composer. Pour en savoir plus sur l'orchestration des pipelines de données avec Cloud Composer et Cloud Build, consultez la page Configurer un pipeline CI/CD pour votre workflow de traitement des données.
  • Lorsque vous déployez une nouvelle version du modèle en production, déployez-la en tant que version Canary pour avoir une idée de ses performances (processeur, mémoire et utilisation du disque). Avant de configurer le nouveau modèle de manière à diffuser tout le trafic en direct, vous pouvez également effectuer des tests A/B. Configurez le nouveau modèle de manière à ce qu'il diffuse entre 10 % et 20 % du trafic en direct. Si le nouveau modèle est plus performant que le modèle actuel, vous pouvez le configurer pour qu'il diffuse tout le trafic. Dans le cas contraire, le système de diffusion revient au modèle actuel.

Étape suivante