Edge POP vs routing DNS-only: kompromis budżetu opóźnienia

Budżet opóźnienia dla przekierowania URL ma dwa reżimy. Poniżej ~50ms p50 jesteś w strefie edge-POP - anycast kieruje użytkownika do pobliskiej pamięci podręcznej, przekierowanie odpowiada, zanim TCP handshake zdąży stać się odczuwalny. Powyżej ~50ms jesteś w strefie DNS-only - DNS-based load-balancing kieruje klienta podczas rozwiązywania nazwy, przekierowanie to jeden cross-kontynentalny round trip TCP, a budżet ten round trip obejmuje. Architektury wyglądają powierzchownie podobnie (obie serwują 302). Obwiednie wydajności nie są takie same. Ten post to porównanie.

Dla cornerstonowego wpisu o budżecie opóźnienia, osiągnięcie p95 < 15ms dla przekierowań to pogłębiona lektura. Ten post to decyzja architektoniczna za nim stojąca.

Co tak naprawdę oznacza "routing DNS-only"

Routing DNS-only odpowiada na pytanie "które origin powinno obsłużyć tego klienta?" przez rozwiązanie DNS, a nie ścieżkę TCP. Użytkownik w Sydney rozwiązuje r.example.com i dostawca DNS (Route 53 latency-based routing, GeoDNS w Cloudflare, NS1 itp.) zwraca IP najbliższego originu - powiedzmy, sydnejskiej instancji serwisu przekierowania.

Architektura:

Klient (Sydney) ──zapytanie DNS── Autorytatywny DNS
       │                                 │
       │  zwraca IP poda Sydney          │
       ↓
   Origin Sydney ──redirect 302──→ Klient

Dostawca DNS nie widzi rzeczywistego żądania HTTP. Widzi tylko zapytanie resolvera - a ten resolver może być o kraj dalej, w którym to przypadku "najbliższy" staje się zgadywaniem. Samo żądanie HTTP to jeden round trip do wybranego originu.

Koszt round trip. Najszybsza ścieżka to jeden TCP handshake + jedna wymiana HTTP do najbliższego originu. Jeśli najbliższy origin jest 40ms stąd (Sydney - lokalny Sydney), przekierowanie rozwiązuje się w ~60-80ms czasu zegarowego (handshake + żądanie + odpowiedź).

Tryb awarii. Gdy wybrany origin jest niedostępny, TTL-e DNS stają się wąskim gardłem. 60-sekundowy TTL oznacza, że klienci mogą potrzebować do minuty, aby wykryć awarię i ponowić próbę z innym IP. Częstotliwość health-checku dostawcy DNS wyznacza rzeczywiste okno odzyskiwania.

Co tak naprawdę oznacza "routing edge POP"

Routing edge POP stawia flotę serwerów cache w wielu regionach, wszystkich odpowiadających na tym samym anycastowym IP. Pierwszy pakiet klienta do tego IP jest kierowany przez BGP do topologicznie najbliższego POP - nie najbliższego geograficznie, ale najbliższego w sensie sieciowym (najmniej przeskoków routera, najniższe mierzone opóźnienie).

Architektura:

Klient (Sydney) ──pakiet na anycast IP── BGP-najbliższy POP (Singapur)
                                              │
                                  Cache hit? odpowiedź 302
                                              │
                                  Cache miss → origin (Frankfurt)
                                  Cache → odpowiedź 302

BGP-najbliższy POP serwuje przekierowanie z pamięci podręcznej. Cache hity omijają origin całkowicie. Cache missy są rzadkie (pierwsze chybienie gorącego linku po deployu; deploy unieważnia jeden wiersz per slug, nie cały cache).

Koszt round trip. Cache hit odpowiada w 5-15ms czasu zegarowego (TCP handshake do lokalnego POP, natychmiastowa odpowiedź). Cache miss dodaje ~80-150ms cross-kontynentalny round trip do originu - ale ten round trip dzieje się raz, potem wiersz jest buforowany w POP dla kolejnego żądania.

Tryb awarii. Gdy POP zawodzi, BGP wycofuje prefiks. Następny pakiet klienta automatycznie trafia do kolejnego najbliższego POP. Odzysk trwa poniżej sekundy, nie poniżej minuty.

Cztery liczby decydujące o tym, która architektura pasuje

1. Liczba originów. Jeśli masz jeden origin (deploy jednoregionu), routing DNS nie może pomóc - nie ma między czym kierować. Anycastowe POP dodają wartość, frontując pojedynczy origin z pamięciami podręcznymi.

2. Twój wskaźnik trafień cache. Edge POP są szybkie tylko wtedy, gdy odpowiada cache. Skracacze URL mają wskaźniki trafień 95%+ - mapa slug-cel jest mała i zdominowana przez odczyty. Jeśli wskaźnik trafień Twojego workloadu spada poniżej 50%, edge POP degraduje się do "dodatkowy hop przed originem", a routing DNS to czystsza architektura.

