Twórz elastyczne i skalowalne rozproszone architektury szkoleniowe za pomocą Kubeflow na AWS i Amazon SageMaker

W tym poście pokazujemy, jak to zrobić Kubeflow w AWS (dystrybucja Kubeflow specyficzna dla AWS) używana z Kontenery AWS Deep Learning i System plików Amazon Elastic (Amazon EFS) upraszcza współpracę i zapewnia elastyczność w szkoleniu modeli uczenia głębokiego na dużą skalę w obu przypadkach Elastyczna usługa Amazon Kubernetes (Amazon EKS) i Amazon Sage Maker z wykorzystaniem podejścia opartego na architekturze hybrydowej.

Tworzenie uczenia maszynowego (ML) opiera się na złożonych i stale ewoluujących strukturach i zestawach narzędzi typu open source, a także złożonych i stale ewoluujących ekosystemach sprzętowych. Stanowi to wyzwanie podczas skalowania rozwoju ML do klastra. Kontenery oferują rozwiązanie, ponieważ mogą w pełni hermetyzować nie tylko kod szkoleniowy, ale cały stos zależności aż do bibliotek sprzętowych. Zapewnia to spójne i przenośne środowisko ML oraz ułatwia powtarzalność środowiska szkoleniowego na każdym pojedynczym węźle klastra szkoleniowego.

Kubernetes to powszechnie stosowany system do automatyzacji wdrażania infrastruktury, skalowania zasobów i zarządzania tymi aplikacjami kontenerowymi. Jednak Kubernetes nie został zbudowany z myślą o ML, więc może wydawać się sprzeczny z intuicją dla naukowców zajmujących się danymi ze względu na duże uzależnienie od plików specyfikacji YAML. Nie ma środowiska Jupyter i nie ma wielu funkcji specyficznych dla ML, takich jak zarządzanie przepływem pracy i potoki oraz inne możliwości, których oczekują eksperci ML, takie jak dostrajanie hiperparametrów, hosting modeli i inne. Takie możliwości można zbudować, ale Kubernetes nie został zaprojektowany do robienia tego jako jego głównego celu.

Społeczność open-source zauważyła i opracowała warstwę na Kubernetes o nazwie Kubeflow. Kubeflow ma na celu sprawić, by wdrażanie kompleksowych przepływów pracy ML na Kubernetes było proste, przenośne i skalowalne. Możesz użyć Kubeflow, aby wdrożyć najlepsze w swojej klasie systemy open source dla ML w różnych infrastrukturach.

Kubeflow i Kubernetes zapewniają elastyczność i kontrolę zespołom analityków danych. Jednak zapewnienie wysokiego wykorzystania klastrów szkoleniowych działających na dużą skalę przy zmniejszonych kosztach operacyjnych nadal stanowi wyzwanie.

W tym poście pokazano, jak klienci, którzy mają ograniczenia lokalne lub istniejące inwestycje w Kubernetes, mogą sprostać temu wyzwaniu, używając Amazon EKS i Kubeflow na AWS do wdrożenia potoku ML do rozproszonego szkolenia opartego na podejściu samozarządzającym i używając w pełni zarządzanego programu SageMaker do zoptymalizowana pod względem kosztów, w pełni zarządzana infrastruktura szkoleniowa na skalę produkcyjną. Obejmuje to stopniową implementację hybrydowej rozproszonej architektury szkoleniowej, która umożliwia wybór między dwoma podejściami w czasie wykonywania, zapewniając maksymalną kontrolę i elastyczność przy rygorystycznych wymaganiach dotyczących wdrożeń. Zobaczysz, w jaki sposób możesz nadal korzystać z bibliotek typu open source w swoim skrypcie szkolenia głębokiego i nadal zapewniać jego kompatybilność z działaniem zarówno na Kubernetes, jak i SageMaker w sposób niezależny od platformy.

Jak pomaga Kubeflow w AWS i SageMaker?

Modele sieci neuronowych zbudowane z wykorzystaniem platform uczenia głębokiego, takich jak TensorFlow, PyTorch, MXNet i innych, zapewniają znacznie większą dokładność dzięki użyciu znacznie większych zestawów danych szkoleniowych, zwłaszcza w przypadkach użycia wizji komputerowej i przetwarzania języka naturalnego. Jednak w przypadku dużych zestawów danych szkoleniowych trenowanie modeli uczenia głębokiego trwa dłużej, co ostatecznie spowalnia czas wprowadzania na rynek. Gdybyśmy mogli skalować klaster i skrócić czas uczenia modelu z tygodni do dni lub godzin, mogłoby to mieć ogromny wpływ na produktywność i prędkość biznesową.

Amazon EKS pomaga aprowizować zarządzaną płaszczyznę kontroli Kubernetes. Możesz użyć Amazon EKS do tworzenia klastrów szkoleniowych na dużą skalę z instancjami CPU i GPU oraz użyć zestawu narzędzi Kubeflow, aby zapewnić przyjazne dla ML narzędzia typu open source i operacjonalizować przepływy pracy ML, które są przenośne i skalowalne przy użyciu Kubeflow Pipelines w celu poprawy produktywności zespołu i skrócić czas wprowadzania na rynek.

