Балансировка нагрузки в облаке: NLB, ALB и L7-прокси - как выбрать

Представьте ситуацию: ваш интернет-магазин внезапно накрывает волна трафика из-за удачной рекламной кампании. Серверы начинают задыхаться, время ответа растет до бесконечности, а пользователи просто закрывают вкладку, не дождавшись загрузки страницы. Знакомая боль? Чтобы такого не происходило, нужен балансировщик нагрузки - устройство или программное решение, которое распределяет входящий сетевой трафик между несколькими серверами для повышения доступности и отказоустойчивости системы. Но какой именно выбрать? В облачных средах AWS (и аналогах вроде Yandex Cloud или VK Cloud) чаще всего спорят о двух типах балансировщиков: Network Load Balancer (NLB) и Application Load Balancer (ALB), плюс классические L7-прокси.

Разобраться в этой путанице важно не только для экономии денег, но и для того, чтобы ваша архитектура не рассыпалась при первом же серьезном нагрузочном тесте. Давайте разберем по полочкам, чем они отличаются друг от друга, где у каждого свои сильные стороны и когда лучше вообще отказаться от «умных» балансировщиков в пользу простых решений.

Зачем вообще нужен балансировщик нагрузки?

Если у вас один сервер, балансировщик не нужен. Но как только вы добавляете второй инстанс для надежности или масштабирования, возникает вопрос: куда отправлять пользователя? Если направить всех на первый сервер, он упадет первым, а второй будет простаивать. Балансировщик решает эту задачу, выступая единой точкой входа для клиентов.

Основные задачи, которые он выполняет:

• Распределение нагрузки: равномерная раздача запросов между здоровыми серверами.
• Health Checks (проверка состояния): автоматическое исключение упавших серверов из пула.
• SSL/TLS разгрузка: расшифровка HTTPS-трафика на уровне балансировщика, чтобы облегчить жизнь бэкенду.
• Маршрутизация: направление разных типов трафика (например, API и статика) на разные группы серверов.

Ключевое различие между типами балансировщиков лежит в модели OSI. NLB работает на 4-м уровне (Transport Layer), оперируя IP-адресами и портами TCP/UDP. ALB и L7-прокси работают на 7-м уровне (Application Layer), понимая HTTP/HTTPS протоколы, куки, пути URL и заголовки.

NLB: Скорость и прозрачность на 4-м уровне

Network Load Balancer (NLB) - это балансировщик уровня 4, который обеспечивает сверхнизкую задержку и высокую производительность, работая с пакетами TCP и UDP без их глубокого анализа. Представьте его как скоростную магистраль: ему все равно, что именно едет внутри машины (данные), главное - быстро доставить груз из точки А в точку Б.

Почему выбирают NLB?

1. Производительность: NLB обрабатывает миллионы запросов в секунду. Он не парсит HTTP-заголовки, поэтому CPU тратится минимально.
2. Сохранение исходного IP клиента: это критически важно для многих приложений. NLB сохраняет реальный IP-адрес посетителя, передавая его на бэкенд. Для сравнения, стандартный ALB может подменять IP на свой, если специально не настроить заголовок X-Forwarded-For.
3. Поддержка нетипичных протоколов: если у вас игра на базе UDP, gRPC или кастомный бинарный протокол, NLB справится с этим отлично. HTTP-ориентированные балансировщики могут споткнуться о нестандартные пакеты.
4. Статический IP: NLB позволяет назначить фиксированный публичный IP-адрес, что удобно для настройки фаерволов на стороне клиента или интеграции с legacy-системами.

Однако у NLB есть ограничения. Он не умеет делать маршрутизацию на основе пути URL (path-based routing). Вы не сможете сказать ему: «Все запросы к /api отправь на группу серверов A, а картинки из /images - на группу B». Для него весь трафик одинаков, пока он идет на один порт.

ALB: Интеллектуальная маршрутизация на 7-м уровне

Application Load Balancer (ALB) - это балансировщик уровня 7, предназначенный для работы с HTTP и HTTPS трафиком, поддерживающий продвинутые функции маршрутизации и SSL-терминацию. Это мозг вашей сети. Он читает HTTP-запросы, понимает методы GET/POST, анализирует заголовки User-Agent и куки.

Когда ALB незаменим?

