Bygg fleksible og skalerbare distribuerte treningsarkitekturer ved å bruke Kubeflow på AWS og Amazon SageMaker

I dette innlegget viser vi hvordan Kubeflow på AWS (en AWS-spesifikk distribusjon av Kubeflow) brukt med AWS Deep Learning-beholdere og Amazon elastisk filsystem (Amazon EFS) forenkler samarbeid og gir fleksibilitet i opplæring av dyplæringsmodeller i stor skala på begge Amazon Elastic Kubernetes-tjeneste (Amazon EKS) og Amazon SageMaker bruke en hybrid arkitekturtilnærming.

Utvikling av maskinlæring (ML) er avhengig av komplekse og kontinuerlig utviklende rammeverk og verktøysett med åpen kildekode, samt komplekse og kontinuerlig utviklende maskinvareøkosystemer. Dette utgjør en utfordring når man skalerer ut ML-utvikling til en klynge. Containere tilbyr en løsning, fordi de fullt ut kan innkapsle ikke bare treningskoden, men hele avhengighetsstakken ned til maskinvarebibliotekene. Dette sikrer et ML-miljø som er konsistent og bærbart, og letter reproduserbarheten av treningsmiljøet på hver enkelt node i treningsklyngen.

Kubernetes er et allment brukt system for automatisering av infrastrukturdistribusjon, ressursskalering og administrasjon av disse containeriserte applikasjonene. Kubernetes ble imidlertid ikke bygget med ML i tankene, så det kan føles motintuitivt for dataforskere på grunn av sin store avhengighet av YAML-spesifikasjonsfiler. Det er ikke en Jupyter-opplevelse, og det er ikke mange ML-spesifikke funksjoner, for eksempel arbeidsflytadministrasjon og pipelines, og andre funksjoner som ML-eksperter forventer, for eksempel hyperparameterinnstilling, modellhosting og andre. Slike evner kan bygges, men Kubernetes ble ikke designet for å gjøre dette som sitt primære mål.

Åpen kildekode-fellesskapet la merke til og utviklet et lag på toppen av Kubernetes kalt Kubeflow. Kubeflow har som mål å gjøre distribusjonen av ende-til-ende ML-arbeidsflyter på Kubernetes enkel, bærbar og skalerbar. Du kan bruke Kubeflow til å distribuere best-of-breed åpen kildekode-systemer for ML til forskjellige infrastrukturer.

Kubeflow og Kubernetes gir fleksibilitet og kontroll til dataforskerteam. Det er imidlertid fortsatt utfordrende å sikre høy utnyttelse av treningsklynger som kjører i skala med reduserte driftskostnader.

Dette innlegget viser hvordan kunder som har restriksjoner på stedet eller eksisterende Kubernetes-investeringer kan møte denne utfordringen ved å bruke Amazon EKS og Kubeflow på AWS for å implementere en ML-pipeline for distribuert opplæring basert på en selvadministrert tilnærming, og bruke fullt administrert SageMaker for en kostnadsoptimalisert, fullt administrert og produksjonsskala opplæringsinfrastruktur. Dette inkluderer trinn-for-trinn-implementering av en hybrid distribuert treningsarkitektur som lar deg velge mellom de to tilnærmingene under kjøring, og gir maksimal kontroll og fleksibilitet med strenge behov for distribusjonene dine. Du vil se hvordan du kan fortsette å bruke åpen kildekode-biblioteker i opplæringsskriptet for dyp læring og fortsatt gjøre det kompatibelt å kjøre på både Kubernetes og SageMaker på en plattformagnostisk måte.

Hvordan hjelper Kubeflow på AWS og SageMaker?

Nevrale nettverksmodeller bygget med dype læringsrammer som TensorFlow, PyTorch, MXNet og andre gir mye høyere nøyaktighet ved å bruke betydelig større opplæringsdatasett, spesielt i datasyn og naturlig språkbehandling. Men med store opplæringsdatasett tar det lengre tid å trene dyplæringsmodellene, noe som til slutt reduserer tiden til markedet. Hvis vi kunne skalere ut en klynge og redusere treningstiden for modellen fra uker til dager eller timer, kan det ha stor innvirkning på produktivitet og forretningshastighet.

