Créez des architectures de formation distribuées flexibles et évolutives à l'aide de Kubeflow sur AWS et Amazon SageMaker

Dans cet article, nous montrons comment Kubeflow sur AWS (une distribution de Kubeflow spécifique à AWS) utilisée avec Conteneurs AWS Deep Learning ainsi que Système de fichiers Amazon Elastic (Amazon EFS) simplifie la collaboration et offre une flexibilité dans la formation de modèles d'apprentissage en profondeur à grande échelle sur les deux Service Amazon Elastic Kubernetes (Amazon EKS) et Amazon Sage Maker en utilisant une approche d'architecture hybride.

Le développement de l'apprentissage automatique (ML) repose sur des cadres et des boîtes à outils open source complexes et en constante évolution, ainsi que sur des écosystèmes matériels complexes et en constante évolution. Cela pose un défi lors de la mise à l'échelle du développement ML vers un cluster. Les conteneurs offrent une solution, car ils peuvent entièrement encapsuler non seulement le code de formation, mais l'ensemble de la pile de dépendances jusqu'aux bibliothèques matérielles. Cela garantit un environnement ML cohérent et portable, et facilite la reproductibilité de l'environnement de formation sur chaque nœud individuel du cluster de formation.

Kubernetes est un système largement adopté pour automatiser le déploiement de l'infrastructure, la mise à l'échelle des ressources et la gestion de ces applications conteneurisées. Cependant, Kubernetes n'a pas été conçu avec ML à l'esprit, il peut donc sembler contre-intuitif pour les scientifiques des données en raison de sa forte dépendance aux fichiers de spécification YAML. Il n'y a pas d'expérience Jupyter, et il n'y a pas beaucoup de fonctionnalités spécifiques au ML, telles que la gestion des flux de travail et les pipelines, et d'autres fonctionnalités attendues par les experts en ML, telles que le réglage des hyperparamètres, l'hébergement de modèles, etc. De telles capacités peuvent être construites, mais Kubernetes n'a pas été conçu pour cela comme objectif principal.

La communauté open source en a pris note et a développé une couche au-dessus de Kubernetes appelée Kubeflow. Kubeflow vise à rendre le déploiement de workflows ML de bout en bout sur Kubernetes simple, portable et évolutif. Vous pouvez utiliser Kubeflow pour déployer les meilleurs systèmes open source pour le ML sur diverses infrastructures.

Kubeflow et Kubernetes offrent flexibilité et contrôle aux équipes de data scientists. Cependant, assurer une utilisation élevée des clusters de formation fonctionnant à grande échelle avec des frais généraux opérationnels réduits reste un défi.

Cet article montre comment les clients qui ont des restrictions sur site ou des investissements Kubernetes existants peuvent relever ce défi en utilisant Amazon EKS et Kubeflow sur AWS pour mettre en œuvre un pipeline ML pour la formation distribuée basée sur une approche autogérée, et utiliser SageMaker entièrement géré pour un infrastructure de formation optimisée en termes de coûts, entièrement gérée et à l'échelle de la production. Cela inclut la mise en œuvre étape par étape d'une architecture de formation distribuée hybride qui vous permet de choisir entre les deux approches au moment de l'exécution, conférant un contrôle et une flexibilité maximum avec des besoins stricts pour vos déploiements. Vous verrez comment vous pouvez continuer à utiliser des bibliothèques open source dans votre script de formation d'apprentissage en profondeur tout en le rendant compatible pour qu'il s'exécute à la fois sur Kubernetes et SageMaker de manière indépendante de la plate-forme.

Comment Kubeflow sur AWS et SageMaker vous aide-t-il ?

Les modèles de réseaux neuronaux construits avec des cadres d'apprentissage en profondeur tels que TensorFlow, PyTorch, MXNet et d'autres offrent une précision beaucoup plus élevée en utilisant des ensembles de données de formation beaucoup plus volumineux, en particulier dans les cas d'utilisation de la vision par ordinateur et du traitement du langage naturel. Cependant, avec de grands ensembles de données de formation, il faut plus de temps pour former les modèles d'apprentissage en profondeur, ce qui ralentit finalement le délai de mise sur le marché. Si nous pouvions faire évoluer un cluster et réduire le temps de formation du modèle de quelques semaines à quelques jours ou heures, cela pourrait avoir un impact énorme sur la productivité et la vitesse de l'activité.

Amazon EKS aide à provisionner le plan de contrôle Kubernetes géré. Vous pouvez utiliser Amazon EKS pour créer des clusters de formation à grande échelle avec des instances CPU et GPU et utiliser la boîte à outils Kubeflow pour fournir des outils open source compatibles ML et opérationnaliser des flux de travail ML portables et évolutifs à l'aide de Kubeflow Pipelines pour améliorer la productivité de votre équipe et réduire le temps de mise sur le marché.

Cependant, il pourrait y avoir quelques défis avec cette approche :

• Garantir une utilisation maximale d'un cluster dans les équipes de science des données. Par exemple, vous devez provisionner des instances GPU à la demande et garantir leur utilisation élevée pour les tâches exigeantes à l'échelle de la production telles que la formation à l'apprentissage en profondeur, et utiliser des instances CPU pour les tâches moins exigeantes telles que le prétraitement des données.
• Assurer la haute disponibilité des composants lourds de l'infrastructure Kubeflow, y compris la base de données, le stockage et l'authentification, qui sont déployés dans le nœud de travail du cluster Kubernetes. Par exemple, le plan de contrôle Kubeflow génère des artefacts (tels que des instances MySQL, des journaux de pod ou un stockage MinIO) qui augmentent au fil du temps et nécessitent des volumes de stockage redimensionnables avec des capacités de surveillance continue.
• Partager l'ensemble de données de formation, le code et les environnements de calcul entre les développeurs, les clusters de formation et les projets est un défi. Par exemple, si vous travaillez sur votre propre ensemble de bibliothèques et que ces bibliothèques ont de fortes interdépendances, il devient très difficile de partager et d'exécuter le même morceau de code entre les data scientists de la même équipe. En outre, chaque exécution d'entraînement vous oblige à télécharger l'ensemble de données d'entraînement et à créer l'image d'entraînement avec les nouvelles modifications de code.

