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

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

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

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

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

Группы виртуальных машин

Руками поднимать и гасить копии — не вариант. В Yandex Cloud для этого есть группа виртуальных машин (instance group) — вы описываете шаблон одной машины, а группа сама поддерживает нужное число одинаковых копий. У неё три ключевых свойства:

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

Это аналог группы автомасштабирования (Auto Scaling Group) в AWS.

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

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

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

Балансировщик знает о копиях через целевую группу (target group) — список машин, куда слать трафик. Обычно группа виртуальных машин сама регистрирует свои копии в целевой группе: добавилась копия — балансировщик начал слать на неё трафик, убралась — перестал.

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

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

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

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

Копии приложения размножить легко — они одинаковые. С базой данных сложнее: данные должны быть согласованы. Здесь помогает то, что берут управляемые базы: у Managed PostgreSQL можно включить хосты в разных зонах, и при отказе основного облако само переключит нагрузку на реплику. Это снимает самую страшную единую точку отказа — базу — без ручной возни с репликацией.

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

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

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

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

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