Створюйте повторювані, безпечні та розширювані наскрізні робочі процеси машинного навчання за допомогою Kubeflow на AWS

Це гостьовий допис у блозі, написаний спільно з athenaealth.

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

У сфері штучного інтелекту (AI) athenaealth використовує науку про дані та машинне навчання (ML), щоб прискорити бізнес-процеси та надати рекомендації, прогнози та статистичні дані для багатьох сервісів. Від свого першого впровадження в автоматизованих службах документообігу, безконтактної обробки мільйонів документів постачальника-пацієнта, до недавньої роботи над віртуальними помічниками та покращенням продуктивності циклу отримання прибутку, athenaealth продовжує застосовувати штучний інтелект для підвищення ефективності, можливостей обслуговування та кращих результатів для постачальників. та їх пацієнтів.

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

Kubeflow — це платформа ML з відкритим вихідним кодом, призначена для того, щоб зробити розгортання робочих процесів ML у Kubernetes простими, портативними та масштабованими. Kubeflow досягає цього, використовуючи відповідні інструменти з відкритим кодом, які добре інтегруються з Kubernetes. Деякі з цих проектів включають Argo для конвеєрної оркестровки, Istio для сервісної сітки, Jupyter для ноутбуків, Spark, TensorBoard і Katib. Kubeflow Pipelines допомагає створювати та розгортати портативні, масштабовані робочі процеси машинного навчання, які можуть включати такі кроки, як вилучення даних, попередня обробка, навчання моделі та оцінка моделі у формі повторюваних конвеєрів.

AWS робить внесок у спільноту Kubeflow із відкритим вихідним кодом, надаючи власний дистрибутив Kubeflow (під назвою Kubeflow на AWS), який допомагає таким організаціям, як athenaealth, створювати високонадійні, безпечні, портативні та масштабовані робочі процеси машинного навчання зі зниженими операційними витратами завдяки інтеграції з керованими службами AWS. AWS надає різні варіанти розгортання Kubeflow, наприклад розгортання за допомогою Амазонка Когніто, розгортання с Служба реляційних баз даних Amazon (Amazon RDS) і Служба простого зберігання Amazon (Amazon S3) і розгортання ваніль. Докладніше про інтеграцію служби та доступні додаткові компоненти для кожного з цих параметрів див розгортання.

Сьогодні Kubeflow на AWS надає чіткий шлях до використання Kubeflow, доповнений такими службами AWS:

Багато клієнтів AWS користуються перевагами Kubeflow у розповсюдженні AWS, зокрема athenahealth.

Тут команда athenaealth MLOps обговорює виклики, з якими вони зіткнулися, і рішення, які вони створили під час своєї подорожі Kubeflow.

Проблеми з попереднім середовищем ML

До того, як ми запровадили Kubeflow на AWS, наші дослідники обробки даних використовували стандартизований набір інструментів і процес, який забезпечував гнучкість технології та робочого процесу, що використовується для навчання певної моделі. Приклади компонентів стандартизованого інструментарію включають API прийому даних, інструменти сканування безпеки, конвеєр CI/CD, створений і підтримуваний іншою командою в межах athenaealth, і загальну платформу обслуговування, створену та підтримувану командою MLOps. Однак у міру того, як наше використання штучного інтелекту та машинного навчання зріло, різноманітність інструментів та інфраструктури, створених для кожної моделі, зростала. Незважаючи на те, що ми все ще змогли підтримувати існуючий процес, ми побачили на горизонті такі проблеми:

