“SERVING” ML
МОДЕЛЕЙ В
МИКРОСЕРВИСНОЙ
АРХИТЕКТУРЕ
• Разговор о моделях в микросервисах, не о моделях
• только бэкенд, только много запросов и жирные
модели
• Это не про машин лерниниг
На входе много
сырых данных
Как получить ML модель
Математическая
модель, которая
могёт!
ETL
Train
Validation
ML модель
• Модели бывают разные и предназначение у них совершенно
разное
• По сути своей каждая модель - программа, которая оптимально
решает заданную задачу.
Serving модели
• использовать модель, до нее надо “достучаться”. Вы можете:
1. внедрить в свой микросервис.
2. создать новый микросервис, который будет обслуживать
только эту модель.
Внедрить в свою программу
• Работает внутри программы - меньше накладных расходов
• Вы получаете из коробки CI - версионирование и менеджмент
• Вы получаете из коробки CD - запуск и остановка
• microservice обвязка уже есть: Service discovery, Health
checking, load balancing, circuit breaking, metrics, logs, central
configuration
Очевидные плюсы
Внедрить в свою программу
CI/CD не всегда сработает - разные жизненные циклы
Очень не видные минусы
• Скорее всего модель будут разрабатывать
data scientist (а вот они наменяют)
• Модели могут обновляться раз в 30 минут
(можно положить в базу и динамически
подтаскивать)
Внедрить в свою программу
Разные требования к железу
плюсы превращаются… превращаются
плюсы…
• Для fastText не проблема занимать на жестком диске > 2GB
• tensoflow в некоторых случаях эффективнее работает на
GPU
• Модели могут занимать много места в памяти
• Модель может быть требовательна к CPU и отъедать его у
других задач
Внедрить в свою программу
Много фреймворков написанных на разных языках
и вообще, внедрить не получится
• Переписывать сервис на новый язык, если вдруг DS применил
новую библиотеку - НЕТ (а он применит)
• Реализовывать алгоритм работы модели на своем языке - НЕТ
(пусть DS сами пишут)
• Некоторые библиотеки плохо работают без batch (например
спарк)
Внедрить в свою программу
Очень редко когда модель используется изолированно
модели бегают толпами
Все предыдущие проблемы можно смело умножать на 2.5
Внедрить в свою программу
• Работает внутри программы - меньше накладных расходов
• Вы получаете из коробки CI - версионирование и менеджмент
• Вы получаете из коробки CD - запуск и остановка
• microservice обвязка уже есть: Service discovery, Health
checking, load balancing, circuit breaking, metrics, logs,
central configuration
Очевидные плюсы
Отдельный микросервис
• Работает отдельно и никого не трогает (можно
запускать на любом железе)
• Отдельный цикл
разработки/тестирования/развертывания
Отдельный микросервис
• Можно делать любой pipeline
• Или даже DAG
Отдельный микросервис
Много фреймворков написанных на разных языках никто не
отменял. Писать для каждого microservice обвязку - НЕТ!
все круто, НО есть нюанс
Что делать? Как быть?• Если модель одна, маленькая и никогда не
меняется - встраивайте
• Если вы уверены, что сможете сделать обвязку для
всех моделей, которые придумают DS - значит у вас
есть лишнее время и ресурсы - пишите.
• А что делать тому у кого много DS, много моделей и
они появляются как грибы?
Искать готовое решение
oryx.io - Отличный serving, но к сожалению
только Spark
- Нет возможности делать Pipeline
Поддерживает любую модель, но не
масштабируется и нет там обвязки микросервисов
есть tensorflow-serving, но это только tensorflow
Сделать своё!
globula
hydro-serving
Мы у мамы программисты
Что мы сделали?
Выбрали писать свой сервис для каждой модели, но
хитро - с использованием Sidecar Pattern
Что такое sidecar? и как это
работает?
Sidecar - отдельный процесс, который берет на себя всю работу с
инфраструктурой, оставляя основному сервису только его логику
Что нам дает Sidecar?
• Отделяем логику сервиса
от инфраструктуры
• Proxy до других сервисов
• Логгирование
• Трассирование сообщений
• Метрики
• Resilient inter-service
communication
Плюсы от использования
Sidecar• 1 имплементация, чтобы править всеми
моделями
• Код для сервинга модели очень простой - надо
просто поднять HTTP сервер
• Интеграция с уже существующей
инфраструктурой
• Гибкие возможности по управлению трафиком
между моделями
Implementations
• Prana [Netflix] - java. Archived.
• go-micro
[https://github.com/micro/micro/tree/master/car] - go
• linkerd [https://github.com/linkerd/linkerd] - java
• envoy [https://github.com/lyft/envoy] - C++
• Istio [Google, IBM and Lyft] - go and C++
Мы выбрали Envoy и используем
следующий функционал
• Метрики - (мы дописали интеграцию с Prometheus)
• Tracing - используется Zipkin (можно подключить
любой OpenTracing)
• Service Discover
• Outlier detection
• Client Load Balancing
• Circuit Breaker
• Connection pooling
• Shadowing
Что мы делаем?Первое: собираем и версионируем микросервисы из моделей, достаем
метаинформацию по структуре данных - избавляем DS от этой головной боли
Что мы делаем?Второе: запускаем это всё в кластере ECS/Kubernetes/Swarm -
помогаем OpsTeam
• Запускаем собранные
микросервисы на
существующем кластере
• Используем родные
абстракции кластеров
• Прячем это все от DS
Что мы делаем?Третье: управляем взаимосвязью моделей в кластере через Sidecar
Что мы делаем?Четвертое: интегрируемая с текущими системами мониторинга
Что мы можем?Blue-green deployment, canary - легко, спасибо sidecar за это, не
надо никаких дополнительных Load Balancer
Что мы можем?
Blue-green deployment, canary - легко, спасибо sidecar за это, не
надо никаких дополнительных Load Balancer
Roadmap
• Поддержка Kubernetes
• Переход на Istio - как средство управления mesh
• Переход на GRPC для взаимодействия
• Реактивные пайплайны
• DAG
Имена! Пароли! Явки!
hydrosphere.io
https://github.com/Hydrospheredata/hydro-serving
???