System Design Space
Граф знанийНастройки

Обновлено: 1 июля 2026 г. в 16:50

Multi-region / Global Systems

сложный

Проектирование глобальных cloud-native систем: multi-region topologies, компромиссы консистентности (consistency trade-offs), global traffic routing и disaster recovery.

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

Для реальных проектных решений глава помогает увидеть, как multi-region topology, routing policy, стратегия репликации (replication strategy), disaster recovery и legal constraints должны складываться в одну модель системы, а не жить набором независимых решений по регионам.

Для интервью и инженерных разборов она полезна тем, что помогает объяснять цену глобализации через write conflicts, сложность эксплуатации, рост инфраструктурного бюджета и более дорогую операционную дисциплину.

Практическая польза главы

Практика проектирования

Определяйте multi-region topology под latency, legal constraints и recovery objectives.

Качество решений

Согласовывайте routing policy, стратегию репликации (replication strategy) и consistency model между регионами.

Аргументация на интервью

Показывайте decision flow: active-active vs active-passive, failover policy, data residency.

Формулировка компромиссов

Объясняйте стоимость глобализации: сложность эксплуатации, write-conflicts и рост инфраструктурного бюджета.

Контекст

Cloud Native Overview

База по облачно-ориентированным принципам, поверх которых строится межрегиональный дизайн.

Открыть главу

Межрегиональные и глобальные системы — это сервисы, которые должны пережить падение целого региона и при этом держать предсказуемую задержку для пользователей по всему миру. Развернуть копии в нескольких регионах — простая часть; трудная начинается, когда задержка, доступность, консистентность, стоимость и соответствие регуляторным требованиям (compliance) тянут проект в разные стороны и за каждый выигрыш приходится чем-то платить.

Базовые межрегиональные топологии

Когда подходит

Простой старт для большинства B2B/B2C систем с одним основным регионом.

Компромисс

Ниже операционная сложность, но выше RTO/RPO и хуже задержка для пользователей далеко от основного региона.

Фокус эксплуатации

Автоматизация переключения и возврата, плюс проверка целостности данных после подъёма резерва.

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

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

Active-Passive

Aurora Global Database

Один writer-регион, storage-репликация во вторичные, управляемое продвижение резерва — учебная реализация паттерна.

Active-Active

DynamoDB Global Tables; Spanner — кворумный вариант

Global Tables принимают записи во всех регионах и платят конфликтами по стратегии «последняя запись побеждает» (LWW); Spanner делает active-active строгим — ценой кворумного и паузы коммита (commit-wait) на каждой записи.

Geo-partitioned

CockroachDB REGIONAL BY ROW; region-pinning тенантов на уровне приложения

Данные закрепляются за домашним регионом строки или арендатора: локальные операции быстры, межрегиональные — явные и редкие.

Данные

Azure latency stats

Публичная таблица межрегиональных P50-задержек Azure — обновляется по реальным замерам магистральной (backbone) сети.

Перейти на сайт

Физика расстояний: межрегиональные задержки

Любой разговор о глобальной архитектуре начинается с одного числа — между регионами. Это нижняя граница для каждой синхронной операции через границу региона: ни , ни репликация, ни не могут быть быстрее. Ориентиры по публичным P50-замерам облачных провайдеров (Azure, июнь 2025; матрица AWS у cloudping.co даёт близкие значения):

US East ↔ US West

~60–70 мс

Один континент: синхронная репликация возможна, но уже съедает заметную часть бюджета задержки.

US East ↔ Западная Европа

~75–85 мс

Классическая трансатлантическая пара: P50 East US ↔ North Europe ≈ 74 мс, ↔ West Europe ≈ 85 мс.

US East ↔ Токио

~165 мс

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

US East ↔ Сингапур

~220–230 мс

Почти четверть секунды на один обмен — любой протокол с двумя раундами уже стоит ~0.5 с.

Западная Европа ↔ Сингапур

~150–165 мс

Маршрут идёт через Ближний Восток или вокруг Индии — длиннее дуги большого круга.

US East ↔ Сан-Паулу

~115–120 мс

Северо-южные маршруты дороже, чем кажется по карте: меньше кабелей, меньше прямых путей.

Что эти числа делают с архитектурой

Синхронная репликация = минимум 1 на фиксацию

Каждая запись, которую нужно подтвердить во втором регионе до ответа клиенту, не может быть быстрее межрегионального . Через Атлантику это ≥75 мс к любой логике приложения.

