Multi-region: зачем разворачивать сервис в нескольких регионах

Прямой ответ

Развёртывание в нескольких регионах (multi-region) оправдано тремя причинами: снижение задержки для географически распределённых пользователей, устойчивость к потере региона и выполнение требований о хранении данных в определённой юрисдикции. Все три требуют затрат, и без одной из причин решение не окупается.

Три схемы отличаются степенью активности регионов:

Один регион с резервной копией — рабочая нагрузка в одном регионе, в другом хранятся копии и инфраструктура как код. При инциденте развёртывание выполняется заново; о процедуре — в статье про disaster recovery.

Active-passive — второй регион содержит работающую инфраструктуру без трафика. Переключение сводится к изменению маршрутизации, поэтому время восстановления измеряется минутами.

Active-active — оба региона обслуживают трафик одновременно. Это даёт устойчивость и низкую задержку, но требует решения конфликтов записи; о схемах — в статье про active-active против active-passive.

Задержка между регионами — физическое ограничение. Между Франкфуртом и Вирджинией время кругового пути составляет около 90 миллисекунд, и оно присутствует в каждом синхронном обращении между регионами. Отсюда правило: данные, участвующие в одной транзакции, должны находиться в одном регионе.

Стоимость складывается из трёх частей: дублирование вычислительных ресурсов, передача данных между регионами (обычно тарифицируется) и сложность сопровождения. Третья часть обычно недооценивается: каждая процедура развёртывания, мониторинга и восстановления существует в двух экземплярах.

Требование резидентности данных — единственная причина, которую нельзя обойти архитектурой. Если закон требует хранения персональных данных в стране пользователя, данные физически размещаются в соответствующем регионе, а не реплицируются глобально.

Стоимость и эксплуатация двух регионов

Расходы на несколько регионов складываются из четырёх частей, и только одна из них очевидна при планировании.

Вычислительные ресурсы. Дублирование инфраструктуры удваивает стоимость серверов, баз данных и управляемых сервисов. При active-passive резерв может быть меньше по мощности, но он не может быть нулевым.

Передача данных между регионами. Исходящий трафик между регионами обычно тарифицируется отдельно от входящего. Постоянная репликация больших объёмов может стоить дороже вычислительных ресурсов, поэтому объём реплицируемых данных требует контроля.

Сложность сопровождения. Каждая процедура существует в двух экземплярах: развёртывание, миграция, резервное копирование, мониторинг, оповещение. Эту стоимость сложно оценить заранее, поскольку она проявляется постепенно — в виде времени на каждую операцию.

Проверка готовности. Учебные переключения требуют отдельного стенда и времени команды. Без них готовность резерва остаётся предположением.

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

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

Практика: переход к нескольким регионам

1. Начните с причины. Снижение задержки, устойчивость или резидентность — разные задачи с разными решениями. Развёртывание «для надёжности» без целевых метрик не окупается.

2. Измерьте задержку до решения. Если 90 процентов пользователей находятся в одном регионе, второй регион снижает задержку для меньшинства при двойной стоимости.

3. Разместите данные рядом с пользователями. Пользователь обслуживается в ближайшем регионе, его данные хранятся там же; о компромиссах — в статье про CAP-теорему.

4. Избегайте синхронных обращений между регионами. Запрос, который в рамках обработки обращается в другой регион, добавляет задержку кругового пути к каждому обращению.

5. Используйте инфраструктуру как код. Развёртывание второго региона вручную приводит к расхождению конфигураций, которое обнаруживается в момент переключения.

6. Проверяйте переключение. План восстановления, который не проверялся, содержит ошибки; о проверке — в статье про disaster recovery.

7. Разделите данные по классам. Персональные данные — в регионе пользователя, общие справочники — реплицируются везде, аналитика — собирается в одном месте.

Рекомендации:

1. Не начинайте с active-active. Схема требует решения конфликтов записи и стоит существенно дороже, чем active-passive при сопоставимом RTO.
2. Учитывайте стоимость передачи данных. Постоянная репликация между регионами может стоить дороже вычислительных ресурсов.
3. Дублируйте процедуры, а не только инфраструктуру. Мониторинг, оповещение и документация для второго региона требуют отдельной работы.
4. Проверяйте требования резидентности юридически. Размещение данных в регионе — юридическое требование, а не техническая оптимизация.
5. Планируйте деградацию. При потере одного региона сервис должен работать, возможно с ограничениями; о деградации — в статье про грациозную деградацию.

Практический сценарий: второй регион для соответствия требованию резидентности данных

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

1. Диагностика. Анализ показал, что персональные данные содержатся в 14 таблицах, а аналитические копии реплицируются в общий склад без ограничений по территории.
2. Причина. Архитектура проектировалась под один регион, поэтому разделение данных по классам отсутствовало: всё реплицировалось одинаково.
3. Действия. (а) Данные классифицировали: персональные, обезличенные, общие справочники; (б) для пользователей нового региона развернули отдельный экземпляр базы с хранением персональных данных локально; (в) маршрутизацию по региону пользователя реализовали на уровне точки входа; (г) репликацию в аналитический склад ограничили обезличенными данными, поскольку полный набор нарушал требование; (д) инфраструктуру второго региона описали тем же кодом, что и первого, чтобы исключить расхождение конфигураций; (е) процедуру переключения проверили переключением тестового трафика.
4. Результат. Требование резидентности выполнено, а задержка для пользователей региона снизилась с 90 до 15 миллисекунд как побочный эффект размещения.

Вывод: развёртывание в нескольких регионах оправдано конкретной причиной, а не общей идеей надёжности. Основная работа заключается не в дублировании инфраструктуры, а в классификации данных и разделении их по территориям.

FAQ

Всегда ли несколько регионов повышают надёжность? Нет. Второй регион добавляет отказы репликации и расхождение конфигураций. Надёжность растёт только при проверенной процедуре переключения.

Можно ли снизить задержку без второго региона? Частично — через CDN для статики и кеш. Динамический ответ требует близости к базе данных, поэтому CDN помогает не всегда.

Что сложнее: active-passive или active-active? Active-active существенно сложнее: он требует решения конфликтов записи и постоянной синхронизации состояний между регионами.

Как быть с аналитикой при нескольких регионах? Собирать обезличенные данные в одном месте. Полная репликация персональных данных обычно противоречит требованию резидентности.

Источники: AWS DR Architecture (multi-site), Azure Architecture Center (резидентность), Kubernetes docs — ссылки в шапке.