Bouw flexibele en schaalbare gedistribueerde trainingsarchitecturen met Kubeflow op AWS en Amazon SageMaker

In deze post laten we zien hoe Kubeflow op AWS (een AWS-specifieke distributie van Kubeflow) gebruikt met AWS diepe leercontainers en Amazon elastisch bestandssysteem (Amazon EFS) vereenvoudigt samenwerking en biedt flexibiliteit bij het op grote schaal trainen van deep learning-modellen Amazon Elastic Kubernetes-service (Amazon EKS) en Amazon Sage Maker gebruik te maken van een hybride architectuurbenadering.

De ontwikkeling van machine learning (ML) is afhankelijk van complexe en continu evoluerende open-source frameworks en toolkits, evenals complexe en continu evoluerende hardware-ecosystemen. Dit vormt een uitdaging bij het uitschalen van ML-ontwikkeling naar een cluster. Containers bieden een oplossing, omdat ze niet alleen de trainingscode volledig kunnen inkapselen, maar de volledige afhankelijkheidsstack tot aan de hardwarebibliotheken. Dit zorgt voor een ML-omgeving die consistent en draagbaar is, en vergemakkelijkt de reproduceerbaarheid van de trainingsomgeving op elk afzonderlijk knooppunt van het trainingscluster.

Kubernetes is een veelgebruikt systeem voor het automatiseren van de implementatie van infrastructuur, het schalen van bronnen en het beheer van deze gecontaineriseerde applicaties. Kubernetes is echter niet gebouwd met ML in gedachten, dus het kan contra-intuïtief aanvoelen voor datawetenschappers vanwege de grote afhankelijkheid van YAML-specificatiebestanden. Er is geen Jupyter-ervaring en er zijn niet veel ML-specifieke mogelijkheden, zoals workflowbeheer en pijplijnen, en andere mogelijkheden die ML-experts verwachten, zoals hyperparameter-tuning, modelhosting en andere. Dergelijke mogelijkheden kunnen worden gebouwd, maar Kubernetes is niet ontworpen om dit als primaire doelstelling te doen.

De open-sourcegemeenschap merkte dit op en ontwikkelde een laag bovenop Kubernetes genaamd Kubeflow. Kubeflow heeft tot doel de implementatie van end-to-end ML-workflows op Kubernetes eenvoudig, draagbaar en schaalbaar te maken. U kunt Kubeflow gebruiken om de beste open-sourcesystemen voor ML in diverse infrastructuren te implementeren.

Kubeflow en Kubernetes bieden datawetenschapperteams flexibiliteit en controle. Het is echter nog steeds een uitdaging om te zorgen voor een hoog gebruik van trainingsclusters die op grote schaal worden uitgevoerd met lagere operationele overheadkosten.

Dit bericht laat zien hoe klanten met beperkingen op locatie of bestaande Kubernetes-investeringen deze uitdaging kunnen aangaan door Amazon EKS en Kubeflow op AWS te gebruiken om een ​​ML-pijplijn voor gedistribueerde training te implementeren op basis van een zelfbeheerde aanpak, en volledig beheerde SageMaker te gebruiken voor een kostengeoptimaliseerde, volledig beheerde trainingsinfrastructuur op productieschaal. Dit omvat de stapsgewijze implementatie van een hybride gedistribueerde trainingsarchitectuur waarmee u tijdens runtime kunt kiezen tussen de twee benaderingen, waardoor u maximale controle en flexibiliteit krijgt met strikte vereisten voor uw implementaties. U zult zien hoe u open-sourcebibliotheken kunt blijven gebruiken in uw deep learning-trainingsscript en het toch compatibel kunt maken om op zowel Kubernetes als SageMaker te draaien op een platformonafhankelijke manier.

Hoe helpt Kubeflow op AWS en SageMaker?

Neurale netwerkmodellen die zijn gebouwd met deep learning-frameworks zoals TensorFlow, PyTorch, MXNet en andere, bieden een veel hogere nauwkeurigheid door aanzienlijk grotere trainingsdatasets te gebruiken, vooral bij gebruik van computervisie en natuurlijke taalverwerking. Met grote trainingsdatasets duurt het echter langer om de deep learning-modellen te trainen, wat uiteindelijk de time-to-market vertraagt. Als we een cluster zouden kunnen uitschalen en de trainingstijd van het model kunnen terugbrengen van weken naar dagen of uren, zou dit een enorme impact kunnen hebben op de productiviteit en de bedrijfssnelheid.

