Пиковые нагрузки: как готовить сайт к наплыву трафика. Опыт, кейсы и советы

Сайт не выдержал. Глубинные причины

Их может быть несколько.

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

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

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

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

Серверная инфраструктура была готова, но проблемы в коде вовремя не обнаружили. Часто бывает так, что «узкие места» сайта — это не количество ядер или памяти на сервере, а не лучшим образом написанный код. В критические моменты он выступает бутылочным горлышком всей системы — и обрушивает ее.

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

План действий: до нагрузок

Вот что стоит сделать.

Выстроить коммуникацию между IT и бизнесом

В IT-команде должен быть человек, способный выступать медиатором: «переводить» с языка бизнеса на язык технических заданий (и обратно). Когда такой человек есть, нужно выстроить процесс коммуникации: договориться, как взаимодействует маркетинг и технический отдел.

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

Протестировать скорость загрузки сайта

Скорость загрузки — крайне важная метрика, влияющая на поведение пользователей и SEO. На скорость может влиять множество факторов: от тяжелой графики до JS-скриптов.

Один из самых популярных инструментов для проверки скорости загрузки — PageSpeed Insights. Промониторить сайт с его помощью можно и без технических знаний: вводите адрес ссылки и получаете срез по производительности на десктопе и мобильных устройствах. 

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

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

Провести нагрузочное тестирование

Нагрузочное тестирование — это «симуляция» большого наплыва трафика на сайт. Существует много сервисов, которые позволяют его проводить: одни просто создают запросы, другие работают более изощренно и подражают поведению живых пользователей на страницах сайта. Для нагрузочного тестирования мы используем Apache JMeter.

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

Подготовить хостинг к нагрузке

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

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

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

Стоит понимать, что недостаточно просто «докупить еще сервер». Код вашего проекта должен поддерживать такую архитектуру, уметь синхронизировать работу нескольких серверов.  

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

Оптимизировать код и технологии на фронтенде 

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

Если касаться фронтенд-технологий, то вот на что стоит обратить внимание:

CDN. Content Delivery Network — так называется распределенная сеть серверов, которая занимается доставкой контента (изображений, видео, стилей, файлов скриптов) конечным пользователям. Проще говоря, вы загружает тяжелый контент в такую сеть, и когда пользователь заходит на сайт, один из серверов CDN «отдает» ему контент. Пользователь Петр получает контент с сервера А, а пользователь Тамара с сервера Б. При этом ваш основной сервер в этом процессе не участвует — и не испытывает нагрузки.

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

Lazy load. Графика на сайте — один из самых тяжелых элементов. «Ленивая загрузка» изображений — это технология постепенной загрузки графики. Например, пользователь попадает на страницу каталога, которая состоит из 5 экранов изображений товаров. Сразу загружаются только те изображения, которые видит пользователь, остальные загрузятся по мере того, как он скроллит страницу вниз. 

Буферные страницы. Еще одно полезное решение — создание лендингов с функцией покупки под конкретные рекламные кампании. Например, магазин запускает РК на конкретный модельный ряд смартфонов и приземляет трафик не на основной сайт, а на специально подготовленный лендинг. Пользователь совершает покупку там, тем самым нагрузка на сайт «рассеивается».

Оптимизировать код и технологии на бэкенде

На стороне бэкенда стоит обращать внимание на те страницы, где у вас есть обращения к внешним сервисам. Например, это почти точно будет страница оформления заказа с расчетом стоимости доставки. У магазина может быть подключен с десяток сервисов — СДЭК, ПЭК, Boxberry, Почта России, Деловые линии. А это десятки внешний запросов.

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

Отдельно: позаботиться о безопасности

Информационная безопасность становится в несколько раз важнее в период больших распродаж. Нужно помнить минимум про два момента.

Резервное копирование данных. Используйте инструменты создания резервных копий сайта — они помогут быстро восстановить его работоспособность, если сайт «упадет». 

Защита от DDoS-атак. Во время больших распродаж не стоит исключать диверсии конкурентов. Сегодня многие хостинг-провайдеры предоставляют услугу защиты от DDoS — как минимум на период распродаж ее стоит активировать.

План действий: во время нагрузок

Если вы все сделали правильно, шансы перегрузки сервера будут минимальными. И все же они сохраняются — поэтому во время большой распродажи стоит непрерывно отслеживать его состояние. Это можно сделать в дашборде хостинг-провайдера — крупные хостеры, такие, как Selectel, предоставляют исчерпывающую аналитику. Или же использовать специализированный софт — мы в своей работе применяем Zabbix и Prometheus.

Ведущий специалист, который вам понадобится для мониторинга, — это опытный системный администратор или DevOps. Обычно, если вы заказываете сопровождение сайта на аутсорсе, компания-подрядчик выделяет специалиста в том числе в «нерабочие» часы. Он отслеживает состояние сайта и быстро реагирует на инциденты — передает задачи в разработку или расширяет серверные мощности прямо во время работы сайта.

А что делать, если сайт «упал»? Если вы используете shared-хостинг, то нужно поднять shared-тариф до максимального, но стоит это делать только если такое возможно без переноса сайта на другой сервер — уточните этот момент у хостера заранее. Второй сценарий действий: переносите сайт в облако и выделяйте нужные ресурсы в панели хостинг-провайдера. 

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

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

Когда технические задачи закрыты

У нас был опыт, когда мы готовились к «черной пятнице», опираясь на опыт прошлого года того же клиента. В итоге с нагрузкой просто не угадали — количество заказов было больше в 2,2 раза, а относительно обычных дней это было x50.

Но подготовка к пиковым нагрузкам чаще все-таки спасает: так в этом году мы помогали другому клиенту, интернет-магазину спортивного питания. В пике нагрузки превышали привычные в 20 раз — но благодаря подготовке, сайт выдержал.