MLOps с Flyte: конвергенция рабочих процессов между машинным обучением и инжинирингом

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

Это кажется легким. Ведь самый сложный этап — построение ML-моделей — дал плодотворный результат. И разве это не должно быть легко, учитывая, насколько хорошо DevOps (операции разработки) превратились в набор методов, позволяющих поставлять программное обеспечение за считанные минуты?

На первый взгляд DevOps кажется лучшим выбором для запуска моделей машинного обучения в производство. Но на самом деле производство машинного обучения — это нечто большее.

DevOps

Мы писали программное обеспечение и создавали приложения в течение очень долгого времени, и почти столько же времени думали о его более широком развертывании. DevOps — это структурированный способ надежного масштабирования и обслуживания программного обеспечения. Типичные практики DevOps включают:

• Непрерывная интеграция (CI): частое слияние изменений кода
• Непрерывная доставка (CD): непрерывное продвижение от разработки к подготовке к производству.
• Инфраструктура как код (IaC): управление инфраструктурой с помощью кода
• Мониторинг и ведение журнала: постоянный мониторинг развертывания
• Коммуникация и сотрудничество: совместная работа в команде, мультиарендность
• Микросервисы: создание приложения как набора небольших сервисов

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

Однако это не так.

В отличие от разработки программного обеспечения, разработка ML имеет несколько направлений работы. Хотя типичные методы DevOps полезны для развертывания моделей, их просто недостаточно.

MLOps — это надмножество DevOps

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

MLOps — это сочетание машинного обучения, DevOps и обработки данных. Вот чем MLOps отличается от DevOps:

• Модели могут ухудшаться со временем. Поскольку модели и данные изменчивы, они требуют постоянных итераций и экспериментов. Разработка программного обеспечения не такая изменчивая и недетерминированная, как модели машинного обучения. Обеспечение того, чтобы модели машинного обучения поднимались по кривой производительности, требует дополнительных усилий.
• Данные могут быть очень сложными. В машинном обучении объем данных может быть огромным. Возможно, его придется брать из нескольких источников.
• Накладные расходы на инфраструктуру и требования к оборудованию значительны. Модели привязаны к более высокой вычислительной и вычислительной мощности. Чаще всего модели машинного обучения должны работать на графических процессорах, и они используют больше памяти, чем разработка программного обеспечения.
• Масштаб операций. Масштабируемость моделей имеет решающее значение для обработки постоянно изменяющихся данных.

При запуске моделей в масштабе нам также придется позаботиться о:

• Переобучение моделей на каденции
• Версии данных и кода
• Качество данных
• Мониторинг и регистрация
• Добавление тестов в CI

Требования к конвейерам машинного обучения

MLOps в целом должен обеспечить:

• Воспроизводимость. Детерминизм пробега. Мы должны быть в состоянии воспроизвести прогон с тем же набором входных данных; это облегчает отладку.
• Возвратность. Если произошел сбой конвейера, мы должны иметь возможность восстановиться после сбоя.
• Надежность. Комплексный подход для обеспечения согласованности конвейера или системы.
• Проверка. Возможность возврата к источнику ошибки в случае сбоя конвейера. Это, в свою очередь, приводит к происхождению данных — пониманию того, как данные трансформируются с течением времени.
• Адаптивность. Динамичность системы машинного обучения. Насколько удобно переключаться между различными моделями машинного обучения внутри пайплайна.
• Удобство обслуживания. Комплексный подход к обслуживанию конвейеров машинного обучения, который включает поддержку итеративной разработки, совместной работы в команде, автоматизации и т. д.

MLOps по-прежнему остается проблемой: Между машинным обучением и инженерией существует большой разрыв. Развертывание моделей — это крепкий орешек, прежде всего из-за утечек из бэкенда в мир данных, над которыми, как ожидается, будут ломать голову специалисты по данным.

На первый взгляд может показаться, что задача специалистов по данным — решать все проблемы, связанные с MLOps. Однако неразумно ожидать, что они будут знать о низкоуровневой инфраструктуре.

Мы должны разделить интересы группы разработчиков платформы/инфраструктуры и группы пользователей.

Знакомьтесь, Флайт!

Flyte — это инструмент автоматизации рабочих процессов с учетом данных и машинного обучения, созданный на основе Kubernetes. Цель Flyte — предоставить воспроизводимую, инкрементальную, итеративную и расширяемую платформу автоматизации рабочих процессов как таковую. a-service (PaaS) для любой организации.

Ниже перечислены функции Flyte, которые направлены на решение задач MLOps за счет объединения рабочих процессов между машинным обучением и проектированием:

Примечание. SDK для Flytekit (инструмента, с помощью которого вы можете писать код, совместимый с Flyte) доступны на Python, Java и Scala. В этой статье приводятся фрагменты кода, использующие Python SDK.

1/Разделение задач между платформами и командами пользователей. Непосредственной задачей MLOps является внедрение платформы абстрагирования инфраструктуры и автоматизации рабочих процессов, которая может разделить обязанности между платформой и пользователями. В то же время он должен объединять команды на основе единой платформы.

Flyte отлично подходит для разделения задач и совместной работы команд.

