Один сервис в трёх странах: что для этого нужно на самом деле, кроме трёх серверов

MAATRIX

Заказчик просит «сделать сервис быстрым в России, США и Британии» — и первая мысль почти всегда одна: взять три VPS в трёх регионах, развернуть на них один и тот же образ и радоваться низкому пингу у всех трёх аудиторий сразу. Технически так и есть — без серверов в каждой стране ничего не заработает. Но сама по себе аренда трёх машин закрывает едва ли десятую часть задачи. Дальше начинается работа, которую не видно на схеме с тремя кружочками на разных континентах: кто решает, куда идёт клиент, что из данных должно совпадать между регионами секунда в секунду, а что может жить своей локальной жизнью, кто заметит аварию именно в Британии, если в России и США всё зелёное, и кто в три часа ночи по Лондону поднимет трубку, если сервис лёг там, где у всей остальной команды разгар рабочего дня.

Сервер в каждой стране — это только входной билет

Три сервера в трёх странах дают ровно одно: физическое присутствие поближе к пользователю. Это снижает задержку на уровне сети — TCP- и TLS-рукопожатие, доставка статики, первый байт ответа. Для части сервисов (лендинг, статический сайт, раздача контента без состояния) этого действительно достаточно: развернул, указал DNS, готово.

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

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

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

Маршрутизация: как клиент попадает в свой регион

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

• GeoDNS — DNS-резолвер отдаёт разным клиентам разные A/AAAA-записи в зависимости от того, откуда пришёл запрос (по geoip резолвера или EDNS Client Subnet). Просто в настройке, не требует anycast-инфраструктуры, но зависит от того, каким DNS-сервером пользуется клиент — мобильный оператор в другой стране может резолвить через DNS где-то в третьей юрисдикции, и клиент улетит не туда.
• Anycast — один и тот же IP анонсируется из нескольких точек, и маршрутизация на уровне BGP сама приводит пакет в ближайшую точку присутствия. Работает надёжнее GeoDNS, но требует своей автономной системы или провайдера, который такое предоставляет, — для большинства арендованных VPS это недоступно напрямую.
• L7-балансировщик с health check — перед регионами стоит слой (например, на основе nginx/HAProxy или облачного балансировщика), который знает про все регионы, проверяет их здоровье и распределяет трафик с учётом и близости, и доступности. Этот вариант проще совместить с failover: если региона нет — трафик уходит в соседний, а не в мёртвую точку.

На практике для трёх серверов в трёх странах чаще всего берут GeoDNS как базовый слой маршрутизации плюс health check поверх — если ближайший регион недоступен, DNS должен переключить клиента на запасной за разумное время (а не ждать TTL в час). Подробный разбор конкретных схем — nginx upstream с весами, GeoDNS-провайдеры, failover между тремя точками и типичные грабли вроде залипания сессии на упавшем сервере — в статье про балансировку между серверами в разных странах.

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

Что в архитектуре должно быть общим, а что может быть локальным

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

Практический способ разложить систему — пройтись по каждой сущности и честно ответить на вопрос: «если пользователь сделает действие в одном регионе, а через минуту откроет сервис из другого — что он должен увидеть?»

Кандидаты на общее состояние (нужна синхронизация или единый источник):

• каталог товаров, цены, остатки — если покупатель в Британии не должен видеть то, что уже продано в США;
• баланс счёта, история платежей — рассинхрон здесь стоит денег и доверия;
• учётные данные и права доступа — пользователь должен одинаково залогиниться из любой точки;
• бизнес-события, которые нужно свести в одну аналитику или бухгалтерию.

Кандидаты на локальное состояние (может жить только в своём регионе, без репликации):

• пользовательские сессии — если клиент «прилип» к региону через маршрутизацию, сессию незачем тащить в другие;
• кэш вычислений и рендеринга — потеря или расхождение кэша не катастрофа, он просто пересчитается;
• очереди фоновых задач, специфичных для региона (например, отправка локальных уведомлений);
• логи и метрики — их разумнее агрегировать централизованно уже после сбора, а не писать в общую БД синхронно.

