Балансування навантаження з виділеними серверами: архітектура, алгоритми та реальне впровадження

Балансування навантаження — це процес розподілу вхідного мережевого трафіку між кількома серверами, щоб жоден окремий вузол не став вузьким місцем, забезпечуючи стабільну продуктивність, відмовостійкість і горизонтальне масштабування. У середовищі виділених серверів балансувальник навантаження розміщується перед пулом серверів і приймає рішення про маршрутизацію в реальному часі на основі стану сервера, активних з’єднань, затримки відповіді або користувацьких правил політики.

Для будь-якої інфраструктури, що виконує навантаження, чутливі до затримок, — платформи електронної комерції, SaaS-додатки, високонавантажені API або медіастримінг — балансування навантаження не є опціональним. Це архітектурна основа, яка відрізняє ненадійне налаштування з єдиною точкою відмови від виробничої, стійкої системи.

Як насправді працює балансування навантаження: технічний процес

Розуміння балансування навантаження вимагає розуміння повного життєвого циклу запиту, а не лише абстрактної концепції «розподілу трафіку».

Конвеєр маршрутизації запитів

1. DNS-розпізнавання вказує клієнту на IP-адресу балансувальника навантаження (або віртуальний IP у налаштуванні anycast), а не на окремий сервер.
2. Балансувальник навантаження отримує з’єднання на рівні Layer 4 (TCP/UDP) або Layer 7 (HTTP/HTTPS) моделі OSI.
3. Балансувальник оцінює свою таблицю маршрутизації, застосовує налаштований алгоритм і перевіряє поточний стан здоров’я кожного бекенд-вузла.
4. Запит пересилається на вибраний бекенд-сервер. Залежно від режиму (NAT, Direct Server Return або IP-тунелювання), шлях відповіді може повертатися або не повертатися через балансувальник.
5. Демони перевірки стану працюють паралельно, безперервно перевіряючи кожен бекенд через TCP ping, HTTP-коди статусу або користувацькі скрипти. Вузол, що не відповідає, видаляється з пулу протягом секунд.

Балансування навантаження Layer 4 проти Layer 7

Це розрізнення є одним із найважливіших архітектурних рішень, які вам доведеться прийняти.

Для більшості веб-додатків, розміщених на Виділених серверах, Layer 7 є правильним вибором, оскільки він забезпечує інтелектуальну маршрутизацію, SSL-розвантаження та детальні перевірки стану на основі HTTP-кодів відповіді, а не сирого TCP-з’єднання.

Алгоритми балансування навантаження: вибір правильної стратегії

Алгоритм визначає, який бекенд-сервер отримує кожен вхідний запит. Вибір неправильного алгоритму для вашого профілю навантаження є поширеною причиною нерівномірного використання ресурсів.

Round Robin

Запити розподіляються послідовно між усіма справними вузлами. Простий і ефективний, коли всі сервери мають однакові апаратні характеристики, а час обробки запитів приблизно однаковий.

Недолік: Якщо один запит займає 10 секунд, а наступний — 10 мілісекунд, round robin не враховує цю різницю. Повільний бекенд накопичує чергу, тоді як інші простоюють.

Зважений Round Robin

Кожному серверу призначається числова вага. Сервер з вагою 3 отримує втричі більше запитів, ніж сервер з вагою 1. Використовуйте це, коли ваш пул містить різнорідне обладнання — наприклад, поєднання 32-ядерного вузла з 16-ядерним.

Найменша кількість з’єднань

Балансувальник відстежує кількість активних з’єднань з кожним бекендом і направляє нові запити на сервер з найменшою кількістю відкритих з’єднань. Це найбільш підходящий алгоритм за замовчуванням для навантажень зі змінною тривалістю запитів, наприклад, для веб-додатків з базами даних.

Найменший час відповіді

Розширення алгоритму найменшої кількості з’єднань, яке також враховує виміряну затримку бекенду. Перемагає сервер з найнижчою комбінацією активних з’єднань і середнього часу відповіді. Це вимагає від балансувальника підтримки метрик затримки, що додає незначні накладні витрати, але значно покращує якість розподілу при змішаному навантаженні.

IP-хеш (спорідненість за джерелом)

Вихідна IP-адреса клієнта хешується для детермінованого вибору бекенду. Один і той самий клієнт завжди потрапляє на один і той самий сервер, доки склад пулу не змінюється. Це забезпечує примітивну форму збереження сесії без необхідності спільного сховища сесій.

Критичний граничний випадок: Якщо значна частина вашого трафіку надходить з-за корпоративного NAT або шлюзу мобільного оператора, тисячі користувачів можуть мати спільний вихідний IP, що спричиняє серйозний дисбаланс. Завжди перевіряйте розподіл трафіку перед використанням IP-хешу у виробництві.

Випадковий вибір з двох варіантів (степінь двох)

Балансувальник випадково вибирає два сервери-кандидати і направляє запит на той, що має менше активних з’єднань. Цей імовірнісний підхід чудово масштабується у великих пулах (50+ вузлів), оскільки уникає накладних витрат на координацію при глобальному скануванні найменшої кількості з’єднань, водночас уникаючи найгіршого дисбалансу при чисто випадковому виборі.

Збереження сесії: коли без стану неможливо

Багато застарілих додатків зберігають стан сесії локально на сервері (наприклад, PHP $_SESSION записується на диск). У таких випадках направлення користувача, що повертається, на інший бекенд спричиняє втрату сесії, що проявляється як несподіваний вихід із системи або втрата даних кошика покупок.

Балансувальники навантаження вирішують це за допомогою липких сесій, реалізованих через:

• Впровадження cookie: Балансувальник вставляє cookie (наприклад, SERVERID=node2) у HTTP-відповідь. Наступні запити від цього клієнта містять cookie, і балансувальник зчитує його для маршрутизації на той самий вузол.
• Спорідненість за вихідним IP: Як описано вище, менш надійний варіант, але не потребує підтримки cookie від додатку.

Правильне довгострокове рішення — винести зберігання сесій у спільний бекенд — Redis або Memcached — щоб будь-який бекенд-вузол міг обслуговувати будь-якого користувача. Це повністю усуває залежність від липких сесій і робить ваш пул повністю без стану, що значно спрощує масштабування та відновлення після збоїв. Якщо ви створюєте новий додаток, проектуйте бекенди без стану з самого початку.

Перевірки стану: механізм автоматичного перемикання при відмові

Балансувальник навантаження настільки надійний, наскільки надійна його конфігурація перевірок стану. Неправильно налаштовані перевірки стану є причиною значної частини реальних інцидентів з балансувальниками навантаження.

Типи перевірок стану

• TCP-перевірка: Відкриває TCP-з’єднання до порту бекенду. Підтверджує, що процес прослуховує, але не перевіряє коректність на рівні додатку.
• HTTP/HTTPS-перевірка: Надсилає HTTP-запит до визначеного ендпоінту (наприклад, /health) і очікує певного коду статусу (зазвичай 200 OK). Це мінімально прийнятний стандарт для веб-додатків.
• Перевірка користувацьким скриптом: Виконує довільний скрипт, який може запитувати базу даних, перевіряти дисковий простір або перевіряти стан додатку. Повертає 0 для справного стану, ненульове значення — для несправного.

Критичні параметри конфігурації

• interval: Як часто виконується перевірка (наприклад, кожні 5 секунд).
• timeout: Скільки чекати відповіді перед тим, як позначити перевірку як невдалу.
• rise: Кількість послідовних успішних перевірок, необхідних для позначення вузла як справного (запобігає нестабільності).
• fall: Кількість послідовних невдалих перевірок, необхідних для видалення вузла з пулу.

Типова виробнича конфігурація для HAProxy виглядає так:

backend web_servers
    balance leastconn
    option httpchk GET /health HTTP/1.1rnHost: example.com
    http-check expect status 200
    default-server inter 5s fall 3 rise 2 slowstart 60s
    server node1 192.168.1.10:80 check weight 10
    server node2 192.168.1.11:80 check weight 10
    server node3 192.168.1.12:80 check weight 5

Директива slowstart 60s є особливо цінною: вона поступово збільшує трафік до щойно відновленого вузла протягом 60 секунд, а не одразу надсилає повне навантаження, запобігаючи проблемі «грому стада», коли бекенд повертається в мережу після технічного обслуговування.

SSL-термінація та TLS-розвантаження

Обробка TLS-шифрування та дешифрування є обчислювально витратною. У наївному налаштуванні кожен бекенд-сервер виконує цю роботу незалежно. SSL-термінація на балансувальнику навантаження означає, що балансувальник розшифровує вхідний HTTPS-трафік і пересилає звичайний HTTP на бекенди через довірену внутрішню мережу.

Переваги:

