Byg fleksible og skalerbare distribuerede træningsarkitekturer ved hjælp af Kubeflow på AWS og Amazon SageMaker

I dette indlæg viser vi hvordan Kubeflow på AWS (en AWS-specifik distribution af Kubeflow) brugt med AWS Deep Learning-containere , Amazon Elastic File System (Amazon EFS) forenkler samarbejde og giver fleksibilitet i træning af dyb læringsmodeller i stor skala på både Amazon Elastic Kubernetes Service (Amazon EKS) og Amazon SageMaker ved at bruge en hybrid arkitekturtilgang.

Udvikling af maskinlæring (ML) er afhængig af komplekse og kontinuerligt udviklende open source-rammer og værktøjssæt, såvel som komplekse og konstant udviklende hardware-økosystemer. Dette udgør en udfordring, når man skalerer ML-udvikling til en klynge. Containere tilbyder en løsning, fordi de fuldt ud kan indkapsle ikke blot træningskoden, men hele afhængighedsstakken ned til hardwarebibliotekerne. Dette sikrer et ML-miljø, der er konsistent og bærbart, og letter reproducerbarheden af ​​træningsmiljøet på hver enkelt knude i træningsklyngen.

Kubernetes er et bredt anvendt system til automatisering af infrastrukturimplementering, ressourceskalering og administration af disse containeriserede applikationer. Kubernetes blev dog ikke bygget med ML i tankerne, så det kan føles kontraintuitivt for dataforskere på grund af dets store afhængighed af YAML-specifikationsfiler. Der er ikke en Jupyter-oplevelse, og der er ikke mange ML-specifikke muligheder, såsom workflow-styring og pipelines, og andre muligheder, som ML-eksperter forventer, såsom hyperparametertuning, modelhosting og andre. Sådanne muligheder kan bygges, men Kubernetes var ikke designet til at gøre dette som dets primære mål.

Open source-fællesskabet lagde mærke til det og udviklede et lag oven på Kubernetes kaldet Kubeflow. Kubeflow sigter mod at gøre implementeringen af ​​end-to-end ML-arbejdsgange på Kubernetes enkel, bærbar og skalerbar. Du kan bruge Kubeflow til at implementere best-of-breed open source-systemer til ML til forskellige infrastrukturer.

Kubeflow og Kubernetes giver fleksibilitet og kontrol til dataforskerhold. Det er dog stadig en udfordring at sikre høj udnyttelse af træningsklynger, der kører i skala med reducerede driftsomkostninger.

Dette indlæg demonstrerer, hvordan kunder, der har restriktioner på stedet eller eksisterende Kubernetes-investeringer, kan tackle denne udfordring ved at bruge Amazon EKS og Kubeflow på AWS til at implementere en ML-pipeline til distribueret træning baseret på en selvadministreret tilgang og bruge fuldt administreret SageMaker til en omkostningsoptimeret, fuldt administreret og produktionsskala træningsinfrastruktur. Dette inkluderer trin-for-trin implementering af en hybrid distribueret træningsarkitektur, der giver dig mulighed for at vælge mellem de to tilgange under kørsel, hvilket giver maksimal kontrol og fleksibilitet med strenge behov for dine implementeringer. Du vil se, hvordan du kan fortsætte med at bruge open source-biblioteker i dit deep learning-træningsscript og stadig gøre det kompatibelt at køre på både Kubernetes og SageMaker på en platformagnostisk måde.

Hvordan hjælper Kubeflow på AWS og SageMaker?

Neurale netværksmodeller bygget med deep learning-rammer som TensorFlow, PyTorch, MXNet og andre giver meget højere nøjagtighed ved at bruge væsentligt større træningsdatasæt, især i tilfælde af computersyn og naturlig sprogbehandling. Men med store træningsdatasæt tager det længere tid at træne de dybe læringsmodeller, hvilket i sidste ende bremser tiden til markedsføring. Hvis vi kunne udskalere en klynge og nedbringe modeltræningstiden fra uger til dage eller timer, kunne det have en enorm indflydelse på produktiviteten og forretningshastigheden.

Amazon EKS hjælper med at klargøre det administrerede Kubernetes-kontrolplan. Du kan bruge Amazon EKS til at skabe storskala træningsklynger med CPU- og GPU-instanser og bruge Kubeflow-værktøjssættet til at levere ML-venlige, open source-værktøjer og operationalisere ML-arbejdsgange, der er bærbare og skalerbare ved hjælp af Kubeflow Pipelines til at forbedre dit teams produktivitet og reducere tiden til markedet.

