La gestion de la croissance chez facebook
Aditya Agarwal est ‘Director of Engineering’ chez Facebook et il nous fait de nouveau bénéficier de son expérience au sein de cette énorme système de plusieurs dizaines de milliers de serveurs (60 000 à ce jour). Dans cette nouvelle présentation il nous explique notamment comment il a fait évoluer les outils internes afin de les optimiser au fur et à mesure de la croissance du site.
Comme d’habitude avec ce type de présentation, les conseils sont à appliquer sur des échelles différentes. Mais indépendament des points techniques sur les logiciels et les détails d’architectures Aditya nous donne plusieurs conseils pour faire évoluer une infrastructure de manière réaliste et pragmatique.
Au programme ‘progression par itération‘ ou ‘éviter de faire trop design‘ … conseils de bon sens mais qu’il est toujours bon d’avoir en tête pour planifier correctement les évolutions de votre plate forme.
Enfin, si vous avez le temps de regarder cette présentation entièrement vous découvrirez quelques informations techniques et optimisations réalisés au sein de l’entreprise. De nouveau, elles ne sont pas toutes applicables dans les architectures plus standard. Il en effet peu fréquent d’écrire un compilateur PHP vers C++ pour optimiser les consommations des pages PHP. Même si avec ce graph il est assez facile de comprendre pourquoi :
Sources :
- http://www.datacenterknowledge.com/archives/2010/06/28/facebook-server-count-60000-or-more/
- http://highscalability.com/blog/2010/6/10/the-four-meta-secrets-of-scaling-at-facebook.html
- http://www.infoq.com/presentations/Scale-at-Facebook
Abonnement RSS
Moi-même ruby-iste je ne suis pas très objectif, mais attention à ce genre de diagrammes, et à ne pas trop en tirer des conclusions hatives. Déjà cela fait abstraction des options de compilation, implémentations différentes, des versions, etc. Ensuite, il y a facilement des rapports de 1 à 5 en terme de performance pur selon le framework utilisé. Enfin, tous n’ont pas les problèmes de facebook ou google, un langage plus rapide sur les temps de dév ou de maintenance pourra être adapté selon les projets (pour faire du J2EE toute la journée au boulot, j’affirme que 99% des projets de ma boite seraient bien plus adaptés à du php, python ou ruby..).
Merci pour les infos sinon que je garde comme d’habitude précieusement, et bonne continuation.
Oui effectivement Jean-Baptiste, je suis d’accord avec toi.
Les performances pures sont une chose, c’est bon de les connaitre mais il faut surtout les adapter aux moyens disponibles au moment de réaliser les développements. D’ailleurs si tu regardes les différents liens de mon article tu verras que des propos similaires sont également mentionnés.
C’est d’ailleurs complètement en ligne avec le conseil N°3 : Choisir le bon outil au bon moment !!!