Выбираем локацию сервера по замерам своей аудитории, а не по карте: план на неделю

MAATRIX

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

День 1: где на самом деле живёт ваша аудитория

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

Источники, которые у вас, скорее всего, уже есть:

• Веб-аналитика (Яндекс.Метрика, Google Analytics, self-hosted вроде Plausible или собственная система) — даёт разбивку по странам и городам, иногда по операторам. Смотрите не только на «топ-5 городов», а на распределение по хвосту: сфокусированная в одном городе аудитория и та же аудитория, размазанная по десятку регионов, — это разные задачи.
• IP-логи веб-сервера или балансировщика — точнее аналитики, потому что не режутся блокировщиками рекламы и трекеров. Быстрый способ вытащить топ подсетей за последние сутки-двое из access-логов nginx:

awk '{print $1}' /var/log/nginx/access.log | \
  sort | uniq -c | sort -rn | head -50 > /tmp/top-ips.txt

# групповая разбивка по /24, чтобы увидеть провайдерские блоки, а не отдельные IP
awk '{print $1}' /var/log/nginx/access.log | \
  awk -F. '{print $1"."$2"."$3".0/24"}' | \
  sort | uniq -c | sort -rn | head -30

• GeoIP-разбивка по ASN, а не только по городу. Для задержки важнее не «город Москва», а конкретный оператор — у разных провайдеров одного города маршрут до одного и того же дата-центра может отличаться в разы. Прогоните топ IP-адресов через базу вроде MaxMind GeoLite2-ASN или сервис ipinfo.io и сгруппируйте по ASN — это даст список реальных операторов, а не абстрактных городов.
• CDN-логи, если CDN уже используется — у большинства провайдеров в панели есть разбивка запросов по стране и иногда по PoP (точке присутствия), к которой подключались пользователи.

Итог первого дня — таблица вида «регион/оператор → доля трафика», а не абстрактное «аудитория в России и Европе». Именно она определит, какие локации вообще имеет смысл тестировать на следующих шагах.

День 2: выбираем 2-4 локации-кандидата и поднимаем тестовые точки

Из таблицы дня 1 выберите не одну «очевидную» локацию, а 2-4 кандидата. Логика отбора:

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

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

Минимальный набор на тестовой точке:

# ICMP должен отвечать (для ping/mtr/globalping)
sudo apt update && sudo apt install -y mtr-tiny

# лёгкий HTTP-эхо для замера TTFB и TCP/TLS-хендшейка
sudo apt install -y nginx
echo "ok" | sudo tee /var/www/html/ping.txt

Этого достаточно, чтобы извне снимать и ICMP-задержку, и полноценный HTTP-запрос с таймингами до конкретной локации. Держите тестовые точки на весь период замеров — несколько дней, а не один час, ниже объясним, зачем.

День 3-4: инструменты для замеров с точки зрения разных сегментов аудитории

Здесь три рабочих способа получить данные не «из своего офиса», а от точек, реально близких к сегментам вашей аудитории.

Globalping — бесплатный сервис с сетью распределённых зондов у волонтёров и провайдеров по всему миру, доступен через веб-интерфейс, API и CLI. Позволяет запустить ping, traceroute, mtr или DNS-запрос из выбранного региона или конкретной страны без необходимости самому иметь там сервер:

npm install -g globalping-cli

# пинг тестовой точки во Франкфурте из зондов в конкретной стране
globalping ping fra-test-ip.example.com --from "Russia" --limit 5

# то же самое как traceroute, чтобы увидеть структуру маршрута
globalping traceroute fra-test-ip.example.com --from "Germany" --limit 3

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

Простые curl-скрипты с воркерами в разных регионах. Если есть доступ к serverless-платформе с точками присутствия в разных регионах, можно развернуть лёгкую функцию, которая снимает тайминги до каждой тестовой точки. Та же команда замера подходит и для обычного VPS в нужном регионе:

for i in $(seq 1 20); do
  curl -o /dev/null -s -w "%{time_total}\n" https://fra-test-ip.example.com/ping.txt
  sleep 1
done | tee /tmp/fra-samples.txt

# среднее, минимум, максимум по накопленным замерам
awk '{sum+=$1; if(min==""||$1<min)min=$1; if($1>max)max=$1; n++}
     END{print "avg="sum/n" min="min" max="max}' /tmp/fra-samples.txt

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

RUM-замеры через JS на реальном сайте (Real User Monitoring) — самый честный источник данных, потому что снимает тайминги не с тестового зонда, а с браузеров реальных посетителей. Минимальная реализация — добавить на страницу небольшой скрипт, который замеряет время соединения до тестовых эндпоинтов в каждой локации-кандидате и отправляет результат на сбор:

<script>
async function measureLocation(url, label) {
  const start = performance.now();
  try {
    await fetch(url, { mode: 'no-cors', cache: 'no-store' });
    const rtt = performance.now() - start;
    navigator.sendBeacon('/collect-latency',
      JSON.stringify({ label, rtt, ts: Date.now() }));
  } catch (e) { /* эндпоинт недоступен из этой сети — тоже сигнал */ }
}
measureLocation('https://fra-test-ip.example.com/ping.txt', 'fra');
measureLocation('https://mow-test-ip.example.com/ping.txt', 'mow');
</script>

Плюс RUM — это реальные сети и провайдеры ваших пользователей, а не зонды третьей стороны. Минус — нужен уже работающий сайт с трафиком и точка сбора результатов (подойдёт и просто логирование в файл на бэкенде). Без такой возможности globalping и curl-замеры с распределённых точек дают достаточно репрезентативную картину.

День 5: как читать результаты — не средний пинг, а джиттер и перцентили

Собрав сырые данные, главная ошибка — свести их к одному числу «средний пинг» и по нему сравнить локации. Средняя задержка одинаково хорошо описывает и стабильный канал с ровными 40 мс, и рваный канал, где половина запросов укладывается в 20 мс, а другая половина улетает за 200, — при одинаковом среднем это два разных пользовательских опыта. Почему среднее систематически обманывает и что смотреть вместо него, подробно разобрано в статье про перцентили p50/p95/p99 — тот же принцип применим и к сравнению локаций.

Что смотреть вместо (или вместе со) средним:

• Перцентили, а не только среднее. p50 (медиана) показывает типичный опыт, p95 и p99 — то, что видит существенная доля пользователей в худшем случае. Локация с невысоким p50, но резко растущим p95, на практике может ощущаться хуже локации с чуть более высоким, но ровным p50.
• Джиттер — разброс задержки между последовательными пакетами, а не просто «средняя минус минимум». Для статичной страницы джиттер малозначим, но для голосовой связи, видеозвонков и онлайн-игр он критичен и заслуживает отдельного внимания при сравнении локаций.
• Долю потерь пакетов (Loss%). Локация со слегка более высокой средней задержкой, но нулевыми потерями, обычно предпочтительнее локации с меньшей средней, но заметными потерями — потери означают повторные передачи, что для TCP добавляет задержку резче, чем кажется по одной цифре RTT.
• Разброс по времени суток. Одна и та же пара точек может показывать разную картину днём и ночью из-за загрузки транзитных каналов в часы пик. Сведите замеры за несколько дней в таблицу по часам, а не берите единственный снимок.

Практически удобно свести данные в таблицу по кандидатам:

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

День 6: взвешиваем латентность против цены и требований к локализации

Локация с лучшей задержкой не всегда становится финальным выбором — на решение влияют ещё минимум два фактора.

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

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

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

Частая ошибка: выбор дата-центра по названию города на карте

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

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

Один регион или несколько серверов с балансировкой — как решить

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

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

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

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

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