Der kan dog være et par udfordringer med denne tilgang:

• Sikring af maksimal udnyttelse af en klynge på tværs af datavidenskabsteams. For eksempel bør du levere GPU-instanser efter behov og sikre dens høje udnyttelse til krævende produktionsskalaopgaver såsom dyb læringstræning og bruge CPU-instanser til de mindre krævende opgaver såsom dataforbehandling
• Sikring af høj tilgængelighed af tunge Kubeflow-infrastrukturkomponenter, herunder database, lagring og godkendelse, der er implementeret i Kubernetes-klyngearbejderknuden. For eksempel genererer Kubeflow-kontrolplanet artefakter (såsom MySQL-forekomster, pod-logfiler eller MinIO-lagring), der vokser over tid og har brug for lagervolumener, der kan ændres størrelse med kontinuerlige overvågningsmuligheder.
• Det er udfordrende at dele træningsdatasættet, kode- og computermiljøerne mellem udviklere, træningsklynger og projekter. For eksempel, hvis du arbejder på dit eget sæt af biblioteker, og disse biblioteker har stærke indbyrdes afhængigheder, bliver det virkelig svært at dele og køre det samme stykke kode mellem dataforskere i det samme team. Hver træningskørsel kræver desuden, at du downloader træningsdatasættet og bygger træningsbilledet med nye kodeændringer.

Kubeflow på AWS hjælper med at løse disse udfordringer og leverer et semi-administreret Kubeflow-produkt i virksomhedskvalitet. Med Kubeflow på AWS kan du erstatte nogle Kubeflow-kontrolplantjenester som database, lagring, overvågning og brugeradministration med AWS-administrerede tjenester som f.eks. Amazon Relationel Database Service (Amazon RDS), Amazon Simple Storage Service (Amazon S3), Amazon Elastic File System (Amazon EFS), Amazon FSx, amazoncloudwatchog Amazon Cognito.

Udskiftning af disse Kubeflow-komponenter afkobler kritiske dele af Kubeflow-kontrolplanet fra Kubernetes, hvilket giver et sikkert, skalerbart, modstandsdygtigt og omkostningsoptimeret design. Denne tilgang frigør også lager- og computerressourcer fra EKS-dataplanet, hvilket kan være nødvendigt af applikationer såsom distribueret modeltræning eller brugernotebook-servere. Kubeflow på AWS giver også indbygget integration af Jupyter-notebooks med Deep Learning Container (DLC)-billeder, som er færdigpakket og prækonfigureret med AWS-optimerede deep learning-rammer såsom PyTorch og TensorFlow, der giver dig mulighed for at begynde at skrive din træningskode med det samme uden at handle. med afhængighedsopløsninger og rammeoptimeringer. Amazon EFS-integration med træningsklynger og udviklingsmiljøet giver dig også mulighed for at dele din kode og bearbejdede træningsdatasæt, hvilket undgår at bygge containerbilledet og indlæse enorme datasæt efter hver kodeændring. Disse integrationer med Kubeflow på AWS hjælper dig med at fremskynde modelopbygningen og træningstiden og giver mulighed for bedre samarbejde med lettere data- og kodedeling.

Kubeflow på AWS hjælper med at bygge en yderst tilgængelig og robust ML-platform. Denne platform giver fleksibilitet til at bygge og træne deep learning-modeller og giver adgang til mange open source-værktøjssæt, indsigt i logfiler og interaktiv debugging til eksperimentering. Men at opnå maksimal udnyttelse af infrastrukturressourcer, mens du træner deep learning-modeller på hundredvis af GPU'er, involverer stadig en masse driftsomkostninger. Dette kunne løses ved at bruge SageMaker, som er en fuldt administreret service, der er designet og optimeret til at håndtere effektive og omkostningsoptimerede træningsklynger, der kun klargøres, når der anmodes om det, skaleres efter behov og lukkes automatisk ned, når opgaver afsluttes, og derved giver tæt på 100 % ressourceudnyttelse. Du kan integrere SageMaker med Kubeflow Pipelines ved hjælp af administrerede SageMaker-komponenter. Dette giver dig mulighed for at operationalisere ML-arbejdsgange som en del af Kubeflow-pipelines, hvor du kan bruge Kubernetes til lokal træning og SageMaker til træning i produktskala i en hybrid arkitektur.

