Лишь бы не упал: как подготовить сайт к новогодней распродаже и другим акциям

Во время распродаж, акций, рекламы, конкурсов посещаемость сайта увеличивается в разы. В распродажу «11.11» 11 ноября 2021 года на Wildberries было оформлено больше 4,5 млн заказов — это на 2 млн больше, чем в 2020 году. Вряд ли Wildberries на этом остановится, так что дальше будет ещё бодрее.

Ежедневная аудитория «Самой громкой распродажи года», которая прошла 11 и 12 ноября на AliExpress, составила 12,5 млн человек. Это 145 человек в секунду. А ведь каждый из них просматривает десятки страниц и делает сотни действий на сайте!

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

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

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

Причины, по которым сайты не справляются со всплеском посещаемости

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

• проблемы с кодом — 55% случаев;
• неоптимальная архитектура — 25% случаев;
• нехватка серверных мощностей — 15% случаев;
• DDoS-атаки — 5% случаев.

Статистика помогает понять, чем заняться в первую очередь.

Решить проблемы с кодом

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

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

Трафик на сайт вырос, и теперь запрос-тяжеловес генерируется раз в секунду. База данных в шоке и скрипит от нагрузки. Уже даже простые запросы ждут, пока она обработает тяжеловеса. Клиенты тем временем продолжают гулять по сайту, раздражаясь, что он подтормаживает, а корзина десятки секунд считает суммарную цену. Очередь запросов растёт, растёт, растёт и в самый неподходящий момент… сайт вообще перестаёт отвечать!

Ситуация

К нам обратился владелец онлайн-кинотеатра. Он рассказал, что в целом его ресурс работал хорошо, только иногда подвисали страницы с фильмами. Но когда после рекламы пришло в 4 раза больше пользователей, чем обычно, сайт лёг. Заказчику хотелось разобраться, в чём дело, и предотвратить подобную ситуацию в будущем.

В первую очередь мы проверили настройки инфраструктуры — с ней всё было в порядке. Затем стали изучать код и сделали профилирование.

При профилировании кода мы разбиваем запрос на отдельные операции и выявляем самые долгие из них. К примеру, запрос занимает 2,5 секунды. Профилирование помогает обнаружить операцию, которая выполняется 900 мс — это ⅓ всего запроса.

После профилирования кода онлайн-кинотеатра удалось разобраться, почему страницы с фильмами подвисали и почему в итоге сайт упал. Оказалось, киносервис не хранил данные о фильмах в собственной базе, а каждый раз онлайн собирал страницу фильма по кусочкам, создавая 1 000 обращений к внешним ресурсам. С других сервисов подтягивались обложка и описание, IMDb-рейтинг, информация об актёрах и прочее. Из-за этого страница грузилась долго — от 1,5 до 2 секунд. При всплеске посещаемости количество запросов киносайта к внешним сервисам выросло в сотни раз — это и привело к тому, что он упал.

Решение

Сложнее всего найти в коде сам баг. Но когда он обнаружен, остаётся только исправить его. Выявив проблему, мы связались с разработчиками заказчика и вместе с ними провели работу по оптимизации кода. Теперь страницы с фильмами генерируются в 20 раз быстрее — за 50−60 мс — и больше не подвисают, а сайт не падает при росте посещаемости.

Проверить архитектуру приложения

Следующая причина, по которой сайты не справляются с резким ростом нагрузки — неоптимальная архитектура. Они изначально так спроектированы, что всплеск посещаемости перегружает и замедляет их. С этой причиной мы сталкиваемся в 25% случаев.

Ситуация

К нам обратился интернет-магазин алкогольной продукции. У заказчика проходила распродажа, и посещаемость сайта была выше, чем обычно. Без какой-либо закономерности сайт падал, выдавал 500-ю ошибку (ошибка сервера), потом приходил в себя, работал нормально, а затем снова падал.

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

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

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

Решение

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

Для таких ситуаций есть рабочая схема — отключить 20−30% функционала и потерять часть пользователей. Звучит пугающе, но на деле всё просто и логично: пожертвовав 20−30% функций, которые нужны 5% посетителей, мы сохраним доступность сайта для остальных 95%. В случае с интернет-магазином алкогольной продукции мы по согласованию с заказчиком отключили часть тяжёлых модулей. Это позволило существенно снизить нагрузку на внутренние сервисы и предотвратить падение сайта до конца распродажи.

Увеличить серверные мощности

В 15% случаев при всплеске посещаемости сайт работает медленно, потому что на обработку возросшего трафика не хватает мощности серверов.

Ситуация

