Створюйте гнучку та масштабовану архітектуру розподіленого навчання за допомогою Kubeflow на AWS і Amazon SageMaker

Перевидано Платоном

читають: 0

У цій публікації ми демонструємо, як Kubeflow на AWS (дистрибутив Kubeflow для AWS), який використовується з Контейнери глибокого навчання AWS та Еластична файлова система Amazon (Amazon EFS) спрощує співпрацю та забезпечує гнучкість у масштабному навчанні моделей глибокого навчання на обох Послуга Amazon Elastic Kubernetes (Amazon EKS) і Amazon SageMaker використання підходу гібридної архітектури.

Розробка машинного навчання (ML) спирається на складні фреймворки та набори інструментів з відкритим кодом, які постійно розвиваються, а також на складні апаратні екосистеми, які постійно розвиваються. Це створює проблему під час масштабування розробки ML до кластера. Контейнери пропонують рішення, оскільки вони можуть повністю інкапсулювати не лише навчальний код, але й увесь стек залежностей аж до апаратних бібліотек. Це забезпечує узгоджене та переносне середовище ML, а також сприяє відтворюваності навчального середовища на кожному окремому вузлі навчального кластера.

Kubernetes — це широко поширена система для автоматизації розгортання інфраструктури, масштабування ресурсів і керування цими контейнерними програмами. Однак Kubernetes не створювався з урахуванням ML, тому науковці з даних можуть здатися неінтуїтивними через велику залежність від файлів специфікації YAML. Немає досвіду Jupyter, і немає багатьох можливостей, специфічних для ML, таких як керування робочим процесом і конвеєрами, а також інших можливостей, які очікують експерти ML, таких як налаштування гіперпараметрів, хостинг моделі та інші. Такі можливості можна створювати, але Kubernetes не створювався для того, щоб це було його основною метою.

Спільнота з відкритим кодом звернула увагу та розробила поверх Kubernetes шар під назвою Kubeflow. Kubeflow має на меті зробити розгортання наскрізних робочих процесів машинного навчання на Kubernetes простим, портативним і масштабованим. Ви можете використовувати Kubeflow для розгортання кращих у своєму класі систем з відкритим кодом для машинного навчання в різних інфраструктурах.

Kubeflow і Kubernetes забезпечують гнучкість і контроль для команд спеціалістів із обробки даних. Проте забезпечення високого рівня використання навчальних кластерів, що працюють у масштабі, зі зниженими операційними витратами все ще є складним завданням.

У цьому дописі показано, як клієнти, які мають локальні обмеження або наявні інвестиції в Kubernetes, можуть вирішити цю проблему, використовуючи Amazon EKS і Kubeflow на AWS для впровадження конвеєра ML для розподіленого навчання на основі підходу самостійного керування та використання повністю керованого SageMaker для оптимізована за витратами, повністю керована і виробнича навчальна інфраструктура. Це включає покрокову реалізацію гібридної розподіленої архітектури навчання, яка дозволяє вибирати між двома підходами під час виконання, забезпечуючи максимальний контроль і гнучкість із суворими потребами для ваших розгортань. Ви побачите, як ви можете продовжувати використовувати бібліотеки з відкритим вихідним кодом у своєму навчальному сценарії глибокого навчання та все ще зробити його сумісним для запуску як на Kubernetes, так і на SageMaker без платформи.

Чим допомагає Kubeflow на AWS і SageMaker?

Моделі нейронних мереж, створені за допомогою інфраструктур глибокого навчання, таких як TensorFlow, PyTorch, MXNet та інші, забезпечують набагато вищу точність завдяки використанню значно більших наборів навчальних даних, особливо у випадках використання комп’ютерного зору та обробки природної мови. Однак із великими наборами навчальних даних навчання моделей глибокого навчання займає більше часу, що зрештою сповільнює час виходу на ринок. Якби ми змогли розширити кластер і скоротити час навчання моделі з тижнів до днів або годин, це могло б мати величезний вплив на продуктивність і швидкість бізнесу.

Amazon EKS допомагає створити керовану площину керування Kubernetes. Ви можете використовувати Amazon EKS для створення великомасштабних навчальних кластерів із екземплярами CPU та GPU, а також використовувати набір інструментів Kubeflow, щоб надати зручні для ML інструменти з відкритим кодом і ввести в дію робочі процеси ML, які є переносними та масштабованими за допомогою Kubeflow Pipelines для підвищення продуктивності вашої команди та скоротити час виходу на ринок.