Amazon EKS helpt bij het inrichten van het beheerde Kubernetes-besturingsvlak. U kunt Amazon EKS gebruiken om grootschalige trainingsclusters met CPU- en GPU-instanties te maken en de Kubeflow-toolkit gebruiken om ML-vriendelijke, open-source tools te bieden en ML-workflows te operationaliseren die draagbaar en schaalbaar zijn met Kubeflow Pipelines om de productiviteit van uw team te verbeteren en de time-to-market verkorten.

Er kunnen echter een aantal uitdagingen zijn bij deze aanpak:

• Zorgen voor maximaal gebruik van een cluster in datawetenschapsteams. U moet bijvoorbeeld GPU-instanties on-demand inrichten en zorgen voor een hoog gebruik voor veeleisende taken op productieschaal, zoals deep learning-training, en CPU-instanties gebruiken voor de minder veeleisende taken, zoals gegevensvoorverwerking
• Zorgen voor hoge beschikbaarheid van zware Kubeflow-infrastructuurcomponenten, inclusief database, opslag en authenticatie, die worden geïmplementeerd in het Kubernetes-clusterwerkerknooppunt. Het Kubeflow-besturingsvlak genereert bijvoorbeeld artefacten (zoals MySQL-instanties, podlogboeken of MinIO-opslag) die in de loop van de tijd groeien en aanpasbare opslagvolumes nodig hebben met continue bewakingsmogelijkheden.
• Het delen van de trainingsdataset, code en rekenomgevingen tussen ontwikkelaars, trainingsclusters en projecten is een uitdaging. Als je bijvoorbeeld aan je eigen set bibliotheken werkt en die bibliotheken sterk onderling afhankelijk zijn, wordt het heel moeilijk om hetzelfde stuk code te delen en uit te voeren tussen datawetenschappers in hetzelfde team. Voor elke trainingsrun moet u ook de trainingsgegevensset downloaden en de trainingsafbeelding bouwen met nieuwe codewijzigingen.

Kubeflow op AWS helpt deze uitdagingen aan te gaan en biedt een semi-beheerd Kubeflow-product op bedrijfsniveau. Met Kubeflow op AWS kunt u sommige Kubeflow-controlevlakservices zoals database, opslag, monitoring en gebruikersbeheer vervangen door door AWS beheerde services zoals Amazon relationele databaseservice (Amazone RDS), Amazon eenvoudige opslagservice (Amazone S3), Amazon elastisch bestandssysteem (Amazone EFS), Amazon FSx, Amazon Cloud Watch en Amazon Cognito.

Door deze Kubeflow-componenten te vervangen, worden kritieke onderdelen van het Kubeflow-besturingsvlak losgekoppeld van Kubernetes, wat een veilig, schaalbaar, veerkrachtig en kostengeoptimaliseerd ontwerp oplevert. Deze aanpak maakt ook opslag- en rekenbronnen vrij van het EKS-datavlak, wat nodig kan zijn voor toepassingen zoals gedistribueerde modeltraining of gebruikersnotebookservers. Kubeflow op AWS biedt ook native integratie van Jupyter-notebooks met Deep Learning Container (DLC)-afbeeldingen, die voorverpakt en geconfigureerd zijn met AWS-geoptimaliseerde deep learning-frameworks zoals PyTorch en TensorFlow, waarmee u direct kunt beginnen met het schrijven van uw trainingscode zonder dat u er iets aan hoeft te doen. met afhankelijkheidsresoluties en raamwerkoptimalisaties. Dankzij de integratie van Amazon EFS met trainingsclusters en de ontwikkelomgeving kunt u uw code en verwerkte trainingsdataset delen, waardoor het bouwen van de containerimage en het laden van enorme datasets na elke codewijziging wordt vermeden. Deze integraties met Kubeflow op AWS helpen je de modelbouw en trainingstijd te versnellen en zorgen voor een betere samenwerking met eenvoudiger delen van gegevens en code.

Kubeflow op AWS helpt bij het bouwen van een zeer beschikbaar en robuust ML-platform. Dit platform biedt flexibiliteit om deep learning-modellen te bouwen en te trainen en biedt toegang tot veel open-source toolkits, inzicht in logboeken en interactieve foutopsporing voor experimenten. Het bereiken van een maximaal gebruik van infrastructuurbronnen en het trainen van deep learning-modellen op honderden GPU's brengt echter nog steeds veel operationele overhead met zich mee. Dit kan worden verholpen door SageMaker te gebruiken, een volledig beheerde service die is ontworpen en geoptimaliseerd voor het verwerken van performante en kostengeoptimaliseerde trainingsclusters die alleen worden geleverd wanneer daarom wordt gevraagd, naar behoefte worden geschaald en automatisch worden afgesloten wanneer taken zijn voltooid, waardoor bijna 100 % resourcegebruik. U kunt SageMaker integreren met Kubeflow Pipelines met behulp van beheerde SageMaker-componenten. Hierdoor kunt u ML-workflows operationaliseren als onderdeel van Kubeflow-pipelines, waar u Kubernetes kunt gebruiken voor lokale training en SageMaker voor training op productschaal in een hybride architectuur.

