Comment préserver la faible latence d’un service hautement disponible

En tant que produit SaaS, la protection contre les bots de DataDome repose sur des intégrations entre nos clients et nos API, ce qui signifie qu’une faible latence est essentielle pour les performances du service. Cet article aborde la façon dont la faible latence est appliquée chez DataDome, en mettant l’accent sur la fiabilité de notre architecture.

• Distribution de services dans le monde entier
• Acheminer les clients vers l’emplacement le plus proche
  • Adressage Anycast
  • Routage Geo-DNS
• Basculement et disponibilité
• Conclusion

Distribution de services dans le monde entier

Les communications réseau entre un client et un service peuvent être divisées en trois étapes :

1. Localisation du service cible : résolution DNS.
2. Initialisation du canal de communication : Établissement de la liaison TCP, négociation SSL.
3. Échange de contenu :  requêtes/réponses HTTP (ou autre protocole).

Les bonnes pratiques du côté client ou service réduisent le temps nécessaire à chaque étape et optimisent la latence totale des requêtes :

Nous ne couvrirons pas les optimisations techniques dans cet article.

La plupart des étapes de communication ci-dessus dépendent fortement de l’emplacement du service cible, en raison du temps physiquement nécessaire pour acheminer les paquets sur le réseau du client au serveur cible. Le temps de trajet est presque impossible à garantir et dépend de nombreux facteurs, tels que :

• la qualité, la longueur et l’encombrement des liens réseau ;
• la santé de l’équipement de réseau intermédiaire ;
• les chemins sélectionnés par l’équipement lors du routage des paquets (dépendent de la charge/de l’encombrement, des annonces, etc.).

Pour réduire le temps de trajet, le service cible doit être le plus proche possible du client. Et si vous souhaitez servir de nombreux clients dans le monde entier, votre service doit être bien distribué pour rester proche de tout client qui effectue une requête.

Afin d’être le plus proche possible de nos clients, DataDome a recours à plus de 26 points de présence (PoP) répartis dans le monde entier.

Carte des points de présence de DataDome

Acheminer les clients vers l’emplacement le plus proche

Pour notre service de protection contre les bots, DataDome ne propose qu’un seul point de terminaison DNS : api.datadome.co. Afin de réduire le temps de trajet, nous devons acheminer chaque client vers son emplacement le plus proche.

Les deux options principales pour le routage sont l’adressage Anycast et le routage Geo-DNS.

Adressage Anycast

Internet est un maillage de réseaux interconnectés. Chaque réseau annonce à sa périphérie les plages d’IP qu’il peut acheminer. Lorsqu’un paquet voyage vers une adresse IP cible, il est acheminé par des « systèmes autonomes » (ou « AS », de grands réseaux ou groupes de réseaux avec une politique de routage commune) de manière à réduire le nombre de sauts de réseau nécessaires pour atteindre la destination. Lorsque vous annoncez une adresse IP dans un seul emplacement (adressage unicast), vous pouvez avoir besoin de plusieurs sauts de réseau pour atteindre votre emplacement.

À la différence de l’adressage unicast, l’adressage anycast repose sur l’annonce d’une adresse IP dans différents réseaux. Lorsqu’un paquet est acheminé entre les réseaux pour atteindre cette adresse IP cible, il est dirigé vers l’emplacement approprié qui nécessite le moins de sauts de réseau.

De cette façon, le service peut être distribué et le temps de trajet peut être réduit en réduisant le nombre de réseaux à traverser. Par exemple, voici un réseau sous-jacent qui décide de l’endroit où votre client ira, en fonction de l’état du réseau et des sauts.

L’utilisateur appelle IP1, qui dépend de l’adressage unicast.

L’utilisateur appelle IP1, qui dépend de l’adressage anycast pour atteindre l’emplacement le plus proche.

Routage Geo-DNS

Le routage Geo-DNS exploite un mécanisme très différent. Chacun de vos emplacements a une adresse IP différente. L’emplacement cible est décidé au tout début, lorsque le client résout l’IP cible pour le service en utilisant un DNS au lieu de pendant le routage de la requête sur les réseaux. Le résolveur gérant la requête DNS peut décider de répondre différemment, en fonction de l’emplacement de l’adresse IP source de la requête.

Geo-DNS repose sur ce principe. Si votre requête DNS provient de la France, vous serez dirigé vers une adresse IP déployée en France. Si votre requête DNS provient du Brésil, vous serez dirigé vers une adresse IP déployée au Brésil.

Pour utiliser le routage Geo-DNS, vous devez paramétrer vos règles de résolution DNS (réponse par pays, exclusion d’une plage d’adresses IP spécifique, session permanente, round-robin, etc.). Ensuite, chaque requête DNS peut être résolue en fonction de ces règles. Vous pouvez également ajouter un mécanisme de vérification de l’état de santé, une analyse de charge, des fenêtres de maintenance, etc. à vos règles de résolution DNS.

