Почему сайты падают во время новогодней распродажи, «Чёрной пятницы» и других акций: 4 кейса от CTO Southbridge
Позади — «Чёрная пятница», впереди — новогодняя распродажа и «Киберпонедельник». Ещё есть время подготовить свой сайт к росту нагрузки из-за всплеска посещаемости. В статье Сергей Фомин, CTO Southbridge, делится 4 кейсами, на примере которых можно найти проблемы в своей инфраструктуре и укрепить сайт перед маркетинговыми активностями.
В материале приводятся реальные кейсы. Для соблюдения NDA мы не называем заказчиков, а также опускаем детали, которые могли бы их раскрыть.
Причины, по которым сайты не справляются со всплеском посещаемости
Во время распродаж, акций, конкурсов посещаемость сайта увеличивается в разы. В распродажу «11.11» 11 ноября 2021 года на Wildberries было оформлено больше 4,5 млн заказов — это на 2 млн больше, чем в 2020 году. Вряд ли Wildberries на этом остановится, так что дальше будет ещё бодрее.
Ежедневная аудитория «Самой громкой распродажи года», которая прошла 11 и 12 ноября на AliExpress, составила 12,5 млн человек. Это 145 человек в секунду. А ведь каждый из них просматривает десятки страниц и делает сотни действий на сайте!
Скачок трафика — дополнительная нагрузка на внутренние сервисы сайта и ИТ-инфраструктуру в целом. Если система к этому не готова, всплеск посещаемости в лучшем случае замедлит работу ресурса. В худшем — уронит его. И то и другое плохо для бизнеса: компания теряет деньги и лояльность клиентов. Также это негативно влияет на SEO-оптимизацию. Если сайт долго лежит или медленно грузится, поисковики понижают его в выдаче.
По нашему опыту, к медленной работе или недоступности сайта при росте нагрузки приводят:
- Проблемы с кодом — 55% случаев. В нашей практике это самый распространённый и самый сложный случай. В обычных условиях баги в коде могут никак не влиять на производительность сайта. Но стоит нагрузке взлететь, и система начинает работать не так, как от неё ожидают.
- Неоптимальная архитектура — 25% случаев. Сайты изначально так спроектированы, что всплеск посещаемости перегружает и замедляет их.
- Нехватка серверных мощностей — 15% случаев. При всплеске посещаемости сайт работает медленно, потому что на обработку возросшего трафика не хватает мощности серверов.
- DDoS-атаки — 5% случаев. DDoS-атака — спланированное нападение на сайт или приложение, при котором на сервер приходит больше запросов, чем он способен обработать. Это перегружает железо и либо совсем выводит его из строя, либо сильно замедляет работу сайта. Чаще всего в e-commerce и других сферах DDoS-атаки используются при недобросовестной конкуренции. В нашей практике сайты подвергаются DDoS-атакам редко. Но вообще это распространённое явление. К примеру, в 2020 году число DDoS-атак на российские интернет-магазины удвоилось, причём 40% из них произошли в последние три месяца — это связано с ростом онлайн-покупок из-за новогодних праздников. В 2021 году число DDoS-атак выросло в 2,5 раза по сравнению с 2020.
Чтобы справиться с резким ростом посещаемости, нужно заранее подготовить сайт к большим нагрузкам. Разберём каждую причину на конкретных кейсах и обсудим варианты решения.
Кейс онлайн-кинотеатра: после рекламы пришло в 4 раза больше пользователей, и сайт лёг
К нам обратился владелец онлайн-кинотеатра. Он рассказал, что в целом его ресурс работал хорошо, только иногда подвисали страницы с фильмами. Но когда после рекламы пришло в 4 раза больше пользователей, чем обычно, сайт лёг. Заказчику хотелось разобраться, в чём дело, и предотвратить подобную ситуацию в будущем.
Мы сделали профилирование кода. При профилировании мы разбиваем запрос на отдельные операции и выявляем самые долгие из них. К примеру, запрос занимает 2,5 секунды. Профилирование помогает обнаружить операцию, которая выполняется 900 мс — это ⅓ всего запроса.
Выяснилось, что киносервис не хранил данные о фильмах в собственной базе, а каждый раз онлайн собирал страницу фильма по кусочкам, создавая 1 000 обращений к внешним ресурсам. С других сервисов подтягивались обложка и описание, IMDb-рейтинг, информация об актёрах и прочее. Из-за этого страница грузилась долго — от 1,5 до 2 секунд. При всплеске посещаемости количество запросов к внешним сервисам выросло в сотни раз и привело к тому, что киносайт упал.
Сложнее всего найти в коде сам баг. Но когда он обнаружен, остаётся только исправить его. Выявив проблему, мы связались с разработчиками заказчика и вместе с ними провели работу по оптимизации кода. Теперь страницы с фильмами генерируются в 20 раз быстрее — за 50–60 мс — и больше не подвисают, а сайт не падает при росте посещаемости.
Кейс интернет-магазина: в распродажу сайт периодически падал и выдавал 500-ю ошибку
К нам обратился интернет-магазин алкогольных напитков. У заказчика проходила распродажа, и посещаемость сайта была выше, чем обычно. Без какой-либо закономерности сайт падал, выдавал 500-ю ошибку (ошибка сервера), потом приходил в себя, а затем снова падал.
В ходе поисков мы выяснили, что сама архитектура приложения не тянула возросшую нагрузку. Интернет-магазин заказчика работал на одной из популярных CMS, к которой было подключено множество тяжёлых модулей. Даже при обычном трафике запросы к модулям генерировали тысячу запросов к серверам и базам данных и затрудняли их работу.
Рост посещаемости привёл к тому, что счёт запросов к модулям пошёл на миллионы. Это перегружало серверы, поэтому сайт периодически «пятисотил».
Архитектурная проблема решается рефакторингом кода — нужно полностью переписать приложение, спроектировав его логику с учётом возрастающих нагрузок. Это эффективно, но долго и дорого. Мы же были ограничены во времени — требовалось лекарство, способное помочь интернет-магазину прямо сейчас.
Для таких ситуаций есть рабочая схема — отключить 20–30% функционала и потерять часть пользователей. Звучит пугающе, но на деле всё просто и логично: пожертвовав 20–30% функций, которые нужны 5% посетителей, мы сохраним доступность сайта для остальных 95%. В случае с интернет-магазином алкогольной продукции мы по согласованию с заказчиком отключили часть тяжёлых модулей. Это позволило существенно снизить нагрузку на внутренние сервисы и предотвратить падение сайта до конца распродажи.
Кейс портала для школьников: ожидали роста посещаемости в 5 раз
На поддержку пришёл портал для школьников. В часы пик посещаемость ресурса возрастала со 100 до 300 тыс. человек и сайт медленно грузился. Заказчик хотел решить эту проблему, а также подготовить портал к сентябрю, когда дети пойдут в школу и посещаемость вырастет в 5 раз.
Изначально при всплесках нагрузки веб-сервер выдавал одну и ту же ошибку — мы получали сообщения о нехватке воркеров вида worker_connections. Это означало, что в часы пик число одновременных подключений к веб-серверу превышало его лимит возможных соединений, поэтому для части пользователей портал был недоступен.
Мы поправили число воркеров и оптимизировали настройки веб-сервера. После тюнинга ситуация улучшилась — сервер смог обрабатывать все коннекты и перестал выдавать ошибку. Но дальше мы столкнулись с новым ограничением — в системе начали заканчиваться TCP-порты.
Изменить лимит TCP-портов невозможно — для одного сервера их количество всегда одинаковое. Единственный способ решить проблему — добавить ещё серверов. По согласованию с заказчиком мы так и сделали: добавили ещё три сервера и настроили Round robin DNS.
Round robin DNS позволяет распределить нагрузку на серверы равномерно — он присваивает сайту несколько IP-адресов и выдаёт их пользователям по очереди:
- юзеру №1 — первый IP,
- юзеру №2 — второй,
- юзеру №3 — третий,
- юзеру №4 — четвёртый,
- юзеру №5 — снова первый и т. д.
Таким образом на каждый из четырёх серверов приходится по 25% нагрузки.
Решение сработало — в сентябре посещаемость в часы пик увеличилась до 1,5 млн человек и сайт справлялся с этой нагрузкой.
Кейс мебельного интернет-магазина: неожиданно посещаемость выросла с 1 000–1 500 человек в минуту до 12 000
У нас на поддержке был магазин мебели. Однажды во время мониторинга мы заметили, что на сайт пошёл огромный трафик. Неожиданно посещаемость выросла с 1 000–1 500 человек в минуту до 12 000. Причин для этого не было: заказчик не давал рекламу и не проводил распродаж или акций.
Ошибки со стороны архитектуры, кода и инфраструктуры исключили сразу — при постановке на поддержку мы проверили и настроили систему.
Посмотрели логи — запросы, поступающие к веб-серверу. Не обнаружили ничего подозрительного: казалось, запросы генерируют обычные пользователи, которые гуляют по сайту и добавляют в корзину диваны и тумбочки. Однако огромный и ничем не объяснимый трафик, который продолжал расти, натолкнул нас на мысль, что на интернет-магазин идёт DDoS-атака.
Есть DDoS-атаки, которые легко обнаружить, посмотрев логи. Если анализ логов показал:
- странные запросы, состоящие из абракадабры;
- запросы, отправленные с подозрительных IP-адресов, например из стран, откуда обычно нет трафика;
- множество запросов с одного IP-адреса
...значит сайт подвергся нападению ботов. Справиться с такой атакой довольно просто средствами веб-сервера: отсеять сомнительный трафик, заблокировать IP-адрес и т. д.
Труднее распознать DDoS-атаку, при которой множество запросов генерят «умные» боты. Роботы маскируются под людей и совершают осмысленные действия: смотрят товары, добавляют их в корзину, гуляют по разным разделам сайта. В этом случае непонятно, какие IP блокировать, поэтому защититься на уровне веб-сервера сложно. В ситуации с интернет-магазином мы заподозрили DDoS-атаку с «умными» ботами.
Мы сотрудничаем с компанией, которая обеспечивает защиту сайта от таких атак, и на случай ЧП у нас выработан чёткий алгоритм действий. Мы предложили заказчику воспользоваться услугами нашего партнёра. Он согласился, и мы поставили сайт под защиту. Предположение о DDoS-атаке подтвердилось: в интерфейсе сервиса-защитника мы увидели, как отсекается трафик, который генерируют боты. При этом трафик мебельного интернет-магазина вернулся к нормальным значениям.
Резюме: как подготовить сайт к росту трафика
Итак, чтобы подготовить сайт к росту нагрузки во время маркетинговой кампании, нужно:
- Провести аудит и проверить код, архитектуру, настройки ИТ-инфраструктуры.
- Провести нагрузочное тестирование, чтобы определить лимит сайта и выявить узкие места в инфраструктуре.
- Исходя из результатов аудита и нагрузочного тестирования, укрепить сайт: сделать рефакторинг кода, оптимизировать долгие запросы, перестроить ИТ-инфраструктуру или добавить ресурсов.
- Повторять шаги №2 и №3 до тех пор, пока не устроит результат.
- По желанию — подключить к сайту защиту от DDoS-атак.
Код, архитектура, серверные мощности, DDoS - это все хорошо, но в мире есть высокопроизводительные объектные СУБД, а не только бесплатные реляционные PostgreSQL, MySQL (и иже с ними). Очевидно, что вся эта бесплатная реляционная катавасия не предназначена для высоконагруженных систем.
Есть такой магазин, "Kate Spade New york". Они столкнулись с ростом количества заказов в 80 раз, до 4000 заказов в час. Перешли на Actian https://www.actian.com/customers/
Мы используем VOD - https://vc.ru/dev/263279-versant-object-database-obektnaya-subd-rodom-iz-gamburga
На днях получили почти миллион тяжелых запросов в сутки по API https://bil24.pro/ Загрузка процессоров сервера впервые достигла 10%, а у системы СУБД 1%.
Резюме: заплатите за объектную СУБД промышленного уровня и, с самого начала, используйте ее как основу системы.