|
|
| Accueil |
|
| Autres Liens |
|
| Partenaires |
|
| Annonces Publicitaires |
|
|
|
|
L'architecture système de Facebook : le vice-président technique s'exprime
Publié par La Rédaction le 2009-09-24 18:03:31 dans Web Social 
 Le vice-président du département d'ingénierie de Facebook, s'exprimait le 22 Septembre, dans le blog du Massachusset Institute of Technology (MIT) sur les défis posés par la gestion d'une plateforme utilisée par 300 millions d'utilisateurs. L'interview originale est disponible sur Technology Review,
En voici une traduction en français.
Technology Review : Qu'est ce qui rend la montée en charge sur un réseau social différente d'un site de news par exemple ?
Mike Schroepfer : Presque toutes les parties du sites ne sont accessibles qu'en mode loggé, et sont personalisées. Ce n'est pas vrai pour la plupart des autres sites.Ainsi, ce que vous voyez est très différent de ce que je vois, et également différent de ce que votre soeur voit. Et cela n'est pas vrai uniquement de la la page d'accueil, mais de tout ce vous pouvez voir dans le site. Votre vision du site change en fonction de qui vous êtes, et de qui fait partie de votre graphe social, ce qui augmente considérablement la charge de calcul nécessaire pour maintenir le service.
TR : Que ce passe-t-il quand je me mets à intérragir avec le site ? Cela doit rendre les choses encore plus complexes.
MS : Si vous êtes un de mes amis et que vous devenez un fan de la page de Green Day par exemple, je vais le voir sur ma page d'accueil, soit dans les "Morceaux choisis", soit dans le "flux".
Si je le vois dans le flux, je saurais également que trois de mes autres amis sont également fans. La simple tâche de mettre en place cette page d'accueil requiert d'interroger en temps réel cet ensemble de données très riche en interconnections - nous appelons cela le graphe - et de l'afficher à l'utilisateur final en l'espace de quelques secondes, voire en une seconde. Nous faisons cela des milliards de fois par jour.
TR : Comment vous-y prenez-vous ? La plupart des sites qui gèrent une grande base de membres recourent à la mise en cache, qui consiste à calculer le rendu d'une page et à la stocker une fois pour toutes, puis à l'afficher de nombreuses fois. Il semble que cela ne fonctionnerait pas pour vous.
MS : Une des meilleure armes des sciences informatiques, c'est effectivement la mise en cache. Mais si votre page d'accueil, comme c'est le cas pour Facebook, est mise à jour toutes les minutes ou moins, alors c'est une nouvelle page ou en tout cas un nouveau contenu qui s'affiche à chaque fois que vous la chargez. Du coup, le principe du cache est hors-sujet. Effectuer des opérations en temps réel, ou en quasi-réel, place le système sous une grande pression, car la fraîcheur, l'aspect "en live" des données, implique d'effectuer beaucoup plus de requêtes en temps réel.
Nous avons mis en place deux ou trois systèmes pour ce faire. L'un d'entre eux est une base de donnée MMDB [mémoire sans mécanisme de disque dur, NDR] qui conserve une traçabilité de ce qui se passe dans votre réseau d'amis, et qui peut retourner l'essentiel des résultats très rapidement. Beaucoup plus rapidement que si nous devions effectuer des requêtes en base de donnée, par exemple.
Et puis nous avons une architecture système originale sur laquelle nous distribuons et greffons toutes ces données.
Il y a beaucoup trop de données mises à jour beaucoup trop vite pour que l'on puisse se permettre de les placer dans une grande base de donnée centralisée. Cela ne fonctionnerait pas. Donc il nous faut les séparer, et les distribuer entre plusieurs milliers de bases de données, puis nous mettre en capacité d'interroger ces bases très rapidement.
TR : Que se passe-t-il quand vous ajoutez de nouvelles fonctionnalités au site ?
MS : L'ajout de nouvelles fonctionnalités peut modifier le comportement des utilisateurs de façon assez spectaculaire, ce qui a des implications aussi spectaculaires sur l'architecture système. Un simple exemple. Nous avons ajouté la fonctionnalité "J'aime" en Février de cette année. Il s'agit d'un simple pousse levé que l'utilisateur peut actionner pour signifier "J'aime cela". Nous avons eu un long débat en interne, pour savoir si cette fonctionnalité allait cannibaliser les commentaires. Cela s'est révélé addictif ; le système de commentaires
est resté identique et la fonctionnalité "J'aime" est devenue l'une des actions les plus populaires à l'intérieur du système.
Ca n'a l'air de rien, mais l'un des plus gros défis dans la construction de systèmes complexes et adaptatifs, c'est justement ça [il est plus facile de récupérer des données dans une base de données que de les y stocker]. Chaque fois que je clique sur le bouton "J'aime", il faut mémoriser cette action quelque part, de façon persistante.
Si nous avons conçu le système en imaginant que nous ferions surtout de la récupération de données, nous avons dû tout revoir depuis le début quand il a fallu modifier les fonctionnalités du produit. Nous faisons de vrais efforts pour ne pas trop s'accrocher à nos suppositions de départ, et nous tenir prêt à les remettre en question quand nous modifions le noyau dur du produit. C'est assez difficile.
TR : Et comment faites-vous pour intégrer ces nouvelles fonctionnalités dans l'architecture déjà existante ?
MS : Une de nos grandes forces est que nous sommes capables "d'ouvrir les vannes" d'une fonctionnalité. Passer de zéro à 300 millions d'utilisateurs en une après-midi pour une toute nouvelle fonctionnalité, c'est assez fou. Et nous pouvons le faire car, d'une façon générale, toute l'architecture est partagée. Vous pouvez ouvrir les vannes
et passer de 1% à 100% d'adoption en un seul jour, sans que ça entraîne trop de ralentissements.
TR : Mais votre problèmatique n'est pas seulement liée aux mises à jours et à la complexité - il y a également le problème du stockage. Facebook délivre des tonnes de photos. Est-ce que le système a été pensé dès le début pour une telle montée en charge ?
MS : Depuis peu, avec l'arrivée des téléphones pouvant prendre des photos et l'intégration directe via les applications smartphone, il y a une quantité impressionnante de photos uploadées et partagées sur le site. Notre premier système de stockage était basé sur des outils de stockage standards connectés en réseaux, le tout relié à des serveurs. C'était fonctionnel, mais pas suffisamment, et c'était très couteux. Nous avons procédé à des réglages sur ce système pour améliorer les performances et nous sommes parvenus à les augmenter par un facteur 5 ou 6.
Puis nous avons conçu un système de stockage original appelé Haystack, basé sur un hardware unique. Il s'agit de puces Intel et des static drives, le tout surmonté d' une mémoire stack customisée, qui nous permet de stocker et délivrer les photos depuis un stockage tiers.
C'est nettement plus rapide que les solutions de stockage standard et aussi nettement moins cher. Nous avons fait beaucoup d'efforts sur le stockage de photos, car la montée en charge est stupéfiante.
TR : Comment pouvez-vous êtes sûr à l'avance que vous pourrez implémenter les changements sur votre architecture ?
MS : Une fois ou deux nous avons entrepris des projets sans trop savoir si nous pourrions réussir - il y en a un dont je ne peux pas parler car nous ferons une annonce plus tard cette année. Il y a des fois où nous essayons de faire quelque chose que beaucoup d'autres ont essayé avant, mais où nous pensons que nous pouvons faire mieux. Je pense que le courage et la volonté de s'investir sont les aspects les plus importants car, sans cela, la meilleure planification possible ne vous mène nulle part.
Ecrit par Yohann Mathieu
Tags de l'article : architecture système mémoire serveurs bases de données
|
|
|
|
|
|
|
|
