Настройка распределения нагрузки L4/L7 на Nginx под ключ

Практические сценарии настройки Nginx для L4/L7

Представьте: ваш интернет-магазин тормозит, половина запросов уходит в таймаут, а мониторинг показывает, что один сервер перегружен на 90%, а два других простаивают. Это классическая проблема неверно настроенной балансировки. Типичная картина: backend-серверы имеют разную мощность (например, один с 4 vCPU, два с 2 vCPU), и round-robin направляет равное количество запросов, перегружая слабые узлы. Это приводит к каскадному увеличению задержки — время ответа TTFB взлетает до 3-5 секунд, а часть запросов падает по ограничению соединений. Промышленная L7 балансировка на Nginx с использованием least_connections и весами решает проблему.

На практике мы сталкивались с проектом, где из-за round-robin время ответа достигало 10 секунд. После перехода на least_conn с весами нагрузка выровнялась, а время ответа снизилось на 40%. По нашим замерам, least_connections работает в 2-3 раза эффективнее round-robin при разной длительности запросов. При среднем чеке $27–39 потеря каждого десятого клиента обходится в $8.1k–12k в год.

В этой статье расскажем о реальных технических сложностях, которые встречаются на практике — от потери сессий до SSL passthrough — и как их преодолеть.

Почему балансировка L4/L7 критична для высоконагруженных проектов?

Отказ одного сервера может привести к недоступности всего сервиса. Без корректных health checks и failover пользователи получают ошибки 502. Кроме того, неоптимальное распределение запросов увеличивает время отклика в 2-3 раза, что напрямую влияет на конверсию. Балансировка на уровне L4 (TCP/UDP) подходит для любых протоколов, но не учитывает содержимое запроса. L7 (HTTP/HTTPS) даёт гибкость: можно маршрутизировать по URL, заголовкам, cookies. Вместе они покрывают любые сценарии.

Когда использовать L4, а когда L7?

Выбор уровня зависит от задачи. L4 балансировка (через модуль stream) незаменима для сервисов, где не нужно анализировать протокол: базы данных (MySQL, PostgreSQL), Redis, SSH. Она вносит минимальную задержку (около 1 мс). L7 подходит для HTTP-приложений, где требуется sticky sessions, канареечный деплой или A/B тестирование. Например, для интернет-магазина с корзиной — L7 с IP hash или cookie-based sticky. Для микросервисной архитектуры часто комбинируют: L4 для балансировки трафика между подами, L7 для маршрутизации внутри.

Проблемы, которые мы решаем

• Неравномерное распределение нагрузки. Round-robin не всегда равномерен: при неравномерной нагрузке на запросы (например, одни запросы тяжелее других) серверы забиваются неравномерно. Мы используем least_connections или weighted least_connections, чтобы это компенсировать.
• Потеря сессий при сбое backend. Без sticky sessions пользователь снова попадает на другой сервер, теряя данные корзины. Мы внедряем cookie-based sticky или hash $cookie_SERVERID consistent.
• Некорректные health checks. Если пассивная проверка не срабатывает, трафик уходит на упавший сервер. Настраиваем max_fails и fail_timeout, а для критичных систем — активные health checks через Nginx Plus или внешний мониторинг.
• SSL passthrough для L4. Проксирование HTTPS без расшифровки требует ssl_preread + SNI маршрутизацию. Это неочевидная настройка, которую часто упускают.

Как мы это делаем: стек и конфигурация

Используем Nginx Open Source (стабильная версия) или Nginx Plus при необходимости enterprise-функций. В проектах применяем GitOps-подход: конфиги хранятся в Git, деплой через Ansible или Terraform. Ниже — пример рабочей конфигурации для типового проекта интернет-магазина.

L7 HTTP балансировка

# /etc/nginx/conf.d/upstream.conf
upstream app_rr {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
    keepalive 64;
}

upstream app_lc {
    least_conn;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080 weight=2;
    server 10.0.1.12:8080;
}

upstream app_ip_hash {
    ip_hash;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080 down;
}