Однак із цим підходом може виникнути кілька проблем:

Забезпечення максимального використання кластера в групах обробки даних. Наприклад, ви повинні надавати екземпляри графічного процесора на вимогу та забезпечити його високий рівень використання для складних завдань виробничого масштабу, таких як глибоке навчання, і використовувати екземпляри центрального процесора для менш вимогливих завдань, таких як попередня обробка даних.
Забезпечення високої доступності потужних компонентів інфраструктури Kubeflow, включаючи базу даних, сховище та автентифікацію, які розгорнуті на робочому вузлі кластера Kubernetes. Наприклад, площина керування Kubeflow генерує артефакти (такі як екземпляри MySQL, журнали модулів або сховище MinIO), які з часом зростають і потребують змінних обсягів сховища з можливостями постійного моніторингу.
Спільне використання навчального набору даних, коду та обчислювальних середовищ між розробниками, навчальними кластерами та проектами є складним завданням. Наприклад, якщо ви працюєте над власним набором бібліотек, і ці бібліотеки мають сильну взаємозалежність, стає дуже важко ділитися та запускати той самий фрагмент коду між спеціалістами з обробки даних в одній команді. Крім того, кожен тренувальний запуск потребує завантаження навчального набору даних і створення навчального образу з новими змінами коду.

Kubeflow на AWS допомагає вирішити ці проблеми та надає напівкерований продукт Kubeflow корпоративного рівня. За допомогою Kubeflow на AWS ви можете замінити деякі служби рівня керування Kubeflow, як-от база даних, сховище, моніторинг і керування користувачами, на керовані служби AWS, як-от Служба реляційних баз даних Amazon (RDS Amazon), Служба простого зберігання Amazon (Amazon S3), Еластична файлова система Amazon (Amazon EFS), Amazon FSx, Amazon CloudWatch та Амазонка Когніто.

Заміна цих компонентів Kubeflow відокремлює критичні частини площини керування Kubeflow від Kubernetes, забезпечуючи безпечний, масштабований, стійкий і економічно оптимізований дизайн. Цей підхід також звільняє сховище та обчислювальні ресурси з площини даних EKS, які можуть знадобитися таким програмам, як навчання розподілених моделей або сервери ноутбуків користувачів. Kubeflow на AWS також забезпечує власну інтеграцію ноутбуків Jupyter із зображеннями контейнерів глибокого навчання (DLC), які попередньо упаковані та налаштовані за допомогою оптимізованих для AWS фреймворків глибокого навчання, таких як PyTorch і TensorFlow, які дозволяють вам почати писати свій навчальний код одразу, не потребуючи жодних зусиль. із вирішенням залежностей і оптимізацією фреймворку. Крім того, інтеграція Amazon EFS із навчальними кластерами та середовищем розробки дозволяє ділитися кодом і обробленим набором навчальних даних, що дозволяє уникнути створення образу контейнера та завантаження величезних наборів даних після кожної зміни коду. Ці інтеграції з Kubeflow на AWS допомагають пришвидшити час створення моделі та навчання, а також сприяють кращій співпраці завдяки простішому обміну даними та кодом.

Kubeflow на AWS допомагає створити високодоступну та надійну платформу машинного навчання. Ця платформа забезпечує гнучкість для створення та навчання моделей глибокого навчання та надає доступ до багатьох наборів інструментів з відкритим вихідним кодом, аналізу журналів та інтерактивного налагодження для експериментів. Однак досягнення максимального використання ресурсів інфраструктури під час навчання моделей глибокого навчання на сотнях графічних процесорів все ще передбачає багато операційних витрат. Цю проблему можна вирішити за допомогою SageMaker, повністю керованого сервісу, розробленого й оптимізованого для роботи з ефективними та економічно оптимізованими навчальними кластерами, які надаються лише за запитом, масштабуються за потреби та автоматично вимикаються після завершення завдань, таким чином забезпечуючи близько 100 % використання ресурсів. Ви можете інтегрувати SageMaker із Kubeflow Pipelines за допомогою керованих компонентів SageMaker. Це дає змогу запровадити робочі процеси машинного навчання як частину конвеєрів Kubeflow, де ви можете використовувати Kubernetes для локального навчання та SageMaker для навчання масштабу продукту в гібридній архітектурі.

Огляд рішення