Kubeflow sur AWS aide à relever ces défis et fournit un produit Kubeflow semi-géré de niveau entreprise. Avec Kubeflow sur AWS, vous pouvez remplacer certains services de plan de contrôle Kubeflow tels que la base de données, le stockage, la surveillance et la gestion des utilisateurs par des services gérés AWS tels que Service de base de données relationnelle Amazon (Amazon RDS), Service de stockage simple Amazon (Amazon S3), Système de fichiers Amazon Elastic (AmazonEFS), Amazon FSx, Amazon Cloud Watchet Amazon Cognito.

Le remplacement de ces composants Kubeflow dissocie les parties critiques du plan de contrôle Kubeflow de Kubernetes, offrant une conception sécurisée, évolutive, résiliente et optimisée en termes de coûts. Cette approche libère également des ressources de stockage et de calcul du plan de données EKS, qui peuvent être nécessaires à des applications telles que la formation de modèles distribués ou les serveurs de bloc-notes utilisateur. Kubeflow sur AWS fournit également une intégration native des blocs-notes Jupyter avec des images Deep Learning Container (DLC), qui sont pré-emballées et préconfigurées avec des cadres d'apprentissage en profondeur optimisés AWS tels que PyTorch et TensorFlow qui vous permettent de commencer à écrire votre code de formation immédiatement sans avoir à traiter avec des résolutions de dépendances et des optimisations de framework. De plus, l'intégration d'Amazon EFS avec les clusters de formation et l'environnement de développement vous permet de partager votre code et l'ensemble de données de formation traité, ce qui évite de créer l'image du conteneur et de charger d'énormes ensembles de données après chaque modification de code. Ces intégrations avec Kubeflow sur AWS vous aident à accélérer la création de modèles et le temps de formation et permettent une meilleure collaboration avec un partage de données et de code plus facile.

Kubeflow sur AWS aide à créer une plateforme ML hautement disponible et robuste. Cette plate-forme offre la flexibilité nécessaire pour créer et former des modèles d'apprentissage en profondeur et donne accès à de nombreux kits d'outils open source, à des informations sur les journaux et à un débogage interactif pour l'expérimentation. Cependant, l'utilisation maximale des ressources d'infrastructure tout en formant des modèles d'apprentissage en profondeur sur des centaines de GPU implique toujours de nombreux frais généraux opérationnels. Cela pourrait être résolu en utilisant SageMaker, qui est un service entièrement géré conçu et optimisé pour gérer des clusters de formation performants et à coût optimisé qui ne sont provisionnés que sur demande, mis à l'échelle selon les besoins et arrêtés automatiquement lorsque les travaux sont terminés, fournissant ainsi près de 100 % utilisation des ressources. Vous pouvez intégrer SageMaker à Kubeflow Pipelines à l'aide de composants SageMaker gérés. Cela vous permet d'opérationnaliser les flux de travail ML dans le cadre des pipelines Kubeflow, où vous pouvez utiliser Kubernetes pour la formation locale et SageMaker pour la formation à l'échelle du produit dans une architecture hybride.

Vue d'ensemble de la solution

L'architecture suivante décrit comment nous utilisons Kubeflow Pipelines pour créer et déployer des workflows de ML portables et évolutifs de bout en bout afin d'exécuter de manière conditionnelle une formation distribuée sur Kubernetes à l'aide de la formation Kubeflow ou de SageMaker en fonction du paramètre d'exécution.

La formation Kubeflow est un groupe d'opérateurs Kubernetes qui ajoutent à Kubeflow la prise en charge de la formation distribuée de modèles ML à l'aide de différents frameworks tels que TensorFlow, PyTorch et autres. pytorch-operator est l'implémentation Kubeflow de Kubernetes ressource personnalisée (PyTorchJob) pour exécuter des tâches de formation PyTorch distribuées sur Kubernetes.

Nous utilisons le composant PyTorchJob Launcher dans le cadre du pipeline Kubeflow pour exécuter la formation distribuée PyTorch pendant la phase d'expérimentation lorsque nous avons besoin de flexibilité et d'un accès à toutes les ressources sous-jacentes pour le débogage et l'analyse interactifs.

Nous utilisons également des composants SageMaker pour Kubeflow Pipelines pour exécuter notre formation de modèle à l'échelle de la production. Cela nous permet de tirer parti des puissantes fonctionnalités de SageMaker telles que des services entièrement gérés, des tâches de formation distribuées avec une utilisation maximale du GPU et une formation rentable via Cloud de calcul élastique Amazon (Amazon EC2) Instances ponctuelles.

Dans le cadre du processus de création de flux de travail, vous effectuez les étapes suivantes (comme indiqué dans le diagramme précédent) pour créer ce pipeline :