На поддержку пришёл портал для школьников. В часы пик посещаемость ресурса возрастала со 100 до 300 тыс. человек и сайт медленно грузился. Заказчик хотел решить эту проблему, а также подготовить портал к сентябрю, когда дети пойдут в школу и посещаемость вырастет в 5 раз.

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

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

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

Решение

Изменить лимит TCP-портов невозможно — для одного сервера их количество всегда одинаковое. Единственный способ решить такую проблему — добавить ещё серверов. По согласованию с заказчиком мы так и сделали: добавили ещё три сервера и настроили Round robin DNS.

Round robin DNS позволяет распределить нагрузку на серверы равномерно — он присваивает сайту несколько IP-адресов и выдаёт их пользователям по очереди:

• юзеру № 1 — первый IP,
• юзеру № 2 — второй,
• юзеру № 3 — третий,
• юзеру № 4 — четвёртый,
• юзеру № 5 — снова первый и т. д.

Таким образом на каждый из четырёх серверов приходится по 25% нагрузки.

Решение сработало — в сентябре посещаемость в часы пик увеличилась до 1,5 млн человек и сайт справлялся с этой нагрузкой, работал стабильно и быстро.

В целом число серверов следует увеличивать в двух случаях:

1. С архитектурой и кодом сайта всё в порядке: архитектура способна выдерживать рост нагрузки в десятки раз, а в коде нет критичных багов. Однако ожидается резкий всплеск посещаемости из-за маркетинговой или сезонной активности и есть подозрение, что нынешнее число серверов с ним не справится.
2. Некоторые сервисы приложения работают неоптимально, например в системе есть тяжёлые запросы, но их логику нельзя переделать. Добавление ресурсов увеличит производительность системы и ускорит обработку сложных запросов.

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

Защититься от DDoS-атак

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

В нашей практике сайты подвергаются DDoS-атакам всего в 5% случаев. Но вообще это распространённое явление. К примеру, в 2020 году число DDoS-атак на российские интернет-магазины удвоилось, причём 40% из них произошли в последние три месяца — это связано с ростом онлайн-покупок из-за новогодних праздников. В 2021 году число DDoS-атак выросло в 2,5 раза по сравнению с 2020.

Ситуация

У нас на поддержке был магазин мебели. Однажды во время мониторинга мы заметили, что на сайт пошёл огромный трафик. Неожиданно посещаемость выросла с 1 000−1 500 человек в минуту до 12 000. Причин для этого не было: заказчик не давал рекламу и не проводил распродаж или акций.

Ошибки со стороны архитектуры, кода и инфраструктуры исключили сразу — при постановке на поддержку мы проверили и настроили систему.

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

Решение

Есть DDoS-атаки, которые легко обнаружить, посмотрев логи. Если анализ логов показал:

• странные запросы, состоящие из абракадабры;
• запросы, отправленные с подозрительных IP-адресов, например из стран, откуда трафик обычно не идёт;
• множество запросов с одного IP-адреса

…значит сайт подвергся нападению ботов. Справиться с такой атакой довольно просто средствами веб-сервера: отсеять сомнительный трафик, заблокировать IP-адрес и т. д.

Труднее распознать DDoS-атаку, при которой множество запросов генерят «умные» боты. Такие роботы маскируются под людей и совершают осмысленные действия: смотрят товары, добавляют их в корзину, гуляют по разным разделам сайта. В этом случае трудно понять, какие IP блокировать, поэтому защититься на уровне веб-сервера сложно.

В ситуации с интернет-магазином мы заподозрили DDoS-атаку с «умными» ботами. Мы сотрудничаем с компанией, которая обеспечивает защиту сайта от таких атак, и на случай ЧП у нас выработан чёткий алгоритм действий.

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

При постановке на поддержку мы сразу подключаем защиту от DDoS-атак в двух случаях:

1. заказчик ожидает нападения и просит об этой услуге;
2. сайт уже подвергался DDoS-атакам.

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

Рекомендасьон: как подготовить сайт к росту нагрузки

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

1. провести аудит и проверить код, архитектуру, настройки ИТ-инфраструктуры.
2. Провести нагрузочное тестирование, чтобы определить лимит сайта и выявить узкие места в инфраструктуре.
3. Исходя из результатов аудита и нагрузочного тестирования, укрепить сайт: сделать рефакторинг кода, оптимизировать долгие запросы, перестроить ИТ-инфраструктуру или добавить ресурсов.
4. Повторять шаги № 2 и № 3 до тех пор, пока не устроит результат.
5. По желанию — подключить к сайту защиту от DDoS-атак.

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

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