Группа авто-масштабирования постоянно убивает и пересоздаёт инстансы вскоре после их запуска, не давая приложению стабильно работать. Как диагностировать и исправить такое поведение?

Короткий ответ

Чаще всего причина — health check помечает инстанс как нездоровый раньше, чем приложение успевает полностью стартовать (долгая инициализация, миграции при старте), из-за чего группа считает его сбойным и заменяет новым, который снова не успевает стартовать — возникает цикл.

Как это работает подробнее

у новых инстансов обычно есть «health check grace period» — время, в течение которого группа игнорирует неудачные health check, пока приложение стартует; если это время меньше реального времени старта, инстанс помечается unhealthy и заменяется до того, как успевает подняться.

Пример кода

example.txtКопировать

ASG event log:
10:00:00  Launching new instance i-0a1 (grace period 60s)
10:00:45  Health check failed for i-0a1 (app выполняет миграции БД)
10:01:00  Terminating unhealthy instance i-0a1
10:01:05  Launching new instance i-0b2

Что использовать на практике

• Рекомендация. диагностику начинают с логов запуска приложения и таймлайна событий группы авто-масштабирования, сравнивая время старта приложения с grace period и порогами health check; дальше либо увеличивают grace period, либо ускоряют старт приложения.
• Проверка. после увеличения grace period до реального времени старта (например, 180с) или разделения health check на «готовность к миграциям» и «готовность к трафику» цикл замены должен прекратиться и число инстансов стабилизироваться на desired.

Подводные камни

• Риск. увеличивать grace period «с запасом» до очень большого значения, маскируя реальную проблему вместо её решения
• Риск. использовать для health check эндпоинт, зависящий от медленно прогревающегося кэша/соединения с БД
• Риск. не смотреть одновременно логи приложения и события scaling activity.