Для общих данных дальше встаёт вопрос — как их синхронизировать. Тут два базовых пути: одна «мастер»-база в одном регионе с чтением с реплик в остальных (просто, но пишущие операции из дальних регионов будут тормозить и упрутся в единую точку отказа), либо мультимастер / active-active с разрешением конфликтов (быстрее для записи из любого региона, но конфликты надо явно проектировать — что произойдёт, если один и тот же товар одновременно купят в двух регионах). Прежде чем выбирать схему репликации, стоит понять её цену: синхронная репликация между странами тратит на каждую запись время сетевого round-trip до дальнего дата-центра, и это не гипотетическая накладная плата — разбор того, во сколько обходится синхронная репликация показывает арифметику этой цены и когда она вообще оправдана против асинхронной схемы с возможной потерей последних секунд записи.

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

Мониторинг: у каждого региона своя правда

Общий дашборд с одной цифрой аптайма — это самая опасная метрика в мультирегиональном сервисе, потому что она усредняет. Если США и Британия отвечают за 80 мс, а Россия из-за проблем с транзитным провайдером отвечает за 3 секунды или не отвечает вовсе, средний показатель по трём регионам всё равно может выглядеть «в целом нормально» — и именно поэтому средние по больнице метрики маскируют локальные аварии до тех пор, пока не начнут звонить пользователи.

Правильная схема — независимые проверки на каждый регион:

• health check изнутри региона (localhost/внутренний адрес) — показывает, жив ли сам сервис;
• проверка снаружи, из точки, близкой к целевой аудитории региона, а не из датацентра, где стоит сам мониторинг, — иначе вы проверяете связность между двумя своими серверами, а не то, что видит реальный пользователь;
• отдельные алерты и отдельные SLA-панели на регион, без слияния в одну цифру;
• проверка именно того пути, которым реально идёт клиентский трафик (через тот же GeoDNS/балансировщик), а не прямого обращения к IP сервера в обход маршрутизации.

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

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

Деплой: одновременно везде или поэтапно, регион за регионом

Выкатка новой версии на три региона разом соблазнительна своей простотой — один pipeline, один тег образа, три docker compose pull && up -d или три ansible-плейбука, запущенные параллельно. Проблема в том, что если в новой версии есть баг, вы получаете инцидент сразу во всех трёх странах одновременно, в разных часовых поясах, и откатывать приходится везде разом под давлением.

Более устойчивая схема — поэтапный деплой, регион за регионом, с паузой между этапами:

1. Деплой в регион с наименьшим трафиком (обычно там, где сейчас ночь)
2. Пауза 15-30 минут, наблюдение за метриками и логами именно этого региона
3. Если всё чисто — деплой во второй регион
4. Пауза, наблюдение
5. Деплой в оставшийся регион (обычно самый нагруженный/критичный)

По сути это canary-деплой, только единицей канарейки выступает не процент трафика внутри одного кластера, а целый регион. Общие принципы — на что смотреть между этапами (ошибки 5xx, время ответа, бизнес-метрики вроде успешных платежей), когда откатываться автоматически, а когда решает человек — описаны в статье про canary deploy; та же логика применима и к региональному раскатыванию, только шаг — не 5% трафика, а целая точка присутствия.

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

Юридические и регуляторные особенности хранения данных по странам

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

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

Поддержка на разных часовых поясах: кто отвечает, когда ломается ночью

Три сервера в трёх странах почти всегда означают три разных часовых пояса — и, значит, три разных «сейчас ночь здесь». Инцидент в британском регионе в 4 утра по Лондону — это разгар дня в России и раннее утро на восточном побережье США. Если вся команда физически сидит в одном часовом поясе, ночная авария в дальнем регионе будет обнаружена только тогда, когда там снова наступит рабочий день — и это может означать многочасовой простой именно там, где команда меньше всего этого ожидает.

Рабочие варианты закрыть этот разрыв, от простого к сложному:

• дежурство по расписанию (on-call) — кто-то один отвечает за алерты 24/7 по очереди, независимо от своего часового пояса, с чёткой эскалацией, если не отреагировал за N минут;
• follow-the-sun — если команда достаточно большая и территориально распределена, дежурство передаётся тому, у кого сейчас рабочий день; сложнее в организации, но снимает нагрузку ночных дежурств с одного человека;
• автоматический откат без участия человека — для типовых сценариев (упавший health check после деплоя) можно настроить автоматический rollback, чтобы не ждать человека вообще, а будить дежурного только если автоматика не справилась.

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

Частые вопросы