Si la vie des vrais agriculteurs était aussi douillette que dans FarmVille, le jeu phare de chez Zynga, alors ma famille n’aurait probablement jamais quitté les hivers rudes du North Dakota. A FarmVille, aucun des contes atroces que me racontait ma grand-mère n’est véridique. Les agriculteurs y prospèrent, les cultures fleurissent, et les animaux ne partent jamais au «  red barn » (abattoir). A mon avis, c’est justement ce charme rustique d’un univers où l’on ne salit même pas ses souliers, qui a contribué à rendre FarmVille « le jeu le plus important au monde » dans un délai étonnamment court.

Comment FarmVille a-t-il réussi le scaling d’une application web pour accueillir 75 millions de joueurs par mois ? Luke Rajlich de FarmVille nous a gracieusement révélé quelques uns de leurs défis et de leurs secrets. Je passe la parole à Luke.

L’entretien comprenait quelques questions que je lui ai adressées, auxquelles il a répondu ainsi :

FarmVille a rencontré des défis de scaling rares, qui sont uniques à cette application. Le jeu a dû scaler très rapidement et très loin. Après seulement 4 jours, le jeu avait attiré un million de joueurs quotidiens, et 10 millions après 60 jours. Lors du lancement, le jeu social le plus important du web avait 5 millions de joueurs quotidiens. Actuellement FarmVille détient 28 millions de joueurs quotidiens, et 75 millions de joueurs mensuels, neuf mois après le lancement. Cela veut dire que le fond de joueurs mensuels FarmVille est plus important que la population totale de la France. Il y a deux éléments fondamentaux qui rendent FarmVille unique au niveau du défi évolutif : premièrement, c’est le jeu le plus répandu au monde, et deuxièmement, c’est l’application la plus importante sur une plate-forme web. Ces deux facteurs représentent un ensemble unique de défis évolutifs que FarmVille a dû surmonter. En termes d’investissement de technologie, FarmVille utilise principalement des composants Open Source, et ses fondements reposent sur la pile LAMP.

Afin de faire prospérer FarmVille en tant que jeu, nous devons nous accommoder des besoins en charge de traitement d’un jeu. L’état de chaque joueur contient une grosse quantité de données, qui sont liées entre elles de façon subtile et complexe. Par exemple, les objets à la ferme ne doivent pas se percuter, donc si un utilisateur installe une maison sur sa ferme, le Backend doit vérifier qu’il n’y aucun autre objet déjà installé qui risque de chevaucher sur l’espace prévu. La plupart des sites web connus, comme Google ou Facebook, servent surtout à être lus, mais FarmVille a une charge de travail en écriture extrêmement lourde. Le ratio de données en lecture par rapport aux données en écriture est de 3:1 (3 pour 1), ce qui implique un taux d’écriture très élevé. La majorité des demandes pour FarmVille adressées au Backend modifient en quelque sorte l’état de l’utilisateur qui joue. Pour que ce soit scalable, nous faisons dialoguer notre application principalement avec des composants de type cache. En plus, le lancement d’un nouveau contenu ou de nouvelles fonctions a tendance à provoquer des pics d’utilisation, car cela revient à une extension du jeu. Les pics de téléchargement peuvent atteindre les 50% le jour du lancement d’une nouvelle fonction. Il nous faut pouvoir accueillir ces pics de trafic.

Le deuxième point est de faire scaler FarmVille comme l’application la plus importante sur une plate-forme web, et elle a autant d’envergure que certains des sites web les plus gros du monde. Du fait que le jeu est exécuté au sein de la plate-forme Facebook, nous sommes très sensibles aux écarts de latence (temps d’attente) et de performance de la plate-forme. En conséquence, nous avons fait des efforts pour mitiger cette variance de la latence : nous entreposons en cache beaucoup de données Facebook, et nous limitons gentiment l’utilisation de la plate-forme quand nous nous apercevons d’une dégradation de la performance. FarmVille a déployé tout un cluster (une grappe) de serveurs cache pour la plate-forme Facebook. Le volume de trafic entre FarmVille et la plate-forme Facebook est vaste : aux heures de pointe environ 3 Gigabits/sec passent entre FarmVille et Facebook, et en même temps notre cluster de caching fournit 1.5 Gigabits/sec de plus à l’application. En plus, étant donné que la performance est variable, l’application est capable de stopper dynamiquement les appels en retour vers la plate-forme. Nous avons un « bouton de réglage » qui nous permet de réduire de manière incrémentale de plus en plus d’appels en retour. Nous faisons en sorte que tous les appels qui reviennent à la plate-forme n’empêchent pas le chargement de l’application même. L’intérêt de cette manipulation est que, quoiqu’il advienne, les joueurs peuvent au moins continuer leur partie.

