Балансировщик и второй сервер: с какого трафика они окупаются

MAATRIX

Рано или поздно у любого растущего проекта возникает один и тот же вопрос: не пора ли добавить второй сервер и балансировщик перед ним. Инфраструктура из двух узлов и распределителя нагрузки стоит денег каждый месяц независимо от того, используется ли она на пределе или простаивает большую часть времени. Ниже — не универсальное число «столько-то запросов в секунду», а методика, которая позволяет посчитать порог именно для вашего проекта: когда сложность и стоимость такой схемы начинают окупаться, а когда она — просто лишняя статья расходов.

Почему один сервер — это нормально, пока не доказано обратное

Один сервер — самая простая, дешёвая и предсказуемая конфигурация. У неё нет проблем распределённых систем: не нужно синхронизировать сессии между узлами, не нужно думать про sticky-соединения, не нужно беспокоиться о том, что балансировщик отправит запрос на узел с устаревшим кэшем. Логи в одном месте, деплой — это один systemctl restart, отладка — это один journalctl -u app -f без необходимости сопоставлять события на двух машинах.

Добавление балансировщика и второго сервера — это не апгрейд «стало лучше», это смена архитектуры с новым классом проблем: balance-алгоритмы, health-check'и, консистентность состояния, синхронизация конфигов и сертификатов, двойная стоимость лицензий там, где они привязаны к серверу. Если текущий сервер справляется с нагрузкой и простой один раз в полгода на десять минут не наносит бизнесу заметного ущерба — усложнять архитектуру рано. Часто более дешёвым и эффективным следующим шагом оказывается не горизонтальное масштабирование, а вертикальное — apgрейд текущего тарифа по CPU/RAM, оптимизация запросов к БД, включение кэша. Это стоит проверить в первую очередь, прежде чем переходить к архитектуре с балансировщиком.

Вопрос «когда добавлять второй сервер» имеет смысл не как абстрактный, а применительно к двум конкретным и разным по природе триггерам — они не всегда наступают одновременно.

Два независимых триггера: производительность и отказоустойчивость

Первый триггер — производительность. Текущий сервер физически не справляется с потоком запросов: CPU упирается в 100% на пиках, растёт latency, начинают копиться очереди в приложении или в очереди установленных, но не принятых соединений (backlog). Здесь второй сервер и балансировщик решают задачу распределения нагрузки — это горизонтальное масштабирование в чистом виде.

Второй триггер — риск простоя единственной точки отказа, и он никак не связан с тем, справляется ли сервер по ресурсам. Даже сервер, загруженный на 20%, может упасть: из-за сбоя диска, зависшего процесса, human error при деплое, планового обслуживания у провайдера, DDoS-атаки на IP. При одном сервере любой из этих сценариев — это полный простой сервиса на время диагностики и восстановления. Здесь балансировщик с двумя узлами решает не задачу нагрузки, а задачу доступности: он выводит из ротации сервер, не прошедший health-check, и трафик продолжает идти через живой узел.

Это разделение важно, потому что решения принимаются по-разному. Порог по нагрузке считается через мониторинг текущей утилизации ресурсов. Порог по риску простоя считается через экономику — через цену часа простоя, помноженную на вероятность и частоту инцидентов. Проект с низким трафиком, но высокой ценой репутационного риска (например, платёжный шлюз или сервис для B2B-клиентов с SLA в договоре) может перейти на схему с двумя узлами куда раньше, чем того требует чистая нагрузка.

Как измерить, что сервер действительно упирается в лимит

Прежде чем тратиться на второй сервер ради производительности, нужно достоверно зафиксировать, что дело в ресурсах, а не в неоптимальном коде или неверно настроенном веб-сервере. Разовый взгляд на top в момент жалобы пользователя ничего не доказывает — нужны данные за период, а не снапшот.

Минимальный набор метрик, которые стоит снимать постоянно:

• CPU — не только средняя утилизация, но и load average за 1/5/15 минут (uptime, vmstat 1). Если load average стабильно выше числа ядер — процессор действительно узкое место.
• Память и своп — free -m, включение свопа под нагрузкой резко увеличивает latency и часто маскируется под «сервер тормозит», хотя причина в нехватке RAM, а не CPU.
• Очередь соединений на веб-сервере. Для nginx это active connections, waiting, а также backlog в listen — если очередь на прослушиваемом сокете регулярно заполняется, новые соединения начинают сбрасываться ещё до того, как приложение их увидело.
• Latency и error rate приложения — время ответа по перцентилям (p50/p95/p99), а не среднее: среднее скрывает деградацию хвоста запросов, которую замечают пользователи.
• Соединения к БД — упирается ли пул соединений в лимит max_connections, растёт ли время ожидания свободного соединения из пула.

Практический способ снять эти метрики без сложной обвязки — установить лёгкий self-hosted мониторинг вроде Uptime Kuma для внешнего контроля доступности и Netdata или связку node_exporter + Prometheus + Grafana для внутренних метрик ресурсов. Для старта достаточно и системных утилит, запущенных по cron с записью в файл, — важно накопить хотя бы 2-4 недели данных, захватывающих характерные пики (утро буднего дня, распродажа, конец месяца — у каждого проекта свой профиль).

Сигнал «пора масштабироваться по производительности» — это не единичный всплеск, а устойчивая картина: CPU или latency стабильно выходят за комфортный порог (условно, load average выше числа ядер или p95 latency ощутимо растёт) в течение рабочих часов на протяжении нескольких недель подряд, а не только в момент разовой рекламной кампании. Разовый пик логичнее гасить временным апгрейдом тарифа на день-два, а не постоянной архитектурой из двух узлов.

Как оценить цену риска простоя одной точки отказа

