Multi-region deployment на собеседовании системного аналитика

Зачем multi-region

Multi-region — это когда сервис развёрнут не в одном дата-центре, а сразу в нескольких географических регионах. На собесе системного аналитика тему поднимают в разделе system design и проверяют, понимаете ли вы, зачем это нужно и какой ценой достаётся. У multi-region четыре основные причины:

• Latency (задержка). Пользователи распределены по миру. Чем ближе к пользователю регион, тем быстрее отклик — запрос не идёт через полпланеты.
• Disaster recovery (аварийное восстановление). Если целый регион выходит из строя (пожар в ДЦ, авария у провайдера), другой регион продолжает обслуживать трафик, и сервис остаётся живым.
• Compliance (требования регуляторов). Законы о хранении данных требуют держать данные в определённой юрисдикции: данные граждан ЕС — в ЕС, данные РФ — в РФ. Multi-region позволяет это выполнить.
• Capacity (ёмкость). Нагрузку можно распределить между регионами, а не упираться в потолок одного ДЦ.

Дальше — два базовых способа построить multi-region и их компромиссы.

Active-passive

Один регион активный и принимает весь трафик, второй стоит в горячем резерве (standby). При отказе основного трафик переключается на резервный.

Плюсы. Схема проще и понятнее, это классический подход к disaster recovery. Данных в резерве достаточно, чтобы подхватить работу, а логика приложения не усложняется мультимастерными записями.

Минусы. Ресурсы резервного региона простаивают, пока основной жив, — вы платите за инфраструктуру, которая не обслуживает трафик. Переключение (failover) не мгновенное: RTO измеряется минутами, и часть данных из последних секунд перед сбоем может потеряться (ненулевой RPO при асинхронной репликации).

Регион A (активный) ──репликация──▶ Регион B (пассивный)
Отказ A → переключение DNS / балансировщика на B

Active-active

Оба региона одновременно обслуживают трафик — каждый принимает свою долю пользователей.

Плюсы.

• Задействована вся ёмкость: ни один регион не простаивает.
• Ниже задержка — пользователь ходит в ближайший к нему регион.
• Быстрее failover: при отказе одного региона второй уже в работе и просто берёт на себя больше нагрузки.

Минусы.

• Согласованность данных резко усложняется: запись идёт в обоих регионах (multi-master), и их надо синхронизировать.
• Появляются конфликты записи — когда один и тот же объект изменили в двух регионах одновременно, нужно решить, чья версия победит.

Пользователь из ЕС → регион ЕС
Пользователь из США → регион США
Кросс-региональная репликация для общих данных

Репликация данных

Ядро любой multi-region-схемы — как данные попадают из одного региона в другой.

Репликация БД между регионами.

• Асинхронная репликация (по умолчанию). Регион подтверждает запись сразу, а в другой регион данные доезжают с задержкой — это eventual consistency. Быстро, но при аварии можно потерять последние изменения.
• Синхронная репликация. Запись подтверждается, только когда её принял и другой регион. Строгая согласованность, но между регионами это обычно слишком медленно (десятки–сотни миллисекунд на раунд), поэтому применяется редко.

Разрешение конфликтов (актуально для active-active, где пишут оба региона):

• Last-write-wins — побеждает запись с более поздней меткой времени. Просто, но может молча терять изменения.
• Application-level merge — приложение само знает, как слить конфликтующие версии по бизнес-логике.
• CRDT-структуры данных — типы, которые математически гарантируют, что параллельные изменения сойдутся без конфликтов (счётчики, множества).

Репликация хранилища. Файлы и объекты реплицируют средствами хранилища — например, cross-region replication в S3, которая асинхронно копирует объекты в бакет другого региона.

Tradeoffs

У multi-region нет бесплатного обеда — на собесе как раз и проверяют, называете ли вы цену.

Стоимость. Фактически двойная инфраструктура плюс плата за кросс-региональный трафик, который считается отдельно и бывает дорогим.

Сложность. Растёт сложность эксплуатации, отладки и выкатки релизов: любой инцидент теперь распределённый, а деплой надо катить согласованно по регионам.

Согласованность. Строгая согласованность между регионами медленна или практически недостижима из-за физической задержки. На практике выбирают eventual consistency, и тогда приложение обязано быть к этому готово — учитывать, что данные в регионах могут временно расходиться.

В РФ multi-region обычно реализуют на Yandex Cloud (несколько зон доступности) или VK Cloud, а межстрановой DR рассматривают отдельно — с оглядкой на требования по хранению данных внутри страны.

Как это спрашивают на собесе

Типичная постановка: «Спроектируй геораспределённое развёртывание для сервиса с пользователями в ЕС и РФ». Интервьюер ждёт, что вы:

1. Уточните требования — сколько можно простоять (RTO) и сколько данных допустимо потерять (RPO), есть ли требования по хранению данных в юрисдикции.
2. Выберете схему (active-passive для простого DR или active-active для низкой задержки и полной ёмкости) и обоснуете выбор.
3. Разберёте, как реплицируются данные и что происходит с согласованностью и конфликтами.
4. Проговорите tradeoffs — стоимость, сложность, split-brain при сетевом разрыве между регионами.

Хороший ответ — не «сделаем active-active, потому что круче», а связка «требования → схема → цена».

Связанные темы

• CAP теорема для SA
• Eventual consistency для SA
• Capacity planning для SA
• SLA SLO SLI для SA
• Подготовка к собесу системного аналитика

FAQ

Чем active-active отличается от active-passive?

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

Что такое RTO и RPO?

RTO (Recovery Time Objective) — сколько времени сервис допустимо восстанавливать после сбоя, то есть максимально допустимый простой. RPO (Recovery Point Objective) — сколько данных допустимо потерять, то есть на какой момент в прошлом мы гарантированно восстановимся. При асинхронной репликации RPO ненулевой: последние изменения могут не успеть доехать до резерва. Эти две цифры задают заказчик и бизнес, и от них зависит выбор схемы.

Почему синхронную репликацию редко используют между регионами?

Потому что запись при синхронной репликации подтверждается, только когда её принял удалённый регион, а раунд между географически далёкими ДЦ занимает десятки–сотни миллисекунд. Это резко бьёт по задержке каждой записи. Поэтому между регионами обычно выбирают асинхронную репликацию и eventual consistency, а синхронную оставляют для реплик внутри одного региона.

Что такое split-brain и как с ним борются?

Split-brain — ситуация, когда из-за сетевого разрыва оба региона считают себя главными и продолжают независимо принимать записи, а после восстановления связи их данные конфликтуют. Борются с этим кворумом (решения принимает только большинство узлов), выделенным арбитром и стратегиями разрешения конфликтов (last-write-wins, merge, CRDT). Полностью избежать нельзя — важно заранее решить, как система себя поведёт.

Это официальная информация?

Нет. Статья основана на общепринятых практиках проектирования облачной архитектуры и опыте кандидатов. Конкретные требования зависят от компании, продукта и уровня позиции.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.