Что такое нагрузочное тестирование и кто такой инженер-нагрузочник в ЮMoney
Привет, меня зовут Анатолий Пласковский, я руковожу отделом нагрузочного тестирования в ЮMoney. Мы исследуем производительность платёжной системы и готовимся к горячему сезону распродаж весь год, чтобы потом наши клиенты могли продавать свои товары миллионам покупателей без сбоев, а система выдерживала нагрузку не менее 600 транзакций в секунду.
Рассказываю, как мы тестируем производительность в ЮMoney, какие инструменты для этого используем и какой он — идеальный инженер нагрузочного тестирования.
Что такое нагрузочное тестирование
Это нефункциональный вид тестирования, который показывает, как система работает под большим потоком пользователей, которые к ней подключаются.
Что мы тестируем в ЮKassa:
Обычную ежедневную пользовательскую активность внутри системы.
Большие притоки пользовательской активности, когда к платёжной системе подключаются новые крупные компании.
Большие притоки пользовательской активности, когда платёжная система готовится к сезону распродаж и акций.
В последнем случае нагрузка на систему может быть колоссальной — до пяти тысяч транзакций в секунду. Чтобы компании и их клиенты остались довольны, мы готовимся к периоду распродаж целый год: тестируем новые сценарии, обеспечиваем определённые мощности системе, разгоняем её и ускоряемся на максимум. В итоге всё всегда проходит успешно: наши клиенты оформляют заказы без сбоев и в больших количествах, а покупатели получают их вовремя и в полном объёме.
Тестировать производительность системы можно на тестовой среде или сразу на продакшене
Нагрузка в России развивается по-разному. Есть сторонники классического подхода, при котором нагрузка происходит только на тестовой среде и не ходит на продакшен. Это подразумевает прогон большого числа тестов даже там, где они не нужны, потому что у нагрузки специфическое покрытие. Ты не обязан покрывать все процессы — только те, которые активно используются. Это всегда элемент точечного исследования и тюнинга.
Мы в ЮMoney занимаемся производительностью не только на тестовой среде, но и на своём продакшене, в связке с контрагентами и клиентами ЮKassa. Так мы проверяем производительность одновременно с трёх сторон:
Внутри платёжной системы ЮKassa, которая получает потоки (заявки) от клиентов и перенаправляет их банкам-эквайерам.
На стороне клиентов, которые отправляют нам эти потоки (заявки).
На стороне банков-эквайеров, которые потом обрабатывают транзакции от наших клиентов.
Безопасно ли это? Да. Мы выработали ряд механизмов, которые снижают вероятность инцидентов, связанных с нашим воздействием на продакшен.
Мы — как Доктор Хаус: всё, что делаем, мы делаем с целью поставить диагноз системе, найти узкие места и устранить их. Но прелесть в том, что на смену исправленным узким местам всегда приходят новые. Поэтому нам всегда есть чем заняться.
Как понять, что компании нужно нагрузочное тестирование
Есть два сценария, когда компании начинают заниматься тестированием производительности:
Они провели глубокую аналитику и решили внедрить это ещё до того, как появились проблемы.
У них уже есть проблемы с производительностью, поэтому медлить больше нельзя.
Второй вариант — самый распространённый и, по сути, самый правильный. Зачем решать проблему до того, как она появилась? В ЮMoney нагрузочное тестирование внедрили десять лет назад, когда столкнулись с инцидентами на продакшене. Все эти годы мы посвятили тому, чтобы решать проблемы с производительностью и предотвращать их повторение. У нас появилось много разных инструментов и подходов, мы построили внутри компании целую систему, которая работает и совершенствуется до сих пор. Поэтому у нас уже лет пять нет проблем, связанных со стабильностью продакшена во время экспериментов с нагрузочным тестированием.
Инженер, в отличие от тестировщика, доводит дело до конца любой ценой, независимо от должности, и не боится привлекать помощников там, где не хватает экспертизы.
Какие бывают проблемы и узкие места
Бывают логические проблемы в коде, которые мы разбираем и оптимизируем с коллегами из разработки.
Бывает, что вместе с ребятами из инфраструктуры находим новое железо или подкручиваем скейлинг, оркестрацию, ищем новые балансировщики или способы балансировки.
Или наоборот: общаемся с представителями бизнеса и решаем вопросы не техническим способом, а с помощью переговоров. Переговоры — лучший инструмент инженера нагрузочного тестирования. Такому специалисту важно уметь общаться и договариваться.
Сейчас все процессы для исследования производительности в ЮMoney автоматизированы и мы можем провести любое количество необходимых экспериментов, чтобы выявить узкое место. На одном из наших недавних мероприятий, митапе для QA-специалистов BugsBusters, мы рассказали, с какими сложностями столкнулись во время тестирования перехода от сессионного к транзакционному режиму пула pgBouncer и какие пять экспериментов провели.
Кто такой инженер нагрузочного тестирования и как он работает
Инженер нагрузочного тестирования смотрит, как система функционирует и взаимодействует с разными своими составляющими под большим потоком конкурирующих между собой запросов. По сути, это можно сравнить с поведением покупателей в больших магазинах во время распродаж в Чёрную пятницу: все ломятся в одну дверь и не дают друг другу пройти.
Процесс нагрузочного тестирования выглядит так: мы получаем задачу проверить нагрузку и смотрим, что нужно сделать. На тестовой среде, которая эмулирует большой приток пользователей, воспроизводим поведение системы и восстанавливаем ситуацию, в которой была зафиксирована проблема. Если всё получается и проблему удаётся воспроизвести, вносим правки любым доступным нам способом, потом выкатываем это на продакшен и смотрим, как это всё там работает. Если по каким-то причинам тестовая среда и продакшен в чём-то отличаются друг от друга, мы идём выяснять, нет ли проблемы в самом продакшене и не нужно ли там что-то подкрутить.
До моего прихода в ЮMoney не было отдела тестирования производительности, но коллеги делали первые пробы пера: смотрели, какую нагрузку ставят партнёры компании, какие методики и инструменты можно у них перенять. Когда я присоединился к команде и начал формировать отдел, я познакомился с разными людьми, которых отличало одно интересное качество: все они были страстными энтузиастами. Не просто сидели на работе с девяти до шести, выполняя поставленные задачи, а генерировали оригинальные идеи, исследовали проблемы со всех сторон, тестировали гипотезы и искали новые решения. Именно поэтому мне близка советская инженерная школа — тогда инженерами были не по должности, а по образу жизни и мышления. Я хотел культивировать в ЮMoney такой подход, и у меня это получилось.
Процесс исследования производительности — то, куда каждый сотрудник привносит что-то своё: знания, идеи, искреннее желание сделать продукт лучше
И в ЮMoney, и на рынке в целом инженеры нагрузочного тестирования стали стремиться быть как SRE-инженеры, то есть развиваться многосторонне. Я считаю, что сегодня это один из главных трендов в нагрузочном тестировании. Мы не ограничиваем себя в экспериментах, способах, методах, много чего пробуем. Для каждого интересного эксперимента стараемся подобрать оптимальный набор инструментов и, если нужно, подключаем что-то новое. А экспертиза в разработке и инфраструктуре позволяет меньше обращаться за помощью к другим командам, не тревожить их и не отвлекать от работы.
Но иногда всё же приходится заходить к специалистам — экспертам из другой области, чтобы с ними советоваться. А порой и взаимодействовать напрямую — садиться и делать каждый новый эксперимент вместе. При этом ты отвечаешь за свою работу, они — за свою, а все вместе вы отвечаете за производительность.
Инженер, в отличие от тестировщика, доводит дело до конца любой ценой, независимо от должности, и не боится привлекать помощников там, где не хватает экспертизы.
Про инструменты инженера нагрузочного тестирования
В качестве эмулятора большого потока пользователей можно взять генератор трафика. Десять лет назад мы в ЮMoney начинали на простейшем — JMeter. Это удобный и доступный инструмент с графическим интерфейсом. В нём можно даже записать поток трафика и потом продублировать его, не погружаясь в детали. Но сегодня мы отказались от него в пользу более удобных инструментов.
Вот какие ещё инструменты используют в работе инженеры нагрузочного тестирования ЮMoney:
Генераторы трафика: Yandex.Tank, k6.
Разработка: TechRadar, ESLint, Helm, Black, Pre-commit, Mypy, Conventional Commits, Poetry, Helm, Documentation as Code.
Языки: Python, JavaScript (косвенно Kotlin, Java).
Фреймворки: Plotly, FastAPI, Loguru, Aiogram, Testcontainers, Vue.js, Axios, Lighthouse, SQLAlchemy, NiceGUI.
Кстати, сейчас ЮMoney как раз в поиске ещё одного специалиста по тестированию производительности. Откликайтесь на вакансию и приходите на собеседование — или делитесь ссылкой с друзьями. С удовольствием с вами пообщаемся.
Пять главных выводов
Нагрузочное тестирование позволяет подготовить систему к большим нагрузкам, например на время сезонных распродаж, и предотвратить возможные сбои.
Большинство компаний запускает нагрузочное тестирование после того, как сталкивается с проблемами и инцидентами на продакшене. Это правильно: незачем тратить ресурсы на тестирование производительности, когда нет проблем.
Лучше тестировать нагрузку и на тестовой среде, и на продакшене — именно так мы делаем в ЮMoney. Потому что, если на продакшене есть проблемы, вы не увидите их во время теста на эмуляторе, зато столкнётесь с ними потом, и это будет больнее.
Идеальный нагрузочник — это не тестировщик, а инженер-энтузиаст советского образца, не ограниченный своей сферой ответственности. Он постоянно учится новому, экспериментирует и пробует новые инструменты. Может заменить сразу нескольких специалистов, может без труда попросить помощи у коллег и протестировать производительность системы вместе с ними.
Если у вас большой интернет-магазин и в сезон повышенной активности, например во время осенне-зимних распродаж, есть колоссальная нагрузка на систему, начинайте тестировать её производительность хотя бы за два-три месяца до акций. Это придаст вам уверенности в том, что в нужный день всё пройдёт хорошо: клиенты получат свои заказы, а вы — желанную прибыль.