2/Развивайтесь поэтапно и постоянно итерируйте. Модель машинного обучения необходимо периодически переобучать (а иногда и обновлять), поскольку данные являются переменными; для этого требуется непрерывная интеграция и доставка на место.

Flyte поддерживает пошаговую и итеративную разработку кода локально и на производственных установках (с той же легкостью, что и при локальном запуске). Продвижение кода с локального на промежуточное и производственное можно легко выполнить с помощью настройки CI/CD, такой как GitHub Actions. Flyte также поставляется с родным планировщиком, который помогает регулярно запускать конвейеры и следить за тем, чтобы они не устаревали.

3/ Инфраструктура как код (IaC). Модели машинного обучения в значительной степени зависят от графических процессоров, и их может потребоваться масштабировать до нескольких графических процессоров, если данные огромны или обучение требует интенсивных вычислений.

Flyte предлагает декларативный подход «инфраструктура как код» (IaC) для доступа к таким ресурсам, как процессоры, графические процессоры и память.

@task(limits=Resources(cpu="2", mem="150Mi"))
def pay_multiplier(df: pandas.DataFrame, scalar: int) -> pandas.DataFrame:
    df["col"] = 2 * df["col"]
    return df

@task — это полностью независимая исполнительная единица и первоклассный объект Flyte. Класс Resources принимает cpu, gpu, mem, storage и ephemeral_storage.

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

Flyte поставляется с тремя интересными функциями для повторного выполнения, а именно: кеширование, повторная попытка и восстановление.

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

@task(cache=True, retries=2)
def pay_multiplier(df: pandas.DataFrame, scalar: int) -> pandas.DataFrame:
    df["col"] = 2 * df["col"]
    return df

"cache" можно установить в значение True, чтобы кэшировать выходные данные @task. Количество повторных попыток — целое число.

5/Мультитенантность. Модели могут использоваться или обрабатываться несколькими командами внутри организации. Один конвейер машинного обучения может состоять из нескольких компонентов, каждый из которых назначается команде. Члены команды должны иметь возможность делиться своим кодом и сотрудничать с другими командами, когда в этом возникает необходимость.

Как нативная платформа Kubernetes, Flyte с самого начала является многопользовательской.

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

Во Flyte весь @workflow (сущность Flyte, которая фиксирует зависимости между задачами) имеет версии, и все задачи и рабочие процессы неизменяемы.

7/Параллелизм. Выполнение кода машинного обучения требует больше времени, чем обычная работа по разработке программного обеспечения. Следовательно, важно запускать код параллельно, когда это возможно.

Flyte определяет, могут ли два узла работать параллельно, что означает меньшее время ожидания для пользователей, чтобы получить свои результаты.

8/Проверка во время компиляции. Вместо того, чтобы перехватывать ошибки во время выполнения, лучше перехватывать ошибки во время компиляции, потому что машинное обучение требует значительных вычислительных ресурсов и времени.

Процесс сериализации и регистрации Flyte имеет множество проверок и тестов, таких как принудительное применение типов, доступных пользователям изначально.

9/Происхождение данных. При появлении ошибки должен быть механизм возврата к источнику ошибки. Более того, пользователь должен иметь возможность понимать промежуточные данные (входные и выходные данные) в каждый момент времени.

Flyte — это информационная платформа. Он понимает данные во всех отношениях.

10/БОНУС: Контрольные точки внутри задачи. Контрольные точки — важная функция, которую следует включить при обучении моделей машинного обучения, поскольку обучение стоит дорого. Контрольные точки могут быть полезны: хранение моментальных снимков модели до тех пор, пока текущее состояние не позволит вам продолжить последующие выполнения из состояния сбоя.

Flyte предоставляет функцию создания контрольных точек внутри задачи, которую можно использовать из @task. Эта функция поддерживает использование спотовых инстансов AWS или вытесняемых инстансов GCP для снижения затрат.

Как начать использовать Flyte для конвейеров машинного обучения

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

Вот хронологический обзор того, как вы можете перенести существующие конвейеры ML на Flyte, что предполагает сотрудничество между командами пользователей и платформы для создания консолидированного решения. Это не универсальное решение, но оно включает в себя некоторые передовые методы.

Предположим

Команда пользователей = специалисты по данным, инженеры по машинному обучению/данным

Команда платформы = инженеры по инфраструктуре, инженеры DevOps

Написать задание машинного обучения

Команда: Пользователь

Первым шагом к созданию конвейера машинного обучения является написание задания (или @task в соответствии с терминологией Flyte). Задание может быть заданием по обучению, заданием по предварительной обработке данных или искровым заданием. Если у команды пользователей есть код для его реализации, им придется преобразовать его в совместимый с Flyte код, чтобы иметь возможность запускать его на серверной части Flyte. (Это требует небольшого рефакторинга.) Если задача взаимодействует с инструментом или внешней службой, группа пользователей может просмотреть поддерживаемые подключаемые модули, прежде чем внедрять код с нуля.

Запускать локально

Команда: Пользователь