Overzicht oplossingen

De volgende architectuur beschrijft hoe we Kubeflow-pijplijnen gebruiken om draagbare en schaalbare end-to-end ML-werkstromen te bouwen en te implementeren om voorwaardelijk gedistribueerde training op Kubernetes uit te voeren met behulp van Kubeflow-training of SageMaker op basis van de runtime-parameter.

Kubeflow-training is een groep Kubernetes-operators die aan Kubeflow de ondersteuning toevoegen voor gedistribueerde training van ML-modellen met behulp van verschillende frameworks zoals TensorFlow, PyTorch en andere. pytorch-operator is de Kubeflow-implementatie van de Kubernetes aangepaste bron (PyTorchJob) om gedistribueerde PyTorch-trainingstaken op Kubernetes uit te voeren.

We gebruiken de PyTorchJob Launcher-component als onderdeel van de Kubeflow-pijplijn om PyTorch-gedistribueerde training uit te voeren tijdens de experimentfase wanneer we flexibiliteit en toegang tot alle onderliggende bronnen nodig hebben voor interactieve foutopsporing en analyse.

We gebruiken ook SageMaker-componenten voor Kubeflow Pipelines om onze modeltraining op productieschaal uit te voeren. Hierdoor kunnen we profiteren van krachtige SageMaker-functies zoals volledig beheerde services, gedistribueerde trainingstaken met maximaal GPU-gebruik en kosteneffectieve training door Amazon Elastic Compute-cloud (Amazon EC2) Spot-instanties.

Als onderdeel van het proces voor het maken van de werkstroom voert u de volgende stappen uit (zoals weergegeven in het voorgaande diagram) om deze pijplijn te maken:

1. Gebruik het Kubeflow-manifestbestand om een ​​Kubeflow-dashboard te maken en toegang te krijgen tot Jupyter-notebooks vanuit het centrale Kubeflow-dashboard.
2. Gebruik de Kubeflow-pijplijn-SDK om Kubeflow-pijplijnen te maken en te compileren met behulp van python-code. Pipeline-compilatie converteert de Python-functie naar een werkstroombron, een Argo-compatibele YAML-indeling.
3. Gebruik de Kubeflow Pipelines SDK-client om het pijplijnservice-eindpunt aan te roepen om de pijplijn uit te voeren.
4. De pijplijn evalueert de voorwaardelijke runtime-variabelen en beslist tussen SageMaker of Kubernetes als de beoogde run-omgeving.
5. Gebruik de Kubeflow PyTorch Launcher-component om gedistribueerde training uit te voeren in de native Kubernetes-omgeving, of gebruik de SageMaker-component om de training in te dienen op het door SageMaker beheerde platform.

De volgende afbeelding toont de Kubeflow Pipelines-componenten die betrokken zijn bij de architectuur en die ons de flexibiliteit geven om te kiezen tussen Kubernetes- of SageMaker-gedistribueerde omgevingen.

Case-workflow gebruiken

We gebruiken de volgende stapsgewijze benadering om de use case voor gedistribueerde training te installeren en uit te voeren met Amazon EKS en SageMaker met Kubeflow op AWS.

Voorwaarden

Voor deze walkthrough moet u aan de volgende vereisten voldoen:

• An AWS-account.
• Een machine met Docker en de AWS-opdrachtregelinterface (AWS CLI) geïnstalleerd.
• Optioneel kunt u AWS-Cloud9, een cloudgebaseerde geïntegreerde ontwikkelomgeving (IDE) waarmee u al het werk vanuit uw webbrowser kunt voltooien. Raadpleeg voor installatie-instructies: Cloud9 IDE instellen. Kies vanuit uw Cloud9-omgeving het plusteken en open nieuwe terminal.
• Maak een rol met de naam sagemakerrole. Beheerd beleid toevoegen AmazonSageMakerFullAccess en AmazonS3FullAccess om SageMaker toegang te geven tot S3-buckets. Deze rol wordt gebruikt door de SageMaker-taak die is ingediend als onderdeel van de stap Kubeflow Pipelines.
• Zorg ervoor dat uw account een SageMaker Training-brontypelimiet heeft voor: ml.p3.2xlarge verhoogd tot 2 met behulp van Console voor servicequota

