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

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

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

Дальше нужен явный контур защиты от автоколебаний. Без cooldown и гистерезиса система начинает добавлять и убирать узлы на каждом шуме метрик. Это особенно заметно, если трафик идет неравномерно и балансировщик перераспределяет нагрузку с задержкой. Рекомендуется обратить внимание на метрику не только текущей загрузки, но и ее устойчивости на окне.

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

Практика простая: масштабируйте прокси-слой по симптомам перегруза, а не по одной «удобной» метрике. Тогда система растет не хаотично, а по данным.