Organiser et configurer des environnements Azure Machine Learning

Lors de la planification d’un déploiement Azure Machine Learning pour un environnement d’entreprise, il existe des points de décision communs qui affectent la façon dont vous créez l’espace de travail :

• Structure de l’équipe : manière dont vos équipes de science des données sont organisées et collaborent sur des projets en fonction de la répartition des cas d’utilisation et des données, ou des exigences de gestion des coûts.
• Environnements : environnements utilisés dans le cadre de votre flux de travail de développement et de mise en production pour séparer le développement de la production.
• Région : emplacement de vos données et du public auquel vous destinez votre solution d’apprentissage automatique.

Structure d’équipe et configuration de l’espace de travail

L’espace de travail est la ressource de niveau supérieur du service Azure Machine Learning. Il stocke les artefacts générés lors de l’utilisation de Machine Learning et du calcul géré, et des pointeurs sur des ressources attachées et associées. Du point de vue de la facilité de gestion, l’espace de travail en tant que ressource Azure Resource Manager permet le contrôle d’accès en fonction du rôle (RBAC) Azure et la gestion par stratégie, et peut être utilisé comme une unité pour les rapports de coût.

Les organisations choisissent généralement un ou plusieurs des modèles de solution suivants pour respecter les exigences de facilité de gestion.

Espace de travail par équipe : utilisez un espace de travail pour chaque équipe lorsque tous les membres d’une équipe ont besoin du même niveau d’accès aux données et aux ressources d’expérimentation. Par exemple, une organisation avec trois équipes de Machine Learning peut créer trois espaces de travail, un pour chaque équipe.

L’avantage d’avoir un espace de travail par équipe est que tous les artefacts d’apprentissage automatique utilisés pour les projets de l’équipe sont stockés dans un même emplacement. La productivité augmente parce que les membres de l’équipe peuvent facilement accéder aux résultats de l’expérimentation, les explorer et les réutiliser. L’organisation de vos espaces de travail par équipe réduit votre encombrement Azure et simplifie la gestion des coûts par équipe. Étant donné que le nombre de ressources d’expérimentation peut croître rapidement, vous pouvez organiser vos artefacts en suivant les conventions d’attribution de noms et de balisage. Pour des recommandations sur la façon de nommer des ressources, consultez Développer une stratégie de nommage et de catégorisation des ressources Azure.

Dans cette approche, chaque membre de l’équipe doit avoir des autorisations de niveau d’accès aux données similaires. Le contrôle d’accès en fonction du rôle (RBAC) précis et les listes de contrôle d’accès (ACL) pour les sources de données et les ressources d’expérimentation sont limités au sein d’un espace de travail. Vous ne pouvez pas avoir des exigences de séparation des données en fonction du cas d’usage.

Espace de travail par projet : utilisez un espace de travail pour chaque projet si vous avez besoin de séparer les données et les ressources d’expérimentation par projet, ou avez des exigences en matière de rapports de coûts et de budgétisation au niveau du projet. Par exemple, une organisation peut avoir quatre équipes d’apprentissage automatique exécutant chacune trois projets pour un total de 12 instances d’espace de travail.

L’avantage de l’utilisation d’un espace de travail par projet est que vous gérez les coûts au niveau du projet. En général, une équipe crée un groupe de ressources dédié pour Azure Machine Learning et les ressources associées pour des raisons similaires. Lorsque vous travaillez, par exemple, avec des contributeurs externes, un espace de travail centré sur un projet simplifie la collaboration, car les utilisateurs externes ont uniquement besoin de l’accès aux ressources du projet, et non aux ressources de l’équipe.

Un aspect à considérer dans cette approche est l’isolation des résultats d’expérimentation et des ressources. La découverte et la réutilisation des ressources peuvent être plus difficiles en raison de la répartition des ressources entre plusieurs instances d’espace de travail.

Espace de travail unique : utilisez un espace de travail pour les travaux non liés à une équipe ou à un projet particulier, ou si les coûts ne peuvent pas être directement imputés à une unité de facturation spécifique, par exemple la recherche et développement.

