Edge POP против DNS-only маршрутизации: компромисс бюджета задержки

Бюджет задержки для URL-редиректа делится на два режима. Ниже ~50 мс p50 - это территория edge POP: anycast направляет пользователя к ближайшему кешу, редирект отвечает до того, как TCP-рукопожатие стало ощутимым. Выше ~50 мс - это территория DNS-only: DNS-балансировка нагрузки маршрутизирует клиента во время разрешения имени, редирект - это один TCP round-trip через континент, и в бюджет входит этот round-trip. Архитектуры внешне похожи (обе отдают 302). Производительность - нет. Этот пост - их сравнение.

Для детального изучения бюджета задержки достижение p95 < 15 мс для редиректов - это подробный материал. Данный пост - об архитектурном решении, лежащем в его основе.

Что на самом деле означает «DNS-only маршрутизация»

DNS-only маршрутизация отвечает на вопрос «на какой origin должен попасть этот клиент?» через DNS-резолвинг, а не через TCP-путь. Пользователь в Сиднее резолвит r.example.com, и DNS-провайдер (Route 53 latency-based routing, GeoDNS в Cloudflare, NS1 и т.д.) возвращает IP ближайшего origin - скажем, сиднейский экземпляр вашего сервиса редиректа.

Архитектура:

Client (Сидней) ──DNS-запрос── Авторитетный DNS
       │                            │
       │  возвращает IP сиднейского pod'а  │
       ↓
   Сиднейский origin ──redirect 302──→ Client

DNS-провайдер не видит фактический HTTP-запрос. Он видит только запрос резолвера - а этот резолвер может быть в другой стране, и тогда «ближайший» становится предположением. Сам HTTP-запрос - это один round-trip к выбранному origin.

Стоимость round-trip. Быстрейший путь - одно TCP-рукопожатие + один HTTP-обмен до ближайшего origin. Если ближайший origin в 40 мс (Сидней → локальный для Сиднея), редирект резолвится за ~60-80 мс по настенным часам (рукопожатие + запрос + ответ).

Режим отказа. Когда выбранный origin падает, TTL DNS становится узким местом. TTL 60 секунд означает, что клиентам может потребоваться до минуты, чтобы обнаружить отказ и повторить попытку с другим IP. Частота проверки работоспособности у DNS-провайдера определяет фактическое окно восстановления.

Что на самом деле означает «маршрутизация edge POP»

Маршрутизация edge POP размещает флот кеш-серверов во многих регионах, все они отвечают на один и тот же anycast IP. Первый пакет клиента на этот IP маршрутизируется BGP к топологически ближайшему POP - не ближайшему в географическом смысле, а ближайшему в сетевом (наименьшее количество переходов через маршрутизаторы, наименьшая измеренная задержка).

Архитектура:

Client (Сидней) ──пакет на anycast IP── BGP-ближайший POP (Сингапур)
                                              │
                                  Попадание в кеш? ответить 302
                                              │
                                  Промах кеша → origin (Франкфурт)
                                  Кеш → ответить 302

BGP-ближайший POP отдаёт редирект из кеша. Попадания в кеш полностью минуют origin. Промахи кеша редки (первый промах горячей ссылки после деплоя; деплой инвалидирует одну строку на slug, а не весь кеш).

Стоимость round-trip. Попадание в кеш отвечает за 5-15 мс по настенным часам (TCP-рукопожатие до локального POP, немедленный ответ). Промах кеша добавляет ~80-150 мс межконтинентального round-trip до origin - но этот round-trip происходит один раз, затем строка кешируется на POP для следующего запроса.

Режим отказа. Когда POP падает, BGP отзывает префикс. Следующий пакет клиента автоматически идёт к следующему ближайшему POP. Восстановление - меньше секунды, а не меньше минуты.

Четыре числа, определяющие подходящую архитектуру

1. Количество ваших origin. Если у вас один origin (однорегиональный деплой), DNS-маршрутизация не поможет - маршрутизировать не между чем. Anycast POP добавляют ценность, фронтируя одиночный origin кешами.