Løsningsoversigt

Den følgende arkitektur beskriver, hvordan vi bruger Kubeflow Pipelines til at bygge og implementere bærbare og skalerbare end-to-end ML-arbejdsgange til betinget at køre distribueret træning på Kubernetes ved hjælp af Kubeflow-træning eller SageMaker baseret på runtime-parameteren.

Kubeflow-træning er en gruppe af Kubernetes-operatører, der tilføjer Kubeflow støtte til distribueret træning af ML-modeller ved hjælp af forskellige rammer som TensorFlow, PyTorch og andre. pytorch-operator er Kubeflow-implementeringen af ​​Kubernetes tilpasset ressource (PyTorchJob) til at køre distribuerede PyTorch træningsjob på Kubernetes.

Vi bruger PyTorchJob Launcher-komponenten som en del af Kubeflow-pipelinen til at køre PyTorch-distribueret træning under eksperimenteringsfasen, når vi har brug for fleksibilitet og adgang til alle de underliggende ressourcer til interaktiv debugging og analyse.

Vi bruger også SageMaker-komponenter til Kubeflow Pipelines til at køre vores modeltræning i produktionsskala. Dette giver os mulighed for at drage fordel af kraftfulde SageMaker-funktioner såsom fuldt administrerede tjenester, distribuerede træningsjob med maksimal GPU-udnyttelse og omkostningseffektiv træning gennem Amazon Elastic Compute Cloud (Amazon EC2) Spot-forekomster.

Som en del af workflow-oprettelsesprocessen skal du udføre følgende trin (som vist i det foregående diagram) for at oprette denne pipeline:

1. Brug Kubeflow-manifestfilen til at oprette et Kubeflow-dashboard og få adgang til Jupyter-notesbøger fra det centrale Kubeflow-dashboard.
2. Brug Kubeflow pipeline SDK til at oprette og kompilere Kubeflow pipelines ved hjælp af Python-kode. Pipeline-kompilering konverterer Python-funktionen til en workflow-ressource, som er et Argo-kompatibelt YAML-format.
3. Brug Kubeflow Pipelines SDK-klienten til at kalde pipeline-serviceslutpunktet for at køre pipelinen.
4. Pipelinen evaluerer de betingede kørselsvariabler og beslutter mellem SageMaker eller Kubernetes som målkørselsmiljøet.
5. Brug Kubeflow PyTorch Launcher-komponenten til at køre distribueret træning på det oprindelige Kubernetes-miljø, eller brug SageMaker-komponenten til at indsende træningen på den SageMaker-administrerede platform.

Følgende figur viser Kubeflow Pipelines-komponenterne involveret i arkitekturen, som giver os fleksibiliteten til at vælge mellem Kubernetes eller SageMaker distribuerede miljøer.

Brug Case Workflow

Vi bruger følgende trin-for-trin tilgang til at installere og køre use casen til distribueret træning ved hjælp af Amazon EKS og SageMaker ved hjælp af Kubeflow på AWS.

Forudsætninger

For denne gennemgang skal du have følgende forudsætninger:

• An AWS-konto.
• En maskine med Docker og AWS kommandolinjegrænseflade (AWS CLI) installeret.
• Eventuelt kan du bruge AWS Cloud9, et cloud-baseret integreret udviklingsmiljø (IDE), der gør det muligt at fuldføre alt arbejdet fra din webbrowser. For opsætningsinstruktioner, se Opsæt Cloud9 IDE. Fra dit Cloud9-miljø skal du vælge plustegnet og åbne en ny terminal.
• Lav en rolle med navnet sagemakerrole. Tilføj administrerede politikker AmazonSageMakerFullAccess , AmazonS3FullAccess at give SageMaker adgang til S3 spande. Denne rolle bruges af SageMaker-job indsendt som en del af Kubeflow Pipelines-trinet.
• Sørg for, at din konto har en SageMaker Training-ressourcetypegrænse for ml.p3.2xlarge øget til 2 vha Servicekvoter konsol

1. Installer Amazon EKS og Kubeflow på AWS