Amazon EKS hjelper til med å klargjøre det administrerte Kubernetes-kontrollflyet. Du kan bruke Amazon EKS til å lage storskala opplæringsklynger med CPU- og GPU-forekomster og bruke Kubeflow-verktøysettet til å tilby ML-vennlige, åpen kildekodeverktøy og operasjonalisere ML-arbeidsflyter som er bærbare og skalerbare ved å bruke Kubeflow Pipelines for å forbedre teamets produktivitet og redusere tiden til markedet.

Imidlertid kan det være et par utfordringer med denne tilnærmingen:

• Sikre maksimal utnyttelse av en klynge på tvers av datavitenskapsteam. Du bør for eksempel levere GPU-forekomster på forespørsel og sikre høy utnyttelse for krevende produksjonsskalaoppgaver som dyp læringstrening, og bruke CPU-forekomster for de mindre krevende oppgavene som dataforbehandling
• Sikre høy tilgjengelighet av tunge Kubeflow-infrastrukturkomponenter, inkludert database, lagring og autentisering, som er distribuert i Kubernetes-klyngearbeidernoden. For eksempel genererer Kubeflow-kontrollplanet artefakter (som MySQL-forekomster, pod-logger eller MinIO-lagring) som vokser over tid og trenger lagringsvolumer som kan endres med kontinuerlige overvåkingsmuligheter.
• Det er utfordrende å dele opplæringsdatasettet, kode- og datamiljøene mellom utviklere, opplæringsklynger og prosjekter. For eksempel, hvis du jobber med ditt eget sett med biblioteker og disse bibliotekene har sterke gjensidige avhengigheter, blir det veldig vanskelig å dele og kjøre den samme kodebiten mellom dataforskere i samme team. Hver treningskjøring krever også at du laster ned treningsdatasettet og bygger treningsbildet med nye kodeendringer.

Kubeflow på AWS hjelper til med å takle disse utfordringene og gir et halvadministrert Kubeflow-produkt i bedriftsklasse. Med Kubeflow på AWS kan du erstatte noen Kubeflow-kontrollflytjenester som database, lagring, overvåking og brukeradministrasjon med AWS-administrerte tjenester som Amazon Relational Database Service (Amazon RDS), Amazon enkel lagringstjeneste (Amazon S3), Amazon elastisk filsystem (Amazon EFS), Amazon FSx, Amazon CloudWatchog Amazon Cognito.

Ved å erstatte disse Kubeflow-komponentene kobles kritiske deler av Kubeflow-kontrollplanet fra Kubernetes, og gir en sikker, skalerbar, spenstig og kostnadsoptimalisert design. Denne tilnærmingen frigjør også lagrings- og dataressurser fra EKS-dataplanet, som kan være nødvendig av applikasjoner som distribuert modellopplæring eller bærbare brukerservere. Kubeflow på AWS gir også innebygd integrering av Jupyter-notatbøker med Deep Learning Container (DLC)-bilder, som er forhåndspakket og forhåndskonfigurert med AWS-optimaliserte dyplæringsrammeverk som PyTorch og TensorFlow som lar deg begynne å skrive treningskoden din med en gang uten å måtte handle. med avhengighetsoppløsninger og rammeverksoptimaliseringer. Amazon EFS-integrasjon med treningsklynger og utviklingsmiljøet lar deg også dele koden og det behandlede treningsdatasettet ditt, noe som unngår å bygge containerbildet og laste inn enorme datasett etter hver kodeendring. Disse integrasjonene med Kubeflow på AWS hjelper deg med å fremskynde modellbyggingen og treningstiden og tillater bedre samarbeid med enklere data- og kodedeling.

Kubeflow på AWS bidrar til å bygge en svært tilgjengelig og robust ML-plattform. Denne plattformen gir fleksibilitet til å bygge og trene dyplæringsmodeller og gir tilgang til mange verktøysett med åpen kildekode, innsikt i logger og interaktiv feilsøking for eksperimentering. Å oppnå maksimal utnyttelse av infrastrukturressursene mens du trener dyplæringsmodeller på hundrevis av GPU-er innebærer imidlertid fortsatt mange driftskostnader. Dette kan løses ved å bruke SageMaker, som er en fullstendig administrert tjeneste designet og optimert for å håndtere effektive og kostnadsoptimaliserte opplæringsklynger som bare klargjøres når det blir bedt om det, skaleres etter behov og stenges automatisk når jobber fullføres, og gir dermed nær 100 % ressursutnyttelse. Du kan integrere SageMaker med Kubeflow Pipelines ved å bruke administrerte SageMaker-komponenter. Dette lar deg operasjonalisere ML-arbeidsflyter som en del av Kubeflow-pipelines, hvor du kan bruke Kubernetes for lokal opplæring og SageMaker for produktskalaopplæring i en hybridarkitektur.