upstream app_random {
    random two least_conn;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

Сравнение алгоритмов балансировки

Таблица сравнения L4 и L7 балансировки

Health checks и failover

upstream app_backend {
    server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:8080 backup;
    keepalive 64;
    keepalive_requests 1000;
    keepalive_time 1h;
}

server {
    listen 443 ssl http2;
    server_name app.example.com;
    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    location / {
        proxy_pass http://app_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
        proxy_next_upstream error timeout http_500 http_502 http_503;
        proxy_next_upstream_tries 2;
        proxy_next_upstream_timeout 10s;
    }
}

proxy_next_upstream — мощный, но опасный инструмент. Мы включаем http_500 только после тщательного анализа: если запрос был POST и уже выполнился частично, повторная отправка может дублировать операцию. Поэтому для идемпотентных методов (GET, PUT) — да, для POST — с осторожностью.

Cookie-based Sticky Sessions

upstream app_sticky {
    hash $cookie_SERVERID consistent;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

L4 TCP балансировка через stream модуль

stream {
    log_format basic '$remote_addr [$time_local] ' '$protocol $status $bytes_sent $bytes_received ' '$session_time';
    access_log /var/log/nginx/stream-access.log basic;

    upstream mysql_cluster {
        least_conn;
        server 10.0.1.20:3306;
        server 10.0.1.21:3306;
        server 10.0.1.22:3306 backup;
    }

    server {
        listen 3306;
        proxy_pass mysql_cluster;
        proxy_connect_timeout 5s;
        proxy_timeout 300s;
    }

    upstream https_backends {
        server 10.0.1.10:443;
        server 10.0.1.11:443;
    }

    server {
        listen 443;
        proxy_pass https_backends;
        ssl_preread on;
    }
}

Для мониторинга upstream используем stub_status + Prometheus-экспортер — это даёт метрики nginx_up, nginx_connections_active и т.д.

upstream app_cluster {
    least_conn;
    server 10.0.1.10:8080 max_fails=5 fail_timeout=60s;
    server 10.0.1.11:8080 max_fails=5 fail_timeout=60s;
    server 10.0.1.12:8080 backup;
    keepalive 128;
}

server {
    listen 80 default_server;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    ssl_certificate /etc/nginx/ssl/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/key.pem;

    location / {
        proxy_pass http://app_cluster;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Процесс работы

1. Аналитика — собираем архитектуру, метрики текущей нагрузки, определяем алгоритм и количество upstream-серверов.
2. Проектирование — проектируем конфигурацию, согласуем health checks, timeout-ы, политики retry.
3. Реализация — настраиваем Nginx, разворачиваем через GitOps (Ansible/Terraform), проверяем на staging.
4. Тестирование — нагрузочное тестирование, проверка failover, мониторинг.
5. Деплой — blue-green или canary rollout с нулевым downtime.

Сроки и стоимость

Стандартный проект (до 5 upstream-серверов) занимает от 1 до 3 дней. Стоимость рассчитывается индивидуально — зависит от сложности конфигурации, необходимости sticky sessions и интеграции с мониторингом. Закажите настройку балансировки у профессионалов — оставьте заявку на сайте.

Что входит в работу

• Настройка Nginx L4/L7 балансировки с выбранным алгоритмом.
• Health checks и failover.
• Cookie-based sticky sessions (при необходимости).
• Мониторинг (stub_status + Prometheus, или настройка Datadog).
• Документация конфигурации и процедуры эксплуатации.
• Обучение вашей команды основам поддержки.
• 2 недели послепусковой поддержки.

Гарантия и опыт

Наши инженеры имеют сертификаты NGINX и Kubernetes, а за плечами — более 50 реализованных проектов по балансировке. Настройка закрепляется SLO с гарантией отказоустойчивости.

Получите консультацию эксперта — свяжитесь с нами, чтобы обсудить вашу архитектуру. Мы поможем выбрать правильный алгоритм и настроить мониторинг.

Источник: Балансировка нагрузки