Дизайн сервиса мониторинга

Погорелов Петр — ML Engineer

Три столпа мониторинга

Логи - это события, которые система зафиксировала и записала в хранилище данных.
Дашборды - это средства визуализации данных, которые помогают оценить состояние системы.
Алерты - это механизм информирования пользователей о том что что-то пошло не так.

И так, мы подробно разобрали различные аспекты мониторинга явления Model Drift, и теперь практически готовы приступить к построению простой системы для отслеживания деградации модели. Но перед этим давайте обсудим три основных инструмента мониторинга, без которых построение системы невозможно.

Первый инструмент - это логи сервиса. Логи - это события, которые система зафиксировала и записала в хранилище данных. При построении системы мониторинга дрейфа модели для нас важны следующие события: входные данные ML сервиса, описательные признаки (то есть, преобразованные входные данные, или в простонародье - фичи), предсказания модели и обратная связь от агентов, которые взаимодействовали с системой. Все эти события по возможности нужно логировать.

Следует обозначить для чего нам нужны описанные выше события: 1) Входные данные как правило тяжело мониторить на предмет наличия дрейфа. У входных данных может быть вложенная структура, возможно отсутствие каких-то данных. Однако информация о входных данных в логах может потребоваться для расследования причин дрейфа данных. 2) Описательные признаки, в отличие от входных данных гораздо проще мониторить на наличие дрейфа данных. 3) Предсказания модели можно использовать для оценки адекватности поведения модели в продакшн среде. Например, локально у исследователя модель может себя вести одним образом, а в продакшн среде - другим образом. 4) Обратная связь от агентов может потребоваться для дообучения модели.

Второй инструмент - это дашборды. Дашборды - это средства визуализации данных, которые могут помочь нам оценить степень деградации модели. Например, можно построить график значения технической метрики в зависимости от времени, и на основе динамики - принимать решение о переобучении. Также по графикам можно проводить sanity-check текущей системы мониторинга, насколько адекватно срабатывают триггеры на переобучение, либо алерты.

Третий инструмент - это алерты (оповещения). Алерты это механизм информирования пользователей системы о том что с ней что-то пошло не так. В нашем случае - алерт может выглядеть как сообщение в мессенджер (либо почту) о том что пора переобучать модель.

Абстрактный дизайн

В рамках практической части курса мы рассмотрим простую систему мониторинга на базе пакетной обработки событий. На слайде представлена схема без указания конкретных технологий. На текущем этапе они для нас не важны, но дальше мы заполним этот пробел.

На схеме представлен набор блоков отражающие отдельные сервисы в рамках MLOps инфраструктуры. Блоки соединены стрелками, где направление стрелок обозначает поток данных. Для каждой дана подпись, которая указывает какие именно данные по ней протекают. Также у стрелок есть порядковые номера, которые описывают последовательность в которой данные проходят из одного сервиса в другой.

Пройдемся по порядку. 1) В результате взаимодействия ML сервиса с пользователем формируются логи, которые отправляются в очередь сообщений. 2) Далее, с заданной периодичностью эти логи сохраняются в склад данных (в простонародье - DWH). 3) Планировщик с предварительно заданной периодичностью запускает сервис детекции. 4,5) Сервис детекции дрейфа забирает контрольные и актуальные данные, сравнивает их и записывает результат в склад данных. 6.1) Далее с заданной периодичностью эти данные читает сервис дашбордов и обновляет графики, которые могут посмотреть разработчики и аналитики. 6.2) В то же время, если сервис детекции дрейфа промаркировал значимое отклонение от контрольного набора данных, то сервис алертинга формирует сообщения на почту либо в мессенджер.

Давайте попробуем заполнить пробелы в этой схеме и укажем конкретные технологии. Мы с вами рассмотрим планировщик, системы для алертинга и мониторинга и готовые решения для детекции явления Model Drift. Программные решения для организации системы DWH и очередей мы сейчас рассматривать не будем, поскольку они выходят за рамки MLOps.

Планировщик

В качестве планировщика мы будем использовать Apache Airflow, с которым вы уже встречались в рамках курса. На всякий случай напомню - Airflow это оркестратор задач, который позволяет по крону вызывать так называемые ДАГи. ДАГ - это ациклический граф, где узлы представляю собой отдельные задачи, а ребра задают последовательность вызова узлов. Airflow позволяет запускать код изолировано в Python-виртуальных средах, либо в Docker контейнерах. Для наших целей это более чем достаточно.

В нашем случае ДАГ может состоять из сенсора, который ожидает данные из склада данных, задачи расчета статистики для оценки деградации модели, и задачи отправки расчетных данных обратно в склад данных.

Дашборд и алертинг

Для построения дашборда предлагается использовать платформу Grafana, которая в том числе поддерживает и систему алертинга. Grafana умеет подключаться к различным источникам данных, и строить на их основе динамически обновляемые графики. Поскольку Grafana не имеет встроенного хранилища данных, куда мы могли бы отправлять метрики - в рамках курса предлагаем воспользоваться сервисом Prometheus.

Prometheus представляет собой базу данных для временных рядов, механизм работы которой отличается от привычных реляционных и NoSQL баз данных. Prometheus работает по модели pull запросов, то есть, он сам опрашивает сервисы и записывает состояние которые они возвращают.

Не считаю целесообразным заострять внимание на деталях устройства Grafana или Prometheus, поскольку мы с ними поработаем во время практического занятия.

Конкретный дизайн

Мы рассмотрели конкретные компоненты, которые можно интегрировать в нашу систему. Теперь попробуем с их помощью описать конкретный дизайн нашей системы мониторинга. В качестве планировщика в схеме используется Apache Airflow, который с заданной периодичностью вызывает сервис детекции дрейфа данных.

Сервис детекции дрейфа подтягивает нужные данные за контрольный период и за тестовый период. Как правило - это вчерашний день, либо последняя неделя, месяц и так далее. Затем сервис детекции дрейфа выполняет свою задачу - проводит оценку степени дрейфа для каждой единицы данных (выражается в вещественной величине). Последнее что делает этот сервис - он отправляет отображение вида <описательный признак>:<величина дрейфа> в специальный сервис мониторинга который хранит состояние. У этого сервиса есть ручка, с помощью которой можно получить текущее состояние - т.е., все метрики.

Далее Prometheus с заданной периодичностью (например, 1 мин) считывает данные из сервиса мониторинга и сохраняет их во временной ряд. Этот временной ряд может прочитать Grafana, и использовать в виде источника данных для дашбордов. Помимо этого - в Grafana можно установить алерт при условии выполнения какого-то правила, например - превышении величиной заданного порога. Этим функционалом мы воспользуемся во время практики для создания телеграм бота для оповещений.

Пакеты для мониторинга дрейфа

В настоящий момент существует множество пакетов для мониторинга явления Model Drift, часть из которых представлена на слайде. В рамках практики вам предлагается выбрать любой из представленных пакетов, либо что-то иное и самостоятельно реализовать механизм обнаружения сдвига ковариат. Выбирать можно будет какую угодно библиотеку, но вам придется использовать механизм детекции посредством статистических тестов, а не статистик. Детектор на базе статистик мы разберем во время практики.

Главное что хочется отметить - не стоит гоняться за хайпом вокруг какой-то определенной библиотеки. Все они работают примерно одинаково и никакого рокет-саенса у них под капотом нет. Многие, например, evidently и tfx - сильно раздуты с точки зрения функционала, который может быть избыточен в ваших задачах. Поэтому - может быть имеет смысл остановиться вообще на библиотеке scipy, забрать оттуда нужные статтесты и использовать их в своем коде.