Наступна архітектура описує, як ми використовуємо Kubeflow Pipelines для створення та розгортання переносних і масштабованих наскрізних робочих процесів машинного навчання для умовного запуску розподіленого навчання на Kubernetes за допомогою навчання Kubeflow або SageMaker на основі параметра часу виконання.

Навчання Kubeflow — це група операторів Kubernetes, які додають у Kubeflow підтримку розподіленого навчання моделей ML за допомогою різних фреймворків, таких як TensorFlow, PyTorch та інших. pytorch-operator це реалізація Kubeflow Kubernetes спеціальний ресурс (PyTorchJob), щоб запускати розподілені навчальні завдання PyTorch у Kubernetes.

Ми використовуємо компонент PyTorchJob Launcher як частину конвеєра Kubeflow для запуску розподіленого навчання PyTorch на етапі експериментів, коли нам потрібна гнучкість і доступ до всіх основних ресурсів для інтерактивного налагодження та аналізу.

Ми також використовуємо компоненти SageMaker для Kubeflow Pipelines, щоб запускати наше навчання моделі у масштабі виробництва. Це дозволяє нам скористатися потужними функціями SageMaker, такими як повністю керовані служби, розподілені навчальні завдання з максимальним використанням графічного процесора та економічно ефективне навчання через Обчислювальна хмара Amazon Elastic (Amazon EC2) Спотові екземпляри.

У рамках процесу створення робочого циклу ви виконуєте такі кроки (як показано на попередній діаграмі), щоб створити цей конвеєр:

Використовуйте файл маніфесту Kubeflow, щоб створити інформаційну панель Kubeflow і отримати доступ до блокнотів Jupyter із центральної інформаційної панелі Kubeflow.
Використовуйте Kubeflow pipeline SDK для створення та компіляції Kubeflow pipelines за допомогою коду Python. Конвеєрна компіляція перетворює функцію Python на ресурс робочого процесу, який є Argo-сумісним форматом YAML.
Використовуйте клієнт Kubeflow Pipelines SDK, щоб викликати кінцеву точку служби конвеєра для запуску конвеєра.
Конвеєр оцінює умовні змінні часу виконання та вибирає SageMaker або Kubernetes як цільове середовище виконання.
Використовуйте компонент Kubeflow PyTorch Launcher, щоб запускати розподілене навчання у рідному середовищі Kubernetes, або використовуйте компонент SageMaker, щоб відправити навчання на керовану платформу SageMaker.

На наступному малюнку показано компоненти Kubeflow Pipelines, задіяні в архітектурі, які дають нам можливість вибирати між розподіленими середовищами Kubernetes або SageMaker.

Компоненти Kubeflow Pipelines

Випадок використання

Ми використовуємо наведений нижче покроковий підхід для встановлення та запуску сценарію розподіленого навчання за допомогою Amazon EKS і SageMaker за допомогою Kubeflow на AWS.

Передумови

Для цього покрокового керівництва ви повинні мати такі передумови:

An Обліковий запис AWS.
Машина з Docker і Інтерфейс командного рядка AWS (AWS CLI).
За бажанням можна використовувати AWS Cloud9, хмарне інтегроване середовище розробки (IDE), яке дозволяє виконувати всю роботу з веб-браузера. Інструкції з налаштування див Налаштуйте Cloud9 IDE. У вашому середовищі Cloud9 виберіть знак плюс і відкрийте новий термінал.
Створіть роль з ім'ям sagemakerrole. Додайте керовані політики AmazonSageMakerFullAccess та AmazonS3FullAccess щоб надати SageMaker доступ до сегментів S3. Цю роль використовує завдання SageMaker, подане як частина етапу Kubeflow Pipelines.
Переконайтеся, що у вашому обліковому записі є обмеження на тип ресурсу SageMaker Training ml.p3.2xlarge збільшено до 2 використовуючи Консоль сервісних квот

1. Установіть Amazon EKS і Kubeflow на AWS

Ви можете використовувати кілька різних підходів для створення кластера Kubernetes і розгортання Kubeflow. У цій публікації ми зосереджуємось на підході, який, на нашу думку, спрощує процес. Спочатку ми створюємо кластер EKS, а потім розгортаємо на ньому Kubeflow на AWS v1.5. Для кожного з цих завдань ми використовуємо відповідний проект з відкритим кодом, який відповідає принципам Виконайте фреймворк. Замість того, щоб встановлювати набір попередніх умов для кожного завдання, ми створюємо контейнери Docker, які мають усі необхідні інструменти та виконують завдання з контейнерів.

