Как балансировать нагрузку между репликами сервера
Что проверяют
Для ML-специальности вопрос обычно про сервинг: несколько реплик инференс-сервиса и запросы очень разной стоимости. Интервьюер хочет понять, отличаете ли вы балансировку соединений от балансировки запросов и учитываете ли специфику моделей: долгую загрузку весов, GPU, батчинг. Следом часто спрашивают про gRPC в Kubernetes или про LLM с длинными ответами.
Как отвечать
Начните с уровней:
- L4 (TCP): распределяются соединения. Kubernetes Service через kube-proxy выбирает под для нового соединения, и все запросы по нему идут туда же;
- L7 (HTTP, gRPC): распределяются отдельные запросы. Это Envoy, NGINX, HAProxy, Ingress или сервис-меш вроде Istio и Linkerd.
Затем алгоритмы:
- round robin, weighted round robin: хороши при одинаковых запросах и одинаковых репликах;
- least connections, least outstanding requests: лучше для инференса, где один запрос занимает 20 мс, а другой несколько секунд;
- power of two choices: из двух случайных реплик берётся менее загруженная. Почти как least requests, но без глобального состояния;
- consistent hashing: когда важна локальность, например кэш признаков или префиксный KV-кэш у LLM. Для LLM есть и специальный роутинг вроде Gateway API Inference Extension, который смотрит на очередь и кэш реплик.
Обязательно скажите про health checks: readiness-проба проходит, только когда модель загружена и прогрета, иначе первые запросы попадают на пустую реплику. Масштабируйте по метрике нагрузки инференса (длина очереди, латентность, загрузка GPU) через HPA или KEDA, а не только по CPU.
Где спотыкаются
Не знают про gRPC: HTTP/2 держит одно долгое соединение, и обычный Service отправляет весь трафик клиента в один под. Нужен L7-балансировщик или клиентская балансировка.
Предлагают round robin для запросов с сильно разной стоимостью. Одна реплика копит очередь из тяжёлых запросов, хотя по счётчику всё поровну.
Забывают, что балансировщик сам может стать точкой отказа, а sticky sessions после добавления реплик оставляют новые почти без трафика.