Jednak takie podejście może wiązać się z kilkoma wyzwaniami:

• Zapewnienie maksymalnego wykorzystania klastra w zespołach analityki danych. Na przykład należy udostępniać instancje GPU na żądanie i zapewnić ich wysokie wykorzystanie w przypadku wymagających zadań na skalę produkcyjną, takich jak szkolenie głębokiego uczenia się, oraz używać instancji procesora do mniej wymagających zadań, takich jak wstępne przetwarzanie danych
• Zapewnianie wysokiej dostępności ciężkich składników infrastruktury Kubeflow, w tym bazy danych, magazynu i uwierzytelniania, które są wdrażane w węźle roboczym klastra Kubernetes. Na przykład płaszczyzna sterowania Kubeflow generuje artefakty (takie jak instancje MySQL, logi pod lub magazyn MinIO), które rosną w czasie i wymagają woluminów pamięci masowej o zmiennej wielkości z możliwością ciągłego monitorowania.
• Udostępnianie szkoleniowego zestawu danych, kodu i środowisk obliczeniowych między programistami, klastrami szkoleniowymi i projektami jest trudne. Na przykład, jeśli pracujesz nad własnym zestawem bibliotek, a te biblioteki mają silne współzależności, naprawdę trudno jest udostępniać i uruchamiać ten sam fragment kodu między analitykami danych w tym samym zespole. Ponadto każdy bieg treningowy wymaga pobrania zestawu danych treningowych i zbudowania obrazu treningowego z nowymi zmianami w kodzie.

Kubeflow w AWS pomaga sprostać tym wyzwaniom i zapewnia półzarządzany produkt klasy korporacyjnej Kubeflow. Dzięki Kubeflow w AWS możesz zastąpić niektóre usługi płaszczyzny kontroli Kubeflow, takie jak baza danych, pamięć masowa, monitorowanie i zarządzanie użytkownikami, usługami zarządzanymi przez AWS, takimi jak Usługa relacyjnych baz danych Amazon (Amazon RDS), Usługa Amazon Simple Storage (Amazonka S3), System plików Amazon Elastic (Amazon EFS), Amazona FSx, Amazon Cloud Watch, Amazon Cognito.

Zastąpienie tych komponentów Kubeflow oddziela krytyczne części płaszczyzny sterowania Kubeflow od Kubernetes, zapewniając bezpieczną, skalowalną, elastyczną i zoptymalizowaną pod względem kosztów konstrukcję. Takie podejście zwalnia również zasoby pamięci masowej i obliczeniowe z płaszczyzny danych EKS, które mogą być potrzebne aplikacjom, takim jak uczenie modeli rozproszonych lub serwery notebooków użytkowników. Kubeflow na AWS zapewnia również natywną integrację notatników Jupyter z obrazami Deep Learning Container (DLC), które są wstępnie spakowane i wstępnie skonfigurowane za pomocą zoptymalizowanych pod kątem AWS platform głębokiego uczenia, takich jak PyTorch i TensorFlow, które umożliwiają natychmiastowe rozpoczęcie pisania kodu szkoleniowego bez konieczności angażowania się z rozwiązaniami zależności i optymalizacjami frameworka. Ponadto integracja Amazon EFS z klastrami szkoleniowymi i środowiskiem programistycznym umożliwia udostępnianie kodu i przetworzonego zestawu danych szkoleniowych, co pozwala uniknąć budowania obrazu kontenera i ładowania ogromnych zestawów danych po każdej zmianie kodu. Te integracje z Kubeflow w AWS pomagają przyspieszyć tworzenie modelu i czas szkolenia oraz umożliwiają lepszą współpracę dzięki łatwiejszemu udostępnianiu danych i kodu.

Kubeflow w AWS pomaga zbudować wysoce dostępną i niezawodną platformę ML. Ta platforma zapewnia elastyczność tworzenia i trenowania modeli uczenia głębokiego oraz zapewnia dostęp do wielu zestawów narzędzi typu open source, wgląd w dzienniki oraz interaktywne debugowanie na potrzeby eksperymentów. Jednak osiągnięcie maksymalnego wykorzystania zasobów infrastruktury podczas uczenia modeli uczenia głębokiego na setkach procesorów graficznych nadal wiąże się z wieloma narzutami operacyjnymi. Można temu zaradzić za pomocą programu SageMaker, który jest w pełni zarządzaną usługą zaprojektowaną i zoptymalizowaną do obsługi wydajnych i zoptymalizowanych pod względem kosztów klastrów szkoleniowych, które są udostępniane tylko na żądanie, skalowane w razie potrzeby i wyłączane automatycznie po zakończeniu zadań, zapewniając w ten sposób blisko 100 % utylizacja zasobów. Możesz zintegrować SageMaker z Kubeflow Pipelines za pomocą zarządzanych komponentów SageMaker. Pozwala to na operacjonalizację przepływów pracy ML w ramach potoków Kubeflow, w których można używać Kubernetes do lokalnego szkolenia i SageMaker do szkolenia na skalę produktu w architekturze hybrydowej.