Du kan bruge flere forskellige tilgange til at bygge en Kubernetes-klynge og implementere Kubeflow. I dette indlæg fokuserer vi på en tilgang, som vi mener gør processen enkel. Først opretter vi en EKS-klynge, derefter implementerer vi Kubeflow på AWS v1.5 på den. Til hver af disse opgaver bruger vi et tilsvarende open source-projekt, der følger principperne i Lav Framework. I stedet for at installere et sæt forudsætninger for hver opgave, bygger vi Docker-containere, der har alle de nødvendige værktøjer og udfører opgaverne inde fra containerne.

Vi bruger Do Framework i dette indlæg, som automatiserer Kubeflow-implementeringen med Amazon EFS som en tilføjelse. For de officielle Kubeflow på AWS-implementeringsmuligheder for produktionsimplementeringer, se Deployment.

Konfigurer den aktuelle arbejdsmappe og AWS CLI

Vi konfigurerer en arbejdsmappe, så vi kan henvise til den som udgangspunkt for de trin, der følger:

export working_dir=$PWD

Vi konfigurerer også en AWS CLI-profil. For at gøre det skal du bruge et adgangsnøgle-id og en hemmelig adgangsnøgle til en AWS identitets- og adgangsstyring (JEG ER) bruger konto med administrative rettigheder (vedhæft den eksisterende administrerede politik) og programmatisk adgang. Se følgende kode:

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 Opret en EKS-klynge

Hvis du allerede har en EKS-klynge tilgængelig, kan du springe til næste afsnit. Til dette indlæg bruger vi aws-do-eks projekt at skabe vores klynge.

1. Klon først projektet i din arbejdsmappe

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

2. Byg og kør derefter aws-do-eks beholder:

   ./build.sh
   ./run.sh

   build.sh script opretter et Docker-containerbillede, der har alle de nødvendige værktøjer og scripts til klargøring og drift af EKS-klynger. Det run.sh script starter en container ved hjælp af det oprettede Docker-billede og holder det oppe, så vi kan bruge det som vores EKS-administrationsmiljø. For at se status for din aws-do-eks container, kan du køre ./status.sh. Hvis beholderen er i Afsluttet status, kan du bruge ./start.sh script for at bringe containeren op, eller for at genstarte containeren, kan du køre ./stop.sh efterfulgt af ./run.sh.

3. Åbn en skal i løbet aws-do-eks beholder:
4. For at gennemgå EKS-klyngekonfigurationen for vores KubeFlow-implementering skal du køre følgende kommando:

   vi ./eks-kubeflow.yaml

   Som standard opretter denne konfiguration en klynge med navnet eks-kubeflow i us-west-2 Region med seks m5.xlarge noder. Desuden er EBS-volumenkryptering ikke aktiveret som standard. Du kan aktivere det ved at tilføje "volumeEncrypted: true" til nodegruppen, og den vil kryptere ved hjælp af standardnøglen. Rediger andre konfigurationsindstillinger, hvis det er nødvendigt.

5. For at oprette klyngen skal du køre følgende kommando:

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

   Klyngeklargøringsprocessen kan tage op til 30 minutter.

6. For at bekræfte, at klyngen blev oprettet, skal du køre følgende kommando:

   kubectl get nodes

   Outputtet fra den foregående kommando for en klynge, der blev oprettet med succes, ser ud som følgende kode:

   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

Opret en EFS-volumen til SageMaker-træningsjobbet

I dette tilfælde fremskynder du SageMaker-træningsjobbet ved at træne deep learning-modeller fra data, der allerede er lagret i Amazon EFS. Dette valg har den fordel, at du direkte starter dine træningsjob fra dataene i Amazon EFS uden dataflytning, hvilket resulterer i hurtigere træningsstarttider.

Vi opretter en EFS-volumen og implementerer EFS Container Storage Interface (CSI)-driveren. Dette opnås ved hjælp af et implementeringsscript placeret i /eks/deployment/csi/efs i aws-do-eks beholder.

Dette script antager, at du har én EKS-klynge på din konto. Sæt CLUSTER_NAME= hvis du har mere end én EKS-klynge.

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

Dette script sørger for en EFS-volumen og opretter monteringsmål for undernettene i klynge-VPC'en. Den implementerer derefter EFS CSI-driveren og opretter efs-sc opbevaringsklasse og efs-pv vedvarende volumen i EKS-klyngen.