1. Utilisez le fichier manifeste Kubeflow pour créer un tableau de bord Kubeflow et accéder aux blocs-notes Jupyter à partir du tableau de bord central Kubeflow.
2. Utilisez le SDK de pipeline Kubeflow pour créer et compiler des pipelines Kubeflow à l'aide de code Python. La compilation du pipeline convertit la fonction Python en une ressource de flux de travail, qui est un format YAML compatible avec Argo.
3. Utilisez le client du SDK Kubeflow Pipelines pour appeler le point de terminaison du service de pipeline afin d'exécuter le pipeline.
4. Le pipeline évalue les variables d'exécution conditionnelles et décide entre SageMaker ou Kubernetes comme environnement d'exécution cible.
5. Utilisez le composant Kubeflow PyTorch Launcher pour exécuter une formation distribuée sur l'environnement Kubernetes natif, ou utilisez le composant SageMaker pour soumettre la formation sur la plateforme gérée SageMaker.

La figure suivante montre les composants Kubeflow Pipelines impliqués dans l'architecture, ce qui nous donne la possibilité de choisir entre les environnements distribués Kubernetes ou SageMaker.

Flux de travail de cas d'utilisation

Nous utilisons l'approche étape par étape suivante pour installer et exécuter le cas d'utilisation pour la formation distribuée à l'aide d'Amazon EKS et de SageMaker à l'aide de Kubeflow sur AWS.

Pré-requis

Pour cette procédure pas à pas, vous devez disposer des prérequis suivants:

• An Compte AWS.
• Une machine avec Docker et le Interface de ligne de commande AWS (AWS CLI) installé.
• En option, vous pouvez utiliser AWSCloud9, un environnement de développement intégré (IDE) basé sur le cloud qui permet d'effectuer tout le travail à partir de votre navigateur Web. Pour les instructions de configuration, reportez-vous à Configurer l'IDE Cloud9. Dans votre environnement Cloud9, choisissez le signe plus et ouvrez un nouveau terminal.
• Créer un rôle avec le nom sagemakerrole. Ajouter des stratégies gérées AmazonSageMakerFullAccess ainsi que AmazonS3FullAccess pour permettre à SageMaker d'accéder aux compartiments S3. Ce rôle est utilisé par la tâche SageMaker soumise dans le cadre de l'étape Kubeflow Pipelines.
• Assurez-vous que votre compte dispose d'une limite de type de ressource de formation SageMaker pour ml.p3.2xlarge augmenté à 2 en utilisant Console des quotas de service

1. Installez Amazon EKS et Kubeflow sur AWS

Vous pouvez utiliser plusieurs approches différentes pour créer un cluster Kubernetes et déployer Kubeflow. Dans cet article, nous nous concentrons sur une approche qui, selon nous, simplifie le processus. Tout d'abord, nous créons un cluster EKS, puis nous y déployons Kubeflow sur AWS v1.5. Pour chacune de ces tâches, nous utilisons un projet open source correspondant qui suit les principes de la Faire le cadre. Plutôt que d'installer un ensemble de prérequis pour chaque tâche, nous construisons des conteneurs Docker qui disposent de tous les outils nécessaires et effectuons les tâches depuis les conteneurs.

Nous utilisons le Do Framework dans cet article, qui automatise le déploiement de Kubeflow avec Amazon EFS en tant que module complémentaire. Pour les options de déploiement officielles de Kubeflow sur AWS pour les déploiements de production, consultez Déploiement.

Configurer le répertoire de travail actuel et l'AWS CLI

Nous configurons un répertoire de travail afin de pouvoir nous y référer comme point de départ des étapes suivantes :

export working_dir=$PWD

Nous configurons également un profil AWS CLI. Pour ce faire, vous avez besoin d'un ID de clé d'accès et d'une clé d'accès secrète d'un Gestion des identités et des accès AWS (JE SUIS) utilisateur compte avec des privilèges administratifs (joindre la stratégie gérée existante) et un accès par programmation. Voir le code suivant :

aws configure --profile=kubeflow
AWS Access Key ID [None]: 
AWS Secret Access Key [None]: 
Default region name [None]: us-west-2
Default output format [None]: json

# (In Cloud9, select “Cancel” and “Permanently disable” when the AWS managed temporary credentials dialog pops up)

export AWS_PROFILE=kubeflow

1.1 Créer un cluster EKS

Si vous disposez déjà d'un cluster EKS, vous pouvez passer à la section suivante. Pour ce post, nous utilisons le projet aws-do-eks pour créer notre cluster.

1. Clonez d'abord le projet dans votre répertoire de travail

   cd ${working_dir}
   git clone https://github.com/aws-samples/aws-do-eks
   cd aws-do-eks/

2. Ensuite, construisez et exécutez le aws-do-eks récipient:

   ./build.sh
   ./run.sh

   Les build.sh Le script crée une image de conteneur Docker qui dispose de tous les outils et scripts nécessaires pour le provisionnement et le fonctionnement des clusters EKS. La run.sh Le script démarre un conteneur à l'aide de l'image Docker créée et le maintient, afin que nous puissions l'utiliser comme environnement de gestion EKS. Pour voir l'état de votre aws-do-eks conteneur, vous pouvez exécuter ./status.sh. Si le conteneur est à l'état Quitté, vous pouvez utiliser le ./start.sh script pour afficher le conteneur ou pour redémarrer le conteneur, vous pouvez exécuter ./stop.sh suivie par ./run.sh.

3. Ouvrir un shell en cours d'exécution aws-do-eks récipient:
4. Pour examiner la configuration du cluster EKS pour notre déploiement KubeFlow, exécutez la commande suivante :

   vi ./eks-kubeflow.yaml

   Par défaut, cette configuration crée un cluster nommé eks-kubeflow dans l' us-west-2 Région avec six nœuds m5.xlarge. De plus, le chiffrement des volumes EBS n'est pas activé par défaut. Vous pouvez l'activer en ajoutant "volumeEncrypted: true" au groupe de nœuds et il chiffrera à l'aide de la clé par défaut. Modifiez les autres paramètres de configuration si nécessaire.

