Приложение работает на трёх EC2 за ALB, один instance упал. Что произойдёт?

Когда один из трёх EC2-инстансов за Application Load Balancer перестаёт отвечать, цепочка событий определяется настройками health checks, target group и Auto Scaling Group. Разберём пошагово.

Что происходит на уровне ALB

ALB непрерывно опрашивает каждый target по HTTP/HTTPS или TCP на заданном пути. Ключевые параметры target group:

• HealthCheckIntervalSeconds — как часто проверять (по умолчанию 30 с).
• UnhealthyThresholdCount — сколько подряд неудачных проверок переводит target в unhealthy (по умолчанию 2).
• DeregistrationDelay — «draining» период, в течение которого ALB дождётся завершения уже открытых соединений, прежде чем полностью убрать target (по умолчанию 300 с).

Как только target помечен unhealthy, ALB перестаёт направлять на него новые запросы. Трафик перераспределяется на оставшиеся два инстанса по правилу round-robin (или least-outstanding-requests, если настроено).

Что происходит на уровне ASG

Если инстансы управляются Auto Scaling Group с ELB health check (не только EC2 health check), ASG получает сигнал о нездоровом инстансе и запускает замену:

1. ASG завершает (terminate) unhealthy инстанс.
2. Запускает новый инстанс согласно Launch Template/Configuration.
3. Новый инстанс регистрируется в target group и проходит health check.
4. После HealthyThresholdCount успешных проверок инстанс становится healthy, и ALB начинает слать ему трафик.

Практический пример — AWS CLI

# Посмотреть состояние targets в группе
aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-tg/abc123

# Пример вывода после падения одного инстанса:
# {
#   "TargetHealthDescriptions": [
#     { "Target": {"Id": "i-aaa"}, "TargetHealth": {"State": "healthy"} },
#     { "Target": {"Id": "i-bbb"}, "TargetHealth": {"State": "healthy"} },
#     { "Target": {"Id": "i-ccc"}, "TargetHealth": {"State": "unhealthy",
#       "Reason": "Target.FailedHealthChecks"} }
#   ]
# }

# Принудительно пометить инстанс unhealthy в ASG для теста
aws autoscaling set-instance-health \
  --instance-id i-ccc \
  --health-status Unhealthy

# Убедиться, что ASG запустила замену
aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names my-asg \
  --query 'AutoScalingGroups[0].Instances[*].{Id:InstanceId,State:LifecycleState,Health:HealthStatus}'

Временная шкала события

t=0s   инстанс i-ccc упал
t=30s  ALB первая неудачная проверка
t=60s  ALB вторая неудачная проверка → state: unhealthy
t=60s  трафик идёт только на i-aaa и i-bbb
t=65s  ASG получает ELB health check failure → terminate i-ccc
t=90s  ASG запускает i-ddd (новый инстанс)
t=3m   i-ddd проходит 2 health checks → state: healthy
t=3m   ALB включает i-ddd в rotation

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

• ASG использует только EC2 health check — ASG заменит инстанс только при «жёстком» сбое EC2, а не при проблемах с приложением. Обязательно включайте HealthCheckType: ELB в ASG.
• Поверхностный health check path — если /health возвращает 200 даже при отказе БД, ALB не узнает о реальной неисправности. Используйте «deep health check», который проверяет зависимости.
• Недостаточный capacity headroom — при двух оставшихся инстансах нагрузка вырастает на 50%. Если инстансы работали на 70% CPU, после падения одного могут уйти в насыщение. Держите желаемую ёмкость с запасом.
• Stateful сессии на локальном диске — если сессии хранятся in-memory или на диске упавшего инстанса, пользователи потеряют состояние. Выносите сессии в ElastiCache (Redis) или DynamoDB.
• Медленный deregistration delay — 300 секунд по умолчанию могут затянуть время восстановления. Для коротких запросов снизьте до 30–60 секунд.
• Sticky sessions (липкие сессии) — если включён session stickiness, часть пользователей была «прилеплена» к упавшему инстансу. После пометки unhealthy ALB сбросит stickiness и перенаправит их, но первый запрос может вернуть 502.
• Отсутствие ASG warm-up — без DefaultInstanceWarmup ASG может считать новый инстанс ready раньше, чем приложение реально запустилось, и ALB начнёт слать трафик на ещё не готовый сервис.
• Только один AZ — если все три инстанса в одной зоне и эта AZ деградировала, ALB не спасёт. Распределяйте инстансы минимум по двум AZ.

• Ожидать мгновенный failover без health check delay.
• Не использовать ASG для replacement.
• Хранить user sessions только на local instance.

• Описывает ALB target health behavior.
• Учитывает ASG replacement при desired capacity.
• Понимает impact на capacity и state.