Cloud : pourquoi la latence et le débit du réseau font-ils la différence ?

Cependant, la rapidité (latence) et la capacité (débit) du réseau des fournisseurs de cloud est généralement déterminante pour le fonctionnement de n’importe quelle application cloud.

En matière de cloud computing, le rôle du réseau est double :
•    Interconnecter les différents sites où sont stockées les données ; on compte généralement deux sites minimum, les données devant être dupliquées à deux endroits différents, même si vous n’avez pas choisi la localisation multiple pour vos serveurs informatiques.
•    Assurer la connexion entre les serveurs d’applications et les utilisateurs de l’application – souvent, elle se fait via Internet, mais certains utilisateurs internes (des machines automatisées par exemple) se connectent avec des réseaux privés étendus.

Pour chacune de ces fonctions, vous devez avoir une exigence particulière ou peut-être même un engament en termes de temps de réponse. Pour un service délivré via un serveur web, le temps de réponse idéal est en dessous des 200 millisecondes (0,2 seconde) – ce qui correspond au temps écoulé entre l’envoi de la requête par l’utilisateur et l’arrivée de la réponse dans son navigateur web. Au-delà cela impacte le confort de l’utilisateur. Si votre application implique une distribution/synchronisation des données entre les nœuds de serveurs, il y a exigence de rapidité sur l’échange d’informations entre ces nœuds, de l’ordre de 10 à 20 millisecondes, voire moins pour certaines applications haute performance.

Le temps de réponse comprend toujours deux parties : le temps pour le serveur de recevoir l’information, de calculer la réponse et de l’envoyer et le temps pour la donnée de parcourir le réseau entre l’ordinateur de l’utilisateur et le serveur, aller-retour. Le plus lent est la latence du réseau, le « round trip time (RTT) ». Alors qu’il existe des moyens d’accélérer le temps à l’intérieur de l’ordinateur ou du data centre (en ajoutant des CPUs, des processeurs et de la  mémoire RAM plus rapides, ou en adoptant un système de stockage moins lent ou encore en améliorant un algorithme et/ou l’implémentation d’un logiciel), le réseau représente une performance fixe du cloud, que l’on ne peut pas modifier.

Une hypothèse simpliste consiste à penser que, comme les données parcourent le réseau à la vitesse de la lumière dans les câbles en fibre optique (environ aux 2/3 de la vitesse de la lumière dans le vide, ce qui reste important), les données transitent d’une zone à l’autre à la vitesse de la lumière. C’est le cas, mais n’oubliez pas que, pour les transferts de données transcontinentaux, les distances sont importantes. La bonne mesure de la vitesse du transfert de données dans un câble fibre optique est de 5 microsecondes par kilomètre de câble. Concernant la latence, le temps est doublé puisqu’il s’agit d’un aller-retour, soit 10 microsecondes par kilomètre. La longueur de câble qui relie Londres à New York avoisine les 5 500 km, ce qui implique un temps aller-retour de 55 millisecondes (55 000 microsecondes). La latence réelle est plus importante parce qu’elle inclut le temps de conversion des signaux de l’électronique à l’optique et vice-versa, les délais imputés au matériel réseau, les délais dus à des corrections d’erreurs sur des paquets de données, etc. La règle la plus communément admise est celle de Peter Norvig et Jeff Dean chez Google, qui estiment à 150 millisecondes la latence entre la Californie et l’Europe (Pays-Bas).

Il ne faut donc jamais oublier que, pour les applications les plus courantes qui parcourent de longues distances entre deux continents, ou pour les systèmes haute performance qui exigent des temps de réponses ultra rapides, la latence réseau est la part la plus importante du temps de réponse. Par exemple, si vous devez fournir des services web entre l’Europe et les Etats-Unis, avec un temps de réponse de 200 millisecondes, sachez qu’il faut déjà compter 150 millisecondes de latence réseau. Par conséquent, chaque milliseconde gagnée en latence, est du temps en plus pour le traitement dans le data centre. Ce qui vous laisse le choix, en tant qu’utilisateur du cloud computing : soit vous économisez (vous utilisez moins de serveurs, moins de CPUs et des équipements plus lents) et vous acceptez une certaine lenteur, soit vous voulez traiter plus d’information et offrir à vos clients un service étendu de meilleure qualité.

L’autre élément clé de la mesure de la performance d’un réseau est le débit (ou bande passante), mesuré selon le volume moyen de données qui parcourt le réseau par unité de temps. Il est généralement mesuré en nombre de bits transférés, huit bits équivalant à un octet. Le débit n’est pas forcément critique pour les applications cloud. Généralement, les fournisseurs de cloud proposent des débits aux alentours de 300 Megabits/seconde, ce qui dépasse en principe le taux de transfert de données exigé par une application. Mais évidemment, pour certaines applications, le débit est crucial : pour le transfert de données vidéos, scientifiques, liées à l’Internet des Objets ou pour du big data temps réel.

Ce qui est critique pour les réseaux dans le cloud computing n’est pas seulement la performance finale mais la teneur de cette performance. Mesurer une latence moyenne à, disons, 20ms, est une chose, mais, si cette moyenne cache des variations de latence entre, disons, 20 et 100 ms, c’est une autre histoire, et ces variations doivent être prises en compte dans la conception de l’application. Le manque d’information sur la performance est un problème majeur lorsqu’on utilise Internet comme réseau entre différentes zones de cloud computing, ce qui est le choix par défaut de nombreux fournisseurs de cloud. Lorsque le fournisseur de cloud est propriétaire de son réseau, il ne passe pas par Internet entre différentes zones, mais par son réseau privé, faible latence, qu’il maîtrise de bout en bout, ce qui permet de maîtriser cette performance.