Meilleures pratiques en matière de projets de science des données pour l’analyse à l’échelle du cloud dans Azure

Nous vous recommandons de suivre ces meilleures pratiques en matière d’utilisation de l’analyse à l’échelle du cloud dans Azure pour assurer l’opérationnalisation des projets de science des données.

Développez un modèle

Développez un modèle qui regroupe un ensemble de services pour vos projets de science des données. Utilisez un modèle qui regroupe un ensemble de services pour assurer la cohérence entre les différents cas d’usage des équipes de science des données. Nous vous recommandons de développer un blueprint cohérent sous la forme d’un référentiel de modèles. Vous pouvez utiliser ce référentiel pour différents projets de science des données au sein de votre entreprise pour réduire les temps de déploiement.

Instructions pour les modèles de science des données

Développez un modèle de science des données pour votre organisation avec les instructions suivantes :

• Développez un ensemble de modèles d’infrastructure en tant que code (IaC) pour déployer un espace de travail Azure Machine Learning. Incluez des ressources telles qu'un coffre de clés, un compte de stockage, un registre de conteneurs et Application Insights.

• Incluez la configuration des magasins de données et des cibles de calcul dans ces modèles, comme les instances de calcul, les clusters de calcul et Azure Databricks.

Bonnes pratiques de déploiement

Temps réel

• Incluez un déploiement Azure Data Factory ou Azure Synapse dans les modèles et Azure Cognitive Services.
• Les modèles doivent fournir tous les outils nécessaires pour exécuter la phase d’exploration de la science des données et la première opérationnalisation du modèle.

Considérations relatives à la configuration initiale

Dans certains cas, les scientifiques des données de votre organisation peuvent nécessiter un environnement pour une analyse au besoin rapide. Cette situation est courante lorsqu’un projet de science des données n’est pas configuré de manière formelle. Par exemple, un chef de projet, un code de coût ou un centre de coûts nécessaires pour la facturation interne dans Azure peuvent être manquants, car l’élément manquant n’est pas encore approuvé. Les utilisateurs de votre organisation ou de votre équipe peuvent avoir besoin d’accéder à un environnement de science des données pour comprendre les données et éventuellement évaluer la faisabilité d’un projet. En outre, certains projets peuvent ne pas nécessiter un environnement de science des données complet en raison du nombre restreint de produits de données.

Dans d’autres cas, un projet de science des données complet peut être requis, avec un environnement, une gestion de projet, un code de coût et un centre de coûts dédiés. Les projets complets de science des données sont utiles pour plusieurs membres de l’équipe qui souhaitent collaborer ou partager des résultats et qui doivent rendre opérationnels des modèles une fois la phase d’exploration réussie.

Le processus de configuration

Les modèles doivent être déployés pour chaque projet une fois qu’ils ont été configurés. Chaque projet doit recevoir au moins deux instances afin que les environnements de développement et de production soient séparés. Dans l’environnement de production, il ne doit pas y avoir d’accès pour une personne individuelle. Tout doit être déployé via des pipelines d’intégration ou de développement continus et un principal de service. Ces principes d’environnement de production sont importants, car Azure Machine Learning ne fournit pas de modèle de contrôle d’accès granulaire en fonction du rôle au sein d’un espace de travail. Votre ne pouvez pas limiter l’accès d’un utilisateur à un ensemble spécifique d’expériences, de points de terminaison ou de pipelines.

Les mêmes droits d’accès s’appliquent généralement à différents types d’artefacts. Il est important de séparer le développement de la production pour empêcher la suppression de pipelines ou de points de terminaison de production au sein d’un espace de travail. Parallèlement au modèle, il convient de créer un processus pour permettre aux équipes de produits de données de demander de nouveaux environnements.

Nous vous recommandons de configurer différents services d’IA, comme Azure Cognitive Services, par projet. En configurant différents services d’IA par projet, les déploiements se produisent pour chaque groupe de ressources de produit de données. Cette stratégie crée une séparation claire du point de vue de l’accès aux données et atténue le risque d’accès non autorisé aux données par les mauvaises équipes.

Scénario de streaming

