1. “SERVING” ML
МОДЕЛЕЙ В
МИКРОСЕРВИСНОЙ
АРХИТЕКТУРЕ

2. • Разговор о моделях в микросервисах, не о моделях
• только бэкенд, только много запросов и жирные
модели
• Это не про машин лерниниг

3. На входе много
сырых данных
Как получить ML модель
Математическая
модель, которая
могёт!
ETL
Train
Validation

4. ML модель
• Модели бывают разные и предназначение у них совершенно
разное
• По сути своей каждая модель - программа, которая оптимально
решает заданную задачу.

5. Serving модели
• использовать модель, до нее надо “достучаться”. Вы можете:
1. внедрить в свой микросервис.
2. создать новый микросервис, который будет обслуживать
только эту модель.

6. Внедрить в свою программу
• Работает внутри программы - меньше накладных расходов
• Вы получаете из коробки CI - версионирование и менеджмент
• Вы получаете из коробки CD - запуск и остановка
• microservice обвязка уже есть: Service discovery, Health
checking, load balancing, circuit breaking, metrics, logs, central
configuration
Очевидные плюсы

7. Внедрить в свою программу
CI/CD не всегда сработает - разные жизненные циклы
Очень не видные минусы
• Скорее всего модель будут разрабатывать
data scientist (а вот они наменяют)
• Модели могут обновляться раз в 30 минут
(можно положить в базу и динамически
подтаскивать)

8. Внедрить в свою программу
Разные требования к железу
плюсы превращаются… превращаются
плюсы…
• Для fastText не проблема занимать на жестком диске > 2GB
• tensoflow в некоторых случаях эффективнее работает на
GPU
• Модели могут занимать много места в памяти
• Модель может быть требовательна к CPU и отъедать его у
других задач

9. Внедрить в свою программу
Много фреймворков написанных на разных языках
и вообще, внедрить не получится
• Переписывать сервис на новый язык, если вдруг DS применил
новую библиотеку - НЕТ (а он применит)
• Реализовывать алгоритм работы модели на своем языке - НЕТ
(пусть DS сами пишут)
• Некоторые библиотеки плохо работают без batch (например
спарк)

10. Внедрить в свою программу
Очень редко когда модель используется изолированно
модели бегают толпами
Все предыдущие проблемы можно смело умножать на 2.5

11. Внедрить в свою программу
• Работает внутри программы - меньше накладных расходов
• Вы получаете из коробки CI - версионирование и менеджмент
• Вы получаете из коробки CD - запуск и остановка
• microservice обвязка уже есть: Service discovery, Health
checking, load balancing, circuit breaking, metrics, logs,
central configuration
Очевидные плюсы

12. Отдельный микросервис
• Работает отдельно и никого не трогает (можно
запускать на любом железе)
• Отдельный цикл
разработки/тестирования/развертывания

13. Отдельный микросервис
• Можно делать любой pipeline
• Или даже DAG

14. Отдельный микросервис
Много фреймворков написанных на разных языках никто не
отменял. Писать для каждого microservice обвязку - НЕТ!
все круто, НО есть нюанс

15. Что делать? Как быть?
• Если модель одна, маленькая и никогда не
меняется - встраивайте
• Если вы уверены, что сможете сделать обвязку для
всех моделей, которые придумают DS - значит у вас
есть лишнее время и ресурсы - пишите.
• А что делать тому у кого много DS, много моделей и
они появляются как грибы?

16. Искать готовое решение
oryx.io - Отличный serving, но к сожалению
только Spark
- Нет возможности делать Pipeline
Поддерживает любую модель, но не
масштабируется и нет там обвязки микросервисов
есть tensorflow-serving, но это только tensorflow

17. Сделать своё!
globula
hydro-serving
Мы у мамы программисты

18. Что мы сделали?
Выбрали писать свой сервис для каждой модели, но
хитро - с использованием Sidecar Pattern

19. Что такое sidecar? и как это
работает?
Sidecar - отдельный процесс, который берет на себя всю работу с
инфраструктурой, оставляя основному сервису только его логику

20. Что нам дает Sidecar?
• Отделяем логику сервиса
от инфраструктуры
• Proxy до других сервисов
• Логгирование
• Трассирование сообщений
• Метрики
• Resilient inter-service
communication

21. Плюсы от использования
Sidecar
• 1 имплементация, чтобы править всеми
моделями
• Код для сервинга модели очень простой - надо
просто поднять HTTP сервер
• Интеграция с уже существующей
инфраструктурой
• Гибкие возможности по управлению трафиком
между моделями

22. 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++

23. Мы выбрали Envoy и используем
следующий функционал
• Метрики - (мы дописали интеграцию с Prometheus)
• Tracing - используется Zipkin (можно подключить
любой OpenTracing)
• Service Discover
• Outlier detection
• Client Load Balancing
• Circuit Breaker
• Connection pooling
• Shadowing

24. Что мы делаем?Первое: собираем и версионируем микросервисы из моделей, достаем
метаинформацию по структуре данных - избавляем DS от этой головной боли

25. Что мы делаем?Второе: запускаем это всё в кластере ECS/Kubernetes/Swarm -
помогаем OpsTeam
• Запускаем собранные
микросервисы на
существующем кластере
• Используем родные
абстракции кластеров
• Прячем это все от DS

26. Что мы делаем?
Третье: управляем взаимосвязью моделей в кластере через Sidecar

27. Что мы делаем?
Четвертое: интегрируемая с текущими системами мониторинга

28. Что мы можем?Blue-green deployment, canary - легко, спасибо sidecar за это, не
надо никаких дополнительных Load Balancer

29. Что мы можем?
Blue-green deployment, canary - легко, спасибо sidecar за это, не
надо никаких дополнительных Load Balancer

30. Roadmap
• Поддержка Kubernetes
• Переход на Istio - как средство управления mesh
• Переход на GRPC для взаимодействия
• Реактивные пайплайны
• DAG

31. Имена! Пароли! Явки!
hydrosphere.io
://github.com/Hydrospheredata/hydro-se

32. ???