Что значит «Высокая нагрузка»? К высоконагруженным проектам относятся любые сайты, сервисы и приложения, которые обрабатывают большое количество запросов. Как определить, что количество запросов должно считаться большим? Нет четкого ответа на этот вопрос: все зависит от инфраструктуры и того, какой у вас сервер. Но, если брать среднее значение, то о высокой нагрузке можно говорить при показателе около 100 запросов в секунду.
В статье рассказываем о «подводных камнях» на таких проектах и о том, как их избежать.
В чем сложность?
Главная сложность в работе высоконагруженных проектов заключается в том, что когда запросов слишком много, то сервер перестает с ними справляться. Он начинает сбоить и это приводит к:
— медленной загрузке страниц сайта;
— внезапным ошибкам в работе сайта, из-за чего пользователи не могут выполнять те или иные действия;
— разрыву соединения между пользователем и сервером.
Пользователи покидают ресурс, не получив того, за чем пришли: не совершают покупку, не завершают регистрации и так далее. Все это приводит к тому, что бизнес теряет этих пользователей, а в конечном итоге, и деньги, которые мог бы на них заработать. В условиях жесткой конкуренции — это становится серьезной проблемой, особенно если речь идет о сотнях или тысячах пользователей.
В высоконагруженных проектах всегда важно использовать надежные технологии и уделять большое внимание тестированию.
Что учесть при разработке высоконагруженного проекта?
- Хранение данных
Чем больше пользователей, тем больше данных (товаров, фотографий, анкет, диалогов и т.д.) они используют. А соответственно, и серверов для того, чтобы эти данные хранить и обрабатывать, нужно больше. Иногда требуется несколько серверов в разных странах, например, если проект международный.
- Динамика объема данных
Важно изначально проектировать такую систему хранения данных, которую возможно быстро масштабировать при необходимости. Представьте, что вы запустили удачную рекламную кампанию, которая произвела вирусный эффект — и на ваш сайт пришли десятки тысяч новых пользователей. Если мощности ваших серверов рассчитаны только на покрытие текущих потребностей, то с резко возросшей нагрузкой они скорее всего не справятся.
Яркий пример — акция «Счастливый час» в H&M онлайн, когда приложение и сайт стабильно «лежит». Результатом таких акций становятся тысячи разгневанных пользователей и сотни негативных отзывов, а не рост продаж.
- Резервное копирование
Жизненно важная необходимость любого высоконагруженного проекта — это запасные серверы или реплики баз данных, на случай если что-то выйдет из строя.
- Кэширование
Можно сохранять данные о запросах пользователя в оперативной памяти, и обращаться к ним, без использования сервера. Страницы загружаются быстрее, а нагрузка на сервер снижается.
Запуск и обновление высоконагруженных проектов
Как правило, процесс загрузки обновлений для рядового сайта происходит быстро, буквально за пару минут, и остается незаметным для пользователей. Высоконагруженные проекты не могут позволить себе даже пары минут задержки в работе. Существуют разные способы выпускать новые версии высоконагруженных проектов так, чтобы пользователи не сталкивались с ошибками или неправильными данными.
В первую очередь, нужно обращать внимание на обратную совместимость кода. Новая версия кода должна быть такой, чтобы работать с данными и в новом формате, и в старом. Кроме того, сложные переносы баз данных лучше осуществлять по шагам, без привязки к обновлению кода.
Какие методы можно использовать:
Штатная система автозагрузки, например, в PHP. Каждый файл в процессе подготовки к выкладке получает свою версию, и в каждом релизе есть карта с актуальными версиями. В продакшн-окружении на каждой машине есть symlink-файл — символическая ссылка — который указывает на нужную карту. Когда все машины получили новый код, одна ссылка меняется на другую. Для всех новых запросов PHP начинает использовать новую карту и, соответственно, новые файлы.
Минус такого подхода в том, что файлы постоянно добавляются, занимают все больше места на диске — их приходится периодически чистить. Кроме того, старый код может продолжать работать в памяти еще несколько дней. Инфраструктура может сильно поменяться, и появляется много ошибок.
Rolling update. При этом методе для развертывания приложений используется внутреннее облако. Всё хранится в контейнерах, и каждое приложение запускается в нескольких экземпляров — балансировщик пускает на них трафик вместо части старых и гасит последние. Так постепенно всё обновляется.
Blue-green. Сначала полностью параллельно «поднимается» нужное количество экземпляров и происходит одномоментное на них переключение. Чтобы использовать такой метод переноса, нужно всегда иметь в запасе в два раза больше свободных ресурсов, что не всегда возможно.