Pour les cas d’usage en temps réel et de diffusion en continu, les déploiements doivent être testés sur un conteneur Azure Kubernetes Service (AKS) de taille réduite. Les tests peuvent se faire dans l’environnement de développement pour réduire les coûts avant le déploiement sur l’instance de production AKS ou Azure App Service pour conteneurs. Effectuez des tests d’entrée et de sortie simples pour vous assurer que les services répondent comme prévu.

Vous pouvez ensuite déployer des modèles sur le service de votre choix. Cette cible de calcul de déploiement est la seule mise à la disposition générale et recommandée pour les charges de travail de production dans un cluster AKS. Cette étape est particulièrement nécessaire si une prise en charge GPU (Graphics Processing Unit, unité de traitement graphique) ou FPGA (Field Programmable Gate Array, réseau de portes programmabes in situ) est requise. D’autres options de déploiement natif qui prennent en charge ces configurations matérielles ne sont actuellement pas disponibles dans Azure Machine Learning.

Azure Machine Learning nécessite un mappage un-à-un avec les clusters AKS. Chaque nouvelle connexion à un espace de travail Azure Machine Learning arrête la connexion précédente entre AKS et Azure Machine Learning. Une fois cette limite atténuée, nous vous recommandons de déployer des clusters AKS centraux en tant que ressources partagées et de les attacher à leurs espaces de travail respectifs.

Une autre instance de test AKS centrale doit être hébergée si des tests de contrainte doivent être effectués avant de déplacer un modèle vers l’AKS de production. L’environnement de test doit fournir la même ressource de calcul que l’environnement de production pour s’assurer que les résultats ressemblent le plus possible à ceux de l’environnement de production.

Scénario de traitement par lots

Tous les cas d’usage n’ont pas besoin de déploiements de cluster AKS. Un cas d’usage n’a pas besoin d’un déploiement de cluster AKS si de grandes quantités de données nécessitent uniquement un scoring régulièrement ou si elles sont basées sur un événement. Par exemple, de grandes quantités de données peuvent être basées sur le moment où les données tombent dans un compte de stockage spécifique. Des pipelines Azure Machine Learning et des clusters de calcul Azure Machine Learning doivent être utilisés pour le déploiement lors de ces types de scénarios. Ces pipelines doivent être orchestrés et exécutés dans Data Factory.

Identifier les ressources de calcul appropriées

Avant de déployer un modèle dans Azure Machine Learning sur une instance AKS, l’utilisateur doit spécifier les ressources telles que l’UC, la mémoire RAM et la GPU qui doivent être allouées pour le modèle respectif. La définition de ces paramètres peut être un processus complexe et fastidieux. Effectuez des tests de contrainte avec des configurations différentes pour identifier un bon ensemble de paramètres. Vous pouvez simplifier ce processus grâce à la fonctionnalité Profilage des modèles dans Azure Machine Learning, qui fournit un travail de longue durée qui teste différentes combinaisons d’allocation des ressources et qui utilise une latence identifiée et un temps d’aller-retour (RTT) pour recommander une combinaison optimale. Ces informations peuvent faciliter le déploiement d’un modèle réel sur AKS.

Pour mettre à jour en toute sécurité des modèles dans Azure Machine Learning, les équipes doivent utiliser la fonctionnalité de déploiement contrôlé (préversion) pour réduire le temps d’arrêt et maintenir la cohérence du point de terminaison REST du modèle.

Bonnes pratiques et workflow pour MLOps

Inclure un exemple de code dans les référentiels de science des données

Vous pouvez simplifier et accélérer les projets de science des données si vos équipes disposent de certains artefacts et meilleures pratiques. Nous vous recommandons de créer des artefacts que toutes les équipes de science des données peuvent utiliser lors de l’utilisation d’Azure Machine Learning et des outils respectifs de l’environnement de produit de données. Les ingénieurs de données et de Machine Learning doivent créer et fournir ces artefacts.

Ces artefacts doivent inclure les éléments suivants :

• Exemples de notebooks qui montrent comment :

  • charger, monter et utiliser des produits de données ;
  • consigner les métriques et les paramètres ;
  • soumettre des travaux de formation à des clusters de calcul.

• Artefacts requis pour l’opérationnalisation :

  • Exemple de pipelines Azure Machine Learning
  • Exemple de pipelines Azure
  • Autres scripts nécessaires pour exécuter les pipelines

• Documentation

