Edge POPs vs routage DNS uniquement : le compromis de budget de latence

Le budget de latence pour une redirection d'URL a deux régimes. En dessous de ~50 ms p50, vous êtes dans le territoire des edge POPs - l'anycast route l'utilisateur vers un cache proche, la redirection répond avant que la négociation TCP ne devienne coûteuse. Au-dessus de ~50 ms, vous êtes dans le territoire DNS uniquement - l'équilibrage de charge basé sur le DNS route le client au moment de la résolution de nom, la redirection est un aller-retour TCP intercontinental, et le budget inclut cet aller-retour. Les architectures se ressemblent superficiellement (les deux servent un 302). Les enveloppes de performance ne sont pas les mêmes. Ce post est la comparaison.

Pour l'article de référence sur le budget de latence, atteindre p95 < 15 ms pour les redirections est la lecture longue. Ce post traite de la décision architecturale qui le sous-tend.

Ce que signifie réellement le "routage DNS uniquement"

Le routage DNS uniquement répond à la question "quelle origine ce client doit-il atteindre ?" par la résolution DNS, pas par le chemin TCP. Un utilisateur à Sydney résout r.example.com et le fournisseur DNS (routage basé sur la latence Route 53, GeoDNS chez Cloudflare, NS1, etc.) renvoie l'IP de l'origine la plus proche - par exemple, l'instance Sydney de votre service de redirection.

L'architecture :

Client (Sydney) ──requête DNS── DNS faisant autorité
       │                            │
       │  renvoie l'IP du pod Sydney │
       ↓
   Origine Sydney ──redirection 302──→ Client

Le fournisseur DNS ne voit pas la requête HTTP réelle. Il ne voit que la requête de résolveur - et ce résolveur pourrait se trouver dans un pays voisin, auquel cas "le plus proche" devient une approximation. La requête HTTP elle-même est un aller-retour vers l'origine choisie.

Coût de l'aller-retour. Le chemin le plus rapide est une négociation TCP + un échange HTTP vers l'origine la plus proche. Si l'origine la plus proche est à 40 ms (Sydney vers Sydney local), la redirection se résout en ~60-80 ms d'horloge (négociation + requête + réponse).

Mode de défaillance. Quand l'origine choisie est hors service, les TTL DNS deviennent le goulot d'étranglement. Un TTL de 60 secondes signifie que les clients peuvent prendre jusqu'à une minute pour découvrir la défaillance et réessayer avec une IP différente. La cadence de vérification d'état du fournisseur DNS fixe la fenêtre de récupération réelle.

Ce que signifie réellement le "routage edge POP"

Le routage edge POP place une flotte de serveurs de cache dans plusieurs régions, tous répondant sur la même IP anycast. Le premier paquet du client vers cette IP est routé par BGP vers le POP topologiquement le plus proche - pas le plus proche en distance géographique, mais le plus proche au sens réseau (moins de sauts routeurs, latence mesurée la plus faible).

L'architecture :

Client (Sydney) ──paquet vers IP anycast── POP BGP-le-plus-proche (Singapore)
                                              │
                                  Cache hit ? répondre 302
                                              │
                                  Cache miss → origine (Frankfurt)
                                  Cache → répondre 302

Le POP BGP le plus proche sert la redirection depuis le cache. Les hits de cache contournent totalement l'origine. Les misses de cache sont peu fréquents (le premier miss d'un lien populaire après déploiement ; le déploiement invalide une ligne par slug, pas l'ensemble du cache).

Coût de l'aller-retour. Un hit de cache répond en 5-15 ms d'horloge (négociation TCP vers le POP local, réponse immédiate). Un miss de cache ajoute un aller-retour intercontinental de ~80-150 ms vers l'origine - mais cet aller-retour se produit une fois, puis la ligne est mise en cache au POP pour la requête suivante.

Mode de défaillance. Quand un POP tombe en panne, BGP retire le préfixe. Le paquet suivant du client va automatiquement vers le POP le plus proche suivant. La récupération est en sous-seconde, pas en sous-minute.

Diagramme d'architecture côte à côte : le routage DNS uniquement envoie un client Sydney effectuer un aller-retour intercontinental vers une seule origine à Francfort, tandis que le routage edge POP répond depuis un cache BGP à Singapore le plus proche en environ 25 ms.

Les quatre chiffres qui déterminent quelle architecture convient