• Зменшує навантаження на CPU бекенд-серверів, звільняючи цикли для логіки додатку.
• Централізує управління сертифікатами — оновлюйте один сертифікат на балансувальнику, а не на кожному вузлі.
• Дозволяє інспекцію вмісту запитів на рівні Layer 7 (неможлива при зашифрованій наскрізній передачі).

Міркування безпеки: Трафік між балансувальником навантаження і бекендами передається у незашифрованому вигляді. Це прийнятно, коли всі вузли знаходяться в ізольованій приватній VLAN або виділеній мережі управління. Якщо ваші вимоги відповідності (PCI-DSS, HIPAA) вимагають наскрізного шифрування, використовуйте SSL-перешифрування: балансувальник завершує клієнтську TLS-сесію та встановлює нову TLS-сесію до кожного бекенду. Це підтримує повне шифрування, водночас дозволяючи маршрутизацію на рівні Layer 7.

Поєднання SSL-термінації з належним чином виданими SSL-сертифікатами гарантує, що ваша інфраструктура з балансуванням навантаження відповідає як вимогам продуктивності, так і вимогам відповідності.

Висока доступність самого балансувальника навантаження

Балансувальник навантаження, який сам є єдиною точкою відмови, зводить нанівець мету всієї архітектури. Виробничі розгортання вимагають пари балансувальників навантаження з високою доступністю.

Активно-пасивний режим з VRRP/Keepalived

Два вузли балансувальника навантаження спільно використовують віртуальний IP (VIP). Активний вузол утримує VIP і обробляє весь трафік. Пасивний вузол відстежує активний вузол через heartbeat. Якщо активний вузол виходить з ладу, keepalived ініціює відмовостійке перемикання VRRP, і пасивний вузол отримує VIP протягом 1–3 секунд.

# Install keepalived on both load balancer nodes (Debian/Ubuntu)
apt-get install keepalived

# /etc/keepalived/keepalived.conf on the MASTER node
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass securepassword
    }
    virtual_ipaddress {
        203.0.113.10/24
    }
}

На резервному вузлі встановіть state BACKUP та priority 90. Вузол з вищим пріоритетом виграє вибори VIP.

Активно-активний режим з DNS Round Robin або Anycast

Обидва вузли балансувальника навантаження активно обробляють трафік одночасно. DNS повертає кілька A-записів, розподіляючи клієнтів між обома балансувальниками. Це подвоює пропускну здатність, але вимагає ретельної синхронізації стану при використанні липких сесій.

Для великомасштабних розгортань на Виділених серверах активно-активна конфігурація з BGP anycast-маршрутизацією забезпечує найвищу пропускну здатність і географічну надлишковість.

Пом’якшення DDoS на рівні балансувальника навантаження

Балансувальник навантаження, розміщений на мережевому краю, є природним місцем для реалізації очищення трафіку та обмеження швидкості до того, як шкідливі запити досягнуть ваших серверів додатків.

Обмеження швидкості з’єднань (HAProxy)

frontend http_in
    bind *:80
    bind *:443 ssl crt /etc/haproxy/certs/
    stick-table type ip size 100k expire 30s store conn_rate(3s),http_req_rate(10s)
    tcp-request connection track-sc0 src
    tcp-request connection reject if { sc_conn_rate(0) gt 100 }
    http-request deny if { sc_http_req_rate(0) gt 300 }

Ця конфігурація відстежує швидкість з’єднань за вихідним IP у таблиці stick і відхиляє клієнтів, які перевищують 100 нових TCP-з’єднань за 3 секунди або 300 HTTP-запитів за 10 секунд — порогові значення, які блокують більшість об’ємних атак HTTP-флуду, дозволяючи легітимний пікові трафік.

Захист від SYN-флуду

Увімкніть SYN cookies на рівні ядра на вузлах балансувальника навантаження для обробки атак SYN-флуду без вичерпання таблиці з’єднань:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.ipv4.tcp_synack_retries=2

Зробіть їх постійними, додавши до /etc/sysctl.conf.

NGINX як балансувальник навантаження Layer 7: виробнича конфігурація

NGINX є широко розгорнутим варіантом для HTTP-балансування навантаження, особливо коли потрібна тісна інтеграція з функціями рівня додатку.

upstream backend_pool {
    least_conn;
    keepalive 32;

    server 192.168.1.10:8080 weight=3 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 weight=3 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:8080 weight=1 max_fails=3 fail_timeout=30s;
    server 192.168.1.13:8080 backup;
}

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    location / {
        proxy_pass         http://backend_pool;
        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_502 http_503;
    }
}