Кворум платит до ближайшего большинства

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

Двухфазная фиксация поверх регионов ≥ 2

Фазы подготовки и фиксации — два межрегиональных раунда. Транзакция, затрагивающая шарды в Европе и Азии, стоит ≥300 мс только на сеть — до любых блокировок и записи на диск.

Физика не торгуется

Свет в оптоволокне проходит ~200 000 км/с: ~1 мс на 100 км в одну сторону. Нью-Йорк — Сингапур по дуге ~15 000 км, теоретический ~150 мс; реальные маршруты кабелей дают 220+.

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

Рамка принятия решений

  • Бюджет задержки: какое p95-время ответа и 99-й перцентиль допустимы в каждом регионе.
  • Целевой уровень доступности: какая деградация приемлема при падении целого региона.
  • Модель консистентности: где нужна строгая консистентность, а где достаточно итоговой консистентности.
  • Суверенитет данных: где физически можно хранить и обрабатывать данные.
  • Профиль стоимости: сколько стоит межрегиональная репликация, исходящий сетевой трафик (egress) и резервная ёмкость.

Theory

CAP Theorem

При глобальном partition архитектура должна явно выбрать приоритеты CP/AP.

Открыть главу

Слой данных: репликация и консистентность

Single-writer + read replicas

Хорошая базовая архитектура для транзакционной обработки (OLTP) с понятной моделью консистентности и управляемым переключением на резерв.

Multi-primary with conflict resolution

Подходит для глобальных нагрузок с преобладанием записи, но требует чёткой стратегии слияния, стратегии «последняя запись побеждает» или модели «бесконфликтно реплицируемый тип данных» (CRDT).

Regional sharding

Разделение арендаторов и доменов данных по регионам уменьшает задержку и стоимость, повышает изоляцию отказов.

Двойная запись недопустима без координации

Пишите через outbox-паттерн, событийную шину или согласованный слой репликации, иначе получите рассинхрон и потери.

Механика

Консенсус: Paxos и Raft

Кворумные записи Spanner и CockroachDB — это Paxos/Raft, растянутые на регионы.

Открыть главу

Как это решают реальные системы

Четыре промышленные системы покрывают почти всё пространство компромиссов: от с платой за каждый кворум до с . Полезно читать каждую карточку по одной схеме: модель согласованности → механизм → цена.

Google Spanner

Модель согласованности

Внешняя согласованность: если транзакция T2 началась после фиксации T1, метка времени T2 строго больше — никакой клиент не увидит эффект T2 без T1.

Механизм

TrueTime: API времени возвращает не момент, а интервал неопределённости [earliest, latest], который GPS-приёмники и атомные часы в каждом дата-центре удерживают в пределах ~7 мс. Запись проходит через Paxos-группу шарда, а перед тем как сделать её видимой, лидер выдерживает паузу коммита (commit-wait) — ждёт, пока верхняя граница интервала гарантированно окажется в прошлом (в среднем единицы миллисекунд).

Цена

Каждая фиксация платит кворумный между регионами реплик плюс паузу коммита (commit-wait); нужна специализированная инфраструктура часов; размещение лидеров шардов приходится проектировать под географию записей.

Топология

Кворумная active-active: лидеры шардов распределены по регионам, чтение — из ближайшей реплики (строгое или заведомо устаревшее).

DynamoDB Global Tables

Модель согласованности

Согласованность в конечном итоге между регионами (режим MREC по умолчанию); строгое чтение доступно только внутри региона.

Механизм

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

Цена

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

Топология

Каноническая active-active: все регионы равноправно принимают и чтения, и записи.

Aurora Global Database

Модель согласованности

Single-writer: один первичный регион принимает записи, до пяти вторичных обслуживают только чтение с отставанием обычно меньше секунды.

Механизм

Репликация на уровне слоя хранения: изменения уезжают во вторичные регионы по выделенной инфраструктуре storage-слоя, не отнимая ресурсы у самих БД. Write forwarding позволяет приложению во вторичном регионе отправлять записи — Aurora прозрачно перешлёт их первичному.

Цена

Асинхронность означает ≈ 1 с: при потере первичного региона последние записи могут пропасть. < 1 мин при управляемом . Пользователи далеко от первичного региона платят полным межрегиональным за каждую запись.

Топология

Active-passive (точнее, active + вторичные в режиме только для чтения): главный паттерн — аварийное восстановление (DR) и локальное чтение, не глобальная запись.

CockroachDB

Модель согласованности

