Architecture pour les opérations de machine learning avec TFX, Kubeflow Pipelines et Cloud Build

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, continuous integration), une livraison continue (CD, continuous delivery) et un entraînement continu (CT, continuous training) pour le système de ML à l'aide de Cloud Build et de Kubeflow 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 Kubeflow 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 extraction de 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 diffuse un nouveau service de prédiction de modèles.

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'extraction de 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'exporter le modèle enregistré 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, ou d'autres services tels que Katib. 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 accéder à un tutoriel expliquant comment utiliser les bibliothèques TFX, consultez la page sur le ML avec TensorFlow Extended (TFX).

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 AI Platform Training
Évaluation et validation du modèle TensorFlow Model Analysis Dataflow
Modèle diffusé à des fins de prédiction TensorFlow Serving AI Platform Prediction
Stockage d'artefacts du modèle N/A AI Hub
  • 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
  • AI Hub est un dépôt hébergé pensé pour les entreprises et conçu pour la découverte, le partage et la réutilisation des ressources d'IA et de ML. Pour stocker des modèles entraînés et validés, ainsi que les métadonnées pertinentes associées, vous pouvez utiliser AI Hub comme registre de modèles.

  • AI Platform est un service géré permettant d'entraîner et de diffuser des modèles de ML à grande échelle. AI Platform Training est compatible avec les modèles TensorFlow, scikit-learn et XGboost, ainsi qu'avec les modèles mis en œuvre dans n'importe quel framework utilisant un conteneur personnalisé fourni par l'utilisateur. En outre, un service bayésien évolutif et basé sur l'optimisation est disponible pour le réglage d'hyperparamètres. Les modèles entraînés peuvent être déployés dans AI Platform Prediction en tant que microservices dotés d'une API REST.

Orchestrer le système de ML à l'aide de Kubeflow 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. 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.

Machine learning avec Kubeflow Pipelines

Kubeflow est un framework Kubernetes Open Source permettant de développer et d'exécuter des charges de travail de ML portables. Kubeflow Pipelines est un service Kubeflow qui vous permet de composer, d'orchestrer et d'automatiser des systèmes de ML, dont chaque composant peut fonctionner sur Kubeflow, Google Cloud ou d'autres plates-formes cloud. La plate-forme Kubeflow 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. Les pipelines Kubeflow utilisent Argo pour orchestrer les ressources Kubernetes.
  • Un SDK Python permettant de définir et manipuler les pipelines et les composants.
  • Des notebooks permettant d'interagir avec le système à l'aide du SDK Python
  • Un espace de stockage des métadonnées de ML permettant d'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 Kubeflow :

  • 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 utilise des arguments d'entrée, produit des fichiers de sortie et effectue une étape dans le pipeline.

  • 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 avec Kubeflow Pipelines.

Graphique d'un pipeline de ML utilisant Kubeflow Pipelines.

Figure 4 : exemple de graphique avec Kubeflow Pipelines.

Composants de Kubeflow Pipelines

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.func_to_container_op.

  • Création d'un composant réutilisable : cette fonctionnalité nécessite que votre composant inclue 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 ComponentStore.load_components du SDK Kubeflow Pipelines lors de la compilation du pipeline. Les spécifications réutilisables component.yaml peuvent être partagées avec AI Hub pour permettre la composabilité dans différents projets Kubeflow Pipelines.

  • Utilisation de composants Google Cloud prédéfinis : Kubeflow Pipelines 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 AI Platform. Ces composants Google Cloud prédéfinis sont également disponibles dans AI Hub. À l'instar des composants réutilisables, ces opérations de composants sont automatiquement créées à partir des spécifications de composants prédéfinis via ComponentStore.load_components. D'autres composants prédéfinis sont disponibles pour exécuter des tâches dans Kubeflow et sur d'autres plates-formes.

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 a la même intégration avec les métadonnées. TFX fournit une interface de ligne de commande qui compile le code Python du pipeline dans un fichier YAML et décrit le workflow Argo. Vous pouvez ensuite envoyer le fichier à Kubeflow Pipelines.

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

Architecture de Kubeflow Pipelines dans Google Cloud.

Figure 5. pipeline de ML avec Kubeflow Pipelines et les services gérés Google Cloud.

Kubeflow 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, Cloud SQL sert d'espace de stockage pour les métadonnées de ML de Kubeflow Pipelines.

Les composants de Kubeflow Pipelines 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 Kubeflow 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.
  • Elle permet l'intégration avec l'espace de stockage des métadonnées de ML à des fins de traçabilité et de reproductibilité.

