Как создать отказоустойчивый онлайн продкут, которому не страшны пиковые нагрузки
Разберем какие требования к нагрузкам и отказоустойчивости закладывать для сайта или приложения и как их контролировать. Заметка для владельцев и менеджеров проектов, чтобы не провалиться при запуске или масштабировании.
Приведу 2 главных инструмента, которые мониторят и прогнозируют работоспособность системы под нагрузкой.
Нагрузочное тестирование и стресс-тесты
В первую очередь делаем нагрузочные и стресс-тесты бекэнд части проекта, так как повышенная нагрузка, включая пиковые значения, влияет на скорость и работоспособность сервера.
Перед нагрузочным и стресс-тестом не забудьте убедиться, что функциональное тестирование продукта завершено, иначе дефекты и баги разработки размоют всю картину.
Пишем тест-кейс
Нам нужна последовательность запросов, которые совершает приложение или сайт, эмулируя действия пользователя. Для этого опишите пользовательский сценарий в продукте:
- Авторизация
- Открытие главной страницы
- Открытие каталога
- Открытие товара
- Добавление товара в корзину
- Фоновое обновление корзины
- Установка региона, города и адреса в корзине итд
Каждый шаг сценария подразумевает запросы к API и будет создавть нагрузку для сервера.
Проводим тест
Методика тестирования заключаеется в том, чтобы сэмулировать нагрузку на сервер и зафиксировать результаты. В качестве инструмента используем Apache JMeter, Яндекс.tank и другие решения.
Начать тестирование можно с пяти повторов, зауская одновременно: 100, затем 200, 500, 750 и 1000 потоков обращений.
Каждый поток — запущенный текст-кейс, где последовательно выполняются его шаги.
Разумеется, интервалы между запросами живого человека будут больше чем последовательный расстерл сервера тестовыми запросами. 1 поток может быть равен 5 или 10 онлайн пользователей, в зависимоти от модели взаимодествия с продуктом. То есть, запуская тест в 100 потоков, мы эмулируем нагрузку, которую создают 500 онлайн-пользователей.
Учитывая среднюю частоту покупок и ретеншн можно предположить какая клиентская база нужна для 500 онлайн-пользователей. Особое внимание стоит уделить стресс-тестам и пикам, которые создает сезонность, маркетинговые рассылки, реклама итд — дьявол обычно кроется именно тут.
Измеряем результат
Базовая метрика — RPS (request per second), она показывает какое количество запросов в секунду выдерживает ваш сервер.
Отслеживаем также:
абсолютное количество ошибок (шт), относительное количество ошибок (%), время выполнения теста (с), время отклика (мс).
Допустим, мы запустили 100 одновременных потоков и сценарий текст-кейса предполагает 20 обращений к серверу (т. е.100 потоков сгенерировали 2 000 запросов), тест прошел без ошибок за 10 секунд.

Тут же видно, что в районе 750 одновременно активных потоков, наблюдается появление ошибок доступа к серверу. Логи ошибок передаем разработке.
С работоспосбностью понятно, давайте изучим производительность — для этого смотрим на время отклика каждого метода API, к которому мы делаем запросы.

Таким образом вы найдете слабые места сервера, которые тормозят сайт и приложение, упростите или уберете лишние обращения к базе данных, поднимите конфигурационные характеристики и оптимизируете работу всей системы.
Как повысить скорость и отказоустойчивость сервера
- В первую очередь — за счет правильной архитектуры проекта еще на этапе разработки, чтобы масштабироваться горизонтально, балансировать нагрузку, дублировать базы и приложения на разных нодах, использовать микросервисную архитекрутру вашего приложения.
- Второй вектор — за счет вертикального прироста производительности железа серверов.
Если оказались в ситуации, когда ваш программный продукт не справляется с количеством клиентов, а у вас cерьезные планы по росту бизнеса и выходам на рынки, чем раньше вы обратитесь к специлистам, тем лучше.
Когда к масштабированию не готовились изначально, это означает, что систему придется разработать заново.
Система мониторинга — Health Monitoring System (HMS)
Крутой инструмент для уже запущенных проектов — круглосуточно и автоматически мониторит API на работоспособность и быстродействие, собирает логи, формирует отчеты о всех событиях и сигнализирует, если запросы мобильного приложения или сайта не обрабатываются, либо скорость ответа сервера упала.
Высший пилотаж — добавление системы автоскейлинга, автоматического масшабирования ресурсов на сервере, в зависимости от роста нагрузки.
К стати, в систему мониторинга рекомендую добавить и баг-репорты, которые пользователи отправляют в техподдержку, плюс подтягивать отзывы из App Store и Google Play (например, через AppFollow или другие агрегаторы).
Таким образом в одном месте собираются серерные логи, данные автотестов и техподдержки, так быстрее находить взаимосвязи и причины сбоев.
Круто делать оповещения о внештатрных ситуциях через Telegram-чат или другой месенджер, либо СМС.
Узнать как мы реализуем Health Monitoring System на своих проектах
Система мониторинга предупреждает и помогает быстро купировать критические ситуции, сохраняет нервы, деньги и репутацию продукта.
Cкорость работы мобильного приложения или сайта
Качество разработки и выбранные технологии — тема отдельной заметки и сегодня мы их не рассматриваем.
Исходим из того, что приложение и сайт разработаны грамотно: с понятной архитектурой, кэшированием, асинхронной загрузкой, без костылей и тормозных сторонних компонентов (колхозных SDK или библиотек). Если не уверены в этом, обратитесь за кодревью в студию или к тимлидам, которым вы доверяете.
Измеряя скорость работы приложений, мы сталкиваемся с тем, что не знаем мощности железа в клиенстком смартфоне, количество запущенных на нем приложений, качества интернет-соединения.
Нельзя буквально влиять на скорость отображения экрана в приложении, так как рендеринг зависит от системного планировщика и свободных ресурсов на устройстве пользователя.
Плюс, на скорость работы влияет объем информации от сервера — чем больше данных тем дольше их парсить перед перелачей на отрисовку экрана.
Для оптимизации остатается смотреть на время с момента получения данных от сервера (загрузили и распарсили) до отправки на отображение, рендеринг.
Итого, чем «тоньше» фронтэнд, чем меньше логики и вычислений ему делигируется, тем лучше. Поэтому решаюшую роль в скорости работы веб или мобильного приложения играет поставщик данных, то есть API.
Помимо скорости ответа следим за форматом API, большие пачки данных увеличат время парсинга и снизят скорость приложения и сайта.
Обсуждать спецификацию к API стоит еще на этапе дизайна продукта.
Если в нашем продукте экран загружается дольше 1-2 секунд — это повод перечитать эту заметку и заняться диагностикой.