В мире ИТ непрерывно происходят эволюционные изменения, которые ставят во главу угла такие аспекты, как безопасность и надёжность решений.
К подобным изменениям, в частности, приводит развитие сервисов, которые должны работать с большим числом пользователей: онлайн-банкинг, маркетплейсы, сервисы покупки билетов и бронирования, бесконтактная оплата через POS-терминалы (вспомните, когда вы последний раз платили на кассе наличными?), оплата метро по Face ID, запрос и получение информации на Госуслугах и т.д.
Качественно создавать и развивать подобные сервисы сложно, к тому же, помимо понятных забот об удобстве, а также безопасности и сохранности личных данных, вас поджидают неочевидные риски, связанные именно с ростом числа пользователей. Именно здесь на помощь приходит нагрузочное тестирование. О нём ниже и поговорим, а также разберём конкретные жизненные примеры.
Постановка задачи:
Онлайн-сервис должен работать 24/7.
Сразу возникает вопрос, сможет ли он действительно работать в таком режиме? А если пользователей станет в 2—3 раза больше? А если объём передаваемой информации увеличится в 5–10 раз?
Ваши ожидания от сервиса такие: человек через браузер или из мобильного клиента или программа ваших партнёров по API приходят на сервис и должны получить запрошенную информацию достаточно быстро (устанавливается SLA — service level agreement — на время отклика) и без большого количества ошибок сервера и приложения (устанавливается SLA на допустимый процент ошибок).
В рамках современного функционального тестирования, состоящего из этапов юнит-тестирования, ФТ, ИТ, СТ, развёрнутого у вас или выполняемого силами привлечённых специалистов (outstaff), вы убедитесь в том, что код соответствует ТЗ и обладает нужным функционалом, но «нефункциональное» требование к производительности проверить не получится.
Решение:
Эту позицию закрывает нагрузочное тестирование.
Специалистам по нагрузочному тестированию (НТ) для его проведения понадобится специализированный стенд и доступы к инфраструктуре для анализа работы системы и подготовки к проведению НТ.
Способ решения:
Команда НТ приходит на проект и начинает свою работу:
По итогам этих работ вы получаете ответ на вопрос, сможет ли эта система на конкретном железе выдерживать поток запросов N-го количества пользователей, выполняющих определённое количество заданных операций?
«Под капотом»:
На этапе подготовки профиля обсуждается набор операций, которые будут выполняться в системе и эмулировать нагрузку.
Например, для сервиса «онлайн продажа билетов на концерт» это может быть:
Откуда НТ возьмёт эти цифры?
Два пути:
Прежде чем будет получен положительный ответ на вопрос, держит ли система нагрузку, НТ может найти дефекты производительности, которые надо будет исправлять.
Нагрузочное тестирование проводится на системе, которая уже вполне устраивает вас с точки зрения функциональности («у вас уже всё работает»), значит, времени на «всё тестирование» надо закладывать достаточно.
Краткий список возможных неприятностей:
Что при этом видит пользователь:
Причём до какого-то уровня нагрузки система живёт и успешно работает БЕЗ таких дефектов. Проблемы начинаются, предположим, с уровня нагрузки 300% профиля, а мы знаем, что иногда (3 раза в год) у вас, например, очень крутые концерты, и объём продаж возрастает в 5 раз (500% от среднего).
Проведённое НТ позволит вам заблаговременно масштабировать свой сервис, и вместо некрасивой 5хх с ещё менее красивым Java stack trace на первой странице вашего сайта компания будет продолжать работать и зарабатывать.
Эффективность легко подсчитать:
Компании, для которых недопустим простой (он очень дорого стоит) и которые не могут позволить себе, чтобы их имидж сильно пострадал, раз и навсегда включают НТ в процесс тестирования.
Если бизнес успешен на рынке, то недоступность сервиса в «горячий» сезон фактически приведёт к «выходу из игры».
Наш условный сайт по продаже билетов успешно работает в продуктиве. Если бизнес развивается, то продолжаются и такие процессы:
а) маркетологи/бизнес придумывают новые интересные кампании для привлечения клиентов;
б) маркетологи/бизнес хотят расширить функционал (добавить ещё несколько кнопок/упростить переход к оплате/добавить ещё несколько шагов до перехода к оплате/разветвить процесс покупки и т.д.);
в) появляются новые требования госорганов (надо реализовать какую-либо проверку, то есть добавился запрос во внешнюю систему);
г) приходят функциональные дефекты от пользователей.
По итогам а), б), в) и г) разработчики дорабатывают функционал, тестирование проходит все стадии, включая системное.
Разумеется, надо убедиться, что новая версия «держит» текущую нагрузку (или выдержит планируемое увеличение нагрузки).
Иными словами, НТ по аналогии с другими видами тестирования — это непрерывный процесс, необходимый для нагруженных систем.
Решение регулярно проходит НТ и успешно работает в продуктиве, но внезапно принимается обоснованное решение миграции на другую архитектуру: более современное железо с более новой версией ОС, которые будут поддерживаться ещё лет 10, в отличие от текущего.
Бизнес устроен таким образом, что остановить операции невозможно.
Решение:
Обсуждаем пошаговый сценарий миграции.
С помощью инструментов нагрузочного тестирования подаём на систему расчётную нагрузку.
Наблюдаем за поведением системы на тестовом стенде в процессе миграции.
Результат:
По инструкции, отработанной в НТ, система успешно переехала с ОС на ОС и с железки на железку, в то время как пользователи непрерывно продолжали ей пользоваться.
В ходе эксплуатации из продуктива приходят функциональные дефекты и могут приходить дефекты производительности.
По результатам таких инцидентов мы при необходимости актуализируем методику нагрузочного тестирования.
Внешняя система реализовала у себя новые требования, обновилась и стала давать ответы размера 1Мб, вместо 10Кб, система даёт свой ответ клиентам за 10 секунд, а не за 1.
Решение:
Увеличиваем размер ответов на тестовом стенде, воспроизводим «новое поведение», проводим полноценное нагрузочное тестирование, понимаем, на каком уровне нагрузки система удовлетворяет требованиям ко времени отклика, добавляем ресурсов, проверяем, что более мощная система выдерживает нужный уровень нагрузки.
Результат:
Система работает в соответствии с поставленными требованиями в новых условиях.
Отдел маркетинга разработал новую акцию: «Купи три пылесоса по цене четырёх и получи один бесплатно». Кто же откажется. Дорогая реклама идёт по всем возможным каналам с охватом всей целевой аудитории. Люди массово приходят за покупками на сайт.
Это хорошо, но откуда мы знаем, что система справится с нагрузкой, а не рухнет?
Ведь тогда средства, выделенные на рекламу, придётся записать в расход, о прибыли компании можно будет забыть, а имидж будет испорчен раз и навсегда: те же каналы, что давали рекламу, с удовольствием (и на этот раз бесплатно!) расскажут о том, что сайт упал.
Решение:
Берём информацию от маркетинга по увеличению нагрузки по определённым операциям и проводим стресс-тест.
Результат:
Ваши оправданные ожидания.
Постановка:
Сотруднику поручают выполнить занудную операцию: надо несколько тысяч раз без ошибок в ручном вводе данных пройти длинный кейс из 5–6 экранов.
Печально оценивая объём работы (пару дней с утра до вечера), смекалистый сотрудник вспоминает, что «чем-то похожий функционал» он видел в другом модуле системы, причём если делать там, то выполнить всю эту работу можно за полчаса с перекурами. Находчиво? Не то слово! Воображение рисует моментальный апгрейд из операциониста в программиста, а то и архитектора решения. Однако что-то пошло не так. Кто уже угадал, что случилось? А получилось вот что: при попытке выполнения операции не из того модуля, откуда её положено делать по инструкции, а при использовании совсем другого, генерируется неоптимальный запрос в БД, которого разработка делать не планировала (смотрите ТЗ), что приводит к блокировкам. В продуктиве DBA разобрались и срубили этот запрос на БД. Система вернулась в нормальный рабочий режим через несколько часов простоя.
Решение:
Операционисты должны уметь работать с системой.
Постановка:
Без проверки со стороны НТ внедряется процедура архивации на БД. Функционально она работает. Зачем именно в продуктиве проверять её под нагрузкой, если собран стенд нагрузочного тестирования? Для нас это осталось загадкой. В продуктиве произошла блокировка на БД, и система не работала, по-моему, сутки.
Решение:
Так как компания имела команду нагрузочного тестирования, вопрос был решён так: воспроизвели дефект на стенде НТ и разработали рекомендации, чтобы больше такого не повторилось. Это тоже часть работ по нагрузочному тестированию. И лучше такие вещи проверить на стенде НТ, чем стрессировать поддержку на продуктиве (коллеги, мы знаем, что вам обычно хватает забот).
По результатам разработки и тестирования (все этапы функционального и НТ) получается продукт с известными характеристиками и инструкциями использования.
Уберите любую составную часть этого комплекса, и «органолептические» свойства продукта изменятся непредсказуемо.
Нагрузочное тестирование — по сути, моделирование нагрузки. Для того чтобы наша модель лучше соответствовала действительности, надо:
Можно ли проводить НТ (и спойлер) как это сделать, если пункты 1 и 2 выше не выполнены, это тема для отдельной статьи. Stay tuned.
К подобным изменениям, в частности, приводит развитие сервисов, которые должны работать с большим числом пользователей: онлайн-банкинг, маркетплейсы, сервисы покупки билетов и бронирования, бесконтактная оплата через POS-терминалы (вспомните, когда вы последний раз платили на кассе наличными?), оплата метро по Face ID, запрос и получение информации на Госуслугах и т.д.
Качественно создавать и развивать подобные сервисы сложно, к тому же, помимо понятных забот об удобстве, а также безопасности и сохранности личных данных, вас поджидают неочевидные риски, связанные именно с ростом числа пользователей. Именно здесь на помощь приходит нагрузочное тестирование. О нём ниже и поговорим, а также разберём конкретные жизненные примеры.
Разберём конкретный кейс: прекрасный клиентоориентированный сервис
Постановка задачи:
Онлайн-сервис должен работать 24/7.
Сразу возникает вопрос, сможет ли он действительно работать в таком режиме? А если пользователей станет в 2—3 раза больше? А если объём передаваемой информации увеличится в 5–10 раз?
Ваши ожидания от сервиса такие: человек через браузер или из мобильного клиента или программа ваших партнёров по API приходят на сервис и должны получить запрошенную информацию достаточно быстро (устанавливается SLA — service level agreement — на время отклика) и без большого количества ошибок сервера и приложения (устанавливается SLA на допустимый процент ошибок).
В рамках современного функционального тестирования, состоящего из этапов юнит-тестирования, ФТ, ИТ, СТ, развёрнутого у вас или выполняемого силами привлечённых специалистов (outstaff), вы убедитесь в том, что код соответствует ТЗ и обладает нужным функционалом, но «нефункциональное» требование к производительности проверить не получится.
Решение:
Эту позицию закрывает нагрузочное тестирование.
Специалистам по нагрузочному тестированию (НТ) для его проведения понадобится специализированный стенд и доступы к инфраструктуре для анализа работы системы и подготовки к проведению НТ.
Способ решения:
Команда НТ приходит на проект и начинает свою работу:
- Выясняет архитектуру системы.
- Собирает статистику по операциям и создаёт профиль нагрузочного тестирования.
- Обсуждает с вами методику нагрузочного тестирования.
- Готовит пулы данных.
- Пишет скрипты.
- Настраивает мониторинг.
- Проводит тесты, регистрирует дефекты.
- Проводит ретесты по исправлениям дефектов.
- Готовит отчёт.
- … ??
- (Ваш) PROFIT.
По итогам этих работ вы получаете ответ на вопрос, сможет ли эта система на конкретном железе выдерживать поток запросов N-го количества пользователей, выполняющих определённое количество заданных операций?
«Под капотом»:
На этапе подготовки профиля обсуждается набор операций, которые будут выполняться в системе и эмулировать нагрузку.
Например, для сервиса «онлайн продажа билетов на концерт» это может быть:
- 30 000 операций в час — посмотреть расписание.
- 20 000 операций в час — посмотреть наличие билетов.
- 10 000 операций в час — оформить покупку, но не оплатить её, а закрыть браузер.
- 2000 операций в час — оформить покупку и оплатить её.
Откуда НТ возьмёт эти цифры?
Два пути:
- Изучение статистики (включая исторические данные, с учётом сезонности и связанных с ней пиков или их отсутствием).
- Бизнес знает/прогнозирует определённое количество этих операций.
Прежде чем будет получен положительный ответ на вопрос, держит ли система нагрузку, НТ может найти дефекты производительности, которые надо будет исправлять.
Нагрузочное тестирование проводится на системе, которая уже вполне устраивает вас с точки зрения функциональности («у вас уже всё работает»), значит, времени на «всё тестирование» надо закладывать достаточно.
Что может пойти не так? Для чего все эти недешёвые мучения?
Краткий список возможных неприятностей:
- В системах с БД под нагрузкой могут пойти блокировки или увеличится время отклика по причине неоптимальных запросов, неудачной структуры хранения данных и т.п.
- На веб-сферах могут быть неоптимальные настройки.
- Микросервисам Кубернет может не хватать ресурсов.
- Приложение может использовать всю оперативную память и рухнуть с неприятной Out Of Memory Error.
Что при этом видит пользователь:
- Отказ в обслуживании («легла» БД, исчерпались потоки на веб-сфере, ушёл в множественные перезагрузки pod в Кубернетах).
- Ответ от сервиса приходит не за 1 секунду, а за 10 (сухим языком звучит нестрашно «превышение SLA на время отклика»).
- Сервер чаще чем надо отдаёт ошибку 5хх, или приложение при своей работе даёт много ошибок («превышение SLA на процент ошибок»).
Причём до какого-то уровня нагрузки система живёт и успешно работает БЕЗ таких дефектов. Проблемы начинаются, предположим, с уровня нагрузки 300% профиля, а мы знаем, что иногда (3 раза в год) у вас, например, очень крутые концерты, и объём продаж возрастает в 5 раз (500% от среднего).
Проведённое НТ позволит вам заблаговременно масштабировать свой сервис, и вместо некрасивой 5хх с ещё менее красивым Java stack trace на первой странице вашего сайта компания будет продолжать работать и зарабатывать.
Эффективность легко подсчитать:
Компании, для которых недопустим простой (он очень дорого стоит) и которые не могут позволить себе, чтобы их имидж сильно пострадал, раз и навсегда включают НТ в процесс тестирования.
Если бизнес успешен на рынке, то недоступность сервиса в «горячий» сезон фактически приведёт к «выходу из игры».
Что дальше?
Наш условный сайт по продаже билетов успешно работает в продуктиве. Если бизнес развивается, то продолжаются и такие процессы:
а) маркетологи/бизнес придумывают новые интересные кампании для привлечения клиентов;
б) маркетологи/бизнес хотят расширить функционал (добавить ещё несколько кнопок/упростить переход к оплате/добавить ещё несколько шагов до перехода к оплате/разветвить процесс покупки и т.д.);
в) появляются новые требования госорганов (надо реализовать какую-либо проверку, то есть добавился запрос во внешнюю систему);
г) приходят функциональные дефекты от пользователей.
По итогам а), б), в) и г) разработчики дорабатывают функционал, тестирование проходит все стадии, включая системное.
Разумеется, надо убедиться, что новая версия «держит» текущую нагрузку (или выдержит планируемое увеличение нагрузки).
Иными словами, НТ по аналогии с другими видами тестирования — это непрерывный процесс, необходимый для нагруженных систем.
Кейсы из реальной жизни
Задача А
Решение регулярно проходит НТ и успешно работает в продуктиве, но внезапно принимается обоснованное решение миграции на другую архитектуру: более современное железо с более новой версией ОС, которые будут поддерживаться ещё лет 10, в отличие от текущего.
Бизнес устроен таким образом, что остановить операции невозможно.
Решение:
Обсуждаем пошаговый сценарий миграции.
С помощью инструментов нагрузочного тестирования подаём на систему расчётную нагрузку.
Наблюдаем за поведением системы на тестовом стенде в процессе миграции.
Результат:
По инструкции, отработанной в НТ, система успешно переехала с ОС на ОС и с железки на железку, в то время как пользователи непрерывно продолжали ей пользоваться.
В ходе эксплуатации из продуктива приходят функциональные дефекты и могут приходить дефекты производительности.
По результатам таких инцидентов мы при необходимости актуализируем методику нагрузочного тестирования.
Задача Б
Внешняя система реализовала у себя новые требования, обновилась и стала давать ответы размера 1Мб, вместо 10Кб, система даёт свой ответ клиентам за 10 секунд, а не за 1.
Решение:
Увеличиваем размер ответов на тестовом стенде, воспроизводим «новое поведение», проводим полноценное нагрузочное тестирование, понимаем, на каком уровне нагрузки система удовлетворяет требованиям ко времени отклика, добавляем ресурсов, проверяем, что более мощная система выдерживает нужный уровень нагрузки.
Результат:
Система работает в соответствии с поставленными требованиями в новых условиях.
Задача В
Отдел маркетинга разработал новую акцию: «Купи три пылесоса по цене четырёх и получи один бесплатно». Кто же откажется. Дорогая реклама идёт по всем возможным каналам с охватом всей целевой аудитории. Люди массово приходят за покупками на сайт.
Это хорошо, но откуда мы знаем, что система справится с нагрузкой, а не рухнет?
Ведь тогда средства, выделенные на рекламу, придётся записать в расход, о прибыли компании можно будет забыть, а имидж будет испорчен раз и навсегда: те же каналы, что давали рекламу, с удовольствием (и на этот раз бесплатно!) расскажут о том, что сайт упал.
Решение:
Берём информацию от маркетинга по увеличению нагрузки по определённым операциям и проводим стресс-тест.
Результат:
Ваши оправданные ожидания.
«Нарочно не придумаешь» (случаи из жизни)
Задача Г
Постановка:
Сотруднику поручают выполнить занудную операцию: надо несколько тысяч раз без ошибок в ручном вводе данных пройти длинный кейс из 5–6 экранов.
Печально оценивая объём работы (пару дней с утра до вечера), смекалистый сотрудник вспоминает, что «чем-то похожий функционал» он видел в другом модуле системы, причём если делать там, то выполнить всю эту работу можно за полчаса с перекурами. Находчиво? Не то слово! Воображение рисует моментальный апгрейд из операциониста в программиста, а то и архитектора решения. Однако что-то пошло не так. Кто уже угадал, что случилось? А получилось вот что: при попытке выполнения операции не из того модуля, откуда её положено делать по инструкции, а при использовании совсем другого, генерируется неоптимальный запрос в БД, которого разработка делать не планировала (смотрите ТЗ), что приводит к блокировкам. В продуктиве DBA разобрались и срубили этот запрос на БД. Система вернулась в нормальный рабочий режим через несколько часов простоя.
Решение:
Операционисты должны уметь работать с системой.
Задача Д
Постановка:
Без проверки со стороны НТ внедряется процедура архивации на БД. Функционально она работает. Зачем именно в продуктиве проверять её под нагрузкой, если собран стенд нагрузочного тестирования? Для нас это осталось загадкой. В продуктиве произошла блокировка на БД, и система не работала, по-моему, сутки.
Решение:
Так как компания имела команду нагрузочного тестирования, вопрос был решён так: воспроизвели дефект на стенде НТ и разработали рекомендации, чтобы больше такого не повторилось. Это тоже часть работ по нагрузочному тестированию. И лучше такие вещи проверить на стенде НТ, чем стрессировать поддержку на продуктиве (коллеги, мы знаем, что вам обычно хватает забот).
Вместо вывода
По результатам разработки и тестирования (все этапы функционального и НТ) получается продукт с известными характеристиками и инструкциями использования.
Уберите любую составную часть этого комплекса, и «органолептические» свойства продукта изменятся непредсказуемо.
Нагрузочное тестирование — по сути, моделирование нагрузки. Для того чтобы наша модель лучше соответствовала действительности, надо:
- Такую же БД (личные данные в ней только обезличьте (сами или закажите эти работы у специалистов).
- Такие же машинные ресурсы, как на продуктиве.
Можно ли проводить НТ (и спойлер) как это сделать, если пункты 1 и 2 выше не выполнены, это тема для отдельной статьи. Stay tuned.