У цьому дописі ми використовуємо Do Framework, який автоматизує розгортання Kubeflow за допомогою Amazon EFS як доповнення. Офіційні варіанти розгортання Kubeflow на AWS для виробничих розгортань див розгортання.

Налаштуйте поточний робочий каталог і AWS CLI

Ми налаштовуємо робочий каталог, щоб ми могли посилатися на нього як на відправну точку для наступних кроків:

export working_dir=$PWD

Ми також налаштовуємо профіль AWS CLI. Для цього вам знадобиться ідентифікатор ключа доступу та секретний ключ доступу Управління ідентифікацією та доступом AWS (Я Є) користувач обліковий запис із правами адміністратора (додайте існуючу керовану політику) і програмним доступом. Перегляньте наступний код:

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 Створіть кластер EKS

Якщо у вас уже є доступний кластер EKS, ви можете перейти до наступного розділу. Для цієї публікації ми використовуємо проект aws-do-eks щоб створити наш кластер.

Спочатку клонуйте проект у вашому робочому каталозі
```
cd ${working_dir}
git clone https://github.com/aws-samples/aws-do-eks
cd aws-do-eks/
```
Потім створіть і запустіть aws-do-eks контейнер:
```
./build.sh
./run.sh
```
Команда build.sh сценарій створює образ контейнера Docker, який містить усі необхідні інструменти та сценарії для надання та роботи кластерів EKS. The run.sh сценарій запускає контейнер за допомогою створеного образу Docker і підтримує його, тому ми можемо використовувати його як середовище керування EKS. Щоб побачити статус свого aws-do-eks контейнер, можна запускати ./status.sh. Якщо контейнер знаходиться в статусі Exited, ви можете використовувати ./start.sh Ви можете запустити сценарій, щоб відкрити контейнер або перезапустити контейнер ./stop.sh подальшою ./run.sh.
Відкрийте оболонку в запущеному режимі aws-do-eks контейнер:
Щоб переглянути конфігурацію кластера EKS для нашого розгортання KubeFlow, виконайте таку команду:
```
vi ./eks-kubeflow.yaml
```
За замовчуванням ця конфігурація створює кластер з іменем eks-kubeflow в us-west-2 Область із шістьма вузлами m5.xlarge. Крім того, шифрування томів EBS не ввімкнено за замовчуванням. Ви можете включити його, додавши "volumeEncrypted: true" до групи вузлів, і він зашифрує за допомогою ключа за замовчуванням. За потреби змініть інші параметри конфігурації.
Щоб створити кластер, виконайте таку команду:
```
export AWS_PROFILE=kubeflow
eksctl create cluster -f ./eks-kubeflow.yaml
```
Процес підготовки кластера може тривати до 30 хвилин.

Щоб переконатися, що кластер створено успішно, виконайте таку команду:

kubectl get nodes

Результат попередньої команди для успішно створеного кластера виглядає так:

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

Створіть том EFS для навчального завдання SageMaker

У цьому випадку використання ви прискорюєте навчання SageMaker, навчаючи моделі глибокого навчання на основі даних, які вже зберігаються в Amazon EFS. Перевага цього вибору полягає в тому, що ваші навчальні завдання запускаються безпосередньо з даних Amazon EFS без необхідності переміщення даних, що призводить до швидшого початку навчання.

Ми створюємо том EFS і розгортаємо драйвер EFS Container Storage Interface (CSI). Це досягається за допомогою сценарію розгортання, розташованого в /eks/deployment/csi/efs в aws-do-eks контейнер

Цей сценарій передбачає, що у вашому обліковому записі є один кластер EKS. встановити CLUSTER_NAME= якщо у вас більше одного кластера EKS.

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

Цей сценарій забезпечує том EFS і створює цілі підключення для підмереж кластера VPC. Потім він розгортає драйвер EFS CSI і створює efs-sc клас зберігання і efs-pv постійний том у кластері EKS.

Після успішного завершення сценарію ви повинні побачити такі результати:

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

Створіть кінцеву точку Amazon S3 VPC

Ви використовуєте приватний VPC, до якого має доступ ваша навчальна робота SageMaker і файлова система EFS. Щоб надати навчальному кластеру SageMaker доступ до сегментів S3 із вашого приватного VPC, ви створюєте кінцеву точку VPC:

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

