Балансировка L4 vs L7: что каждый уровень видит и чего не видит

Команда пилит монолит: /api/* должен идти в новый сервис, всё остальное — в старый. У них уже крутится AWS NLB «ради производительности», поэтому они добавляют правило маршрутизации по пути — и обнаруживают, что такого правила нет. NLB не видит путь. Он форвардит сырой TCP; URL появляется только после парсинга HTTP, а L4-балансировщик HTTP никогда не парсит. Миграция встаёт, пока кто-то не поставит ALB. Урок стоил дня: выбранный уровень решает, какая маршрутизация вообще возможна.

L4 форвардит байты; L7 читает запросы

Балансировщик уровня 4 работает на транспортном уровне. Он видит TCP/UDP-соединение — source IP, destination IP, порты — и форвардит пакеты на бэкенд, ни разу не декодируя содержимое. По сути это быстрый, соединение-знающий NAT. Так как payload он не парсит, он протокол-агностичен (балансирует любой TCP- или UDP-сервис, а не только HTTP) и крайне дёшев на пакет — AWS NLB держит миллионы запросов в секунду с накладными в микросекунды на пакет и выдаёт статические IP.

Балансировщик уровня 7 работает на прикладном уровне. Он терминирует клиентское соединение, читает весь HTTP-запрос — метод, хост, путь, заголовки, cookie — и затем открывает собственное соединение к выбранному бэкенду. Это «терминировать и переоткрыть» — весь источник его мощи и его цены. Раз балансировщик держит распарсенный запрос, он может маршрутизировать на /api/* против /, по заголовку Host:, по cookie или по кастомному заголовку для канареек. Цена: он обязан буферизировать и парсить каждый запрос, а если в игре TLS — расшифровывать и шифровать заново. Реальный CPU на запрос, и он говорит только на тех протоколах, которые понимает (HTTP/1.1, HTTP/2, gRPC).

Решение не в том, «что лучше», а в том, «что мне нужно видеть». Если нужно лишь раскидать сырой TCP по одинаковым бэкендам — L4 быстрее и проще. В момент, когда маршрутизация зависит от чего-то внутри запроса, нужен L7 — и никакой тюнинг L4 не наколдует URL, который тот не декодировал.

Где терминируется TLS — меняет всё

Терминация TLS — самая чистая призма на раздел L4/L7. L7-балансировщик завершает зашифрованную сессию на краю: он держит сертификат, расшифровывает запрос, читает открытый HTTP, принимает решение о маршрутизации и форвардит — либо открытым текстом внутри доверенной сети, либо заново зашифрованным к бэкенду. Именно эта расшифровка и позволяет маршрутизировать по пути или заголовку. Она же централизует управление сертификатами и снимает крипто с серверов приложения.

L4-балансировщик обычно не может терминировать TLS, потому что терминировать — значит расшифровывать, а расшифровывать — значит стать HTTP-aware. Поэтому он делает TLS passthrough: зашифрованные байты идут прямо на бэкенд, который держит сертификат и терминирует. Это держит балансировщик слепым по дизайну — отлично для end-to-end шифрования и для не-HTTP протоколов, бесполезно, если хотелось маршрутизации по пути. Это и есть конкретная причина, почему «просто возьми быстрый» бьёт в обратку: быстрый буквально не может прочитать то, по чему ты хочешь маршрутизировать.

Алгоритмы, health-чеки и вынос мёртвых бэкендов

Оба уровня всё равно должны выбрать бэкенд. Round-robin раскидывает соединения поровну и нормален, когда запросы стоят примерно одинаково. Least-connections отправляет следующий запрос на бэкенд с наименьшим числом активных соединений — куда лучше, когда длительности запросов сильно разнятся, потому что один медленный эндпоинт не будет получать всё больше нагрузки. Хеширование (по IP клиента или consistent hashing) прикрепляет данный ключ к данному бэкенду — так L4-балансировщик имитирует stickiness без cookie.

Health-чеки держат пул честным. Активные чеки опрашивают каждый бэкенд по интервалу (скажем, раз в несколько секунд) и выносят его из ротации после N подряд неудач; пассивные помечают бэкенд мёртвым после того, как он вернул ошибки реальному трафику. Open-source nginx опирается на пассивные чеки; ALB/NLB и nginx Plus делают активный опрос. То, что не доходит до интуиции: упавший бэкенд выносят только после того, как health-чек это заметит — поэтому слишком медленный интервал даёт окно, когда живой трафик продолжает бить в мёртвую коробку и 502 утекают пользователям.

Sticky-сессии и connection draining: два способа сломать деплой

Sticky-сессии (session affinity) прикрепляют клиента к одному бэкенду — через L4 IP-хеш или L7-cookie — чтобы in-memory состояние сессии оставалось на месте. Это работает и тихо вредит: нагрузка перестаёт распределяться ровно (один «кит»-клиент молотит одну коробку), и этот бэкенд нельзя чисто слить, потому что он владеет сессиями, которых нет ни у кого. Рефлекс сеньора — делать бэкенды stateless (сессии в Redis или JWT), чтобы любой бэкенд обслуживал любой запрос; тянуться к stickiness только когда состояние реально нельзя вынести.

Убийца деплоя — отсутствие connection draining. Когда ты убираешь бэкенд во время выката, на нём всё ещё обслуживаются in-flight запросы. Если балансировщик вырывает его мгновенно, эти запросы умирают — пользователи видят сброс на середине оформления заказа. Connection draining (AWS зовёт это deregistration delay) велит балансировщику перестать слать на бэкенд новые соединения, но дать существующим доработать в течение grace-окна. В AWS дефолт — 300 секунд, настраиваемо от 0 до 3600. Поставишь короче самого долгого запроса — всё равно режешь живые запросы; забудешь включить — каждый деплой это маленький простой. Сочетай с health-чеками: слить, подождать, потом гасить.