Как готовить e-commerce к пиковым нагрузкам

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

Проблема в том, что подготовка к пику часто сводится к увеличению серверных ресурсов непосредственно перед акцией. Иногда этого достаточно. Но узким местом может оказаться база данных, поиск, интеграция с ERP, расчёт цены, платёжный сервис или процесс обновления остатков. Дополнительные процессоры не исправят ограничение, которое находится совсем в другом месте.

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

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

Фраза «посетителей будет примерно в пять раз больше» даёт только общее представление о нагрузке.

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

Поэтому полезно собрать данные по предыдущим периодам и прогноз будущей кампании:

• количество одновременных пользователей;
• просмотры и запросы в секунду;
• количество поисковых запросов;
• добавления в корзину;
• оформления заказов;
• оплаты;
• авторизации;
• обращения к личному кабинету;
• объём обновлений каталога;
• интенсивность интеграционного обмена.

Если исторических данных нет, можно построить несколько сценариев: ожидаемый, повышенный и стрессовый. Это всё равно полезнее абстрактного требования «сайт должен выдержать много пользователей».

Нужно учитывать скорость прихода аудитории

Два интернет-магазина могут получить одинаковые 100 000 посещений за день и столкнуться с совершенно разной нагрузкой.

В первом случае трафик распределён относительно равномерно. Во втором в 12:00 начинается акция, одновременно отправляется push-уведомление и письмо по клиентской базе, а рекламная кампания ведёт пользователей на одну товарную категорию.

Именно резкий рост нагрузки часто становится проблемой. Поэтому при подготовке важно знать не только суточный объём трафика, но и предполагаемую концентрацию активности: сколько пользователей может прийти в течение одной минуты, пяти минут или часа после запуска кампании. Маркетинговый план в этом смысле становится одним из источников данных для технической команды.

Определить критичные пользовательские сценарии

Не все функции интернет-магазина одинаково важны во время пика.

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

Например: главная → каталог → карточка товара → корзина → оформление → оплата.

Для другого проекта значительную роль могут играть поиск и фильтрация: поиск → результаты → фильтр → карточка → корзина.

В B2B e-commerce появятся персональные цены, авторизация, остатки по складам, лимиты и другие операции.

Именно эти сценарии затем становятся основой нагрузочного тестирования и мониторинга во время акции.

Проверить архитектуру по всей цепочке

Пользователь видит один интернет-магазин, но за его действиями может стоять целый набор компонентов:

CDN → веб-сервер → приложение → кеш → база данных → поиск → ERP → платёжная система → доставка.

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

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

Кеширование снижает количество дорогих операций

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

Кешировать можно разные уровни:

• статические файлы;
• страницы или их фрагменты;
• результаты запросов;
• данные каталога;
• результаты вычислений;
• отдельные ответы API.

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

Статику стоит отдавать отдельно от приложения

Изображения, стили, JavaScript и другие статические ресурсы не обязательно каждый раз отдавать с тех же серверов, которые занимаются бизнес-логикой интернет-магазина. Использование CDN позволяет распределить доставку таких файлов и снизить часть нагрузки на основную инфраструктуру. Особенно заметен эффект, если акция привлекает много новых пользователей, которым требуется впервые загрузить весь набор ресурсов страницы.

CDN не решает проблемы оформления заказа или медленного запроса к базе данных, но освобождает инфраструктуру от работы, которую можно вынести за пределы приложения. Это хороший пример того, почему масштабирование e-commerce требует работы на нескольких уровнях одновременно.

База данных часто становится узким местом

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

Поэтому перед крупным пиком стоит проверить:

• медленные запросы;
• индексы;
• блокировки;
• количество соединений;
• наиболее частые операции;
• объём чтения и записи;
• нагрузку при оформлении заказа;
• фоновые процессы.

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

Поиск и фильтры нужно тестировать отдельно

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

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

Например, сам поиск быстро находит товары, но затем интернет-магазин для каждого результата отдельно рассчитывает цену и остаток. В итоге пользователь всё равно получает страницу медленно. Поэтому тестировать стоит пользовательский сценарий целиком, а не только отдельный поисковый сервис.

Интеграции не должны получать весь пользовательский пик

Особенно опасны синхронные обращения к внешним и внутренним системам во время пользовательского запроса.

Представим, что для открытия корзины интернет-магазин каждый раз запрашивает актуальные данные в ERP. В обычный день это работает приемлемо. При десятикратном росте аудитории ERP неожиданно получает тот же десятикратный рост запросов, хотя изначально не проектировалась как публичный высоконагруженный сервис.

Поэтому для критичных интеграций стоит заранее определить:

• какие запросы действительно должны выполняться синхронно;
• какие данные можно хранить локально;
• где допустим кеш;
• какие операции можно перевести в очередь;
• что произойдёт при недоступности внешней системы;
• как ограничить количество запросов к ней.

Интернет-магазин должен по возможности защищать внутренний контур от прямого переноса пользовательского пика.

Фоновые процессы тоже создают нагрузку

Проблема может возникнуть даже без дополнительного трафика.

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

