Группа автоскейлинга остаётся прежнего размера под высокой нагрузкой и не добавляет инстансы — почему?
Час назад трафик утроился, задержка растёт, но группа автоскейлинга (ASG) так и не выросла сверх исходных 4 инстансов. По состоянию ниже определите, почему она не расширяется и что вы бы изменили.
ASG: web-asg min=2 desired=4 max=4
Политика: target tracking по AverageCPUUtilization = 70%
Текущий AverageCPUUtilization: 34% (запросы I/O-bound, ждут БД)
Cooldown: 300s последняя активность скейлинга: 3 дня назад
Инстансы: 4/4 healthyОбъясните корневую причину(ы) и фикс.
Мешают два. Первое: max равен desired на 4, поэтому группа не может добавить инстансы, даже если политика сработает, — поднимите max. Второе: политика следит за CPU 70%, но запросы I/O-bound и CPU на 34%, порог не срабатывает; скейльте по сигналу спроса — числу запросов или очереди. Cooldown активность не маскирует.
- ✗Упустить, что max равен desired, не оставляя запаса для расширения
- ✗Скейлить по CPU на I/O-bound нагрузке, из-за чего порог не срабатывает
- ✗Считать, что desired может превысить max или что CPU — единственная метрика
- →Какую метрику вы бы взяли для флота обработчиков очереди вместо CPU?
- →Как окна cooldown или warm-up мешают скейлингу осциллировать?
Решение
Причина 1 — потолок мощности
min=2 desired=4 max=4 ← desired уже упёрся в maxГруппе физически некуда расти: desired не может превысить max. Даже если политика захочет добавить инстанс, лимит max=4 это запретит. Поднимите max (например, до 12).
Причина 2 — метрика не отражает бутылочное горло
Политика следит за AverageCPUUtilization = 70%, но нагрузка I/O-bound: запросы ждут БД, а CPU держится на 34%. Порог 70% не пересекается — политика молчит. Скейлите по сигналу, отражающему реальный спрос: числу запросов на инстанс, p95-задержке или глубине очереди.
Проверка
last scaling activity: 3 дня назад подтверждает, что cooldown тут ни при чём — он не «съедает» события, событий просто нет. После фиксов max и метрики группа начнёт расширяться под нагрузкой.