• Підтримання та зростання – Відтворення та підтримка моделей навчальних середовищ вимагало більше зусиль, оскільки кількість розгорнутих моделей зростала. Кожен проект підтримував детальну документацію, яка описувала, як кожен сценарій використовувався для створення остаточної моделі. У багатьох випадках це був складний процес, який включав від 5 до 10 сценаріїв з кількома виходами кожен. Їх потрібно було відстежувати вручну з докладними інструкціями про те, як кожен результат використовуватиметься в наступних процесах. Підтримувати це з часом стало громіздким. Крім того, оскільки проекти ставали складнішими, кількість інструментів також збільшувалася. Наприклад, більшість моделей використовували Spark і TensorFlow із графічними процесорами, що вимагало більшої різноманітності конфігурацій середовища. З часом користувачі переходили на новіші версії інструментів у своїх середовищах розробки, але потім не могли запускати старіші сценарії, коли ці версії ставали несумісними. Отже, підтримка та розширення старих проектів потребувало більше часу та зусиль інженерів. Крім того, коли до команди приєдналися нові вчені з обробки даних, передача знань і адаптація займали більше часу, оскільки синхронізація локальних середовищ включала багато незадокументованих залежностей. Перемикання між проектами стикалося з тими ж проблемами, оскільки кожна модель мала свій власний робочий процес.
• Безпека – Ми серйозно ставимося до безпеки, тому надаємо пріоритет дотриманню всіх договірних, юридичних і нормативних зобов’язань, пов’язаних із ML і data science. Дані потрібно використовувати, зберігати та отримувати доступ у певний спосіб, і ми впровадили надійні процеси, щоб забезпечити відповідність наших дій нашим юридичним зобов’язанням, а також найкращим галузевим практикам. До прийняття Kubeflow забезпечення того, що дані зберігаються та доступ до них певним чином передбачало регулярну перевірку в багатьох різноманітних робочих процесах. Ми знали, що можемо підвищити ефективність, об’єднавши ці різноманітні робочі процеси на одній платформі. Однак ця платформа має бути достатньо гнучкою, щоб добре інтегруватися з нашими стандартизованими інструментами.
• операції – Ми також побачили можливість підвищити операційну ефективність і управління шляхом централізації реєстрації та моніторингу робочих процесів. Оскільки кожна команда розробила власні інструменти, ми збирали цю інформацію з кожного робочого процесу окремо та об’єднували її.

Команда Data Science оцінила різні рішення для консолідації робочих процесів. Окрім задоволення цих вимог, ми шукали рішення, яке б бездоганно інтегрувалося з існуючою стандартизованою інфраструктурою та інструментами. Ми вибрали Amazon EKS і Kubeflow на AWS як рішення робочого процесу.

Цикл розробки науковців із обробки даних, що включає Kubeflow

Проект з обробки даних починається з чистого аркуша: ні даних, ні коду, лише бізнес-проблема, яку можна вирішити за допомогою ML. Перше завдання — це перевірка концепції (POC), щоб з’ясувати, чи містять дані достатньо сигналу, щоб модель ML була ефективною для вирішення бізнес-проблеми, починаючи із запиту необробленого набору даних із нашого сховища даних Snowflake. Цей етап є ітераційним, і дослідники даних використовують під час цього процесу пакети Kubernetes або блокноти Kubeflow Jupyter.

Наш кластер Kubeflow використовує інструмент автомасштабування кластера Karpenter, який спрощує розгортання ресурсів для спеціалістів із обробки даних, оскільки їм потрібно лише зосередитися на визначенні бажаних типів екземплярів, тоді як роботу з надання виконує набір попередньо визначених провайдерів Karpenter. У нас є окремі провайдери для типів екземплярів CPU та GPU, і всі екземпляри, які підтримує Amazon EKS, належать до однієї з цих двох категорій відповідно до нашої конфігурації провайдера. Науковці обирають типи екземплярів за допомогою селекторів вузлів, а Карпентер піклується про керування життєвим циклом вузлів.

Після розробки запиту дослідники обробки даних витягують необроблені дані до місця на Amazon S3, а потім запускають блокнот Jupyter з інтерфейсу користувача AWS Kubeflow для вивчення даних. Мета полягає в тому, щоб створити набір функцій, який використовуватиметься для навчання першої моделі. Це дозволяє дослідникам даних визначити, чи достатньо сигналу в даних для задоволення бізнес-потреб клієнта.

