Configuration des cibles d’exécution d’Azure ML

 

Ce billet s'inscrit dans la série de billets sur les nouveaux services d'Azure Machine Learning (Azure ML) à savoir le service d'expérimentation et le service de gestion des modèles, série que nous avons initiée en septembre et octobre dernier avec les annonces associées.

Cette série de billets vise à vous faire découvrir progressivement ce nouvel environnement Azure ML, à en partager avec vous les nouveautés et bénéfices, et de pouvoir aborder plus en profondeur certains aspects des fonctionnalités ainsi offertes.

Ce billet s'intéresse plus particulièrement comme son titre l'indique à la configuration des cibles d'exécution d'Azure ML au travers de fichiers de configuration. Ainsi, il vous est donné la possibilité d'entrainer vos modèles ou d'exécuter vos scripts sur différents environnements, que ce soit dans le cloud, en bordure ou en local. Voyons ce qu'il en est.

J'en profite pour remercier Paul Jenny actuellement en stage de fin d'étude au sein de Microsoft France pour cette contribution.

Le fonctionnement des fichiers de configuration

Pour gérer vos environnements et exécuter les commandes nécessaires à la préparation de l'environnement, Azure ML utilise deux fichiers de configuration en YAML (Yet Another Markup Language) situés dans le dossier aml_config de votre projet avec le nom de votre environnement :

Dans la pratique, les fichiers de configuration contiennent les paramètres suivants :

  • <VOTRE_ENV> .compute : Type d'environnement (local, localdocker, remotedocker, cluster) ; identifiants de connexion à l'environnement si distant);
  • <VOTRE_ENV> .runconfig : Paramètres d'Azure ML (suivi des expérimentations, Framework, nom de l'environnement, chemin vers la liste des dépendances, etc.).

La création d'une cible d'exécution

Pour créer une cible d'exécution avec les fichiers associés, vous pouvez créer manuellement les fichiers ou utiliser l'utilitaire en ligne de commandes ; ce qui est recommandée car le format des fichiers de configuration est susceptible d'évoluer avec de futures mises à jour).

L'utilisation de la ligne de commandes

D'une façon générale, il est préférable de toujours passer par Azure ML Workbench pour accéder à la ligne de commandes comme certaines variables d'environnements sont nécessaires pour l'utilisation d'Azure ML CLI.

Pour ce faire, vous devez vous placer dans votre projet dans Azure ML Workbench puis aller dans File > Open Command Prompt :

La sous-catégorie de commandes dédiée aux contextes d'exécution est intitulée computetarget. Vous pouvez voir la liste des commandes disponibles en ajoutant l'argument -h comme suit :

Actuellement, les types de contexte supportés sont à date :

Ainsi, si vous souhaitez obtenir la liste des contextes d'exécution, vous pouvez utiliser la commande list suivante :

Remarque : Vous pouvez utiliser l'argument –output (ou -o) pour définir le format de sortie que vous souhaitez (table pour afficher sous forme de tableau, par défaut en JSON)

Pour créer votre environnement d'exécution, vous devez utiliser la commande attach :

Les arguments obligatoires sont les suivants :

  • Le type de votre contexte (qui suit la commande), à savoir :
    • local: environnement Conda d'Azure ML.
    • localdocker: environnement Docker en local.
    • remotedocker: environnement Docker distant (sur une VM ou tout environnement Linux avec Docker installé). Windows n'est pas supporté en tant qu'hôte.
    • cluster: environnement Azure HDInsight pour Spark.
  • --name : le nom de votre contexte. Il sera ensuite utilisé pour nommer votre contexte d'exécution dans Azure ML Workbench ou dans les commandes d'expérimentation
  • --username : dans le cas d'une connexion distante (Azure HDInsight ou Docker distant), le nom d'utilisateur pour se connecter en SSH à la machine. Sur Azure HDInsight, ce nom d'utilisateur est l'utilisateur du nœud maître !
  • --password : dans le cas d'une connexion distante (HDInsight ou Docker distant), le mot de passe du compte utilisateur pour se connecter en SSH à la machine. Sur Azure HDInsight, ce mot de passe est le mot de passe de connexion au nœud maître !
  • --use-azureml-ssh-key : si vous n'avez pas spécifié de mot de passe, vous pouvez utiliser cet argument pour générer une paire de clés SSL puis ajouter la clé publique dans les clés autorisées sur le contexte d'exécution (situées dans ~/.ssh/authorized_keys).
  • --address : dans le cas d'une connexion distante (HDInsight ou Docker distant), l'adresse IP ou nom de domaine complètement qualifié de la machine distante.

Vous pouvez trouver un exemple de création de contexte ci-dessous :

Vous pouvez retrouver les fichiers crées dans le dossier aml_config de votre projet.

Le paramétrage d'une cible d'exécution

Une fois vos fichiers ainsi créés sur la base des éléments précédents, vous pourrez éditer manuellement les fichiers, les changements seront appliqués dès la sauvegarde de ceux-ci.

La configuration de l'exécution de vos expérimentations

Comme évoqué ci-avant, le fichier <VOTRE_ENV> .runconfig est responsable de la configuration de vos expérimentations.

Vous pouvez disposer de plusieurs fichiers .runconfig pour une même cible d'exécution. Pour créer un fichier de configuration une fois une cible créée, vous pouvez utiliser la ligne de commandes avec la commande az ml runconfiguration comme suit :

Par exemple, vous pouvez créer un fichier .runconfig avec la commande create :

 

Dans la pratique, le fichier .runconfig est un fichier au format YAML. Vous pouvez paramétrer des variables d'environnement pour votre exécution grâce à la variable EnvironmentVariablessous forme de liste :