1. Installeer Amazon EKS en Kubeflow op AWS

U kunt verschillende benaderingen gebruiken om een ​​Kubernetes-cluster te bouwen en Kubeflow te implementeren. In deze post richten we ons op een aanpak die volgens ons eenvoud in het proces brengt. Eerst maken we een EKS-cluster en vervolgens implementeren we Kubeflow op AWS v1.5 erop. Voor elk van deze taken gebruiken we een bijbehorend open-sourceproject dat de principes van de Kader doen. In plaats van een reeks vereisten voor elke taak te installeren, bouwen we Docker-containers met alle benodigde tools en voeren we de taken uit vanuit de containers.

We gebruiken het Do Framework in dit bericht, dat de Kubeflow-implementatie automatiseert met Amazon EFS als add-on. Raadpleeg voor de officiële Kubeflow op AWS-implementatie-opties voor productie-implementaties: Deployment.

Configureer de huidige werkmap en AWS CLI

We configureren een werkmap zodat we ernaar kunnen verwijzen als het startpunt voor de volgende stappen:

export working_dir=$PWD

We configureren ook een AWS CLI-profiel. Hiervoor heeft u een toegangssleutel-ID en geheime toegangssleutel nodig van een AWS Identiteits- en toegangsbeheer (IAM) gebruiker account met beheerdersrechten (voeg het bestaande beheerde beleid toe) en programmatische toegang. Zie de volgende code:

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 Een EKS-cluster maken

Als u al een EKS-cluster beschikbaar heeft, kunt u doorgaan naar de volgende sectie. Voor dit bericht gebruiken we de aws-do-eks-project om onze cluster te creëren.

1. Kloon eerst het project in uw werkmap

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

2. Bouw en voer vervolgens de aws-do-eks houder:

   ./build.sh
   ./run.sh

   De build.sh script maakt een Docker-containerimage met alle benodigde tools en scripts voor het inrichten en bedienen van EKS-clusters. De run.sh script start een container met behulp van de gemaakte Docker-image en houdt deze bij, zodat we deze kunnen gebruiken als onze EKS-beheeromgeving. Om de status van uw . te zien aws-do-eks container, je kunt rennen ./status.sh. Als de container de status Verlaten heeft, kunt u de ./start.sh script om de container te openen, of om de container opnieuw te starten, kunt u uitvoeren ./stop.sh gevolgd door ./run.sh.

3. Open een shell in de running aws-do-eks houder:
4. Voer de volgende opdracht uit om de EKS-clusterconfiguratie voor onze KubeFlow-implementatie te bekijken:

   vi ./eks-kubeflow.yaml

   Deze configuratie maakt standaard een cluster met de naam eks-kubeflow in de us-west-2 Regio met zes m5.xgrote knooppunten. EBS-volumecodering is ook niet standaard ingeschakeld. U kunt het inschakelen door toe te voegen "volumeEncrypted: true" naar de nodegroup en het zal versleutelen met de standaardsleutel. Wijzig indien nodig andere configuratie-instellingen.

5. Voer de volgende opdracht uit om het cluster te maken:

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

   Het clusterinrichtingsproces kan tot 30 minuten duren.

6. Voer de volgende opdracht uit om te controleren of het cluster is gemaakt:

   kubectl get nodes

   De uitvoer van de voorgaande opdracht voor een cluster dat is gemaakt, ziet eruit als de volgende code:

   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

Een EFS-volume maken voor de SageMaker-trainingstaak

In dit geval versnelt u de SageMaker-trainingstaak door deep learning-modellen te trainen op basis van gegevens die al zijn opgeslagen in Amazon EFS. Deze keuze heeft het voordeel dat uw trainingstaken direct worden gestart vanuit de gegevens in Amazon EFS zonder dat gegevensverplaatsing nodig is, wat resulteert in snellere starttijden van de training.

We maken een EFS-volume en implementeren de EFS Container Storage Interface (CSI)-driver. Dit wordt bereikt door een implementatiescript dat zich in /eks/deployment/csi/efs in de aws-do-eks container.

Dit script gaat ervan uit dat u één EKS-cluster in uw account heeft. Set CLUSTER_NAME= voor het geval u meer dan één EKS-cluster heeft.

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

Dit script voorziet in een EFS-volume en maakt aankoppeldoelen voor de subnetten van de cluster-VPC. Vervolgens implementeert het het EFS CSI-stuurprogramma en maakt het de efs-sc opslagklasse en efs-pv aanhoudend volume in het EKS-cluster.

