Des informations techniques précises sur les causes du problème ont été publiées. Voila donc l’occasion d’expliquer l’architecture technique du site de manière simplifiée pour les non techniciens.

500 millions d’utilisateurs, et parmis eux presque 100 millions qui se connectent au moins une fois par jour, ça fait beaucoup de données qui transitent sur le réseaux (images, wall, news feed etc…)  et beaucoup à  stocker.

Evolution du traffic réseaux lors de la panne

Pour tenir la charge (c’est à dire le niveau de travail demandé pour ce service en termes de puissance machine) pas moins de 60 000 serveurs sont utilisés. Pour info google c’est 2 millions mais vous l’avez compris 60 000 c’est déjà une trés grosse infrastructure.

A ce niveau, la ressource machine est précieuse. Stoquer un nouveau format de vignette par exemple plus large ou un format panoramique pour vos photos  peut nécessiter plusieurs milliers de serveurs en plus.  Avec une telle échelle, les architectes techniques de facebook doivent redoubler d’ingéniosité pour rendre le service dans des délais acceptables (temps d’affichage d’une page) mais surtout pour que tout cela soit simplement possible.

Cache?

Pourquoi stocker une information si je  peut la calculer à partir d’autres informations présentes?

Exemple: dés que l’utilisateur arrive sur mon site, je récupére sa date de naissance dans la base, calcul son age et l’affiche.

Plus proche de la réalité: aller chercher l’age dans la base à un coup conséquent en ressources machines. Mon serveur web (front) doit se connecter à la base, lui demander de fouiller dans le disque dur pour trouver le segment de données qui contient la date, et la récupérer en local, dans sa mémoire. Mais un disque dur c’est lent, beaucoup plus lent que la mémoire vive qui est la plus rapide quand il s’agit de récupérer/lire des données.

C’est la qu’intervient le cache. La première fois qu’on demande une information, je vais la chercher sur les serveurs concernés (trés lent) et je garde l’information en mémoire vive. La deuxième fois je ne refait pas tout le travail!  Je vais chercher l’information dans la mémoire RAM directement.

Un cache peut être invalidé. Par exemple si l’utilisateur change sa date de naissance, la donnée en mémoire n’est plus bonne. Mon application doit détecter que le cache n’est plus valide, aller chercher la valeur à  jour, et la stocker à nouveau en mémoire.

Je peut aussi donner un timeout à mon cache.  Je décide que 3600 secondes aprés qu’il ai été créé il sera invalidé et mon application devra le reconstruire avec les données à jour.

Sans cache, pas de facebook!

L’incident du 23 septembre est exactement un problème de cache. Facebook  a mis en place un robot (un logiciel autonome) qui parcours en permanence les serveurs et examine les caches un à un. Si il n’est pas à jour, il va récupérer la données dans le cluster (groupe de serveurs) de base de données concerné et remplace la donnée invalidée par la nouvelle.

Le problème c’est que ce robot a planté: il a remplacé l’ancienne donnée du cache invalide par une donnée erronée donc encore détecté comme invalide!

Quand un utilisateur se connectait sur le site (pour faire simple…) le cache était consulté, les données considérées comme obsoletes (cache miss) et les vrais données demandées aux bases. Ces dernières se sont retrouvées surchargées de requêtes.

Les serveurs se sont vite écroulés, ne pouvant assumer tout le travail qui leur était demandé, beaucoup plus que ce qu’ils peuvent traiter. Les ingénieurs n’ont pas eu d’autres alternatives que de couper le réseau entre les bases et les frontaux web (reboot). Le site était donc complétement indisponible a ce moment (ainsi que les boutons “j’aime” présent sur tous les sites tiers d’ailleurs).

Les connections ont étés réouvertes progressivement, afin de reconstruire tous les caches en toute sécurité.

Le monde entier a alors repris un activité normale …

ps:

Si vous êtes technicien, voici un lien, sur mon blog technique, vers une conférence d’un directeur technique de facebook par laquelle j’ai appris beaucoup sur l’architecture de ce réseau social.

Extreme Programming | Crossbow Labs

# Pratiques

Les tests unitaires | Crossbow Labs

Principes avancés de conception objet | Crossbow Labs

Fat Agnus » Program to an interface, not an implementation

Principles Of Object Oriented Design

ArticleS.UncleBob.PrinciplesOfOod

My. Debian. » java as a daemon service

Using Automake and Autoconf with C++

Native C++ “Hello World” working in emulator – Android and G1 Forums, Mods, Hacks, News, Downloads, Skins, Themes, and more! | ModMyGphone

http://www.danlj.org/lad/src/sighup.c

Daemon en c qui catch les appels sighup. Court et instructif.

Quelles technologies utilisent-ils? Quelles problématique rencontrent-ils? Qu’en est il des interruptions de services? Ces blogs sont aussi écrits par des techniciens qui souhaitent partager leurs expérience professionnelle.

Communauté: Technology – Second Life Blogs

Twitter Blog

Amazon Web Services Blog

The LinkedIn Blog Engineering «

Facebook | Engineering @ Facebook

Code: Flickr Developer Blog

Digg the Blog » Digg Technology

Des études de cas sont détaillées avec leurs sources.  Sur la home page vous avez un fil d’infos avec les dernières news. Je suis déja fan de ce site peut être aussi parce qu’il comblait chez moi un manque d’infos de cette nature. On imagine toujours que les gros sites gérent de grosses fermes de serveurs, un gros volumes de données, mais tous cela ne s’empile pas n’importe comment!

Les architectes systèmes font preuve d’ingéniosité, et leurs idées sont stratégiques pour leur entreprise et leur compétitivité: c’est cela que je trouve admirable.

Si de votre coté vous connaissez d’autres sources d’informations sur l’architecture des services n’hésitez pas a le poster en commentaire!

Haute Disponibité