Quand l’analyse réseau montre un problème applicatif !

À qui la faute ?

Ce n’est pas pour rien que nous avons lancé notre propre collection de stickers « It’s not the Network » et « It’s not the Application ». Qui n’a pas assisté à une scène où les équipes réseau et applicative se cachent derrière des indicateurs au vert en renvoyant la responsabilité sur l’autre ?

       

Chez Phenisys, nous sommes là pour trouver des solutions et non pointer du doigt l’équipe en cause. Pour cela, nous intervenons avec des outils et une méthodologie qui apporte un langage commun pour les équipes qui peuvent échanger sur des données factuelles.

Récemment, un de nos clients avait ces symptômes : une application fonctionnait bien tant que les clients étaient dans le même VLAN que le serveur. Lorsqu’une notion de routage apparaissait, l’application devenait inutilisable, car les informations remontaient avec un décalage de plusieurs minutes.

À première vue, tout semble indiquer un problème réseau. Or tous les indicateurs et les métriques de performance réseau étaient bons, même en période de forte charge.

L’analyse réseau (via des traces) et une pointe de reverse engineering ont montré que l’application avait un fonctionnement où chaque client lisait un fichier plat afin d’afficher les nouvelles informations sur une interface. La lecture de ce fichier était séquentielle et dictée de manière centrale par le serveur à tous les clients.

Exemple concret

Le client « routé » demande 602 octets à partir de l’emplacement 1000, il obtient donc des informations jusqu’à l’emplacement 1602.

Mais à l’itération suivante, l’offset à lire est le 1039 (due à la gestion centrale de cette valeur par le serveur), il demande 602 octets. Il obtient donc les valeurs entre l’emplacement 1039 et 1641.

Or, à l’itération précédente, il avait obtenu des informations jusqu’à l’emplacement 1602, il a donc obtenu 39 nouveaux octets (1641–1602=39), soit 6.4% de données utiles sur les 602 demandées. Cette itération a donc rapatrié 93% de données déjà rapatriées à l’itération précédente. 

Pourquoi la gestion centrale demande-t-elle de lire un emplacement si loin ? Car les clients non routés ont une latence 2x plus faible que les clients routés (latence WAN : 20 ms contre 9ms en moyenne). Chaque itération est donc 2x plus rapide, est nécessite donc de lire moins de nouvelles données.

Cela produit donc des retards pour les clients routés, retard qui peut amener à des décalages de plusieurs minutes (voir de dizaines de minutes comme ici).

Nous avons donc une application faite pour une utilisation locale. Un changement des conditions réseau amène à une application inutilisable.

Quelle est donc la solution ?

Proposition n°1 : mettre tous les clients en local. Oui, mais pas faisable…

Proposition n°2 : réduire la latence des clients routés. Oui, mais cela équivaut à rapprocher les utilisateurs des datacenter, géographiquement distants, ou à augmenter la vitesse de la lumière. L’un est couteux, l’autre est physiquement compliqué.

Proposition n°3 : modifier l’application de sorte que chaque client lise à son rythme le fichier central en prenant en compte le fait que les clients peuvent avoir des latences réseau différentes.