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

Версия 1

Наши инженеры по машинному обучению используют Python и R. В нашей инфраструктуре версии 1 использовался настраиваемый формат XML, из которого мы сгенерировали конвейеры фабрики данных Azure (ADF) v1 для копирования входных данных модели в хранилище больших двоичных объектов. Затем модели запускались на наборе виртуальных машин, обслуживаемых нашей командой. Модели считывают входные данные и записывают выходные данные обратно в хранилище BLOB-объектов. Затем конвейеры ADF скопировали выходные данные в Обозреватель данных Azure и в озеро данных распределения данных.

Инфраструктура V1 столкнулась с несколькими проблемами, которые мы намеревались преодолеть:

  • Нет самообслуживания. Подобно тому, как мы реализовали среду самообслуживания для аналитики, мы хотели сделать что-то подобное для машинного обучения, чтобы наши инженеры машинного обучения могли создавать и развертывать модели, не нуждаясь в помощи со стороны команда инженеров данных.
  • Автоматическое масштабирование. У нас есть несколько ресурсоемких моделей, которые запускаются в определенный день месяца, когда становятся доступными наборы данных восходящего направления. На несколько дней нам потребуются большие вычислительные ресурсы. Затем, до следующего месяца, наши вычислительные потребности значительно уменьшатся. Инфраструктура V1 не учитывала это, и у нас всегда было постоянное количество работающих виртуальных машин.
  • Изоляция: мы раньше упаковывали несколько моделей на одной виртуальной машине, поэтому, если одна из них потребляет, например, слишком много оперативной памяти, это повлияет на все другие модели, работающие на той же виртуальной машине. Нам нужна была лучшая изоляция.
  • Различия между средами разработки и разработки. Мы постоянно сталкивались с проблемой, связанной с моделями, которые нормально работали на виртуальной машине инженера машинного обучения, но не работали при переходе в рабочую среду из-за различий в среде, например отсутствия пакетов.

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

Версия 2

Наша инфраструктура версии 2 призвана решить все эти проблемы и предоставить масштабируемую платформу самообслуживания для машинного обучения. Он полностью построен на базе Azure и состоит из следующих компонентов, которые мы обсудим по очереди:

  • Оркестровка
  • Хранение и распространение
  • Вычислить
  • DevOps
  • Мониторинг и оповещение

Оркестровка

Для оркестрации мы используем фабрику данных Azure V2. В отличие от нашей инфраструктуры V1, мы не используем XML для генерации конвейеров, а предоставляем набор шаблонов, которые инженеры машинного обучения могут использовать для создания самих конвейеров. У нас есть dev ADF и производственный.

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

Мы используем CI / CD для ADF: экземпляр ADF разработчика синхронизируется с Git, поэтому инженер машинного обучения может отправить запрос на вытягивание для проверки. После утверждения и объединения с мастером ADF генерирует шаблон ARM, который мы используем для развертывания производственного экземпляра ADF.

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

Хранение и распространение

Что касается хранилища, мы перешли с большого двоичного объекта на Azure Data Lake Storage (ADLS) gen2. ADLS gen2 поддерживается хранилищем BLOB-объектов с парой важных дополнительных функций: иерархическая файловая система и детальный контроль доступа. Оба являются ключевыми для нашей инфраструктуры.

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

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

Вычислить

Вычислительные ресурсы - это наше самое большое обновление по сравнению с V1: вместо обслуживания виртуальных машин мы перешли на Машинное обучение Azure (AML). Это важный переход с IaaS на PaaS, где большая часть инфраструктуры, на поддержку которой мы потратили время, теперь предоставляется и обрабатывается AML.

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

Поскольку конфигурация вычислений выполняется с помощью кода, среда разработки и производственная среда идентичны, а это означает, что мы не сталкиваемся с какими-либо проблемами при переводе модели в рабочую среду. Мы также можем выбрать размер вычислений, который нам нужен, с помощью этой конфигурации, и поэтому модель, которая является более ресурсоемкой, может быть настроена для работы с большим объемом оперативной памяти и / или большей мощности процессора. AML также дает нам статистику использования ЦП и памяти, что помогает нам правильно определять размер вычислений для каждой модели.

DevOps

И ADF, и AML синхронизируются с Git и развертываются через два конвейера выпуска Azure DevOps. Один из них обновляет производственный экземпляр ADF, другой - производственный экземпляр AML. Мы разделили их, потому что обновление кода модели не требует обновлений оркестровки. Это означает, например, что для исправления ошибки модели достаточно развернуть AML, не касаясь фабрики данных.

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

Мониторинг и оповещение

У нас есть производственная система, поэтому мониторинг и оповещение являются ключевыми компонентами. Для мониторинга мы используем Azure Monitor / Log Analytics. ADF управляет запуском всех наших моделей и изначально интегрируется с Azure Monitor, где мы можем определять предупреждения для сбоев конвейера.

Для оповещения мы используем IcM, систему отслеживания инцидентов Microsoft. Сбои конвейера генерируют билеты инцидентов, которые предупреждают инженеров о проблемах с действующим сайтом, как и все производственные службы Azure. Мы также предоставляем панель мониторинга Power BI, на которой заинтересованные стороны могут видеть статус всех моделей.

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

Резюме

В этой статье мы рассмотрели нашу инфраструктуру машинного обучения версии 2, рассмотрев ее ключевые компоненты:

  • Мы используем фабрику данных Azure для управления всем перемещением данных и запуском моделей.
  • Мы используем Azure Data Lake Storage для хранения как входных, так и выходных данных модели, что позволяет нам реализовать детальный контроль доступа и легко распределять данные среди последующих групп.
  • Мы используем машинное обучение Azure для вычислений, которое обеспечивает автоматическое масштабирование и изоляцию для прогонов модели.
  • Мы используем Azure DevOps для развертывания из Git, что обеспечивает самообслуживание и воспроизводимость.
  • Мы используем Azure Monitor для мониторинга и оповещения производственной среды.

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