5. Pour créer le cluster, exécutez la commande suivante :

   export AWS_PROFILE=kubeflow
   eksctl create cluster -f ./eks-kubeflow.yaml

   Le processus de provisionnement du cluster peut prendre jusqu'à 30 minutes.

6. Pour vérifier que le cluster a bien été créé, exécutez la commande suivante :

   kubectl get nodes

   Le résultat de la commande précédente pour un cluster qui a été créé avec succès ressemble au code suivant :

   root@cdf4ecbebf62:/eks# kubectl get nodes
   NAME                                           STATUS   ROLES    AGE   VERSION
   ip-192-168-0-166.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-13-28.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-45-240.us-west-2.compute.internal   Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-63-84.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-75-56.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-85-226.us-west-2.compute.internal   Ready       23m   v1.21.14-eks-ba74326

Créer un volume EFS pour la tâche de formation SageMaker

Dans ce cas d'utilisation, vous accélérez la tâche de formation SageMaker en formant des modèles d'apprentissage en profondeur à partir de données déjà stockées dans Amazon EFS. Ce choix a l'avantage de lancer directement vos tâches de formation à partir des données dans Amazon EFS sans aucun déplacement de données requis, ce qui se traduit par des temps de démarrage de formation plus rapides.

Nous créons un volume EFS et déployons le pilote EFS Container Storage Interface (CSI). Ceci est accompli par un script de déploiement situé dans /eks/deployment/csi/efs au sein du aws-do-eks récipient.

Ce script suppose que vous avez un cluster EKS dans votre compte. Régler CLUSTER_NAME= au cas où vous auriez plus d'un cluster EKS.

cd /eks/deployment/csi/efs
./deploy.sh

Ce script provisionne un volume EFS et crée des cibles de montage pour les sous-réseaux du VPC de cluster. Il déploie ensuite le pilote EFS CSI et crée le efs-sc classe de stockage et efs-pv volume persistant dans le cluster EKS.

Une fois le script terminé avec succès, vous devriez voir une sortie comme celle-ci :

Generating efs-sc.yaml ...

Applying efs-sc.yaml ...
storageclass.storage.k8s.io/efs-sc created
NAME            PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
efs-sc          efs.csi.aws.com         Delete          Immediate              false                  1s
gp2 (default)   kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  36m

Generating efs-pv.yaml ...
Applying efs-pv.yaml ...
persistentvolume/efs-pv created
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
efs-pv   5Gi        RWX            Retain           Available           efs-sc                  10s

Done ...

Créer un point de terminaison de VPC Amazon S3

Vous utilisez un VPC privé auquel votre tâche de formation SageMaker et votre système de fichiers EFS ont accès. Pour donner au cluster de formation SageMaker l'accès aux compartiments S3 à partir de votre VPC privé, vous créez un point de terminaison VPC :

cd /eks/vpc 
export CLUSTER_NAME= 
export REGION= 
./vpc-endpoint-create.sh

Vous pouvez maintenant quitter le aws-do-eks shell du conteneur et passez à la section suivante :

exit

root@cdf4ecbebf62:/eks/deployment/csi/efs# exit
exit
TeamRole:~/environment/aws-do-eks (main) $

1.2 Déployer Kubeflow sur AWS sur Amazon EKS

Pour déployer Kubeflow sur Amazon EKS, nous utilisons le projet aws-do-kubeflow.

1. Clonez le dépôt à l'aide des commandes suivantes :

   cd ${working_dir}
   git clone https://github.com/aws-samples/aws-do-kubeflow
   cd aws-do-kubeflow

2. Configurez ensuite le projet :

   ./config.sh

   Ce script ouvre le fichier de configuration du projet dans un éditeur de texte. C'est important pour AWS_REGION à définir sur la région dans laquelle se trouve votre cluster, ainsi que AWS_CLUSTER_NAME pour correspondre au nom du cluster que vous avez créé précédemment. Par défaut, votre configuration est déjà correctement définie, donc si vous n'avez pas besoin d'apporter de modifications, fermez simplement l'éditeur.

   ./build.sh
   ./run.sh
   ./exec.sh

   Les build.sh Le script crée une image de conteneur Docker qui dispose de tous les outils nécessaires pour déployer et gérer Kubeflow sur un cluster Kubernetes existant. La run.sh démarre un conteneur, en utilisant l'image Docker, et le script exec.sh ouvre un shell de commande dans le conteneur, que nous pouvons utiliser comme environnement de gestion Kubeflow. Vous pouvez utiliser le ./status.sh script pour voir si le aws-do-kubeflow conteneur est opérationnel et le ./stop.sh ainsi que ./run.sh scripts pour le redémarrer si nécessaire.

3. Après avoir ouvert un shell dans le aws-do-eks conteneur, vous pouvez vérifier que le contexte de cluster configuré est comme prévu :

   root@ip-172-31-43-155:/kubeflow# kubectx
   kubeflow@eks-kubeflow.us-west-2.eksctl.io

