Автоматизация масштабирования прокси-слоя: какие сигналы нельзя отдавать наугад

Автоматизация масштабирования прокси-слоя: какие сигналы нельзя отдавать наугад

Масштабирование прокси почти всегда ломается не в момент роста, а в момент выбора триггера. Если опираться только на CPU, можно запоздать с расширением пула; если смотреть только на RPS, легко получить лишние узлы и пустую емкость. Анализ показал, что рабочая схема строится на нескольких независимых сигналах:

— очередь соединений и время ожидания на accept;
— p95/p99 задержки на upstream;
— процент ошибок по таймаутам и reset;
— насыщение conntrack, лимитов fd и локальных портов.

Дальше важна не сама метрика, а правило принятия решения. Автоскейлер должен учитывать не одиночный всплеск, а устойчивое отклонение в окне наблюдения. Иначе система будет дергаться на кратком пике, создавая флаппинг: добавили узел, трафик ушел, узел простаивает, потом его снова убрали.

На практике полезно разделять горизонтальное и вертикальное масштабирование. Горизонтальное — когда упираетесь в параллелизм и очереди. Вертикальное — когда узел еще жив, но уже близок к пределу по памяти, fd или таблицам состояний. Рассмотрим архитектурный срез по данному узлу: если есть узкое место в NAT или conntrack, добавление новых экземпляров без перераспределения трафика даст только иллюзию запаса.

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

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