Коли результати стають задовільними, дослідники даних переходять до наступного етапу циклу розробки та перетворюють свої відкриття на надійний конвеєр. Вони перетворюють код POC на код продуктивної якості, який працює в масштабі. Щоб забезпечити відповідність через використання затверджених бібліотек, створюється контейнер із відповідним базовим образом Docker. Для наших дослідників даних ми виявили, що надання стандартного базового образу Python, TensorFlow і Spark забезпечує достатню гнучкість для більшості, якщо не всіх, робочих навантажень. Потім вони можуть використовувати Dockerfile свого компонента для подальшого налаштування середовища розробки. Потім цей Dockerfile використовується процесом CI/CD для створення образу компонентів, який використовуватиметься у виробництві, таким чином зберігаючи узгодженість між середовищами розробки та виробництва.

У нас є інструмент, який дає науковцям можливість запускати своє середовище розробки в модулі, що працює на Kubernetes. Коли цей модуль працює, спеціалісти з обробки даних можуть підключити Visual Studio Code IDE безпосередньо до модуля та налагодити свій код моделі. Після успішного виконання коду вони можуть відправити свої зміни в git, і буде створено нове середовище розробки з останніми змінами.

Стандартний конвеєр обробки даних складається з етапів, які включають вилучення, попередню обробку, навчання та оцінку. Кожен етап у конвеєрі відображається як компонент у Kubeflow, який складається з модуля Kubernetes, який виконує команду з певною інформацією, що передається як параметри. Ці параметри можуть бути статичними значеннями або посиланнями на вихідні дані попереднього компонента. Образ Docker, який використовується в модулі, побудований на основі процесу CI/CD. Детальна інформація про цей процес міститься в робочому процесі CI/CD, який обговорюється в наступному розділі.

Цикл розробки на Kubeflow. Робочий процес розробки починається зліва з POC. Готову модель розгортають на платформі обслуговування моделі athenaealth, що працює на Amazon ECS.

Процес CI/CD підтримує автоматизовані робочі процеси

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

Крім того, для підтримки короткого циклу розробки дослідники даних також можуть запустити конвеєр зі своєї локальної машини, змінюючи будь-які параметри конвеєра, з якими вони можуть експериментувати.

Існує інструментарій, який гарантує, що опорні покажчики зі збірки CI/CD використовуються за замовчуванням. Якщо в сховищі є артефакт, який можна розгорнути, логіка CI/CD продовжить розгортати артефакт на платформі обслуговування моделі athenaealth (служба прогнозування), що працює на Amazon ECS за допомогою AWS Fargate. Після того, як усі ці етапи пройдені, фахівець з обробки даних об’єднує код із основною гілкою. Потім конвеєри та артефакти, які можна розгорнути, надходять у виробництво.

Робочий процес розгортання CI/CD. На цій діаграмі описано процес збирання та розгортання Data Science. Процес CI/CD керується Дженкінс.

Безпека

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

Безпека даних

Безпека даних є надзвичайно важливою для athenaealth. З цієї причини ми розробляємо та підтримуємо інфраструктуру, яка повністю відповідає нормам і стандартам, які захищають безпеку та цілісність цих даних.

Щоб забезпечити дотримання стандартів відповідності даних, ми забезпечуємо нашу інфраструктуру AWS відповідно до наших інструкцій athenaealth для підприємств. Двома основними сховищами даних є Amazon RDS для високомасштабованих метаданих конвеєрів і Amazon S3 для конвеєрів і артефактів моделей. Для Amazon S3 ми гарантуємо, що сегменти зашифровані, кінцеві точки HTTPS застосовуються, а політики сегментів і Управління ідентифікацією та доступом AWS Ролі (IAM) дотримуються принципів найменших привілеїв під час надання доступу до даних. Це також стосується даних Amazon RDS: шифрування завжди ввімкнено, а групи безпеки та облікові дані дотримуються принципу найменших привілеїв. Ця стандартизація гарантує, що лише авторизовані сторони мають доступ до даних, і цей доступ відстежується.