Omówienie rozwiązania

Poniższa architektura opisuje, w jaki sposób używamy Kubeflow Pipelines do tworzenia i wdrażania przenośnych i skalowalnych, kompleksowych przepływów pracy ML, aby warunkowo uruchamiać rozproszone szkolenie na Kubernetes przy użyciu szkolenia Kubeflow lub SageMaker na podstawie parametru środowiska uruchomieniowego.

Szkolenie Kubeflow to grupa operatorów Kubernetes, które dodają do Kubeflow obsługę rozproszonego uczenia modeli ML przy użyciu różnych platform, takich jak TensorFlow, PyTorch i inne. pytorch-operator jest implementacją Kubeflow Kubernetes zasób niestandardowy (PyTorchJob) do uruchamiania rozproszonych zadań szkoleniowych PyTorch na Kubernetes.

Używamy komponentu PyTorchJob Launcher jako części potoku Kubeflow do uruchamiania rozproszonego szkolenia PyTorch w fazie eksperymentowania, gdy potrzebujemy elastyczności i dostępu do wszystkich podstawowych zasobów do interaktywnego debugowania i analizy.

Używamy również komponentów SageMaker dla Kubeflow Pipelines, aby prowadzić nasze szkolenia modelowe na skalę produkcyjną. Pozwala nam to na korzystanie z zaawansowanych funkcji SageMaker, takich jak w pełni zarządzane usługi, rozproszone zadania szkoleniowe z maksymalnym wykorzystaniem procesora graficznego i opłacalne szkolenia dzięki Elastyczna chmura obliczeniowa Amazon (Amazon EC2) Wystąpienia dodatkowe.

W ramach procesu tworzenia przepływu pracy wykonaj następujące kroki (jak pokazano na poprzednim diagramie), aby utworzyć ten potok:

1. Użyj pliku manifestu Kubeflow, aby utworzyć pulpit nawigacyjny Kubeflow i uzyskać dostęp do notatników Jupyter z centralnego pulpitu nawigacyjnego Kubeflow.
2. Użyj zestawu SDK potoku Kubeflow do tworzenia i kompilowania potoków Kubeflow przy użyciu kodu w języku Python. Kompilacja potoku konwertuje funkcję Pythona na zasób przepływu pracy, który jest zgodnym z Argo formatem YAML.
3. Użyj klienta Kubeflow Pipelines SDK, aby wywołać punkt końcowy usługi potoku w celu uruchomienia potoku.
4. Potok ocenia warunkowe zmienne czasu wykonywania i decyduje między SageMaker lub Kubernetes jako docelowym środowiskiem uruchamiania.
5. Użyj komponentu Kubeflow PyTorch Launcher, aby uruchomić rozproszone szkolenia w natywnym środowisku Kubernetes, lub użyj komponentu SageMaker, aby przesłać szkolenie na platformie zarządzanej SageMaker.

Poniższy rysunek przedstawia komponenty Kubeflow Pipelines zaangażowane w architekturę, które zapewniają nam elastyczność wyboru między środowiskami rozproszonymi Kubernetes lub SageMaker.

Przepływ pracy nad przypadkami użycia

Stosujemy następujące podejście krok po kroku, aby zainstalować i uruchomić przypadek użycia dla szkolenia rozproszonego przy użyciu Amazon EKS i SageMaker przy użyciu Kubeflow na AWS.

Wymagania wstępne

W tej instrukcji należy spełnić następujące wymagania wstępne:

• An Konto AWS.
• Maszyna z Dockerem i Interfejs wiersza poleceń AWS (AWS CLI).
• Opcjonalnie możesz użyć Chmura AWS9, zintegrowane środowisko programistyczne (IDE) oparte na chmurze, które umożliwia wykonywanie wszystkich prac z poziomu przeglądarki internetowej. Aby uzyskać instrukcje dotyczące konfiguracji, zobacz Skonfiguruj IDE Cloud9. W swoim środowisku Cloud9 wybierz znak plus i otwórz nowy terminal.
• Utwórz rolę z nazwą sagemakerrole. Dodaj zarządzane zasady AmazonSageMakerFullAccess i AmazonS3FullAccess aby dać SageMakerowi dostęp do zasobników S3. Ta rola jest używana przez zadanie SageMaker przesłane w ramach kroku Kubeflow Pipelines.
• Upewnij się, że Twoje konto ma limit typu zasobów SageMaker Training dla ml.p3.2xlarge zwiększona do 2 za pomocą Konsola limitów usług

1. Zainstaluj Amazon EKS i Kubeflow na AWS