Второй триггер считается иначе — через ожидаемую стоимость инцидента, а не через загрузку CPU. Базовая формула:

Ожидаемые потери от простоя (в год) =
  Частота инцидентов (шт/год) × Средняя длительность простоя (ч) × Цена часа простоя (₽/ч)

Цена часа простоя — это не абстракция, а сумма нескольких компонент, которые стоит прикинуть отдельно для своего проекта:

• Прямая упущенная выручка — сколько заказов/подписок/транзакций в среднем проходит за час в ваши рабочие часы.
• Стоимость SLA-компенсаций, если они прописаны в договорах с клиентами.
• Отток пользователей — часть аудитории, которая после сбоя не возвращается или переходит на альтернативу; для B2C-сервисов с низким порогом переключения эта статья часто дороже прямой выручки.
• Время команды на инцидент — устранение аварии, коммуникация с клиентами, постмортем.
• Репутационный ущерб — тяжело формализуется, но для проектов, зависящих от доверия (финтех, инфраструктурные сервисы), стоит закладывать явный коэффициент.

Частоту инцидентов и их длительность для одного сервера логично оценивать не «с потолка», а по собственной истории аптайма (если сервис живёт хотя бы несколько месяцев) либо по декларируемому провайдером SLA для одного сервера — но с поправкой на то, что SLA провайдера покрывает только его инфраструктуру, а не сбои в вашем приложении, деплое или ОС.

Дальше сравниваете эту цифру с ежемесячной стоимостью второй точки: аренда второго сервера + балансировщика (или managed load balancer у провайдера) + время администратора на поддержку более сложной схемы. Если ожидаемые годовые потери от простоя одного узла выше годовой стоимости резервной схемы — переход экономически оправдан уже сегодня, независимо от загрузки CPU. Отдельно с этой темой стоит ознакомиться в разборе экономики уровней доступности: каждая девятка аптайма обходится дороже предыдущей, и переход от одного узла к двум обычно — самый резкий скачок по цене и по эффекту одновременно.

Считаем итоговую точку окупаемости: пример логики расчёта

Сведите оба триггера в одну таблицу — это удобнее, чем держать два разрозненных вывода в голове.

Формальный критерий перехода — выполнение хотя бы одного из условий:

1. По нагрузке. Метрики за 2-4 недели показывают устойчивое приближение к лимиту ресурсов текущего тарифа в рабочие часы, а вертикальный апгрейд тарифа либо уже упёрся в потолок линейки провайдера, либо экономически менее выгоден, чем горизонтальное масштабирование (что бывает на верхних тарифах, где цена растёт быстрее ресурсов).
2. По риску. Ожидаемые годовые потери от простоя > Годовая стоимость резервной схемы (второй сервер + балансировщик + время на поддержку).

Если оба условия далеки от выполнения — оставайтесь на одном сервере и вложите освободившийся бюджет в мониторинг, автоматические бэкапы и быстрый скрипт восстановления: это дешевле и часто снижает цену простоя эффективнее, чем архитектурное усложнение. Если проект стоит на границе — разумный промежуточный шаг — тёплый резерв без постоянного балансировщика: сравнение холодного, тёплого и горячего резерва по стоимости даёт третий вариант между «один сервер» и «полноценная схема с балансировщиком».

Что учесть при выборе схемы, если решение принято

Когда расчёт показал, что переход оправдан, остаётся два практических вопроса — какой балансировщик ставить и как избежать того, что вторая точка окажется мнимой.

Выбор балансировщика. Для большинства веб-проектов достаточно nginx или HAProxy на отдельном небольшом узле (или на одном из существующих серверов, если ресурс позволяет и вы осознанно принимаете, что этот узел частично теряет независимость). HAProxy обычно предпочтительнее для L4/L7-балансировки с гибкими алгоритмами и детальными health-check'ами, nginx — когда балансировка нужна попутно с уже настроенным reverse proxy и TLS-терминацией. Подробное сравнение есть в статье HAProxy или nginx для балансировки: что выбрать для сервера, а пошаговая настройка — в материале как установить и настроить балансировку нагрузки на VPS.

Простейший конфиг с health-check на HAProxy для двух backend-узлов:

frontend http_front
    bind *:80
    default_backend app_servers

backend app_servers
    balance roundrobin
    option httpchk GET /health
    http-check expect status 200
    server app1 10.0.0.11:8080 check inter 3s fall 3 rise 2
    server app2 10.0.0.12:8080 check inter 3s fall 3 rise 2

Параметры fall/rise определяют, через сколько неудачных/успешных проверок узел выводится из ротации или возвращается в неё — их стоит подбирать так, чтобы не выводить сервер из-за случайного разового таймаута, но и не держать в ротации узел, который уже 30 секунд не отвечает.

Мнимая вторая точка. Частая ошибка — поставить второй сервер приложения, но оставить единственную базу данных без репликации, единственный DNS-провайдер или единственный upstream-канал у самого балансировщика. В этом случае вы удвоили счёт за инфраструктуру, но не устранили точку отказа — просто передвинули её на уровень ниже. Прежде чем считать переход завершённым, пройдитесь по всей цепочке: приложение, БД, DNS, сам балансировщик (он тоже единственная точка, если не зарезервирован через keepalived/VRRP или managed-решение провайдера), сеть до дата-центра.

Также стоит учитывать состояние (session state, файлы загрузок, локальный кэш) — если приложение хранит что-то на диске конкретного узла, при балансировке round-robin пользователь может «прыгать» между серверами и терять контекст. Решение — вынести состояние в общее хранилище (Redis для сессий, S3-совместимое хранилище или сетевая ФС для файлов) до включения балансировки, а не после того, как пользователи начнут жаловаться на разлогинивание.

Частые вопросы