4. Pour déployer Kubeflow sur le cluster EKS, exécutez le deploy.sh script:

   ./kubeflow-deploy.sh

   Le déploiement est réussi lorsque tous les pods de l'espace de noms kubeflow passent à l'état Running. Une sortie typique ressemble au code suivant :

   Waiting for all Kubeflow pods to start Running ...
   
   Waiting for all Kubeflow pods to start Running ...
   
   Restarting central dashboard ...
   pod "centraldashboard-79f489b55-vr6lp" deleted
   /kubeflow/deploy/distro/aws/kubeflow-manifests /kubeflow/deploy/distro/aws
   /kubeflow/deploy/distro/aws
   
   Kubeflow deployment succeeded
   Granting cluster access to kubeflow profile user ...
   Argument not provided, assuming default user namespace kubeflow-user-example-com ...
   clusterrolebinding.rbac.authorization.k8s.io/kubeflow-user-example-com-cluster-admin-binding created
   Setting up access to Kubeflow Pipelines ...
   Argument not provided, assuming default user namespace kubeflow-user-example-com ...
   
   Creating pod-default for namespace kubeflow-user-example-com ...
   poddefault.kubeflow.org/access-ml-pipeline created

5. Pour surveiller l'état des pods KubeFlow, dans une fenêtre séparée, vous pouvez utiliser la commande suivante :

   watch kubectl -n kubeflow get pods

6. Presse Ctrl + C lorsque tous les pods sont en cours d'exécution, exposez le tableau de bord Kubeflow en dehors du cluster en exécutant la commande suivante :

   ./kubeflow-expose.sh

Vous devriez voir une sortie qui ressemble au code suivant :

root@ip-172-31-43-155:/kubeflow# ./kubeflow-expose.sh
root@ip-172-31-43-155:/kubeflow# Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080

Cette commande transfère le service de passerelle d'entrée Istio de votre cluster vers votre port local 8080. Pour accéder au tableau de bord Kubeflow, consultez http://localhost:8080 et connectez-vous en utilisant les informations d'identification de l'utilisateur par défaut (user@example.com/12341234). Si vous exécutez le aws-do-kubeflow conteneur dans AWS Cloud9, vous pouvez alors choisir Aperçu, Puis choisissez Aperçu de l'application en cours d'exécution. Si vous utilisez Docker Desktop, vous devrez peut-être exécuter le ./kubeflow-expose.sh scénario en dehors du aws-do-kubeflow récipient.

2. Configurer l'environnement Kubeflow sur AWS

Pour configurer votre environnement Kubeflow sur AWS, nous créons un volume EFS et un notebook Jupyter.

2.1 Créer un volume EFS

Pour créer un volume EFS, procédez comme suit :

• Sur le tableau de bord Kubeflow, choisissez Volumes dans le volet de navigation.
• Choisissez Nouveau tome.
• Pour Nom, Entrer efs-sc-claim.
• Pour Taille du volume, Entrer 10.
• Pour Classe de stockage, choisissez efs-sc.
• Pour Mode d'accès, choisissez LireÉcrireUne fois.
• Selectionnez Création.

2.2 Créer un bloc-notes Jupyter

Pour créer un bloc-notes, procédez comme suit :

• Sur le tableau de bord Kubeflow, choisissez Carnets dans le volet de navigation.
• Selectionnez Nouveau cahier.
• Pour Nom, Entrer aws-hybrid-nb.
• Pour Image du dossier Jupyter, choisissez l'image c9e4w0g3/notebook-servers/jupyter-pytorch:1.11.0-cpu-py38-ubuntu20.04-e3-v1.1 (la dernière image DLC jupyter-pytorch disponible).
• Pour Processeur, Entrer 1.
• Pour Mémoire, Entrer 5.
• Pour GPU, laissez comme Aucun.
• N'apportez aucune modification au Volume de l'espace de travail .
• Dans le Volumes de données section, choisissez Attacher un volume existant et développez la section Volume existant
• Pour Nom, choisissez efs-sc-claim.
• Pour Chemin de montage, Entrer /home/jovyan/efs-sc-claim.
  Cela monte le volume EFS sur votre pod de bloc-notes Jupyter et vous pouvez voir le dossier efs-sc-claim dans votre interface de laboratoire Jupyter. Vous enregistrez l'ensemble de données de formation et le code de formation dans ce dossier afin que les clusters de formation puissent y accéder sans avoir à reconstruire les images de conteneur pour les tests.
• Sélectionnez Autoriser l'accès à Kubeflow Pipelines dans la rubrique Configuration.
• Selectionnez Lancement.
  Vérifiez que votre bloc-notes est créé avec succès (cela peut prendre quelques minutes).
• Sur le Carnets page, choisissez NOUS CONTACTER pour vous connecter à l'environnement JupyterLab.
• Sur le Git menu, choisissez Cloner un référentiel.
• Pour Cloner un dépôt, Entrer https://github.com/aws-samples/aws-do-kubeflow.
  

3. Organisez une formation distribuée

Après avoir configuré le bloc-notes Jupyter, vous pouvez exécuter l'intégralité de la démonstration en suivant les étapes de haut niveau suivantes à partir du dossier aws-do-kubeflow/workshop dans le dépôt cloné :

• Script de formation PyTorch Distributed Data Parallel (DDP) : Reportez-vous au script de formation PyTorch DDP cifar10-distributed-gpu-final.py, qui inclut un exemple de réseau neuronal convolutif et une logique pour distribuer la formation sur un cluster CPU et GPU multi-nœuds. (Voir 3.1 pour plus de détails)
• Installez les bibliothèques : Exécutez le bloc-notes 0_initialize_dependencies.ipynb pour initialiser toutes les dépendances. (Voir 3.2 pour plus de détails)
• Exécutez une formation sur les tâches PyTorch distribuée sur Kubernetes : Exécutez le bloc-notes 1_submit_pytorchdist_k8s.ipynb pour créer et soumettre une formation distribuée sur un conteneur principal et deux conteneurs de travail à l'aide du fichier YAML PyTorchJob de ressources personnalisées Kubernetes à l'aide de code Python. (Voir 3.3 pour plus de détails)
• Créez un pipeline Kubeflow hybride : Exécutez le bloc-notes 2_create_pipeline_k8s_sagemaker.ipynb pour créer le pipeline Kubeflow hybride qui exécute une formation distribuée sur SageMaker ou Amazon EKS à l'aide de la variable d'exécution training_runtime. (Voir 3.4 pour plus de détails)