Løsningsoversikt

Den følgende arkitekturen beskriver hvordan vi bruker Kubeflow Pipelines til å bygge og distribuere bærbare og skalerbare ende-til-ende ML-arbeidsflyter for å betinget kjøre distribuert opplæring på Kubernetes ved å bruke Kubeflow-trening eller SageMaker basert på kjøretidsparameteren.

Kubeflow-trening er en gruppe Kubernetes-operatører som legger til Kubeflow støtte for distribuert opplæring av ML-modeller ved å bruke forskjellige rammeverk som TensorFlow, PyTorch og andre. pytorch-operator er Kubeflow-implementeringen av Kubernetes tilpasset ressurs (PyTorchJob) for å kjøre distribuerte PyTorch-treningsjobber på Kubernetes.

Vi bruker PyTorchJob Launcher-komponenten som en del av Kubeflow-pipelinen for å kjøre PyTorch distribuert opplæring under eksperimenteringsfasen når vi trenger fleksibilitet og tilgang til alle de underliggende ressursene for interaktiv feilsøking og analyse.

Vi bruker også SageMaker-komponenter for Kubeflow Pipelines for å kjøre modellopplæringen vår i produksjonsskala. Dette lar oss dra nytte av kraftige SageMaker-funksjoner som fullt administrerte tjenester, distribuerte opplæringsjobber med maksimal GPU-utnyttelse og kostnadseffektiv opplæring gjennom Amazon Elastic Compute Cloud (Amazon EC2) Spotforekomster.

Som en del av arbeidsflytopprettingsprosessen, fullfører du følgende trinn (som vist i det foregående diagrammet) for å lage denne rørledningen:

1. Bruk Kubeflow-manifestfilen til å lage et Kubeflow-dashbord og få tilgang til Jupyter-notatbøker fra det sentrale Kubeflow-dashbordet.
2. Bruk Kubeflow-rørlednings-SDK for å lage og kompilere Kubeflow-rørledninger ved hjelp av Python-kode. Pipeline-kompilering konverterer Python-funksjonen til en arbeidsflytressurs, som er et Argo-kompatibelt YAML-format.
3. Bruk Kubeflow Pipelines SDK-klienten til å ringe endepunktet for pipeline-tjenesten for å kjøre pipelinen.
4. Rørledningen evaluerer de betingede kjøretidsvariablene og bestemmer mellom SageMaker eller Kubernetes som målkjøringsmiljøet.
5. Bruk Kubeflow PyTorch Launcher-komponenten til å kjøre distribuert opplæring på det opprinnelige Kubernetes-miljøet, eller bruk SageMaker-komponenten for å sende inn opplæringen på den administrerte SageMaker-plattformen.

Følgende figur viser Kubeflow Pipelines-komponentene som er involvert i arkitekturen som gir oss fleksibiliteten til å velge mellom Kubernetes eller SageMaker distribuerte miljøer.

Bruk Case Workflow

Vi bruker følgende trinnvise tilnærming for å installere og kjøre brukstilfellet for distribuert opplæring ved bruk av Amazon EKS og SageMaker ved å bruke Kubeflow på AWS.

Forutsetninger

For dette gjennomgangen bør du ha følgende forutsetninger:

• An AWS-konto.
• En maskin med Docker og AWS kommandolinjegrensesnitt (AWS CLI) installert.
• Eventuelt kan du bruke AWS Cloud9, et skybasert integrert utviklingsmiljø (IDE) som gjør det mulig å fullføre alt arbeidet fra nettleseren din. For installasjonsinstruksjoner, se Sett opp Cloud9 IDE. Fra Cloud9-miljøet ditt, velg plusstegnet og åpne ny terminal.
• Lag en rolle med navnet sagemakerrole. Legg til administrerte retningslinjer AmazonSageMakerFullAccess og AmazonS3FullAccess for å gi SageMaker tilgang til S3-bøtter. Denne rollen brukes av SageMaker-jobben som er sendt inn som en del av Kubeflow Pipelines-trinnet.
• Sørg for at kontoen din har SageMaker Training-ressurstypegrense for ml.p3.2xlarge økt til 2 ved bruk Tjenestekvoter-konsoll

