Причина перекосов в уровне балансировки
L4-балансировщик выбирает серверную ноду при создании соединения. Дальше http.Transport может переиспользовать это соединение через keep-alive, из за чего может случиться перекос нагрузки на одну ноду.
Проблема далеко не новая, но я хочу разобрать отдельные решения подробнее. В чем, собственно, проблема:
Для http 1.x свободные соединения в http.Transport переиспользуются по LIFO: логично, что нам выгоднее взять последнее освободившееся. Это видно в реализации
http.Transport.queueForIdleConn и в самой модели http.Transport:
type Transport struct {
///
idleConn map[connectMethodKey][]*persistConn // most recently used at end
///
В отдельных кейсах типо
#79664, LIFO может приводить к перекосу: если одна из нод отвечает немного медленнее остальных, её соединение позже возвращается в idle pool и оказывается последним использованным. Следующий запрос снова забирает его, нода опять отвечает дольше — и так по кругу. В данном кейсе мы минует L4 - ведь новых соединений нет и выбирать ему просто нечего.
Периодическая ротация соединений встряхнет L4 (рис 1)
В вышеописаном issue предлагают добавить новый параметр, который ограничит число запросов на одно соединение (MaxRequestsPerConn), чтобы они периодически закрывались и снова проходили через балансировщик. Например, можно периодически вытеснять активно переиспользуемые соединения через вероятностное включение Request.Close.
Подобную задачу давно решают на инфраструктурном уровне, например, в nginx есть upstream параметры keepalive_requests - которое ограничивает число запросов и keepalive_time типо время жизни соединения. Поэтому часть подобных проблем по 10+ лет не доезжает до http.Transport: их уже умеет решать инфра снаружи.
Балансировка на уровне пулов (рис 2,3)
Можно поступить грубее и держать несколько независимых http.Transport и распределяться между ними. Так устроен
clbtransport: снаружи это обертка, которая внутри ротирует запрос между несколькими пулами. Перед каждым запросом
сравнивается два кандидата: один по round-robin, второй рандомный. Запрос уходит в тот пул, где меньше незавершённых запросов на пул (это кстати Power of Two Choices).
К тому же пулы периодически пересоздаются в фоне с jitter, чтобы минимизировать одновременное закрытие и создание кучи соединений.
Но внутри каждого пула остаётся LIFO, а конкретную ноду по-прежнему выбирает L4 только при создании соединения.
Кастомная балансировка на уровне отдельного RPC - на примере gRPC (рис 4)
В http2 привязка к соединению становится ещё важнее: через одно соединение одновременно может идти множество стримов.
Видимо поэтому в gRPC балансировку вынесли в клиент благодаря отдельным моделям: Resolver, который получает адреса доступных нод (аля service discovery), Picker - модель, которую выбирает подходящее соединение (`SubConn`) для каждого запроса.
Клиент может поддерживать соединения сразу с несколькими нодами напрямую, если перед каждым запросом вызывать Picker, который выбирает подходящий SubConn по заданной стратегии - например round-robin или least-request, который тоже использует Power of Two Choices. Но в отличие от clbtransport, здесь выбор происходит уже между конкретными нодами, а не между пулами с агрегированным счётчиком активных запросов на каждый пул.
Не буду пересказывать то о чем можно почитать в
доке gRPC. И подробнее про
реализацию кастомного grpc балансировщика
На этих примерах хорошо видно, что балансировка зависит в том числе от уровня, где она вызывается.
В http.Transport для http 1.x L4 участвует только при создании соединения. Пока keep-alive соединение переиспользуется, новый выбор ноды не происходит - для этого нужно открыть новое соединение.
В gRPC балансировку встроили прямо в клиентскую модель: он поддерживает соединения с несколькими нодами и выбирает подходящее для каждого запроса. Нравится..
