wOueb by Romain DECKER / Another IT Guy Blog

Facebook est une vraie machine de guerre : on a pu voir récemment que c’était le site le plus visité au monde, et tout ça seulement après quelques années. Contrairement à d’autres « supergrands » (Google, Microsoft, Apple, Youtube, etc.) un certain nombre d’informations filtrent lors de conférences, et dans des documents officiels.

Je rappelle que pour écrire ces 2 articles, j’ai simplement visionné des vidéos de conférences pour compiler les informations. Vu la masse de détails obtenus, j’ai publié deux articles :

• le précédent, présentant les chiffres clés sur l’infrastructure de Facebook,
• celui-ci : comment Facebook gère quotidiennement son (immense) infrastructure ?

En extrapolant plusieurs données (graphiques d’évolution, chiffres passés, etc.) on estime entre 60 000 et 100 000 le nombre de serveurs de Facebook .

Facebook : évolution du nombre de serveurs

Cependant, ce chiffre ne tient pas compte de deux nouveaux datacenters actuellement en cours construction (Oregon et Caroline du Nord).

Facebook a depuis longtemps atteint une masse critique qui nécessite de voir sa copie en terme d’administration quotidienne.

Un des ingénieurs de Facebook a bien illustré le problème lors d’une conférence :

With Facebook users spending a collective 8 billion minutes on the site each day, serving 1.2 million photos each second, and managing more than 25 terabytes of data per day in logging data, we’re forced to think about servers and datacenters differently.

Nb : les chiffres sont de 2009, les actuels sont présents dans mon article précédent.

Les datacenters

Jusqu’à présent, Facebook n’avait pas de datacenter propre : la société ne faisait que louer de l’espace à divers spécialistes du domaine. Décidés au début 2010, deux nouveaux datacenters font partie d’un plan d’investissement global décidé par Facebook.

• Un nouveau datacenter en Oregon : plus de 28 000 m², pour plus de 450 millions de $,
• Un nouveau datacenter en Caroline du Nord.

Vous pouvez suivre l’évolution de la construction de ces nouveaux datacenters sur :

• facebook.com/prinevilledatacenter
• facebook.com/rutherforddatacenter

Nb : vous pouvez noter que la totalité des serveurs de Facebook sont aux États-Unis, c’est donc la loi américaine qui s’applique aux données hébergées par Facebook.

Les serveurs

Au vu de la popularité exponentielle de Facebook, il a été nécessaire d’utiliser toutes les possibilités pour optimiser l’infrastructure :

• scalabilité horizontale : utilisation massive de petits serveurs quad-core,
• optimisation :
  • du système d’exploitation,
  • des applications,
  • de l’accès aux données,
  • de l’échange entre les différents systèmes.

Comme beaucoup d’autres, Facebook utilise une architecture LAMP (Linux / Apache / MySQL / PHP) :

• Linux : il s’agit d’une version de CentOS, avec un kernel 2.6 customisé,
• Apache 1.3,
• MySQL 5.1 (passage à la version 5.5 prévu à moyen terme),
• PHP5.

Facebook a conçu HipHop PHP qui traduit le code PHP en C++, celui-ci étant compilé avec G++. Après plusieurs mois de tests, HipHop PHP a été déployé en 2008 : le jour du déploiement, la consommation CPU totale a baissé de 50% (excusez du peu) !

Le code est disponible depuis février 2010 ; voici l’annonce faite par un des développeurs : HipHop for PHP, Move Fast.

L’administration

Dans les diverses vidéos, on apprend plusieurs choses intéressantes sur l’administration quotidienne chez Facebook.

• Le code web est distribué via des serveurs Bittorent internes, ce qui permet de pousser les modifications de code web en 1 minute seulement sur tous les serveurs : cela représente quelques centaines de mégaoctets pour quelques dizaines de milliers de serveurs.
• Facebook utilise CFengine pour l’automatisation de la configuration des serveurs : il s’agit d’ailleurs de la plus grosse infrastructure CFengine dans le monde. CFengine vérifie à intervalles réguliers (15 minutes chez Facebook) la configuration des serveurs, et les mets en compliance.
• Utilisation majeure d’IRC en interne et des bots pour l’automatisation des tâches récurrentes.
• Les 25 TB de logs qui sont produits par jours sont stockés dans Scribe, un serveur de logging spécifiquement créé par Facebook pour leur besoin.
• Les modifications du schéma des bases de données peuvent être faite directement en ligne, via un OSC (Online Schema Change).
• Les pannes matérielles (cartes réseau, RAM, etc.) sont traitées automatiquement.