Часть из них можно перенести на другое время. Для остальных — ограничить потребление ресурсов или разделить инфраструктуру. Важно также проверить очереди. Если при росте числа заказов фоновые задачи поступают быстрее, чем обрабатываются, задержка будет постепенно увеличиваться даже после снижения пользовательской нагрузки.

Масштабирование нужно проверить заранее

Фраза «если что, добавим сервер» работает только в том случае, если система действительно умеет использовать дополнительные ресурсы.

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

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

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

Нагрузочный тест должен повторять поведение покупателей

Просто отправить большое количество запросов на главную страницу недостаточно. Тест должен воспроизводить несколько основных сценариев с реалистичным распределением. Например:

• 35% пользователей просматривают каталог;
• 25% используют поиск и фильтры;
• 20% открывают карточки;
• 12% работают с корзиной;
• 8% проходят оформление заказа.

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

Так нагрузочный тест начинает отвечать на практический вопрос: что произойдёт, если в магазин одновременно придёт ожидаемая аудитория и будет вести себя примерно так же, как настоящие покупатели?

Нагрузку стоит увеличивать постепенно

Полезно знать не только результат в одной точке, например при 5 000 одновременных пользователей. Нагрузку можно увеличивать ступенчато и смотреть, как меняется поведение системы.

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

Если ожидаемый пик находится слишком близко к ней, запас небольшой. Если система сохраняет приемлемые показатели при нагрузке заметно выше прогнозной, риск ниже.

Проверять нужно не только скорость

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

• создаются дубли заказов;
• часть заказов не передаётся в ERP;
• неверно резервируется товар;
• задерживаются уведомления;
• платежи получают неправильный статус;
• остатки обновляются с большой задержкой.

Поэтому после нагрузочного теста стоит проверять не только графики времени ответа и CPU, но и корректность результата. Особенно это важно для операций записи: заказов, оплат, резервов и изменения данных клиента.

Нужно заранее решить, чем можно пожертвовать

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

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

Конкретные решения зависят от проекта. Но принцип полезен: лучше сохранить оформление заказов за счёт временного ограничения второстепенной функции, чем потерять весь магазин. Такие сценарии деградации нужно продумывать заранее, а не в момент аварии.

Мониторинг во время пика должен быть готов заранее

Во время акции поздно решать, какие показатели нужно смотреть. До старта полезно собрать дашборд с основными техническими и бизнес-метриками:

• количество запросов;
• время ответа;
• процент ошибок;
• нагрузка на инфраструктуру;
• состояние базы данных;
• длина и возраст очередей;
• работа поиска;
• состояние интеграций;
• количество заказов;
• успешность оплат.

Особенно полезно сопоставлять технические и бизнес-показатели. Если серверы выглядят нормально, но количество оформленных заказов внезапно упало почти до нуля, проблема всё равно требует проверки.

Нужны пороги и ответственные

Сам график не поможет, если никто не заметит изменение. Перед пиковым периодом стоит определить, при каких показателях отправляются уведомления и кто должен на них реагировать.

Например:

• выросло время ответа → проверяет дежурный разработчик;
• увеличилась очередь заказов → проверяется интеграция;
• снизилась доля успешных платежей → проверяется платёжный контур;
• нагрузка приближается к расчётному пределу → запускается масштабирование.

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

После пика данные нужно сохранить и разобрать

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

• какой был максимальный трафик;
• сколько операций выполнялось;
• где возникали задержки;
• какие компоненты приблизились к пределу;
• как сработало масштабирование;
• возникали ли ошибки;
• насколько быстро команда на них реагировала;
• какой запас остался.

Это позволяет уточнить нагрузочную модель и заранее понять, что потребуется при следующем росте. Если каждый пик заканчивается только облегчением «в этот раз выдержали», система не становится подготовленнее к следующему.

Что проверить перед крупной акцией

Практический список можно собрать в несколько групп:

Область	Что проверить
Прогноз	Ожидаемый и стрессовый объём нагрузки
Сценарии	Какие действия будут выполнять пользователи
Архитектура	Где находятся потенциальные ограничения
Приложение	Производительность критичных операций
База данных	Запросы, индексы, соединения, блокировки
Кеш и CDN	Какие операции можно снять с основной инфраструктуры
Поиск	Работа поиска и фильтров под нагрузкой
Интеграции	Ограничения ERP, CRM, платежей, доставки и других систем
Фоновые задачи	Расписание и способность очередей переварить рост
Масштабирование	Можно ли действительно добавить ресурсы и насколько быстро
Корректность	Не теряются ли и не дублируются ли операции
Деградация	Какие второстепенные функции можно ограничить
Мониторинг	Технические и бизнес-метрики, алерты
Реакция	Ответственные и сценарии действий при проблемах

Не каждому интернет-магазину нужна инфраструктура, рассчитанная на нагрузку крупнейшего маркетплейса. Избыточный запас тоже стоит денег.

Задача подготовки к пику — не сделать систему бесконечно производительной, а определить реалистичный диапазон нагрузки, проверить его заранее и понимать, что произойдёт при выходе за ожидаемые границы.

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