Введение и архитектура HAProxy

HAProxy обрабатывает миллиарды запросов ежедневно на таких платформах как GitHub, Twitter, Instagram. Понимание его архитектуры — ключ к эффективному использованию.

#Что такое HAProxy

HAProxy (High Availability Proxy) — это открытый балансировщик нагрузки и прокси-сервер для TCP и HTTP приложений, разработанный Вилли Тарраном (Willy Tarreau) в 2000 году.

Ключевые особенности:

🚀 Экстремальная производительность — миллионы соединений в секунду
🛡️ Высокая надёжность — используется в production с 2000-х годов
⚙️ Гибкость — балансировка HTTP, TCP, gRPC, WebSocket
📊 Богатая телеметрия — встроенная статистика, Prometheus, Grafana
🔐 Безопасность — SSL/TLS termination, WAF, rate limiting

#Место HAProxy в современной инфраструктуре

                    ┌─────────────┐
    Клиенты ───────►│   HAProxy   │
                    └─────────────┘
                           │
         ┌─────────────────┼─────────────────┐
         ▼                 ▼                 ▼
   ┌──────────┐     ┌──────────┐     ┌──────────┐
   │  Web 1   │     │  Web 2   │     │  Web 3   │
   └──────────┘     └──────────┘     └──────────┘

HAProxy решает задачи:

Балансировка нагрузки — распределение трафика между серверами
High Availability — автоматическое исключение упавших серверов
SSL Termination — расшифровка HTTPS на уровне балансировщика
Маршрутизация — направление запросов на разные backend'ы по условиям
Защита — rate limiting, базовый WAF, DDoS mitigation
Наблюдаемость — метрики, логи, health checks

#Event-Driven архитектура

HAProxy использует event-driven модель — это фундаментальное отличие от многопоточных серверов вроде Apache (prefork).

#Как работает event-driven

Традиционный многопоточный подход:
┌────────┐   ┌────────┐   ┌────────┐   ┌────────┐
│ Поток 1│   │ Поток 2│   │ Поток 3│   │ Поток N│
│  sleep │   │  sleep │   │  work  │   │  sleep │
└────────┘   └────────┘   └────────┘   └────────┘
    ▼            ▼            ▼            ▼
  блокировка  блокировка   работа      блокировка

Event-driven подход HAProxy:
┌────────────────────────────────────────────────┐
│              Один поток                        │
│  ┌────────┐  ┌────────┐  ┌────────┐  ┌──────┐ │
│  │ Сокет A│  │ Сокет B│  │ Сокет C│  │СокетD│ │
│  │  read  │  │ write  │  │  idle  │  │close │ │
│  └────────┘  └────────┘  └────────┘  └──────┘ │
└────────────────────────────────────────────────┘

Принцип работы:

HAProxy регистрирует все сокеты в epoll (Linux) или kqueue (BSD/macOS)
Ядро уведомляет HAProxy о событиях: «сокет X готов к чтению», «сокет Y готов к записи»
HAProxy обрабатывает только готовые сокеты, не тратя CPU на ожидание
Один поток обрабатывает тысячи соединений без блокировок

#Преимущества event-driven

Характеристика	Многопоточный	Event-driven (HAProxy)
Потребление памяти	1-8 МБ на поток	~10 КБ на соединение
Переключение контекста	Частое, дорогое	Минимальное
Масштабирование	Ограничено числом ядер	Десятки тысяч соединений в одном потоке
Latency	Варьируется из-за GC/планировщика	Предсказуемая, низкая

#Архитектурные компоненты HAProxy

┌─────────────────────────────────────────────────────────┐
│                      HAProxy Process                    │
├─────────────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐      │
│  │   Master    │  │   Worker    │  │   Agent     │      │
│  │   Process   │  │  Processes  │  │  (health)   │      │
│  │  (config)   │  │  (traffic)  │  │  checks     │      │
│  └─────────────┘  └─────────────┘  └─────────────┘      │
├─────────────────────────────────────────────────────────┤
│  ┌─────────────────────────────────────────────────┐    │
│  │              Event Loop (epoll)                 │    │
│  │  ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐        │    │
│  │  │Front 1│ │Front 2│ │Back 1 │ │Back 2 │  ...   │    │
│  │  └───────┘ └───────┘ └───────┘ └───────┘        │    │
│  └─────────────────────────────────────────────────┘    │
├─────────────────────────────────────────────────────────┤
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐   │
│  │ Stick Tables │  │   Cache      │  │  Log Buffer  │   │
│  │  (rate limit)│  │  (optional)  │  │   (rsyslog)  │   │
│  └──────────────┘  └──────────────┘  └──────────────┘   │
└─────────────────────────────────────────────────────────┘

#Master Process

Читает конфигурацию
Открывает сокеты (bind)
Запускает worker процессы
Не обрабатывает трафик

#Worker Processes

Обрабатывают весь трафик
Каждый worker имеет свой event loop
Поддерживают zero-downtime reload (мягкая перезагрузка)
Количество workers = числу CPU ядер (обычно)

#Health Check Agent

Отдельный поток для проверок доступности серверов
Не блокирует основной event loop
Параллельные проверки для всех backend серверов