Le nombre d'origines. Si vous avez une seule origine (déploiement en région unique), le routage DNS ne peut pas aider - il n'y a rien entre quoi router. Les POPs anycast apportent de la valeur en frontalisant la seule origine avec des caches.
Votre taux de hit de cache. Les edge POPs ne sont rapides que quand le cache répond. Les raccourcisseurs d'URL ont des taux de hit de 95 % ou plus - la table slug-vers-destination est petite et dominée par les lectures. Si le taux de hit de votre charge de travail est inférieur à 50 %, les edge POPs se dégradent en "saut supplémentaire avant l'origine", et le routage DNS est l'architecture plus propre.
Votre dispersion géographique. Si vos utilisateurs sont à 90 % ou plus dans un seul pays, les deux architectures ont des performances similaires - une seule origine dans ce pays est déjà à moins de 30 ms de tout le monde. Si vos utilisateurs sont répartis sur plusieurs continents, l'architecture edge POP commence à gagner. Un utilisateur à Sydney qui atteint une origine uniquement à Francfort via le routage DNS paie l'aller-retour intercontinental (~180-220 ms de négociation TCP) sur chaque redirection. Avec un edge POP à Singapore, ce même utilisateur paie ~25 ms.
Votre tolérance aux défaillances face à la propagation lente. La récupération basée sur DNS est limitée par le cache TTL du résolveur le plus lent. Certains résolveurs ne respectent pas les TTL bas ; ils plafonnent le TTL minimum à 60 ou 300 secondes. Si votre raccourcisseur d'URL doit occasionnellement mettre une origine hors ligne (déploiement, maintenance, région hors service), le routage DNS laisse une longue traîne de clients sur l'origine morte. L'anycast se retire en sous-seconde.

Projetez les quatre chiffres sur une charge de travail typique de raccourcisseur d'URL :

Nombre d'origines : généralement 2-3 (multi-région pour la redondance)
Taux de hit de cache : 95-99 % (la table slug est petite)
Dispersion géographique : généralement multi-continentale (toute marque grand public)
Tolérance aux défaillances : zéro (le lien est dans des supports imprimés ; les temps d'arrêt coûtent de la confiance)

Les quatre poussent vers les edge POPs. L'architecture DNS uniquement est plus appropriée pour les outils internes B2B SaaS où la surface de redirection est régionale et la table slug change fréquemment (plus d'invalidations de cache que de lectures).

À quoi ressemblent réellement les chiffres de latence

Nous avons évalué les deux architectures depuis quatre emplacements sur la même charge de travail (lien court unique, cache froid puis cache chaud). Les chiffres ci-dessous sont p50 / p95 pour 1 000 requêtes séquentielles par emplacement.

Routage DNS uniquement (origine unique à Francfort, routage GeoDNS) :

Emplacement de l'origine	Client vers Frankfurt	p50	p95
Frankfurt	<1 ms	4 ms	9 ms
London	14 ms	22 ms	35 ms
New York	90 ms	110 ms	145 ms
Singapore	165 ms	195 ms	240 ms

Routage edge POP (anycast sur FRA, ASH, SGP), cache HIT :

Emplacement du client	Route vers POP	p50	p95
Frankfurt	FRA	3 ms	7 ms
London	FRA	11 ms	18 ms
New York	ASH	5 ms	9 ms
Singapore	SGP	4 ms	8 ms

L'écart se situe aux emplacements à longue traîne. Francfort semble similaire dans les deux cas parce que c'est l'origine dans le cas DNS uniquement. Singapore est le cas spectaculaire : 195 ms p50 contre 4 ms p50, parce que l'architecture edge POP répond depuis Singapore directement. L'architecture DNS uniquement paie l'aller-retour intercontinental sur chaque redirection, quelle que soit la mise en cache.

Graphique à barres horizontales de la latence p50 de redirection par emplacement client, montrant le routage DNS uniquement et le routage edge POP à égalité à Francfort mais divergeant à 195 ms versus 4 ms à Singapore.

Le compromis de coût

Les edge POPs coûtent plus cher par redirection à faible volume. Le coût fixe de faire tourner un POP - même un petit sur une machine Hetzner Falkenstein - est réel. En dessous de 100 000 redirections/mois, le routage DNS uniquement vers une seule origine est moins cher.

Le point de croisement se situe autour de 1 million de redirections/mois. Au-delà, l'architecture edge POP gagne sur le coût par redirection parce que les réponses via hit de cache ne touchent pas les ressources de calcul ou la bande passante de l'origine. L'origine s'adapte pour les remplissages de cache (~1 % des requêtes) plutôt que pour le volume total de requêtes.

La plupart des raccourcisseurs d'URL dépassent le point de croisement dès le premier jour parce que la distribution de la charge de travail est à longue traîne - quelques liens populaires portent la majeure partie du volume de clics, et ces liens ont des taux de hit de cache effectivement infinis.

