Visualisation de la latence des centres de données AWS

• Il s’agit d’une page de visualisation qui présente la latence entre centres de données AWS répartie en 3 plages en millisecondes
• La légende distingue moins de 100 ms, 100 à 200 ms et plus de 200 ms, afin de comparer rapidement les niveaux de latence
• Les informations fournies ne permettent pas d’identifier quels centres de données ou régions sont inclus
• La méthode de mesure, le moment de la mesure et les valeurs de latence individuelles entre centres de données ne sont pas fournis
• Par conséquent, le périmètre vérifiable dans ce résumé se limite aux seuils des plages de la visualisation

---

Légende de latence

• X < 100ms : moins de 100 ms
• X 100ms - 200ms : 100 à 200 ms
• X > 200ms : plus de 200 ms

Détails qui ne peuvent pas être vérifiés

• Aucune liste précise de centres de données AWS ni aucun nom de région n’est fourni
• La méthode de mesure, le moment de la mesure et les valeurs de latence entre centres de données individuels ne peuvent pas être vérifiés

[devenv]

On dirait que us-east-1 est l’emplacement le plus avantageux en direction de l’Occident.

[GN⁺]

Avis de Hacker News

• Plutôt que d’afficher seulement les temps de ping, ce serait bien de montrer aussi à quel point ils sont mauvais par rapport à la valeur optimale théorique.
  Si je me souviens bien, la vitesse de la lumière dans la fibre optique est environ 30 % plus lente que dans le vide.
  Plusieurs fois, lors de réunions d’architecture, des gens se sont plaints de la latence entre datacenters, avant qu’on se rende compte ensuite qu’elle était en fait assez proche de ce qui était théoriquement possible dès le départ.

  • Chez les hyperscalers et les grands acteurs de colocation/hébergement, j’imagine que ce genre d’indicateurs est déjà bien connu en interne.
    Quand un client conçoit un système de haute disponibilité ou de reprise après sinistre, il est important d’éviter qu’il choisisse par erreur, comme zone principale, une région ou une zone « artificiellement » très latente.
    Mon entreprise actuelle est spécialisée dans la migration de SAP vers le cloud ; depuis que nous nous sommes fait piéger par le passé par une latence inacceptable due à de mauvaises hypothèses, nous avons systématiquement cette discussion avec les experts réseau d’AWS et de GCP dès la phase d’estimation et de cadrage.
  • Ça ne semble pas être un vrai ping, et c’est plutôt une bonne chose.
    Ce n’est pas un ping ICMP, mais une connexion en flux socket sur tcp/443.
    Le ping peut être un mauvais indicateur.
    https://github.com/mda590/cloudping.co/blob/8918ee8d7e632765...
  • Pour faire ça, il faudrait cartographier tous les trajets des câbles.
    Dans un câble en fibre optique, la lumière se déplace à environ 70 % de la vitesse de la lumière, soit autour de 210 000 km/s.
    La circonférence de la Terre est d’environ 40 000 km, et le trajet en ligne droite jusqu’au point opposé du globe représente environ 100 ms à l’aller, soit environ 200 ms aller-retour.
  • En cliquant sur la carte, je ne vois pas vraiment de cas où la latence s’écarte fortement de ce qu’on attendrait au regard de la distance.
    Bien sûr, avec de la fibre optique creuse et des trajets de fibre proches de la ligne droite, on pourrait théoriquement gagner environ 40 %, mais peu d’acteurs voudront en payer le prix.
  • Je suis l’auteur. C’est intéressant, et on m’a proposé la même idée sur X.
    Je me demande s’il existe de bonnes ressources pour calculer cette valeur précisément.

• Étant daltonien rouge-vert, il m’est difficile, voire impossible, de distinguer les lignes sous 100 ms de celles au-dessus de 200 ms.
  Cela concerne environ 8 % de la population masculine, donc ce serait bien d’ajouter un mode daltonien.
  La visualisation elle-même est très réussie.

  • Comme contournement rapide, on peut appliquer un filtre CSS à toute la page.
    Dans les outils de développement, ajoutez la règle filter: hue-rotate(60deg); à l’élément body, ou exécutez javascript:void(document.body.style.filter='hue-rotate(60deg)') dans la barre d’adresse.
  • Je suis l’auteur. Merci pour la suggestion.
    Si vous connaissez des exemples particulièrement réussis de résolution de ce problème, idéalement avec des liens, je serais preneur.
  • Je ne vois pas du tout les lignes, seulement les points bleus répétés qui représentent les datacenters.
    C’est assez déroutant.
  • Je me demande s’il existe des outils d’accessibilité pour ce genre d’usage.
    Par exemple un filtre qui modifierait les couleurs de tout l’écran d’une certaine manière pour les rendre distinguables.
  • En tant que daltonien, il est important de tenir compte du daltonisme lorsqu’on choisit des couleurs, mais les 8 % d’hommes concernés ne sont pas tous incapables de distinguer ces deux couleurs.
    La proportion est plus faible, et même parmi les personnes daltoniennes, la perception des couleurs varie.
    Ce n’est pas parce que c’est lisible pour quelqu’un que ça le sera pour quelqu’un d’autre, et inversement.