Efter vellykket gennemførelse af scriptet, bør du se output som følgende:

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

Opret et Amazon S3 VPC-slutpunkt

Du bruger en privat VPC, som dit SageMaker-uddannelsesjob og EFS-filsystem har adgang til. For at give SageMaker træningsklyngen adgang til S3-bøtterne fra din private VPC, opretter du et VPC-slutpunkt:

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

Du kan nu forlade aws-do-eks beholderskal og fortsæt til næste afsnit:

exit

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

1.2 Implementer Kubeflow på AWS på Amazon EKS

For at implementere Kubeflow på Amazon EKS bruger vi aws-do-kubeflow projekt.

1. Klon depotet ved hjælp af følgende kommandoer:

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

2. Konfigurer derefter projektet:

   ./config.sh

   Dette script åbner projektkonfigurationsfilen i en teksteditor. Det er vigtigt for AWS_REGION skal indstilles til den region, din klynge er i, samt AWS_CLUSTER_NAME for at matche navnet på den klynge, du oprettede tidligere. Som standard er din konfiguration allerede korrekt indstillet, så hvis du ikke behøver at foretage nogen ændringer, skal du bare lukke editoren.

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

   build.sh script opretter et Docker-containerbillede, der har alle de nødvendige værktøjer til at implementere og administrere Kubeflow på en eksisterende Kubernetes-klynge. Det run.sh script starter en container ved hjælp af Docker-billedet, og exec.sh-scriptet åbner en kommandoskal i containeren, som vi kan bruge som vores Kubeflow-administrationsmiljø. Du kan bruge ./status.sh script for at se, om aws-do-kubeflow containeren er oppe at køre, og den ./stop.sh , ./run.sh scripts for at genstarte det efter behov.

3. Efter du har åbnet en skal i aws-do-eks container, kan du kontrollere, at den konfigurerede klyngekontekst er som forventet:

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

4. For at implementere Kubeflow på EKS-klyngen skal du køre deploy.sh manuskript:

   ./kubeflow-deploy.sh

   Implementeringen er vellykket, når alle pods i kubeflow-navneområdet går ind i tilstanden Kørende. Et typisk output ser ud som følgende kode:

   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. For at overvåge tilstanden af ​​KubeFlow pods, i et separat vindue, kan du bruge følgende kommando:

   watch kubectl -n kubeflow get pods

6. Presse Ctrl + C når alle pods kører, så eksponer Kubeflow-dashboardet uden for klyngen ved at køre følgende kommando:

   ./kubeflow-expose.sh

Du bør se output, der ligner følgende kode:

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

Denne kommando port-forwarder Istio ingress gateway-tjenesten fra din klynge til din lokale port 8080. For at få adgang til Kubeflow-dashboardet, besøg http://localhost:8080 og log ind med standardbrugeroplysningerne (bruger@eksempel.com/12341234). Hvis du kører aws-do-kubeflow container i AWS Cloud9, så kan du vælge Eksempel, Og vælg derefter Forhåndsvisning af kørende applikation. Hvis du kører på Docker Desktop, skal du muligvis køre ./kubeflow-expose.sh script uden for aws-do-kubeflow beholder.

2. Konfigurer Kubeflow på AWS-miljøet

For at konfigurere dit Kubeflow på AWS-miljø opretter vi et EFS-volumen og en Jupyter-notesbog.

2.1 Opret et EFS-volumen

For at oprette en EFS-diskenhed skal du udføre følgende trin:

• Vælg på Kubeflow-dashboardet Volumes i navigationsruden.
• valgte Nyt bind.
• Til Navn, gå ind efs-sc-claim.
• Til Volumen størrelse, gå ind 10.
• Til Opbevaringsklasse, vælg efs-sc.
• Til Adgangstilstand, vælg ReadWriteOnce.
• Vælg Opret.

2.2 Opret en Jupyter-notesbog

For at oprette en ny notesbog skal du udføre følgende trin:

