Переезд в другую локацию ради маршрутов: когда это реально помогает, а когда нет

MAATRIX

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

Когда переезд помогает: замеры подтверждают, что аудитория объективно далеко

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

Ключевое слово здесь — «замеры», а не «ощущение». Ощущение вроде «у нас сервер в Москве, а половина клиентов вроде бы из Азии, наверное там и тормозит» регулярно не подтверждается на практике: реальное распределение трафика по логам может сильно отличаться от обрывочных жалоб в поддержку. Как выглядит методичный сбор таких замеров — от логов и GeoIP-разбивки по ASN до RUM-скриптов на реальном сайте и чтения результатов через перцентили, а не только среднее — подробно разобрано в статье про выбор локации по замерам аудитории. Тот же план применим и к решению о переезде уже работающего сервиса: у вас уже есть текущая локация как одна из точек сравнения, остаётся снять те же метрики до кандидата и сравнить с тем, что показывает сервер прямо сейчас.

Практический порог, ниже которого переезд обычно не окупается: если разница в p50/p95 между текущей и новой локацией — единицы миллисекунд, а сервис не относится к категории «каждая миллисекунда критична» (торговые терминалы, real-time игры, голосовая связь), овчинка не стоит выделки. Если разница измеряется в десятках-сотнях миллисекунд для заметной доли аудитории, а сервис интерактивный (частые API-запросы, живой чат, панель управления) — здесь у переезда есть реальный шанс окупиться, но проверять всё равно нужно замерами, а не предположением о географии.

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

Когда переезд помогает: у текущей локации объективно плохая связность с ключевыми регионами

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

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

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

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

Когда переезд не поможет: проблема не в сети, а в архитектуре приложения

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

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

Та же логика применима и к бэкенду: если тормозит не отдача статики, а конкретный API-эндпоинт, стоит сначала профилировать сам запрос — сколько времени уходит на N+1-запросы к базе, синхронные вызовы к внешним сервисам, неэффективные SQL-планы — и только после этого решать, действительно ли узкое место в сети. Переезд не ускорит запрос, который сам по себе выполняется секунду на бэкенде из-за архитектурной проблемы, — он лишь чуть сократит время доставки того же медленного ответа. Пользователь по-прежнему будет ждать, просто чуть меньше.

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

Практическая проверка перед переездом: снимите water-fall загрузки страницы в DevTools или профиль медленного запроса на бэкенде. Если видно, что время уходит не на сетевой RTT до сервера, а на количество запросов, на медленные запросы к БД или на синхронные вызовы к сторонним API — переезд не решит эту часть проблемы, и деньги разумнее сначала вложить в оптимизацию именно этого.

Когда переезд не поможет: аудитория распределена широко, а не сосредоточена в одном месте

Второй случай, где простой переезд не решает задачу, — когда аудитория объективно размазана по нескольким удалённым друг от друга регионам, а не сконцентрирована в одном. Переезд из локации A в локацию B в этой ситуации не устраняет проблему задержки — он просто меняет, для какого сегмента аудитории она станет заметной. Было плохо пользователям в Азии — станет плохо пользователям в Европе, потому что один сервер физически не может быть одинаково близко ко всем.

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

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

Когда переезд не поможет: деградация временная и устранима без переезда

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

Признаки, что деградация, скорее всего, временная, а не структурная:

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

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

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

Алгоритм принятия решения: сначала диагностика, потом цена, а не наоборот

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

1. Соберите объективные замеры. Реальное распределение аудитории по логам и ASN, задержка/джиттер/потери до текущей локации и до 1-2 кандидатов, картина по времени суток за несколько дней, а не один снимок. Без этого шага дальше двигаться нет смысла — решение будет строиться на догадке.
2. Диагностируйте настоящую причину, а не только симптом. Проверьте водопад загрузки страницы и профиль медленных запросов бэкенда, прежде чем списывать всё на сеть. Отдельно проверьте, не временный ли это инцидент у конкретного аплинка, который решится сам или сменой провайдера без переезда.
3. Определите архитектуру распределения аудитории. Один явно доминирующий регион — кандидат на переезд. Несколько сопоставимых по значимости регионов — кандидат на мультирегиональную схему, а не на единичный переезд.
4. Только теперь считайте цену переезда против ожидаемого выигрыша. В цену входят: время простоя или период двойной работы на время миграции DNS TTL, риск потери данных при переносе базы, трудозатраты команды, стоимость новой локации. Ожидаемый выигрыш — не точное число, а диапазон: замеры показывают ощутимо более низкую задержку и меньше потерь для сегмента, дающего заметную долю трафика или выручки, — либо не показывают.
5. Сравните конкретно, а не абстрактно. Если цена переезда сопоставима или выше ожидаемой пользы для бизнес-метрик — переезд не оправдан сейчас, даже если технически он бы улучшил задержку на какие-то миллисекунды. Если пользы существенно больше цены для значимого сегмента аудитории — это тот случай, когда переезд стоит делать.

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

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