QCon (suite) et les grands du web

le 20/04/2010 par Andre Nedelcoux

Parmi les différentes tracks à QCon, une était dédiée aux "architectures sur lesquelles vous vous êtes toujours posé des questions" - comprendre grosso-modo les architectures des grands du web. Comme c'est un sujet qui m'interpelle (nous y avions d'ailleurs consacré une session à USI 2009 avec Olivier Mallassi), j'ai donc assisté à certaines présentations. Je voulais partager avec vous les quelques enseignements que j'en ai tiré : vous allez voir, les chiffres sont encore une fois impressionnants :)

Facebook

Si le track n'était finalement pas à la hauteur de mes attentes (les speakers ne sont malheureusement pas allés loin dans les détails), les retours issus de la présentation du directeur de l'engineering de Facebook portaient quelques enseignements intéressants (malgré une tradition, encore une fois respectée de "en dire sans trop en dévoiler"):

sur PHP tout d'abord : "PHP est très simple pour développer mais... difficile à scaler" (dixit Aditya Agarwal, responsable de l'Engineering). Difficile de scaler l'écriture de code, lorsque celui-ci devient complexe, le langage ne faisant rien pour pousser aux bonnes pratiques de développement et le découpage en "modules" étant complexe. Difficile de scaler l'exécution du code, la construction de pages étant jusqu'à "10 fois plus longue qu'en java ou c#" - la conséquence de ce dernier point étant que les équipes de Facebook ont ré-écrit un compilateur php to c++ (18 mois de travail pour coder Hiphop) pour permettre de servir 400 millions d'utilisateurs (aouch!). Alors bien entendu, l'échelle de Facebook n'est pas celle d'un projet lambda, mais ces retours sont tout de même intéressants. Ont-ils de regrets à être partis sur PHP? "Non, qui sait quelles limites nous aurions tapé dans un autre langage!".
sur leur architecture : le plus gros point douloureux reste le fait d'avoir "posé le cache de données trop loin de la base de données" et de manière indépendante. La conséquence est qu'aujourd'hui ils ont beaucoup de problèmes de corruption de cache et d'inconsistances des données et que finalement pour des petites équipes cette gestion du cache "à côté" rend les développements complexes. Il est intéressant de noter ici la différence entre du pur cache (comme memcached, utilisé chez facebook) et les solutions nosql, présentes chez beaucoup d'autres acteurs, qui gèrent un datastore permettant d'assurer la durabilité des données et dont le haut niveau de performance peuvent permettre d'éviter l'utilisation d'une solution de cache dans l'architecture. D'ailleurs, c'est d'autant plus dommage dans le cas de Facebook que... les MySQL déployés sur 6000 serveurs ont progressivement basculé vers une utilisation en stockage clef/valeur à partir de l'approche relationnelle initiale (CQFD).
enfin, un chiffre pour terminer : 30% des charges de développements des équipes Facebook sont consacrées à des tâches techniques. Et chez vous?

Il est intéressant de noter cette dynamique de reversement vers l'open source de frameworks et produits que certains acteurs d'internet ont amorcé (on peut également citer LinkedIn et son produit Voldemort) : ces nouveaux types de contributeurs vont-ils faire l'effort de transformer leurs frameworks internes en véritables produits? la mayonnaise va-t-elle prendre et vont-ils se populariser, avec une vraie communauté? L'avenir nous le dira

Skype

La présentation du responsable de l'Engineering de Skype qui a suivi était, elle, plus à rebrousse-poil de certaines idées préconçues sur les "bonnes pratiques d'architecture". En effet:

chez Skype, ils adorent la procédure stockée! et d'ailleurs, la plupart de leur code est dans la base (PostgreSQL)
le gros du volume et de la complexité de leur architecture est dans le traffic peer-to-peer: lors d'une communication entre deux internautes, presque rien ne passe par des serveurs Skype ce qui permet au système de scaler extrêmement facilement. La conséquence négative de cette approche est qu'il devient difficile de pousser des informations vers le client et de connaître ses usages.
le client Skype est développé en... Delphi et ils se heurtent aux classiques (mais exponentielles à leur échelle) limites du déploiement d'une application client lourd. Ainsi, comme il est difficile de forcer les gens à monter de version du client, le multi-version est de rigueur, ce qui freine sur le rythme auquel il est possible de mettre à disposition de nouvelles fonctionnalités (fini le "permanent beta" dans ce cas). Vous aussi, vous avez 10 applications natives sur votre iPhone non mises à jour? Mettez-les à jour, vous rendrez heureux des ingénieurs à travers le monde :)

Gilt.com

Enfin, le VP IT du site internet Gilt faisait un retour très intéressant sur les patterns d'architecture mis en oeuvre. La particularité du site est de connaître un pic de charge de plus de 500 000 utilisateurs en concurrence sur une fenêtre d'une demi-heure (lors de l'ouverture de la boutique en ligne) - "it's like launching a rocket everyday". Beaucoup de données et d'idées intéressantes lors de cette session, mais j'en envie de retenir les suivantes:

l'architecture a été adaptée à chaque use case : selon que l'on affiche une page en lecture, une page en écriture mais où l'on tolère des données inconsistantes (ex : ajouter à son caddy un objet qui n'est plus en stock, le dernier ayant été vendu après la construction de la page) ou une page en écriture où l'on ne tolère pas d'inconsistance (ex : la page où le client paye ses produits), l'architecture n'est pas la même! Dans ce cas, l'utilisation de Voldemort a permis de gérer un paramétrage différent par type de données.
les besoins d'utilisation de la donnée étant spécifiques selon le type de la donnée, des ilots autonomes ont été construits sur les grappes de données, un ilot étant composé d'un noeud Voldemort, d'un service REST au-dessus des données exposant du JSON. L'utilisation de REST permet de load-balancer les accès via du load-balancing HTTP et donc de scaler très facilement.
Voldemort vs Tokyo Cabinet? Voldemort ! Geir Magnusson a mené de nombreux benchmarks sur plusieurs solutions noSQL avant de choisir Voldemort et son feedback est que Tokyo Cabinet, malgré la capacité à encaisser un très grand nombre d'updates / seconde, ne propose pas une stabilité suffisante en terme de performance : lorsque le nombre d'updates augmente, TC finit par flusher ces updates sur le disque, ce qui impacte fortement les temps de réponse.