• Vælg på Kubeflow-dashboardet Notebooks i navigationsruden.
• Vælg Ny notesbog.
• Til Navn, gå ind aws-hybrid-nb.
• Til Jupyter Docket billede, vælg billedet c9e4w0g3/notebook-servers/jupyter-pytorch:1.11.0-cpu-py38-ubuntu20.04-e3-v1.1 (det seneste tilgængelige Jupyter-pytorch DLC-billede).
• Til CPU, gå ind 1.
• Til Hukommelse, gå ind 5.
• Til GPU'er, lad være som Ingen.
• Foretag ikke ændringer i Workspace Volume sektion.
• I Datamængder sektion, skal du vælge Vedhæft eksisterende volumen og udvid Eksisterende volumensektion
• Til Navn, vælg efs-sc-claim.
• Til Mount sti, gå ind /home/jovyan/efs-sc-claim.
  Dette monterer EFS-volumen til din Jupyter notebook-pod, og du kan se mappen efs-sc-claim i din Jupyter lab-grænseflade. Du gemmer træningsdatasættet og træningskoden i denne mappe, så træningsklyngerne kan få adgang til det uden at skulle genopbygge containerbillederne til test.
• Type Tillad adgang til Kubeflow Pipelines i afsnittet Konfiguration.
• Vælg Launch.
  Bekræft, at din notesbog er oprettet korrekt (det kan tage et par minutter).
• På Notebooks side, vælg Tilslut for at logge på JupyterLab-miljøet.
• På Git menu, vælg Klon et depot.
• Til Klon en repo, gå ind https://github.com/aws-samples/aws-do-kubeflow.
  

3. Kør distribueret træning

Når du har konfigureret Jupyter notesbogen, kan du køre hele demoen ved at bruge følgende trin på højt niveau fra mappen aws-do-kubeflow/workshop i det klonede depot:

• PyTorch Distributed Data Parallel (DDP) træningsscript: Se PyTorch DDP-træningsscript cifar10-distributed-gpu-final.py, som inkluderer et eksempel på et foldet neuralt netværk og logik til at distribuere træning på en multi-node CPU og GPU-klynge. (Se 3.1 for detaljer)
• Installer biblioteker: Kør notesbogen 0_initialize_dependencies.ipynb at initialisere alle afhængigheder. (Se 3.2 for detaljer)
• Kør distribueret PyTorch jobtræning på Kubernetes: Kør notesbogen 1_submit_pytorchdist_k8s.ipynb at oprette og indsende distribueret træning på én primær og to arbejdercontainere ved hjælp af Kubernetes brugerdefinerede ressource PyTorchJob YAML-fil ved hjælp af Python-kode. (Se 3.3 for detaljer)
• Opret en hybrid Kubeflow-pipeline: Kør notesbogen 2_create_pipeline_k8s_sagemaker.ipynb at skabe den hybride Kubeflow-pipeline, der kører distribueret træning på enten SageMaker eller Amazon EKS ved hjælp af runtime-variablen training_runtime. (Se 3.4 for detaljer)

Sørg for at køre notesbogen 1_submit_pytorchdist_k8s.ipynb før du starter notesbogen 2_create_pipeline_k8s_sagemaker.ipynb.

I de efterfølgende afsnit diskuterer vi hvert af disse trin i detaljer.

3.1 PyTorch Distributed Data Parallel (DDP) træningsscript

Som en del af den distribuerede træning træner vi en klassifikationsmodel skabt af et simpelt foldet neuralt netværk, der opererer på CIFAR10-datasættet. Træningsmanuskriptet cifar10-distributed-gpu-final.py indeholder kun open source-biblioteker og er kompatibel til at køre både på Kubernetes og SageMaker træningsklynger på enten GPU-enheder eller CPU-instanser. Lad os se på et par vigtige aspekter af træningsscriptet, før vi kører vores notesbogseksempler.

Vi bruger torch.distributed modul, som indeholder PyTorch-understøttelse og kommunikationsprimitiver til multi-proces parallelisme på tværs af noder i klyngen:

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

Vi skaber en simpel billedklassificeringsmodel ved hjælp af en kombination af foldning, max pooling og lineære lag, hvorpå en relu-aktiveringsfunktion anvendes i det fremadrettede gennemløb af modeltræningen:

# 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

Vi bruger lommelygten DataLoader, der kombinerer datasættet og DistributedSampler (indlæser en delmængde af data på en distribueret måde ved hjælp af torch.nn.parallel.DistributedDataParallel) og giver en enkelt- eller multi-proces iterator over dataene:

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

Hvis træningsklyngen har GPU'er, kører scriptet træningen på CUDA-enheder, og enhedsvariablen indeholder standard-CUDA-enheden:

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

Før du kører distribueret træning ved hjælp af PyTorch DistributedDataParallel for at køre distribueret behandling på flere noder, skal du initialisere det distribuerede miljø ved at kalde init_process_group. Dette initialiseres på hver maskine i træningsklyngen.

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

Vi instansierer klassificeringsmodellen og kopierer modellen til målenheden. Hvis distribueret træning er aktiveret til at køre på flere noder, DistributedDataParallel klasse bruges som et indpakningsobjekt omkring modelobjektet, hvilket tillader synkron distribueret træning på tværs af flere maskiner. Inputdataene opdeles på batchdimensionen, og en kopi af modellen placeres på hver maskine og hver enhed.

model = Net().to(device)

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

...

3.2 Installer biblioteker

Du vil installere alle nødvendige biblioteker for at køre PyTorch-eksemplet med distribueret træning. Dette inkluderer Kubeflow Pipelines SDK, Training Operator Python SDK, Python-klient til Kubernetes og 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 Kør distribueret PyTorch jobtræning på Kubernetes

Notesbogen 1_submit_pytorchdist_k8s.ipynb opretter den tilpassede Kubernetes-ressource PyTorchJob YAML-fil ved hjælp af Kubeflow-træning og Kubernetes-klienten Python SDK. Det følgende er et par vigtige uddrag fra denne notesbog.

Vi opretter PyTorchJob YAML med de primære og arbejdsbeholdere som vist i følgende kode:

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

Dette indsendes til Kubernetes kontrolplan ved hjælp af PyTorchJobClient:

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

pytorch_job_manifest=pytorchjob_client.create(pytorchjob):

Se Kubernetes træningslogfiler

Du kan se træningsloggene enten fra den samme Jupyter-notebook ved hjælp af Python-kode eller fra Kubernetes-klientskallen.

3.4 Opret en hybrid Kubeflow-pipeline

Notesbogen 2_create_pipeline_k8s_sagemaker.ipynb opretter en hybrid Kubeflow-pipeline baseret på betinget runtime-variabel training_runtime, som vist i følgende kode. Notesbogen bruger Kubeflow Pipelines SDK og det leveres med et sæt Python-pakker til at specificere og køre ML workflow pipelines. Som en del af denne SDK bruger vi følgende pakker:

• Pakkedekorator for domænespecifikke sprog (DSL). dsl.pipeline, som dekorerer Python-funktionerne for at returnere en pipeline
• dsl.Condition pakke, som repræsenterer en gruppe af operationer, der kun køres, når en bestemt betingelse er opfyldt, såsom at kontrollere training_runtime værdi som sagemaker or kubernetes

Se følgende kode:

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

Vi konfigurerer SageMaker distribueret træning ved hjælp af to ml.p3.2xlarge instanser.

Efter at pipelinen er defineret, kan du kompilere pipelinen til en Argo YAML-specifikation ved hjælp af Kubeflow Pipelines SDK'er kfp.compiler pakke. Du kan køre denne pipeline ved hjælp af Kubeflow Pipeline SDK-klienten, som kalder Pipelines-tjenestens slutpunkt og sender passende godkendelsesheadere direkte fra notesbogen. Se følgende kode:

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

Hvis du får en sagemaker import fejl, kør !pip install sagemaker og genstart kernen (på kernel menu, vælg Genstart Kernel).

Vælg den Kør detaljer link under den sidste celle for at se Kubeflow-pipelinen.

Gentag trinnet til oprettelse af pipeline med training_runtime='kubernetes' at teste pipeline-kørslen i et Kubernetes-miljø. Det training_runtime variabel kan også overføres i din CI/CD-pipeline i et produktionsscenarie.

Se Kubeflow-pipeline-kørselsloggene for SageMaker-komponenten

Følgende skærmbillede viser vores pipeline detaljer for SageMaker-komponenten.

Vælg træningsjobbet trin og på Logs fanen, skal du vælge linket CloudWatch-logfiler for at få adgang til SageMaker-logfilerne.

Følgende skærmbillede viser CloudWatch-logfilerne for hver af de to ml.p3.2xlarge-forekomster.

Vælg en af ​​grupperne for at se logfilerne.

Se Kubeflow-pipelinekørselslogfilerne for Kubeflow PyTorchJob Launcher-komponenten