• J’ai travaillé autrefois sur une planification liée à ce sujet pour un client.
  En mesurant la latence AWS, j’ai constaté qu’en estimant grossièrement la longueur des câbles sous-marins en kilomètres puis en divisant par 150, on tombait à moins de 10 % de la latence réelle.
  Ce n’était pas vraiment surprenant, mais c’était très cohérent ; avec le recul, je crois que le facteur était plutôt 155.

  • Ça me rappelle l’histoire de l’e-mail à 500 miles.
    https://www.ibiblio.org/harris/500milemail.html
  • Je pense que c’est dû à la vitesse de la lumière dans le milieu.
    « Avec LabVIEW, la vitesse de la lumière dans la fibre optique a été calculée à environ 2,054 x 10^8 m/s, ce qui correspond à une valeur typique pour un indice de réfraction n ≈ 1,4606 »
    https://web.phys.ksu.edu/posters/2009/juma-Adv-Lab-S09.pdf
  • Dans la modélisation du monde réel, il est étonnamment fréquent que de simples multiplications et additions donnent une précision satisfaisante.
  • Cette page est vraiment bien faite comme carte interactive, et je l’ai trouvée très amusante.
    Je me demande si l’explication mathématique de cette règle empirique ressemble à peu près à ceci.
    https://news.ycombinator.com/user?id=Hikikomori a corrigé la vitesse de la lumière dans la fibre optique : 2e5 au lieu de 3e5.
    La vitesse de la lumière est de 2e5 km/s, soit environ 2e2 km/ms, ce qui donne une forme longueur (km) / 200 (km/ms), et donc au final latence (ms) ≈ K' × longueur (km).
    Je me demande si K vaut environ 1,3, K' vaut 1/155, et si cela intègre des facteurs comme les trajets non rectilignes, l’overhead réseau et la commutation, ainsi que les erreurs de mesure aller-retour.
  • D’après la visualisation, la plupart, voire la totalité, des lignes rouges correspondent à des trajets longs, comme entre l’Amérique du Nord et l’Afrique du Sud.

• Intéressant. En cliquant sur le cercle bleu qui représente un datacenter, la latence vers les autres datacenters s’affiche.
  Il m’a fallu un petit moment pour le comprendre ; ce serait bien d’ajouter sur le site une indication du type cliquez sur un datacenter pour le sélectionner.

  • Strictement parlant, ce ne sont pas des datacenters mais des agrégations au niveau des régions.
    Une région est composée d’un mélange de réseaux et de composants de calcul à plusieurs niveaux d’abstraction, comme des datacenters, des points de présence en périphérie, etc.
    Même au sein d’une même région, la variabilité entre zones peut être importante, donc la méthodologie de mesure compte.

• AWS fournit dans Network Manager des chiffres de latence entre régions, entre zones de disponibilité et au sein d’une même zone de disponibilité
  C’est utile pour établir une ligne de base de latence et voir s’il y a un problème côté AWS
  https://docs.aws.amazon.com/network-manager/latest/infrastru...

  • AWS propose aussi un tableau de bord montrant les pannes de régions ou de services, mais l’historique montre qu’il est difficile de faire entièrement confiance à ce type de tableau de bord, précisément pour les mêmes raisons

• La visualisation et le concept sont superbes, mais ce serait mieux si les couleurs étaient un dégradé continu plutôt que des classes
  La méthode actuelle fait paraître 100 ms bien pire que 99 ms, tout en le faisant paraître identique à 200 ms
  Par exemple, quand on clique sur us-east-1, les latences des datacenters d’Europe de l’Ouest semblent assez différentes : eu-central-1 et eu-south-1 ne diffèrent que d’environ 9 ms mais paraissent complètement différents, tandis que eu-north-1 et ap-south-1 diffèrent d’environ 88 ms mais paraissent identiques
  Certains proposent aussi de comparer les mesures à la latence minimale possible compte tenu de la vitesse de la lumière, mais le problème est que la vitesse de la lumière dans le vide, c, n’est pas la vitesse de transmission de l’information dans une fibre optique
  Le meilleur théorique réel dépasse difficilement 70 % de c, rien qu’en considérant la vitesse de la lumière dans le milieu, et il existe beaucoup d’autres facteurs inconnus comme la latence des répéteurs

  • Je suis l’auteur. Le dégradé est vraiment une excellente idée
    La visualisation actuelle donne l’impression qu’une latence de 90 ms est « bonne », alors qu’en réalité c’est totalement inacceptable pour de nombreuses applications
    C’est particulièrement vrai lorsqu’il faut plusieurs allers-retours pour traiter une seule requête

