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

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

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

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

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

Группы экземпляров

Руками поднимать и гасить копии — не вариант. В Compute Engine для этого есть управляемая группа экземпляров (managed instance group, MIG) — вы описываете шаблон одной машины, а группа сама поддерживает нужное число одинаковых копий. Ключевые свойства:

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

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

Cloud Load Balancing

Раз копий несколько, кто-то раздаёт между ними входящие запросы — это Cloud Load Balancing. Его сильная сторона — глобальный HTTP(S)-балансировщик: один внешний адрес принимает пользователей со всего мира и направляет каждого в ближайший регион с работающим сервисом (маршрутизация по путям и хостам, терминация TLS, проверки здоровья). Есть и региональные балансировщики уровня соединений (L4). Балансировщик прячет приложения во внутренней сети и раздаёт им трафик.

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

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

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

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

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

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

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

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

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

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