Сети и протоколы
Proxy и load balancing: тест с выбором ответа
Суть Синтез по всему юниту proxy и load balancing в формате выбора — компромиссы алгоритмов, L4 против L7, обнаружение здоровья, анти-паттерн sticky session, retry storm и отказоустойчивая топология.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, проходящих через весь юнит. Каждый отражает решение, которое вы принимаете на реальной платформе — не определение для пересказа, а компромисс между скоростью, справедливостью и состоянием под нагрузкой.
Цель
Убедитесь, что можете связать выбор алгоритма, L4 против L7, обнаружение здоровья, стратегию сессий и контроль каскада — тот синтез, к которому вели отдельные уроки.
Викторина
Completed
Пул из 50 backends обслуживает запросы с резко разной стоимостью (вызовы API на 1 мс вперемешку с загрузками на 200 мс). Какой алгоритм балансировки — правильный default и почему?
Heads-up Round-robin распределяет КОЛИЧЕСТВО запросов равномерно, но не нагрузку. Загрузка на 200 мс и вызов на 1 мс занимают по одному ходу, поэтому backend с загрузками отстаёт несмотря на свою справедливую долю.
Heads-up Least-connections адаптируется к нагрузке, но устраивает стадо: когда счётчик восстановившегося backend падает, все клиенты видят один минимум одновременно и сбегаются на него. Плюс ему нужен O(log N) скан на запрос.
Heads-up IP-hash — это инструмент session affinity, а не балансировки. Он плохо кластеризуется за NAT и полностью игнорирует реальную нагрузку.
Викторина
Completed
Нужно направлять /api/payments/ в PCI-совместимый пул, а /api/catalog/ — в общий, делать retry на HTTP 5xx и собирать метрики по эндпоинтам. Какой слой нужен и сколько это стоит?
Heads-up L4 видит только 4-кортеж IP:port. Он не может прочитать path URL или отличить /payments/ от /catalog/ и не понимает HTTP 5xx, чтобы делать retry.
Heads-up L4 никогда не парсит HTTP-заголовки; это делает только L7. Content routing и retry на 5xx — возможности исключительно L7.
Heads-up DNS резолвит hostname, а не path URL. Маршрутизация по path требует L7-прокси, который парсит строку запроса.
Викторина
Completed
У backend заполнился диск; он по-прежнему принимает TCP-соединения, но возвращает 500 на каждый HTTP-запрос. Ваш активный health check — это TCP SYN-проба, и она сообщает, что backend здоров. Какое исправление правильное?
Heads-up Более частая TCP SYN-проба всё равно проверяет лишь то, что TCP соединяется. Процесс ПРИНИМАЕТ соединения, поэтому проба сообщает «здоров» как бы часто вы ни пробовали.
Heads-up Маршрутизация по наименьшей загрузке снижает трафик на медленный узел, но никогда не удаляет узел, отдающий мгновенные 500: его соединения закрываются быстро, поэтому он выглядит простаивающим и притягивает БОЛЬШЕ трафика.
Heads-up Заглушка, всегда возвращающая 200, — это опасная противоположность исправлению: она маскирует сломанное приложение и продолжает направлять трафик в шторм 500-ок.
Викторина
Completed
Команда включает sticky session, чтобы пользователи не разлогинивались, когда запросы попадают на разные backends. После деплоя дисбаланс нагрузки ухудшается, а упавший узел разлогинивает тысячи пользователей. Как это читать?
Heads-up Более длинный TTL cookie закрепляет клиентов ещё сильнее, ухудшая дисбаланс и делая потерю сессии при краше более вероятной, а не менее. Само закрепление и есть проблема.
Heads-up IP-hash — это всё та же affinity: она сохраняет SPOF и добавляет кластеризацию за NAT и поломку при смене IP. Смена разновидности affinity не убирает дефект stateful-backend дизайна.
Heads-up Дисбаланс и массовый разлогин — прямые следствия закрепления. Sticky session снижают отказоустойчивость, создавая единую точку отказа на уровне сессии.
Викторина
Completed
У backend пауза GC на 500 мс. Клиенты и три промежуточных слоя сервисов делают по одному retry при таймауте. Блип на 500 мс превращается в отказ всего кластера. Каков минимальный набор мер?
Heads-up Больше retry ещё сильнее усиливают перегрузку — по K слоям retry компаундируются к нагрузке 2^K×. Агрессивнее ретраить в тонущий backend — это именно то, что вызывает шторм.
Heads-up Ёмкость отсрочивает коллапс, но усиление retry масштабируется вместе с нагрузкой; новые узлы втягиваются в тот же шторм. Нужно ограничивать retry, а не просто добавлять ёмкость.
Heads-up Убрав jitter, вы синхронизируете каждого затаймаутившего клиента на retry в один момент — thundering herd. Jitter существует именно для размазывания всплеска.
Викторина
Completed
Ваш единственный L7 load balancer сам является единой точкой отказа: когда он падает, весь трафик пропадает. Какая топология убирает SPOF и какое ограничение она накладывает?
Heads-up Переключение active-passive занимает 10–30 с на обнаружение и продвижение резерва, достаточно долго, чтобы пользователи заметили. Anycast + ECMP сходятся меньше чем за секунду на активном кластере.
Heads-up TTL DNS в 60–300 с означают, что клиенты продолжают бить в мёртвый LB, пока кэш не истечёт; у DNS нет осведомлённости о здоровье на уровне запроса. DNS делает гео-маршрутизацию, а не переключение LB.
Heads-up Вертикальное масштабирование не убирает единую точку отказа — машина, NIC, стойка или питание всё равно могут отказать. Резервирование на уровне нескольких машин — единственное исправление.
Итог
Сквозная линия юнита — один треугольник компромиссов: скорость, справедливость и состояние, разрешаемый на каждом слое. Power-of-two-choices — справедливый O(1)-default; L7 покупает content routing и retry на 5xx ценой латентности в 100× выше L4; активные плюс пассивные health check покрывают и краши, и тихие 5xx; sticky session — обход stateful-backend, который заменяется Redis; retry budget, circuit breaker и jitter ограничивают каскад; а anycast + BGP ECMP убирают собственную единую точку отказа LB ценой statelessness.