Utiliser des artefacts bien conçus pour opérationnaliser les pipelines

Des artefacts peuvent accélérer les phases d’exploration et d’opérationnalisation des projets de science des données. Une stratégie de duplication (fork) DevOps peut vous aider à mettre à l’échelle ces artefacts dans tous les projets. Puisque cette configuration favorise l’utilisation de Git, les utilisateurs et le processus global d’automatisation peuvent tirer parti des artefacts fournis.

Conseil

Les exemples de pipelines Azure Machine Learning doivent être générés avec le kit de développement logiciel (SDK) Python ou basés sur le langage YAML. La nouvelle expérience YAML sera plus durable, car l’équipe produit Azure Machine Learning travaille actuellement sur un nouveau SDK et une nouvelle interface de ligne de commande (CLI). L’équipe produit d’Azure Machine Learning est certaine que YAML servira de langage de définition pour tous les artefacts dans Azure Machine Learning.

Les exemples de pipelines ne sont pas prêts à l’emploi pour chaque projet, mais ils peuvent être utilisés comme ligne de base. Vous pouvez ajuster les exemples de pipelines en fonction des projets. Un pipeline doit inclure les aspects les plus pertinents de chaque projet. Par exemple, un pipeline peut référencer une cible de calcul et des produits de données, définir des paramètres, des entrées, et des étapes d’exécution. Le même processus peut être effectué pour Azure Pipelines. Azure Pipelines doit également utiliser le SDK ou la CLI Azure Machine Learning.

Pipelines doit indiquer comment :

• se connecter à un espace de travail à partir d’un pipeline DevOps ;
• vérifier si le calcul requis est disponible ;
• soumettre un travail ;
• inscrire et déployer un modèle.

Les artefacts ne conviennent pas tout le temps à tous les projets et peuvent nécessiter une personnalisation, mais disposer d’une base peut accélérer le déploiement et l’opérationnalisation d’un projet.

Structurer le référentiel MLOps

Dans certains cas, les utilisateurs perdent le suivi de l’emplacement où trouver et stocker des artefacts. Pour éviter ces complications, vous devez demander plus de temps pour communiquer et construire une structure de dossiers de niveau supérieur pour le référentiel standard. Tous les projets doivent suivre la structure des dossiers.

Remarque

Les concepts mentionnés dans cette section peuvent être utilisés dans des environnements locaux, Amazon Web Services, Palantir et Azure.

La structure de dossiers de niveau supérieur proposée pour un référentiel d’opérations Machine Learning (MLOps) est illustrée dans ce diagramme :

Les objectifs de chaque dossier du référentiel sont les suivants :

Dossier	Objectif
.cloud	Stockez du code et des artefacts spécifiques au cloud dans ce dossier. Les artefacts incluent les fichiers de configuration pour l’espace de travail Azure Machine Learning, notamment les définitions de cibles de calcul, les travaux, les modèles inscrits et les points de terminaison.
.ado/.github	Stockez les artefacts Azure DevOps ou GitHub tels que les pipelines YAML ou les propriétaires de code dans ce dossier.
code	Incluez le code réel développé dans le cadre du projet dans ce dossier. Ce dossier peut contenir des packages Python et certains scripts utilisés pour les étapes respectives du pipeline d’apprentissage automatique. Nous vous recommandons de séparer les différentes étapes qui doivent être effectuées dans ce dossier. Les étapes courantes sont le prétraitement, l’apprentissage du modèle et l’inscription du modèle. Définissez les dépendances telles que les dépendances Conda, les images Docker ou autres pour chaque dossier.
docs	Utilisez ce dossier à des fins de documentation. Il stocke les fichiers Markdown et les images pour décrire le projet.
pipelines	Stockez des définitions de pipelines Azure Machine Learning dans YAML ou Python dans ce dossier.
tests	Ecrivez des tests unitaires et d’intégration qui doivent être exécutés pour détecter les bogues et les problèmes au début du projet dans ce dossier.
notebooks	Séparez les notebooks Jupyter du projet Python réel dans ce dossier. Chaque individu doit disposer d’un sous-dossier dans ce dossier afin d’y archiver ses notebooks et d’éviter les conflits de fusion Git.

Étape suivante

Produits de données d'analyse à l'échelle du cloud dans Azure