Chez DataDome, nous utilisons le Geo-DNS pour acheminer les requêtes, car sa flexibilité est meilleure qu’anycast.

• La qualité des réseaux et le temps de trajet global sont facilement surveillés avec des sondes HTTP qui mettent à jour les règles du résolveur DNS en temps réel. Avec l’adressage anycast, nous aurions besoin de nous fier aux annonces de plage d’adresses IP faites par chaque réseau (annonces BGP) pour optimiser le routage en permanence, sur quoi nous avons très peu d’emprise.
• De plus, si nous faisons face à une panne temporaire sur un emplacement cible, les sondes pilotant les résolveurs DNS achemineraient rapidement le trafic ailleurs. Avec les publicités BGP, nous serions dépendants des mises à jour du réseau et des nouveaux itinéraires envisagés pour une option de repli. Là encore, nous n’aurions pas assez de contrôle.
• Geo-DNS nous permet d’appliquer plus facilement la réglementation du pays et l’isolation.

En revanche, le Geo-DNS nécessite plus de travail pour cartographier nos services. Nous testons la latence point-à-point et devinons les performances du réseau et les peerings afin d’avoir un routage efficace pour chaque client.

Mappage Geo-DNS appliqué en Europe pour acheminer les clients vers le point de présence le plus proche

Basculement et disponibilité

Malheureusement, à un moment ou un autre, tous les réseaux échouent et tous les systèmes plantent.

Les paramétrages RAID, les clusters de zones de disponibilité croisées, les charges de travail chaud-froid, etc. sont essentiels en cas de panne dans une partie d’une région, mais ne couvriront pas une situation dans laquelle une région entière ou un réseau est en panne. Maintenir un service hautement disponible n’est pas seulement une question d’architectures de haute disponibilité dans chaque emplacement, mais lorsqu’un emplacement cible ne répond pas ou ralentit la requête, le trafic client doit être acheminé rapidement vers un autre emplacement sain.

Le fait de s’appuyer sur le Geo-DNS permet à DataDome de contrôler le routage lors de tels événements. Le résolveur DNS tient à jour une carte de l’état de santé des régions et des points de présence en temps réel pour supprimer les PoP s’ils deviennent malsains. Lorsqu’un PoP fait face à une dégradation de performance, le résolveur cesse de le résoudre et retourne à l’emplacement sain le plus proche.

Néanmoins, ce mécanisme DNS a un défaut : la mise en cache des réponses DNS. La mise en cache est définie avec un paramètre de temps de vie (TTL) appliqué par enregistrement DNS. La configuration définie par le fournisseur de services est ensuite appliquée du côté client. Du point de vue du client, la mise en cache est utile pour réduire le temps nécessaire à la communication réseau. Elle empêche le client d’avoir à attendre un trajet DNS complet avant d’interroger une IP cible. D’un autre côté, cette mise en cache commande la fréquence des mises à jour de l’emplacement cible (IP) d’un service. Lorsque l’emplacement A (IP A) échoue, les clients qui en dépendaient doivent ensuite attendre que le prochain rafraîchissement DNS soit relocalisé sur l’emplacement B jusqu’à ce que A soit à nouveau en bonne santé.

Anatomie d’une panne dans une région

Afin de maintenir une haute disponibilité du service (et de garder les périodes d’indisponibilité très courtes), nous utilisons un TTL court, soit le taux de rafraîchissement de la cible DNS. Bien que cela implique un léger retard pour les communications réseau à chaque actualisation DNS, le compromis est avantageux compte tenu du taux de requêtes de nos clients.

Nous avons perdu une région (eu-west-1) pendant ~4 minutes.

Le bilan de santé de la région a provoqué une panne.

La région saine la plus proche a temporairement remplacé la zone affectée pendant la panne.

Conclusion

Geo-DNS est un outil puissant qui nous permet de répondre aux requêtes des clients très rapidement, quel que soit leur emplacement source. De plus, associé aux vérifications de l’état de santé, le geo-DNS nous permet de gérer le trafic, même en cas de panne du côté fournisseur ou du réseau. Nous tirons parti du Geo-DNS chez DataDome pour offrir à nos clients un service de latence très faible axé sur la fiabilité.

Néanmoins, le mécanisme repose sur l’emplacement de la requête DNS source, ce qui implique que l’IP de référence doit être précise et que l’IP source de la requête DNS doit atteindre nos résolveurs DNS. Chez DataDome, nous faisons face à quelques cas imprévus liés à ces deux assomptions, mais nous avons des procédures automatisées en place pour surveiller la latence du trafic, détecter et corriger rapidement ce type de cas. Nous travaillons sans relâche pour atténuer les problèmes qui surviennent alors que nous protégeons nos clients dans le monde entier.

Plus d’informations sur ce sujet à suivre…