Причины, по которым сайты не справляются с ростом нагрузки: опыт Southbridge
В статье на реальных кейсах из разных сфер разберём, почему сайты не справляются с ростом нагрузки. Для соблюдения NDA мы не называем заказчиков, а также опускаем детали, которые могли бы их раскрыть.
Почему сайты не справляются с ростом нагрузки
По нашему опыту, к медленной работе или недоступности сайта при росте нагрузки приводят:
проблемы с кодом — 55% случаев;
неоптимальная архитектура — 25% случаев;
нехватка серверных мощностей — 15% случаев;
DDoS-атаки — 5% случаев.
Разберём каждую причину на конкретном кейсе.
Кейс: проблемы с кодом
Ситуация
Сайт онлайн-кинотеатра в целом работал хорошо, только иногда подвисали страницы с фильмами. Однако когда после рекламы на сайт пришло в 4 раза больше пользователей, чем обычно, он лёг.
Мы сделали профилирование кода и выяснили, что киносервис не хранил данные о фильмах в собственной базе, а каждый раз онлайн собирал страницу фильма по кусочкам, создавая 1 000 обращений к внешним ресурсам. Из-за этого страница грузилась от 1,5 до 2 секунд. При всплеске посещаемости количество запросов к внешним сервисам выросло в сотни раз и киносайт упал.
Решение
Выявив проблему, мы связались с разработчиками заказчика и вместе с ними провели работу по оптимизации кода. Теперь страницы с фильмами генерируются в 20 раз быстрее — за 50–60 мс — и больше не подвисают, а сайт не падает при росте трафика.
Кейс: неоптимальная архитектура приложения
Ситуация
К нам обратился интернет-магазин алкогольных напитков. У заказчика проходила распродажа, и посещаемость была выше, чем обычно. Без какой-либо закономерности сайт периодически падал и выдавал 500-ю ошибку.
В ходе поисков мы поняли, что сама архитектура приложения не тянула возросшую нагрузку. Интернет-магазин работал на одной из популярных CMS, к которой было подключено множество тяжёлых модулей. Даже при обычной нагрузке модули нагружали базу данных, отправляя на неё множество запросов.
Всплеск посещаемости привёл к тому, что счёт запросов к базе данных пошёл на миллионы. Это перегружало БД, и сайт периодически «пятисотил».
Решение
На рефакторинг кода не было времени — требовалось средство, способное помочь прямо сейчас. По согласованию с заказчиком мы отключили часть тяжёлых модулей. После этого некоторые функции на сайте стали недоступны, например пользователи не могли найти через поиск определённый товар, зато нагрузка на внутренние сервисы существенно снизилась. Это позволило предотвратить падение сайта до конца распродажи.
Кейс: нехватка серверных мощностей
Ситуация
На поддержку пришёл портал для школьников. В часы пик посещаемость ресурса возрастала со 100 до 300 тыс. человек и сайт медленно грузился. Заказчик хотел решить эту проблему, а также подготовить портал к сентябрю, когда дети пойдут в школу и посещаемость вырастет в 5 раз.
Изначально при всплесках нагрузки веб-сервер выдавал сообщения о нехватке воркеров вида worker_connections. Мы поправили число воркеров и оптимизировали настройки веб-сервера. Но дальше столкнулись с новым ограничением — в системе начали заканчиваться TCP-порты.
Решение
Эту проблему можно было решить, только увеличив количество серверов. По согласованию с заказчиком мы добавили ещё три сервера и настроили Round robin DNS. Решение сработало — в сентябре посещаемость в часы пик увеличилась до 1,5 млн человек, и сайт справлялся с этой нагрузкой.
Кейс: DDoS-атаки
Ситуация
У нас на поддержке был магазин мебели. Однажды во время мониторинга мы заметили, что на сайт пошёл огромный трафик. Неожиданно посещаемость выросла с 1 000–1 500 человек в минуту до 12 000. Причин для этого не было: заказчик не давал рекламу и не проводил распродаж или акций.
Ошибки со стороны архитектуры, кода и инфраструктуры исключили сразу — при постановке на поддержку мы проверили и настроили систему.
Посмотрели логи. Не обнаружили ничего подозрительного: казалось, запросы генерируют обычные пользователи. Однако огромный и ничем не объяснимый трафик, который продолжал расти, натолкнул на мысль, что на интернет-магазин идёт DDoS-атака с «умными» ботами. Мы сотрудничаем с компанией, которая обеспечивает защиту сайта от таких атак, и на случай ЧП у нас выработан чёткий алгоритм действий.
Решение
Мы предложили заказчику воспользоваться услугами нашего партнёра. Он согласился, и мы поставили сайт под защиту. Предположение о DDoS-атаке подтвердилось: в интерфейсе сервиса-защитника мы увидели, как отсекается трафик, который генерируют боты. При этом трафик мебельного интернет-магазина вернулся к нормальным значениям.
Почему сайты падают при росте нагрузки и что с этим делать
К замедлению или недоступности сайта при росте нагрузки чаще всего приводят баги в коде, неоптимальная архитектура и неверные настройки ИТ-инфраструктуры. Проблем в работе ресурса можно избежать, если заранее подготовить его к высоким нагрузкам:
Провести аудит и нагрузочное тестирование, чтобы определить лимит сайта и выявить узкие места в инфраструктуре,
Исходя из результатов аудита и нагрузочного тестирования, укрепить ресурс: сделать рефакторинг кода, оптимизировать долгие запросы, перестроить ИТ-инфраструктуру или добавить ресурсов.
По желанию — можно подключить к сайту защиту от DDoS-атак, но это необязательно. В конце концов, сайт может никогда не подвергнуться атаке, а платить за услугу придётся каждый месяц.
По-хорошему готовить инфраструктуру к наплыву пользователей нужно заранее, но так получается не всегда. Что делать, если нагрузка уже взлетела выше некуда и всё вот-вот рухнет? Рассказываем в статье «Что делать, если «Черная пятница» завтра, а ваши серверы не готовы».
Для иллюстрации использованы иконки с icons8.ru
