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

Это гостевой пост в блоге, написанный в соавторстве с athenahealth.

athenahealth ведущий поставщик сетевого программного обеспечения и услуг для медицинских групп и систем здравоохранения по всей стране. Его электронные медицинские карты, управление циклом доходов и инструменты взаимодействия с пациентами обеспечивают доступ в любое время и в любом месте, улучшая финансовые результаты для своих клиентов и позволяя клиентам-поставщикам оказывать более качественную помощь.

В области искусственного интеллекта (ИИ) athenahealth использует науку о данных и машинное обучение (МО) для ускорения бизнес-процессов и предоставления рекомендаций, прогнозов и аналитических данных по нескольким службам. От своей первой реализации в автоматизированных службах обработки документов, бесконтактной обработки миллионов документов между поставщиками и пациентами, до более поздней работы с виртуальными помощниками и повышения эффективности цикла доходов, athenahealth продолжает применять ИИ для повышения эффективности, возможностей обслуживания и лучших результатов для поставщиков. и их пациентов.

Этот пост в блоге демонстрирует, как athenahealth использует Kubeflow на AWS (специальный дистрибутив Kubeflow для AWS) для создания и оптимизации сквозного рабочего процесса обработки данных, который сохраняет основные инструменты, оптимизирует операционную эффективность, повышает производительность специалистов по данным и создает основу для более легкого расширения их возможностей машинного обучения.

Kubeflow — это платформа машинного обучения с открытым исходным кодом, предназначенная для простого, переносимого и масштабируемого развертывания рабочих процессов машинного обучения в Kubernetes. Kubeflow достигает этого за счет включения соответствующих инструментов с открытым исходным кодом, которые хорошо интегрируются с Kubernetes. Некоторые из этих проектов включают Argo для оркестровки конвейеров, Istio для сервисной сетки, Jupyter для ноутбуков, Spark, TensorBoard и Katib. Kubeflow Pipelines помогает создавать и развертывать переносимые, масштабируемые рабочие процессы машинного обучения, которые могут включать такие этапы, как извлечение данных, предварительная обработка, обучение модели и оценка модели в виде повторяемых конвейеров.

AWS вносит свой вклад в сообщество Kubeflow с открытым исходным кодом, предоставляя собственный дистрибутив Kubeflow (называемый Kubeflow на AWS), который помогает таким организациям, как athenahealth, создавать высоконадежные, безопасные, переносимые и масштабируемые рабочие процессы машинного обучения с сокращением операционных издержек за счет интеграции с управляемыми сервисами AWS. AWS предоставляет различные варианты развертывания Kubeflow, такие как развертывание с Амазон Когнито, развертывание с Сервис реляционной базы данных Amazon (Amazon RDS) и Простой сервис хранения Amazon (Amazon S3) и ванильное развертывание. Для получения подробной информации об интеграции службы и доступных надстройках для каждого из этих вариантов см. развертывание.

Сегодня Kubeflow на AWS предоставляет четкий путь к использованию Kubeflow, дополненный следующими сервисами AWS:

Многие клиенты AWS используют преимущества дистрибутива Kubeflow на AWS, в том числе athenahealth.

Здесь команда athenahealth MLOps обсуждает проблемы, с которыми они столкнулись, и решения, которые они создали в своем путешествии по Kubeflow.

Проблемы с предыдущей средой ML

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

• Поддержание и рост – Воспроизведение и поддержка сред обучения моделей требовали больше усилий по мере увеличения количества развернутых моделей. Каждый проект содержал подробную документацию, в которой описывалось, как каждый сценарий использовался для создания окончательной модели. Во многих случаях это был сложный процесс, включающий от 5 до 10 сценариев с несколькими выходами каждый. Их нужно было отслеживать вручную с подробными инструкциями о том, как каждый результат будет использоваться в последующих процессах. Поддерживать это со временем стало обременительно. Более того, по мере усложнения проектов увеличивалось и количество инструментов. Например, в большинстве моделей использовались Spark и TensorFlow с графическими процессорами, что требовало большего разнообразия конфигураций среды. Со временем пользователи переключались на более новые версии инструментов в своих средах разработки, но не могли запускать более старые сценарии, когда эти версии становились несовместимыми. Следовательно, поддержание и расширение старых проектов требовало больше инженерного времени и усилий. Кроме того, по мере того как к команде присоединялись новые специалисты по данным, передача знаний и адаптация занимали больше времени, поскольку синхронизация локальных сред включала множество недокументированных зависимостей. Переключение между проектами сталкивалось с теми же проблемами, потому что у каждой модели были свои рабочие процессы.
• Безопасность – Мы серьезно относимся к безопасности и поэтому уделяем первостепенное внимание соблюдению всех договорных, юридических и нормативных обязательств, связанных с машинным обучением и наукой о данных. Данные должны использоваться, храниться и получать к ним доступ определенным образом, и мы внедрили надежные процессы, чтобы гарантировать, что наши методы соответствуют нашим юридическим обязательствам, а также соответствуют передовым отраслевым практикам. До принятия Kubeflow обеспечение того, чтобы данные хранились и предоставлялись к ним определенным образом, требовало регулярной проверки в нескольких разнообразных рабочих процессах. Мы знали, что можем повысить эффективность, объединив эти разнообразные рабочие процессы на единой платформе. Однако эта платформа должна быть достаточно гибкой, чтобы хорошо интегрироваться с нашими стандартизированными инструментами.
• Операционный отдел – Мы также увидели возможность повысить операционную эффективность и управление за счет централизации регистрации и мониторинга рабочих процессов. Поскольку каждая команда разработала свои собственные инструменты, мы собрали эту информацию по каждому рабочему процессу отдельно и объединили их.

Команда специалистов по обработке и анализу данных оценила различные решения для консолидации рабочих процессов. В дополнение к удовлетворению этих требований мы искали решение, которое легко интегрировалось бы с существующей стандартизированной инфраструктурой и инструментами. В качестве решения для рабочего процесса мы выбрали Amazon EKS и Kubeflow на AWS.

Цикл разработки специалистов по данным, включающий Kubeflow

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

В нашем кластере Kubeflow используется средство автоматического масштабирования кластера Karpenter, которое упрощает развертывание ресурсов для специалистов по обработке и анализу данных, поскольку им нужно сосредоточиться только на определении желаемых типов экземпляров, в то время как работа по подготовке выполняется набором предопределенных средств подготовки Karpenter. У нас есть отдельные поставщики для типов инстансов ЦП и ГП, и все инстансы, поддерживаемые Amazon EKS, попадают в одну из этих двух категорий в соответствии с нашей конфигурацией поставщика. Специалисты по данным выбирают типы экземпляров с помощью селекторов узлов, а Карпентер заботится об управлении жизненным циклом узлов.

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

После удовлетворительных результатов специалисты по данным переходят к следующему этапу цикла разработки и превращают свои открытия в надежный конвейер. Они преобразуют код POC в код производственного качества, который работает в масштабе. Чтобы обеспечить соответствие за счет использования утвержденных библиотек, создается контейнер с соответствующим базовым образом Docker. Что касается наших специалистов по данным, мы обнаружили, что предоставление стандартного базового образа Python, TensorFlow и Spark обеспечивает достаточную гибкость для большинства, если не для всех, рабочих нагрузок. Затем они могут использовать Dockerfile своего компонента для дальнейшей настройки своей среды разработки. Затем этот Dockerfile используется процессом CI/CD для создания образа компонентов, который будет использоваться в рабочей среде, что обеспечивает согласованность между средами разработки и рабочей средой.

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

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

Цикл разработки в Kubeflow. Рабочий процесс разработки начинается слева с POC. Завершенная модель развертывается на платформе обслуживания модели athenahealth, работающей на Amazon ECS.

Процесс CI/CD, поддерживающий автоматизированные рабочие процессы

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

В качестве альтернативы, чтобы поддерживать короткий цикл разработки, специалисты по данным могут запускать конвейер со своего локального компьютера, изменяя любые параметры конвейера, с которыми они могут экспериментировать.