Na succesvolle voltooiing van het script, zou u de volgende uitvoer moeten zien:

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 ...

Een Amazon S3 VPC-eindpunt maken

U gebruikt een privé-VPC waartoe uw SageMaker-trainingstaak en EFS-bestandssysteem toegang hebben. Om het SageMaker-trainingscluster toegang te geven tot de S3-buckets vanaf uw privé-VPC, maakt u een VPC-eindpunt:

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

U kunt nu de aws-do-eks container shell en ga verder met de volgende sectie:

exit

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

1.2 Kubeflow implementeren op AWS op Amazon EKS

Om Kubeflow op Amazon EKS te implementeren, gebruiken we de aws-do-kubeflow-project.

1. Kloon de repository met behulp van de volgende opdrachten:

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

2. Configureer vervolgens het project:

   ./config.sh

   Dit script opent het projectconfiguratiebestand in een teksteditor. Het is belangrijk voor AWS_REGION in te stellen op de regio waarin uw cluster zich bevindt, evenals: AWS_CLUSTER_NAME zodat deze overeenkomt met de naam van het cluster dat u eerder hebt gemaakt. Uw configuratie is standaard al correct ingesteld, dus als u geen wijzigingen hoeft aan te brengen, sluit u gewoon de editor.

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

   De build.sh script maakt een Docker-containerinstallatiekopie met alle hulpprogramma's die nodig zijn om Kubeflow op een bestaand Kubernetes-cluster te implementeren en te beheren. De run.sh script start een container, met behulp van de Docker-afbeelding, en het exec.sh-script opent een opdrachtshell in de container, die we kunnen gebruiken als onze Kubeflow-beheeromgeving. U kunt de ./status.sh script om te zien of de aws-do-kubeflow container is in gebruik en de ./stop.sh en ./run.sh scripts om het indien nodig opnieuw te starten.

3. Nadat je een shell hebt geopend in de aws-do-eks container, kunt u controleren of de geconfigureerde clustercontext is zoals verwacht:

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

4. Om Kubeflow op het EKS-cluster te implementeren, voert u de deploy.sh script:

   ./kubeflow-deploy.sh

   De implementatie is geslaagd wanneer alle peulen in de kubeflow-naamruimte de status Actief krijgen. Een typische uitvoer ziet eruit als de volgende code:

   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. Om de status van de KubeFlow-pods te controleren, kunt u in een apart venster de volgende opdracht gebruiken:

   watch kubectl -n kubeflow get pods

6. Media Ctrl + C wanneer alle pods actief zijn, stelt u het Kubeflow-dashboard buiten het cluster bloot door de volgende opdracht uit te voeren:

   ./kubeflow-expose.sh

U zou uitvoer moeten zien die eruitziet als de volgende code:

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

Met deze opdracht wordt de Istio ingress gateway-service doorgestuurd van uw cluster naar uw lokale poort 8080. Voor toegang tot het Kubeflow-dashboard gaat u naar http://localhost:8080 en log in met de standaardgebruikersgegevens (gebruiker@voorbeeld.com/12341234). Als je de aws-do-kubeflow container in AWS Cloud9, dan kun je kiezen Voorbeschouwing, kies dan Voorbeeld van actieve toepassing. Als u op Docker Desktop draait, moet u mogelijk de ./kubeflow-expose.sh script buiten de aws-do-kubeflow container.

2. Stel de Kubeflow in op de AWS-omgeving

Om uw Kubeflow op AWS-omgeving in te stellen, maken we een EFS-volume en een Jupyter-notebook.

2.1 Een EFS-volume maken

Voer de volgende stappen uit om een ​​EFS-volume te maken:

• Kies op het Kubeflow-dashboard Volumes in het navigatievenster.
• Chose Nieuw deel.
• Voor Naam, ga naar binnen efs-sc-claim.
• Voor Volume grootte, ga naar binnen 10.
• Voor Opslagklasse, kiezen efs-sc.
• Voor Toegangsmodus, kiezen LezenSchrijvenEenmaal.
• Kies creëren.

2.2 Een Jupyter-notebook maken

Voer de volgende stappen uit om een ​​nieuw notitieblok te maken:

• Kies op het Kubeflow-dashboard Notitieboekjes in het navigatievenster.
• Kies Nieuw notitieboek.
• Voor Naam, ga naar binnen aws-hybrid-nb.
• Voor Jupyter Docket-afbeelding, kies de afbeelding c9e4w0g3/notebook-servers/jupyter-pytorch:1.11.0-cpu-py38-ubuntu20.04-e3-v1.1 (de nieuwste beschikbare jupyter-pytorch DLC-afbeelding).
• Voor CPU, ga naar binnen 1.
• Voor Geheugen, ga naar binnen 5.
• Voor GPU's, laat als Geen.
• Breng geen wijzigingen aan in de Werkruimtevolume pagina.
• In het Gegevensvolumes sectie, kies Bestaand volume koppelen en vouw de sectie Bestaand volume uit
• Voor Naam, kiezen efs-sc-claim.
• Voor Mount pad, ga naar binnen /home/jovyan/efs-sc-claim.
  Dit koppelt het EFS-volume aan uw Jupyter-notebookpod en u kunt de map zien efs-sc-claim in uw Jupyter lab-interface. U slaat de trainingsgegevensset en trainingscode op in deze map zodat de trainingsclusters deze kunnen openen zonder dat u de containerinstallatiekopieën opnieuw hoeft te bouwen om te testen.
• kies Toegang tot Kubeflow Pipelines toestaan in het gedeelte Configuratie.
• Kies Lancering.
  Controleer of uw notitieblok is aangemaakt (dit kan een paar minuten duren).
• Op de Notitieboekjes pagina, kies Verbinden om in te loggen op de JupyterLab-omgeving.
• Op de Git menu, kies Een opslagplaats klonen.
• Voor Kloon een opslagplaats, ga naar binnen https://github.com/aws-samples/aws-do-kubeflow.
  

3. Gedistribueerde training uitvoeren

Nadat u de Jupyter-notebook hebt ingesteld, kunt u de volledige demo uitvoeren met behulp van de volgende stappen op hoog niveau vanuit de map: aws-do-kubeflow/workshop in de gekloonde repository:

• PyTorch Distributed Data Parallel (DDP) trainingsscript: Raadpleeg het PyTorch DDP-trainingsscript cifar10-distributed-gpu-final.py, dat een voorbeeld van een convolutioneel neuraal netwerk en logica bevat om training te distribueren op een CPU- en GPU-cluster met meerdere knooppunten. (Zie 3.1 voor details)
• Bibliotheken installeren: Voer de notebook uit 0_initialize_dependencies.ipynb om alle afhankelijkheden te initialiseren. (Zie 3.2 voor details)
• Voer gedistribueerde PyTorch-jobtraining uit op Kubernetes: Voer de notebook uit 1_submit_pytorchdist_k8s.ipynb om gedistribueerde training te maken en in te dienen op één primaire en twee werkcontainers met behulp van het Kubernetes aangepaste bron PyTorchJob YAML-bestand met behulp van Python-code. (Zie 3.3 voor details)
• Maak een hybride Kubeflow-pijplijn: Voer de notebook uit 2_create_pipeline_k8s_sagemaker.ipynb om de hybride Kubeflow-pijplijn te maken die gedistribueerde training uitvoert op SageMaker of Amazon EKS met behulp van de runtime-variabele training_runtime. (Zie 3.4 voor details)

Zorg ervoor dat je de notebook hebt uitgevoerd 1_submit_pytorchdist_k8s.ipynb voordat je notebook start 2_create_pipeline_k8s_sagemaker.ipynb.

In de volgende paragrafen bespreken we elk van deze stappen in detail.

3.1 PyTorch Distributed Data Parallel (DDP) trainingsscript

Als onderdeel van de gedistribueerde training trainen we een classificatiemodel dat is gemaakt door een eenvoudig convolutief neuraal netwerk dat werkt op de CIFAR10-dataset. Het trainingsscript cifar10-distributed-gpu-final.py bevat alleen de open-sourcebibliotheken en is compatibel om zowel op Kubernetes- als SageMaker-trainingsclusters op GPU-apparaten of CPU-instanties te draaien. Laten we een paar belangrijke aspecten van het trainingsscript bekijken voordat we onze notebookvoorbeelden uitvoeren.

We maken gebruik van de torch.distributed module, die PyTorch-ondersteuning en communicatieprimitieven bevat voor parallellisme met meerdere processen tussen knooppunten in het 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
...

We creëren een eenvoudig beeldclassificatiemodel met behulp van een combinatie van convolutionele, max pooling en lineaire lagen waarop een relu-activeringsfunctie wordt toegepast in de voorwaartse doorgang van de modeltraining:

# 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

We gebruiken de fakkel DataLoader die de dataset en DistributedSampler (laadt een subset van gegevens op een gedistribueerde manier met behulp van torch.nn.parallel.DistributedDataParallel) en biedt een single-process of multi-process iterator over de gegevens:

# 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)
...