Możesz użyć kilku różnych podejść do zbudowania klastra Kubernetes i wdrożenia Kubeflow. W tym poście skupiamy się na podejściu, które naszym zdaniem upraszcza proces. Najpierw tworzymy klaster EKS, a następnie wdrażamy na nim Kubeflow na AWS v1.5. Do każdego z tych zadań używamy odpowiedniego projektu open-source zgodnego z zasadami Czy Framework. Zamiast instalować zestaw wymagań wstępnych dla każdego zadania, tworzymy kontenery Docker, które mają wszystkie niezbędne narzędzia i wykonują zadania z poziomu kontenerów.

W tym poście używamy Do Framework, który automatyzuje wdrażanie Kubeflow z Amazon EFS jako dodatkiem. Aby zapoznać się z oficjalnymi opcjami wdrażania Kubeflow on AWS dla wdrożeń produkcyjnych, zobacz Rozlokowanie.

Skonfiguruj bieżący katalog roboczy i AWS CLI

Konfigurujemy katalog roboczy, abyśmy mogli odwoływać się do niego jako do punktu wyjścia dla następujących kroków:

export working_dir=$PWD

Konfigurujemy również profil AWS CLI. Aby to zrobić, potrzebujesz identyfikatora klucza dostępu i tajnego klucza dostępu AWS Zarządzanie tożsamością i dostępem (JESTEM) użytkownik konto z uprawnieniami administracyjnymi (dołącz istniejącą zarządzaną politykę) i dostępem programistycznym. Zobacz następujący kod:

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 Utwórz klaster EKS

Jeśli masz już dostępny klaster EKS, możesz przejść do następnej sekcji. W tym poście używamy projekt aws-do-eks do stworzenia naszego klastra.

1. Najpierw sklonuj projekt w swoim katalogu roboczym

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

2. Następnie zbuduj i uruchom aws-do-eks pojemnik:

   ./build.sh
   ./run.sh

   Połączenia build.sh skrypt tworzy obraz kontenera platformy Docker, który zawiera wszystkie niezbędne narzędzia i skrypty do aprowizacji i obsługi klastrów EKS. The run.sh skrypt uruchamia kontener przy użyciu utworzonego obrazu Dockera i utrzymuje go, dzięki czemu możemy go używać jako naszego środowiska zarządzania EKS. Aby zobaczyć status swojego aws-do-eks pojemnik, możesz uruchomić ./status.sh. Jeśli kontener ma status Exited, możesz użyć ./start.sh skrypt do uruchomienia kontenera lub do ponownego uruchomienia kontenera, możesz uruchomić ./stop.sh następnie ./run.sh.

3. Otwórz muszlę w biegu aws-do-eks pojemnik:
4. Aby przejrzeć konfigurację klastra EKS dla naszego wdrożenia KubeFlow, uruchom następujące polecenie:

   vi ./eks-kubeflow.yaml

   Domyślnie ta konfiguracja tworzy klaster o nazwie eks-kubeflow us-west-2 Region z sześcioma m5.xdużymi węzłami. Ponadto szyfrowanie woluminów EBS nie jest domyślnie włączone. Możesz to włączyć, dodając "volumeEncrypted: true" do grupy węzłów i zaszyfruje przy użyciu domyślnego klucza. W razie potrzeby zmodyfikuj inne ustawienia konfiguracji.

5. Aby utworzyć klaster, uruchom następujące polecenie:

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

   Proces udostępniania klastra może potrwać do 30 minut.

6. Aby sprawdzić, czy klaster został pomyślnie utworzony, uruchom następujące polecenie:

   kubectl get nodes

   Dane wyjściowe z poprzedniego polecenia dla klastra, który został pomyślnie utworzony, wyglądają jak następujący kod:

   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

Utwórz wolumin EFS dla zadania szkoleniowego SageMaker

W tym przypadku można przyspieszyć zadanie szkoleniowe SageMaker, trenując modele głębokiego uczenia się na podstawie danych już przechowywanych w Amazon EFS. Ten wybór ma tę zaletę, że bezpośrednio uruchamia zadania szkoleniowe z danych w Amazon EFS bez konieczności przenoszenia danych, co skutkuje szybszym czasem rozpoczęcia szkolenia.

Tworzymy wolumin EFS i wdrażamy sterownik EFS Container Storage Interface (CSI). Odbywa się to za pomocą skryptu wdrażania znajdującego się w /eks/deployment/csi/efs w ciągu aws-do-eks pojemnik.

Ten skrypt zakłada, że ​​masz jeden klaster EKS na swoim koncie. Ustawić CLUSTER_NAME= w przypadku, gdy masz więcej niż jeden klaster EKS.

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

Ten skrypt udostępnia wolumin EFS i tworzy miejsca docelowe instalacji dla podsieci VPC klastra. Następnie wdraża sterownik EFS CSI i tworzy efs-sc klasa przechowywania i efs-pv wolumin stały w klastrze EKS.