На додаток до цих заходів платформа також проходить оцінку загроз безпеці та постійне сканування безпеки та відповідності.

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

Щоб обмежити доступ до Amazon S3 і Amazon RDS із Kubeflow на AWS і Amazon EKS, ми використовуємо IRSA (ролі IAM для облікових записів сервісів), який забезпечує надання дозволів на основі IAM для ресурсів у Kubernetes. Кожен клієнт у Kubeflow має унікальний попередньо створений обліковий запис служби, який ми прив’язуємо до ролі IAM, створеної спеціально для виконання вимог щодо доступу клієнта. Доступ користувачів до орендарів також обмежено за допомогою членства в групі пулів користувачів Amazon Cognito для кожного користувача. Коли користувач проходить автентифікацію в кластері, згенерований маркер містить претензії групи, і Kubernetes RBAC використовує цю інформацію, щоб дозволити або заборонити доступ до певного ресурсу в кластері. Це налаштування пояснюється більш детально в наступному розділі.

Безпека кластера з використанням ізоляції кількох користувачів

Як ми зазначали в попередньому розділі, спеціалісти з обробки даних виконують дослідницький аналіз даних, запускають аналітику даних і навчають моделі машинного навчання. Для розподілу ресурсів, організації даних і керування робочими процесами на основі проектів Kubeflow на AWS забезпечує ізоляцію на основі просторів імен Kubernetes. Ця ізоляція працює для взаємодії з інтерфейсом користувача Kubeflow; однак він не надає інструментів для керування доступом до Kubernetes API за допомогою Kubectl. Це означає, що доступом користувачів можна керувати в інтерфейсі Kubeflow, але не через Kubernetes API через Kubectl.

Архітектура, описана на наступній діаграмі, вирішує цю проблему шляхом уніфікації доступу до проектів у Kubeflow на основі членства в групах. Щоб досягти цього, ми скористалися маніфестами Kubeflow на AWS, які інтегровані з пулами користувачів Amazon Cognito. Крім того, ми використовуємо рольовий контроль доступу Kubernetes (RBAC) для контролю авторизації в кластері. Дозволи користувача надаються на основі членства в групі Amazon Cognito. Ця інформація передається в кластер за допомогою маркера, згенерованого клієнтом OIDC. Цей процес спрощено завдяки вбудованій функції Amazon EKS, яка дозволяє асоціювати постачальників ідентифікаційної інформації OIDC для автентифікації з кластером.

За замовчуванням автентифікація Amazon EKS виконується автентифікатором IAM, який є інструментом, який дає змогу автентифікувати кластер EKS за допомогою облікових даних IAM. Цей метод автентифікації має свої переваги; однак це не підходить для нашого випадку використання, оскільки athenahealth використовує Microsoft Azure Active Directory для служби ідентифікації в усій організації.

Ізоляція простору імен Kubernetes. Науковці даних можуть отримати членство в одній або кількох групах, якщо це необхідно для їх роботи. Доступ перевіряється на регулярній основі та за необхідності видаляється.

Azure Active Directory, будучи службою ідентифікації для всього підприємства, є джерелом правди для контролю доступу користувачів до кластера Kubeflow. Налаштування для цього включає створення корпоративної програми Azure, яка виконує роль принципала служби, і додавання груп для різних клієнтів, яким потрібен доступ до кластера. Це налаштування в Azure відображається в Amazon Cognito шляхом налаштування об’єднаного постачальника ідентифікаційної інформації OIDC, який передає відповідальність за автентифікацію Azure. Доступ до груп Azure контролюється SailPoint IdentityIQ, який надсилає запити на доступ власнику проекту, щоб дозволити або заборонити відповідно. У пулі користувачів Amazon Cognito створено два клієнти додатків: один використовується для налаштування автентифікації для кластера Kubernetes за допомогою постачальника ідентифікаційної інформації OIDC, а інший для захисту автентифікації Kubeflow в інтерфейсі користувача Kubeflow. Ці клієнти налаштовані на передачу групових претензій після автентифікації в кластері, і ці групові претензії використовуються разом із RBAC для налаштування авторизації в кластері.