Als het trainingscluster GPU's heeft, voert het script de training uit op CUDA-apparaten en bevat de apparaatvariabele het standaard CUDA-apparaat:

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

Voordat u gedistribueerde training uitvoert met PyTorch DistributedDataParallel om gedistribueerde verwerking op meerdere knooppunten uit te voeren, moet u de gedistribueerde omgeving initialiseren door te bellen met init_process_group. Dit wordt geïnitialiseerd op elke machine van het trainingscluster.

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

We instantiëren het classificatiemodel en kopiëren het model naar het doelapparaat. Als gedistribueerde training op meerdere knooppunten kan worden uitgevoerd, DistributedDataParallel class wordt gebruikt als een wrapper-object rond het modelobject, waardoor synchrone gedistribueerde training over meerdere machines mogelijk is. De invoergegevens worden gesplitst op de batchdimensie en een replica van het model wordt op elke machine en elk apparaat geplaatst.

model = Net().to(device)

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

...

3.2 Bibliotheken installeren

U installeert alle benodigde bibliotheken om het door PyTorch gedistribueerde trainingsvoorbeeld uit te voeren. Dit omvat Kubeflow Pipelines SDK, Training Operator Python SDK, Python-client voor Kubernetes en Amazon SageMaker Python SDK.

#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 Gedistribueerde PyTorch-jobtraining uitvoeren op Kubernetes

De notebook 1_submit_pytorchdist_k8s.ipynb maakt het Kubernetes-aangepaste resource PyTorchJob YAML-bestand met behulp van Kubeflow-training en de Kubernetes-client Python SDK. Hieronder volgen enkele belangrijke fragmenten uit dit notitieboek.

We maken de PyTorchJob YAML met de primaire en werkcontainers zoals weergegeven in de volgende code:

# 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}
)
)

Dit wordt ingediend bij het Kubernetes-besturingsvlak met behulp van PyTorchJobClient:

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

pytorch_job_manifest=pytorchjob_client.create(pytorchjob):

Bekijk de Kubernetes-trainingslogboeken

U kunt de trainingslogboeken bekijken vanuit hetzelfde Jupyter-notebook met Python-code of vanuit de Kubernetes-clientshell.

3.4 Een hybride Kubeflow-pijplijn maken

De notebook 2_create_pipeline_k8s_sagemaker.ipynb maakt een hybride Kubeflow-pijplijn op basis van een voorwaardelijke runtime-variabele training_runtime, zoals weergegeven in de volgende code. Het notitieboek gebruikt de Kubeflow Pipelines-SDK en het heeft een set Python-pakketten geleverd om de ML-werkstroompijplijnen op te geven en uit te voeren. Als onderdeel van deze SDK gebruiken we de volgende pakketten:

• De domeinspecifieke taal (DSL) pakketdecorateur dsl.pipeline, die de Python-functies siert om een ​​pijplijn te retourneren
• De dsl.Condition pakket, dat een groep bewerkingen vertegenwoordigt die alleen worden uitgevoerd als aan een bepaalde voorwaarde is voldaan, zoals het controleren van de training_runtime waarde als sagemaker or kubernetes

Zie de volgende code:

# 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)

We configureren SageMaker gedistribueerde training met behulp van twee ml.p3.2xlarge instances.

Nadat de pijplijn is gedefinieerd, kunt u de pijplijn compileren naar een Argo YAML-specificatie met behulp van de Kubeflow Pipelines SDK's kfp.compiler pakket. U kunt deze pijplijn uitvoeren met behulp van de Kubeflow Pipeline SDK-client, die het Pipelines-service-eindpunt aanroept en de juiste verificatieheaders rechtstreeks vanuit de notebook doorgeeft. Zie de volgende code:

# 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.

Als je een krijgt sagemaker import fout, voer !pip install sagemaker uit en herstart de kernel (op de pit menu, kies Herstart Kernel).

Kies de Gegevens uitvoeren link onder de laatste cel om de Kubeflow-pijplijn te bekijken.

Herhaal de stap voor het maken van de pijplijn met training_runtime='kubernetes' om de pijplijn te testen die wordt uitgevoerd in een Kubernetes-omgeving. De training_runtime variabele kan ook in een productiescenario in uw CI/CD-pijplijn worden doorgegeven.

Bekijk de Kubeflow-pijplijnuitvoeringslogboeken voor de SageMaker-component

De volgende schermafbeelding toont onze pijplijndetails voor de SageMaker-component.

Kies de opleidingstaak stap en op de Logs tabblad, kiest u de link CloudWatch-logboeken om toegang te krijgen tot de SageMaker-logboeken.