Тепер ви можете вийти з aws-do-eks оболонку контейнера та перейдіть до наступного розділу:

exit

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

1.2 Розгорніть Kubeflow на AWS на Amazon EKS

Щоб розгорнути Kubeflow на Amazon EKS, ми використовуємо проект aws-do-kubeflow.

Клонуйте репозиторій за допомогою таких команд:

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

Потім налаштуйте проект:
```
./config.sh
```
Цей сценарій відкриває файл конфігурації проекту в текстовому редакторі. Це важливо для AWS_REGION має бути встановлено регіон, у якому знаходиться ваш кластер, а також AWS_CLUSTER_NAME відповідати назві кластера, який ви створили раніше. За замовчуванням ваша конфігурація вже встановлена належним чином, тому, якщо вам не потрібно вносити жодних змін, просто закрийте редактор.
```
./build.sh
./run.sh
./exec.sh
```
Команда build.sh сценарій створює образ контейнера Docker, який містить усі інструменти, необхідні для розгортання та керування Kubeflow на існуючому кластері Kubernetes. The run.sh сценарій запускає контейнер, використовуючи образ Docker, а сценарій exec.sh відкриває командну оболонку в контейнері, яку ми можемо використовувати як середовище керування Kubeflow. Ви можете використовувати ./status.sh сценарій, щоб перевірити, чи є aws-do-kubeflow контейнер запущений і працює, і ./stop.sh та ./run.sh сценарії для перезапуску за потреби.
Після того, як у вас буде відкрита оболонка в aws-do-eks контейнер, ви можете переконатися, що налаштований контекст кластера відповідає очікуванням:
```
root@ip-172-31-43-155:/kubeflow# kubectx
kubeflow@eks-kubeflow.us-west-2.eksctl.io
```

Щоб розгорнути Kubeflow на кластері EKS, запустіть deploy.sh сценарій:

./kubeflow-deploy.sh

Розгортання є успішним, коли всі модулі в просторі імен kubeflow переходять у стан Running. Типовий результат виглядає так:

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

Щоб відстежувати стан модулів KubeFlow, в окремому вікні можна використати таку команду:
```
watch kubectl -n kubeflow get pods
```
прес Ctrl + C коли всі модулі запущені, виведіть інформаційну панель Kubeflow за межі кластера, виконавши таку команду:
```
./kubeflow-expose.sh
```

Ви маєте побачити результат, який виглядає як такий код:

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

Ця команда перенаправляє службу вхідного шлюзу Istio з вашого кластера на локальний порт 8080. Щоб отримати доступ до інформаційної панелі Kubeflow, відвідайте http://localhost:8080 і увійдіть, використовуючи облікові дані користувача за замовчуванням (user@example.com/12341234). Якщо ви запускаєте aws-do-kubeflow контейнер в AWS Cloud9, то ви можете вибрати попередній перегляд, Потім виберіть Попередній перегляд запущеної програми. Якщо ви працюєте на Docker Desktop, вам може знадобитися запустити ./kubeflow-expose.sh сценарій за межами aws-do-kubeflow контейнер

2. Налаштуйте Kubeflow у середовищі AWS

Щоб налаштувати Kubeflow у середовищі AWS, ми створюємо том EFS і блокнот Jupyter.

2.1 Створіть том EFS

Щоб створити том EFS, виконайте такі дії:

Виберіть на інформаційній панелі Kubeflow Обсяги у навігаційній панелі.
Вибрали Новий том.
для ІМ'Я, введіть efs-sc-claim.
для Розмір обсягу, введіть 10.
для Клас зберіганнявиберіть efs-sc.
для Режим доступувиберіть ReadWriteOnce.
Вибирати Створювати.

2.2 Створіть блокнот Jupyter

Щоб створити новий блокнот, виконайте такі дії:

Виберіть на інформаційній панелі Kubeflow Ноутбуки у навігаційній панелі.
Вибирати Новий блокнот.
для ІМ'Я, введіть aws-hybrid-nb.
для Зображення докета Юпітера, виберіть зображення c9e4w0g3/notebook-servers/jupyter-pytorch:1.11.0-cpu-py38-ubuntu20.04-e3-v1.1 (останнє доступне зображення DLC jupyter-pytorch).
для центральний процесор, введіть 1.
для пам'ять, введіть 5.
для Графічні процесори, залишити як ніхто.
Не вносьте жодних змін у Обсяг робочої області .
У Обсяги даних розділ, вибрати Приєднайте наявний том і розгорніть розділ «Існуючий том».
для ІМ'Явиберіть efs-sc-claim.
для Шлях монтування, введіть /home/jovyan/efs-sc-claim.
Таким чином том EFS буде підключено до модуля ноутбука Jupyter, і ви зможете побачити папку efs-sc-claim в інтерфейсі лабораторії Jupyter. Ви зберігаєте навчальний набір даних і навчальний код у цій папці, щоб навчальні кластери мали доступ до них без необхідності перебудовувати образи контейнерів для тестування.
Select Дозволити доступ до Kubeflow Pipelines у розділі Конфігурація.
Вибирати Запуск.
Переконайтеся, що блокнот створено успішно (це може зайняти кілька хвилин).
на Ноутбуки сторінку, виберіть З'єднуватися щоб увійти в середовище JupyterLab.
на Git меню, виберіть Клонуйте репозиторій.
для Клонуйте репо, введіть https://github.com/aws-samples/aws-do-kubeflow.

3. Запустіть розподілене навчання

Після налаштування блокнота Jupyter ви можете запустити всю демонстрацію, виконавши наступні кроки високого рівня з папки aws-do-kubeflow/workshop у клонованому сховищі:

Навчальний сценарій PyTorch Distributed Data Parallel (DDP): Зверніться до навчального сценарію PyTorch DDP cifar10-distributed-gpu-final.py, який містить зразок згорткової нейронної мережі та логіку для розподілу навчання на багатовузловому кластері CPU та GPU. (Детальніше див. 3.1)
Встановити бібліотеки: Запустіть блокнот 0_initialize_dependencies.ipynb щоб ініціалізувати всі залежності. (Детальніше див. 3.2)
Запустіть розподілене робоче навчання PyTorch на Kubernetes: Запустіть блокнот 1_submit_pytorchdist_k8s.ipynb створювати та надсилати розподілене навчання в одному основному та двох робочих контейнерах за допомогою файлу YAML PyTorchJob спеціального ресурсу Kubernetes за допомогою коду Python. (Детальніше див. 3.3)
Створіть гібридний конвеєр Kubeflow: Запустіть блокнот 2_create_pipeline_k8s_sagemaker.ipynb щоб створити гібридний конвеєр Kubeflow, який запускає розподілене навчання на SageMaker або Amazon EKS за допомогою змінної часу виконання training_runtime. (Детальніше див. 3.4)

Переконайтеся, що ви запустили блокнот 1_submit_pytorchdist_k8s.ipynb перед тим, як запустити блокнот 2_create_pipeline_k8s_sagemaker.ipynb.

У наступних розділах ми докладно обговоримо кожен із цих кроків.

3.1 Навчальний скрипт PyTorch Distributed Data Parallel (DDP).

У рамках розподіленого навчання ми тренуємо модель класифікації, створену простою згортковою нейронною мережею, яка працює з набором даних CIFAR10. Сценарій навчання cifar10-distributed-gpu-final.py містить лише бібліотеки з відкритим вихідним кодом і сумісний із запуском у навчальних кластерах Kubernetes і SageMaker на пристроях GPU або екземплярах CPU. Давайте розглянемо кілька важливих аспектів навчального сценарію, перш ніж запускати наші приклади блокнотів.

Ми використовуємо torch.distributed модуль, який містить підтримку PyTorch і комунікаційні примітиви для багатопроцесного паралелізму між вузлами в кластері:

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

Ми створюємо просту модель класифікації зображень, використовуючи комбінацію згорткових, максимального об’єднання та лінійних шарів, до яких застосована функція активації relu під час прямого проходу навчання моделі:

# 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

Ми використовуємо факел DataLoader, який поєднує набір даних і DistributedSampler (завантажує підмножину даних у розподілений спосіб за допомогою torch.nn.parallel.DistributedDataParallel) і надає однопроцесний або багатопроцесний ітератор над даними:

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

Якщо навчальний кластер має графічні процесори, сценарій запускає навчання на пристроях CUDA, а змінна пристрою містить пристрій CUDA за замовчуванням:

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

Перш ніж запускати розподілене навчання за допомогою PyTorch DistributedDataParallel щоб запустити розподілену обробку на кількох вузлах, потрібно ініціалізувати розподілене середовище за допомогою виклику init_process_group. Це ініціалізується на кожній машині навчального кластера.

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

