Балансировка нагрузки (L4 и L7)

Зачем больше одного сервера

Один сервер упирается в потолок: не тянет нагрузку или падает целиком, и сайт лежит. Решение: поставить несколько одинаковых копий приложения и раскидывать запросы между ними. Распределением занимается балансировщик нагрузки (load balancer).

Это даёт сразу две вещи. Масштабирование: больше копий, больше суммарной нагрузки держим. Отказоустойчивость: одна копия упала, балансировщик перестаёт слать на неё трафик, остальные продолжают работать.

Алгоритмы распределения

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

• Round-robin — по очереди, каждому следующему серверу свой запрос. Простой дефолт.
• Least connections — тому, у кого сейчас меньше всего активных соединений. Лучше, когда запросы разной длины.
• IP hash — клиент по своему IP всегда попадает на один и тот же сервер. Нужно, когда сервер держит локальную сессию клиента.

Без IP hash клиент при каждом запросе может попадать на разные копии. Поэтому копии делают stateless: сессии и данные держат в общем месте (база, Redis), а не в памяти конкретного сервера. Тогда любой запрос обслужит любая копия.

Health-checks

Балансировщик должен знать, какие копии живы. Для этого он периодически дёргает каждую — это health-check:

upstream app {
    server 10.0.5.10:8080;
    server 10.0.5.11:8080;
}
# nginx сам перестаёт слать на сервер, который вернул ошибку/таймаут

Приложение обычно отдаёт отдельный лёгкий эндпоинт /healthz, который быстро отвечает 200 OK, если всё в порядке. Сервер, который перестал отвечать или вернул ошибку, выводится из ротации, пока не починится.

L4 и L7

Балансировать можно на разных уровнях (как и проксировать).

L4-балансировщик работает на уровне TCP/UDP. Он смотрит только на IP и порты, содержимое запроса не разбирает. Быстрый, не умеет роутить по URL или домену. Пример: облачный Network Load Balancer.

L7-балансировщик работает на уровне HTTP. Он видит URL, заголовки, cookie и может раскидывать умно: /api/ на одни серверы, /static/ на другие; клиента по cookie держать на одной копии. nginx, HAProxy и облачные Application Load Balancer — это L7.

Правило простое. Если надо только раскидать TCP-соединения, хватит L4. Как только нужно решать по содержимому HTTP, берут L7.

Что важно запомнить

Балансировщик раскидывает запросы по нескольким копиям приложения, давая масштаб и отказоустойчивость. Копии делают stateless, сессии выносят в общее хранилище.

Health-check выводит мёртвую копию из ротации; приложение отдаёт лёгкий /healthz.

L4 балансирует по TCP/портам и быстр, L7 видит HTTP и роутит по URL/заголовкам. Выбор зависит от того, нужно ли решать по содержимому.

В следующих треках это соединяется с Kubernetes: Service и Ingress — это и есть встроенная балансировка кластера.