• Микросервисная архитектура: вам нужно разделить трафик между десятками микросервисов. Например, сервис оплаты живет на одном пуле серверов, а каталог товаров - на другом. ALB легко настроит правила: путь /payments -> Target Group Payments, путь /catalog -> Target Group Catalog.
• A/B тестирование: можно направлять 10% трафика на новую версию приложения, основываясь на куках или весах, не меняя код приложения.
• HTTP/2 и WebSocket: ALB нативно поддерживает современные веб-протоколы, обеспечивая стабильные долгие соединения.
• Управление сертификатами: интеграция с ACM (AWS Certificate Manager) или аналогами позволяет автоматически обновлять SSL-сертификаты без даунтайма.

Но за интеллект приходится платить ресурсами. ALB потребляет больше CPU и памяти на балансировщике, так как должен распарсить каждый пакет. Также он обычно имеет более высокую стоимость за единицу обработки трафика по сравнению с NLB.

L7-прокси: Гибкость и контроль

Иногда облачные managed-сервисы (NLB/ALB) оказываются слишком дорогими или недостаточно гибкими. Тогда на помощь приходят L7-прокси - программные решения, такие как Nginx, HAProxy или Envoy, развернутые на виртуальных машинах, которые выполняют функции балансировщика и обратного прокси-сервера.

В чем преимущество самописного L7-прокси перед облачным ALB?

Например, если вам нужна сложная логика ретраев (повторных попыток) с экспоненциальной задержкой или специфическое кеширование статики прямо на граничном узле, Nginx справится с этим дешевле и точнее, чем попытки выкрутить настройки ALB.

Однако помните: развернув свой прокси, вы берете на себя ответственность за его отказоустойчивость. Если ваш единственный Nginx-сервер упадет, вся инфраструктура станет недоступной. Поэтому L7-прокси тоже нужно балансировать! Обычно ставят два инстанса Nginx за обычным сетевым балансировщиком (L3/L4) или используют Anycast IP.

Как выбрать: чек-лист для архитектора

Выбор между NLB, ALB и L7-прокси зависит от трех факторов: протокола, бюджета и требований к управлению трафиком. Вот простая схема принятия решений:

1. Какой протокол использует ваше приложение?
   • TCP/UDP (игры, базы данных, VoIP) → Только NLB.
   • HTTP/HTTPS → Переходите к шагу 2.
2. Нужна ли вам маршрутизация по URL или заголовкам?
   • Да, нужно разделять трафик на разные бэкенды → ALB.
   • Нет, весь трафик идет на один пул серверов → Можно рассмотреть NLB (если важна скорость/IP) или L7-прокси (если нужна дешевизна).
3. Каков объем трафика?
   • Миллионы запросов в месяц → Облачные балансировщики могут стать неподъемно дорогими. Рассмотрите выделенные L7-прокси на мощных bare-metal серверах.
   • Небольшой или средний трафик → Используйте ALB, чтобы сэкономить время инженеров на настройке и поддержке.

Частая ошибка новичков - ставить ALB перед всем скопом микросервисов, даже если у них нет необходимости в сложной маршрутизации. Это переплата за неиспользуемые функции. И наоборот, использование NLB для веб-сайта часто приводит к головной боли с пробросом реального IP-адреса клиента через заголовки PROXY protocol, что требует доработки кода приложения или веб-сервера.

Практические советы по внедрению

Даже правильный выбор типа балансировщика не гарантирует успеха, если неправильно настроены health checks. По умолчанию многие балансировщики проверяют доступность порта (TCP check). Но сервер может слушать порт, а приложение внутри него уже упало. Всегда настраивайте HTTP health check на конкретный endpoint, например /healthz, который возвращает статус 200 OK только тогда, когда приложение полностью готово принимать нагрузку.

Еще один нюанс - таймауты. У NLB и ALB разные дефолтные значения idle timeout. Если ваше приложение держит долгие соединения (long polling, WebSocket), убедитесь, что таймаут балансировщика больше, чем таймаут вашего приложения. Иначе балансировщик будет разрывать соединение раньше, чем это сделает сервер, вызывая ошибки 504 Gateway Timeout.

И не забывайте про зоны доступности (Availability Zones). Разворачивайте целевые группы серверов минимум в двух AZ. Сам балансировщик в облаке обычно высокодоступен по умолчанию, но если все ваши бэкенды лежат в одной зоне, а эта зона выйдет из строя, балансировщик останется живым, но раздавать трафик будет некому.