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

Вертикальное и горизонтальное масштабирование

Есть два способа дать сервису больше мощности.

  • Вертикальное — взять машину помощнее. Просто, но упирается в потолок самой большой машины, требует перезапуска, и одна машина всегда единая точка отказа.
  • Горизонтальное — поднять несколько одинаковых копий и раздать нагрузку между ними. Сложнее, но так строят и масштаб, и надёжность: одна копия упала — остальные держат.

Общее правило облака: масштабируются горизонтально, а сервис делают stateless — без состояния в памяти конкретной копии. Сессии, корзины, промежуточные данные выносят во внешнее хранилище (базу или кэш), чтобы любой запрос обслужила любая копия.

Масштабируемые наборы виртуальных машин

Руками поднимать и гасить копии — не вариант. В Azure для этого есть Virtual Machine Scale Sets (VMSS) — вы описываете шаблон одной машины, а набор сам поддерживает нужное число одинаковых копий. Ключевые свойства:

  • Автомасштабирование — набор добавляет копии при росте нагрузки (например, по загрузке процессора) и убирает лишние при спаде;
  • Автовосстановление — копия, не прошедшая проверку здоровья, пересоздаётся;
  • Распределение по зонам — копии раскидывают по нескольким зонам доступности; выпадет зона — сервис продолжит работать на оставшихся.

Аналог группы автомасштабирования (Auto Scaling Group) в AWS. Для контейнерных нагрузок ту же роль играют AKS и Container Apps с их автомасштабированием.

Балансировщик нагрузки

Раз копий несколько, кто-то раздаёт между ними входящие запросы. В Azure два варианта (подробнее — в статье про сеть):

  • Load Balancer — на уровне соединений (L4), быстрый и простой;
  • Application Gateway — на уровне HTTP (L7): маршрутизация по путям и хостам, терминация TLS, проверки здоровья. Обычно он и стоит публичной точкой входа, а приложения прячутся во внутренней сети.

Проверки здоровья

Балансировщик не должен слать запросы в мёртвую копию. За это отвечает проверка здоровья (health probe) — балансировщик периодически стучится по адресу вроде GET /health и считает копию живой, только если та отвечает 200. Не отвечает — трафик не идёт, а набор её пересоздаёт.

Практический совет: делайте /health честным. Если он отвечает 200 всегда, даже когда база недоступна, балансировщик будет слать трафик в заведомо сломанную копию. Хорошая проверка отражает, готов ли сервис реально обслуживать запросы.

Доступность данных

Копии приложения размножить легко — они одинаковые. С базой сложнее: данные должны быть согласованы. Здесь помогают управляемые базы: у Azure Database for PostgreSQL можно включить зоно-избыточную высокую доступность (zone-redundant HA) — резервный сервер в другой зоне и автопереключение при отказе. Это снимает самую страшную единую точку отказа — базу — без ручной возни.

Где это применяется

Собранная схема высокой доступности: балансировщик как публичная точка входа, за ним — масштабируемый набор копий в нескольких зонах, автомасштабирование под нагрузку, автовосстановление упавших копий, а данные — в управляемой базе с резервом в другой зоне. Типовой каркас боевого развёртывания.

Типичные ошибки новичков:

  • держат состояние в памяти копии — теряют при масштабировании и пересоздании;
  • всё в одной зоне — авария зоны уносит весь сервис;
  • фиктивный /health, который всегда 200 — трафик идёт в сломанные копии;
  • забывают про базу — приложение продублировано, а база в одном экземпляре осталась точкой отказа.

Что учить дальше: как пережить отказ целого региона и что такое RPO/RTO — в отказоустойчивости и аварийном восстановлении; событийная модель, масштабирующаяся сама, — в serverless. Та же механика в AWS — масштабирование и доступность в AWS.