Assurez-vous que vous avez exécuté le bloc-notes 1_submit_pytorchdist_k8s.ipynb avant de commencer le bloc-notes 2_create_pipeline_k8s_sagemaker.ipynb.

Dans les sections suivantes, nous détaillons chacune de ces étapes.

3.1 Script de formation PyTorch Distributed Data Parallel (DDP)

Dans le cadre de la formation distribuée, nous formons un modèle de classification créé par un simple réseau neuronal convolutif qui fonctionne sur l'ensemble de données CIFAR10. Le scénario de formation cifar10-distributed-gpu-final.py contient uniquement les bibliothèques open source et est compatible pour s'exécuter à la fois sur les clusters de formation Kubernetes et SageMaker sur des périphériques GPU ou des instances CPU. Examinons quelques aspects importants du script de formation avant d'exécuter nos exemples de bloc-notes.

Nous utilisons les torch.distributed module, qui contient la prise en charge de PyTorch et les primitives de communication pour le parallélisme multi-processus entre les nœuds du cluster :

...
import torch
import torch.distributed as dist
import torch.nn as nn
import torch.nn.functional as F
import torch.optim as optim
import torch.utils.data
import torch.utils.data.distributed
import torchvision
from torchvision import datasets, transforms
...

Nous créons un modèle simple de classification d'images en utilisant une combinaison de couches convolutives, de pooling max et linéaires auxquelles une fonction d'activation relu est appliquée dans le passage vers l'avant de la formation du modèle :

# Define models
class Net(nn.Module):
def __init__(self):
super(Net, self).__init__()
self.conv1 = nn.Conv2d(3, 6, 5)
self.pool = nn.MaxPool2d(2, 2)
self.conv2 = nn.Conv2d(6, 16, 5)
self.fc1 = nn.Linear(16 * 5 * 5, 120)
self.fc2 = nn.Linear(120, 84)
self.fc3 = nn.Linear(84, 10)

def forward(self, x):
x = self.pool(F.relu(self.conv1(x)))
x = self.pool(F.relu(self.conv2(x)))
x = x.view(-1, 16 * 5 * 5)
x = F.relu(self.fc1(x))
x = F.relu(self.fc2(x))
x = self.fc3(x)
return x

Nous utilisons le chalumeau DataLoader qui combine le jeu de données et DistributedSampler (charge un sous-ensemble de données de manière distribuée en utilisant torch.nn.parallel.DistributedDataParallel) et fournit un itérateur monoprocessus ou multiprocessus sur les données :

# Define data loader for training dataset
def _get_train_data_loader(batch_size, training_dir, is_distributed):
logger.info("Get train data loader")

train_set = torchvision.datasets.CIFAR10(root=training_dir,
train=True,
download=False,
transform=_get_transforms())

train_sampler = (
torch.utils.data.distributed.DistributedSampler(train_set) if is_distributed else None
)

return torch.utils.data.DataLoader(
train_set,
batch_size=batch_size,
shuffle=train_sampler is None,
sampler=train_sampler)
...

Si le cluster d'entraînement a des GPU, le script exécute l'entraînement sur les appareils CUDA et la variable d'appareil contient l'appareil CUDA par défaut :

device = "cuda" if torch.cuda.is_available() else "cpu"
...

Avant d'exécuter une formation distribuée à l'aide de PyTorch DistributedDataParallel pour exécuter un traitement distribué sur plusieurs nœuds, vous devez initialiser l'environnement distribué en appelant init_process_group. Celui-ci est initialisé sur chaque machine du cluster d'apprentissage.

dist.init_process_group(backend=args.backend, rank=host_rank, world_size=world_size)
...

Nous instancions le modèle de classifieur et copions le modèle sur l'appareil cible. Si la formation distribuée est activée pour s'exécuter sur plusieurs nœuds, le DistributedDataParallel La classe est utilisée comme objet wrapper autour de l'objet modèle, ce qui permet une formation distribuée synchrone sur plusieurs machines. Les données d'entrée sont réparties sur la dimension du lot et une réplique du modèle est placée sur chaque machine et chaque appareil.

model = Net().to(device)

if is_distributed:
model = torch.nn.parallel.DistributedDataParallel(model)

...

3.2 Installer les bibliothèques

Vous installerez toutes les bibliothèques nécessaires pour exécuter l'exemple de formation distribuée PyTorch. Cela inclut le SDK Kubeflow Pipelines, le SDK Python de l'opérateur de formation, le client Python pour Kubernetes et le SDK Python Amazon SageMaker.

#Please run the below commands to install necessary libraries

!pip install kfp==1.8.4

!pip install kubeflow-training

!pip install kubernetes

!pip install sagemaker

3.3 Exécuter une formation aux tâches PyTorch distribuée sur Kubernetes

Le cahier 1_submit_pytorchdist_k8s.ipynb crée le fichier YAML PyTorchJob de ressource personnalisée Kubernetes à l'aide de la formation Kubeflow et du SDK Python client Kubernetes. Voici quelques extraits importants de ce cahier.

