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