L’avantage de cette configuration est que le coût d’un travail individuel non lié à un projet peut être découplé des coûts liés aux projets. Lorsque vous configurez un espace de travail unique pour permettre à tous les utilisateurs d’effectuer leur travail individuel, vous réduisez votre empreinte Azure.

Avec cette approche, l’espace de travail peut rapidement devenir encombré lorsque de nombreux praticiens de l’apprentissage automatique partagent la même instance. Les utilisateurs peuvent avoir besoin d’un filtrage des ressources basé sur une interface utilisateur pour trouver efficacement leurs ressources. Vous pouvez créer des espaces de travail d’apprentissage automatique partagés pour chaque division afin d’atténuer les problèmes de mise à l’échelle ou pour segmenter les budgets.

Configuration des environnements et de l’espace de travail

Un environnement est une collection de ressources que les déploiements ciblent en fonction de leur étape dans le cycle de vie de l’application. Les exemples courants de noms d’environnement sont dev, test, AQ, intermédiaire et production.

Le processus de développement de votre organisation affecte les exigences relatives à l’utilisation de l’environnement. Votre environnement affecte la configuration d’Azure Machine Learning et des ressources associées, comme le calcul attaché. Par exemple, la disponibilité des données peut imposer des contraintes à la gestion de la disponibilité d’une instance d’apprentissage automatique pour chaque environnement. Les modèles de solution suivants sont courants :

Déploiement d’un espace de travail d’environnement unique : lorsque vous choisissez de déployer un espace de travail d’environnement unique, Azure Machine Learning opère le déploiement dans un seul environnement. Cette configuration est courante pour les scénarios axés sur la recherche, où il n’est pas nécessaire de libérer les artefacts d’apprentissage automatique en fonction de leur phase de cycle de vie à travers les environnements. Ce scénario est un autre scénario dans lequel cette configuration est utile lorsque seuls des services d’inférence (et non des pipelines d’apprentissage automatique) sont déployés dans les environnements.

L’avantage d’une configuration centrée sur la recherche est un encombrement Azure réduit et une charge de gestion minimale. De cette façon, il n’est pas nécessaire de déployer un espace de travail Azure Machine Learning dans chaque environnement.

Avec cette approche, le déploiement d’un environnement unique est tributaire de la disponibilité des données. Soyez prudent donc lorsque vous configurez votre magasin de données. Si vous configurez un accès étendu, par exemple un accès en écriture sur des sources de données de production, vous risquez de nuire à la qualité des données. Si vous mettez le travail en production dans le même environnement que celui où le développement est effectué, les mêmes restrictions de RBAC s’appliquent à la fois au travail de développement et au travail de production. Cette configuration peut rendre les deux environnements trop rigides ou trop flexibles.

Déploiement de l’espace de travail sur plusieurs environnements : lorsque vous choisissez un déploiement d’espace de travail sur plusieurs environnements, une instance d’espace de travail est déployée pour chaque environnement. Un scénario courant pour cette configuration est un espace de travail réglementé avec une séparation claire des tâches entre les environnements et pour les utilisateurs qui ont accès aux ressources de ces environnements.

Cette configuration présente les avantages suivants :

• Déploiement intermédiaire de flux de travail et d’artefacts d’apprentissage automatique. Par exemple, des modèles dans les environnements, avec la possibilité d’améliorer l’agilité et de réduire le temps de déploiement.
• Renforcement de la sécurité et du contrôle des ressources, car vous avez la possibilité d’affecter des restrictions d’accès supplémentaires dans les environnements en aval.
• Scénarios d’apprentissage sur les données de production dans les environnements hors développement, car vous pouvez accorder l’accès à un groupe spécifique d’utilisateurs.

