Все еще измеряете latency в персентилях?

Latency — очевидная метрика, приходящая на ум почти всегда, когда дело доходит до мониторинга наших сервисов. Будь это простой контроллер, воркер, вычитывающий ивент из очереди, или сервис, делающий бэкап вашей монги — любой логический кусок кода, перформанс которого для нас важен. Рассмотрим простой пример: у вас есть сервис, принимающий запросы от пользователей и возвращающий на UI необходимые данные. Если этот сервис в продакшне и вы уже достаточно зрелый проект, вполне вероятно, что вы уже настроили метрики и мониторите их. А может даже настроили алерты, pagerduty, назначили on-call инженеров, отчитываетесь за выполнение своих SLA раз в месяц. Почти наверное один из алертов у вас будет на latency этого сервиса. И я попробую угадать — вы используете персентили в качестве статистики.

Угадал? А что если я скажу, что это не лучший вариант? Что если я пойду дальше и буду утверждать, что персентили могут скрывать серьезные изменения в latency после очередного деплоя? Давайте по порядку.

Начнем с быстрого обсуждения персентилей: что это и как инженеры их используют на ежедневной основе, чтобы отслеживать состояние сервисов, искать причины и следствия во время аутейджей, автоматически откатываться на предыдущий коммит во время деплоя с вашим рефакторингом после прочтения Фаулера, просыпаться в 3 ночи (утра?) от звонка на телефон с выключенным звуком, показывать красивые ровненькие графики трех девяток начальству…

Персентили

И так, у нас есть сервис и мы очень хотим отслеживать то, как быстро он отвечает. В этом случае под latency мы чаще всего понимаем время от получения запроса до момента, когда сервис готов вернуть результат (хотя бывают команды, которые включают в latency и другие вещи: например концом этого временного отрезка считают момент получения пользователем ответа. В нашем случае это не лучшая идея, ведь в эту метрику будет входить, например, скорость передачи данных по сети, а также все, что связано с encryption/decryption для шифрования). Собирая данные по этой величине для всех пользовательских запросов, можно отслеживать то, как быстро наш сервис работает, а так же то, как наши новые коммиты на эту скорость влияют. И есть много исследований, показывающих прямую зависимость между скоростью работы сервисов и удовлетворением пользователей (которое может выражаться, к примеру, в конверсиях новых пользователей в платящих), что добавляет ценности.

Пока все просто. Теперь предположим, что сервис весьма нагруженный, 100к запросов в секунду. Чтобы не отсылать в систему мониторинга данные об этой метрике с такой же частотой, мы хотим поступить умнее: на стороне сервиса собираем данные за 10 секунд, агрегируем их, а потом отсылаем в систему мониторинга. И вот тут мы наконец добрались до персентилей — это та самая статистика, которую мы используем для агрегации всех данных, чтоб отправить в систему мониторинга одно значение раз в 10 секунд. По сути мы просто отрезаем какую-то часть самых долгих запросов, которые могут исказить нашу картину, чтобы примерно представлять то, что видит основная часть наших пользователей. Например, p99 показывает максимальное значение после удаления 1% самых долгих запросов. Или другими словами: p99 превышает 99% всех значений, для агрегации которых мы используем эту статистику.

Предположим, что мы настроили алерт с условием, что три значения подряд не должны превышать 200ms. После месяца работы над новой версией сервиса, наконец пришло время деплоить! Сказано — сделано, деплоим и идем в графану проверять графики! Красная линия показывает момент деплоя.

Заметили разницу? Я нет. Идем показываем менеджеру график и отсутствие алертов, получаем повышение?

Нет. Или, менее критично — не так быстро. Выполнение SLA — дело хорошее, но мы еще хотим понимать динамику наших метрик после изменений, которые мы делаем. На первый взгляд все хорошо. Если, конечно, p99 дает нам достаточно информации о динамике. Давайте взглянем на две точки этого графика, зеленую и фиолетовую. Зеленая — последнее значение метрики перед деплоем. Фиолетовая — первое значение сразу после деплоя. А вот те реальные значения latency, которые привели к этим двум точкам после агрегации метрикой p99:

Упс! Уверен, теперь вы видите разницу. Хотя p99 одно и то же, очевидно, что latency после деплоя значительно изменилось. Даже хотя эти графики вымышленные, немного преувеличив для красоты можно сказать, что запросы пользователей стали обрабатываться в два раза дольше!

Проблема

Попробуем описать проблему простыми словами: персентили как статистика дают информацию об одной точке. Подумайте об этом: p90 показывает значение единственной точки, которое больше 90% всех значений. То есть применяя эту статистику мы теряем информацию обо всех значениях, кроме одного — остальные мы просто не рассматриваем. Что мы и увидели на графике выше — эта метрика недостаточно чувствительна чтобы отразить изменения среди этих 90% значений. А теперь подумайте о user experience: существует немало бизнесов, для которых такое значительное увеличение latency просто неприемлимо! Можем ли мы как-то улучшить ситуацию?

Trimmed mean

Можем! Trimmed mean статистика позволяет мониторить среднее значение среди выбранного диапазона данных, давая более аккуратное представление о реальном положении дел. Например, TM90 представляет собой среднее после удаления 10% самых больших значений (чтобы убрать флуктуации: не найдено значений в кэше и пришлось идти в базу, или downstream сервисы долго отвечали, или GC решил, что пора действовать). Trimmed mean более чувствительна к изменениям, которые не могут быть замечены при использовании персентилей!

Играясь с этой метрикой, можно получить хорошее представление о user experience. Например, TM(99% : ) показывает среднее значение среди 1% самых медленных запросов, а TM99 — среднее среди 99% самых быстрых запросов.

Чтобы продемонстрировать разницу, взглянем на предыдущий график, но дорисовав значения статистики TM90.

Легко видеть, что изменения после нашего деплоя не остались незамеченными! С правильно настроенным роллбэком, деплоем и нагрузочными тестами, проблемный коммит может даже не дойти до продакшн серверов. А разве не этого мы все хотим? 🙂 Надеюсь, эту статистику когда-нибудь добавят во все популярные системы мониторинга. Например, Amazon уже добавил в CloudWatch.

Нагружайте с удовольствием!