В статье на реальных кейсах из разных сфер разберём, почему сайты не справляются с ростом нагрузки. Для соблюдения 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-атаке подтвердилось: в интерфейсе сервиса-защитника мы увидели, как отсекается трафик, который генерируют боты. При этом трафик мебельного интернет-магазина вернулся к нормальным значениям.

Почему сайты падают при росте нагрузки и что с этим делать

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

  1. Провести аудит и нагрузочное тестирование, чтобы определить лимит сайта и выявить узкие места  в инфраструктуре,

  2. Исходя из результатов аудита и нагрузочного тестирования, укрепить ресурс: сделать рефакторинг кода, оптимизировать долгие запросы, перестроить ИТ-инфраструктуру или добавить ресурсов.

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

По-хорошему готовить инфраструктуру к наплыву пользователей нужно заранее, но так получается не всегда. Что делать, если нагрузка уже взлетела выше некуда и всё вот-вот рухнет? Рассказываем в статье «Что делать, если “Черная пятница” завтра, а ваши серверы не готовы».

Для иллюстрации использованы иконки с icons8.ru