Cette architecture de référence montre comment implémenter une intégration continue (CI), une livraison continue (CD) et un pipeline de réentraînement pour une application IA à l’aide d’Azure DevOps et d’Azure Machine Learning. La solution est basée sur le jeu de données « diabetes » de scikit-learn, mais elle est facilement adaptable à n’importe quel scénario IA et à d’autres systèmes de génération populaires, tels que Jenkins ou Travis.
Une implémentation de référence pour cette architecture est disponible sur GitHub.
Architecture
Téléchargez un fichier Visio de cette architecture.
Workflow
Cette architecture se compose des services suivants :
Azure Pipelines . Ce système de génération et de test s’appuie sur Azure DevOps et est utilisé pour les pipelines de build et de mise en production. Azure Pipelines divise ces pipelines en étapes logiques appelées tâches. Par exemple, la tâche Azure CLI facilite l’utilisation des ressources Azure.
Azure Machine Learning est un service cloud pour l’entraînement, le scoring, le déploiement et la gestion des modèles Machine Learning à grande échelle. Cette architecture utilise le kit SDK pour Python d’Azure Machine Learning afin de créer un espace de travail, des ressources de calcul, le pipeline Machine Learning et l’image de scoring. Un espace de travail Azure Machine Learning fournit l’espace nécessaire à l’expérimentation et à l’entraînement, ainsi qu’au déploiement de modèles Machine Learning.
La capacité de calcul Azure Machine Learning est un cluster de machines virtuelles à la demande, doté d’une mise à l’échelle automatique et d’options de nœuds Processeur et GPU. Le travail d’entraînement est exécuté sur ce cluster.
Pipelines Azure Machine Learning . Ces pipelines fournissent des workflows Machine Learning réutilisables qui peuvent resservir dans différents scénarios. Pour ce cas d’usage, l’entraînement, l’évaluation du modèle, l’inscription du modèle et la création d’une image se produisent à des étapes différentes dans ces pipelines. Le pipeline est publié ou mis à jour à la fin de la phase de génération, et il est déclenché lors de l’arrivée de nouvelles données.
Stockage Blob Azure . Les conteneurs d’objets blob sont utilisés pour stocker les journaux à partir du service de scoring. Dans ce cas, les données d’entrée et la prédiction de modèle sont collectées. Après quelques transformations, ces journaux peuvent être utilisés pour le réentraînement du modèle.
Azure Container Registry . Le script Python de scoring est empaqueté en tant qu’image Docker, et versionné dans le Registre.
Azure Container Instances . Dans le cadre d’un pipeline de mise en production, l’environnement intermédiaire et AQ est imité en déployant l’image du service web de scoring sur Container Instances, ce qui offre un moyen serverless simple pour exécuter un conteneur.
Azure Kubernetes Service . Une fois l’image du service web de scoring minutieusement testée dans l’environnement AQ, elle est déployée dans l’environnement de production sur un cluster Kubernetes managé.
Azure Application Insights . Ce service de supervision est utilisé pour détecter les anomalies de performance.
Pipeline MLOps
Cette solution illustre une automatisation de bout en bout des différentes étapes d’un projet IA, à l’aide d’outils qui sont déjà familiers aux ingénieurs logiciels. Le problème de Machine Learning est simple pour conserver le focus sur le pipeline DevOps. La solution utilise le jeu de données « diabetes » de scikit-learn et crée un modèle de régression linéaire de crête (ridge) pour prédire le risque de diabète.
Cette solution s’appuie sur les trois pipelines suivants :
- Pipeline de build. Génère le code et exécute une suite de tests.
- Pipeline de réentraînement. Réentraîne le modèle selon une planification ou lorsque de nouvelles données sont disponibles.
- Pipeline de mise en production. Opérationnalise l’image de scoring et la promeut de manière sécurisée dans différents environnements.
Les sections suivantes décrivent chacun de ces pipelines.
Pipeline de build
Le pipeline CI est déclenché chaque fois que du code est archivé. Il publie un pipeline Azure Machine Learning mis à jour après la génération du code et l’exécution d’une suite de tests. Le pipeline de build est composé des tâches suivantes :
Qualité du code. Ces tests garantissent que le code est conforme aux standards de l’équipe.
Test unitaire. Ces tests permettent de s’assurer que le code fonctionne, qu’il dispose d’une couverture de code appropriée et qu’il est stable.
Test de données. Ces tests vérifient que les exemples de données sont conformes au schéma et à la distribution qui sont attendus. Personnalisez ce test pour d’autres cas d’usage et exécutez-le comme pipeline de validité des données distinct, déclenché au fur et à mesure que de nouvelles données arrivent. Par exemple, déplacez la tâche de test des données sur un pipeline d’ingestion de données pour pouvoir les tester plus tôt.
Notes
Vous devez envisager l’activation des pratiques DevOps pour les données servant à entraîner les modèles Machine Learning, mais ce sujet n’est pas traité dans cet article. Pour plus d’informations sur l’architecture et les bonnes pratiques relatives à l’intégration continue/livraison continue d’un pipeline d’ingestion de données, consultez DevOps pour un pipeline d’ingestion des données.
Les tâches uniques suivantes se produisent lors de la configuration de l’infrastructure pour Azure Machine Learning et le kit SDK Python :
- Création de l’espace de travail qui héberge toutes les ressources liées à Azure Machine Learning.
- Création des ressources de calcul qui exécutent le travail d’entraînement.
- Création du pipeline Machine Learning avec le script d’entraînement mis à jour.
- Publication du pipeline Machine Learning en tant que point de terminaison REST pour orchestrer le workflow d’entraînement. La section suivante décrit cette étape.
Pipeline de réentraînement
Le pipeline Machine Learning orchestre le processus de réentraînement du modèle de manière asynchrone. Le réentraînement peut être déclenché selon une planification ou lorsque de nouvelles données sont disponibles en appelant le point de terminaison REST du pipeline publié à l’étape précédente.
Ce pipeline se décompose selon les étapes suivantes :
Entraînement du modèle. Le script Python d’entraînement est exécuté sur la ressource de Capacité de calcul Machine Learning pour obtenir un nouveau fichier de modèle qui est stocké dans l’historique d’exécution. L’entraînement étant la tâche la plus gourmande en ressources système dans un projet IA, la solution utilise la Capacité de calcul Azure Machine Learning.
Évaluation du modèle. Un test d’évaluation simple compare le nouveau modèle au modèle existant. Ce n’est que lorsque le nouveau modèle est meilleur qu’il est promu. Dans le cas contraire, le modèle n’est pas enregistré, et le pipeline est annulé.
Inscription du modèle. Le modèle réentraîné est inscrit auprès du Registre de modèles Azure Machine Learning. Ce service fournit un contrôle de version des modèles ainsi que des balises de métadonnées afin de les rendre facilement reproductibles.
Pipeline de mise en production
Ce pipeline montre comment opérationnaliser l’image de scoring et la promouvoir de manière sécurisée dans différents environnements. Ce pipeline est subdivisé en deux environnements, AQ et production :
Environnement AQ
Déclencheur Model Artifact. Les pipelines de mise en production sont déclenchés chaque fois qu’un nouvel artefact est disponible. Un nouveau modèle inscrit auprès de la Gestion des modèles Azure Machine Learning est traité comme artefact de mise en production. Dans ce cas, un pipeline est déclenché pour chaque nouveau modèle inscrit.
Créez une image de scoring. Le modèle inscrit est empaqueté avec un script de scoring et les dépendances Python (fichier YAML Conda) dans une image Docker d’opérationnalisation. La version de l’image est automatiquement gérée par Azure Container Registry.
Déploiement sur Container Instances. Ce service est utilisé pour créer un environnement hors production. L’image de scoring est également déployée ici, et l’utilisation qui en est faite est principalement à des fins de test. Container Instances offre un moyen simple et rapide de tester l’image Docker.
Test du service web. Un test d’API simple garantit que l’image est déployée avec succès.
Environnement de production
Déploiement sur Azure Kubernetes Service. Ce service est utilisé pour déployer l’image de scoring comme service web à grande échelle dans un environnement de production.
Test du service web. Un test d’API simple garantit que l’image est déployée avec succès.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.
Extensibilité
Un pipeline de build sur Azure DevOps peut être mis à l’échelle pour des applications de toutes tailles. Les pipelines de build disposent d’un délai d’expiration maximal qui varie en fonction de l’agent sur lequel ils sont exécutés. Les builds peuvent s’exécuter indéfiniment sur des agents auto-hébergés (agents privés). En ce qui concerne les agents hébergés par Microsoft pour un projet public, les builds peuvent s’exécuter pendant six heures. Quant aux projets privés, la limite est fixée à 30 minutes.
Pour utiliser le délai d’expiration maximal, définissez la propriété suivante dans votre fichier YAML Azure Pipelines :
jobs:
- job: <job_name>
timeoutInMinutes: 0
Dans l’idéal, votre pipeline de build doit se terminer rapidement et n’exécuter que les tests unitaires et un sous-ensemble d’autres tests. De cette façon, vous pouvez valider les modifications rapidement, et les corriger si des problèmes surviennent. Exécutez les tests de longue durée pendant les heures creuses.
Le pipeline de mise en production publie un service web de scoring en temps réel. Pour des raisons pratiques, une mise en production dans l’environnement AQ est réalisée à l’aide de Container Instances, mais vous pouvez utiliser un autre cluster Kubernetes s’exécutant dans l’environnement intermédiaire/AQ.
Mettez l’environnement de production à l’échelle en fonction de la taille de votre cluster Azure Kubernetes Service. La taille du cluster dépend de la charge attendue pour le service web de scoring déployé. Pour les architectures de scoring en temps réel, le débit est une métrique d’optimisation capitale. Dans les scénarios non-Deep Learning, le processeur doit être suffisant pour gérer la charge. En revanche, pour les charges de travail Deep Learning, lorsque la vitesse constitue un goulot d’étranglement, les GPU offrent généralement de meilleures performances que les processeurs. Azure Kubernetes Service prend en charge les types de nœuds GPU et Processeur, raison pour laquelle cette solution l’utilise pour le déploiement d’image. Pour plus d’informations, consultez GPU ou processeur pour le déploiement des modèles Deep Learning.
Effectuez un scale-up ou un scale-down du pipeline de réentraînement en fonction du nombre de nœuds de votre ressource de Capacité de calcul Azure Machine Learning, et utilisez l’option de mise à l’échelle automatique pour gérer le cluster. Cette architecture utilise des processeurs. Pour les charges de travail Deep Learning, les GPU représentent un meilleur choix ; ils sont également pris en charge par la Capacité de calcul Azure Machine Learning.
Gestion
Supervision du travail de réentraînement. Les pipelines Machine Learning orchestrent le réentraînement sur un cluster de machines, ils offrent un moyen simple qui permet de les superviser. Utilisez l'interface utilisateur Azure Machine Learning et recherchez les journaux dans la section des pipelines. Ces journaux sont également écrits dans des objets blob, et ils peuvent y être lus par le biais d’outils, tels que l’Explorateur Stockage Azure.
Journalisation. Azure Machine Learning fournit un moyen simple de consigner des informations à chaque étape du cycle de vie Machine Learning. Les journaux sont stockés dans un conteneur d’objets blob. Pour plus d’informations, consultez Activer la journalisation dans Azure Machine Learning. Une supervision plus détaillée s’obtient en configurant Application Insights pour utiliser les journaux.
Sécurité. Tous les secrets et les informations d’identification sont stockés dans Azure Key Vault, et accessibles dans Azure Pipelines par l’intermédiaire des groupes de variables.
Optimisation des coûts
L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.
Azure DevOps est gratuit pour les projets open source et les petits projets comprenant jusqu’à cinq utilisateurs. Pour les équipes de plus grande taille, procurez-vous un plan en fonction du nombre d’utilisateurs.
La capacité de calcul est le vecteur de coût le plus important de cette architecture, et son coût varie en fonction du cas d’usage. Cette architecture utilise Capacité de calcul Azure Machine Learning, mais d’autres options sont disponibles. Azure Machine Learning n’ajoute pas de supplément en plus du coût des machines virtuelles qui sauvegardent votre cluster de calcul. Configurez votre cluster de calcul pour disposer d’un minimum de zéro nœud, de sorte que s’il n’est pas utilisé, votre cluster peut faire l’objet d’un scale-down jusqu’à zéro nœud sans entraîner de coûts. Le coût du calcul dépend du type de nœud, du nombre de nœuds et du mode de provisionnement (priorité basse ou dédié). Vous pouvez estimer le coût de Machine Learning et d’autres services à l’aide de la calculatrice de prix Azure.
Déployer ce scénario
Pour déployer cette architecture de référence, suivez les étapes du guide Bien démarrer dans le dépôt GitHub.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Praneet Singh Solanki | Ingénieur logiciel senior
Étapes suivantes
- Vous souhaitez en savoir plus ? Consultez le parcours d’apprentissage associé Démarrer le cycle de vie du Machine Learning avec MLOps.