Прив’язки ролей Kubernetes RBAC налаштовуються між групами та роллю кластера Kubeflow-edit, яка створюється після встановлення Kubeflow у кластері. Це прив’язування ролей гарантує, що будь-який користувач, який взаємодіє з кластером після входу через OIDC, може отримати доступ до просторів імен, на які вони мають дозволи, як визначено в претензіях групи. Хоча це працює для користувачів, які взаємодіють із кластером за допомогою Kubectl, інтерфейс користувача Kubeflow наразі не надає доступу користувачам на основі членства в групах, оскільки він не використовує RBAC. Натомість він використовує ресурс політики авторизації Istio для контролю доступу користувачів. Щоб подолати цю проблему, ми розробили спеціальний контролер, який синхронізує користувачів шляхом опитування груп Amazon Cognito та додає або видаляє відповідні прив’язки ролей для кожного користувача, а не для групи. Це налаштування дозволяє користувачам мати однаковий рівень дозволів під час взаємодії з інтерфейсом Kubeflow і Kubectl.

Оперативна ефективність

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

Ведення журналів і моніторинг

Для журналювання ми використовуємо FluentD, щоб надсилати журнали всіх наших контейнерів Служба Amazon OpenSearch і системні показники до Prometheus. Потім ми використовуємо Kibana та інтерфейс користувача Grafana для пошуку та фільтрації журналів і показників. На наступній діаграмі показано, як ми це налаштовуємо.

Ведення журналів Kubeflow. Ми використовуємо як Grafana UI, так і Kibana для перегляду та перегляду журналів

На наступному скріншоті зображено вигляд Kibana UI з нашого конвеєра.

Зразок перегляду інтерфейсу Kibana. Kibana дозволяє налаштовувати перегляди.

Безпечне оновлення кластера Kubeflow

Підключаючи користувачів до Kubeflow на AWS, ми підтримуємо надійний і послідовний користувацький досвід, водночас дозволяючи команді MLOps залишатися гнучкими, випускаючи та інтегруючи нові функції. На перший погляд, Kustomize виглядає модульним для нас, щоб дозволити працювати й оновлювати один компонент за раз, не впливаючи на інші, таким чином дозволяючи нам додавати нові можливості з мінімальними перешкодами для користувачів. Однак на практиці є сценарії, коли найкращим підходом є просто створити новий кластер Kubernetes, а не застосовувати оновлення на рівні компонентів для існуючих кластерів. Ми знайшли два випадки використання, де було б доцільніше створити повністю нові кластери:

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

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

• Відокремте сховище та обчислювальні ресурси Kubeflow, щоб метадані конвеєра, артефакти конвеєра та дані користувача зберігалися під час деініціалізації старішого кластера
• Інтеграція з Kubeflow у маніфести AWS, щоб під час оновлення версії Kubeflow вносити мінімальні зміни
• Отримайте легкий спосіб відкоту, якщо щось піде не так після оновлення кластера
• Майте простий інтерфейс для просування кластера-кандидата до виробництва

Наступна схема ілюструє цю архітектуру.

Безпечне оновлення кластера Kubeflow. Після успішного тестування Kubeflow Candidate його підвищують до Kubeflow Prod через оновлення Route 53.

Маніфести Kubeflow на AWS попередньо запаковані з інтеграціями Amazon RDS і Amazon S3. Завдяки цим керованим службам, які діють як загальні сховища даних, ми можемо налаштувати синьо-зелену стратегію розгортання. Щоб досягти цього, ми переконалися, що метадані конвеєра зберігаються в Amazon RDS, який працює незалежно від кластера EKS, а журнали та артефакти конвеєра зберігаються в Amazon S3. Окрім метаданих конвеєра та артефактів, ми також налаштували FluentD для маршрутизації журналів модулів до Amazon OpenSearch Service.