C’est avec ce type d’astuces (et bien plus encore) que Facebook peut se permettre de n’employer qu’un seul ingénieur pour 1,1 millions d’utilisateurs.

Le monitoring et la supervision

Le nerf de la guerre dans une infrastructure informatique est de savoir ce qu’il se passe sur chaque composant de cette infrastructure. Facebook ne déroge pas à la règle, et a intégré plusieurs solutions de supervision et de monitoring pour l’ensemble de ses services.

Pour la surveillance « basique« , Facebook utilise Nagios. Il s’agit de tests simples, comme :

• ping,
• telnet vers le port SSH,
• telnet vers le port 80 pour vérifier que les serveurs web sont démarrés,
• etc.

Les alertes de Nagios ne sont pas envoyées par mail, mais sont insérés dans un outil interne à Facebook qui permet de les analyser. Une fois agrégées, les alertes sont traitées automatiquement. Tout l’intérêt réside dans le fait de pouvoir classer les alarmes par urgence, par type, par datacenter, par localisation géographique (jusqu’aux racks), par cluster, etc.

Un second monitoring, plus complet (5 millions d’objets mesurés) est réalisé via Ganglia qui a pour avantage d’être très rapide (mise à jour toutes les minutes), et qui permet de découper logiquement en « grid » (cluster) le monitoring.

Le monitoring applicatif est fait avec un Operationnal Data Store (ODS) : un ODS est une base de données conçue pour regrouper des données de sources hétérogènes (dans ce cas, des sondes multiples, des temps de réponses, etc.) dans un but de faciliter les analyses et le reporting. Les données obtenues sont stockées dans un datawarehouse.

Cet ODS permet à Facebook d’utiliser les données pour du reporting, de la transformation, des comparaisons, le tout avec une vision historique des objets.

Enfin, dernier élément essentiel, MySQL est particulièrement surveillé :

• show variables,
• via Nagios,
• MySQLd error logs,
• etc.

Enfin, Facebook a découpé son infrastructure en unités logiques afin d’optimiser la tolérance aux pannes :

• serveurs,
• racks,
• clusters (plusieurs milliers de serveurs),
• datacenters.

Ainsi, des scénarios peuvent être envisagés pour les pannes de chaque élément logique. Que se passerait-il par exemple, si tel rack avait un souci d’alimentation électrique ? Ou si tel ou tel datacenter ne serait plus joignable ?

Les problématiques

Comme la majorité des sites dynamiques, Facebook fait face à une problématique majeure : les connexions au sites ne sont pas homogènes dans le temps et ne sont que partiellement prévisibles. En effet, un certain nombre d’évènements prévisibles génèrent beaucoup de mises à jours (statuts, photos) : le nouvel an, le jour après Halloween, les soirs d’élection, etc.

D’autre part, certains évènements sont totalement imprévisibles et génèrent une forte augmentation de traffic : on peut penser à la mort de Mickael Jackson par exemple, qui a généré un gros pic de bande passante et de mises à jour de statut.

Par ailleurs, des problématiques techniques majeures apparaissent au fur et à mesure : par exemple, la demande en bande passante évolue beaucoup plus rapidement que la roadmap des constructeurs pour les éléments de réseau actifs (switchs de niveau 3, routeurs, etc.).

Conclusion

Facebook fait face tous les mois à plus de 690 milliards de pages vues, et le nombre d’utilisateurs actifs est toujours en croissance. Les techniques applicables dans le monde de l’entreprise sont bousculées, il faut sans cesse visionner le développement à long terme pour pouvoir faire face à une demande toujours plus grande.

Dans les cas de telles infrastructures, il ne faut pas hésiter à faire à développer vos propres systèmes et solutions, comme Facebook l’a fait avec HipHop PHP, Scribe, etc.

Enfin, le découpage logique de toutes les entités est un vrai plus pour l’administration, la supervision, et surtout la reprise sur incident.

Sources :

• A Day in the Life of Facebook Operations,
• Facebook on Bandwidth,
• MySQL Tech Talk.