Когда мы работали над Content Cues, одним из продуктов машинного обучения Zendesk, мы столкнулись с проблемой масштабируемости, связанной с ежедневным построением до 50 000 моделей машинного обучения (ML). Да, 50к моделей. Да это много! Просмотр данных поначалу нервировал.

В этой статье основное внимание уделяется новой платформе для построения моделей, которую мы разработали и создали для Content Cues и уже несколько месяцев используют в производственной среде AWS Batch. От концепции до реализации этот процесс был для нас сложным, но полезным опытом, и мы хотели бы поделиться с вами нашим путешествием.

Это первая из трех частей серии, в которых рассказывается, как мы оценивали различные технологические возможности (AWS Batch, AWS Sagemaker, Kubernetes, EMR Hadoop / Spark), в конечном итоге выбирая AWS Batch.

Контентные подсказки

Content Cues сочетает в себе несколько моделей машинного обучения с использованием методов обработки естественного языка и глубокого обучения для объединения обращений в службу поддержки клиентов по осмысленным темам. Алгоритмы, лежащие в основе Content Cues, настолько увлекательны, что заслуживают серии блогов или набора научных статей. Возможно, мои друзья-аналитики данных (Soon-Ee Cheah и Ai-Lien Tran-Cong) поделятся более подробной информацией в будущем.

Построение модели Content Cues

Прежде чем исследовать различные варианты вычислительной платформы, важно понять, как строится единая модель Content Cues. Модели Content Cues строятся для каждого клиента (т. Е. По одной модели на клиента), и процесс построения модели можно упростить, как показано ниже:

  • Сводные данные о обращениях в службу поддержки за последние 2 месяца для клиента
  • Примените алгоритмы машинного обучения (написанные на Python) к билетам, чтобы обобщить их
  • Создайте файл JSON, представляющий эти сводки

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

Требования

  • Масштабируемость, масштабируемость, масштабируемость!
  • Поддержка по запросу и периодическое построение моделей
  • Поддержка отказоустойчивости и повторных попыток выполнения задания
  • Гибкость обучения на экземплярах ЦП или ГП
  • Хорошие возможности отладки и мониторинга

Представляем AWS Batch

AWS Batch - полностью управляемый сервис для выполнения пакетных рабочих нагрузок. Работа выполняется внутри контейнеров Docker. AWS Batch использует Elastic Container Service (ECS) для организации контейнеров Docker для выполнения задач. AWS Batch отслеживает текущие задания и очереди заданий и может автоматически масштабировать емкость кластера в зависимости от рабочей нагрузки. AWS Batch состоит из:

  • вычислительная среда: контейнеры ECS, которые запускаются в указанном VPC и подсети. Мы можем определять разные типы экземпляров (CPU / GPU) для разных вычислительных сред.
  • определение должности: определяет тип работы. Он определяет образ Docker, требования к ресурсам, переменные среды, количество повторных попыток и т. Д.
  • очередь заданий: рабочая очередь для запуска заданий. Он поддерживает уровни приоритета от 0 до 10. В одну очередь можно отправлять разные типы заданий.

Использование AWS Batch для построения моделей

Вот как мы использовали AWS Batch в производстве:

Построение модели повлекло за собой:

  • Отправка работ по построению модели в AWS Batch
  • AWS Batch запускает контейнер Docker для работы по построению модели
  • Команда контейнера построения модели запускает код построения модели (Python) для извлечения обучающих данных из корзины функций S3 и создания модели. Образ и команда Docker для использования определены в определении задания. AWS Batch повторяет невыполненные задания до определенного предела повторных попыток.
  • Контейнер построения модели, загружающий модель в корзину моделей S3. Создание нового объекта запускает событие S3, которое помещается в очередь в SNS, а затем распространяется на SQS.
  • Служба обслуживания моделей подписывается на SQS, обеспечивая получение уведомлений при создании новых моделей.

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

Рассмотрены другие варианты

Помимо AWS Batch, мы рассматривали следующие варианты:

  • AWS Sagemaker: управляемый сервис от AWS, предназначенный для обучения и обслуживания моделей машинного обучения. В нем используется концепция, аналогичная AWS Batch: обучающие данные размещаются на S3, а модели создаются в корзине S3. Sagemaker не был выбран, поскольку, по всей видимости, существовали различные ограничения на количество разрешенных одновременных рабочих мест. В отличие от этого, AWS Batch позволяет определять столько виртуальных ЦП, сколько требуется для ваших вычислительных сред.

  • Kubernetes: система с открытым исходным кодом для оркестровки контейнеров. AWS предоставляет управляемую версию Kubernetes через EKS. Для наших нужд отсутствие встроенной поддержки для указания зависимостей и приоритетов заданий является существенным ограничением Kubernetes (Jobs).
  • EMR Hadoop / Spark: фреймворки распределенной обработки данных на AWS. Для фреймворков сокращения карты (MR), таких как Hadoop, все модели в пакете необходимо повторно запускать, если построение любой модели не удается, что приводит к потере большого количества ресурсов. Кроме того, настройка отдельных моделей может быть затруднена, поскольку они выполняются заданием MR в пакетном режиме, в отличие от подхода на основе очереди, принятого в AWS Batch.

Почему мы выбрали AWS Batch

  • Автоматическое масштабирование вычислительного ресурса по умолчанию в зависимости от рабочей нагрузки
  • Готовая поддержка приоритетов заданий, повторных попыток и зависимостей заданий
  • Подход на основе очередей хорошо подходит для нашего варианта использования для создания повторяющихся заданий и заданий по запросу.
  • Поддерживает рабочую нагрузку CPU и GPU. Возможность использовать графический процессор для построения моделей машинного обучения имеет решающее значение, поскольку графический процессор может значительно ускорить процесс обучения, особенно для моделей глубокого обучения.
  • Гибкость определения пользовательских образов машин Amazon (AMI) для вычислительной среды.

В поисках гремлинов

Есть так много вещей, которые могут пойти не так, как надо, при создании нового продукта. В Zendesk мы стремимся изучить проблемное пространство на ранней стадии, задолго до того, как продукт станет общедоступным. Я провел серию экспериментов и проверок концепции, чтобы изучить возможности AWS Batch. Образ Docker с упрощенной версией кода построения модели использовался для тестов со следующими сценариями:

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

  • Умение обрабатывать сценарии сбоя. Это было проверено запуском заданий, которые, как ожидается, завершатся ошибкой, например из-за нехватки памяти, ошибки в коде и т. д., а также обеспечения работы уведомлений о сбоях по электронной почте SNS.
  • Возможность назначать приоритет задания. Это проверяется заполнением очередей с низким приоритетом несколькими заданиями, гарантируя, что задание с высоким приоритетом запускается сразу после отправки.

AWS Batch преуспел во всех сценариях и продолжал работать, как ожидалось.

Резюме

Создав прототип и экспериментируя, мы определили AWS Batch как предпочтительный вариант для создания платформы для построения моделей. Простая установка и готовая поддержка сделали его привлекательным для выполнения задач массовой обработки с контейнерами Docker.

Во частях 2 и 3 нашей серии моих уважаемых товарищей по команде Дана Ма и Деррик Ченг. Они расскажут о реализации нашей платформы для построения моделей и ознакомятся с советами и приемами.

Предупреждение о спойлере: благодаря тщательной оптимизации нам удалось снизить стоимость вычислений для построения 1000 моделей в AWS Batch до уровня ниже цены чашки кофе! Будьте на связи ;)

Я хотел бы поблагодарить моих коллег Эрика Пака, Soon-Ee Cheah и Джонатона Белотти за помощь на разных этапах проверки. концепция.