Для компании сайт, интернет-магазин или личный кабинет являются рабочим контуром: через них оформляются заказы, загружаются документы, выполняется авторизация, проводится оплата. Если этот контур размещён на одном сервере, любой пик обращений или любой отказ оборудования останавливает сервис целиком.
Крупные системы не направляют весь трафик на один сервер. Между клиентами и серверами приложения устанавливается балансировщик нагрузки. Он принимает входящие запросы и распределяет их между несколькими одинаковыми серверами бэкенда, чтобы ни один из них не был перегружен.
В чём заключается проблема
На одном сервере система работает стабильно при умеренной посещаемости. При одновременном росте числа запросов — в период акции, рекламной кампании, сезонного спроса или утренней рабочей нагрузки в B2B-портале — время ответа увеличивается. Далее появляются ошибки 502 и 503, обрывы сессий, сбои на этапе оплаты.
Отдельный риск связан не с пиковой нагрузкой, а с отказом. Перезагрузка, исчерпание диска, сбой приложения или регламентные работы на единственном сервере делают недоступным весь сервис. Для организации это означает остановку продаж и внутренних процессов, а не локальную техническую неисправность.
Если продукт участвует в выручке или в операционной работе сотрудников, зависимость от одного узла является архитектурным ограничением. Его необходимо учитывать на этапе проектирования.
Почему возникает перегрузка и простой
Ресурсы сервера ограничены: процессорное время, память, число одновременных соединений, пропускная способность диска. Каждый запрос к каталогу, расчёт корзины, авторизация, генерация документа и обращение к внешней системе потребляет часть этих ресурсов.
Пока поток запросов невелик, запас сохраняется. При росте очереди сначала увеличивается задержка, затем часть запросов завершается по таймауту. Особенно критичны длительные операции: обращение к платёжному шлюзу, обмен с 1С, формирование PDF. Они занимают рабочие процессы приложения и сокращают число слотов для остальных пользователей.
Вторая причина — единая точка отказа. Если витрина, личный кабинет, генерация файлов и фоновые задания выполняются на одном сервере, любой его отказ останавливает все функции одновременно.
Третья причина проявляется при попытке добавить второй сервер без подготовки. Если сессии, загруженные файлы и служебные данные хранятся локально, запросы одного пользователя, попавшие на разные узлы, обрабатываются несогласованно. В этом случае увеличение числа серверов не повышает устойчивость, а создаёт расхождения в данных.
Принцип работы балансировщика нагрузки
Схема прохождения трафика:
клиенты → балансировщик нагрузки → серверы бэкенда
Пользователь обращается к сайту по единому адресу. Запрос поступает на балансировщик. Балансировщик выбирает доступный сервер приложения и направляет запрос на него. Ответ возвращается клиенту тем же путём. Для пользователя система выглядит как один сайт.
Корректно настроенный балансировщик выполняет четыре основные функции.
Равномерное распределение запросов
Входящие запросы направляются на несколько однотипных серверов, чтобы нагрузка не концентрировалась на одном узле. Однотипность серверов обязательна: при разной производительности распределение по числу запросов перегрузит более слабый узел раньше остальных.
Основные алгоритмы выбора сервера:
round robin — запросы передаются серверам по очереди;
least connections — запрос направляется на узел с наименьшим числом текущих соединений;
IP hash — запросы с одного IP-адреса направляются на один и тот же сервер.
Round robin приемлем, если запросы сопоставимы по трудоёмкости. Он даёт искажённую картину, если часть операций существенно тяжелее остальных: генерация документов, выгрузки, обращения к внешним системам. Least connections учитывает занятость узла и обычно лучше подходит для смешанной нагрузки. IP hash закрепляет пользователя за сервером по адресу, но даёт неравномерность при работе через общий корпоративный NAT и разрывает привязку при смене адреса.
Проверка состояния серверов
Балансировщик периодически проверяет, способен ли сервер обрабатывать запросы. Неисправный узел исключается из пула, новые запросы направляются только на работоспособные серверы.
Проверка должна относиться к состоянию приложения, а не только к доступности сети. Ответ на ICMP-запрос означает, что узел включён, но не подтверждает работу приложения, базы данных и диска. Открытие TCP-порта веб-сервера также недостаточно, если само приложение не отвечает. Проверка главной страницы может завершаться успешно за счёт кэша, в то время как оформление заказа уже недоступно.
Работоспособная проверка обращается к выделенному служебному адресу, который подтверждает готовность приложения и его зависимостей. Пороги исключения и возврата узла в пул необходимо задавать так, чтобы кратковременный сбой не выводил сервер из работы без необходимости, а устойчивая деградация не оставляла его в пуле.
Отказоустойчивость
При отказе одного сервера остальные продолжают обработку. Полная недоступность сервиса в этом случае не является неизбежной. Производительность может снизиться, поскольку нагрузка распределяется на меньшее число узлов, однако сервис сохраняет работоспособность.
Это свойство реализуется только при условии, что серверы взаимозаменяемы. Если состояние пользователя хранится исключительно в памяти или на диске одного узла, отказ этого узла приводит к потере сессии, корзины или загруженных файлов.
Закреплённые сессии
Ряд приложений требует, чтобы запросы одного пользователя обрабатывались на одном и том же сервере: локальная сессия, промежуточное состояние оформления заказа, файлы, сохранённые только на конкретном узле. В таких случаях балансировщик закрепляет сессию за выбранным сервером.
Это решение допустимо как временная мера. Оно не устраняет зависимость от конкретного узла: при его отказе закреплённые пользователи теряют состояние. Кроме того, закрепление снижает эффективность распределения, поскольку нагрузка перестаёт свободно перераспределяться между серверами.
Предпочтительный подход — централизованное хранение сессий, файлов и очередей. Тогда любой сервер может продолжить обработку запроса пользователя, а закрепление сессий не требуется.
Уровень балансировки: L4 и L7
Балансировка на уровне соединения (L4) учитывает адрес и порт. Содержимое HTTP-запроса не анализируется. Такое решение эффективно для однородного потока и минимальной задержки, но не позволяет направлять различные типы запросов в разные пулы и корректно выводить узел из обработки без разрыва соединений.
Балансировка на уровне приложения (L7) анализирует HTTP-запрос: путь, заголовки, в отдельных конфигурациях — cookie. Это позволяет разделять витрину и оформление заказа, завершать TLS на балансировщике, исключать узел из пула после завершения текущих запросов. Для интернет-магазина, личного кабинета и B2B-портала, как правило, требуется именно этот режим.
Необходимо различать смежные механизмы. CDN кэширует статическое содержимое ближе к пользователю и не обрабатывает расчёт корзины или оплату. Кэширование и СУБД решают другие задачи: повторные чтения и хранение данных. Балансировщик не ускоряет медленный SQL-запрос и не заменяет резервирование базы данных. При нескольких копиях приложения и одной перегруженной базе данных узкое место смещается, но не устраняется.
Когда балансировка нагрузки требуется бизнесу
Балансировщик не является обязательным компонентом любого сайта. Для корпоративной визитки, лендинга и сайта услуг с формой заявки достаточно одного сервера, резервного копирования и мониторинга.
Решение следует рассматривать, если выполняются следующие условия:
сайт или сервис участвует в продажах либо в ежедневной работе сотрудников;
прогнозируются пиковые периоды: акции, рекламные кампании, сезонность;
используются личный кабинет, B2B-портал, онлайн-оплата, обмен с 1С;
простой сервиса приводит к потере заказов или остановке внутренних процессов;
текущая инфраструктура построена на одном сервере без резервного контура обработки запросов.
Если приложение нельзя сделать взаимозаменяемым в разумный срок — сессии и файлы остаются локальными. Введение второго сервера под балансировщиком может ухудшить поведение системы. В таком случае приоритетнее укрепление одного контура, резервное копирование и проработанный сценарий восстановления.
Требования к сайту и серверной части
Балансировщик эффективен только если сайт и его серверная часть к этому готовы.
Несколько одинаковых серверов с сайтом.
Распределять запросы между одним рабочим узлом невозможно. Требуется как минимум два однотипных сервера с одной и той же версией сайта.
Общее хранение данных.
Сессии, загруженные файлы, сгенерированные документы и служебный кэш не должны храниться только на диске отдельного сервера. Иначе пользователь будет получать разный результат в зависимости от выбранного узла: пропавшая корзина, недоступный документ, повторный вход в кабинет.
Корректная проверка работоспособности.
Балансировщик должен получать сигнал, что сайт действительно обрабатывает запросы, а не только что сервер включён и отвечает на сетевой опрос.
Единая точка запуска фоновых заданий.
При двух серверах одинаковые задания планировщика не должны выполняться дважды: это приводит к повторной отправке писем и повторному запуску обмена с учётной системой. Фоновые процессы выносят на выделенный сервер либо ограничивают одним экземпляром.
Согласованный выпуск обновлений.
Сервер выводится из пула, завершает текущие запросы и только после этого обновляется. Одновременная работа двух версий сайта при незавершённой миграции базы данных создаёт ошибки, которые сложно диагностировать.
Наблюдаемость.
Необходимы сведения о числе запросов, времени ответа, кодах ошибок и составе пула серверов. Без этого невозможно отличить отказ сайта от неверной настройки распределения трафика.
Практические рекомендации
Перед внедрением балансировщика следует зафиксировать ответы на конкретные вопросы.
Где хранится сессия после авторизации: в локальном файле, в базе данных или в отдельном хранилище.
Что происходит с запросом оплаты, если выбранный сервер становится недоступен в момент обработки.
Какой адрес используется для проверки состояния и что именно он подтверждает.
Где размещаются загруженные файлы и формируемые документы.
На каком узле запускаются задания планировщика и обмен с 1С.
Каким образом выполняется выпуск новой версии без полной остановки сервиса.
Отсутствие ответов означает, что сценарий пиковой нагрузки и отказа не проработан. В этом случае сначала приводят в порядок хранение состояния и зависимости приложения, затем вводят распределение трафика.
Вертикальное увеличение мощности одного сервера повышает запас производительности, но не устраняет единую точку отказа. Горизонтальная схема с балансировщиком требует более сложного сопровождения, однако позволяет сохранять сервис при отказе отдельного узла и проводить обновления без полной недоступности.
Для бизнеса типичны два рабочих варианта: облачный балансировщик провайдера и отдельный входной узел на базе nginx или HAProxy перед двумя серверами приложения. Kubernetes и ingress оправданы, если кластер уже используется. Разворачивать его исключительно ради двух копий типового магазина, как правило, избыточно.
Примеры применения
Интернет-магазин в период акции. Рост числа одновременных обращений к каталогу и оформлению заказа. При одном сервере очередь запросов приводит к задержкам и ошибкам на этапе оплаты. При двух и более копиях приложения балансировщик распределяет входящие запросы; проверка состояния исключает неисправный узел из пула.
B2B-портал в начале рабочего дня. Сотрудники и клиенты одновременно открывают счета, остатки и документы. Нагрузка носит рабочий, а не рекламный характер. Здесь существенны и распределение запросов, и сохранение сессии: повторная авторизация в ходе операции снижает качество работы с системой.
Личный кабинет с загрузкой файлов. Документ, сохранённый только на одном сервере, будет недоступен, если следующий запрос поступит на другой узел. Файлы размещают в общем хранилище. Балансировщик распределяет запросы, но не заменяет общее файловое пространство.
Выпуск обновления. Часть серверов временно исключается из пула, обновляется и возвращается в работу. Пользователи продолжают работать с оставшимися узлами. Полная остановка сайта для выкладки новой версии в этом случае не является обязательной.
Выводы
Балансировщик нагрузки распределяет входящие запросы между несколькими серверами приложения, проверяет их состояние и позволяет сохранить работоспособность сервиса при отказе отдельного узла.
Для пользователя система остается одним адресом. Для организации появляется возможность принимать пиковую нагрузку и проводить обслуживание без полной недоступности. Это достигается только если серверы взаимозаменяемы, проверка состояния отражает реальную готовность приложения, а сессии и файлы не привязаны к локальному диску одного узла.
Необходимость решения определяется не размером компании, а стоимостью простоя и характером нагрузки. Если сайт, магазин, портал или личный кабинет участвуют в продажах и операционной деятельности, вопрос формулируется так: сохраняется ли зависимость от одного сервера или система проектируется с учётом распределения трафика.
Когда целесообразно обратиться к специалистам
Если вы разрабатываете или развиваете интернет-магазин, B2B-портал, личный кабинет либо веб-сервис и предполагаете рост нагрузки либо уже фиксируете снижение производительности в отдельные периоды, распределение запросов следует закладывать в архитектуру до запуска рекламных кампаний и сезонных акций.
Мы проектируем и сопровождаем такие системы для бизнеса: от корпоративных сайтов до сервисов с личными кабинетами, интеграциями и AI-сценариями. Можем проанализировать текущую инфраструктуру, определить единые точки отказа и предложить схему, соответствующую фактическим сценариям использования, без избыточной сложности.
Интересует похожий проект?
Всё очень просто!