Cette approche vous expose à une surcharge de gestion et de traitement. Cette configuration nécessite un processus de développement et de déploiement précis des artefacts d’apprentissage automatique dans les instances d’espace de travail. Par ailleurs, des efforts de gestion et d’ingénierie des données peuvent être nécessaires pour rendre les données de production disponibles pour l’apprentissage dans l’environnement de développement. La gestion des accès requiert que vous permettiez à une équipe d’accéder à la résolution et à l’examen des incidents en production. Et enfin, votre équipe doit disposer d’une expertise en matière d’ingénierie d’apprentissage automatique et d’Azure DevOps pour implémenter des workflows d’automatisation.

Un environnement avec un accès limité aux données, et un avec un accès aux données de production : lorsque vous choisissez cette configuration, Azure Machine Learning se déploie sur deux environnements : l’un avec un accès limité aux données, et l’autre avec un accès aux données de production. Cette configuration est courante si vous avez besoin de séparer les environnements de développement et de production. Par exemple, vous travaillez peut-être sous des contraintes organisationnelles pour rendre les données de production disponibles dans n’importe quel environnement, ou vous souhaitez peut-être séparer le travail de développement du travail de production sans dupliquer les données plus que nécessaire en raison du coût élevé de la maintenance.

L’avantage de cette configuration est la séparation claire des tâches et de l’accès entre les environnements de développement et de production. Un autre avantage est la réduction de la charge de gestion des ressources par rapport à un scénario de déploiement à plusieurs environnements.

Avec cette approche, vous avez besoin d’un processus de développement et de déploiement bien défini pour les artefacts d’apprentissage automatique dans les espaces de travail. En outre, elle pourrait nécessiter des efforts de gestion et d’ingénierie des données afin de rendre les données de production disponibles pour l’apprentissage dans un environnement de développement. En revanche, elle pourrait nécessiter un effort relativement moindre que le déploiement d’un espace de travail sur plusieurs environnements.

Configuration des régions et des ressources

L’emplacement de vos ressources, données ou utilisateurs peut vous obliger à créer des instances d’espace de travail Azure Machine Learning et des ressources associées dans plusieurs régions Azure. Par exemple, un projet peut répartir ses ressources dans les régions Azure Europe Ouest et USA Est pour des raisons de performances, de coût et de conformité. Les scénarios suivants sont courants :

Apprentissage régional : Les tâches d’apprentissage de Machine Learning s’exécutent dans la même région Azure que celle où se trouvent les données. Dans cette configuration, un espace de travail d’apprentissage automatique se déploie dans chaque région Azure où se trouvent des données. Ce scénario est courant lorsque vous devez respecter des exigences conformité, ou composer avec des contraintes de déplacement de données entre régions.

L’avantage de cette configuration est que vous pouvez faire des expériences dans le centre de données où se trouvent les données avec le moins de latence réseau. Avec cette approche, quand un pipeline d’apprentissage automatique s’exécute sur plusieurs instances d’espace de travail, il augmente la complexité de la gestion. Il devient difficile de comparer les résultats des expérimentations entre les instances, et cela ajoute une charge à la gestion des quotas et des calculs.

Si vous souhaitez attacher du stockage à travers les régions, mais utiliser le calcul d’une seule région, Azure Machine Learning prend en charge le scénario d’attachement de comptes de stockage dans une région plutôt que dans l’espace de travail. Les métadonnées, par exemple les métriques, sont stockées dans la région de l’espace de travail.

Service régional : les services d’apprentissage automatique sont déployés près de l’emplacement où réside le public cible. Par exemple, si les utilisateurs cibles sont en Australie et que la région de stockage et d’expérimentation principale est Europe Ouest, déployez l’espace de travail d’apprentissage automatique pour l’expérimentation dans la région Europe Ouest. Vous déployez ensuite un cluster AKS pour le déploiement du point de terminaison d’inférence en Australie.

Les avantages de cette configuration sont l’opportunité d’avoir l’inférence dans le centre de données où les nouvelles données sont ingérées, la réduction de la latence et du déplacement des données, ainsi que la conformité aux réglementations locales.

Avec cette approche, une configuration à plusieurs régions offre plusieurs avantages, mais ajoute également une surcharge de gestion de quota et de calcul. Quand une inférence par lot est requise, un service régional peut nécessiter un déploiement sur plusieurs espaces de travail. Les données collectées via des points de terminaison d’inférence peuvent nécessiter d’être transférées entre régions pour des scénarios de réapprentissage.