• Je me demande comment ils ont choisi quels datacenters inclure
  Par exemple, l’Espagne, eu-south-2, n’y figure pas
  J’ai travaillé par le passé sur un projet où la latence entre datacenters devait être inférieure à 30 ms, et nous devions utiliser eu-west-1 en Irlande et eu-south-2
  Mais la latence réelle était proche de 42 ms, principalement parce qu’il n’y a pas de câble sous-marin entre l’Irlande et le continent européen : il fallait passer par le Royaume-Uni, puis retraverser le Royaume-Uni jusqu’au câble vers le continent

  • En bas de la page, il est écrit que ce sont des données scrapées depuis CloudPing, avec aussi un lien vers le jeu de données CloudPing
    Si l’on va sur CloudPing, eu-south-2 n’est pas dans le jeu de données
  • Je suis l’auteur. Je n’ai utilisé que ce qui était disponible sur https://www.cloudping.co, et il manque effectivement quelques emplacements
    Le dépôt GitHub de CloudPing n’a pas connu de changement de code depuis 4 ans, donc quelques nouvelles régions ont pu apparaître depuis la dernière période d’activité du projet
  • Je serais curieux de savoir comment tu as appris qu’il n’y avait pas de câble entre l’Irlande et le continent européen
    Je voudrais simplement savoir où cette information est disponible publiquement
  • Il manque pas mal de datacenters sur cette carte
  • Israël, il-central-1, manque aussi

• Les données sont très utiles et le globe est visuellement impressionnant, mais pour un usage réel, une carte du monde plane serait probablement meilleure
  Elle montrerait tous les datacenters en même temps, et les lignes seraient moins resserrées, donc plus faciles à lire

  • Je me souviens que ce type de projection azimutale équidistante était populaire chez les radioamateurs
    https://en.wikipedia.org/wiki/Azimuthal_equidistant_projecti...
  • Une carte du monde en 2D ne donne pas forcément une bonne intuition des distances réelles entre les lieux
    Une option permettant de basculer entre les deux serait préférable
  • D’accord. C’est joli, mais ce n’est pas la meilleure visualisation pour réellement lire les données
  • Je suis l’auteur. Il faut trouver un équilibre soigneux entre ce qui est beau et ce qui est utile

• Le principal facteur de latence est évidemment la distance
  Mais même entre des régions relativement proches, il peut ne pas y avoir de fibre optique directement connectée, ce qui donne par exemple de mauvaises latences via des routes passant par les régions polaires
  Je me demande s’il existe des cas de régions qui violent fortement l’inégalité triangulaire
  Autrement dit, des cas où la latence A–C est bien pire que la meilleure latence A–B + B–C
  Par curiosité, je me demande aussi si l’on pourrait, à partir de cette idée, déduire quels datacenters ont le plus de chances d’être directement reliés par fibre optique, puis n’afficher que ces liaisons

  • Je ne peux pas parler directement d’AWS, mais dans ma thèse de doctorat, j’ai trouvé pas mal de cas de ce type en utilisant des sondes RIPE Atlas
    L’idée de base consiste à chercher des paires de sondes pour lesquelles le temps aller-retour entre les sondes A et C est supérieur à A–B + B–C
    Cette méthode a les problèmes habituels des mesures ICMP/RTT, ainsi que le fait que le trafic n’a pas réellement été routé via la sonde « intermédiaire », mais de telles paires existent
    Il y a un exemple à la page 84 de https://theses.hal.science/tel-03666771/document, si vous savez lire le français
  • À grande échelle, je ne pense pas que cela se produise souvent à cause du routage
    Si la route de « détour » via B est le chemin le moins coûteux pour qu’un paquet ICMP arrive à destination, alors il empruntera effectivement ce chemin
    Il serait plutôt intéressant de chercher les endroits où A–C est presque égal à A–B + B–C : on y verrait sans doute ce phénomène
    Outre l’absence de fibre optique, cela peut aussi être dû à des raisons financières, comme des accords de peering plus avantageux
  • Il y a très peu de câbles, et de mauvaise qualité, dans la zone entre la Russie, la Mongolie et l’Inde
    À ma connaissance, Mumbai n’est pas si loin du sud de la Russie en termes de distance, mais la latence est étonnamment élevée
    Elle est par exemple bien plus élevée qu’entre Francfort et Moscou, et je ne sais pas si cela suffit à violer l’inégalité triangulaire entre Francfort–Moscou–Mumbai
  • Pour une carte mondiale des câbles en fibre optique, il suffit de regarder ici
    https://www.submarinecablemap.com/
    Comme les câbles sous-marins coûtent extrêmement cher à poser, il est très peu probable qu’il existe des câbles non publics
  • Certaines régions comme l’Amérique du Sud et l’Asie du Sud sont notoirement connues pour la mauvaise qualité de leur réseau
    De manière générale, la perte de paquets y est aussi plus élevée

• J’utilisais ça il y a quelques jours
  https://aws-latency-test.com/

  • Je suis l’auteur. J’ai vu ce site en cherchant des données à utiliser pour cette visualisation, et il était correct