Два требования к продакшн-сервису — держать растущую нагрузку и не падать при отказе — в AWS решаются одной связкой: несколько экземпляров за балансировщиком, распределённых по зонам доступности, с автоматическим масштабированием. Понять эту связку — значит уметь спроектировать сервис, который и тянет пики, и переживает сбои.

Вертикальное против горизонтального

Вертикальное масштабирование — взять инстанс мощнее. Просто, но упирается в потолок, требует перезапуска и не добавляет отказоустойчивости (один инстанс — одна точка отказа). Горизонтальное — добавить экземпляров за балансировщиком. Сложнее (нужен stateless-сервис), зато масштабируется дальше, и отказ одного экземпляра не роняет сервис.

AWS-путь — горизонтальное. Условие — сервис должен быть stateless: состояние выносится в базу/кеш, а не хранится в памяти инстанса. Тогда экземпляры взаимозаменяемы, и их число можно менять свободно.

Auto Scaling Groups

Auto Scaling Group (ASG) держит заданное число одинаковых экземпляров и меняет его по нагрузке. Задают минимум/максимум/желаемое и политику масштабирования — чаще всего target tracking: «держи среднюю загрузку CPU около 50%», и ASG сам добавляет/убирает инстансы.

ASG же обеспечивает самовосстановление: упал инстанс (не прошёл health check) — ASG поднимает новый на замену. Так число здоровых экземпляров поддерживается без ручного вмешательства.

Балансировщики: ALB и NLB

Балансировщик распределяет трафик по экземплярам и не шлёт его в нездоровые. Два основных:

  • ALB (Application Load Balancer) — уровень 7 (HTTP/HTTPS): маршрутизация по пути/хосту, терминирование TLS, заголовки. Для веб-сервисов и API — основной выбор.
  • NLB (Network Load Balancer) — уровень 4 (TCP/UDP): очень высокая производительность и низкая задержка, статический IP. Для не-HTTP и предельных нагрузок.

Балансировщик стоит в public-подсетях, сервисы — в private; трафик идёт через балансировщик, а сами инстансы наружу не торчат.

Multi-AZ и health checks

Доступность даёт распределение по зонам. Зона доступности (AZ) — изолированный датацентр; их в регионе несколько. Если экземпляры ASG раскиданы по двум-трём AZ за балансировщиком, отказ целой зоны не роняет сервис — трафик уходит в оставшиеся.

Связывают это health checks: и балансировщик, и ASG регулярно проверяют экземпляры. Не прошёл — балансировщик перестаёт слать трафик, ASG заменяет инстанс. Здесь важна осмысленная проверка готовности (а не просто «порт открыт») — та же readiness-логика, что в Kubernetes.

Где это в UCP

Масштабирование и доступность — это про то, как сервис живёт под нагрузкой и при отказах: stateless-экземпляры в ASG, балансировщик, распределение по зонам, health checks. Это инфраструктурная сторона того же, что resilience-паттерны решают в коде. Для backend-разработчика вывод практический: сервис проектируют stateless и с честными health-проверками — иначе ни горизонтальное масштабирование, ни авто-восстановление не работают. Отказ зоны это покрывает; отказ целого региона и план восстановления — отказоустойчивость и DR. А спайковую/событийную нагрузку иногда лучше отдать serverless.