Pour toute application web, un temps d’attente élevé est fatal, et une latence hautement variable lui sera fatale tôt ou tard. Afin de résoudre la latence élevée, FarmVille a installé beaucoup de caches devant les composants à latence élevée. La latence hautement variable représente une épreuve de plus, car elle nous oblige à trouver une approche différente : l’application dépend des éléments de son architecture qui ont habituellement une latence correcte. Pratiquement tous les composants sont susceptibles de latence variable, certains plus que d’autres. Vu la nature de FarmVille, qui a une charge de travail très importante en termes d’écritures et de transactions, la variabilité de latence affecte l’expérience de jeu des utilisateurs de façon exacerbée, par rapport à une application web traditionnelle. La solution, chez nous à FarmVille, pour gérer ces scénarii est de considérer chaque composant comme un service dégradable. Memcache, base de données, APIs REST, etc. sont maniés comme des services dégradables. Afin de gérer la dégradation des services, nous attribuons des seuils en termes de nombre d’erreurs et utilisons des régulateurs d’usage desdits services. Les principes clés sont d’isoler les services problématiques et hautement latents et de les empêcher, par le biais de régulateurs d’erreurs et de timeout, d’entraîner des problèmes similaires ailleurs et, si besoin, désactiver la fonctionnalité de l’application avec des interrupteurs On/Off et des régulateurs de fonctionnalité.

En ce qui concerne la gestion et le suivi de la ferme web de FarmVille, nous exploitons quelques outils de gestion et de monitoring Open Source. Nous utilisons Nagios pour les alertes (supervision), Munin pour le monitoring et Puppet pour la configuration. Nous nous appuyons fortement sur des systèmes de statistiques internes afin de surveiller la performance des services utilisés par l’application, tels Facebook, DB et Memcache. En outre, dès que nous constatons une dégradation de performance, nous profilons les événements I/O d’une demande, sur une base échantillonnée.

Leçons retenues

Il manque un peu de détails à mon goût, mais il y a quand même beaucoup de points intéressants qui pourront servir :

1. Les jeux interactifs sont lourds en écriture. Les applications web typiques lisent plus qu’elles n’écrivent, donc il se peut que plusieurs architectures courantes ne suffisent pas. Des applications lourdes en lecture peuvent souvent s’en sortir à l’aide d’une couche de cache devant une seule base de données. Les applications lourdes en écriture auront besoin de partitionner, les écritures sont donc réparties et/ou utilisent une architecture en mémoire.
2. Chaque composant doit être conçu comme un service dégradable. Isolez les composants de manière que les latences élevées dans une zone particulière ne puissent pas impacter une autre. Régulez l’usage afin de réduire les problèmes. Désactivez les fonctions quand c’est nécessaire.
3. Mettez les données Facebook en cache. Quand vous dépendez fortement d’un composant externe, pensez à mettre en cache les données du composant afin d’améliorer les temps de latence.
4. Prévoyez à l’avance des pics de trafic liés aux nouveaux lancements.
5. Echantillonnez. En analysant des flux abondants de données, à la recherche de problèmes par exemple, il n’est pas nécessaire de traiter chaque donnée. Echantillonner rendra les mêmes résultats pour beaucoup moins d’effort.

J’aimerais remercier Zynga et Luke Rajlich de nous avoir accordé cette interview. Si des lecteurs ont une architecture qu’ils voudraient présenter ici, n’hésitez pas à me contacter.

Todd HOFF @highscalability.com

Vous trouverez cette vidéo en suivant ce lien : Facebook: Science and the Social Graph.

La conférence est en anglais et dure 1h00. Je vous conseille de prendre ce temps car les sujets abordés sont forts intéressants.

Je me propose de faire un bref récapitulatif des points de l’architecture Facebook qui m’ont semblé importants lors de cette présentation de Aditya Agarwal et d’en tirer les éléments que nous pouvons appliquer dans nos architectures, même à moindre échelle.

Rappel de la problématique du graphe social
La difficulté de l’exploitation d’un graphe social est que la majeure partie des données sont actives en permanence car chaque utilisiteur peut consulter les données d’un autre, même si celui-ci n’est pas connecté. De plus, un utilisateur a en général un nombre de « connexions » ou relations non négligeable. Ce qui implique de devoir gérer un volume de données conséquent et accédé en permanence et de mettre à jour toutes ces informations afin que chacun puisse accéder à ses informations et celles de ses relations en « temps réel ». Cela implique des problématiques telles que la difficulté de partitionner les données du fait que « tout le monde est connecté », de conserver un maximum d’informations en cache mémoire (RAM) pour accélérer les requêtes, … Et je ne parle pas du traitement de tous les accès concurrents !