1. Installer Amazon EKS og Kubeflow på AWS

Du kan bruke flere forskjellige tilnærminger for å bygge en Kubernetes-klynge og distribuere Kubeflow. I dette innlegget fokuserer vi på en tilnærming som vi mener gir enkelhet i prosessen. Først lager vi en EKS-klynge, deretter distribuerer vi Kubeflow på AWS v1.5 på den. For hver av disse oppgavene bruker vi et tilsvarende åpen kildekode-prosjekt som følger prinsippene til Gjør rammeverk. I stedet for å installere et sett med forutsetninger for hver oppgave, bygger vi Docker-containere som har alle nødvendige verktøy og utfører oppgavene fra containerne.

Vi bruker Do Framework i dette innlegget, som automatiserer Kubeflow-distribusjonen med Amazon EFS som et tillegg. For de offisielle Kubeflow på AWS-distribusjonsalternativene for produksjonsdistribusjoner, se Utplassering.

Konfigurer gjeldende arbeidskatalog og AWS CLI

Vi konfigurerer en arbeidskatalog slik at vi kan referere til den som utgangspunkt for trinnene som følger:

export working_dir=$PWD

Vi konfigurerer også en AWS CLI-profil. For å gjøre det trenger du en tilgangsnøkkel-ID og en hemmelig tilgangsnøkkel til en AWS identitets- og tilgangsadministrasjon (JEG ER) bruker konto med administrative rettigheter (legg ved den eksisterende administrerte policyen) og programmatisk tilgang. 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 Opprett en EKS-klynge

Hvis du allerede har en EKS-klynge tilgjengelig, kan du hoppe til neste seksjon. For dette innlegget bruker vi aws-do-eks prosjekt å skape klyngen vår.

1. Klon først prosjektet i arbeidskatalogen din

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

2. Bygg og kjør deretter aws-do-eks container:

   ./build.sh
   ./run.sh

   De build.sh script oppretter et Docker-beholderbilde som har alle nødvendige verktøy og skript for klargjøring og drift av EKS-klynger. De run.sh script starter en container ved å bruke det opprettede Docker-bildet og holder det oppe, slik at vi kan bruke det som vårt EKS-administrasjonsmiljø. For å se statusen til din aws-do-eks container, kan du kjøre ./status.sh. Hvis beholderen er i Avsluttet-status, kan du bruke ./start.sh skript for å få opp beholderen, eller for å starte beholderen på nytt, kan du kjøre ./stop.sh etterfulgt av ./run.sh.

3. Åpne et skall i løpet aws-do-eks container:
4. For å se gjennom EKS-klyngekonfigurasjonen for KubeFlow-distribusjonen vår, kjør følgende kommando:

   vi ./eks-kubeflow.yaml

   Som standard oppretter denne konfigurasjonen en klynge med navn eks-kubeflow i us-west-2 Region med seks m5.xlarge noder. EBS-volumkryptering er heller ikke aktivert som standard. Du kan aktivere det ved å legge til "volumeEncrypted: true" til nodegruppen, og den vil kryptere med standardnøkkelen. Endre andre konfigurasjonsinnstillinger om nødvendig.

5. For å opprette klyngen, kjør følgende kommando:

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

   Klyngeklargjøringsprosessen kan ta opptil 30 minutter.

6. For å bekrefte at klyngen ble opprettet, kjør følgende kommando:

   kubectl get nodes

   Utdataene fra den foregående kommandoen for en klynge som ble opprettet, ser ut 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

Opprett et EFS-volum for SageMaker-treningsjobben

I dette tilfellet setter du fart på SageMaker-treningsjobben ved å trene dyplæringsmodeller fra data som allerede er lagret i Amazon EFS. Dette valget har fordelen av å starte treningsjobbene dine direkte fra dataene i Amazon EFS uten behov for dataflytting, noe som resulterer i raskere treningsstarttider.

Vi oppretter et EFS-volum og distribuerer EFS Container Storage Interface (CSI)-driveren. Dette oppnås ved hjelp av et distribusjonsskript som ligger i /eks/deployment/csi/efs innenfor aws-do-eks container.

Dette skriptet forutsetter at du har én EKS-klynge på kontoen din. Sett CLUSTER_NAME= i tilfelle du har mer enn én EKS-klynge.

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

Dette skriptet sørger for et EFS-volum og oppretter monteringsmål for undernettene til klyngen VPC. Deretter distribuerer den EFS CSI-driveren og oppretter efs-sc oppbevaringsklasse og efs-pv vedvarende volum i EKS-klyngen.

Etter vellykket fullføring av skriptet, bør du se utdata 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 ...

Opprett et Amazon S3 VPC-endepunkt

Du bruker en privat VPC som din SageMaker-treningsjobb og EFS-filsystem har tilgang til. For å gi SageMaker-treningsklyngen tilgang til S3-bøttene fra din private VPC, oppretter du et VPC-endepunkt:

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

Du kan nå avslutte aws-do-eks beholderskall og fortsett til neste seksjon:

exit

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

1.2 Distribuer Kubeflow på AWS på Amazon EKS

For å distribuere Kubeflow på Amazon EKS bruker vi aws-do-kubeflow-prosjektet.

1. Klon depotet ved å bruke følgende kommandoer:

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

2. Konfigurer deretter prosjektet:

   ./config.sh

   Dette skriptet åpner prosjektkonfigurasjonsfilen i et tekstredigeringsprogram. Det er viktig for AWS_REGION settes til regionen din klynge er i, så vel som AWS_CLUSTER_NAME for å matche navnet på klyngen du opprettet tidligere. Som standard er konfigurasjonen allerede riktig innstilt, så hvis du ikke trenger å gjøre noen endringer, er det bare å lukke redigeringsprogrammet.

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

   De build.sh skriptet oppretter et Docker-beholderbilde som har alle verktøyene som er nødvendige for å distribuere og administrere Kubeflow på en eksisterende Kubernetes-klynge. De run.sh skriptet starter en container ved å bruke Docker-bildet, og exec.sh-skriptet åpner et kommandoskall inn i beholderen, som vi kan bruke som vårt Kubeflow-administrasjonsmiljø. Du kan bruke ./status.sh skript for å se om aws-do-kubeflow containeren er oppe og går og ./stop.sh og ./run.sh skript for å starte den på nytt etter behov.

3. Etter at du har et skall åpnet i aws-do-eks container, kan du bekrefte at den konfigurerte klyngekonteksten er som forventet:

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

4. For å distribuere Kubeflow på EKS-klyngen, kjør deploy.sh manus:

   ./kubeflow-deploy.sh

   Distribusjonen er vellykket når alle pods i kubeflow-navneområdet går inn i kjøretilstanden. En typisk utgang ser ut 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 å overvåke tilstanden til KubeFlow-podene, i et eget vindu, kan du bruke følgende kommando:

   watch kubectl -n kubeflow get pods

6. Press Ctrl + C når alle pods kjører, kan du eksponere Kubeflow-dashbordet utenfor klyngen ved å kjøre følgende kommando:

   ./kubeflow-expose.sh

Du bør se utdata som ser ut som 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 kommandoen videresender Istio ingress gateway-tjenesten fra klyngen din til din lokale port 8080. For å få tilgang til Kubeflow-dashbordet, gå til http://localhost:8080 og logg på med standard brukerlegitimasjon (bruker@eksempel.com/12341234). Hvis du kjører aws-do-kubeflow container i AWS Cloud9, så kan du velge Forhåndsvisning, velg deretter Forhåndsvisning kjører applikasjon. Hvis du kjører på Docker Desktop, må du kanskje kjøre ./kubeflow-expose.sh skript utenfor aws-do-kubeflow container.

2. Sett opp Kubeflow på AWS-miljøet

For å sette opp Kubeflow på AWS-miljøet, lager vi et EFS-volum og en Jupyter-notisbok.

2.1 Lag et EFS-volum

For å opprette et EFS-volum, fullfør følgende trinn:

• Velg på Kubeflow-dashbordet Volumene i navigasjonsruten.
• Velg Nytt bind.
• Til Navn, Tast inn efs-sc-claim.
• Til Volumstørrelse, Tast inn 10.
• Til Oppbevaringsklasse, velg efs-sc.
• Til Tilgangsmodus, velg ReadWriteOnce.
• Velg Opprett.

2.2 Lag en Jupyter-notisbok

For å opprette en ny notatbok, fullfør følgende trinn:

• Velg på Kubeflow-dashbordet Notatbøker i navigasjonsruten.
• Velg Ny notatbok.
• Til Navn, Tast inn aws-hybrid-nb.
• Til Jupyter Docket Image, velg bildet c9e4w0g3/notebook-servers/jupyter-pytorch:1.11.0-cpu-py38-ubuntu20.04-e3-v1.1 (det siste tilgjengelige Jupyter-pytorch DLC-bildet).
• Til prosessor, Tast inn 1.
• Til Minne, Tast inn 5.
• Til GPU, la være som none.
• Ikke gjør noen endringer i Arbeidsområdevolum seksjon.
• på Datavolumer delen velger Fest eksisterende volum og utvide Eksisterende volumseksjon
• Til Navn, velg efs-sc-claim.
• Til Monteringssti, Tast inn /home/jovyan/efs-sc-claim.
  Dette monterer EFS-volumet til din Jupyter bærbare pod, og du kan se mappen efs-sc-claim i Jupyter lab-grensesnittet. Du lagrer opplæringsdatasettet og opplæringskoden i denne mappen, slik at opplæringsklyngene kan få tilgang til det uten å måtte bygge om beholderbildene for testing.
• Plukke ut Tillat tilgang til Kubeflow Pipelines i konfigurasjonsdelen.
• Velg Start.
  Bekreft at notatboken er opprettet (det kan ta et par minutter).
• På Notatbøker side, velg Koble for å logge på JupyterLab-miljøet.
• På gå meny, velg Klone et depot.
• Til Klone en repo, Tast inn https://github.com/aws-samples/aws-do-kubeflow.
  

3. Kjør distribuert trening

Etter at du har konfigurert Jupyter-notisboken, kan du kjøre hele demoen ved å bruke følgende trinn på høyt nivå fra mappen aws-do-kubeflow/workshop i det klonede depotet:

• PyTorch Distributed Data Parallel (DDP) opplæringsskript: Se PyTorch DDP-treningsskriptet cifar10-distributed-gpu-final.py, som inkluderer et eksempel på konvolusjonelt nevralt nettverk og logikk for å distribuere opplæring på en multi-node CPU og GPU-klynge. (Se 3.1 for detaljer)
• Installer biblioteker: Kjør notatboken 0_initialize_dependencies.ipynb for å initialisere alle avhengigheter. (Se 3.2 for detaljer)
• Kjør distribuert PyTorch jobbtrening på Kubernetes: Kjør notatboken 1_submit_pytorchdist_k8s.ipynb å opprette og sende inn distribuert opplæring på én primær og to arbeiderbeholdere ved å bruke den tilpassede Kubernetes-ressursen PyTorchJob YAML-fil ved bruk av Python-kode. (Se 3.3 for detaljer)
• Opprett en hybrid Kubeflow-rørledning: Kjør notatboken 2_create_pipeline_k8s_sagemaker.ipynb å lage den hybride Kubeflow-rørledningen som kjører distribuert opplæring på enten SageMaker eller Amazon EKS ved å bruke kjøretidsvariabelen training_runtime. (Se 3.4 for detaljer)

Sørg for at du har kjørt notatboken 1_submit_pytorchdist_k8s.ipynb før du starter notatboken 2_create_pipeline_k8s_sagemaker.ipynb.

I de påfølgende avsnittene diskuterer vi hvert av disse trinnene i detalj.

3.1 PyTorch Distributed Data Parallel (DDP) opplæringsskript

Som en del av den distribuerte opplæringen trener vi en klassifiseringsmodell laget av et enkelt konvolusjonelt nevralt nettverk som opererer på CIFAR10-datasettet. Treningsmanuset cifar10-distributed-gpu-final.py inneholder bare åpen kildekode-bibliotekene og er kompatibel for å kjøre både på Kubernetes og SageMaker treningsklynger på enten GPU-enheter eller CPU-forekomster. La oss se på noen viktige aspekter ved opplæringsskriptet før vi kjører notatbokeksemplene våre.

Vi bruker torch.distributed modul, som inneholder PyTorch-støtte og kommunikasjonsprimitiver for multi-prosess parallellitet på tvers av 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 lager en enkel bildeklassifiseringsmodell ved å bruke en kombinasjon av konvolusjon, maks pooling og lineære lag som en relu-aktiveringsfunksjon brukes på i foroverpasset av modelltreningen:

# 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 bruker lommelykten DataLoader som kombinerer datasettet og DistributedSampler (laster et delsett av data på en distribuert måte ved hjelp av torch.nn.parallel.DistributedDataParallel) og gir en enkelt-prosess eller multi-prosess 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 treningsklyngen har GPUer, kjører skriptet opplæringen på CUDA-enheter og enhetsvariabelen inneholder standard CUDA-enhet:

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

Før du kjører distribuert trening med PyTorch DistributedDataParallel for å kjøre distribuert prosessering på flere noder, må du initialisere det distribuerte miljøet ved å ringe init_process_group. Dette initialiseres på hver maskin i treningsklyngen.

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

Vi instansierer klassifiseringsmodellen og kopierer over modellen til målenheten. Hvis distribuert trening er aktivert for å kjøre på flere noder, vil DistributedDataParallel klasse brukes som et innpakningsobjekt rundt modellobjektet, som tillater synkron distribuert trening på tvers av flere maskiner. Inndataene deles på batchdimensjonen og en kopi av modellen er plassert på hver maskin og hver enhet.

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 å kjøre PyTorch-eksemplet med distribuert opplæring. Dette inkluderer Kubeflow Pipelines SDK, Training Operator Python SDK, Python-klient for 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 Kjør distribuert PyTorch jobbtrening på Kubernetes

Notatboken 1_submit_pytorchdist_k8s.ipynb oppretter den tilpassede Kubernetes-ressursen PyTorchJob YAML-filen ved å bruke Kubeflow-trening og Kubernetes-klienten Python SDK. Følgende er noen viktige utdrag fra denne notatboken.

Vi oppretter PyTorchJob YAML med primær- og arbeiderbeholderne 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 sendes til Kubernetes kontrollplan ved hjelp av PyTorchJobClient:

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

pytorch_job_manifest=pytorchjob_client.create(pytorchjob):

Se Kubernetes-treningsloggene

Du kan se treningsloggene enten fra den samme Jupyter-notatboken ved å bruke Python-kode eller fra Kubernetes-klientskallet.

3.4 Opprett en hybrid Kubeflow-rørledning

Notatboken 2_create_pipeline_k8s_sagemaker.ipynb oppretter en hybrid Kubeflow-pipeline basert på betinget kjøretidsvariabel training_runtime, som vist i følgende kode. Notatboken bruker Kubeflow Pipelines SDK og det er gitt et sett med Python-pakker for å spesifisere og kjøre ML arbeidsflyt-pipelines. Som en del av denne SDK-en bruker vi følgende pakker:

• Pakkedekoratoren for domenespesifikk språk (DSL). dsl.pipeline, som dekorerer Python-funksjonene for å returnere en pipeline
• De dsl.Condition pakke, som representerer en gruppe operasjoner som bare kjøres når en bestemt betingelse er oppfylt, for eksempel å sjekke training_runtime verdi 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 distribuert trening ved å bruke to ml.p3.2xlarge instanser.

Etter at rørledningen er definert, kan du kompilere rørledningen til en Argo YAML-spesifikasjon ved å bruke Kubeflow Pipelines SDK-er kfp.compiler pakke. Du kan kjøre denne pipelinen ved å bruke Kubeflow Pipeline SDK-klienten, som kaller opp Pipelines-tjenestens endepunkt og sender inn passende autentiseringshoder rett fra notatboken. 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 feil, kjør !pip install sagemaker og start kjernen på nytt (på Kernel meny, velg Start kjernen på nytt).

Velg Kjør detaljer lenke under den siste cellen for å se Kubeflow-rørledningen.

Gjenta rørledningsopprettingstrinnet med training_runtime='kubernetes' for å teste rørledningen i et Kubernetes-miljø. De training_runtime variabel kan også sendes i CI/CD-pipeline i et produksjonsscenario.

Se Kubeflow-rørledningskjøringsloggene for SageMaker-komponenten

Følgende skjermbilde viser våre pipelinedetaljer for SageMaker-komponenten.

Velg treningsjobbtrinn og på Logger fanen, velg koblingen CloudWatch-logger for å få tilgang til SageMaker-loggene.