Несмотря на то, что код написан в соответствии с Flyte DSL (предметно-ориентированным языком), важно, чтобы команда пользователей могла запускать код локально. Flyte поддерживает локальное выполнение из коробки. После того, как команда создаст рабочие процессы, совместимые с Flyte, она может запустить код локально, как если бы вы запускали файл Python.

Масштабируйте задание

Команда: Пользователь

В зависимости от того, насколько ресурсоемкими являются задачи, группе пользователей может потребоваться настроить ресурсы для их запуска в рабочей среде. Поскольку Flyte предлагает декларативный подход IaC, команда может использовать ручки для установки требуемого CPU, GPU и mem.

Создайте воронку

Команда: Пользователь

Соедините все задания/задачи вместе, чтобы создать конвейер/рабочий процесс.

Протестируйте конвейер локально

Команда: Пользователь

Запустите код локально, чтобы проверить вывод.

Настройте локальную среду Flyte

Команда: Пользователь

Перед тем, как команда пользователей протестирует код в производственной среде, полезно протестировать его на простой установке Flyte. Руководство по началу работы должно помочь команде настроить кластер Kubernetes на своих локальных машинах и запустить рабочие процессы на серверной части Flyte. Kubernetes может напугать специалистов по данным; тем не менее, учитывая, что Docker, платформа виртуализации на уровне ОС, установлена, менее трех минут потребуется менее трех минут, чтобы запустить рабочие процессы Flyte на серверной части.

Настройка Flyte

Команда: Платформа

Настройка Flyte в производственной среде включает в себя настройку базы данных, хранилища объектов, аутентификации и так далее. Это можно сделать в локальной среде или в облаке — будь то AWS, GCP, Azure или любой другой облачный сервис. Руководство по развертыванию в документации Flyte должно помочь в настройке готового к работе бэкэнда Flyte с централизованно управляемой инфраструктурой. Команда платформы напрямую взаимодействует с Flyte, чтобы убедиться, что производственная среда работает должным образом, а команда пользователей работает с данными и моделями.

Настройка DevOps

Команда: Платформа

Чтобы автоматизировать процесс упаковки кода и его регистрации в серверной части Flyte для запуска конвейера в масштабе, важно внедрить некоторые методы DevOps.

После того, как пользовательская команда создаст конвейер машинного обучения, код необходимо упаковать и зарегистрировать в серверной части Flyte. Это может оказаться сложным процессом, если его нужно выполнять для каждого изменения кода или зависимости. Вот как Lyft примерно обрабатывает 1+ миллион рабочих процессов Flyte:

• Каждый раз, когда команда пользователей создает новый запрос на вытягивание (PR), контейнер Docker, фиксирующий зависимости, создается из PR, а также регистрируются задачи и рабочие процессы, которые будут использовать образ Docker при запуске.
• Если зависимости изменяются пользовательской командой — скажем, когда должна быть установлена ​​новая библиотека — PR снова безопасно создает контейнер.
• Прямые изменения кода используют быструю регистрацию: код регистрируется на серверной части Flyte без создания образа Docker.
• Команда пользователей может запускать зарегистрированные задачи и рабочие процессы на серверной части Flyte (при тестировании через PR допустим, что домен — разработка).
• После объединения PR с основной/основной ветвью задачи и рабочие процессы переводятся в рабочий домен. Затем группа пользователей может имитировать развертывание с помощью конвейера развертывания.
• На каждом этапе развертывания задачи и рабочие процессы регистрируются в Flyte с определенным доменом (например, разработка, подготовка и производство).
• Журналы и метрики автоматически отслеживаются для производственных развертываний.

Как управлять версиями задач и рабочих процессов Flyte в процессе регистрации? Версии задач можно определять с помощью GIT-SHA или хэша всего артефакта кода. Для рабочих процессов можно управлять версиями с помощью GIT-SHA содержащего репозитория.

Выполнение конвейера по запросу

Команда: Пользователь

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

Планирование рабочих процессов

Команда: Пользователь

Расписания можно создавать изнутри кода с помощью LaunchPlan — плана выполнения рабочих процессов.

Получить результаты

Команда: Пользователь

Команда пользователей может получить промежуточные или окончательные результаты конвейера из ноутбука Jupyter с помощью FlyteRemote или из интерфейса командной строки с помощью Flytectl или просмотреть их через пользовательский интерфейс.

Техническое обслуживание

Команда: Платформа

Техническое обслуживание включает в себя периодическое обновление компонентов Flyte и обеспечение работоспособности серверной части Flyte.

Все процессы вместе дают четкую картину того, как можно легко реализовать MLOps с помощью Flyte.

Конвергенция рабочих процессов между машинным обучением и проектированием — давняя проблема, которую нам нужно решить сейчас. Мы считаем, что Flyte устраняет разрыв между ними и добавляет гораздо больше ML в инженерную дисциплину. Flyte стремится объединить специалистов по данным, инженеров машинного обучения и разработчиков платформ на одной платформе, установив четкие границы интерфейса.

Если Flyte вас заинтересовал, загляните на наш GitHub, изучите нашу документацию и присоединитесь к нашему Slack!

Первоначально опубликовано на https://mlops.community 26 мая 2022 г.