Автоматизировать масштабирование прокси-слоя без метрик — это просто отложенный инцидент

Автоматизировать масштабирование прокси-слоя без метрик — это просто отложенный инцидент

Слой прокси масштабируют не по «ощущению нагрузки», а по признакам деградации. Базовый набор: CPU, p95/p99 latency, число активных соединений, очередь accept, ошибки upstream и доля ретраев. Если смотреть только на загрузку процессора, можно пропустить ситуацию, когда узел ещё не упёрся в CPU, но уже теряет новые соединения.

Рассмотрим архитектурный срез по данному узлу. Автоскейлинг должен опираться на связку сигналов, а не на один порог:
— рост новых TCP-сессий при стабильном CPU;
— увеличение времени ответа upstream;
— исчерпание лимитов файловых дескрипторов;
— рост SYN backlog или очереди на accept.
Данные подтверждают следующую корреляцию: сначала растёт латентность, затем появляются ретраи, и только после этого срабатывают очевидные алерты.

Полезно разделять горизонтальное и вертикальное масштабирование. Если упираетесь в соединения и контекст-переключения, добавление CPU не решает проблему. Если узкое место в шифровании или буферах, новый узел без тюнинга даст лишь повторение того же профиля отказа. Поэтому перед автоматическим увеличением пула рекомендуется фиксировать базовые лимиты: ulimit, backlog, conntrack, keepalive и timeout-параметры.

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