Бизнес на пиковых нагрузках

Как компании готовятся к чёрным пятницам и вирусным продажам и как в этом помогают облачные технологии

Материал подготовлен совместно с экспертами Cloud.ru — российского провайдера облачных сервисов и ИИ-технологий.

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

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

ИТ-системы редко выходят из строя одномоментно, как правило, возникает каскадная реакция. Всё начинается с резкого роста числа одновременных запросов: тысячи пользователей открывают карточки товаров, добавляют позиции в корзину, обновляют страницы со скидками. База данных не успевает параллельно обрабатывать такой поток, очереди запросов накапливаются, а время отклика возрастает от миллисекунд до секунд.

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

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

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

Отдельная зона риска — корпоративные системы, например ERP (enterprise resource planning — планирование ресурсов предприятия), бухгалтерия, документооборот. В сезонный пик они тоже испытывают нагрузку, и сбой здесь означает задержку в отгрузке, даже если сайт работает исправно.

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

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

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

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

Всё чаще для этого используют ML-модели (machine learning — машинное обучение): они предсказывают не просто «будет больше трафика», а конкретные всплески с детализацией до часа и отдельного сервиса. Точный прогноз помогает заранее усилить именно те компоненты, что окажутся под максимальным давлением, не переплачивая за ненужные ресурсы.

Собственное ИТ-оборудование закупают с запасом, чтобы инфраструктура выдерживала периоды максимальной нагрузки. Поскольку такие пики случаются редко, 70–80% вычислительных мощностей большую часть времени простаивает, требуя при этом обслуживания и неизбежно устаревая. В облаке оплата начисляется за фактически потреблённые ресурсы: при росте трафика компания оперативно наращивает мощности, а при спаде высвобождает излишки.

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

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

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

Общая статистика может показывать, что система загружена всего на 20%. Кажется, что запаса прочности достаточно. Однако, если эти 20% приходятся на критически важный узел (например, базу данных или платёжный шлюз), который прямо сейчас работает на пределе возможностей, сервис всё равно даст сбой. Оставшиеся 80% свободных мощностей соседних элементов никак не помогут обработать зависшие транзакции. Поэтому мониторинг должен фиксировать не только общую картину, но и состояние каждого потенциального «узкого горлышка».

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

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

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

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

Бизнесу критически важно понимать разницу между резервной площадкой и резервными копиями. Они страхуют от разных рисков.

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

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

Сезон распродаж притягивает не только покупателей. Пока системы работают на пределе, DDoS-атака (distributed denial of service — распределённый отказ от обслуживания) может добить то, что и так держится из последних сил.

Облачные провайдеры размещают сервисы Anti-DDoS поверх широких каналов, они фильтруют объёмные атаки на уровне сети. Но атака, направленная точечно на инфраструктуру внутри этого канала, может пройти через общий фильтр. Периметр собственных виртуальных сетей нужно защищать отдельно.

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

За 4–6 недель

За 2–3 недели

За 1–2 недели

Накануне

После

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

А как ваша ИТ-инфраструктура справляется с неожиданными наплывами клиентов? Делитесь своим опытом (и выводами) в комментариях.