Po pomyślnym zakończeniu skryptu powinieneś zobaczyć dane wyjściowe takie jak:

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

Utwórz punkt końcowy Amazon S3 VPC

Korzystasz z prywatnego VPC, do którego mają dostęp Twoje zadanie szkoleniowe SageMaker i system plików EFS. Aby dać klasterowi szkoleniowemu SageMaker dostęp do zasobników S3 z prywatnego VPC, utwórz punkt końcowy VPC:

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

Możesz teraz wyjść z aws-do-eks powłoki kontenera i przejdź do następnej sekcji:

exit

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

1.2 Wdróż Kubeflow w AWS na Amazon EKS

Aby wdrożyć Kubeflow w Amazon EKS, używamy projekt aws-do-kubeflow.

1. Sklonuj repozytorium za pomocą następujących poleceń:

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

2. Następnie skonfiguruj projekt:

   ./config.sh

   Ten skrypt otwiera plik konfiguracyjny projektu w edytorze tekstu. To ważne dla AWS_REGION być ustawionym na region, w którym znajduje się Twój klaster, a także NAZWA_KLASTRA AWS pasujące do nazwy klastra utworzonego wcześniej. Domyślnie twoja konfiguracja jest już poprawnie ustawiona, więc jeśli nie musisz wprowadzać żadnych zmian, po prostu zamknij edytor.

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

   Połączenia build.sh skrypt tworzy obraz kontenera Docker, który zawiera wszystkie narzędzia niezbędne do wdrożenia i zarządzania Kubeflow w istniejącym klastrze Kubernetes. The run.sh skrypt uruchamia kontener, używając obrazu Docker, a skrypt exec.sh otwiera powłokę poleceń w kontenerze, której możemy użyć jako naszego środowiska zarządzania Kubeflow. Możesz użyć ./status.sh skrypt, aby sprawdzić, czy aws-do-kubeflow kontener jest uruchomiony, a ./stop.sh i ./run.sh skrypty, aby zrestartować go w razie potrzeby.

3. Po otwarciu muszli w aws-do-eks kontenera, możesz sprawdzić, czy skonfigurowany kontekst klastra jest zgodny z oczekiwaniami:

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

4. Aby wdrożyć Kubeflow w klastrze EKS, uruchom deploy.sh scenariusz:

   ./kubeflow-deploy.sh

   Wdrożenie zakończy się pomyślnie, gdy wszystkie zasobniki w przestrzeni nazw kubeflow przejdą do stanu Uruchomione. Typowy wynik wygląda jak następujący kod:

   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. Aby monitorować stan zasobników KubeFlow, w osobnym oknie możesz użyć następującego polecenia:

   watch kubectl -n kubeflow get pods

6. Naciśnij przycisk Ctrl + C gdy wszystkie pody są uruchomione, udostępnij pulpit nawigacyjny Kubeflow poza klastrem, uruchamiając następujące polecenie:

   ./kubeflow-expose.sh

Powinieneś zobaczyć dane wyjściowe, które wyglądają jak następujący kod:

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

To polecenie przekierowuje usługę bramy przychodzącej Istio z klastra do lokalnego portu 8080. Aby uzyskać dostęp do pulpitu nawigacyjnego Kubeflow, odwiedź http://localhost:8080 i zaloguj się przy użyciu domyślnych poświadczeń użytkownika (użytkownik@example.com/12341234). Jeśli prowadzisz aws-do-kubeflow kontener w AWS Cloud9, wtedy możesz wybrać Podgląd, A następnie wybierz Podgląd uruchomionej aplikacji. Jeśli korzystasz z platformy Docker Desktop, może być konieczne uruchomienie ./kubeflow-expose.sh skrypt poza aws-do-kubeflow pojemnik.

2. Skonfiguruj Kubeflow w środowisku AWS

Aby skonfigurować Twój Kubeflow w środowisku AWS, tworzymy wolumin EFS i notatnik Jupyter.

2.1 Utwórz wolumin EFS

Aby utworzyć wolumin EFS, wykonaj następujące czynności:

• W panelu Kubeflow wybierz Volumes w okienku nawigacji.
• Wybrałem Nowy tom.
• W razie zamówieenia projektu Imię, wchodzić efs-sc-claim.
• W razie zamówieenia projektu Wielkość objętości, wchodzić 10.
• W razie zamówieenia projektu Klasa pamięciwybierz efs-sc.
• W razie zamówieenia projektu Tryb dostępuwybierz PrzeczytajNapiszRaz.
• Dodaj Stwórz.

2.2 Utwórz notatnik Jupyter

Aby utworzyć nowy notatnik, wykonaj następujące czynności:

• W panelu Kubeflow wybierz Notebooki w okienku nawigacji.
• Dodaj Nowy notatnik.
• W razie zamówieenia projektu Imię, wchodzić aws-hybrid-nb.
• W razie zamówieenia projektu Obraz kwitów Jupyter, wybierz obraz c9e4w0g3/notebook-servers/jupyter-pytorch:1.11.0-cpu-py38-ubuntu20.04-e3-v1.1 (najnowszy dostępny obraz DLC jupyter-pytorch).
• W razie zamówieenia projektu CPU, wchodzić 1.
• W razie zamówieenia projektu Pamięć, wchodzić 5.
• W razie zamówieenia projektu GPU, zostaw jako żaden.
• Nie wprowadzaj żadnych zmian do Objętość obszaru roboczego
• W Woluminy danych Sekcja, wybierz Dołącz istniejący wolumin i rozwiń sekcję Istniejąca objętość
• W razie zamówieenia projektu Imięwybierz efs-sc-claim.
• W razie zamówieenia projektu Ścieżka do montażu, wchodzić /home/jovyan/efs-sc-claim.
  Spowoduje to zamontowanie woluminu EFS do notebooka Jupyter i wyświetlenie folderu efs-sc-claim w interfejsie laboratorium Jupyter. Treningowy zestaw danych i kod treningowy zapisujesz w tym folderze, aby klastry szkoleniowe miały do ​​niego dostęp bez konieczności ponownego kompilowania obrazów kontenerów do testowania.
• Wybierz Zezwól na dostęp do potoków Kubeflow w sekcji Konfiguracja.
• Dodaj Premiera.
  Sprawdź, czy Twój notes został pomyślnie utworzony (może to potrwać kilka minut).
• Na Notebooki wybierz stronę Skontaktuj się aby zalogować się do środowiska JupyterLab.
• Na git menu, wybierz Sklonuj repozytorium.
• W razie zamówieenia projektu Sklonuj repozytorium, wchodzić https://github.com/aws-samples/aws-do-kubeflow.
  

3. Przeprowadź rozproszone szkolenie

Po skonfigurowaniu notatnika Jupyter możesz uruchomić całe demo, wykonując następujące wysokopoziomowe kroki z folderu aws-do-kubeflow/workshop w sklonowanym repozytorium:

• Skrypt treningowy PyTorch Distributed Data Parallel (DDP): Zapoznaj się ze skryptem szkoleniowym PyTorch DDP cifar10-distributed-gpu-final.py, który zawiera przykładową splotową sieć neuronową i logikę do dystrybucji szkoleń w wielowęzłowym klastrze procesora CPU i GPU. (Patrz 3.1, aby uzyskać szczegółowe informacje)
• Zainstaluj biblioteki: Uruchom notatnik 0_initialize_dependencies.ipynb aby zainicjować wszystkie zależności. (Patrz 3.2, aby uzyskać szczegółowe informacje)
• Uruchom rozproszone szkolenie zawodowe PyTorch na Kubernetes: Uruchom notatnik 1_submit_pytorchdist_k8s.ipynb do tworzenia i przesyłania rozproszonych szkoleń na jednym podstawowym i dwóch kontenerach roboczych przy użyciu niestandardowego pliku Kubernetes PyTorchJob YAML przy użyciu kodu Python. (Patrz 3.3, aby uzyskać szczegółowe informacje)
• Utwórz hybrydowy potok Kubeflow: Uruchom notatnik 2_create_pipeline_k8s_sagemaker.ipynb do utworzenia hybrydowego potoku Kubeflow, który uruchamia rozproszone szkolenie w SageMaker lub Amazon EKS przy użyciu zmiennej runtime training_runtime. (Patrz 3.4, aby uzyskać szczegółowe informacje)

Upewnij się, że uruchomiłeś notatnik 1_submit_pytorchdist_k8s.ipynb zanim zaczniesz zeszyt 2_create_pipeline_k8s_sagemaker.ipynb.

W kolejnych sekcjach szczegółowo omawiamy każdy z tych kroków.

3.1 Skrypt szkoleniowy PyTorch Distributed Data Parallel (DDP)

W ramach szkolenia rozproszonego trenujemy model klasyfikacji stworzony przez prostą splotową sieć neuronową działającą na zbiorze danych CIFAR10. Skrypt szkoleniowy cifar10-distributed-gpu-final.py zawiera tylko biblioteki open-source i jest kompatybilny do uruchamiania zarówno w klastrach szkoleniowych Kubernetes, jak i SageMaker na urządzeniach GPU lub instancjach CPU. Przyjrzyjmy się kilku ważnym aspektom skryptu szkoleniowego, zanim uruchomimy nasze przykłady zeszytów.

Używamy torch.distributed moduł, który zawiera obsługę PyTorch i prymitywy komunikacji dla wieloprocesowej równoległości między węzłami w klastrze:

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

Tworzymy prosty model klasyfikacji obrazów, używając kombinacji warstw splotowych, max pooling i liniowych, do których funkcja aktywacji relu jest stosowana w przejściu do przodu szkolenia modelu:

# 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