Сериализуемые транзакции всегда — вопрос не «какая согласованность», а «где живёт задержка». Вместо TrueTime — гибридные логические часы с настраиваемым максимумом рассинхронизации.

Механизм

Таблицы с локальностью REGIONAL BY ROW: каждая строка получает скрытую колонку crdb_region — «домашний» регион, куда помещается владелец аренды её диапазона и голосующие реплики. Survival goal задаёт цену: ZONE держит весь кворум в домашнем регионе (локальная запись, но регион — точка отказа), REGION растягивает кворум по регионам (переживает регион, но каждая запись платит до ближайшего соседа). Follower reads (AS OF SYSTEM TIME) читают слегка устаревшие данные с ближайшей реплики, не обращаясь к владельцу аренды.

Цена

Явный выбор на уровне базы: либо региональная выживаемость, либо локальная задержка записи — не оба сразу. Чтения с ближайшей реплики жертвуют свежестью.

Топология

Geo-partitioned с настраиваемым перекосом: строки живут там, где их пользователи.

Обратите внимание на закономерность: Spanner и CockroachDB кладут цену согласованности в задержку записи (кворум + под контролем), DynamoDB — в потерянные конфликты, Aurora — в и единственный writer-регион. Бесплатного варианта в таблице нет — есть выбор, какой валютой платить.

Глобальная маршрутизация трафика

  • Geo-DNS поверх системы доменных имен (DNS) направляет входящий запрос в регион с наименьшей задержкой — но решает это резолвер клиента, поэтому реакция измеряется минутами, а не секундами.
  • Управление трафиком с учётом проверки работоспособности (health check) убирает деградировавший регион из ротации быстро — но только если проверки действительно ловят его болезнь, а не просто ping.
  • Липкая маршрутизация держит сессию и кэш пользователя в одном регионе: меньше промахов кэша и кросс-региональных обращений, но при переключении на резерв привязку придётся явно сбросить.
  • Глобальный шлюз API и edge-слой задают единое место, где живут политики резервного сценария (fallback) и частичной аварии, — иначе каждый сервис изобретает свою деградацию, и поведение системы в инциденте становится непредсказуемым.

Контекст

Google Global Network

Эникаст-фронты и собственная глобальная сеть WAN — то, что делает быстрое региональное переключение на резерв физически возможным.

Открыть главу

Механика регионального переключения на резерв

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

Health-based DNS

Минуты

Проверки работоспособности снимают деградировавший регион с -ответов (Route 53-стиль). Но решение исполняют клиентские резолверы: пока не истечёт время жизни (TTL) — а часть резолверов игнорирует TTL — трафик продолжает идти в мёртвый регион.

Скорость переключения ограничена кэшами, которыми вы не управляете.

Anycast

Секунды — десятки секунд

Один и тот же IP анонсируется по из многих точек мира; переключение происходит на сетевом уровне, минуя клиентские -кэши. AWS Global Accelerator обнаруживает нездоровый эндпоинт за доли секунды и перенаправляет новые соединения, обычно в пределах десятков секунд; так же работают фронты Google и Cloudflare.

Адрес не меняется — меняется то, куда сеть его ведёт.

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

Split-brain: два региона, обе «живые» половины

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

  • Кворумный арбитр. Нечётное число участников: третий регион (или лёгкий witness-узел) даёт большинство ровно одной стороне разделения — вторая обязана перестать принимать записи.
  • Fencing. Продвижение нового первичного сопровождается токеном эпохи; старый первичный с устаревшим токеном физически не может записать — даже если он ещё «думает», что главный.
  • Асимметрия по умолчанию. Для CP-частей системы правило простое: лучше отклонить запись в меньшинстве, чем принять её дважды. AP-части (DynamoDB Global Tables) сознательно выбирают обратное — и платят конфликтами.

Region evacuation: переключение как рутина

Зрелые операторы относятся к выводу региона из работы не как к катастрофе, а как к управляемой процедуре — region evacuation: постепенный слив трафика (drain) в соседние регионы, наблюдение за ошибками и насыщением, возможность мгновенного отката. Google регулярно прогоняет такие эвакуации в учениях DiRT, а без реального слива трафика считаются неполными: процедура, исполняемая только на бумаге, в реальной аварии не сработает. Ключевой вопрос эвакуации — не «куда уйдёт трафик», а «есть ли у соседей ёмкость его принять».

2 региона active-active

Каждый регион утилизирован ≤50%