3. Twoje rozłożenie geograficzne. Jeśli 90%+ Twoich użytkowników jest w jednym kraju, obie architektury działają podobnie - jeden origin w tym kraju jest już <30ms od każdego. Jeśli Twoi użytkownicy są rozłożeni na kilka kontynentów, architektura edge POP zaczyna wygrywać. Użytkownik w Sydney trafiający na origin tylko we Frankfurcie przez routing DNS płaci cross-kontynentalny RTT (~180-220ms TCP handshake) przy każdym przekierowaniu. Z edge POP w Singapurze ten sam użytkownik płaci ~25ms.

4. Tolerancja na powolną propagację przy awarii. Odzysk oparty na DNS jest ograniczony przez buforowanie TTL najwolniejszego resolvera. Niektóre resolvery nie respektują niskich TTL-i; ograniczają minimalny TTL do 60 lub 300 sekund. Jeśli Twój skracacz URL okazjonalnie wymaga wyłączenia originu (deploy, maintenance, awaria regionu), routing DNS pozostawia długi ogon klientów na martwym originie. Anycast wycofuje się w czasie poniżej sekundy.

Porównaj cztery liczby z typowym workloadem skracacza URL:

• Liczba originów: zazwyczaj 2-3 (multi-region dla redundancji)
• Wskaźnik trafień cache: 95-99% (mapa slug-cel jest mała)
• Rozłożenie geograficzne: zazwyczaj multi-kontynentalne (każda marka skierowana do konsumentów)
• Tolerancja awarii: zerowa (link jest w materiałach drukowanych; czas awarii kosztuje zaufanie)

Wszystkie cztery wskazują na edge POP. Architektura DNS-only jest bardziej odpowiednia dla wewnętrznych narzędzi B2B SaaS, gdzie powierzchnia przekierowań jest regionalna, a mapa slug-cel często się zmienia (więcej unieważnień cache niż odczytów).

Jak wyglądają liczby opóźnienia

Przeprowadziliśmy benchmark obu architektur z czterech lokalizacji wobec tego samego workloadu (pojedynczy krótki link, zimny cache a potem ciepły cache). Liczby poniżej to p50 / p95 z 1000 kolejnych żądań per lokalizacja.

Routing DNS-only (pojedynczy origin we Frankfurcie, routing GeoDNS):

Lokalizacja originu	Klient - Frankfurt	p50	p95
Frankfurt	<1ms	4ms	9ms
Londyn	14ms	22ms	35ms
Nowy Jork	90ms	110ms	145ms
Singapur	165ms	195ms	240ms

Routing edge POP (anycast przez FRA, ASH, SGP), cache HIT:

Lokalizacja klienta	Trasa do POP	p50	p95
Frankfurt	FRA	3ms	7ms
Londyn	FRA	11ms	18ms
Nowy Jork	ASH	5ms	9ms
Singapur	SGP	4ms	8ms

Różnica widoczna jest w lokalizacjach na długim ogonie. Frankfurt wygląda podobnie w obu, ponieważ jest originem w przypadku DNS-only. Singapur jest dramatyczny: 195ms p50 do 4ms p50, ponieważ architektura edge POP odpowiada bezpośrednio z Singapuru. Architektura DNS-only płaci cross-kontynentalny round trip przy każdym przekierowaniu, bez względu na buforowanie.

Kompromis kosztowy

Edge POP kosztuje więcej per przekierowanie przy małym wolumenie. Stały koszt prowadzenia POP - nawet małego na maszynie Hetzner Falkenstein - jest realny. Przy <100 tys. przekierowań miesięcznie, routing DNS-only przeciwko jednemu originowi jest tańszy.

Punkt przecięcia to około 1 mln przekierowań miesięcznie. Powyżej tego architektura edge POP wygrywa w koszcie per przekierowanie, ponieważ odpowiedzi cache-hit nie dotykają compute originu ani pasma originu. Origin skaluje się do wypełnień cache (~1% żądań) zamiast do pełnego wolumenu żądań.

Większość skracaczy URL przekracza próg od pierwszego dnia, ponieważ rozkład workloadu jest heavy-tailed - kilka gorących linków niesie większość wolumenu kliknięć, a te linki mają efektywnie nieskończony wskaźnik trafień cache.

Czego edge POP nie naprawia

Edge POP nie są uniwersalnym ulepszeniem. Trzy workloady, które spowalniają, a nie przyspieszają:

1. Zapisy. Tworzenie nowego linku, aktualizowanie celu - muszą trafić do autorytatywnego originu, a następnie propagować się do warstwy unieważniania cache. Opóźnienie odczytu jest świetne; opóźnienie zapisu jest mniej więcej takie samo jak ścieżka tylko-origin.