Używamy latarki DataLoader, która łączy zbiór danych i DistributedSampler (ładuje podzbiór danych w sposób rozproszony za pomocą torch.nn.parallel.DistributedDataParallel) i zapewnia iterator jednoprocesowy lub wieloprocesowy nad danymi:

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

Jeśli klaster szkoleniowy ma procesory GPU, skrypt uruchamia szkolenie na urządzeniach CUDA, a zmienna device przechowuje domyślne urządzenie CUDA:

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

Zanim uruchomisz rozproszone szkolenie przy użyciu PyTorch DistributedDataParallel aby uruchomić przetwarzanie rozproszone na wielu węzłach, musisz zainicjować środowisko rozproszone, wywołując init_process_group. Jest to inicjowane na każdym komputerze klastra szkoleniowego.

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

Tworzymy wystąpienie modelu klasyfikatora i kopiujemy go na urządzenie docelowe. Jeśli szkolenie rozproszone jest włączone w wielu węzłach, DistributedDataParallel class jest używany jako obiekt opakowujący wokół obiektu modelu, co umożliwia synchroniczne trenowanie rozproszone na wielu komputerach. Dane wejściowe są dzielone na wymiar partii, a replika modelu jest umieszczana na każdej maszynie i każdym urządzeniu.

model = Net().to(device)

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

...

3.2 Zainstaluj biblioteki

Zainstalujesz wszystkie niezbędne biblioteki, aby uruchomić przykład szkolenia rozproszonego PyTorch. Obejmuje to Kubeflow Pipelines SDK, Training Operator Python SDK, klient Python dla Kubernetes i 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 Przeprowadź rozproszone szkolenie zawodowe PyTorch na Kubernetes

Notatnik 1_submit_pytorchdist_k8s.ipynb tworzy plik Kubernetes niestandardowego zasobu PyTorchJob YAML przy użyciu szkolenia Kubeflow i pakietu SDK klienta Kubernetes w języku Python. Oto kilka ważnych fragmentów tego notatnika.

Tworzymy PyTorchJob YAML z kontenerem podstawowym i roboczym, jak pokazano w poniższym kodzie:

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

Jest to przesyłane do płaszczyzny kontrolnej Kubernetes za pomocą PyTorchJobClient:

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

pytorch_job_manifest=pytorchjob_client.create(pytorchjob):

Wyświetl dzienniki szkoleniowe Kubernetes

Dzienniki treningowe można przeglądać w tym samym notesie Jupyter przy użyciu kodu w języku Python lub w powłoce klienta Kubernetes.

3.4 Utwórz hybrydowy potok Kubeflow

Notatnik 2_create_pipeline_k8s_sagemaker.ipynb tworzy hybrydowy potok Kubeflow w oparciu o warunkową zmienną runtime training_runtime, jak pokazano w poniższym kodzie. Notatnik wykorzystuje Pakiet SDK potoków Kubeflow i jest dostarczany zestaw pakietów Pythona do określania i uruchamiania potoków przepływu pracy ML. W ramach tego SDK korzystamy z następujących pakietów:

• Dekorator pakietów języka specyficznego dla domeny (DSL) dsl.pipeline, który ozdabia funkcje Pythona w celu zwrócenia potoku
• Połączenia dsl.Condition pakiet, który reprezentuje grupę operacji, które są uruchamiane tylko wtedy, gdy spełniony jest określony warunek, taki jak sprawdzenie training_runtime wartość jako sagemaker or kubernetes

Zobacz następujący kod:

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

Szkolenie rozproszone SageMaker konfigurujemy przy użyciu dwóch instancji ml.p3.2xlarge.

Po zdefiniowaniu potoku możesz skompilować potok do specyfikacji Argo YAML za pomocą pakietu Kubeflow Pipelines SDK kfp.compiler pakiet. Ten potok można uruchomić przy użyciu klienta Kubeflow Pipeline SDK, który wywołuje punkt końcowy usługi Pipelines i przekazuje odpowiednie nagłówki uwierzytelniania bezpośrednio z notesu. Zobacz następujący kod:

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

Jeśli dostaniesz sagemaker import błąd, uruchom !pip install sagemaker i zrestartuj jądro (na Jądro menu, wybierz Uruchom ponownie jądro).

Wybierz Uruchom szczegóły link pod ostatnią komórką, aby wyświetlić potok Kubeflow.

Powtórz krok tworzenia potoku za pomocą training_runtime='kubernetes' aby przetestować potok uruchomiony w środowisku Kubernetes. The training_runtime zmienna może być również przekazywana w potoku CI/CD w scenariuszu produkcyjnym.

Wyświetl dzienniki uruchomienia potoku Kubeflow dla komponentu SageMaker

Poniższy zrzut ekranu pokazuje nasze szczegóły potoku dla komponentu SageMaker.

Wybierz etap szkolenia i na Dzienniki wybierz link Logi CloudWatch, aby uzyskać dostęp do logów SageMaker.

