HAProxy для высоконагруженного e-commerce: балансировка 50 000 одновременных пользователей

HAProxy проверяет здоровье бэкендов тремя способами:

• L4 TCP check — просто открывает TCP-соединение. Быстро, но не ловит зависшее приложение.
• L7 HTTP check — отправляет HTTP-запрос и проверяет ответ. Мы используем именно этот вариант.
• Agent check — внешний скрипт на бэкенде сообщает HAProxy свой статус и вес.

Наш health check endpoint на Node.js:

// health.js — эндпоинт для HAProxy health check
app.get('/health', async (req, res) => {
  try {
    // Проверяем подключение к БД
    await db.query('SELECT 1');

    // Проверяем Redis
    await redis.ping();

    // Проверяем свободную память (не менее 100 МБ)
    const freeMemMB = os.freemem() / 1024 / 1024;
    if (freeMemMB < 100) {
      return res.status(503).json({ status: 'degraded', reason: 'low memory' });
    }

    // Проверяем Event Loop Lag (не более 100 мс)
    if (eventLoopLag > 100) {
      return res.status(503).json({ status: 'degraded', reason: 'event loop lag' });
    }

    res.status(200).json({ status: 'ok', uptime: process.uptime() });
  } catch (err) {
    res.status(503).json({ status: 'error', reason: err.message });
  }
});

Параметры inter 3s fall 3 rise 2 означают: проверять каждые 3 секунды, считать сервер упавшим после 3 неудач, считать восстановленным после 2 успехов. Суммарное время обнаружения сбоя — 9 секунд.

Connection queuing — важная функция HAProxy, отсутствующая в Nginx. Когда все соединения к бэкенду заняты (maxconn 15000), HAProxy не отклоняет запрос, а ставит его в очередь на timeout queue 30s. Это позволяет выдержать кратковременные пики без ошибок 503.

Stick tables — уникальная возможность HAProxy, позволяющая хранить данные о клиентах (IP, cookie, header) прямо в памяти балансировщика без внешних хранилищ.

Мы использовали stick tables для трёх задач:

1. Rate limiting (защита от DDoS и парсеров):

# В секции frontend:
stick-table type ip size 200k expire 30s store http_req_rate(10s),conn_cur,gpc0

# Трекаем каждый IP
http-request track-sc0 src

# Мягкий лимит — 100 req/10s → 429
http-request deny deny_status 429 if { sc_http_req_rate(0) gt 100 }

# Жёсткий лимит — 500 req/10s → бан на 10 минут
http-request sc-set-gpc0(0) 1 if { sc_http_req_rate(0) gt 500 }
acl is_banned sc_get_gpc0(0) gt 0
http-request deny deny_status 403 if is_banned

2. Session persistence (привязка к серверу):

# В backend — привязка по cookie
backend be_app
    stick-table type string len 52 size 100k expire 30m
    stick store-response res.cook(PHPSESSID)
    stick match req.cook(PHPSESSID)

3. Мониторинг stick tables в реальном времени:

# Просмотр содержимого stick table
echo "show table fe_https" | socat stdio /run/haproxy/admin.sock

# Пример вывода:
# 0x55a8c7f23420: key=192.168.1.50 use=0 exp=24312 http_req_rate(10000)=42 conn_cur=3 gpc0=0
# 0x55a8c7f24680: key=45.33.22.11  use=0 exp=1523  http_req_rate(10000)=847 conn_cur=87 gpc0=1

# Ручной бан IP
echo "set table fe_https key 45.33.22.11 data.gpc0 1" | socat stdio /run/haproxy/admin.sock

# Разбан IP
echo "clear table fe_https key 45.33.22.11" | socat stdio /run/haproxy/admin.sock

На распродаже stick tables автоматически заблокировали 340 IP-адресов парсеров и 12 IP ботнета, которые пытались положить сайт. Всё — без внешних WAF и дополнительных сервисов.

SSL termination на HAProxy экономит до 30% CPU на бэкендах. Настройка:

# Подготовка сертификата — HAProxy требует PEM с ключом и сертификатом в одном файле
cat /etc/letsencrypt/live/megashop.ru/fullchain.pem \
    /etc/letsencrypt/live/megashop.ru/privkey.pem \
    > /etc/haproxy/certs/megashop.ru.pem
chmod 600 /etc/haproxy/certs/megashop.ru.pem

# Автообновление сертификата (cron)
0 3 * * * certbot renew --deploy-hook "cat /etc/letsencrypt/live/megashop.ru/fullchain.pem /etc/letsencrypt/live/megashop.ru/privkey.pem > /etc/haproxy/certs/megashop.ru.pem && systemctl reload haproxy"

Hot reload — HAProxy перечитывает конфигурацию без потери соединений:

# Проверка конфигурации перед reload
haproxy -c -f /etc/haproxy/haproxy.cfg
# Configuration file is valid

# Reload без потери соединений
systemctl reload haproxy

# Что происходит при reload:
# 1. Запускается новый процесс HAProxy с новой конфигурацией
# 2. Новый процесс принимает новые соединения
# 3. Старый процесс дообслуживает существующие соединения
# 4. После закрытия всех соединений старый процесс завершается

# Мониторинг reload через stats socket
echo "show proc" | socat stdio /run/haproxy/admin.sock

За время распродажи мы делали reload 4 раза (добавление бэкендов, изменение rate limits) — ни одного обрыва соединения.

Один HAProxy — single point of failure. Мы развернули два HAProxy с Keepalived для автоматического переключения виртуального IP:

# /etc/keepalived/keepalived.conf — MASTER (haproxy1)
vrrp_script chk_haproxy {
    script "/usr/bin/killall -0 haproxy"
    interval 2
    weight -20
    fall 3
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 110
    advert_int 1
    unicast_src_ip 10.0.0.1
    unicast_peer {
        10.0.0.2
    }
    authentication {
        auth_type PASS
        auth_pass megashop_vrrp_2025
    }
    virtual_ipaddress {
        10.0.0.100/24
    }
    track_script {
        chk_haproxy
    }
    notify_master "/etc/keepalived/notify.sh MASTER"
    notify_backup "/etc/keepalived/notify.sh BACKUP"
    notify_fault  "/etc/keepalived/notify.sh FAULT"
}

# /etc/keepalived/keepalived.conf — BACKUP (haproxy2)
vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    # ... остальное идентично
}

При падении HAProxy на master-ноде Keepalived обнаруживает это за 6 секунд (interval 2 * fall 3) и переключает VIP на backup. Клиенты не замечают переключения — TCP-соединения пересоздаются через браузер автоматически.

Распродажа прошла без единого 503 при пиковых 52 000 одновременных пользователях:

Рекомендации по HAProxy:

• Всегда используйте option httpchk вместо TCP check — падение приложения при работающем TCP-порте будет обнаружено только HTTP check.
• Включайте maxconn на серверах — это предотвращает перегрузку бэкенда и активирует connection queuing.
• Stick tables заменяют внешний rate limiter для 90% сценариев — не тратьте деньги на Cloudflare при обычных нагрузках.
• Keepalived — обязательный компонент, настройка занимает 30 минут, а защищает от полного простоя.