Автомасштабирование прокси-слоя ломается не в пик, а на слабых сигналах

Автомасштабирование прокси-слоя ломается не в пик, а на слабых сигналах

Проблема обычно не в самом скейлинге, а в выборе метрики. Если ориентироваться только на CPU, можно пропустить рост очередей, saturation по соединениям или деградацию upstream. Для прокси-слоя полезнее смотреть на совокупность признаков: активные сессии, p95 latency, число retries, backlog в accept-очереди и долю 5xx.

Рассмотрим архитектурный срез по данному узлу. Удобная схема — разделить масштабирование на два контура:
• горизонтальный — добавление инстансов при росте нагрузки;
• защитный — ограничение новых подключений, если downstream уже деградирует.

Анализ показал, что без гистерезиса автоматика начинает «пилить» кластер: подъем на коротком всплеске, затем резкий откат, затем повторный старт. Поэтому нужны задержки на scale-in, окно усреднения метрик и минимальный порог стабильности перед уменьшением пула.

Еще один обязательный элемент — прогрев. Новый прокси должен пройти health-check не только по TCP, но и по реальному запросу через полный маршрут: DNS, TLS, авторизация, upstream. Иначе в баланс попадает узел, который формально жив, но фактически не обслуживает трафик.

Рекомендуется строить автомасштабирование как систему из метрик, ограничителей и проверки готовности. Тогда прокси-слой расширяется по фактической нагрузке, а не по случайному шуму.