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

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

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