2. Spersonalizowane przekierowania. Smart linki, które kierują na podstawie tożsamości użytkownika (nie tylko sluga) nie mogą być buforowane w POP - muszą trafiać do originu za każdym razem, aby odczytać profil użytkownika. POP staje się cienkim proxy terminowania TLS, dodającym 5-10ms do tego, co w przeciwnym razie byłoby bezpośrednim trafieniem do originu. Dla większości skracaczy URL jest to w porządku, ponieważ spersonalizowane przekierowania to mały ułamek ruchu. Dla produktów deep-link (Branch, Adjust), wskaźnik personalizacji jest bliższy 50%, co zmienia rachunek architektoniczny.

3. Geograficznie ograniczone cele. Jeśli cel przekierowania zmienia się według geografii użytkownika (różne strony docelowe per kraj), klucz cache musi zawierać kraj. To fragmentuje cache - zamiast jednego wiersza per slug masz N wierszy per slug dla N obsługiwanych krajów. Wskaźnik trafień cache spada; koszt pamięci cache rośnie. POP nadal pomagają, tylko mniej.

Dla skracaczy URL, trzeci przypadek jest tym, na który należy uważać. Większość krótkich linków rozwiązuje się do jednego URL niezależnie od geo użytkownika, więc jeden klucz cache działa. Ale gdy dodasz warianty per kraj, równanie kosztów się zmienia.

Jak Elido to robi

Trzy POP (Hetzner Falkenstein, Hetzner Ashburn, OVH Singapur), anycast przez /24, który posiadamy. Caddy na edge dla TLS + certyfikaty on-demand; fasthttp za Caddy dla samego przekierowania. Dwupoziomowy cache: in-process LRU (L1, ~10 tys. najgorętszych slugów w pamięci) - Redis Cluster (L2, pełny zestaw slugów). Cache miss spada przez do endpointu gRPC api-core, który czyta z Postgres.

Cykl wypełniania cache: każda aktualizacja celu linku publikuje zdarzenie unieważnienia na Redpanda. Edge POP subskrybuje i usuwa swój wpis L1 dla dotkniętego sluga. Następne żądanie do tego sluga trafia do L2 (nadal ciepłe), wypełnia L1. Opóźnienie unieważnienia p95 wynosi ~120ms we wszystkich trzech POP.

Ta architektura to post redirect p95 < 15ms cornerstone w szczegółach operacyjnych. Dokument architektury pod adresem /docs/architecture/edge-redirect zawiera pełny diagram.

Drzewo decyzyjne

Krótka lista kontrolna przy wyborze między architekturami DNS-only i edge POP:

• Baza użytkowników w jednym kraju + jeden origin? DNS-only jest w porządku. Nie nadmiernie inżynieruj.
• Użytkownicy w wielu krajach + wysoki wskaźnik trafień cache? Edge POP. Zysk opóźnienia jest dramatyczny w lokalizacjach na długim ogonie.
• Użytkownicy w wielu krajach + spersonalizowane przekierowania dla >50% ruchu? Mieszane. POP pomagają z terminowaniem TLS, ale nie z samym przekierowaniem. Rozważ routing DNS + mała flota POP tylko do terminowania SSL.
• Rygorystyczne SLA dotyczące szybkości failover? Edge POP wygrywają - wycofanie BGP bije buforowanie TTL DNS o rzędy wielkości.
• Poniżej 1 mln przekierowań miesięcznie? DNS-only jest tańsze. Oceń ponownie przy 1 mln+.

Nie ma jednej odpowiedzi pasującej do wszystkich. Skracacze URL konkretnie tendencyjnie pasują do segmentu "multi-kraj + wysoki wskaźnik trafień cache + rygorystyczne SLA failover", dlatego większość produkcyjnych skracaczy URL ostatecznie przechodzi na architekturę edge POP. Koszt przejścia (re-architektura wypełniania cache, wybór dostawców POP, konfiguracja BGP) jest realny, ale ograniczony.

Powiązane na blogu

• Osiągnięcie p95 < 15ms dla przekierowań z Frankfurtu, Ashburn i Singapuru - cornerstone, ze szczegółami operacyjnymi
• Strategia cache dla przekierowań URL: co usuwać i kiedy - architektura cache L1/L2
• Asynchroniczne przechwytywanie kliknięć - co dzieje się na ścieżce przekierowania, co nie jest sprawdzeniem cache
• Dlaczego ClickHouse dla analityki kliknięć (a nie Postgres) - strona analityczna tej samej architektury
• Krótkie linki jako Terraform: cornerstone inżynieryjny - IaC do zarządzania konfiguracją edge