Graphique linéaire du coût par redirection où les courbes DNS uniquement et edge POP se croisent près de 1 million de redirections par mois : DNS uniquement est moins cher en dessous, les edge POPs gagnent au-dessus car les hits de cache contournent les ressources de calcul et la bande passante de l'origine.

Ce que les edge POPs ne résolvent pas

Les edge POPs ne sont pas une mise à niveau universelle. Trois charges de travail qu'ils rendent plus lentes, pas plus rapides :

Les écritures. Créer un nouveau lien, mettre à jour une destination - ces opérations doivent atterrir sur l'origine faisant autorité, puis se propager vers la couche d'invalidation de cache. La latence de lecture est excellente ; la latence d'écriture est à peu près la même que le chemin d'origine uniquement.
Les redirections personnalisées. Les liens intelligents qui routent sur l'identité de l'utilisateur (pas seulement le slug) ne peuvent pas être mis en cache au POP - ils doivent atteindre l'origine à chaque fois pour lire le profil de l'utilisateur. Le POP devient un proxy mince de terminaison TLS, ajoutant 5-10 ms à ce qui serait autrement un accès direct à l'origine. Pour la plupart des raccourcisseurs d'URL, c'est acceptable parce que les redirections personnalisées représentent une petite minorité du trafic. Pour les produits de deep links (Branch, Adjust), le taux de personnalisation est plus proche de 50 %, ce qui change le calcul architectural.
Les destinations géo-restreintes. Si la destination de la redirection change selon la géographie de l'utilisateur (page de destination différente par pays), la clé de cache doit inclure le pays. Cela fragmente le cache - au lieu d'une ligne par slug, vous avez N lignes par slug pour N pays supportés. Le taux de hit de cache baisse ; le coût en mémoire de cache augmente. Les POPs aident quand même, juste moins.

Pour les raccourcisseurs d'URL, le troisième cas est celui à surveiller. La plupart des liens courts se résolvent vers une seule URL quelle que soit la géographie de l'utilisateur, donc une seule clé de cache fonctionne. Mais une fois que vous ajoutez des variantes par pays, l'équation de coût change.

Comment Elido fait cela

Trois POPs (Hetzner Falkenstein, Hetzner Ashburn, OVH Singapore), anycast sur un /24 que nous possédons. Caddy en périphérie pour TLS + certificats à la demande ; fasthttp derrière Caddy pour la redirection elle-même. Cache à deux niveaux : LRU en processus (L1, ~10 000 slugs les plus populaires en mémoire) vers Redis Cluster (L2, ensemble complet de slugs). Le miss de cache bascule vers le point de terminaison gRPC d'api-core, qui lit depuis Postgres.

Cadence de remplissage du cache : toute mise à jour de la destination d'un lien publie un événement d'invalidation sur Redpanda. Les edge POPs s'abonnent et suppriment leur entrée L1 pour le slug affecté. La requête suivante vers ce slug atteint L2 (encore chaud), puis renseigne L1. La latence d'invalidation p95 est ~120 ms sur les trois POPs.

Cette architecture est développée en détail opérationnel dans l'article redirect p95 < 15 ms cornerstone. Le document d'architecture à /docs/architecture/edge-redirect contient le diagramme complet.

L'arbre de décision

Une courte liste de vérification si vous choisissez entre les architectures DNS uniquement et edge POP :

Base d'utilisateurs dans un seul pays + origine unique ? DNS uniquement convient. Ne sur-ingéniez pas.
Utilisateurs multi-pays + taux de hit de cache élevé ? Edge POPs. Le gain de latence est spectaculaire aux emplacements à longue traîne.
Utilisateurs multi-pays + redirections personnalisées sur >50 % du trafic ? Mixte. Les POPs aident pour la terminaison TLS mais pas pour la redirection elle-même. Envisagez le routage DNS + une petite flotte de POPs uniquement pour la terminaison SSL.
SLA strict sur la vitesse de basculement ? Les edge POPs gagnent - le retrait BGP bat le cache TTL DNS de plusieurs ordres de grandeur.
Moins d'1 million de redirections/mois ? DNS uniquement est moins cher. Réévaluez à partir de 1 million.

Il n'y a pas de réponse universelle. Les raccourcisseurs d'URL spécifiquement tendent à correspondre au segment "multi-pays + taux de hit de cache élevé + SLA de basculement strict", ce qui explique pourquoi la plupart des raccourcisseurs d'URL en production finissent par passer à une architecture edge POP. Le coût de transition (re-architecture du remplissage de cache, choix des fournisseurs de POP, configuration BGP) est réel mais délimité.