De volgende schermafbeelding toont de CloudWatch-logboeken voor elk van de twee ml.p3.2xlarge-instanties.

Kies een van de groepen om de logboeken te bekijken.

Bekijk de Kubeflow-pijplijnuitvoeringslogboeken voor de Kubeflow PyTorchJob Launcher-component

De volgende schermafbeelding toont de pijplijndetails voor onze Kubeflow-component.

Voer de volgende opdrachten uit met Kubectl op uw Kubernetes-clientshell die is verbonden met het Kubernetes-cluster om de logboeken te zien (vervang uw naamruimte- en podnamen):

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

4.1 Opruimen

Om alle bronnen die we in het account hebben gemaakt op te schonen, moeten we ze in omgekeerde volgorde verwijderen.

1. Verwijder de Kubeflow-installatie door uit te voeren ./kubeflow-remove.sh in de aws-do-kubeflow container. De eerste reeks opdrachten is optioneel en kan worden gebruikt als u nog geen opdrachtshell in uw aws-do-kubeflow container geopend.

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

2. Van de aws-do-eks container map, verwijdert u het EFS-volume. De eerste reeks opdrachten is optioneel en kan worden gebruikt als u nog geen opdrachtshell in uw aws-do-eks container geopend.

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

   Het verwijderen van Amazon EFS is nodig om de netwerkinterface vrij te geven die is gekoppeld aan de VPC die we voor ons cluster hebben gemaakt. Houd er rekening mee dat het verwijderen van het EFS-volume alle gegevens vernietigt die erop zijn opgeslagen.

3. Van de aws-do-eks container, voer de eks-delete.sh script om het cluster en alle andere daaraan gekoppelde bronnen te verwijderen, inclusief de VPC:

   cd /eks
   ./eks-delete.sh

Samengevat

In dit bericht hebben we enkele van de typische uitdagingen van gedistribueerde modeltraining en ML-workflows besproken. We hebben een overzicht gegeven van de Kubeflow op AWS-distributie en hebben twee open-sourceprojecten gedeeld (aws-do-eks en aws-do-kubeflow) die het inrichten van de infrastructuur en de implementatie van Kubeflow daarop vereenvoudigen. Ten slotte hebben we een hybride architectuur beschreven en gedemonstreerd waarmee workloads naadloos kunnen overschakelen tussen het draaien op een zelfbeheerde Kubernetes en een volledig beheerde SageMaker-infrastructuur. We raden u aan deze hybride architectuur te gebruiken voor uw eigen use-cases.

Je kunt het volgen AWS Labs-repository om alle AWS-bijdragen aan Kubeflow bij te houden. U kunt ons ook vinden op de Kubeflow #AWS Slack-kanaal; uw feedback daar helpt ons bij het prioriteren van de volgende functies om bij te dragen aan het Kubeflow-project.

Speciale dank aan Sree Arasanagatta (Software Development Manager AWS ML) en Suraj Kota (Software Dev Engineer) voor hun steun bij de lancering van dit bericht.

Over de auteurs

Kanwaljit Khurmi is een AI/ML Specialist Solutions Architect bij Amazon Web Services. Hij werkt samen met het AWS-product, de engineering en klanten om begeleiding en technische assistentie te bieden om hen te helpen de waarde van hun hybride ML-oplossingen te verbeteren bij het gebruik van AWS. Kanwaljit is gespecialiseerd in het helpen van klanten met toepassingen in containers en machine learning.

Gautama Kumar is een Software Engineer bij AWS AI Deep Learning. Hij heeft AWS Deep Learning Containers en AWS Deep Learning AMI ontwikkeld. Hij is gepassioneerd door het bouwen van tools en systemen voor AI. In zijn vrije tijd fietst hij graag en leest hij graag boeken.

Alex Iankouski is een full-stack software- en infrastructuurarchitect die graag diepgaand, hands-on werk doet. Momenteel is hij Principal Solutions Architect for Self-managed Machine Learning bij AWS. In zijn rol richt hij zich op het helpen van klanten met containerisatie en orkestratie van ML- en AI-workloads op container-aangedreven AWS-services. Hij is ook de auteur van de open source Doe kader en een Docker-kapitein die dol is op het toepassen van containertechnologieën om het innovatietempo te versnellen en 's werelds grootste uitdagingen op te lossen. De afgelopen 10 jaar heeft Alex gewerkt aan het bestrijden van klimaatverandering, het democratiseren van AI en ML, het veiliger maken van reizen, het verbeteren van de gezondheidszorg en het slimmer maken van energie.