Nous créons le PyTorchJob YAML avec les conteneurs principal et de travail, comme indiqué dans le code suivant :

# Define PyTorchJob custom resource manifest
pytorchjob = V1PyTorchJob(
api_version="kubeflow.org/v1",
kind="PyTorchJob",
metadata=V1ObjectMeta(name=pytorch_distributed_jobname,namespace=user_namespace),
spec=V1PyTorchJobSpec(
run_policy=V1RunPolicy(clean_pod_policy="None"),
pytorch_replica_specs={"Master": master,
"Worker": worker}
)
)

Celui-ci est soumis au plan de contrôle Kubernetes à l'aide de PyTorchJobClient:

# Creates and Submits PyTorchJob custom resource file to Kubernetes
pytorchjob_client = PyTorchJobClient()

pytorch_job_manifest=pytorchjob_client.create(pytorchjob):

Afficher les journaux de formation Kubernetes

Vous pouvez afficher les journaux de formation soit à partir du même bloc-notes Jupyter à l'aide de code Python, soit à partir du shell client Kubernetes.

3.4 Créer un pipeline Kubeflow hybride

Le cahier 2_create_pipeline_k8s_sagemaker.ipynb crée un pipeline Kubeflow hybride basé sur une variable d'exécution conditionnelle training_runtime, comme indiqué dans le code suivant. Le bloc-notes utilise le Kit de développement logiciel (SDK) Kubeflow Pipelines et il fournit un ensemble de packages Python pour spécifier et exécuter les pipelines de workflow ML. Dans le cadre de ce SDK, nous utilisons les packages suivants :

• Le décorateur de packages de langage spécifique au domaine (DSL) dsl.pipeline, qui décore les fonctions Python pour renvoyer un pipeline
• Les dsl.Condition package, qui représente un groupe d'opérations qui ne sont exécutées que lorsqu'une certaine condition est remplie, comme la vérification du training_runtime valeur comme sagemaker or kubernetes

Voir le code suivant:

# Define your training runtime value with either 'sagemaker' or 'kubernetes'
training_runtime='sagemaker'

# Create Hybrid Pipeline using Kubeflow PyTorch Training Operators and Amazon SageMaker Service
@dsl.pipeline(name="PyTorch Training pipeline", description="Sample training job test")
def pytorch_cnn_pipeline():

# Pipeline Step 1: to evaluate the condition. You can enter any logic here. For demonstration we are checking if GPU is needed for training
condition_result = check_condition_op(training_runtime)

# Pipeline Step 2: to run training on Kuberentes using PyTorch Training Operators. This will be executed if gpus are not needed
with dsl.Condition(condition_result.output == 'kubernetes', name="PyTorch_Comp"):
train_task = pytorch_job_op(
name=training_job_name,
namespace=user_namespace,
master_spec=json.dumps(master_spec_loaded), # Please refer file at pipeline_yaml_specifications/pipeline_master_spec.yml
worker_spec=json.dumps(worker_spec_loaded), # Please refer file at pipeline_yaml_specifications/pipeline_worker_spec.yml
delete_after_done=False
).after(condition_result)

# Pipeline Step 3: to run training on SageMaker using SageMaker Components for Pipeline. This will be executed if gpus are needed
with dsl.Condition(condition_result.output == 'sagemaker', name="SageMaker_Comp"):
training = sagemaker_train_op(
region=region,
image=train_image,
job_name=training_job_name,
training_input_mode=training_input_mode,
hyperparameters='{ 
"backend": "'+str(pytorch_backend)+'", 
"batch-size": "64", 
"epochs": "3", 
"lr": "'+str(learning_rate)+'", 
"model-type": "custom", 
"sagemaker_container_log_level": "20", 
"sagemaker_program": "cifar10-distributed-gpu-final.py", 
"sagemaker_region": "us-west-2", 
"sagemaker_submit_directory": "'+source_s3+'" 
}',
channels=channels,
instance_type=instance_type,
instance_count=instance_count,
volume_size=volume_size,
max_run_time=max_run_time,
model_artifact_path=f's3://{bucket_name}/jobs',
network_isolation=network_isolation,
traffic_encryption=traffic_encryption,
role=role,
vpc_subnets=subnet_id,
vpc_security_group_ids=security_group_id
).after(condition_result)

Nous configurons la formation distribuée SageMaker à l'aide de deux instances ml.p3.2xlarge.

Une fois le pipeline défini, vous pouvez compiler le pipeline selon une spécification Argo YAML à l'aide du SDK Kubeflow Pipelines. kfp.compiler forfait. Vous pouvez exécuter ce pipeline à l'aide du client Kubeflow Pipeline SDK, qui appelle le point de terminaison du service Pipelines et transmet les en-têtes d'authentification appropriés directement depuis le bloc-notes. Voir le code suivant :

# DSL Compiler that compiles pipeline functions into workflow yaml.
kfp.compiler.Compiler().compile(pytorch_cnn_pipeline, "pytorch_cnn_pipeline.yaml")

# Connect to Kubeflow Pipelines using the Kubeflow Pipelines SDK client
client = kfp.Client()

experiment = client.create_experiment(name="kubeflow")

# Run a specified pipeline
my_run = client.run_pipeline(experiment.id, "pytorch_cnn_pipeline", "pytorch_cnn_pipeline.yaml")

# Please click “Run details” link generated below this cell to view your pipeline. You can click every pipeline step to see logs.

Si vous obtenez un sagemaker import erreur, exécutez !pip install sagemaker et redémarrez le noyau (sur le Noyau menu, choisissez Redémarrer le noyau).

