5 conseils pour réduire la latence : en voici un sixième

Il y a quelques mois paraissait un article de Stephen J. Bigelow listant 5 conseils pour réduire la latence d’un cloud hybride. Cet article a l’avantage de parler d’un vrai sujet : la latence. Il nous a semblé nécessaire cependant d’y ajouter quelques compléments pour apporter une réponse concrète à un problème de fond.

Les processeurs passent leur temps à attendre

On pense trop souvent, à tort, que la performance d’un service Internet est directement liée à la puissance de calcul d’une plateforme. Or, quand on y regarde de plus près, les processeurs passent le plus souvent leur temps à… attendre ! Bien sûr on va tenter de mieux les occuper en leur demandant de plus en plus (virtualisation), mais l’essentiel du sujet n’est pas là : le problème n’est pas là où on le croit. A répartir l’information dans plusieurs systèmes (géographiquement différents), en découplant les unités de stockage des centres de traitement de données, on gagne en “scalabilité” et en redondance mais on perd en vitesse de traitement en introduisant, à tous les étages, de la latence. Le temps que l’on perd à déplacer les informations, des cartes d’acquisition vers la mémoire, de la mémoire vers le(s) processeur(s), du processeur vers les interfaces réseau, de réseau en réseau, est devenu largement supérieur au temps de traitement de l’information. Mieux encore, les protocoles d’aujourd’hui (en TCP), sont de véritables ballets conversationnels qui induisent de la latence dans toutes les requêtes : établissement de connexion, acquittement, transfert de données, fermeture de connexion…

L’article de Stephen J. Bigelow insiste entre autres sur la nécessité de proximité. Mais s’il est vrai que la distance des liens mis en œuvre influe sur la latence, surtout si l’on fait le tour de la terre par défaut de peering, il est faux de penser que cela soit une condition nécessaire et suffisante. Dans l’Internet …

… le chemin le plus rapide n’est pas toujours le plus court

Au mieux, en réduisant de quelques milliers de km la distance, on gagnera quelques millisecondes, mais on pourra perdre beaucoup plus (cela se chiffre en dizaines de millisecondes, voir pire) à cause du nombre de “sauts” et de l’efficacité des routeurs mis en œuvre (performance, qualité de paramétrage, ordre de priorisation de trafic, surcharge toujours possible, mécanismes de gestion de QoS hasardeux…). Ainsi, je préfère toujours un trajet de 5.000 km le plus direct possible et des ingénieurs IP qui connaissent leur métier, à 18 “sauts” (hops) pour faire quelques centaines de kilomètres autour de Paris avec des liaisons en hyper contention et des routeurs à genoux tellement on leur demande de faire plus que leur travail.

Revenons aux 5 conseils pour réduire la latence.

Oui, travailler avec du direct peering entre ses centres informatiques et les infrastructure du Cloud est important dans la maîtrise de la qualité de son service. Mais pas parce qu’ils raccourcissent la distance. Parce que le direct peering réduira le nombre de sauts et d’infrastructure non “maitrisée” au milieu et diminuera de facto la réduction de la latence.

En fait, le conseil le plus important de l’article est la conclusion :« En revanche, les développeurs doivent prendre le temps d’évaluer les changements conceptuels susceptibles d’y contribuer. » Et là… on n’est pas plus avancé si on ne dispose d’aucun moyen d’évaluer ces changements. Heureusement, des solutions existent. Les remarques qui suivent sont le fruit de notre expérience d’opérateur Internet et de 16 ans de recul à aider la plupart des acteurs au niveau mondial pour améliorer la performance de leurs services.

« Oui, travailler avec du direct peering entre ses centres informatiques et les infrastructure du Cloud est important dans la maîtrise de la qualité de son service. Mais pas essentiel dans la réduction de la latence. »

Impossible d’améliorer ce que l’on ne mesure pas.

Et oui, dans l’Internet, rien n’est une science absolue. Les technologies changent souvent, les effets de bords apparaissent, et les montées en charge induisent des comportements mal maîtrisés. Bref, rien ne se passe jamais comme prévu. Et c’est cela qui est fantastique.
Les meilleurs se remettent en cause continuellement. Aucune position n’est immuable. Assurer la qualité que vous constatez sur des sites grand public comme Amazon, Google, Facebook ou Apple est un travail énorme, de chaque instant qui nécessite, outre des compétences très fortes, des indicateurs précis et utiles.
Sans ces indicateurs, les compétences humaines, rares et coûteuses, sont mal utilisées et perdent trop de temps là où une automatisation et une meilleure information est possible.

Trop souvent, les utilisateurs se plaignent de la durée d’une panne et pensent que les ingénieurs sont incompétents, ne savent pas réparer. Mais savez-vous que l’essentiel de la durée d’une panne, ce n’est pas réparer mais savoir d’où vient la panne et pourquoi ?

Seul un véritable monitoring de bout en bout avant, pendant et après modification peut aider, comme un GPS ou une boussole, à conserver un cap et savoir où l’on va.

Comment mesurer la latence ? Quoi mesurer ?