Følgende skjermbilde viser CloudWatch-loggene for hver av de to ml.p3.2xlarge-forekomstene.

Velg en av gruppene for å se loggene.

Se Kubeflow-pipeline-kjøringsloggene for Kubeflow PyTorchJob Launcher-komponenten

Følgende skjermbilde viser rørledningsdetaljene for Kubeflow-komponenten vår.

Kjør følgende kommandoer med Kubectl på Kubernetes-klientskallet koblet til Kubernetes-klyngen for å se loggene (erstatt navneområdet og podnavnene dine):

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

4.1 Rydde opp

For å rydde opp i alle ressursene vi opprettet i kontoen, må vi fjerne dem i omvendt rekkefølge.

1. Slett Kubeflow-installasjonen ved å kjøre ./kubeflow-remove.sh i aws-do-kubeflow container. Det første settet med kommandoer er valgfritt og kan brukes i tilfelle du ikke allerede har et kommandoskall i din aws-do-kubeflow beholder åpen.

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

2. Fra aws-do-eks container-mappen, fjern EFS-volumet. Det første settet med kommandoer er valgfritt og kan brukes i tilfelle du ikke allerede har et kommandoskall i din aws-do-eks beholder åpen.

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

   Å slette Amazon EFS er nødvendig for å frigjøre nettverksgrensesnittet knyttet til VPC-en vi opprettet for klyngen vår. Merk at sletting av EFS-volumet ødelegger alle data som er lagret på det.

3. Fra aws-do-eks container, kjør eks-delete.sh skript for å slette klyngen og eventuelle andre ressurser knyttet til den, inkludert VPC:

   cd /eks
   ./eks-delete.sh

Oppsummering

I dette innlegget diskuterte vi noen av de typiske utfordringene ved distribuert modellopplæring og ML-arbeidsflyter. Vi ga en oversikt over Kubeflow på AWS-distribusjon og delte to åpen kildekode-prosjekter (aws-do-eks og aws-do-kubeflow) som forenkler klargjøringen av infrastrukturen og distribusjonen av Kubeflow på den. Til slutt beskrev og demonstrerte vi en hybridarkitektur som gjør at arbeidsbelastninger kan gå sømløst mellom å kjøre på en selvadministrert Kubernetes og fullt administrert SageMaker-infrastruktur. Vi oppfordrer deg til å bruke denne hybridarkitekturen til dine egne brukstilfeller.

Du kan følge AWS Labs-depot for å spore alle AWS-bidrag til Kubeflow. Du finner oss også på Kubeflow #AWS Slack Channel; tilbakemeldingen din der vil hjelpe oss med å prioritere de neste funksjonene for å bidra til Kubeflow-prosjektet.

Spesiell takk til Sree Arasanagatta (programvareutviklingssjef AWS ML) og Suraj Kota (programvareutviklere) for deres støtte til lanseringen av dette innlegget.

Om forfatterne

Kanwaljit Khurmi er en AI/ML-spesialistløsningsarkitekt hos Amazon Web Services. Han jobber med AWS-produktet, ingeniørarbeid og kunder for å gi veiledning og teknisk assistanse som hjelper dem å forbedre verdien av deres hybride ML-løsninger når de bruker AWS. Kanwaljit spesialiserer seg på å hjelpe kunder med containeriserte og maskinlæringsapplikasjoner.

Gautam Kumar er en programvareingeniør med AWS AI Deep Learning. Han har utviklet AWS Deep Learning Containers og AWS Deep Learning AMI. Han brenner for å bygge verktøy og systemer for AI. På fritiden liker han å sykle og lese bøker.

Alex Iankoulski er en fullstack programvare- og infrastrukturarkitekt som liker å gjøre dypt, praktisk arbeid. Han er for tiden en hovedløsningsarkitekt for selvstyrt maskinlæring ved AWS. I sin rolle fokuserer han på å hjelpe kunder med containerisering og orkestrering av ML- og AI-arbeidsmengder på containerdrevne AWS-tjenester. Han er også forfatteren av åpen kildekode Gjør rammeverk og en Docker-kaptein som elsker å bruke containerteknologier for å akselerere innovasjonstakten samtidig som den løser verdens største utfordringer. I løpet av de siste 10 årene har Alex jobbet med å bekjempe klimaendringer, demokratisere AI og ML, gjøre reiser tryggere, helsevesenet bedre og energismartere.