Hello,
J’écoute le podcast (connu via le journal du hacker), un sujet qui m’intéresse beaucoup en ce moment, c’est la latence.
Dans un datacenter on a 0.1ms de ping entre les machines vs 50+ms à travers le WAN.
Quelles sont vos méthodes pour traiter cette différence de vitesse qui nous fait passer de l’avion supersonique à la charrette à cheval sur chemin de terre ?
Sujet complexe en effet… On va réfléchir à comment traiter ce sujet mais nous n’avons pas des compétences assez avancées pour cela, il faudra qu’on trouve un intervenant mieux câlé 
Bonjour,
Je suis loin d’être un expert du sujet. Mais si ça peut aider.
Je peux expliquer un peu les accélérateurs wan. (mais des personnes réseaux en seront probablement bien plus).
La réplication asynchrone dans le cas de réplication baie à baie entre site.
Mais surtout, je peux partager 2 expériences, malheureuses à cause de la latence. 1 x de migration d’infra, 1 x de mise en prod sur du cloud.
A mon sens, il manque une info importante a ta question : “c’est quoi ton problème ?”. La latence n’est pas un problème en soi, c’est simplement une donnée qu’il faut parfois prendre en compte pour rendre un service.
Par exemple depuis mon laptop je ping google et j’ai 10ms de latence. Pourtant Google fonctionne suffisamment bien pour répondre a mon besoin. Si j’avais 100us de latence, je ne pense pas qu’il fonctionne mieux, car je ne ressentirai pas la différence.
Autre exemple: certains organismes bancaire en charge du trading achètent des datacenters à des emplacement géographique avantageux pour la latence, cela leur permet de passer des ordres plus rapidement et donc de vendre/acheter au bon moment.
@Uggla ça à l’air top tes retours d’expériences, je suis très intéressé pour les écouter
@thierry.f.78 je n’ai pas de problème à te donner comme ça, mais je me suis aperçu que c’était un paramètre dont on parle peu et qui a son importance dans le design d’archi système avec beaucoup de transaction. Venant plutôt du monde “dev” je suis preneur de retour d’expérience sur les moyens de cohabitation des archi synchrone / asynchrone.
Je comprends mieux. C’est sûr que le sujet est intéressant. Tu doit pouvoir tenir 7 ou 8 episodes de podcast sur le sujet 
De plus, le sujet sur la latence est totalement dépendante du débit de la ligne de communication.
Tu peux même étendre le sujet en te demandant si la latence est sujet transparent chez ton cloud-prodiver préféré (spoiler: pas toujours - en tous cas chez le marchand de livres).
Pour moi, les principaux axes de discussions sur ce sujet sont:
… bref, peut être 9 épisodes
Hello,
Je veux bien animer ce genre de podcast, par contre je suis complettement à la ramasse quand on parle de reseau.
Peut-être que le mieu soit que ces sujets soit traiter par @Thomas qui lui est bien meilleur que moi.
@thierry.f.78
Alors perso je signe pas pour 7 ou 8 épisodes.
@JeromeB
En fait avec la latence il y a pas vraiment de spoiler, car la cause c’est de la physique, il y a des cas d’utilisations ou elle est négligeable et d’autres ou elle ne l’est malheureusement pas. Et quand tu touches ces limites c’est souvent douloureux.
Exemple un peu grossier et volontairement simpliste:
Tu veux envoyer un paquet (une io) vers un site distant via un réseau. La limite c’est la “vitesse de la lumière”.
Bon l’ordre de grandeur grosse maille c’est 5µs / km. (célérité de la lumière dans le verre bla bla, on va pas chipoter)
Si tu fais 1000km * 5µs = 5ms, et ces 5ms elles sont impossibles à compresser. (sauf avec la Dolorean de Doc)
Et là je fais cadeau des temps de commutation des équipements, des congestions et des erreurs possibles sur le réseau etc…
5ms c’est plus vraiment négligeable. C’est le temps de réponse d’un disque mécanique.
Le truc rigolo, c’est que souvent tu veux un acquittement de cette io par ton stockage.
Bing 5ms de plus pour le recevoir et que ton système dise, ok l’io a été écrite. Spoiler, en asynchrone tu vas justement pas attendre cette acquittement pour validé l’io, elle se fera en “background”.
Zut c’est balo on venait de mettre un baie full flash de la mort sur le site distant et ça se traine lamentablement… 
Tu notes aussi que tu peux grossir la taille du tuyau 1Gb, 10 Gb, 100Gb, ça change rien en fait.
Ton io mettra toujours au minimum 5ms de a vers b.
Pour que ça change il va falloir paralléliser les flux. Et donc + ou - “masquer” cette latence, en augmentant le débit.
Pour l’illustrer, tu peux le voir avec un ftp car globalement tu streams les octets les un à la suite des autres.
Après fun with flags, voici fun with linux (Amy cher assistante sortait moi le tc qui va bien) :
Test 1:
1 flux, latence réseau round trip time = 100ms (0,1s) taille du paquet max ethernet = 1500 Bytes
Théoriquement.
Tu peux donc envoyer, 10 paquets en 1s.
10 * 1500 = 15000B/s ~ 14,6 MB/s théorique :
Petit test avec la loopback de mon laptop, histoire de pas trop se faire limiter par le réseau. Le sous système disque est un ssd.
Création d’un fichier de 1GB avec du random pour le test
dd if=/dev/random of=testfile_1G bs=1024k count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 33.1674 s, 32.4 MB/s
Petit cp pour voir le temps de copie et que ce ne soit pas le disque qui va nous limiter.
sync && time cp testfile_1G /tmp
real 0m2.210s
user 0m0.024s
sys 0m1.061s
1024MB / 2,210s = 463MB/s (un ssd normal quoi. Si vous trouvez le débit faible, j’accepte un don d’un NVMe 1TB)
Ok si le débit théorique calculé est juste le ssd devrait pas être le problème.
Set du mtu a 1500 sur la loopback
sudo ip link set dev lo mtu 1500
Check du ping sur la loopback:
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.079 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.040 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64 time=0.073 ms
Oui la loopback ca envoie,
il y a pas trop de lantence
Ajout de la latence sur la loopback
sudo tc qdisc add dev lo root netem delay 50ms
ping localhost
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64
time=100 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=100 ms
Voila le round trip time est maintenant de 100ms. 
Ensuite je lance mon ftp entre le fichier dans ma home vers /tmp via ftp.
Si je regarde mon fidèle gkrellm, 10MB/s (8.2MB/s a moment du screenshot), c’est horrible, même moins que le théorique calculé.
A noter que ici mon host fait client et serveur, cf le flux orange (tx) et bleu (rx)
Et donc le flux global de 10MB/s et divisé par 2. En utile c’est environ 4,5 MB/s (cf screenshot)
File transfer successful, transferred 1,077,917,630 bytes in 240 seconds
Test 2:
2 flux, latence réseau round trip time = 100ms (0,1s) taille du paquet max ethernet = 1500 Bytes
Je coupe mon fichier initial en 2 :
split -n 2 testfile_1G testfile_1G_
.rw-rw-r-- uggla uggla 512 MB Mon Aug 17 22:13:49 2020 testfile_1G_aa
.rw-rw-r-- uggla uggla 512 MB Mon Aug 17 22:13:52 2020 testfile_1G_ab
Et je lance le ftp:
Mon débit est ~doublé même si ma latence est identique.
~20MB/s
File transfer successful, transferred 538,958,338 bytes in 117 seconds
Status: File transfer successful, transferred 538,959,292 bytes in 118 seconds
Test 3:
La je suis chaud, Amy on lance avec 10 flux en parallèle.
10 flux, latence réseau round trip time = 100ms (0,1s) taille du paquet max ethernet = 1500 Bytes
split -n 10 testfile_1G testfile_1G_10part_
.rw-rw-r-- uggla uggla 102.4 MB Mon Aug 17 22:19:05 2020 testfile_1G_10part_aa
.rw-rw-r-- uggla uggla 102.4 MB Mon Aug 17 22:19:06 2020 testfile_1G_10part_ab
.rw-rw-r-- uggla uggla 102.4 MB Mon Aug 17 22:19:06 2020 testfile_1G_10part_ac
.rw-rw-r-- uggla uggla 102.4 MB Mon Aug 17 22:19:07 2020 testfile_1G_10part_ad
...
~100 MB/s youpi 
Status: File transfer successful, transferred 107,792,010 bytes in 23 seconds
Status: File transfer successful, transferred 107,792,422 bytes in 23 seconds
Status: File transfer successful, transferred 107,790,652 bytes in 23 seconds
Status: File transfer successful, transferred 107,791,849 bytes in 23 seconds
...
On est quand même passé de 240s à 23s pour transferer le même contenu.
Test 4:
1 flux, latence réseau round trip time ~ 0,040ms taille du paquet max ethernet = 1500 Bytes
Je retire la latence de la loopback
sudo tc qdisc del dev lo root netem
ping localhost
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.040 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.063 ms
File transfer successful, transferred 1,077,917,630 bytes in 2 seconds.
Mon ssd redevient l’élément à la latence la plus grande et limite le débit.
On plafonne donc au débit de mon ssd ~ 450MB/s.
A noter aussi que tu peux jouer sur le mtu, si j’utilisais des jumbo frame par exemple.
Si tu passes le mtu à 9000, bein je te laisse faire le test mais ça change pas grand chose dans cet exemple.
Le mtu va jouer sur la fragmentation, tu vas donc avoir moins de paquet ack a traiter. Mais je pense que sur un aussi petit débit ça ne change pas grand chose en fait. Ca serait pas le cas sur un système qui prend cher en io reseau. Mais ça peut aussi etre contre productif dans certain cas. (si l’appli fait de toute petite io)
Ici en faisant plusieurs fichiers, je peux paralléliser mon flux.
Mais si c’est pas le cas alors cela devient compliqué. Et des applis qui parlent avec un seul flux, il y en a plein. (un peu comme les applis mono thread) et ces applications vont être super sensible à la latence et dans certains cas, ça peut complétement faire échouer des migrations ou des mises en production. Et l’illustration de cela on peut l’aborder dans un podcast. Si @cchaudier , @Thomas sont ok.
Ouh mais t’es chaud/bouillant @Uggla 
Bon j’ai survollé, mais ta proposition mérite d’être mise à l’essai pour comprendre 
L’explication théorique et la démo c’est vachement intéressant et bien expliqué ! en plus avec tout ce qu’il faut pour reproduire. C’est top. Pour ma part, j’ajouterai un côté pratique à tout ceci. Disons Pour ma part, j’ajouterai un côté pratique à tout ceci. Pour répondre à la question : « ok, j’ai la théorie je fais quoi maintenant ? »
Avant toute étude de l’impact de la latence, il faut savoir « quel est le service que je souhaite rendre et dans quels délais ». Attention au biais qui serait de répondre « le plus vite possible », car cela peut entrainer très loin dans le financement de l’infra. En effet, « le plus vite possible » est conditionné par du matériel très cher.
Note : dans le texte ci dessous, je parle de « clients » et « serveur ». La terminologie n’est pas juste. Il faut plutôt comprendre « communiquant 1 » et « communiquant 2 ». Je trouve que client et serveur sont des termes plus lisibles.
comme l’a dit @Uggla, de la limitation par la vitesse de la lumière. Cette limitation va concerner le medium de base, à savoir : le câble, la fibre optique, les ondes radio, … Pas la peine d’invoquer la supra-conductivité, elle ne casse pas la vitesse de lumière
la latence provient également des équipements électroniques. Un transistor des années 80 commute moins vite qu’un transistor des années 2020, et va donc ralentir le temps de traitement du signal. Par exemple, pour le cas d’ethernet, le « truc » qui transforme les 1 et les 0 à envoyer en signal modulé pour le transport va ajouter de la latence.
sur les réseaux, on va avoir un mix de tout ça. Pour aller d’un point A à un point B, on va traverser « n » routeurs qui vont ajouter de la latence et « n » câbles qui vont eux aussi ajouter de la latence.
on a la latence due à la surcharge de la ligne de communication. Si la ligne n’est pas liée à une activité (par exemple l’accès Internet d’une société), un protocole qui devrait être prioritaire devra attendre que le réseau ait fait passer ce qui n’est pas prioritaire. C’est la « congestion » de la ligne.
On va rencontrer la latence et le RTT. On va considérer que de ce point de vue, la latence et la congestion sont similaires, car la congestion est une cause de latence.
Pour une communication symétrique, le RTT = 2 x la latence, ce n’est pas vrai pour de l’asymétrique. Par exemple sur Internet, rien ne garantit que la paquet IP de réponse passera par le même chemin que le paquet IP de requête.
Les deux catégories principales :
le délai de réception des données par rapport à l’heure de l’événement est important pour le service rendu. Par exemple dans un véhicule, ou souhaite que le système de freinage sache rapidement que le conducteur a appuyé sur la pédale.
les protocoles avec acquittement. Si la réception des données nécessite un ou plusieurs acquittements, la latence va ralentir le transfert. Par exemple, une connexion TCP nécessite un acquittement, donc l’établissement d’une connexion TCP est sensible au RTT. Par ailleurs cette sensibilité au RTT va brider la capacité de débit de la ligne.
On va retrouver les problématiques liées au stockage et à la réplication. Note : Ces problématiques prennent également en compte la latence des disques dur, mais je l’ignore dans le reste de l’explication. Attention, dans la vrai vie, on ne l’ignore pas. Dans l’idéal, on souhaite que la donnée soit stockée sur deux nœuds dont un dans un autre data-center, et on veut être sûr qu’elle soit stockée sur les deux nœuds avant d’acquitter l’écriture.
Cette volonté devient problématique au vu de la latence : l’acquittement du stockage par le second nœud, est long à arriver et donc, du point de vue client, les écritures sont longues à être faites.
On trouve également les problématiques de live vidéo. On a tous connu des ralentissements ou des freezes sur Hangouts ou autre. On a aussi connu des discussions difficiles à tenir car l’interlocuteur reçoit le message avec une seconde de lag.
Le premier point est traité par les méthodes du temps réel. En gros, la latence ne peut pas être de 0, donc on va calculer le max acceptable, et garantir que l’on sera toujours en dessous. Pour le freinage, on va par exemple demander à ce que la commande de freinage soit toujours déclenchée 50ms (valeur au hasard) après avoir appuyé sur la pédale.
Une fois que l’on dispose de cette donnée, on garantit techniquement le délai, maximum. Dans le cadre des réseaux informatiques, on va trouver des technologies allant du plus cher au moins cher.
Pour la latence liée aux mediums de transport, on ne peut rien faire d’autre qu’approcher la limite théorique de la vitesse de la lumière. On est à 70 à 75% de la vitesse de la lumière dans de la fibre (selon Wikipedia), soit 210 000 et 220 000 km/s. Entre 175 000 et 200 000 km/s dans le cuivre (selon Wikipedia). Je ne parle pas des ondes radio, car je n’ai jamais touché ces technos. Attention à la qualité du médium : pour les longues distances, une fibre ou un câble de mauvaise qualité perdra le signal. Il faudra ajouter des répéteurs, ce qui fait augmenter la latence. Donc pour réduire la latence due à la distance, il faut préférer la fibre optique de bonne qualité.
Pour la latence liée à la partie électronique, on peut augmenter la vitesse de transfert du réseau. Cela fera baisser la latence. Le débit et la latence ne sont pas directement liés, mais on sous certaines conditions, on trouve une relation. Pour augmenter le débit, on parallélise les lignes de connexion, ou on augmente la vitesse. Si on augmente la vitesse, on réduit la latence. Globalement, la latence sur de l’Ethernet 10Mbps sera plus élevé que sur du 10Gbps. Attention toutefois aux technos. Par exemple, 1Gbps Ethernet, c’est 4 signaux modulés à 250MHz, donc la baisse de latence n’est pas proportionnelle au débit. Les technos 40Gbps sont parfois 4 x 10Gbps, cela ne fait pas baisser non plus la latence par rapport à du 10Gbps.
On va aussi bien sur réduire au maximum le nombre d’équipement traversés. Tu ajoutes un routeur Cisco hardware, la latence ajoutée va être faible, mais mesurable. Tu ajoutes un firewall Linux Netfilter, la latence va être élevée, car le signal est traité en software, et non en hardware. Donc attention aux équipements qui traitent en fonction de ce que tu veux faire.
En conclusion, les problèmes de latence se règlent en allant aussi vite que nécessaire :
La congestion c’est l’encombrement des lignes de communication. Si on veut garantir un temps de transfert de sa donnée, il ne faut pas que la ligne soit congestionnée. Pour éviter la congestion, on peut :
Dimensionner ses lignes de communication. Si tu sais que tu auras des pics à 1Gbps et que tu prends une ligne 100Mbps, tu auras de la congestion, et dons de la latence ajoutée. Il faut donc bien dimensionner ses lignes.
Dédier ses lignes de communication. Ben oui, si la ligne est dédiée à un protocole sensible à la latence comme du SIP, ou des protocoles de vidéo chat, tu ne seras pas perturbé par tes paquets bit torrent. Si ta ligne fait du bit torrent et du vidéo chat en même temps, tu t’expose à des ennuis, si la ligne est un peu juste.
Mettre en place de la QoS. Il s’agit d’indiquer à ton routeur quels sont les protocoles à prioriser. Ça fonctionne, mais c’est une solution de dernier recours, car cela signifie que ta ligne est sous dimensionnée, et tu finiras par avoir un problème.
En conclusion, tu gère la congestion avec :
Ça devient plus complexe. Dans le cas de la latence, cela ne change rien au fonctionnement des clients, seule la qualité du service rendu est contrainte. Dans le cas du RTT, la latence impacte aussi le client.
Les problématiques de RTT sont parfaitement liés aux problématiques de latence et de congestion. Les solutions qui s’appliquent à la latence et à la congestion peuvent en partie résoudre les problématiques dues au RTT.
Pour répondre au dilemme du serveur de fichier, on va simplement devoir faire un compromis. On ne peut pas avoir à la fois un fonctionnement rapide et la garantie de dupliquer des données. C’est l’architecte qui va trancher en fonction du service à mettre en œuvre.
Si on peut se permettre de perdre quelques minutes de data en cas de crash, mais qu’il est primordial que la réponse au client soit faite très rapidement, on va privilégier la duplication des données asynchrone. Le premier nœud acquitte les données, et s’occupe de leur duplication quand il a le temps.
Si on ne peut pas se permettre de prendre de la donnée, par exemple pour de la transaction financière, on va privilégier la synchronisation des données. On aura donc de l’écriture synchrone, le client mettra plus de temps avant d’avoir son acquittement, mais on sera sûr que la transaction est écrite sur deux serveurs.
Finalement, pour les communications qui nécessitent de l’acquittement (comme TCP), on va minimiser l’effet de la latence en utilisant des fenêtres de data. Le concept est simple : plutôt que d’acquitter chaque donnée, le client s’autorise à envoyer une grande quantité de données et recevoir les acquittements en asynchrone. La quantité de données que l’on s’autorise à envoyer sans attendre d’acquittement se nomme la fenêtre.
Voilà un calcul théorique qui sert pour les calculs de fenêtre. C’est la quantité de données « sur le fil ». Ce sont les données en transit entre le moment ou le client les émet et le moment ou le serveur les reçoit. On a donc le débit en « b/s » et la latence en « s ». La quantité de données en transit sera le débit x latence (« b/s » x « s » = « b »).
Pour une latence de 100ms et un débit de 1Gbps, on a 1Gbps x 100ms = 100kb, soit 100kbits en transit. Une fenêtre de 100kbit peut assurer le remplissage de la capacité en débit d’une ligne à 1Gbps.
Comme on utilise des couches d’abstraction, on peut étendre le problème des fenêtres au-dessus de TCP. La couche TCP du système nous garantit que la donnée envoyée sera reçue, ou la connexion sera rompue. Seulement, au-dessus de TCP on a une API (sous Linux, TCP est gérée par le kernel, et est accessible aux applications par les appels système qui sont le plus souvent matérialisés par la libc). On fournit un buffer de données à transmettre à l’API qui acquitte, et le kernel utilise TCP pour les transférer. Qu’est ce qui garantit que les datas sont parties ? Peut-être la connexion est rompue et le kernel n’a pas pu tout envoyé ? Réponse 1 : rien, répose 2 : ça arrive.
Fort de ce constant, des protocoles ajoutent un système de fenêtre au-dessus de TCP. C’est le cas du célèbre SSH qui a longtemps vu ses débit SFTP limités à cause de la fenêtre en question.
En conclusion tu gère les problèmes de RTT avec :
J’ai un peu bossé pour une boite qui, comme beaucoup d’autres, se voulait le n°1 français de l’intégration AWS, et j’ai découvert de cloud. C’est génial le cloud car tout est pris en charge par le cloud provider, tu ne t’occupes de rien et ça fonctionne ! Qu’en est-il de la latence ?
C’est pas du tout transparent. Comme l’a noté @Uggla c’est une limite de la physique. Ça doit donc ressortir. En est-on conscient ? Je n’en ai pas l’impression. Donc sur AWS entre deux serveurs virtuels du même VPC et du même LAN virtuel, un sur une AZ « A » et l’autre sur une AZ « B », on a plus de latence qu’entre deux serveurs sur une même AZ.
Souvent, les applications sont lourdingues et leurs temps de réponses sont bien plus élevés que la latence inter-AZ, alors ça ne se voit pas.
Mais il reste des cas. Qu’en est-il de la mode du micro-service poussée à outrance installé chez un cloud provider. C’est simple les services en HA sur plusieurs AZ communiquent entre eux dans tous les sens. Les LB ou le DNS choisissent un DC. En fonction de ces choix, la latence comme à se faire sentir. Effectivement, 3ms (je ne me rappelle pas de la vrai valeur) dans une connexion, ça peut être négligeable, mais « n » micro-services à contacter, ça fait « n » x 3ms. Ça peut peser.
La solution consiste à avoir une préférence locale (je ne sais pas si possible dans AWS). Le concept est de dire que si je suis sur un DC, j’utilise au maximum les services de mon DC. J’utiliserai les services de l’autre DC uniquement en mode dégradé.
Je pense avoir fait le tour de la problématique. N’hésitez pas à compléter ou corriger !
Les zones dans une région sur AWS bénéficient entre elles d’une interconnexion à faible latence. Même dans le cas de microservices cela n’a pas d’impact particulier dans la majorité des cas et c’est aussi grâce à cette faible latence que des services comme RDS peuvent être déployés sans souci en multi-AZ.
Par contre, entre régions, c’est une autre histoire, là on se retrouve vraiment avec une latence non négligeable un peu comme chez OVH entre deux DC. Ceci rendait difficile de concevoir des architectures multi-régions et cela a été longtemps réservé à des entreprises expérimentées comme Netflix.
Ces dernières mois cela devient plus accessible avec notamment RDS Aurora qui offre maintenant la possibilité de déployer un cluster de base de données multi-maitres entre régions avec compatibilité MySQL et PostgreSQL (reste à voir l’impact réel sur les perfs).
J’ai appris a ne pas faire confiance aux annonce de AWS, alors j’ai testé et c’est vrai. Dans eu-west-1, au sein de la même AZ je mesure un RTT de ~0.450ms entre deux AZ différente, je mesure ~0.870ms.
Ma mesure date d’il y a ~4ans, les choses ont du évoluer.
Cela dit pour comparer, j’ai deux machine physiques entrée de gamme chez un hosteur. Elles sont connectées en Gbps. Le RTT entre les deux est de 0.1ms. (en plus ces machines physique me coutent moins cher que deux instances EC2 aws moins puissante, mais c’est un autre histoire).
A configuration identique, tu auras toujours de meilleures performance sur du bare-metal ce qui est tout à fait normal.
En environnement cloud, la puissance se construit sur le nombre pas à l’unité.
Personnellement, lorsque je mets au point une architecture d’infrastructure, ce qui va m’intéresser spécialement c’est la latence entre les différents DC car c’est là où on fait le plus face à ce problème.
Chez OVH* si tu utilises leur vRack pour relier plusieurs serveurs dispatchés sur différents DC, tu auras probablement des latences bien pire que chez AWS/GCP/Azure.
Je pense qu’on entre justement dans une nouvelle ère où les principaux cloud providers vont essayer de faciliter la mise en place d’infrastructures multi-regions, cela à mon avis pour minimiser l’intérêt du multi-cloud et fidéliser d’avantage les clients.
* Ce n’est pas du bashing d’OVH, c’est juste que j’ai eu des expériences pro avec eux qui me permettent d’en parler concrètement.
Salut tout le monde, c’est une sujet super intéressant et très bien traité par @Uggla et @thierry.f.78 ! Merci pour votre contribution très détaillée et très complète.
Pour la question qui m’était adressée beaucoup plus haut, à savoir animer un podcast sur le sujet, pourquoi pas ! Mais cela a été répondu, il faut circoncire le sujet pour éviter de partir dans du trop générique et perdre l’auditoire.
La question de la latence peut rester dans le titre, mais en effet il est nécessaire de prendre du recul et parler également de QoS, des usages des protocoles TCP et UDP, et tout simplement de commutation ! C’est @thierry.f.78 qui le rappelle je crois, faire de la commutation avec un switch Cisco niveau 2 (ou 3) ou avec un serveur Linux (niveau 5 et +), c’est carrément pas la même !
Donc pour un épisode de podcast digérable par les auditeurs⋅trices, je pense qu’il est préférable d’axer la discussion autour de cas concrets, avec des solutions concrètes. Et au milieu on glisse quelques vocabulaires et concepts importants à comprendre.
Par contre je suis un peu limité en disponibilité en ce moment (temps partiel), et il faut travailler un peu le sujet avant. Donc on peut continuer à échanger sur la technique dans ce sujet, et créer un autre sujet pour la préparation d’un podcast. Qui serait intéressé pour y participer ?
Effectivement, 3ms (je ne me rappelle pas de la vrai valeur) dans une connexion, ça peut être négligeable, mais « n » micro-services à contacter, ça fait « n » x 3ms. Ça peut peser.
@thierry.f.78 super post ! 
C’est une excellente remarque. Il faut toujours garder à l’esprit qu’établir une connexion tcp à l’échelle de temps d’un ordinateur c’est “super” lent. D’où le besoin par exemple entre un app serveur et une db de garder des connexion ouvertes (pool) et de les réutiliser.
J’aime bien ce lien aussi qui permet de synthétiser les ordres de grandeur:
Une petite précision:
Il faudra ajouter des répéteurs, ce qui fait augmenter la latence. Donc pour réduire la latence due à la distance, il faut préférer la fibre optique de bonne qualité.
Absolument, mais même avec des équipements top et fibres de bonne qualités il faut mettre des répéteurs, pour remettre le signal en forme. La où je travaillais, on avait mis en place 2 liens entre 2 DC distants de ~80km (note: il y a des règles sur la distance dans le monde bancaire pas ex suite au 11/09/2001 et le crash des 2 tours du World Trade Center 
). Sur le deuxième lien, plusieurs passages étaient possibles, notamment un plus long ~120km mais géographiquement très éloigné du premiers, mais nous n’avions pas pris cette option car sur ce chemin il fallait des répéteurs avec un impact sur la latence (pas énorme quand même) et le cout si je me souviens bien.
Ce comparatif est top ! Je pense qu’il serait perfectible en ajoutant:
Je confirme, et j’ai participé à la conception une très interessante architecture bancaire qui prends en compte la latence liée à cette distance (env 250km vol d’oiseau).
Oui bonne idée.
J’adore le parallèle avec la baquette de pain de Quentin Adam ici:
https://youtu.be/1dTPoBXPDcg?t=1665.
Je trouve que ça matérialise bien les ordres de grandeurs et avec humour.
J’aime bien le parallèle entre la data et la fourniture de pain. Je trouve que ce genre d’explications met bien le sujet en abime. Après, bien que possible, c’est un peu exagéré, car lorsque l’on utilise un SAN c’est souvent en local avec une latence de 0,1ms et pas en Californie avec 150ms. Cela dit l’explication reste saine.
Merci @Uggla pour la conf de Quentin Adam, je l’ai adoré (au delà de la rubrique boulangère).