Це гарантує, що рівень зберігання повністю відокремлений від рівня обчислень, і таким чином дозволяє тестувати зміни під час оновлення версії Kubeflow на повністю новому кластері EKS. Після успішного проходження всіх тестів ми можемо просто змінити Амазонський маршрут 53 DNS-запис до кластера-кандидата, на якому розміщено Kubeflow. Крім того, ми підтримуємо роботу старого кластера як резервного копіювання протягом кількох днів на випадок, якщо нам знадобиться відкат.

Переваги Amazon EKS і Kubeflow на AWS для нашого конвеєра машинного навчання

Amazon EKS і Kubeflow на пакеті AWS перемістили наш робочий процес розробки на шаблон, який наполегливо заохочує повторюване навчання моделі. Ці інструменти дозволяють нам мати повністю визначені кластери з повністю визначеними орендарями та запускати повністю визначений код.

Багато виграшів від створення цієї платформи є менш кількісними і пов’язані більше з тим, як робочі процеси покращилися як для розробників платформи, так і для користувачів. Наприклад, MinIO було замінено прямим доступом до Amazon S3, що наближає нас до початкових робочих процесів і зменшує кількість сервісів, які ми повинні підтримувати. Ми також можемо використовувати Amazon RDS як бекенд для Kubeflow, що спрощує міграцію між кластерами та дає нам можливість щоночі створювати резервні копії наших конвеєрів.

Ми також визнали корисними покращення інтеграції Kubeflow із керованими сервісами AWS. Наприклад, завдяки Amazon RDS, Amazon S3 і Amazon Cognito, попередньо налаштованим у маніфестах Kubeflow на AWS, ми заощаджуємо час і зусилля на оновленні до новіших дистрибутивів Kubeflow. Коли ми змінювали офіційні маніфести Kubeflow вручну, оновлення до нової версії займало кілька тижнів, від розробки до тестування.

Перехід на Amazon EKS дає нам можливість визначити наш кластер у Kustomize (тепер частина Kubectl) і Terraform. Виявилося, що для роботи на платформах з Kubernetes і Terraform дуже легко працювати, витративши достатньо часу на навчання. Після багатьох ітерацій доступні нам інструменти дозволяють дуже легко виконувати стандартні операції платформи, як-от оновлення компонента або заміна цілого кластера розробки. Порівняно з необробленими роботами Обчислювальна хмара Amazon Elastic (Amazon EC2), важко порівняти, яку величезну різницю має наявність чітко визначених пакетів із вбудованими механізмами гарантованого очищення ресурсів і повторних спроб.

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

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

Використання Kubeflow також значно покращує продуктивність порівняно з роботою на одному екземплярі EC2. Часто під час навчання моделі дослідникам даних потрібні різні інструменти та оптимізація для попередньої обробки та навчання. Наприклад, попередня обробка часто виконується за допомогою розподілених інструментів обробки даних, таких як Spark, тоді як навчання часто виконується за допомогою екземплярів GPU. За допомогою конвеєрів Kubeflow вони можуть визначати різні типи екземплярів для різних етапів конвеєра. Це дозволяє їм використовувати потужні екземпляри GPU на одному етапі та групу менших машин для розподіленої обробки на іншому етапі. Крім того, оскільки конвеєри Kubeflow описують залежності між етапами, конвеєри можуть виконувати етапи паралельно.

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

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

Висновок

Завдяки впровадженню конвеєра Kubeflow на AWS у нашій наскрізній інфраструктурі машинного навчання ми змогли консолідувати та стандартизувати наші робочі процеси обробки даних, зберігаючи при цьому наші основні інструменти (такі як CI/CD і обслуговування моделей). Наші спеціалісти з обробки даних тепер можуть переходити між проектами на основі цього робочого процесу, не витрачаючи на це навчання, як підтримувати абсолютно інший набір інструментів. Для деяких із наших моделей ми також були приємно здивовані швидкістю нового робочого процесу (у п’ять разів швидшого), що дозволило проводити більше навчальних ітерацій і, як наслідок, створювати моделі з кращими прогнозами.