Существуют инструменты, обеспечивающие использование по умолчанию указателей ссылок из сборки CI/CD. Если в репозитории есть развертываемый артефакт, логика CI/CD продолжит развертывание артефакта на платформе обслуживания модели athenahealth (служба прогнозирования), работающей на Amazon ECS с АМС Фаргейт. После того, как все эти этапы пройдены, дата-сайентист сливает код в основную ветку. Затем конвейеры и развертываемые артефакты отправляются в производство.

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

Безопасность

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

Безопасность данных

Безопасность данных имеет первостепенное значение для athenahealth. По этой причине мы разрабатываем и поддерживаем инфраструктуру, которая полностью соответствует нормам и стандартам, защищающим безопасность и целостность этих данных.

Чтобы обеспечить соблюдение стандартов соответствия данных, мы предоставляем нашу инфраструктуру AWS в соответствии с нашими корпоративными рекомендациями athenahealth. Двумя основными хранилищами данных являются Amazon RDS для высокомасштабируемых метаданных конвейера и Amazon S3 для артефактов конвейера и моделей. Для Amazon S3 мы гарантируем, что корзины зашифрованы, конечные точки HTTPS принудительно применены, а политики корзин и Управление идентификацией и доступом AWS (IAM) следуют принципу наименьших привилегий при разрешении доступа к данным. Это верно и для данных Amazon RDS: шифрование всегда включено, а группы безопасности и доступ к учетным данным следуют принципу наименьших привилегий. Эта стандартизация гарантирует, что только авторизованные стороны имеют доступ к данным, и этот доступ отслеживается.

В дополнение к этим мерам платформа также подвергается оценке угроз безопасности и постоянным проверкам безопасности и соответствия требованиям.

Мы также учитываем требования к хранению данных посредством управления жизненным циклом данных для всех корзин S3, содержащих конфиденциальные данные. Эта политика автоматически перемещает данные в Амазонка S3 Glacier после 30 дней создания. Исключения из этого управляются с помощью запросов на получение данных и утверждаются или отклоняются в каждом конкретном случае. Это гарантирует, что все рабочие процессы соответствуют политике хранения данных. Это также решает проблему с восстановлением данных, если модель работает плохо и требуется переобучение, или когда необходимо оценить новую модель по сравнению с исторической итерацией набора данных более старой модели.

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

Безопасность кластера с использованием многопользовательской изоляции

Как мы отмечали в предыдущем разделе, специалисты по данным выполняют исследовательский анализ данных, проводят анализ данных и обучают модели машинного обучения. Для распределения ресурсов, организации данных и управления рабочими процессами на основе проектов Kubeflow на AWS обеспечивает изоляцию на основе пространств имен Kubernetes. Эта изоляция работает для взаимодействия с пользовательским интерфейсом Kubeflow; однако он не предоставляет никаких инструментов для управления доступом к API Kubernetes с помощью Kubectl. Это означает, что доступ пользователей можно контролировать через пользовательский интерфейс Kubeflow, но не через API Kubernetes через 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 из нашего пайплайна.

Пример пользовательского интерфейса 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 для маршрутизации журналов pod в Amazon OpenSearch Service.

Это гарантирует, что уровень хранения полностью отделен от уровня вычислений, и тем самым позволяет тестировать изменения во время обновлений версии Kubeflow на совершенно новом кластере EKS. После того, как все тесты пройдены успешно, мы можем просто изменить Amazon Route 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 (Amazon EC2), трудно сравнить, какое огромное значение имеет наличие четко определенных модулей с гарантированной очисткой ресурсов и встроенными механизмами повторных попыток.

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

Между тем, Kubeflow позволяет нам проводить воспроизводимое обучение модели. Даже с одинаковыми данными никакое обучение не дает идентичных моделей, но у нас есть следующая лучшая вещь. С Kubeflow мы точно знаем, какой код и данные использовались для обучения модели. Адаптация значительно улучшилась, потому что каждый шаг в нашем конвейере четко и программно определен. Когда новые специалисты по обработке и анализу данных получают задачу исправить ошибку, им требуется гораздо меньше ручного управления, потому что существует четкая структура того, как выходные данные кода используются между этапами.

