Система автоматизированного мониторинга продуктовых метрик в Google Cloud Platform

Компания Xsolla является продуктовой компанией на рынке видеоигр и многие годы помогает игровым издателям монетизировать и продвигать свои проекты с помощью широкого набора инструментов — от настройки платежей до поиска инвестора.

В то время как Backend и Frontend инженеры трудятся над постоянным улучшением основных продуктов компании, команда Data Science работает над повсеместным внедрением Data Informed культуры в эти самые продукты, чтобы все решения, вне зависимости от их важности, принимались с учетом анализа данных и показателей метрик. Как раз о метриках и пойдет разговор ниже.

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

В техническом блоге компании Xsolla есть статья про планирование https://medium.com/xsolla-tech/how-to-organize-pi-planning-online-for-more-than-200-people-and-not-die-af8c314e34f5.

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

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

Из информационной схемы с первого взгляда понятно, что для разработки использовались облачные сервисы Google Cloud Platform. Такой выбор технологического стека был сделан по ряду причин:

В большинстве случаев метрики можно разложить в ряд по времени и использовать методы математической статистики или алгоритмы машинного обучения для их анализа. Под анализом временных рядов можно понимать широкий спектр операций: проверку на стационарность, сглаживание, прогнозирование, выявление аномалий или простую визуализацию. При наличии большого количества таких временных рядов (порядка 100 тысяч) необходимо четко понимать, какой тип анализа наиболее важный. Мы пошли по пути выявления аномалий (нетипичного падения или роста метрики), которые можно обнаружить на основе исторических данных.

Для получения актуальных данных по интересующим нас продуктовым метрикам и агрегации на их основе временных рядов, чтобы впоследствии проанализировать и выявить аномалии, мы используем сервис Composer, ядром которого является Open Source решение Apache Airflow https://airflow.apache.org/. Посредством асинхронных процессов Dags, сервис позволяет организовать получение необходимых данных из хранилища через знакомый каждому аналитику SQL, формировать временные ряды на их основе и отправлять их с необходимой периодичностью на анализ в формате JSON.

Вся логика и конкретные методы для выявления аномалий во временных рядах были разработаны с помощью очередей сообщений Pub/Sub и микросервисов Cloud Functions, которые работают по триггерному принципу. Список триггеров для Cloud Functions довольно широкий, но чаще всего используются следующие: появление сообщения в очереди Pub/Sub, которую микросервис слушает как подписчик, и отправка прямого HTTP-запроса на конкретный микросервис. Если планируется оперирование большими объемами данных, использование очередей позволяет достигнуть плавной балансировки нагрузки и поэтапного масштабирования.

Как мы организовали логику анализа временных рядов:

Имея в распоряжении несколько Base Line методов (сравнение показателя за текущий период с заранее заданными граничными значениями и ряд стандартных методов математической статистики для выявления аномалий), нам был необходим микросервис маршрутизации [4], который, в зависимости от свойств и атрибутов временного ряда, выбирал бы наиболее подходящий метод анализа. При наличии граничных знаний (таргетов) анализ выполняется в самом маршрутизаторе, после чего ряд отправляется в очередь микросервиса, который определяет необходимость отправки сообщения о выявленной аномалии [8]. При этом нет смысла сообщать о мельчайших отклонениях от нормального поведения, но сохранить полученные знания стоит. В случае отсутствия заранее определенных границ “нормальности” метрики, временной ряд отправляется на анализ микросервисом статистических методов [6].

Архитектура нашей системы была разработана таким образом, чтобы точкой входа и точкой выхода было общее хранилище данных. Благодаря этому, все полученные знания о продуктовых метриках доступны любому аналитику. Но есть один большой минус — к хранилищу регулярно выполняется большое количество запросов и строятся дашборды. Нельзя допустить, чтобы запись большого объема данных от нашей системы нарушила работоспособность главного хранилища. Решается данная проблема с помощью ETL процессов сервиса Dataflow [10].

Как и во многих сервисах облачной платформы Google, техническим ядром Dataflow является Open Source решение, а именно Apache Beam https://beam.apache.org/. Это универсальная модель построения Batching ETL и Streaming ETL процессов.

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

Для этого система автоматически раз в неделю формирует персональные отчеты о выявленных крупных аномалиях. В этом нам все так же помогает сервис Composer [11]. Идея об ежедневных отчетах отошла на второй план, так как практика показывает, что люди не очень любят большое количество писем с графиками и цифрами, поэтому еженедельный дайджест оптимально отвечает необходимым потребностям в аналитической отчетности. Дополнительно для продуктивного взаимодействия системы с конечным пользователем была добавлена возможность отмечать выявленные аномалии как false positive [13]. Эти отметки будут использоваться для последующих итераций анализа данных.

Надеюсь, мне удалось концептуально изложить подход нашей команды к решению задачи автоматизированного анализа данных. Если обратиться к вопросу трудозатрат на разработку, то MVP удалось подготовить силами 1.5 разработчиков менее чем за 2 месяца, а ежедневная стоимость использования инфраструктуры Google Cloud Platform составляет 40$. Разработанное решение оказалось очень востребованным как аналитиками, так и высшим менеджментом компании, вследствие чего уже запланированы эксперименты с сервисами, предоставляющие инфраструктуру для машинного обучения.

П.С. Любите данные и метрики так же, как мы любим их в Xsolla!

Written by

Written by

Источник: medium.com

Комментарии: