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 (Sydney) ──DNS query── Authoritative DNS
       │                            │
       │  returns IP of Sydney pod  │
       ↓
   Sydney origin ──redirect 302──→ Client

DNS-провайдер не бачить фактичного HTTP-запиту. Він бачить лише запит резолвера - а цей резолвер може бути в іншій країні, і тоді «найближчий» стає здогадом. Сам HTTP-запит - це один round trip до обраного origin.

Вартість round trip. Найшвидший шлях - один TCP-хендшейк + один HTTP-обмін до найближчого origin. Якщо найближчий origin знаходиться на відстані 40мс (Сідней → місцевий Сідней), редирект розв'язується за ~60-80мс wall-clock (хендшейк + запит + відповідь).

Режим відмови. Коли обраний origin недоступний, TTL DNS стають вузьким місцем. TTL в 60 секунд означає, що клієнтам може знадобитися до хвилини для виявлення відмови і повторної спроби з іншим IP. Каденція health-check DNS-провайдера визначає реальне вікно відновлення.

Що насправді означає «маршрутизація через edge POP»

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

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

Client (Sydney) ──packet to anycast IP── BGP-nearest POP (Singapore)
                                              │
                                  Cache hit? respond 302
                                              │
                                  Cache miss → origin (Frankfurt)
                                  Cache → respond 302

BGP-найближчий POP обслуговує редирект з кешу. Cache hit пропускає origin повністю. Cache miss трапляється рідко (перший miss для гарячого посилання після деплою; деплой анулює один рядок на slug, а не весь кеш).

Вартість round trip. Cache hit відповідає за 5-15мс wall-clock (TCP-хендшейк до місцевого POP, миттєва відповідь). Cache miss додає ~80-150мс міжконтинентальний round trip до origin - але цей round trip відбувається один раз, після чого рядок кешується в POP для наступного запиту.

Режим відмови. Коли POP виходить з ладу, BGP відкликає префікс. Наступний пакет клієнта автоматично спрямовується до наступного найближчого POP. Відновлення - менш ніж за секунду, а не менш ніж за хвилину.

Чотири числа, що визначають, яка архітектура підходить

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

2. Ваш cache hit ratio. Edge POP швидкі лише тоді, коли кеш відповідає. URL-скорочувачі мають hit ratio 95%+: карта slug→призначення мала і переважно для читання. Якщо hit ratio вашого навантаження нижче 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 (мультирегіон для надлишковості)
• Cache hit ratio: 95-99% (карта slug мала)
• Географічний розподіл: зазвичай мультиконтинент (будь-який споживчий бренд)
• Толерантність до відмов: нульова (посилання в друкованих матеріалах; простої коштують довіри)

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

Як виглядають числа затримки насправді

Ми порівняли обидві архітектури з чотирьох локацій при однаковому навантаженні (одне коротке посилання, спочатку cold-cache, потім warm-cache). Числа нижче - 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), cache HIT:

Локація клієнта	Маршрут до 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 виграє за ціною за редирект, тому що cache-hit відповіді не торкаються обчислень origin або пропускної здатності origin. Origin масштабується для cache fill (~1% запитів), а не для повного обсягу запитів.

Більшість URL-скорочувачів перебувають вище точки перехину з першого дня, тому що розподіл навантаження має важкий хвіст - кілька гарячих посилань несуть більшість обсягу кліків, і ці посилання мають фактично нескінченний cache hit ratio.

Що edge POP не виправляють

Edge POP - не універсальне покращення. Три навантаження, які вони роблять повільнішими, а не швидшими:

1. Записи. Створення нового посилання, оновлення призначення - все це має потрапити до авторитетного origin, а потім поширитися на рівень анулювання кешу. Затримка читання чудова; затримка запису приблизно така сама, як і шлях лише через origin.

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

3. Геообмежені призначення. Якщо призначення редиректу змінюється за географією користувача (різний лендінг для кожної країни) - ключ кешу має включати країну. Це фрагментує кеш: замість одного рядка на slug - N рядків на slug для N підтримуваних країн. Cache hit ratio падає; вартість пам'яті кешу зростає. POP все одно допомагають, просто менше.

Для URL-скорочувачів третій випадок є тим, за яким слід стежити. Більшість коротких посилань розв'язується до одного URL незалежно від гео користувача, тому один ключ кешу працює. Але як тільки ви додаєте варіанти для кожної країни - рівняння вартості змінюється.

Як це реалізує Elido

Три POP (Hetzner Falkenstein, Hetzner Ashburn, OVH Singapore), anycast через наш /24. Caddy на edge для TLS + on-demand сертифікатів; fasthttp за Caddy для самого редиректу. Дворівневий кеш: in-process LRU (L1, ~10k найгарячіших slug в пам'яті) → Redis Cluster (L2, повний набір slug). Cache miss падає на gRPC ендпоінт 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 цілком підходить. Не ускладнюйте.
• Мультикраїнні користувачі + високий cache hit ratio? Edge POP. Виграш у затримці драматичний на локаціях з довгим хвостом.
• Мультикраїнні користувачі + персоналізовані редиректи на >50% трафіку? Змішано. POP допомагають з TLS-termination, але не з самим редиректом. Розгляньте DNS-маршрутизацію + малий флот POP лише для SSL-termination.
• Суворий SLA на швидкість відновлення після відмови? Виграють edge POP - відклик BGP перевершує TTL-кешування DNS на порядки.
• Менше 1M редиректів/місяць? DNS-only дешевший. Перегляньте при 1M+.

Немає єдино правильної відповіді для всіх. URL-скорочувачі зокрема зазвичай вписуються в сегмент «мультикраїна + високий cache hit ratio + суворий SLA на відновлення після відмови», саме тому більшість production URL-скорочувачів з часом переходять на архітектуру edge POP. Вартість переходу (переархітектурування cache fill, вибір провайдерів POP, налаштування BGP) реальна, але обмежена.

Пов'язані матеріали в блозі

• Досягнення p95 < 15мс для редиректів з Франкфурта, Ашберна і Сінгапуру - опорний матеріал з операційними деталями
• Стратегія кешування для URL-редиректів: що виштовхувати і коли - архітектура кешу L1/L2
• Fire-and-forget інгестія кліків - що відбувається на шляху редиректу, що не є пошуком у кеші
• Чому ClickHouse для аналітики кліків (а не Postgres) - аналітична сторона тієї самої архітектури
• Short links as Terraform: інженерний опорний матеріал - IaC для управління edge-конфігурацією