Математика задержки: что налагает физика
Свет в вакууме движется со скоростью 299 792 км/с. Свет в оптоволокне движется примерно со скоростью 2/3 от этой — около 200 000 км/с, или примерно 5 мс на 1000 км в одну сторону. Время прохождения (RTT) — удвоенное: ~10 мс на 1000 км кабельного пути. Реальные оптоволоконные пути обычно в 1,3-2 раза длиннее великого круга, поэтому учитывайте дополнительную задержку за реальные особенности маршрутизации.
Свет замедляется в стекле из-за коэффициента преломления. Коэффициент преломления одномодового волокна — примерно 1,467, поэтому скорость света в волокне c/1,467 ≈ 204 300 км/с. Это даёт одностороннюю задержку около 4,9 мс на 1000 км волокна и RTT 9,8 мс. Это жёсткий физический пол — никакая инженерия провайдера не превзойдёт скорость света. Более полезное правило для планирования продакшена: закладывайте 1 мс на 100 км в одну сторону плюс 1-2 мс накладных расходов на коммутацию и маршрутизацию на сетевой хоп. Длиннодистанционные подводные кабели хорошо инженерны и приближаются к теоретическому минимуму (Лондон-Нью-Йорк примерно 70 мс RTT, близко к пределу 5500 км великого круга). Последняя миля и внутригородские пути часто 5-15 мс из-за хопов маршрутизаторов и геометрии пиринга ISP, а не расстояния.
Реальные оценки RTT между крупными городами
Приблизительные RTT (полное время прохождения) между крупными хостинговыми узлами в 2026: Лондон-Амстердам ~10 мс, Лондон-Франкфурт ~15 мс, Лондон-Нью-Йорк ~70 мс, Нью-Йорк-Сан-Франциско ~70 мс, Франкфурт-Сингапур ~160 мс, Лондон-Сидней ~250 мс, Токио-Сан-Франциско ~100 мс. Это типичные значения наилучшего случая по волокну, измеренные TCP-к-TCP между пирами дата-центров.
Эти числа — из публичных пиринговых данных, опубликованных крупными IXP (LINX, AMS-IX, DE-CIX, KINX) и крупномасштабных атласов задержек (RIPE Atlas, WonderNetwork, Cloudping). Ваш реальный RTT будет варьироваться на 10-30% в зависимости от времени суток, отношений пиринга между Вашим провайдером и ISP пользователя и конкретного пути подводных кабелей. Числа выше типичные, не гарантированные, и они предполагают, что обе конечные точки находятся в дата-центрах с многотерабитным транзитом. Жилые соединения последней мили добавляют ещё 5-30 мс поверх пола дата-центр-к-дата-центру.
| Откуда | Куда | Расстояние (великий круг) | Типичный RTT |
|---|---|---|---|
| Лондон | Амстердам | 360 км | ~10 мс |
| Лондон | Франкфурт | 640 км | ~15 мс |
| Лондон | Париж | 340 км | ~10 мс |
| Франкфурт | Варшава | 900 км | ~20 мс |
| Лондон | Нью-Йорк | 5570 км | ~70 мс |
| Нью-Йорк | Майами | 1760 км | ~30 мс |
| Нью-Йорк | Сан-Франциско | 4140 км | ~70 мс |
| Сан-Франциско | Токио | 8280 км | ~100 мс |
| Франкфурт | Сингапур | 10 290 км | ~160 мс |
| Лондон | Сидней | 16 990 км | ~250 мс |
| Франкфурт | Мумбаи | 6580 км | ~110 мс |
| Сан-Паулу | Майами | 6580 км | ~120 мс |
Резидентность данных: GDPR, CLOUD Act и остальные
Персональные данные ЕС/EEA подпадают под GDPR (Регламент (ЕС) 2016/679), который ограничивает передачу за пределы EEA без специальных гарантий. US CLOUD Act (2018) позволяет органам США обязать провайдеров со штаб-квартирой в США раскрывать данные независимо от того, где они физически хранятся. У России и Китая собственные режимы локализации данных. Выбирайте регион дата-центра, соответствующий и юрисдикциям пользователей, и Вашим контрактным обязательствам.
GDPR (вступил в силу в мае 2018) рассматривает любые персональные данные резидентов ЕС или EEA — имя, email, IP-адрес, поведенческие данные — как регулируемые независимо от того, где находится штаб-квартира контролёра. Трансграничная передача требует решения об адекватности, Стандартных контрактных условий или Обязательных корпоративных правил. Послабления статьи 49 узки. Решение Schrems II (Суд ЕС, июль 2020) отменило Privacy Shield и значительно ужесточило гарантии передачи. US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) позволяет федеральным властям США обязать любого американского провайдера предоставить хранящиеся данные, даже если они находятся на сервере во Франкфурте. Это создаёт напряжение для европейских клиентов, использующих американских хостинг-провайдеров, независимо от того, в каком дата-центре физически находятся их данные. Российский Федеральный закон № 242-ФЗ требует, чтобы персональные данные граждан России обрабатывались первоначально на серверах, физически находящихся в России. Китайский PIPL (Закон о защите персональной информации, в силе с ноября 2021) требует локализации для операторов критической информационной инфраструктуры и для крупных обработчиков данных. Никому из этих режимов не важно, где работают Ваши серверы приложений; всем им важно, где хранятся и обрабатываются персональные данные.
Когда мульти-регион имеет смысл
Мульти-регион оправдан, когда у Вас географически распределённые пользователи с требованиями задержки менее 100 мс, когда у Вас есть регуляторные обязательства по резидентности данных в разных юрисдикциях или когда риск простоя одного региона неприемлем. Он редко оправдан для хобби-проектов, низкотрафиковых SaaS с пользователями в одном регионе или нагрузок, где инженерная сложность перевешивает выигрыши в задержке.
Мульти-регион добавляет три конкретных стоимости. Во-первых, инженерная сложность: репликация данных (eventually-consistent или глобально синхронная), логика маршрутизации (geo-DNS, anycast, региональный failover) и наблюдаемость во всех регионах умножают операционную поверхность. Во-вторых, инфраструктурные затраты: как минимум удвоенные вычисления и хранилище плюс плата за межрегиональный транзит, которую облачные провайдеры берут за ГБ. В-третьих, компромиссы согласованности: синхронные глобальные записи физически ограничены той же математикой задержки из предыдущего раздела, поэтому большинство мульти-региональных проектов принимает некоторую форму eventual consistency. Оправдания такой стоимости: реальные пользователи, распределённые по континентам, где задержка 200+ мс убивает конверсию; требования восстановления RTO менее секунды; регуляторные обязательства держать данные ЕС в ЕС, а данные США в США одновременно; или требования active-active высокой доступности, где сбой любого одного дата-центра должен быть невидимым. Большинству продакшен-нагрузок это не нужно; многие проекты переинженерены к этому.
Дерево решений: как выбрать регион
Шаг 1: определите, где живут 80% Ваших пользователей (аналитика, логи CDN, ожидаемый целевой рынок). Шаг 2: выберите ближайший хостинговый регион. Шаг 3: проверьте, что юридическая юрисдикция соответствует Вашим обязательствам по резидентности данных. Шаг 4: добавляйте второй регион, только если шаг 1 выявляет второй кластер пользователей более чем в 100 мс RTT от первого, или если требования HA/DR этого требуют.
Честно пройдите по дереву. Для типичного европейского SaaS с пользователями в основном в Германии, Франции, Великобритании и Нидерландах один западноевропейский дата-центр (Франкфурт, Амстердам или Лондон) держит каждого пользователя ниже 30 мс RTT и чисто удовлетворяет GDPR. Для US-сосредоточенного B2B-продукта с пользователями от Бостона до Лос-Анджелеса один US-East дата-центр (Эшбёрн, Нью-Йорк) держит пользователей восточного побережья ниже 20 мс, западного — ниже 80 мс — плохо для геймеров, нормально для большинства SaaS. Для действительно глобальных продуктов (веб-приложения с пользователями на всех континентах) основной регион плюс CDN с глобальным edge-присутствием обычно превосходит запуск active-active в трёх дата-центрах. Для продуктов с жёсткими требованиями резидентности данных в разных юрисдикциях (плоскость данных только в ЕС и только в США) мульти-регион становится обязательным независимо от задержки.
Сертификаты, которые что-то значат
Ищите ISO/IEC 27001 (управление информационной безопасностью), SOC 2 Type II (операционные контроли, аудитируемые во времени, а не на момент) и PCI DSS Level 1 (платёжные данные), если применимо. Для клиентов из ЕС ищите явные соглашения об обработке данных GDPR (DPA) и чёткий список субподрядчиков. Маркетинг «безопасности корпоративного класса» без названных сертификатов по сути ничего не значит.
Три сертификата имеют реальный вес. ISO/IEC 27001:2022 — международный стандарт для систем управления информационной безопасностью, требующий независимого аудита и продолжающихся надзорных аудитов. SOC 2 Type II аудирует контроли организации в окне наблюдения 6-12 месяцев, отличая его от Type I (на момент). PCI DSS применяется, если Вы обрабатываете платёжные карты; Level 1 — для организаций, обрабатывающих 6+ миллионов транзакций в год. Для клиентов из ЕС GDPR DPA (приложение об обработке данных) контрактно обязывает и описывает, что именно провайдер может и не может делать с Вашими данными. Помимо этого, ищите отчёты о прозрачности (как часто провайдер получает запросы от правоохранительных органов?), опубликованный список субподрядчиков (третьи стороны, имеющие доступ к Вашим данным) и чёткие гарантии удаления данных при прекращении контракта. Общие фразы вроде «банковский уровень безопасности» или «военный уровень шифрования» ничего Вам не говорят — лежащий в основе алгоритм AES-256 одинаков везде.