Réglage régional : un modèle de base est formé sur un jeu de données initial, par exemple des données publiques ou des données de toutes les régions, et est ensuite affiné avec un jeu de données régional. Le jeu de données régional peut exister uniquement dans une région particulière en raison de contraintes de déplacement de données ou de conformité. Par exemple, vous pourriez avoir besoin que l’apprentissage du modèle de base soit effectué dans un espace de travail situé dans une région A, et que le réglage fin soit effectué dans un espace de travail situé dans une région B.

L’avantage de cette configuration est que vous pouvez expérimenter de manière conforme dans le centre de données où résident les données. Vous pouvez également tirer parti de l’apprentissage du modèle de base sur un jeu de données plus volumineux dans une phase de pipeline antérieure.

Cette approche prend en charge des pipelines d’expérimentation complexes, mais peut créer des difficultés supplémentaires. Par exemple, lorsque vous comparez des résultats d’expérience entre régions, cela peut entraîner une surcharge de gestion de quota et de calcul.

Implémentation de référence

Pour illustrer le déploiement d’Azure Machine Learning à plus grande échelle, cette section montre comment l’organisation « Contoso » configure Azure Machine Learning en fonction de ses contraintes organisationnelles, et de ses exigences en matière de création de rapports et de budgétisation :

• Contoso crée des groupes de ressources pour chaque solution pour faciliter la gestion des coûts et la création de rapports.
• Les administrateurs informatiques créent uniquement des groupes de ressources et des ressources pour les solutions financées afin de répondre aux exigences budgétaires.
• En raison de la nature exploratoire et incertaine de la science des données, les utilisateurs ont besoin d’un emplacement d’expérimentation et de travail pour l’exploration des données et des cas d’usage. Souvent, les travaux d’exploration ne peuvent pas être directement associés à un cas d’usage particulier et peuvent être associés uniquement à un budget de recherche et développement. Contoso souhaite financer certaines ressources d’apprentissage automatique que tout le monde peut utiliser à des fins d’exploration de manière centralisée.
• Quand un cas d’usage d’apprentissage automatique se révèle concluant dans l’environnement exploratoire, les équipes peuvent demander des groupes de ressources. Par exemple, l’entreprise peut configurer le développement, le contrôle qualité et la production pour le travail du projet d’expérimentation itérative, et l’accès aux sources de données de production.
• Les exigences de séparation et de conformité des données ne permettent pas la présence de données de production dans les environnements de développement.
• Différentes exigences RBAC existent pour différents groupes d’utilisateurs par stratégie informatique et par environnement. Par exemple l’accès est plus restrictif en production.
• Les données, l’expérimentation et l’inférence sont gérées dans une seule région Azure.

Pour respecter les exigences ci-dessus, Contoso configure ses ressources de la manière suivante :

• Espaces de travail et groupes de ressources Azure Machine Learning délimités par projet pour respecter les exigences de budgétisation et de séparation des cas d’usage.
• Une configuration à plusieurs environnements pour Azure Machine Learning et les ressources associées pour respecter les exigences en matière de gestion des coûts, RBAC et d’accès aux données.
• Un groupe de ressources unique et un espace de travail d’apprentissage automatique dédié à l’exploration.
• Groupes Microsoft Entra différents selon le rôle d’utilisateur et l’environnement. Par exemple les opérations qu’un scientifique des données peut effectuer dans un environnement de production sont différentes de celles de l’environnement de développement, et les niveaux d’accès peuvent varier selon la solution.
• Toutes les ressources sont créées dans une seule région Azure.

Étapes suivantes

Découvrez les meilleures pratiques de DevOps d’apprentissage automatique avec Azure Machine Learning.

Guide DevOps pour le machine learning

Découvrez des considérations relatives à la gestion des budgets, des quotas et des coûts avec Azure Machine Learning.

Gérer les budgets, les coûts et le quota pour Azure Machine Learning à l’échelle de l’organisation