#Режимы работы HAProxy

#HTTP Mode (Layer 7)

defaults
    mode http

frontend http_front
    bind *:80
    # Доступ к HTTP полям: path, headers, cookies
    acl is_api path_beg /api
    use_backend api_servers if is_api

Возможности:

Анализ HTTP заголовков, path, method
Модификация запросов/ответов
Cookie-based сессии
Кэширование HTTP ответов

#TCP Mode (Layer 4)

defaults
    mode tcp

backend db_cluster
    balance leastconn
    server db1 192.168.1.10:3306 check
    server db2 192.168.1.11:3306 check

Применение:

Балансировка баз данных (MySQL, PostgreSQL)
Кастомные бинарные протоколы
SSH, SMTP, Redis, MongoDB
Когда не нужен HTTP анализ

#Производительность HAProxy

Бенчмарки (реальные кейсы):

Компания	Трафик	Конфигурация
GitHub	10+ млрд запросов/день	Кластер HAProxy
Twitter	Миллионы RPS	HAProxy + custom
Instagram	Высоконагруженный API	HAProxy на edge

Факторы производительности:

Ядро Linux — tune параметры (somaxconn, tcp_fin_timeout)
Конфигурация — maxconn, buffer size, timeouts
Аппаратное обеспечение — CPU, NIC с offloading
Сетевая топология — latency до backend'ов

#Сравнение с альтернативами

Характеристика	HAProxy	Nginx	Envoy
Производительность HTTP	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
Производительность TCP	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐
Конфигурация	Файл	Файл + Lua	API + xDS
Динамическое обновление	Dataplane API	Lua, NJS	Native API
Kubernetes native	Ingress	Ingress	Native (data plane)
Learning curve	Средняя	Низкая	Высокая

#Когда выбирать HAProxy

✅ Выбирайте HAProxy если:

Нужна максимальная производительность TCP/HTTP
Критична предсказуемая latency
Требуется простая, но мощная конфигурация
Планируется highload production

❌ Рассмотрите альтернативы если:

Нужен полноценный web сервер (статика) — Nginx
Требуется service mesh с mTLS — Envoy + Istio
Нужна динамическая конфигурация без API — Consul + Envoy

┌─────────────┐ Клиенты ───────►│ HAProxy │ └─────────────┘ │ ┌─────────────────┼─────────────────┐ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Web 1 │ │ Web 2 │ │ Web 3 │ └──────────┘ └──────────┘ └──────────┘

Традиционный многопоточный подход: ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ Поток 1│ │ Поток 2│ │ Поток 3│ │ Поток N│ │ sleep │ │ sleep │ │ work │ │ sleep │ └────────┘ └────────┘ └────────┘ └────────┘ ▼ ▼ ▼ ▼ блокировка блокировка работа блокировка Event-driven подход HAProxy: ┌────────────────────────────────────────────────┐ │ Один поток │ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌──────┐ │ │ │ Сокет A│ │ Сокет B│ │ Сокет C│ │СокетD│ │ │ │ read │ │ write │ │ idle │ │close │ │ │ └────────┘ └────────┘ └────────┘ └──────┘ │ └────────────────────────────────────────────────┘

Характеристика

Многопоточный

Event-driven (HAProxy)

Потребление памяти

1-8 МБ на поток

~10 КБ на соединение

Переключение контекста

Частое, дорогое

Минимальное

Масштабирование

Ограничено числом ядер

Десятки тысяч соединений в одном потоке

Latency

Варьируется из-за GC/планировщика

Предсказуемая, низкая

┌─────────────────────────────────────────────────────────┐ │ HAProxy Process │ ├─────────────────────────────────────────────────────────┤ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Master │ │ Worker │ │ Agent │ │ │ │ Process │ │ Processes │ │ (health) │ │ │ │ (config) │ │ (traffic) │ │ checks │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ ├─────────────────────────────────────────────────────────┤ │ ┌─────────────────────────────────────────────────┐ │ │ │ Event Loop (epoll) │ │ │ │ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ │ │ │ │ │Front 1│ │Front 2│ │Back 1 │ │Back 2 │ ... │ │ │ │ └───────┘ └───────┘ └───────┘ └───────┘ │ │ │ └─────────────────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────┤ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Stick Tables │ │ Cache │ │ Log Buffer │ │ │ │ (rate limit)│ │ (optional) │ │ (rsyslog) │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ └─────────────────────────────────────────────────────────┘

Компания

Трафик

Конфигурация

GitHub

10+ млрд запросов/день

Кластер HAProxy

Twitter

Миллионы RPS

HAProxy + custom

Instagram

Высоконагруженный API

HAProxy на edge

Характеристика

HAProxy

Nginx

Envoy

Производительность HTTP

⭐⭐⭐⭐⭐

⭐⭐⭐⭐

Производительность TCP

⭐⭐⭐⭐⭐

⭐⭐⭐

⭐⭐⭐⭐

Конфигурация

Файл

Файл + Lua

API + xDS

Динамическое обновление

Dataplane API

Lua, NJS

Native API

Kubernetes native

Ingress

Native (data plane)

Learning curve

Средняя

Низкая

Высокая