“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

???