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

Большие распродажи — это всегда испытания на прочность для вашей IT-инфраструктуры. И не так важно, что послужило причиной повышенного интереса пользователей: «Черная пятница», большой новогодний сейл или просто удачная рекламная кампания. Когда сайт не выдерживает и «падает», последствия для бизнеса очевидны: упущенная выручка, сбои в обработке уже полученных заказов, а если проблема становится системной — удар по репутации магазина. Вместе с технической командой ADN и продакшн-директором Юлией Петросян выясняем, как правильно готовить сайт к крупным распродажам.

2 008 просмотров

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

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

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

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

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

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

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

Бывает, что слабое место даже не в коде самого сайта, а в тех местах, где он соединяется с третьими сервисами — например, подключаемой маркетинговой платформой. Я однажды наблюдал, как крупный DIY-ритейлер запустил акцию, и мониторинг показал, что подключение по cURL, то есть соединение с внешним сервисом, нагрузки не выдерживает. Для пользователей итог понятен: 500 Internal Server Error и прерванный процесс заказа.

Александр Кондраков
backend-разработчик в ADN

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

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

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

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

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

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

Дискоммуникация — самая частая причина проблем. Мы наблюдали ситуации, когда бизнес запускал рекламные кампании, не ставя в известность свой IT-департамент. Это неизбежно вело к замедлению работы сайта и даже его полной остановке. Поэтому сейчас мы закрепляем процесс коммуникации в договоре. Непосредственно в период распродаж всегда проявляем заботу о клиенте: если нужно быть на связи ночью, мы будем на связи.

Юлия Петросян
продакшн-директор и руководитель клиентской поддержки в ADN

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

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

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

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

Пример рекомендаций, которые дает сервис

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

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

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

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

Дмитрий Коротков
CTO в ADN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Алексей Понарин
fullstack-разработчик в ADN

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

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

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

Дмитрий Коротков
CTO в ADN

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

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

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

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

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

Не рекомендуется выводить технические подробности 500-х ошибок (ошибки на стороне сервера). Это только облегчит работу злоумышленников.

Александр Кондраков
backend-разработчик в ADN

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

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

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

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

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

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

Кто обычно входит в команду поддержки: С чем работает команда:
Бэкенд- и фронтенд-разработчик (или fullstack) Работа с серверами
DevOps или системный администратор Мониторинг системы
Менеджер-координатор IT-команды Распределение нагрузки
Команда маркетинга на стороне клиента Оптимизация кода на бэкенде
Оптимизация кода на фронтенде
Усиление мер безопасности

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

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

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

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

Юлия Петросян
продакшн-директор и руководитель клиентской поддержки в ADN
2 008 просмотров
Подпишись

Мы отправляем полезные материалы, которые помогут вам в работе

Популярные статьи в категории Кейсы