Poniższy zrzut ekranu przedstawia logi CloudWatch dla każdej z dwóch instancji ml.p3.2xlarge.

Wybierz dowolną grupę, aby zobaczyć dzienniki.

Wyświetl dzienniki uruchomienia potoku Kubeflow dla komponentu Kubeflow PyTorchJob Launcher

Poniższy zrzut ekranu przedstawia szczegóły potoku dla naszego komponentu Kubeflow.

Uruchom następujące polecenia za pomocą Kubectl w powłoce klienta Kubernetes połączonej z klastrem Kubernetes, aby zobaczyć logi (zastąp swoją przestrzeń nazw i nazwy pod):

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

4.1 Posprzątaj

Aby wyczyścić wszystkie zasoby, które utworzyliśmy na koncie, musimy je usunąć w odwrotnej kolejności.

1. Usuń instalację Kubeflow, uruchamiając ./kubeflow-remove.sh aws-do-kubeflow pojemnik. Pierwszy zestaw poleceń jest opcjonalny i może być użyty w przypadku, gdy nie masz jeszcze powłoki poleceń w swoim aws-do-kubeflow pojemnik otwarty.

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

2. Z aws-do-eks folderu kontenera, usuń wolumin EFS. Pierwszy zestaw poleceń jest opcjonalny i może być użyty w przypadku, gdy nie masz jeszcze powłoki poleceń w swoim aws-do-eks pojemnik otwarty.

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

   Usunięcie Amazon EFS jest konieczne, aby zwolnić interfejs sieciowy powiązany z utworzonym przez nas VPC dla naszego klastra. Pamiętaj, że usunięcie woluminu EFS powoduje zniszczenie wszystkich danych, które są na nim przechowywane.

3. Z aws-do-eks pojemnik, uruchom eks-delete.sh skrypt usuwający klaster i wszelkie inne powiązane z nim zasoby, w tym VPC:

   cd /eks
   ./eks-delete.sh

Podsumowanie

W tym poście omówiliśmy niektóre typowe wyzwania związane z uczeniem modeli rozproszonych i przepływami pracy ML. Dostarczyliśmy przegląd dystrybucji Kubeflow na AWS i udostępniliśmy dwa projekty open-source (aws-do-eks i aws-do-kubeflow), które upraszczają udostępnianie infrastruktury i wdrażanie na niej Kubeflow. Na koniec opisaliśmy i zademonstrowaliśmy architekturę hybrydową, która umożliwia bezproblemowe przechodzenie obciążeń między uruchamianiem na samodzielnie zarządzanej infrastrukturze Kubernetes a w pełni zarządzaną infrastrukturą SageMaker. Zachęcamy do korzystania z tej hybrydowej architektury do własnych przypadków użycia.

Możesz podążać za Repozytorium AWS Labs do śledzenia wszystkich wkładów AWS do Kubeflow. Możesz nas również znaleźć na Kanał Kubeflow #AWS Slack; Twoja opinia pomoże nam ustalić priorytety dla kolejnych funkcji, które wniosą wkład do projektu Kubeflow.

Specjalne podziękowania dla Sree Arasanagatta (kierownik rozwoju oprogramowania AWS ML) i Suraj Kota (inżynier ds. tworzenia oprogramowania) za wsparcie w przygotowaniu tego postu.

O autorach

Kanwaljit Khurmi jest specjalistą ds. rozwiązań AI/ML w Amazon Web Services. Pracuje z produktem AWS, inżynierią i klientami, aby zapewnić wskazówki i pomoc techniczną, pomagając im poprawić wartość ich hybrydowych rozwiązań ML podczas korzystania z AWS. Kanwaljit specjalizuje się w pomaganiu klientom w aplikacjach kontenerowych i uczących się maszynowo.

Gautama Kumara jest inżynierem oprogramowania z Głębokim Uczeniem AWS AI. Opracował kontenery AWS Deep Learning i AWS Deep Learning AMI. Pasjonuje się budowaniem narzędzi i systemów dla AI. W wolnym czasie lubi jeździć na rowerze i czytać książki.

Aleks Iankoulski jest pełnowymiarowym architektem oprogramowania i infrastruktury, który lubi wykonywać głęboką, praktyczną pracę. Obecnie jest głównym architektem rozwiązań dla samozarządzającego się uczenia maszynowego w AWS. W swojej roli koncentruje się na pomaganiu klientom w konteneryzacji i orkiestracji obciążeń ML i AI w usługach AWS opartych na kontenerach. Jest także autorem open source Czy ramy oraz kapitana Dockera, który uwielbia stosować technologie kontenerowe, aby przyspieszyć tempo innowacji, jednocześnie rozwiązując największe wyzwania świata. W ciągu ostatnich 10 lat Alex pracował nad przeciwdziałaniem zmianom klimatycznym, demokratyzacją sztucznej inteligencji i ML, bezpieczniejszymi podróżami, lepszą opieką zdrowotną i inteligentniejszą energią.