Trop souvent, on voit des gens confondre le fameux “ping” et parler de latence, alors qu’ils mesurent un aller et retour de paquets dans un mode de fonctionnement de l’Internet (ICMP), où il n’y a aucune application qui fonctionne !
La plupart des applications que nous utilisons fonctionnent en TCP ou en UDP, pas en ICMP et les réseaux sont souvent organisés pour optimiser ces modes et traiter l’ICMP “as time permiting”, voir ne pas le traiter du tout en le filtrant pour éviter que des masses de gens ne perturbent la performance des routeurs en passant leur vie à faire des “pings” dessus.

Nous ne disons pas que le ping ne sert à rien, c’est un bon premier outil de “debug”, utilisable par tout un chacun pour :

  • savoir si une destination est toujours atteignable (reachable)
  • avoir une première idée du délai de réaction de certains segments.

En effet, autant une mesure absolue ICMP ne veut pas dire grand chose, autant une destination qui a l’habitude de répondre en 60 ms et qui se met à perdre des paquets et à répondre en 800 ms est un bon indicateur de problème de transport. (lien saturé, mauvaise qualité, attaque DoS en cours…)

Si l’on veut vraiment faire quelque chose pour améliorer la latence, il faut donner les bonnes méthodes et les bons outils aux développeurs et aux dev-ops, chargés du maintien en conditions opérationnelles. Il faut passer de la latence théorique à la latence réelle, c’est à dire, la latence applicative “de bout en bout”.

Pour ne pas être trop long et pour ceux que cela passionne, je vous engage à faire une recherche sur SYN / ACK et à mieux creuser tous les échanges qui se mettent en œuvre lors d’une session HTTP par exemple.

« Seul un véritable monitoring de bout en bout avant, pendant et après modification peut aider, comme un GPS ou une boussole, à conserver un cap et savoir où l’on va. »

Les exigences en termes de latence sont-elles les mêmes pour tous les services / usages ?

Et bien non. Autant il est stupide de dire qu’une connexion IP de qualité ne doit pas présenter plus de 10 puissance -8 erreurs, autant une latence de 10 ms n’est pas une catastrophe dans le cas de certains usages (mail / smtp par exemple) et totalement impossible dans d’autres. (voix… sans parler de ceux qui jouent au fast trading et se battent à coup de nano secondes).
La qualité d’un service doit se mesurer par rapport à l’usage réel qui est fait, sans extrapolation arbitraire, sinon on arrive à des approximations voir de complètes erreurs.

Prenons l’exemple de la vidéo. Les choses ont complètement changé depuis le broadcast traditionnel, jusqu’à l’OTT d’aujourd’hui, en passant par l’IPTV. On peut maintenant regarder parfaitement une vidéo avec une forte latence, simplement parce que les développeurs ont compris l’Internet et ont inventé des protocoles qui tirent partie des faiblesses possibles pour en faire une force. Je pense à l’HTTP Live Streaming (aka HLS) en particulier. La troisième révolution amenée par Apple, après l’iPhone et l’iPad dans les années 2007-2009.

Comment faire alors ? Par où commencer ?

Et bien déjà par mesurer. Mais mesurer quoi ?

Dans l’idéal, il y a deux choses importantes à connaître :

  • la qualité du service (pas la qualité de service, aka QoS, mais bien la qualité du service. Chez Witbe, nous avons inventé une méthodologie qui classifie cette qualité, au travers d’une mesure que nous appelons QoE au travers de 3 axes :
    • la disponibilité
    • la performance
    • l’intégrité
  • la qualité de la couche transport (le niveau 3, le niveau IP). En effet, autant la première mesure nous permettra de savoir ce qu’il se passe, autant cette deuxième permettra d’aller plus loin dans le “root cause analysis” et de comprendre le pourquoi. Chez Witbe, nous sommes joueurs…  nous avons appelé « SMARTPING » cette mesure, ou plutôt cette ensemble de mesures que nous avons inventé dès 2000.

 

Passer du contrôle à la maîtrise grâce aux bons indicateurs

Avec les bons indicateurs, on peut mieux comprendre les incidences d’un changement de routage sur la performance et la qualité d’un service. On pourra immédiatement diagnostiquer une performance fluctuante à cause d’une asymétrie de routage… Sans cela, c’est assurément chercher une aiguille dans une botte de foin et continuer de prétendre que l’on ne peut pas assurer une bonne qualité de service parce que “Internet”. C’est le fameux “c’est la faute au Net”.

Chez Witbe, notre métier depuis 16 ans est d’aider les acteurs du numérique à passer du contrôle à la maîtrise. Là où hier l’un des moyens pouvait être le contrôle, au travers de systèmes de mesures de la QoS, aujourd’hui ce n’est plus suffisant et il est essentiel d’aller plus loin, grâce à une véritable politique de maîtrise de la QoE. C’est à ce prix que l’on tirera partie de tout le potentiel des technologies issues de l’Internet et que l’on arrêtera de subir ré-activement en devenant pro-actif.

Pour plus d'informations sur nos technologies de test et de monitoring, n'hésitez pas à nous contacter!