Choisissez le Détails de l'exécution sous la dernière cellule pour afficher le pipeline Kubeflow.

Répétez l'étape de création du pipeline avec training_runtime='kubernetes' pour tester l'exécution du pipeline dans un environnement Kubernetes. La training_runtime La variable peut également être transmise dans votre pipeline CI/CD dans un scénario de production.

Afficher les journaux d'exécution du pipeline Kubeflow pour le composant SageMaker

La capture d'écran suivante montre les détails de notre pipeline pour le composant SageMaker.

Choisissez l'étape de la tâche d'entraînement et sur la Journaux , choisissez le lien CloudWatch logs pour accéder aux journaux SageMaker.

La capture d'écran suivante montre les journaux CloudWatch pour chacune des deux instances ml.p3.2xlarge.

Choisissez l'un des groupes pour voir les journaux.

Afficher les journaux d'exécution du pipeline Kubeflow pour le composant Kubeflow PyTorchJob Launcher

La capture d'écran suivante montre les détails du pipeline pour notre composant Kubeflow.

Exécutez les commandes suivantes à l'aide de Kubectl sur votre shell client Kubernetes connecté au cluster Kubernetes pour voir les journaux (remplacez votre espace de noms et vos noms de pod) :

kubectl get pods -n kubeflow-user-example-com
kubectl logs  -n kubeflow-user-example-com -f

4.1 Nettoyer

Pour nettoyer toutes les ressources que nous avons créées dans le compte, nous devons les supprimer dans l'ordre inverse.

1. Supprimez l'installation de Kubeflow en exécutant ./kubeflow-remove.sh dans l' aws-do-kubeflow récipient. Le premier ensemble de commandes est facultatif et peut être utilisé au cas où vous n'auriez pas déjà un shell de commande dans votre aws-do-kubeflow conteneur ouvert.

   cd aws-do-kubeflow
   ./status.sh
   ./start.sh
   ./exec.sh
   
   ./kubeflow-remove.sh

2. Extrait du aws-do-eks dossier conteneur, supprimez le volume EFS. Le premier ensemble de commandes est facultatif et peut être utilisé au cas où vous n'auriez pas déjà un shell de commande dans votre aws-do-eks conteneur ouvert.

   cd aws-do-eks
   ./status.sh
   ./start.sh
   ./exec.sh
   
   cd /eks/deployment/csi/efs
   ./delete.sh
   ./efs-delete.sh

   La suppression d'Amazon EFS est nécessaire afin de libérer l'interface réseau associée au VPC que nous avons créé pour notre cluster. Notez que la suppression du volume EFS détruit toutes les données qui y sont stockées.

3. Extrait du aws-do-eks conteneur, exécutez le eks-delete.sh script pour supprimer le cluster et toutes les autres ressources qui lui sont associées, y compris le VPC :

   cd /eks
   ./eks-delete.sh

Résumé

Dans cet article, nous avons abordé certains des défis typiques de la formation de modèles distribués et des flux de travail ML. Nous avons fourni un aperçu de la distribution Kubeflow sur AWS et partagé deux projets open source (aws-do-eks ainsi que aws-do-kubeflow) qui simplifient le provisionnement de l'infrastructure et le déploiement de Kubeflow sur celle-ci. Enfin, nous avons décrit et démontré une architecture hybride qui permet aux charges de travail de passer de manière transparente entre l'exécution sur une infrastructure Kubernetes autogérée et une infrastructure SageMaker entièrement gérée. Nous vous encourageons à utiliser cette architecture hybride pour vos propres cas d'utilisation.

Vous pouvez suivre les Référentiel AWS Labs pour suivre toutes les contributions AWS à Kubeflow. Vous pouvez également nous retrouver sur le Chaîne Kubeflow #AWS Slack; vos commentaires nous aideront à prioriser les prochaines fonctionnalités à contribuer au projet Kubeflow.

Un merci spécial à Sree Arasanagatta (Software Development Manager AWS ML) et Suraj Kota (Software Dev Engineer) pour leur soutien au lancement de ce poste.

À propos des auteurs

Kanwaljit Khurmi est architecte de solutions spécialisées en IA/ML chez Amazon Web Services. Il travaille avec le produit AWS, l'ingénierie et les clients pour fournir des conseils et une assistance technique les aidant à améliorer la valeur de leurs solutions ML hybrides lors de l'utilisation d'AWS. Kanwaljit est spécialisé dans l'aide aux clients avec des applications conteneurisées et d'apprentissage automatique.

Gautam Kumar est un ingénieur logiciel avec AWS AI Deep Learning. Il a développé AWS Deep Learning Containers et AWS Deep Learning AMI. Il est passionné par la construction d'outils et de systèmes pour l'IA. Dans ses temps libres, il aime faire du vélo et lire des livres.

Alex Yankoulski est un architecte logiciel et infrastructure full-stack qui aime faire un travail approfondi et pratique. Il est actuellement architecte principal de solutions pour l'apprentissage automatique autogéré chez AWS. Dans son rôle, il se concentre sur l'aide aux clients pour la conteneurisation et l'orchestration des charges de travail ML et AI sur les services AWS alimentés par conteneurs. Il est également l'auteur de l'open source Faire le cadre et un capitaine Docker qui aime appliquer les technologies de conteneurs pour accélérer le rythme de l'innovation tout en résolvant les plus grands défis du monde. Au cours des 10 dernières années, Alex a travaillé sur la lutte contre le changement climatique, la démocratisation de l'IA et du ML, rendant les voyages plus sûrs, les soins de santé meilleurs et l'énergie plus intelligente.