Pour gérer les dépendances Conda et Spark, Azure ML s'appuie sur deux fichiers en YAML spécifiés respectivement par les variables CondaDependenciesFile et SparkDependenciesFile comme suit :

Lorsque vous créez une cible d'exécution, celle-ci n'a pas été préparée comme indiquée par un message d'avertissement lors de sa création.

Vous pouvez choisir de préparer votre environnement cible selon votre fichier de configuration (dépendances, variables d'environnement, etc.) manuellement ou automatiquement à chaque lancement d'une expérimentation.

Si vous souhaitez le préparer manuellement, vous n'aurez à effectuer cette opération qu'une fois pour un environnement donné avec la commande az ml experiment prepare –runconfiguration <run configuration name>:

Si au contraire vous souhaitez qu'Azure ML s'occupe de préparer votre environnement à chaque lancement d'une expérimentation, vous pouvez positionner la variable PrepareEnvironment à true :

Remarque : Cette opération peut prendre quelques minutes étant donné que l'ensemble de vos dépendances et votre image Docker sont téléchargées et installées.

Remarque : Si vous utilisez l'environnement local avec le Python embarqué d'Azure ML Workbench, vous devez télécharger et installer manuellement vos dépendances.

Par défaut, Azure ML enregistre l'historique de vos expérimentations grâce à Git avec des statistiques (durée d'exécution, métriques, etc.). Cela vous permet de pouvoir comparer et/ou revenir sur une expérimentation antérieure. Néanmoins, vous pouvez désactiver ce comportement au travers de la variable TrackedRun:

La configuration de l'environnement de calcul

En complément du fichier <VOTRE_ENV >.runconfig, un autre fichier est utilisé pour paramétrer votre environnement. Celui-ci a pour extension .compute comme précédemment présenté.

Celui-ci spécifie le type de la cible (local, remotedocker, cluster, localdocker) mais aussi différents paramètres inhérents du type de cible.

Par exemple, si vous utilisez une cible située dans un conteneur Docker, vous devez spécifier l'image que vous devez utiliser avec l'attribut baseDockerImage.

Les images supportées sont celles basées sur microsoft/mmlspark : plus. Vous pouvez voir la liste des images disponibles ici au niveau du repo public Docker : https://hub.docker.com/r/microsoft/mmlspark/tags/

Ensuite, pour poursuivre avec Docker, vous pouvez indiquer si vous souhaitez monter automatiquement le répertoire partagé d'Azure ML entre votre hôte et le conteneur via la variable sharedVolumes.

Enfin, si vous souhaitez entraîner vos modèles avec l'aide de GPUs, vous devez indiquer une image Docker supportant les GPUs ainsi qu'activer le support du pilote NVIDIA avec les paramètres suivants :

  • baseDockerImage: microsoft/mmlspark:plus-gpu-0.9.9
  • nvidiaDocker: true

La gestion des dépendances de vos projets

Les dépendances Conda

Le fichier conda_dependencies.yml spécifie les dépendances liées à Conda dont votre projet a besoin pour fonctionner.

La liste des paquets nécessaires est sous forme de liste YAML dans la section dependencies.

Si vous avez besoin d'une version précise d'un paquet, vous pouvez saisir le numéro de version après le nom de paquet précédé de deux signes « = » comme par exemple :

azure-ml-api-sdk==0.1.0a10

Vous pouvez également indiquer une URL vers le paquet sous format WHL comme suit :

https://azuremldownloads.blob.core.windows.net/wheels/latest/azureml.assets-1.0.0-py3-none-any.whl?sv=2016-05-31&si=ro-2017&sr=c&sig=xnUdTm0B%2F%2FfknhTaRInBXyu2QTTt8wA3OsXwGVgU%2BJk%3D

Si vous souhaitez utiliser un ou plusieurs GPUs pour vos calculs, vous devez utiliser les paquets avec support GPU. Par exemple, pour les Frameworks d'apprentissage profond (Deep Learning) comme CNTK ou Tensorflow, vous devez choisir la version avec support GPU (le wheel GPU de CNTK et tensorflow-gpu).

Attention, si vous exécutez sur une cible locale, ce fichier n'est pas utilisé pour configurer votre environnement Conda. Vous devez exécuter par vous-même via une ligne de commande la mise à jour de vos paquets :

conda env update --file conda_dependencies.yml

Les dépendances Spark

Le fichier spark_dependencies spécifie les paquets et configuration liés à Spark dont votre projet a besoin pour fonctionner.

Pour spécifier un paquet dont vous avez besoin, vous devez saisir sous forme de liste YAML votre paquet dans la section packages :

- group: "com.microsoft.ml.spark"

artifact: "mmlspark_2.11"

version: "0.7.91"

La préparation de votre cible d'exécution

Une fois vos fichiers de configuration finalisés, vous devez indiquer à Azure ML de préparer votre environnement distant ou local (avec Docker) en utilisant la commande :

az ml experiment prepare -c myenv

Selon la configuration, cette action peut nécessiter plusieurs minutes pour s'exécuter. Néanmoins celle-ci n'est à effectuer qu'à la première exécution dans votre nouvel environnement ou à chaque modification de configuration. En effet, une nouvelle image Docker est créée à chaque utilisation de cette commande.

Vous êtes désormais « armé » pour configurer dès à présent différentes cibles d'exécution qu'elles soient distantes ou locales, avec ou sans support GPU, avec des versions particulières de paquets. Ainsi, votre environnement se trouve adapté à vos (besoins en) calculs.

Si vous souhaitez plus d'informations, vous pouvez consulter l'article Configuration du service d'expérimentation Azure Machine Learning.

Ceci conclut notre billet sur la configuration des cibles d'exécution.