Pour obtenir une présentation complète de Kubeflow Pipelines et des exemples utilisant les bibliothèques TFX, consultez l'article de blog Premiers pas avec Kubeflow Pipelines.

Déclencher et programmer des pipelines Kubeflow

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

Kubeflow Pipelines fournit un SDK Python permettant de faire fonctionner le pipeline de manière automatisée. La classe kfp.Client inclut des API permettant de créer des tests, et de déployer et d'exécuter des pipelines. Au moyen du SDK Kubeflow Pipelines, vous pouvez appeler Kubeflow Pipelines à l'aide des services suivants :

  • Selon une programmation, utilisez Cloud Scheduler.
  • En réponse à un événement, utilisez Pub/Sub et Cloud Functions. Par exemple, l'événement peut concerner la disponibilité de nouveaux fichiers de données dans un bucket Cloud Storage.
  • Dans le cadre d'un workflow de traitement des données plus important, utilisez Cloud Composer ou Cloud Data Fusion.

Kubeflow Pipelines fournit également un programmeur intégré pour les pipelines récurrents dans Kubeflow Pipelines.

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

Kubeflow 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. Pendant la phase d'exploration des data scientists, Kubeflow Pipelines permet de réaliser rapidement des tests sur l'ensemble du système. Pendant la phase de production, Kubeflow Pipelines vous permet d'automatiser l'exécution du pipeline en cas d'utilisation 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 Kubeflow Pipelines.

Architecture CI/CD pour le pipeline de ML à l'aide de Kubeflow Pipelines.

Figure 6 : vue d'ensemble de l'architecture CI/CD pour les pipelines Kubeflow.

Au cœur de cette architecture se trouve Cloud Build, une infrastructure. 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 la configuration suivante :

  • Une routine de compilation démarre lorsque des commits sont effectués sur une branche de développement.
  • Une routine de compilation démarre lorsque des commits sont effectués 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, $BRANCE_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 Python permettant de mettre en œuvre des composants de Kubeflow Pipelines, y compris 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.
  • Des tests unitaires Python permettant de tester les méthodes mises en œuvre dans le composant
  • Des fichiers Dockerfile requis pour créer des images de conteneurs Docker, une pour chaque composant de Kubeflow Pipelines.
  • Le fichier component.yaml qui définit les spécifications de composants du pipeline. Ces spécifications sont utilisées pour générer les opérations de composants dans la définition du pipeline.
  • Un module Python (par exemple, le module pipeline.py) dans lequel le workflow Kubeflow Pipelines est défini.
  • D'autres scripts et fichiers de configuration, y compris les fichiers cloudbuild.yaml.
  • Des notebooks utilisés pour l'analyse de données exploratoire, l'analyse de modèles et les tests interactifs sur des modèles.
  • Un fichier de paramètres (par exemple, le fichier settings.yaml), incluant les configurations des paramètres d'entrée du pipeline.

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 science des données.

Exemples d'étapes de compilation.

Figure 7 : 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. Les tests unitaires 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 conteneurs Docker sont créées, une pour chaque composant de Kubeflow Pipelines. Des tags sont ajoutés aux images avec le paramètre $COMMIT_SHA.
  5. Les images de conteneurs Docker sont importées dans Container 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 Kubeflow Pipelines est compilé pour produire le fichier workflow.tar.gz.
  8. Le fichier workflow.tar.gz est importé dans Cloud Storage.
  9. Le pipeline compilé est déployé dans Kubeflow Pipelines, ce qui implique les opérations suivantes :
    1. Lecture des paramètres du pipeline à partir du fichier settings.yaml
    2. Création d'un test (ou utilisation d'un test existant)
    3. Déploiement du pipeline dans Kubeflow Pipelines (et ajout d'un tag de version à son nom)
  10. (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é déploie finalement un modèle en tant qu'API dans AI Platform.

Pour obtenir un exemple détaillé de processus Cloud Build qui inclut la plupart de ces étapes, consultez la page présentant un exemple simple de CI/CD avec Kubeflow Pipelines et Cloud Build.

Informations complémentaires

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

  • Pour l'environnement de science des données, vous pouvez utiliser une machine locale ou une instance Notebooks basée sur une VM de deep learning (DLVM).
  • 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 le tester à l'aide de la méthode wait_for_pipeline_completion, qui permet d'exécuter le pipeline sur un exemple d'ensemble de données.
  • 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