Привет! С вами Олег, Рамиль и Андрей из Flocktory. Мы руководим машинным обучением и разработкой в компании, сейчас активно внедряем AI для лучшей персонализации. В прошлом году наши команды реализовали ML-сервисы, внедрили ML Feature Store и переработали жизненный цикл моделей (о чём мы подробно рассказывали на HighLoad++: https://highload.ru/moscow/2024/abstracts/12929). В этой статье поразмышляем над следующим шагом для среднего размера компании, которая внедряет AI – как масштабировать проекты машинного обучения. Обработка, анализ и обучение на данных влекут за собой применение ML систем, в том числе нейросетей. Это требует больших вычислительных ресурсов: сотни гигабайт ОЗУ, десятки ядер CPU, а также видеокарты и (или) специальные чипы для ускорения вычислений.
Рассмотрим основные варианты ресурсов, которые можно использовать, сложности, связанные с их эксплуатацией, целесообразность вложений и vendor lock. Но сначала поговорим о природе трудностей, возникающих при масштабировании.
Проблемы с масштабированием и откуда они берутся
На первый взгляд кажется, что если вы хорошо решаете задачи малыми усилиями, то с большими ресурсами делать это будет еще проще. Но нет. И вот несколько причин, почему так:
При работе над крупной системой в большой разнородной команде, где есть аналитики и исследователи данных, инженеры-разработчики, системные инженеры и так далее, сотрудники из разных команд часто используют различные инструменты для решения задач. Это касается как сред разработки и исполнения (Python, Matlab, Java, C/C++ etc.) так и используемых баз данных (RDBMS, NO SQL, файлы и пр.). Переквалификация может быть долгой, дорогой или невозможной в краткосрочной перспективе.
Внедрение новых технологий может сделать неудобным или невозможным использование единого инструментария. К примеру, основная часть ML системы может быть реализована на Java, но при имплементации новой модели могут потребоваться библиотеки на Python, C/С++ etc. Их придется интегрировать: повторная имплементация фич в текущем инструментарии может потребовать много времени и чревата большими издержками для бизнеса.
Вертикальное масштабирование системы может быть недоступно или слишком дорого. Конечно, это зависит от мощностей дата-центров вашего провайдера, но у любого из них есть практический предел. Это ограничивает увеличение вычислительных ресурсов на одном узле. Приходится использовать несколько узлов, объединенных в кластер, чтобы достичь требуемых мощностей.
В ряде случаев, когда требуется специализированное оборудование для вычислений, например, Nvidia Tesla и Tensor Cores, целесообразна покупка собственных серверов и установка их в дата-центрах провайдера.
Какие решения существуют?
Для решения проблем неоднородности инструментария используется контейнеризация приложений с помощью Docker и система оркестрации контейнеров.
Контейнерное приложение – это приложение и необходимая для него среда исполнения, собранные в определенном формате для запуска в изолированной среде в системе управления контейнерными приложениями.
В контейнерах могут быть практически любые приложения прикладного и системного уровня. они будут запущены в изолированной среде, что позволяет избегать конфликтов между системными библиотеками, а также гибко разграничивать доступ и ресурсы.
Docker – это наиболее распространенная платформа контейнеризации приложений. В ее состав входят как инструменты позволяющие собирать контейнерные приложения, так и демон, позволяющий запускать контейниризованные приложения и управлять ими в пределах одного узла.
Kubernetes – самая известная и стандартизированная система оркестрации контейнеров в кластере. Kubernetes кластеры доступны практически у любого крупного облачного провайдера (AWS, Azure, GCP и пр.).
Оговорюсь, что существуют другие технологии контейнеризации и кластерные системы управления контейнерами, но Kubernetes on Docker – наиболее распространенные и стандартные решения сейчас.
Сначала поговорим об особенностях выбора платформы для Kubernetes, а потом – об особенностях архитектуры ML систем в кластере Kubernetes. Как я отметил выше, основные варианты – это managed кластер in cloud или собственный кластер on bare metal. Рассмотрим подробнее эти варианты.
Кластер в облаке
Плюсы:
Обслуживанием занимается облачный провайдер. Отдельный администратор кластера не требуется, чаще всего разработчики сами справятся.
Доступны базы данных и другая инфраструктура с автоматическим масштабированием (S3, DynamoDB, RDS, Redshift и пр.).
Возможность быстро изменять количество ресурсов кластера при возникновении такой потребности.
Неисправности происходят реже.
Минусы:
Дорого, очевидно что bare metal сервера стоят дешевле без учета поддержки.
Большая вероятность получить жесткий vendor lock-in при использовании технологий провайдера (например, DynamoDB)
Неисправности, когда случаются, чинятся дольше.
Выбор оборудования ограничен, невозможно использовать специфическое железо.
Часто непрозрачное ценообразование.
Комментарий:
Конечно, сначала проще пользоваться managed кластером, чем разворачивать свой. Но потом, при возникновении проблем в расследованиях с траблшутингом, поиск причины и возможного решения может быть гораздо более долгим и болезненным. Вы будете ограничены в доступе к системному уровню, что влечет дополнительные сложности в диагностике и решении этих проблем. Некоторые, возможно, вы и не сможете решить самостоятельно при отсутствии доступа к системному уровню, придется ожидать помощи техподдержки.
С осторожностью нужно относиться к проприетарным сервисам in cloud. Они формируют vendor lock-in. Если вас перестанет устраивать провайдер, вам будет тяжелее отказаться от его услуг из-за внедренных решений на базе этих продуктов (например, проприетарные NO SQL хранилища).
Собственный кластер на физических серверах
Плюсы:
Аренда физических серверов у хостеров в несколько раз дешевле аренды узлов у cloud провайдеров (пример сравнения цен будет ниже).
Большая гибкость в выборе, конфигурировании и размещении оборудования. Colocation. Можно собрать собственные и разместить их в дата-центре. Актуально при использовании специфического оборудования (видеокарты, тензорные ядра, аппаратное шифрование и пр.).
Скорость устранения неисправностей часто выше, этому способствует отсутствие жестких vendor lock-in, что вводит возможность быстрой миграции и широту выбора решений провайдеров.
Большая гибкость в выборе и конфигурации систем и сервисов.
Минусы:
Для обслуживания кластера, включая развертывание, мониторинг, резервирование, требуется выделенный эксперт или даже целая команда администрирования.
Неисправности на раннем этапе происходят чаще, в зависимости от квалификации эксперта.
Масштабирование требует больше времени, в том числе на добавление серверов, изменение конфигурации, не исключена миграция между стойками и (или) датацентрами.
Комментарий:
При выборе оборудования надо отдать предпочтение именно dedicated серверам. При использовании virtual серверов можно заметить периодические просадки по IO или CPU – это аффектит скорость и стабильность вычислений.
Также имеет смысл обратить внимание на организацию сети между вашими серверами. Размещение в одном дата-центре – это хорошо, но гораздо лучше – в одной стойке и на одном коммутаторе. Скорость и стабильность связи между вашими серверами убирает множество проблем. У bare metal providers услуга размещения серверов на одной стойке называется colocation, обращайте на нее внимание.
Архитектура ML кластера
Рассмотрим минимальную схему кластера с типизацией по узлам, чтобы говорить предметнее. Каждый тип узла может быть отмаcштабирован в зависимости от требований.
На узлах Data приложений собираются данные для ML приложений. Хранилище Мастер Данных – это хранилище, в которое поды Data приложений загружают подготовленные данные. Если весь набор данных помещается в локальное хранилище узлов, то рекомендуется делать полную репликацию этих данных на все узлы. Это значительно снижает количество сбоев и нагрузку на сеть, когда поды с ML приложением читают данные. В качестве Хранилища Мастер Данных можно использовать ClickHouse и (или) MinIO.
Можно использовать colocation и подключить всю стойку (rack) к одному быстрому 10GE коммутатору. Однако, даже в этом случае, подготовленные данные важно грамотно сгруппировать. Это позволит использовать один из бинарных форматов хранения, тем самым исключить накладные расходы на парсинг, обращайте на это внимание.
На узлах ML приложений запускаются модели и связанные с ними функции. Они делают инференс и фиксируют результат. Узлы Хранилища Результатов Данных должны уметь принять результаты анализа данных, оценить их и предоставить доступ к ним извне. В качестве Хранилища Мастер Данных можно использовать ClickHouse и (или) MinIO.
Можно написать свой планировщик, используя Kubernetes API, либо воспользоваться встроенным в Dagster, Airflow и других планировщиках. В имплементации важно иметь контроль количества записей в etcd для подов. Завершившиеся поды приложений нужно периодически очищать, иначе etcd распухнет и кластер умрет.
Распределение нагрузки по нескольким узлам. При работе ML приложений ресурсы задействованы максимально, и это типичная ситуация, Важно, чтобы для системных сервисов всегда оставались свободные ресурсы. Исключение – environments for dev testing, в целях экономии их можно размещать на одном узле.
Резервирование должно быть выделено в отдельную систему, которая не зависит от работы самой ML системы. Важно, чтобы она включала в себя создание набора бекапов в разные моменты времени и их тестирование в плановых учениях по отработке внезапных отказов.
Выводы
Когда ваши ML сервисы только развиваются и не потребляют ресурсы круглосуточно, целесообразно пользоваться услугами in cloud. Можно арендовать spot и on-demand инстансы под выполнение конкретной задачи чтобы не платить за них постоянно. Да, это в разы дороже, чем virtual или bare metal инстансы (в пересчете на часы), но особенность оплаты по часам, в которых были действительно задействованы эти ресурсы, поможет сэкономить здесь и сейчас.
Если ваши ML сервисы будут круглосуточно нагружать кластер, то, при наличии экспертизы в команде, целесообразно рассмотреть bare metal провайдера. При отсутствии специальных скидок от cloud провайдера, даже при максимальной экономии и с учетом пакетных годовых офферов, стоимость virtual инстансов будет выше, чем стоимость bare metal инстансов. При резервировании менее чем на год — еще выше.
