Hit-based: как нагрузить прод, не написав ни одного сценария

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

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

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

Сначала модель, потом инструмент

Доклад начинается не с инструментов, а с вопроса, как генератор должен вести себя, когда система затормозила. Приходько называет это фундаментальным техническим заданием для теста [03:00].

Открытая модель объясняется через кота, которому заказывают корм. Магазину поплохело, он начал тормозить — и что делают пользователи? Жмут обновление страницы. Прежние запросы система всё ещё обрабатывает, а сверху валятся новые. Причём тормозить начинает и у тех, кто корм не заказывал, так что обновляют страницу и они [04:00].

Такой тип нагрузки считается самым тяжёлым для информационных систем.

Закрытая модель — это кормушка на два места и ограниченное число котов в очереди. Никто не приходит извне, коты ждут, пока освободится слот [05:00].

Практический вывод сформулирован прямо: если ваша система торчит в интернет, она работает по открытой модели, и подавать нагрузку надо тоже по открытой [07:00].

Тут стоит добавить от себя. Это ровно то следствие, которое даёт закон Литтла: при фиксированном числе виртуальных пользователей рост времени ответа автоматически снижает нагрузку. Доклад приходит к тому же выводу через поведение живых пользователей, а не через формулу.

Что не так со сценариями

Сценарий — это логически связанная последовательность запросов, воспроизводящая абстрактного пользователя. Приходько сразу называет её синтетикой и говорит, что воспроизвести сценарным подходом реалистичную модель продакшена крайне трудозатратно [08:00].

Чтобы запросы не шли стеной, между ними ставят случайные задержки, а между итерациями сценария — пейсинг [09:00]. Пользователей запускают не разом, а постепенно, чтобы получить распределение, похожее на нормальное [10:00].

Отдельный момент, который часто упускают. Сценарии можно гнать и в открытой модели, но тогда вы оперируете не числом виртуальных пользователей, а темпом прихода новых. В JMeter за это отвечают плагины Arrivals и Open Model Group. Сценарная часть тестов Ozon работает именно так [11:00].

Главная претензия к сценариям — стоимость владения:

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

И следом наблюдение про отрасль: команды со сложными сценариями держат отдельных инженеров только на поддержке одного теста, и чаще всего это банки, потому что там содержать такой штат дешевле, чем не содержать [12:00].

Hit-based

Идея простая. Если запрос читающий и идемпотентный, сценарий ему не нужен: отправили один и тот же запрос, получили один и тот же ответ [13:00].

Приходько отдельно отмечает, что информации об этом подходе в интернете почти нет и в книгах он его не встречал.

Готовится это в четыре шага.

Собрать логи продакшена и разложить по классам. Логи грузятся в базу, дальше аналитика: каждому запросу присваивается тег — поиск, создание заказа, положить в корзину. Для больших объёмов рекомендуется ClickHouse, для скромных хватит PostgreSQL [15:00].

Отделить пишущие запросы от читающих. И вот главное число доклада:

Всего-то пишущей нагрузки у нас 10% от всей остальной, всё остальное — это чтение.

Для интернет-магазина основной трафик читающий, и его можно грузить без единого сценария [16:00].

Подготовить патроны. Из размеченных логов собирается файл с запросами, по которому генератор итерируется. В Ozon это десятки гигабайт [26:00]. Инструменты называются свои: Yandex.Tank, Pandora, JMeter [17:00].

Прогнать и следить за покрытием. Нужен параметр, который покажет появление запросов, ещё не попавших в систему тегирования [21:00].

Три грабли, о которых обычно молчат

Их стоит выписать отдельно, потому что они ломают реалистичность незаметно [18:00].

Кеш. Подготовленные запросы могут все попадать в кеш, и вы измерите скорость кеша, а не системы.

Авторизация. Часть трафика авторизована, часть нет, и это соотношение надо воспроизвести, а не усреднить.

Регион. Если весь трафик идёт с одних и тех же адресов, поиск отдаёт региональную выдачу не так, как в реальности.

Есть и запасной вариант на случай, когда доступа к логам не дают: профиль можно собрать по метрикам Prometheus, считая обращения к ручкам [23:00].

Как это устроено в Ozon

Микс. Девяносто процентов трафика закрывает hit-based, десять — сценарии, которые гоняются параллельно [23:00]. Нагрузочных тестировщиков в команде четверо [28:00].

Своя таблица сравнения из доклада [24:00]–[27:00]:

	Сценарный	Hit-based	Микс
Сложность разработки	высокая	от низкой до средней	высокая
Сложность поддержки	высокая	низкая	средняя
Стоимость доработок	высокая	низкая	средняя
Репрезентативность	низкая	высокая	высокая

Про низкую репрезентативность сценариев сказано через эффект пестицида: на проверяемом шаге всё хорошо, шаг влево или вправо — начинаются жуткие тормоза.

Про простоту разбора у hit-based замечание практичное: отдельный запрос проще проверить курлом и сразу увидеть, что пошло не так, чем воспроизводить целый сценарий [27:00].

Чего в докладе нет

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

И ещё одно, что стоит сказать честно. Hit-based требует подробных логов, а к ним нужен доступ. Приходько прямо говорит, что придётся общаться с информационной безопасностью и что это не всегда получается легко [22:00].

Что забрать с собой

Откройте свой самый большой сценарий и посмотрите, сколько шагов в нём действительно требуют состояния от предыдущего запроса.

В докладе есть ровно это наблюдение: часто сценарий разрастается до огромных размеров, хотя из него можно было сделать два — сценарный на четыре запроса и hit-based на всё остальное [28:00].