2. Ваш коэффициент попадания в кеш. Edge POP быстры только когда отвечает кеш. Сокращатели URL имеют коэффициент попаданий в диапазоне 95%+ - карта slug↔назначение невелика и преимущественно читается. Если коэффициент попаданий вашей нагрузки ниже 50%, edge POP деградируют до «лишнего хопа перед origin», и DNS-маршрутизация является более чистой архитектурой.

3. Ваш географический охват. Если 90%+ ваших пользователей из одной страны, обе архитектуры работают схоже - один origin в этой стране уже в <30 мс от всех. Если ваши пользователи распределены по континентам, архитектура edge POP начинает выигрывать. Пользователь из Сиднея, обращающийся к origin только во Франкфурте через DNS-маршрутизацию, платит межконтинентальный RTT (~180-220 мс TCP-рукопожатие) при каждом редиректе. С edge POP в Сингапуре тот же пользователь платит ~25 мс.

4. Ваша терпимость к отказу при медленном распространении. Восстановление на основе DNS ограничено TTL-кешированием у самого медленного резолвера. Некоторые резолверы не соблюдают низкие TTL; они устанавливают минимальный TTL от 60 до 300 секунд. Если вашему сокращателю URL иногда нужно отключить origin (деплой, обслуживание, отказ региона), DNS-маршрутизация оставляет длинный хвост клиентов на мёртвом origin. Anycast отзывает за долю секунды.

Наложим четыре числа на типичную нагрузку сокращателя URL:

• Количество origin: как правило 2-3 (мультирегион для отказоустойчивости)
• Коэффициент попадания в кеш: 95-99% (карта slug невелика)
• Географический охват: как правило мультиконтинентальный (любой потребительский бренд)
• Терпимость к отказу: нулевая (ссылка в печатных материалах; простой стоит доверия)

Все четыре указывают на edge POP. Архитектура DNS-only больше подходит для внутренних B2B SaaS инструментов, где поверхность редиректов регионально ограничена, а карта slug часто меняется (больше инвалидаций кеша, чем чтений).

Как выглядят цифры задержки на практике

Мы протестировали обе архитектуры из четырёх локаций с одинаковой нагрузкой (одна короткая ссылка, холодный кеш затем тёплый). Числа ниже - p50 / p95 из 1000 последовательных запросов на локацию.

DNS-only маршрутизация (один origin во Франкфурте, GeoDNS маршрутизация):

Расположение origin	Клиент → Франкфурт	p50	p95
Франкфурт	<1 мс	4 мс	9 мс
Лондон	14 мс	22 мс	35 мс
Нью-Йорк	90 мс	110 мс	145 мс
Сингапур	165 мс	195 мс	240 мс

Маршрутизация edge POP (anycast через FRA, ASH, SGP), попадание в кеш:

Расположение клиента	Маршрут к POP	p50	p95
Франкфурт	FRA	3 мс	7 мс
Лондон	FRA	11 мс	18 мс
Нью-Йорк	ASH	5 мс	9 мс
Сингапур	SGP	4 мс	8 мс

Разрыв проявляется на удалённых локациях. Франкфурт выглядит схоже в обоих случаях, потому что он и есть origin в случае DNS-only. Сингапур - самый показательный: 195 мс p50 против 4 мс p50, потому что архитектура edge POP отвечает прямо из Сингапура. Архитектура DNS-only платит межконтинентальный round-trip при каждом редиректе, независимо от кеширования.

Компромисс по стоимости

Edge POP дороже на редирект при малом объёме. Фиксированная стоимость запуска POP - даже небольшого на боксе Hetzner Falkenstein - реальна. При <100k редиректов/месяц DNS-only маршрутизация против одного origin дешевле.

Точка перехода находится около 1M редиректов/месяц. Выше неё архитектура edge POP выигрывает по стоимости одного редиректа, потому что ответы при попадании в кеш не касаются вычислительных ресурсов origin или пропускной способности. Origin масштабируется для заполнения кеша (~1% запросов), а не для всего объёма запросов.

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

Что edge POP не исправляет

Edge POP - не универсальное улучшение. Три нагрузки, при которых они замедляют, а не ускоряют:

1. Записи. Создание новой ссылки, обновление назначения - всё это должно приземляться на авторитетный origin, а затем распространяться на слой инвалидации кеша. Задержка чтения отличная; задержка записи примерно такая же, как на пути только через origin.

2. Персонализированные редиректы. Смарт-ссылки, которые маршрутизируют по идентификатору пользователя (а не только по slug), не могут быть кешированы на POP - им нужно попадать на origin каждый раз для чтения профиля пользователя. POP становится тонким TLS-терминационным прокси, добавляя 5-10 мс к тому, что иначе было бы прямым обращением к origin. Для большинства сокращателей URL это нормально, потому что персонализированные редиректы - небольшое меньшинство трафика. Для deep-link продуктов (Branch, Adjust) уровень персонализации ближе к 50%, что меняет математику архитектуры.

3. Гео-ограниченные назначения. Если назначение редиректа меняется в зависимости от географии пользователя (разные лендинги для разных стран), ключ кеша должен включать страну. Это фрагментирует кеш - вместо одной строки на slug появляется N строк на slug для N поддерживаемых стран. Коэффициент попадания в кеш падает; стоимость памяти кеша растёт. POP всё равно помогают, просто меньше.

Для сокращателей URL третий случай требует внимания. Большинство коротких ссылок резолвятся в один URL независимо от географии пользователя, поэтому один ключ кеша работает. Но как только добавляются варианты по странам, уравнение стоимости меняется.

Как это реализовано в Elido

Три POP (Hetzner Falkenstein, Hetzner Ashburn, OVH Singapore), anycast через /24 в нашем распоряжении. Caddy на edge для TLS + сертификаты по требованию; fasthttp за Caddy для самого редиректа. Двухуровневый кеш: in-process LRU (L1, ~10k самых горячих slug в памяти) → Redis Cluster (L2, полный набор slug). Промах кеша проваливается до gRPC endpoint api-core, который читает из Postgres.

Цикл заполнения кеша: любое обновление назначения ссылки публикует событие инвалидации в Redpanda. Edge POP подписываются и удаляют свою L1-запись для затронутого slug. Следующий запрос к этому slug попадает в L2 (ещё тёплый), наполняет L1. Задержка инвалидации p95 - ~120 мс по трём POP.

Эта архитектура подробно описана в посте redirect p95 < 15 мс. Архитектурный документ на /docs/architecture/edge-redirect содержит полную диаграмму.

Дерево решений

Краткий чеклист для выбора между DNS-only и архитектурами edge POP:

• Однострановая база пользователей + один origin? DNS-only подойдёт. Не усложняйте.
• Мультистрановые пользователи + высокий коэффициент попадания в кеш? Edge POP. Выигрыш по задержке резкий на удалённых локациях.
• Мультистрановые пользователи + персонализированные редиректы на >50% трафика? Смешанно. POP помогают с TLS-терминацией, но не с самим редиректом. Рассмотрите DNS-маршрутизацию + небольшой флот POP только для SSL-терминации.
• Жёсткий SLA по скорости переключения при отказе? Edge POP выигрывают - BGP отзыв превосходит TTL-кеширование DNS на порядки.
• Менее 1M редиректов/месяц? DNS-only дешевле. Переоцените при 1M+.

Универсального ответа нет. Сокращатели URL в частности обычно попадают в категорию «мультистрановые + высокий коэффициент попадания в кеш + жёсткий SLA по переключению при отказе», вот почему большинство production сокращателей URL в конечном итоге переходят на архитектуру edge POP. Стоимость перехода (реархитектура заполнения кеша, выбор POP провайдеров, настройка BGP) реальна, но ограничена.

По теме в блоге

• Достижение p95 < 15 мс для редиректов из Франкфурта, Эшберна и Сингапура - ключевой материал с операционными деталями
• Стратегия кеширования для URL-редиректов: что вытеснять и когда - архитектура двухуровневого кеша L1/L2
• Fire-and-forget приём кликов - что происходит на пути редиректа, что не является поиском в кеше
• Почему ClickHouse для аналитики кликов (а не Postgres) - аналитическая сторона той же архитектуры
• Короткие ссылки как Terraform: инженерный ключевой материал - IaC для управления edge-конфигурацией