Ми також створили міцну основу для розширення наших можливостей MLOps і масштабування кількості та розміру наших проектів. Наприклад, оскільки ми зміцнюємо свою позицію управління у родоводі моделі та відстеженні, ми зменшили нашу увагу з понад 15 робочих процесів до одного. І коли наприкінці 4 року виявилася вразливість Log2021shell, ми змогли зосередитися на одному робочому процесі та швидко виправити її за потреби (виконуючи Реєстр контейнерів Amazon Elastic (Amazon ECR), оновлюючи Amazon OpenSearch Service, оновлюючи наші інструменти тощо) з мінімальним впливом на поточну роботу дослідників даних. Коли вдосконалення AWS і Kubeflow стануть доступними, ми зможемо включати їх, як вважаємо за потрібне.

Це підводить нас до важливого та заниженого аспекту нашого Kubeflow щодо впровадження AWS. Одним із важливих результатів цієї подорожі є можливість безперешкодно розгортати оновлення та вдосконалення Kubeflow для наших спеціалістів із обробки даних. Хоча ми обговорювали наш підхід до цього раніше, ми також покладаємося на маніфести Kubeflow, надані AWS. Ми розпочали нашу подорож Kubeflow як доказ концепції у 2019 році, до випуску версії 1.0.0. (Наразі ми працюємо над версією 1.4.1, оцінюємо 1.5. AWS уже працює над версією 1.6.) За останні 3 роки було випущено щонайменше шість випусків із значним вмістом. Завдяки своєму дисциплінованому підходу до інтеграції та перевірки цих оновлень і випуску маніфестів за передбачуваним, надійним графіком команда Kubeflow в AWS відіграла вирішальну роль у тому, щоб команда athenaealth MLOps спланувала нашу дорожню карту розвитку, а отже, наш розподіл ресурсів і сфери фокусування. , далі в майбутнє з більшою впевненістю.

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

---

Про авторів

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

Тайлер Калбах є основним членом технічного персоналу athenahealth. Тайлер має приблизно 7 років досвіду в аналітиці, науці про дані, нейронних мережах і розробці програм машинного навчання в сфері охорони здоров’я. Він брав участь у створенні кількох рішень машинного навчання, які зараз обслуговують робочий трафік. Наразі Тайлер працює головним спеціалістом з обробки даних в інженерній організації athenaealth, і був частиною команди, яка створила нову навчальну платформу машинного навчання для athenaealth із самого початку цих зусиль.

Віктор Крилов є основним членом технічного персоналу athenahealth. Віктор є інженером і скрам-майстром, який допомагає дослідникам даних створювати надійні конвеєри швидкого машинного навчання. У Athenaealth він працював над інтерфейсами, клінічними замовленнями, рецептами, плануванням, аналітикою, а тепер машинним навчанням. Він цінує чітко написаний і добре тестований код, але має нездорову одержимість однорядковим кодом. У вільний час він із задоволенням слухає подкасти, гуляючи з собакою.

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

Ану Тумкур є архітектором у athenaealth. Ану має понад два десятиліття архітектури, дизайну та досвіду розробки різних програмних продуктів у сфері машинного навчання, хмарних операцій, великих даних, розподілених каналів даних у реальному часі, рекламних технологій, аналітики даних, аналітики соціальних мереж. Зараз Ану працює архітектором в організації Product Engineering компанії athenaealth у командах Machine Learning Platform і Data Pipeline.

Вільям Цен є старшим інженерним менеджером у athenaealth. Він має більш ніж 20-річний досвід інженерного керівництва розробкою рішень у сферах інформаційних технологій охорони здоров’я, розподілених обчислень із великими даними, інтелектуальних оптичних мереж, систем редагування відео в реальному часі, корпоративного програмного забезпечення та групового страхування охорони здоров’я. Наразі Вільям очолює дві чудові команди в athenaealth: команди Machine Learning Operations і DevOps в організації Product Engineering.