Ми створюємо екземпляр моделі класифікатора та копіюємо модель на цільовий пристрій. Якщо розподілене навчання ввімкнено для запуску на кількох вузлах, DistributedDataParallel клас використовується як обгортка об’єкта моделі, що дозволяє синхронно розподілене навчання на кількох машинах. Вхідні дані розподіляються за розміром партії, і копія моделі розміщується на кожній машині та кожному пристрої.

model = Net().to(device)

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

...

3.2 Встановлення бібліотек

Ви встановите всі необхідні бібліотеки для запуску прикладу розподіленого навчання PyTorch. Це включає Kubeflow Pipelines SDK, Training Operator Python SDK, клієнт Python для Kubernetes і 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 Запустіть розподілене робоче навчання PyTorch на Kubernetes

Зошит 1_submit_pytorchdist_k8s.ipynb створює файл YAML спеціального ресурсу Kubernetes PyTorchJob за допомогою навчання Kubeflow і клієнта Kubernetes Python SDK. Нижче наведено кілька важливих фрагментів із цього блокнота.

Ми створюємо PyTorchJob YAML з основним і робочим контейнерами, як показано в наступному коді:

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

Це надсилається до панелі керування Kubernetes за допомогою PyTorchJobClient:

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

pytorch_job_manifest=pytorchjob_client.create(pytorchjob):

Перегляньте журнали навчання Kubernetes

Ви можете переглядати журнали навчання з того самого блокнота Jupyter за допомогою коду Python або з клієнтської оболонки Kubernetes.

3.4 Створіть гібридний конвеєр Kubeflow

Зошит 2_create_pipeline_k8s_sagemaker.ipynb створює гібридний конвеєр Kubeflow на основі умовної змінної часу виконання training_runtime, як показано в наступному коді. Блокнот використовує Kubeflow Pipelines SDK і він надав набір пакетів Python для визначення та запуску конвеєрів робочого процесу ML. Як частину цього SDK ми використовуємо такі пакети:

Декоратор пакетів доменно-спеціальної мови (DSL). dsl.pipeline, який прикрашає функції Python для повернення конвеєра
Команда dsl.Condition пакет, який представляє групу операцій, які виконуються лише тоді, коли виконується певна умова, наприклад перевірка training_runtime значення як sagemaker or kubernetes

Дивіться наступний код:

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

Ми налаштовуємо розподілене навчання SageMaker за допомогою двох екземплярів ml.p3.2xlarge.

Після того, як конвеєр визначено, ви можете скомпілювати його до специфікації Argo YAML за допомогою Kubeflow Pipelines SDK kfp.compiler пакет. Ви можете запустити цей конвеєр за допомогою клієнта Kubeflow Pipeline SDK, який викликає кінцеву точку служби Pipelines і передає відповідні заголовки автентифікації прямо з блокнота. Перегляньте наступний код:

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

Якщо ви отримаєте sagemaker import помилка, запустіть !pip, установіть sagemaker і перезапустіть ядро (на Ядро меню, виберіть Перезапустіть ядро).

Виберіть Виконати деталі посилання під останньою клітинкою, щоб переглянути конвеєр Kubeflow.

Повторіть крок створення конвеєра з training_runtime='kubernetes' щоб перевірити роботу конвеєра в середовищі Kubernetes. The training_runtime змінну також можна передати у вашому конвеєрі CI/CD у сценарії виробництва.

Перегляньте журнали виконання конвеєра Kubeflow для компонента SageMaker

На наступному знімку екрана показано деталі конвеєра для компонента SageMaker.

Виберіть крок навчання роботи і на Logs виберіть посилання на журнали CloudWatch, щоб отримати доступ до журналів SageMaker.

На наступному знімку екрана показано журнали CloudWatch для кожного з двох екземплярів ml.p3.2xlarge.

Виберіть будь-яку з груп, щоб переглянути журнали.

Перегляньте журнали запуску конвеєра Kubeflow для компонента Kubeflow PyTorchJob Launcher

На наступному знімку екрана показано деталі конвеєра для нашого компонента Kubeflow.

Виконайте наступні команди за допомогою Kubectl у вашій клієнтській оболонці Kubernetes, підключеній до кластера Kubernetes, щоб переглянути журнали (замініть свій простір імен і назви модулів):

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

4.1 Очищення

