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

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

Масштабирование прокси обычно пытаются строить вокруг CPU и числа соединений. Анализ показал, что этого мало: узел может быть «спокойным» по загрузке, но уже упираться в лимит файловых дескрипторов, очереди accept или задержки на upstream.

Рабочая схема начинается с набора метрик, которые реально отражают деградацию:
— p95/p99 latency на входе и на upstream;
— error-rate по таймаутам и reset;
— occupancy очередей и backlog;
— число активных сессий на процесс и на ядро;
— состояние health-check, а не только его успех/неуспех.

Затем нужен не один триггер, а комбинация правил. Добавлять экземпляры стоит при устойчивом росте латентности и соединений, а удалять — только после окна стабилизации. Иначе автоматика будет «пилить» кластер при кратких всплесках, создавая лишнюю турбулентность в сети.

Рассмотрим архитектурный срез по данному узлу: контрольная плоскость должна быть отделена от data-plane, а конфигурация — воспроизводима из шаблона. Тогда новый прокси поднимается с тем же набором ACL, лимитов и таймаутов, без ручной донастройки в аварийном режиме.

Вывод простой: автоматизация масштабирования работает только там, где сигнал качества опережает сигнал перегрузки. Если метрики выбраны правильно, прокси-слой растет предсказуемо и не превращается в источник самоподдерживающихся инцидентов.