Использование Kubeflow также значительно повышает производительность по сравнению с работой на одном экземпляре EC2. Часто при обучении моделей специалистам по данным требуются различные инструменты и оптимизации для предварительной обработки и обучения. Например, предварительная обработка часто выполняется с использованием инструментов распределенной обработки данных, таких как Spark, тогда как обучение часто выполняется с использованием экземпляров графического процессора. С конвейерами Kubeflow они могут указывать разные типы экземпляров для разных этапов конвейера. Это позволяет им использовать мощные экземпляры GPU на одном этапе и парк небольших машин для распределенной обработки на другом этапе. Кроме того, поскольку конвейеры Kubeflow описывают зависимости между этапами, конвейеры могут запускать этапы параллельно.

Наконец, поскольку мы создали процесс добавления арендаторов в кластер, теперь существует более формальный способ регистрации команд в арендаторе кластера. Поскольку мы используем Kubecost для отслеживания затрат в нашем кластере EKS, это позволяет нам относить затраты к одному проекту, а не приписывать затраты на уровне учетной записи, которая включает все проекты по науке о данных. Kubecost представляет отчет о потраченных деньгах на пространство имен, который тесно связан с арендатором или командой, отвечающей за запуск конвейера.

Несмотря на все преимущества, мы бы предостерегали от такой миграции только в том случае, если есть полная поддержка со стороны пользователей. Пользователи, которые потратят время, получат много преимуществ от использования Amazon EKS и Kubernetes, но им придется долго учиться.

Заключение

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

Мы также заложили прочную основу для расширения наших возможностей MLOps и масштабирования количества и размера наших проектов. Например, по мере того, как мы ужесточаем нашу позицию управления в отношении происхождения и отслеживания моделей, мы сократили наше внимание с более чем 15 рабочих процессов до одного. А когда в конце 4 года была обнаружена уязвимость Log2021shell, мы смогли сосредоточиться на одном рабочем процессе и быстро устранить его по мере необходимости (выполнение Реестр Amazon Elastic Container (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 сыграла решающую роль в том, чтобы позволить команде athenahealth MLOps планировать нашу дорожную карту разработки и, следовательно, наше распределение ресурсов и области внимания. , дальше в будущее с большей уверенностью.

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

---

Об авторах

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

Тайлер Калбах является главным членом технического персонала в athenahealth. Тайлер имеет около 7 лет опыта работы в области аналитики, науки о данных, нейронных сетей и разработки приложений машинного обучения в сфере здравоохранения. Он участвовал в разработке нескольких решений для машинного обучения, которые в настоящее время обслуживают производственный трафик. В настоящее время Тайлер работает главным специалистом по данным в инженерной организации athenahealth и с самого начала входил в состав команды, которая создавала новую учебную платформу машинного обучения для athenahealth.

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

Сасанк Вемури является ведущим членом технического персонала в athenahealth. У него есть опыт разработки решений на основе данных в таких областях, как здравоохранение, страхование и биоинформатика. В настоящее время Сасанк занимается проектированием и разработкой платформ машинного обучения и логических выводов на AWS и Kubernetes, которые помогают обучать и развертывать решения машинного обучения в масштабе.

Ану Тумкур является архитектором в athenahealth. Ану имеет более чем двадцатилетний опыт работы в области архитектуры, дизайна и разработки, создавая различные программные продукты в области машинного обучения, облачных операций, больших данных, распределенных конвейеров данных в реальном времени, рекламных технологий, анализа данных, анализа социальных сетей. В настоящее время Ану работает архитектором в отделе разработки продуктов athenahealth в командах, занимающихся платформой машинного обучения и конвейером данных.

Уильям Цен является старшим техническим менеджером в athenahealth. Он имеет более чем 20-летний опыт разработки решений в области ИТ в здравоохранении, распределенных вычислений больших данных, интеллектуальных оптических сетей, систем редактирования видео в режиме реального времени, корпоративного программного обеспечения и группового андеррайтинга в области здравоохранения. В настоящее время Уильям возглавляет две замечательные команды в athenahealth: инженерные группы Machine Learning Operations и DevOps в организации Product Engineering.