Ключові деталі цієї конфігурації:

• keepalive 32 підтримує постійні з’єднання з бекендами, усуваючи накладні витрати на TCP-рукостискання для запитів з високою частотою.
• proxy_next_upstream автоматично повторює невдалі запити на наступному справному бекенді.
• Директива backup призначає node4 як резервний, який отримує трафік лише тоді, коли всі основні вузли недоступні.
• X-Forwarded-For гарантує, що бекенд-додатки бачать реальний IP клієнта, а не IP балансувальника.

Порівняння варіантів програмного забезпечення для балансування навантаження

Для самостійно керованих Виділених серверів HAProxy та NGINX охоплюють переважну більшість виробничих випадків використання. Traefik є прагматичним вибором для навантажень Docker Swarm або Kubernetes завдяки автоматичному виявленню сервісів.

Реальна архітектура: платформа електронної комерції під пікове навантаження

Розглянемо конкретний сценарій: платформа електронної комерції, що очікує 50 000 одночасних користувачів під час рекламної акції.

Схема інфраструктури:

• 2 вузли HAProxy в активно-пасивній конфігурації, що спільно використовують VIP (через Keepalived)
• 6 серверів додатків, що виконують веб-рівень
• 2 виділені сервери баз даних (не в пулі балансувальника навантаження — вони використовують власну реплікацію)
• 1 кластер Redis для спільного зберігання сесій (усуває залежність від липких сесій)
• Спільне NFS або об’єктне сховище для завантажених користувачами ресурсів

Потік трафіку:

1. DNS клієнта розпізнається до VIP, що утримується активним вузлом HAProxy.
2. HAProxy застосовує алгоритм leastconn, розподіляючи запити між 6 серверами додатків.
3. Кожен сервер додатків читає/записує дані сесії з Redis — спорідненість сесій не потрібна.
4. Статичні ресурси обслуговуються безпосередньо з об’єктного сховища через CDN, повністю обходячи балансувальник навантаження та зменшуючи його навантаження на 60–70%.
5. Якщо перевірка стану одного сервера додатків тричі поспіль не проходить, HAProxy видаляє його з пулу протягом 15 секунд. Решта 5 серверів поглинають його трафік.
6. Якщо активний вузол HAProxy виходить з ладу, Keepalived передає VIP пасивному вузлу протягом 2 секунд — прозоро для всіх клієнтів.

Ця архітектура справляється з пікові навантаженням під час акції без того, щоб будь-який окремий компонент став вузьким місцем, і масштабується горизонтально шляхом додавання нових серверів додатків до пулу HAProxy без простою.

Якщо ви запускаєте навантаження GPU-прискореного виведення за балансувальником навантаження — наприклад, розподіляєте запити до сервісу ML-моделей — ті самі принципи застосовуються, але перевірки стану бекенду повинні перевіряти доступність GPU та запас VRAM, а не лише HTTP-доступність. Інфраструктура GPU-хостингу значно виграє від балансування за найменшим часом відповіді через високу варіативність затримки виведення для різних типів запитів.

Моніторинг інфраструктури з балансуванням навантаження

Розгортання балансувальника навантаження без спостережуваності — це робота наосліп. Ось метрики, які мають значення:

• Активні з’єднання на бекенд: Виявляє дисбаланс в алгоритмі розподілу або концентрацію липких сесій.
• Швидкість запитів (RPS) на бекенд: Має бути пропорційною вагам серверів.
• Час відповіді бекенду (p50, p95, p99): Стрибки затримки p99 на одному вузлі вказують на проблему до того, як спрацюють перевірки стану.
• Частота невдалих перевірок стану: Бекенд, що коливається між справним і несправним станом (нестабільність), вказує на базову нестабільність, яку потрібно дослідити.
• Глибина черги з’єднань: Якщо черга балансувальника зростає, ваш пул бекендів недостатній для поточного трафіку.
• Швидкість SSL-рукостискань: Висока швидкість вказує на потенційну атаку виснаження TLS або неправильно налаштований клієнт, що агресивно повторює спроби.

HAProxy надає сторінку статистики (увімкніть за допомогою stats enable у frontend) та Unix-сокет для програмних запитів. Передавайте ці метрики до Prometheus через haproxy_exporter та візуалізуйте в Grafana для повного стеку спостережуваності.

Практичний контрольний список рішень

Використовуйте цю матрицю перед розгортанням або модифікацією архітектури з балансуванням навантаження:

• Додаток зі станом? Перенесіть зберігання сесій до Redis або Memcached перед увімкненням балансування навантаження. Не покладайтеся на липкі сесії як постійне рішення.
• Потрібен TLS? Завершуйте SSL на балансувальнику навантаження. Переконайтеся, що мережа бекенду ізольована. Отримуйте та керуйте сертифікатами централізовано через SSL-сертифікати.
• Змінна тривалість запитів? Використовуйте leastconn, а не round robin.
• Різнорідне обладнання? Застосовуйте значення weight пропорційно до потужності сервера.
• Висока доступність балансувальника навантаження? Розгорніть два вузли балансувальника з Keepalived/VRRP. Ніколи не запускайте єдиний балансувальник навантаження у виробництві.
• Схильність до DDoS? Реалізуйте обмеження швидкості з’єднань та захист SYN cookie на рівні ядра та балансувальника.
• Глибина перевірки стану? Використовуйте HTTP-перевірки до виділеного ендпоінту /health, який перевіряє підключення до бази даних, а не лише доступність TCP-порту.
• План масштабування? Додавання нового бекенд-вузла до пулу HAProxy або NGINX вимагає перезавантаження конфігурації (haproxy -sf $(cat /var/run/haproxy.pid) для перезавантаження без простою) — плануйте процес управління змінами відповідно.
• Моніторинг? Налаштуйте HAProxy або NGINX з експортерами Prometheus до запуску, а не після інциденту.
• Перевага панелі керування? Якщо ви надаєте перевагу управлінню сервером через GUI поряд з ручною конфігурацією балансувальника навантаження, оцініть Панелі керування VPS для адміністративних завдань на окремих вузлах.

FAQ

У чому різниця між балансувальником навантаження та зворотним проксі?

Зворотний проксі пересилає клієнтські запити на один або кілька бекенд-серверів і повертає відповідь клієнту — він обробляє маршрутизацію, кешування та SSL-термінацію. Балансувальник навантаження — це специфічний тип зворотного проксі, основна функція якого полягає в розподілі запитів між кількома бекендами за допомогою визначеного алгоритму. Усі балансувальники навантаження є зворотними проксі, але не всі зворотні проксі виконують балансування навантаження.

Чи може балансування навантаження працювати з одним виділеним сервером?

Технічно так — ви можете запустити балансувальник навантаження перед одним сервером для SSL-термінації, кешування та обмеження швидкості. Однак переваги відмовостійкості та горизонтального масштабування проявляються лише при наявності двох або більше бекенд-вузлів. Налаштування з одним сервером за балансувальником навантаження є допустимою перехідною архітектурою, яка робить майбутнє масштабування операційно тривіальним.

Як балансувальник навантаження обробляє WebSocket-з’єднання?

WebSocket вимагають постійних, довготривалих TCP-з’єднань. Балансувальники навантаження Layer 7 повинні бути явно налаштовані для обробки HTTP Upgrade-рукостискання, а потім підтримувати спорідненість з’єднання протягом усієї WebSocket-сесії. У NGINX встановіть proxy_http_version 1.1 та proxy_set_header Upgrade $http_upgrade зі значенням proxy_set_header Connection "upgrade". У HAProxy використовуйте option http-server-close та налаштуйте відповідні значення тайм-ауту (timeout tunnel 1h для довготривалих з’єднань).

Що відбувається з запитами в процесі виконання, коли бекенд-сервер виходить з ладу?

З proxy_next_upstream у NGINX або retries у HAProxy балансувальник виявляє помилку з’єднання або тайм-аут при першій спробі та негайно повторює запит на наступному справному бекенді. Це повторення прозоре для клієнта. Ідемпотентні запити (GET, HEAD) безпечно повторювати автоматично. Неідемпотентні запити (POST, PUT) слід повторювати з обережністю — налаштуйте proxy_next_upstream для виключення http_500 для POST-маршрутів, щоб уникнути подвійної обробки платежу або відправки форми.

Скільки бекенд-серверів потрібно, щоб балансування навантаження давало відчутну користь?

Два сервери забезпечують негайну можливість відмовостійкого перемикання та приблизно подвоюють потужність. Три або більше серверів забезпечують значущий статистичний розподіл і дозволяють поетапне технічне обслуговування (вивести один вузол з мережі для оновлень, поки інші поглинають трафік). Для виробничих навантажень три вузли є практичним мінімумом для стійкого пулу — два вузли означають, що одна відмова знижує вашу потужність на 50%, що може порушити ваш SLA продуктивності під пікове навантаження.