Любой из двух должен мгновенно принять 100% глобальной нагрузки — половина купленной ёмкости простаивает в обычный день.

3 региона active-active

Каждый регион утилизирован ≤66%

Выживающая пара делит нагрузку погибшего: запас ёмкости — 1/(N−1) от нормальной доли каждого региона.

Active-passive с «тёплым» резервом

Резерв дешевле, но целевое время восстановления (RTO) длиннее

Минимальный footprint в резерве (данные + уменьшенный compute) снижает счёт, но добавляет время на масштабирование при аварии — и риск, что резерв не отмасштабируется, когда все побежали в один регион.

Это и есть цена «горячего» резерва: чем меньше регионов, тем больше невидимой ёмкости оплачивается каждый день. Она конкурирует со стоимостью на репликацию — в сумме они часто оказываются дороже самих вычислений, и именно их считают в первую очередь при выборе между active-active и тёплым резервом.

Аварийное восстановление, переключение на резерв и операционная готовность

Определите целевое время восстановления (RTO) и целевую точку восстановления (RPO) по каждому критичному сервису и базе данных.

Проверяйте переключение на резерв и возврат регулярно через учения по отказу (game days), а не только на бумаге.

Автоматизируйте продвижение резервного региона и проверку целостности данных после переключения.

Держите инструкцию: кто, когда и по каким сигналам инициирует региональное переключение на резерв.

Разделяйте граф зависимостей, чтобы региональная авария не каскадировала глобально.

Непротестированное переключение на резерв — это не отказоустойчивость, а гипотеза о ней: без регулярных учений архитектура остаётся «теоретически» надёжной ровно до первой настоящей аварии.

Theory

PACELC

Residency добавляет третью ось к компромиссу задержка/консистентность: где данным разрешено находиться.

Открыть главу

Территориальное размещение данных как архитектурное ограничение

— единственное требование в этой главе, которое нельзя «купить» задержкой или деньгами: если закон или контракт требует, чтобы данные жителей ЕС физически не покидали ЕС, это инвариант слоя данных, а не настройка. Технически он реализуется через region-pinning — закрепление строк или арендаторов за домашним регионом, то есть через ту же механику, что и , только выбор региона диктует регулятор, а не задержка.

Строка

CockroachDB REGIONAL BY ROW: домашний регион строки определяет, где живут её кворум и владелец аренды. Данные жителя ЕС физически остаются в регионах ЕС.

Арендатор

Маршрутизация по арендатору на шлюзе: каждый тенант приписан к домашнему региону, его запросы и данные не покидают регион; глобальным остаётся только справочник «тенант → регион».

Развёртывание

Отдельные региональные стеки (например, изолированный контур для ЕС): максимальная изоляция и простая аргументация перед регулятором — ценой дублирования эксплуатации.

Вариант с арендатором опирается на на уровне глобального шлюза — и это обманчиво простая часть. Сложная часть — следствия, которые residency накладывает на всё остальное:

  • Глобальная уникальность (e-mail, username) требует межрегиональной координации или глобального справочника — это единственное место, где residency-архитектура всё же платит межрегиональным временем прохождения туда и обратно (RTT).
  • Перенос пользователя или тенанта между регионами — явный бизнес-процесс с миграцией данных, а не смена флага.
  • Аналитика и ML собирают агрегаты или анонимизированные данные, а не сырые записи: пайплайны тоже обязаны уважать границы.
  • Резервные копии и журналы репликации наследуют ограничение — бэкап «в другой регион для надёжности» может оказаться нарушением.

References

Связанные главы

  • Cloud Native Overview - Базовые принципы облачно-ориентированных архитектур и операционных практик.
  • Kubernetes Fundamentals - Механики управления несколькими кластерами, поэтапного запуска и устойчивости рабочих нагрузок.
  • CAP Theorem - Фундаментальные ограничения распределённых систем при сетевом разделении.
  • PACELC - Почему за выбор между задержкой и консистентностью система платит и в обычном режиме, а не только при сетевом разделении.
  • Консенсус: Paxos и Raft - Как договариваться о состоянии в отказоустойчивом кластере.
  • Google Global Network - Эволюция глобальной сети и подходы к WAN как стратегическому активу.
  • Cost Optimization & FinOps - Как считать стоимость межрегиональных решений и долгосрочные компромиссы.
  • Инженерия надёжности сервисов - Инциденты, целевой уровень сервиса (SLO) и эксплуатация сложных систем в рабочей среде.

Чтобы отмечать прохождение, включи трекинг в Настройки