Щоб очистити всі ресурси, які ми створили в обліковому записі, нам потрібно видалити їх у зворотному порядку.

Видаліть установку Kubeflow, запустивши ./kubeflow-remove.sh в aws-do-kubeflow контейнер. Перший набір команд необов’язковий і може використовуватися, якщо у вас ще немає командної оболонки aws-do-kubeflow відкритий контейнер.
```
cd aws-do-kubeflow
./status.sh
./start.sh
./exec.sh

./kubeflow-remove.sh
```
Від aws-do-eks папку контейнера, видаліть том EFS. Перший набір команд необов’язковий і може бути використаний, якщо у вас ще немає командної оболонки aws-do-eks відкритий контейнер.
```
cd aws-do-eks
./status.sh
./start.sh
./exec.sh

cd /eks/deployment/csi/efs
./delete.sh
./efs-delete.sh
```
Видалення Amazon EFS необхідно, щоб звільнити мережевий інтерфейс, пов’язаний із VPC, який ми створили для нашого кластера. Зауважте, що видалення тому EFS знищує всі дані, які зберігаються на ньому.
Від aws-do-eks контейнер, запустіть eks-delete.sh сценарій для видалення кластера та будь-яких інших пов’язаних із ним ресурсів, включаючи VPC:
```
cd /eks
./eks-delete.sh
```

Підсумки

У цій публікації ми обговорили деякі типові проблеми навчання розподіленої моделі та робочих процесів машинного навчання. Ми надали огляд Kubeflow у дистрибутиві AWS і поділилися двома проектами з відкритим кодом (aws-do-eks та aws-do-kubeflow), які спрощують створення інфраструктури та розгортання Kubeflow на ній. Нарешті, ми описали та продемонстрували гібридну архітектуру, яка дозволяє плавно переходити робочі навантаження між самокерованою інфраструктурою Kubernetes і повністю керованою інфраструктурою SageMaker. Ми заохочуємо вас використовувати цю гібридну архітектуру для власних випадків використання.

Ви можете наслідувати Репозиторій AWS Labs щоб відстежувати всі внески AWS у Kubeflow. Ви також можете знайти нас на Kubeflow #AWS Slack Channel; ваш відгук допоможе нам визначити пріоритети наступних функцій, щоб зробити внесок у проект Kubeflow.

Особлива подяка Шрі Арасанагатта (менеджер з розробки програмного забезпечення AWS ML) і Сурадж Кота (інженер із розробки програмного забезпечення) за їхню підтримку в публікації цієї публікації.

Про авторів

Канвалджит Хурмі є архітектором-спеціалістом з рішень AI/ML у Amazon Web Services. Він працює з продуктом AWS, розробником і клієнтами, щоб надати вказівки та технічну допомогу, допомагаючи їм підвищити цінність своїх гібридних рішень ML під час використання AWS. Kanwaljit спеціалізується на допомозі клієнтам із контейнерними програмами та програмами машинного навчання.

Створюйте гнучку та масштабовану розподілену навчальну архітектуру за допомогою Kubeflow на AWS і Amazon SageMaker PlatoBlockchain Data Intelligence. Вертикальний пошук. Ai. Гаутам Кумар є інженером-програмістом у AWS AI Deep Learning. Він розробив AWS Deep Learning Containers і AWS Deep Learning AMI. Він захоплений створенням інструментів і систем для ШІ. У вільний час любить їздити на велосипеді та читати книги.

Алекс Янкульський є архітектором повного програмного забезпечення та інфраструктури, який любить виконувати глибоку практичну роботу. Зараз він є головним архітектором рішень для самокерованого машинного навчання в AWS. У своїй ролі він зосереджується на допомозі клієнтам із контейнеризацією та оркестровкою робочих навантажень ML та AI у службах AWS на базі контейнерів. Він також є автором відкритого коду Зробіть каркас і капітан Docker, який любить застосовувати контейнерні технології для прискорення темпів інновацій, вирішуючи найбільші світові проблеми. Протягом останніх 10 років Алекс працював над боротьбою зі зміною клімату, демократизацією штучного інтелекту та машинного навчання, роблячи подорожі безпечнішими, охорону здоров’я кращими та енергію розумнішою.

Часова мітка: Вересень 30, 2022Вересень 30, 2022

Часова мітка: Квітень 11, 2023

Створюйте гнучку та масштабовану розподілену навчальну архітектуру за допомогою Kubeflow на AWS і Amazon SageMaker