MySQL ou « comment stocker un graphe social ? »
Tout d’abord MySQL est utilisé comme une base clé – valeur. Les données sont distribuées massivement et de manière aléatoire sur un large éventail d’instances logiques qui elles-mêmes sont réparties sur un ensemble de noeuds physiques. Chaque donnée possède un « global ID » (identifiant unique) par lequel elle est accédée. Il n’y a pas de JOIN (jointure SQL) au niveau des requêtes du fait de la distribution des données. Outre le fait que la majeure partie des données est distribuée (et donc qu’aucun lien logique ne les rapproche), « quelques » méta données sont stockées sur une logique « par utilisateur » et sont rassemblées sur un même serveur (ou ensemble de serveurs mais regroupées selon des critères logiques, donc permettant d’effectuer des jointures) : ce sont les méta informations des utilisateurs telles que le profile, … Meta informations que l’on retrouve en cache (Memcache), mais nous verrons cela après.

Il est à noter également que les bases sont optimisées afin d’accéder plus rapidement aux données récentes ou fréquemment accédées tandis que les plus anciennes sont « archivées » (mais toujours disponibles). Il s’agit du partitionnement ou sharding vertical que j’ai décrit dans l’article Sharding et optimisation des accès aux données.

Il est à noter que le moteur de base de données MySQL utilisé par Facebook a subi quelques modifications (mais peu, notamment en comparaison de Memcache), notamment afin de faire de la réplication entre plusieurs data-center et de gérer au mieux la consistence des données. On entend à nouveau parler de la consistence éventuelle des données… A ce propos, je vous invite à lire cet article Eventually Consistent – Revisited de Werner Vogels (CTO – Amazon.com) sur son weblog « All Things Distributed ». Il explique notamment que la consistence éventuelle, c’est le fait que pour construire des systèmes fiables (comprendre disponibles – haute disponibilité) distribués à une échelle mondiale, cela demande un compromis entre consistance (intégrité des données à un instant « t » entre plusieurs bases) et disponibilité.

On note également que les objects sont faiblement typés afin de faciliter leur utilisation.

Memcache ou « comment soulager la base ? »
Memcache (ou Memcached, « d » pour daemon – démon), une hashtable haute performance distribuée (accès via interface réseau) stockée en mémoire (RAM), pour Facebook c’est 25TB de données et des temps de réponse moyens < 200 micro-secondes. Memcache permet de soulager les bases MySQL, voire plutôt de les sauver, et d’avoir des temps de réponse bien meilleurs. Y sont stockées beaucoup de données et notamment des objets PHP « pré-calculés » et sérialisés. Les requêtes sont effectuées via les « global ID » en « multi-get » (sur de telles volumétries, oubliez les get). Les chiffres annoncés en termes de hit rate pour Memcache sont supérieurs à 95%.

Concernant l’aspect customisation de Memcache, il a été modifié en profondeur, notamment en remplaçant les accès protocolaires TCP par des UDP, impliquant l’ajout d’un contrôle de cohérence au niveau applicatif afin de prévenir les pertes de données et de combler la lacune laissée par le passage de TCP à UDP. Le Kernel du système a également été modifié, …

A la question d’un invité sur « qui a fait ces modifications ? » que ce soit pour Memcache ou bien MySQL, on notera la réponse : « des gens qui connaissent ». C’est dit : ne reproduisez pas à la maison ce que vous venez de voir à la conférence ! Plus sérieusement, les modèles décrits sont applicables à nos cas d’utilisation plus modestes, cependant il n’est pas conseillé (ni forcément nécessaire pour nos cas) d’effectuer des modifications aussi en profondeur. On notera que la version UDP de Memcache devra être (est ?) à disposition de la communauté. Cependant est-ce que nous pourrons l’utiliser telle quel sachant toutes les modifications annexes apportées par Facebook (Kernel, …) ?

LAMP is not perfect
Effectivement, LAMP ne s’applique pas à tous les cas et n’est pas exempt d’inconvénients. Commençons par PHP, stateless et pas si rapide, en tout cas moins que des langages compilés. De plus, certaines fonctionnalités sont présentes dans d’autres langages et non dans PHP. D’où le développement par Facebook de services accédés par PHP : chaque service est développé dans le langage (JAVA, Erlang, Python, …) optimisé pour la tâche qui lui incombe. Cependant, ces services (nécessaires) induisent la présence d’autres failure points éventuels et ajoute un coût de déploiement et de maintenance.

Les outils « maison »
La présentation s’achève par une rapide présentation, disons plutôt citation, faute de temps, des outils « maison » tels que Thrift, Scribe, SMC (Service Management Console), … Vous pouvez retrouvez certains de ces outils et notamment Thrift et Scribe et bien d’autres encore (Cassandra, …) sur le Site des développeurs de Facebook, dans la rubrique Community – Open Source.

Conclusion
Cette conférence, comme je vous l’ai précisé, est en anglais et dure 1h00, mais elle vaut le coût de part les sujets abordés forts intéressants. On appréciera cette incursion dans l’architecture logicielle de Facebook et plus généralement des réseaux sociaux et des applications bâties sur l’exploitation de graphes sociaux et dont le leitmotiv est « scalabilité ! ».

Frédéric FAURE