Følgende skærmbillede viser pipelinedetaljerne for vores Kubeflow-komponent.

Kør følgende kommandoer vha Kubectl på din Kubernetes-klient-shell forbundet til Kubernetes-klyngen for at se logfilerne (erstat dit navneområde og podnavne):

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

4.1 Oprydning

For at rydde op i alle de ressourcer, vi har oprettet på kontoen, skal vi fjerne dem i omvendt rækkefølge.

1. Slet Kubeflow-installationen ved at køre ./kubeflow-remove.sh i aws-do-kubeflow beholder. Det første sæt kommandoer er valgfrit og kan bruges, hvis du ikke allerede har en kommandoskal i din aws-do-kubeflow container åben.

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

2. På hjemmesiden for oprettelse af en konto skal du indtaste postnummeret for dit service-eller faktureringsområde i feltet, der er markeret (A) på billedet ovenfor. aws-do-eks container mappe, skal du fjerne EFS-diskenheden. Det første sæt kommandoer er valgfrit og kan bruges, hvis du ikke allerede har en kommandoskal i din aws-do-eks container åben.

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

   Sletning af Amazon EFS er nødvendig for at frigive netværksgrænsefladen forbundet med den VPC, vi har oprettet til vores klynge. Bemærk, at sletning af EFS-volumen ødelægger alle data, der er gemt på den.

3. På hjemmesiden for oprettelse af en konto skal du indtaste postnummeret for dit service-eller faktureringsområde i feltet, der er markeret (A) på billedet ovenfor. aws-do-eks container, køre eks-delete.sh script til at slette klyngen og alle andre ressourcer, der er knyttet til den, inklusive VPC'en:

   cd /eks
   ./eks-delete.sh

Resumé

I dette indlæg diskuterede vi nogle af de typiske udfordringer ved distribueret modeltræning og ML-arbejdsgange. Vi gav et overblik over Kubeflow på AWS-distribution og delte to open source-projekter (aws-do-eks , aws-do-kubeflow), der forenkler levering af infrastrukturen og implementeringen af ​​Kubeflow på den. Til sidst beskrev og demonstrerede vi en hybridarkitektur, der gør det muligt for arbejdsbelastninger at skifte problemfrit mellem at køre på en selvadministreret Kubernetes og fuldt administreret SageMaker-infrastruktur. Vi opfordrer dig til at bruge denne hybride arkitektur til dine egne brugssager.

Du kan følge AWS Labs repository at spore alle AWS-bidrag til Kubeflow. Du kan også finde os på Kubeflow #AWS Slack Channel; din feedback der vil hjælpe os med at prioritere de næste funktioner, der skal bidrage til Kubeflow-projektet.

Særlig tak til Sree Arasanagatta (Software Development Manager AWS ML) og Suraj Kota (Software Dev Engineer) for deres støtte til lanceringen af ​​dette indlæg.

Om forfatterne

Kanwaljit Khurmi er AI/ML Specialist Solutions Architect hos Amazon Web Services. Han arbejder med AWS-produktet, ingeniørarbejdet og kunderne for at yde vejledning og teknisk assistance, der hjælper dem med at forbedre værdien af ​​deres hybride ML-løsninger, når de bruger AWS. Kanwaljit har specialiseret sig i at hjælpe kunder med container- og maskinlæringsapplikationer.

Gautam Kumar er softwareingeniør med AWS AI Deep Learning. Han har udviklet AWS Deep Learning Containers og AWS Deep Learning AMI. Han brænder for at bygge værktøjer og systemer til kunstig intelligens. I sin fritid nyder han at cykle og læse bøger.

Alex Iankoulski er en fuld stack software- og infrastrukturarkitekt, der kan lide at udføre dybt, praktisk arbejde. Han er i øjeblikket Principal Solutions Architect for Self-managed Machine Learning hos AWS. I sin rolle fokuserer han på at hjælpe kunder med containerisering og orkestrering af ML- og AI-arbejdsbelastninger på containerdrevne AWS-tjenester. Han er også forfatter til open source Lav rammer og en Docker-kaptajn, der elsker at anvende containerteknologier til at accelerere innovationstempoet og samtidig løse verdens største udfordringer. I løbet af de sidste 10 år har Alex arbejdet på at bekæmpe klimaændringer, demokratisere AI og ML, gøre rejser sikrere, sundhedspleje bedre og energismartere.