Проекту стало тесно в одной стране: когда заводить второй сервер в другом регионе

MAATRIX

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

Сигнал первый: аудитория ушла в другой регион, и это подтверждено замерами

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

Практический порядок такой:

1. Посмотреть в аналитике реальное географическое распределение запросов за последние несколько месяцев, а не за один пиковый день — краткосрочные всплески трафика из нового региона (реклама, вирусный пост) не повод разворачивать инфраструктуру.
2. Для той части аудитории, что выросла, замерить фактическую задержку до текущего сервера — не «на глаз», а инструментами вроде globalping или RUM-метрик из браузера пользователя, и смотреть не на среднее, а на перцентили (p75, p95) — среднее прячет именно тех пользователей, для кого сервис ощутимо тормозит.
3. Сравнить эту задержку с задержкой до кандидата на второй регион, снова по перцентилям, а не по одному пингу с ноутбука разработчика.

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

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

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

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

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

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

Юридический сигнал отличается от сигнала по задержке тем, что он не обсуждаем с точки зрения «выгодно или нет» — если требование применимо к проекту, второй сервер в нужном регионе становится не оптимизацией, а условием продолжения работы с этой аудиторией.

Сигнал третий: нужен план на случай недоступности основного региона

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

Здесь важно различать два родственных, но разных решения:

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

Прежде чем заводить резервный контур, стоит явно ответить на два вопроса: сколько времени простоя проект может себе позволить (RTO — recovery time objective) и сколько данных допустимо потерять при аварии (RPO — recovery point objective). Эти ответы определяют, нужен ли второй сервер вообще в горячем режиме, или достаточно регулярных бэкапов, которые лежат в другом регионе и разворачиваются вручную при необходимости. Для многих проектов правильный ответ — второе: резервные бэкапы в другом регионе без постоянно работающего второго сервера уже закрывают большую часть риска disaster recovery без затрат на постоянную синхронизацию.

Частая ошибка: второй регион «на всякий случай»

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

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

• Синхронизация данных — как только на втором сервере лежит своя копия базы, встаёт вопрос синхронной или асинхронной репликации, и если она синхронная, каждая запись в основной базе начинает ждать подтверждения от реплики в другой стране — а это добавляет к каждому COMMIT полный сетевой RTT до второго региона, независимо от мощности серверов с обеих сторон. Во что это выливается на практике и какие есть варианты компромисса между надёжностью и скоростью — подробно разобрано в статье про цену синхронной репликации в другую страну.
• Двойное администрирование — обновления безопасности, мониторинг, ротация ключей, проверка бэкапов теперь нужны на двух независимых контурах вместо одного, и расхождение конфигурации между ними — вопрос времени, а не вероятности.
• Маршрутизация и здоровье по регионам — если трафик должен идти в ближайший рабочий регион, нужен отдельный слой, который решает, куда направить конкретного пользователя, и отдельный мониторинг, который заметит проблему именно во втором регионе, если в первом всё зелёное.

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

Прежде чем решать: сформулируйте, что именно решает второй регион

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

Возможные честные ответы выглядят примерно так:

• «Задержка для аудитории из региона X объективно выше, чем для основной, и это подтверждено замерами по перцентилям» — решает конкретная схема с обслуживанием запросов ближе к этой аудитории.
• «Данные пользователей из региона Y по итогам консультации с юристом обязаны физически храниться в этом регионе» — решает выделенный контур хранения именно для этих данных, а не обязательно весь сервис целиком.
• «Простой основного региона длиннее, чем допустимый RTO проекта, и это неприемлемо» — решает резервный контур disaster recovery, необязательно постоянно работающий.

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

От ответа к архитектуре: active-active, active-passive или просто резервные бэкапы

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

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

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

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