éco-conception logicielle : 10 fois moins de serveurs pour LinkedIn
[Mise à jour du 28/12/2013 – Fred Bordage : Dans l’interview (http://arstechnica.com/information-technology/2012/10/a-behind-the-scenes-look-at-linkedins-mobile-engineering/2/), Kiran Prasad précise que LinkedIn “a été en mesure de passer de 30 serveurs à trois, tout en ayant suffisamment de marge pour gérer environ dix fois le niveau actuel de l’utilisation des ressources”. A charge égale, LinkedIn a donc divisé par 112 les ressources informatiques nécessaires au fonctionnement de son site web mobile. C’est également ce que suggère le graphique ci-dessus. Notre titre était donc erroné.]
En août 2011, LinkedIn lance sa nouvelle application mobile issue de la refonte complète de leur architecture. Après un an de travail, les équipes mobile du réseau social professionnel parviennent à réduire leur infrastructure de 30 serveurs à seulement 3. Cette modification s’est faite sans réduction des performances. Au contraire, les équipes de LinkedIn constatent que la partie cliente est entre 2 et 10 fois plus rapide. Revenons sur cet évènement pour comprendre quels choix technologiques et logiciels ont pu permettre cette prouesse.
Un serveur web dans le terminal
La choses la plus étonnante, de mon point de vue, est l’intégration d’un serveur web dans le terminal mobile. Ce serveur web fait office de cache local et de moteur de rendu de modèles (template). Par exemple, lorsque l’on consulte un profil, seules quelques données changent entre les différents profiles. Et donc, au lieu de tout télécharger à nouveau à chaque nouvelle visite, on charge juste les informations relatives au profil visité . Si le modèle change, on le met à jour. Ceci permet donc de réduire drastiquement la bande passante utilisée mais aussi, les cycles CPU, les accès disque (IO) et la charge côté serveur. Je vous conseille de lire les point 4 et 5 de cet article sur le site de LinkedIn sur les performances de node.js.
D’après Kiran Prasad, le leader du département mobile de LinkedIn, l’architecture 3-tier n’est pas adaptée aux applications mobiles. Le terminal doit s’occuper du dernier tier (la présentation), comme on vient de le voir, avec le moteur de rendu intégré au client. Pour la couche “métier”, le 2ème tier, LinkedIn voulait une nouvelle technologie, plus adéquat pour des communications mobiles. L’équipe en charge du projet a alors imaginé que ce tier devait s’occuper de récolter les données aux différents endroits (le 1er tier – base de données), puis renvoyer le flux de données à l’utilisateur. Le résultat est une seule connexion, ouverte en permanence, qui envoie en une seule fois, toutes les données nécessaires, et zippées s’il vous plait. Ceci réduit les latences introduites par plusieurs connections simultanées, la bande passante utilisée et donc, encore une fois, la charge côté serveur.
Node.js plutôt que Ruby On Rails
Avant, LinkedIn utilisait les serveurs de Joyent comme proxy pour leur architecture mobile. Ce proxy écrit en Ruby On Rails, faisait l’interface entre l’application mobile et leur API. Lors d’une demande d’un utilisateur, un processus s’occupait de la demande. Ce processus faisait plusieurs appels vers l’API de LinkedIn. Il fallait attendre la réponse de l’API entre chaque appel et pendant ce temps, le processus était “occupé” et ne pouvait servir d’autres personnes. Imaginez. C’est comme faire du MySQL over HTTP entre 2 data centers : inefficient au possible ! LinkedIn s’est donc mis à la recherche d’un “collecteur” efficace, capable de faire les requêtes aux différents endroits en simultané.
L’équipe voulait un serveur applicatif léger et piloté par évènement (event-driven) pour éviter ces “temps morts”. Après plusieurs tests entre Ruby (EventMachine), Python (Twisted) et JavaScript (Node.js), il s’est avéré que le dernier est 20 fois plus performant dans certains cas. C’est d’ailleurs une des bonnes pratiques (n°74) proposée dans le livre éco-conception web : les 100 bonnes pratiques.
JavaScript nativement asynchrone
Sans entrer dans les débats partisans, la puissance de javascript réside dans sa conception asynchrone. Les 2 autres alternatives ont été rendues asynchrones alors que javascript l’est depuis la naissance, et c’est pour cela qu’il excelle dans son domaine! Néanmoins, l’équipe de LinkedIn rappelle ses limitations. Par exemple, pour du calcul intensif, il vaut mieux privilégier un langage compilé (point 8). Grâce à Node.js, le 2nd tier fait tous les appels au 1er tier en presque simultané, ce qui est incroyablement plus efficace que de la programmation synchrone (Ruby on Rails) dans ce cas précis.
Les points à retenir sont :
- rendu sur le terminal (seuls les données utiles sont envoyées au mobile, pas les modèles)
- réduction des IO entre client-serveur en ayant une seule connexion
- zip du flux de données
- utiliser le bon langage pour la bonne fonction
- compilé pour du calcul intensif
- javascript pour une programmation asynchrone
Les bénéfices sont multiples, plus de simplicité pour les développeurs, plus de rapidité pour les utilisateurs, moins de pannes pour les opérations, et moins de serveurs pour l’environnement (10x moins). Tout ça rendu possible grâce à une réflexion en profondeur sur l’architecture mobile et à l’optimisation de chaque composant.
Et vous, prévoyez vous de repenser votre architecture?
Pour aller plus loin :
– http://www.infoq.com/news/2012/10/Ruby-on-Rails-Node-js-LinkedIn
– http://arstechnica.com/information-technology/2012/10/a-behind-the-scenes-look-at-linkedins-mobile-engineering/2/
Source : http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobile
