7 навыков DevOps для операций машинного обучения

Уроки, извлеченные из успешного внедрения MLOps

DevOps встречается с машинным обучением

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

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

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

В недавнем проекте MLOps я был в основном сосредоточен на задачах, связанных с DevOps. Мы достигли наших целей как команда, и я заметил, что инженеры DevOps могут помочь во многих отношениях, не только в технических вопросах, но и в улучшении командной работы. Я не имею в виду, что они важнее других, определенно нет. Но, поскольку DevOps играет перекрестную роль в команде, инженеры могут играть, учиться и делиться знаниями от начала до конца, выступая за гибкие и инженерные передовые методы, одновременно выполняя «операционную» часть MLOps.

Инженеры DevOps, которые хотят работать с операциями машинного обучения, несомненно, будут использовать свой опыт в «обычных» проектах. Однако, как вы увидите дальше, они также должны быть открыты для изучения новых вещей, особенно облачных сервисов для больших данных, анализа данных и машинного обучения/ИИ.

GitLab, Terraform и Google Cloud

Опыт, которым я делюсь в этой статье, связан с реализацией MLOps с помощью GitLab, Terraform и сервисов, управляемых Google Cloud, таких как BigQuery, Облачное хранилище, Магазин функций вершин, Конвейеры вершин, Модели вершин и Конечные точки вершин.

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

Семь навыков

1. Управление исходным кодом

Это элементарный навык для инженеров DevOps. Предполагается, что они знакомы с такими понятиями Git, как ветвление, слияние, перемещение и связанные с ними команды. Кроме того, широко используемые рабочие процессы, такие как Gitflow, GitHub flow, или разработка пользовательских альтернатив, которые лучше соответствуют потребностям команды в управлении исходным кодом.

2. Непрерывная интеграция и доставка

Знание CI/CD также обязательно в наборе инструментов DevOps Engineer. Это будет полезно при разговоре с другими членами команды на различные темы, включая, помимо прочего:

выбор инструментов, отвечающих потребностям команды в области CI/CD, таких как поддержка проверки кода, реестры контейнеров и других артефактов, а также возможность интеграции со сторонними службами (например, облачными провайдерами);
организация репозиториев таким образом, чтобы код обработки данных, код ML/AI, код CI/CD и код, связанный с инфраструктурой, синхронизировались, но управлялись независимо;
разработка кода, подходящего для автоматизированного тестирования;
подготовка кода к запуску в изолированных контейнерах;
разделение невыполненной работы на небольшие задачи, которые будут выполняться непрерывно короткими циклами.

3. Инфраструктура как код

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

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

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

4. Языки программирования

Инженеры DevOps обычно отвечают за инструментирование контейнеров, которые будут запускать автоматические тесты или сквозные конвейеры, созданные инженерами данных или машинного обучения. Хотя от них не требуется глубокое знание языков программирования, используемых их коллегами, полезно знать хотя бы те инструменты CLI, которые чаще всего используются командой (например, pytest для Python). ) и как управляются внешние зависимости (например, отношение между pip install и requirements.txt для Python). Такие знания помогут DevOps Engineers находить элементарные ошибки в конвейере CI/CD и самостоятельно их исправлять.

Инструменты автоматизации сборки и языки сценариев, такие как Make и Bash, помогают команде упростить выполнение повторяющихся задач. Bash является обязательным, и сделайте его где-то между приятным и обязательным для инженеров DevOps, которые стремятся работать с MLOps.

Совет для профессионалов: когда мы работали с Vertex Feature Store на заре его существования, мы поняли, что связанный с ним модуль Terraform был незавершенным, в нем не было возможности создавать некоторые ресурсы. Затем одному из наших инженеров DevOps потребовалось написать скрипт Python, чтобы обойти это ограничение и создать ресурсы с помощью вызовов API. Ваша команда может столкнуться с подобными сценариями при работе с недавно запущенными инструментами. Тем не менее, знакомство с языком программирования, который позволяет вам взаимодействовать со сторонними сервисами, может быть для вас плюсом.

5. Пользовательские контейнеры

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

6. Оркестровка конвейера

Существует два основных типа пайплайнов при работе с MLOps: один для CI/CD и другой для машинного обучения. Конвейеры CI/CD управляются с помощью GitLab CI, GitHub Actions, Circle CI или аналогичных инструментов, которые хорошо документированы, и я не собираюсь повторять свои документы здесь.

С другой стороны, конвейеры машинного обучения могут значительно различаться от проекта к проекту. Обычно они включают в себя такие этапы, как подготовка данных, обучение модели, проверка модели, развертывание модели и мониторинг модели. В отличие от конвейеров CI/CD, запускаемых по событиям Git, конвейеры машинного обучения обычно запускаются на основе календаря (например, ежедневный планировщик). Кстати, в зависимости от используемых технологий каждый шаг может превратиться в подконвейер. Инженер DevOps должен понимать, как команда решает организовать свои конвейеры, чтобы предоставить все необходимые ресурсы для успешного выполнения.

Например, если команда использует Apache Airflow (включая управляемые версии, такие как Cloud Composer или Astronomer), задача DevOps может быть такой же простой, как запуск машинного обучения DAG. Код оркестровки в этом случае обычно создается инженерами данных. Но если инструменты оркестрации, такие как Airflow, не подходят (поверьте мне, такое случается!), DevOps Engineer может отвечать за предоставление похожих на cron планировщиков, бессерверных функций и других компонентов, предназначенных для запуска шаги машинного обучения в соответствующем порядке.

7. Работа в команде

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

Кроме того, имейте в виду, что некоторые товарищи по команде могут быть не знакомы с методами Agile и DevOps.

Тем не менее, работа в команде является важным навыком для инженеров DevOps. Чтобы преуспеть, они должны время от времени ставить себя на место своих товарищей по команде, сопереживать, помнить, что не все на одной волне, когда дело доходит до готовности к автоматизации (особенно в новых командах), и стремиться к эффективному общению.

Подведение итогов

Я знаю, я много чего перерыл. Однако это не означает, что один человек должен овладеть всеми навыками. Напротив, довольно часто можно увидеть, как товарищи по команде делятся своим опытом, чтобы увеличить внедрение DevOps.

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

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

Спасибо, что прочитали!