Decrypt

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. [...]

 
Pour ceux qui doutaient encore de l’efficacité de Puppet, voilà encore un bel exemple de réalisation utilisant cet outil ! Allez consulter cet article de High Scalability : How FarmVille Scales to Harvest 75 Million Players a Month ! [...]

Les bases de données non relationnelles sont mises en avant depuis quelques temps avec un panel important de systèmes de stockage de la forme clé/valeur (key/value store). Cette approche permet d’avoir des structures optimisées pour certains types de fonctionnel et facilement distribuables. Tokyo Cabinet est un de ces outils. C’est un outil de stockage clé/valeur open source sponsorisé et utilisé par Mixi (Facebook japonais). Il a été développé par Mikio Hirabayashi que vous pouvez retrouver ainsi que l’exhaustivité des produits qu’il met à disposition sur Mikio Hirabayashi’s homepage. Tokyo Cabinet est couplé à un autre produit : Tokyo Tyrant. Tokyo Tyrant est en fait l’interface réseau qui permet, entre autre, d’accéder à partir d’un serveur distant à Tokyo Cabinet. Il ne se limite cependant pas à cela et permet un certain nombre de fonctionnalités très intéressantes. Le point fort de ce couple est la rapidité de traitement des requêtes, ainsi que les possibilités de mise en oeuvre.

[...]

Décidemment, encore un article sur les AWS (Amazon Web Services). Au-delà du fait, que ce sont de bons composants dans le cadre de la mise en place d’une infrastructure, il faut noter qu’ils couvrent un scope complet de ce que l’on peut trouver dans une infrastructure en termes de fonctionnalités (gestionnaire de files de messages -SQS-, base de données non relationnelle -SimpleDB- et relationnelle -RDS- depuis peu, traitement massif de données -MapReduce, bonjour BI ?-, instances virtuelles -EC2-, VPN -VPC-, …), mais également en termes de « background technique ». Je m’explique : prenons l’exemple de S3, qui sera notre sujet d’étude dans cet article d’ailleurs, quoi de plus simple qu’un système de stockage d’objets ? Ca se résume à « PUT », « GET » et « DELETE ». Et pourtant derrière cette apparente simplicité, se cache une complexité technique sous-jacente étonnante, qui reprend bons nombres de concepts « standards », mais que l’on implémente rarement soi-même, parceque complexes à mettre en place. On laisse donc cela aux outils que l’on utilise ou tout simplement on fait l’impasse dessus. Tout cela pour introduire les 9 principes sous-jacents au service S3 d’Amazon qui font de ce service apparemment succint, un bel exemple technique.

[...]

Une petite vidéo intéressante de Werner Vogels de moins de 3 min sur un retour utilisateur (Joshua Baer, co-fondateur et CEO de OtherInbox) sur les AWS (Amazon Web Services) et plus particulièrement l’utilisation qui est faite de SimpleDB et S3. Ce retour montre comment en utilisant différents services de stockage (en l’occurrence SimpleDB et S3) adaptés au type de la donnée à conserver et en se reposant sur l’architecture AWS, on optimise et facilite le développement de son propre service. En résumé, pourquoi refaire ce qui existe déjà.

[...]

Facebook… En voilà une architecture qui fait rêver et qui laisse songeur au vue du volume de connexions simultanées et de données stockées. J’ai récemment regardé une vidéo très intéressante d’une conférence données par Aditya Agarwal (Director of Engineering chez Facebook) durant le QCon SF 2008 (San Fransisco) sur l’architecture de Facebook et plus exactement la couche logicielle utilisée, basée sur le modèle LAMP (Linux, Apache, MySQL, PHP). C’est essentiellement de MySQL et PHP que la conférence traite sur ce modèle. Une belle part est également faite à Memcache. Memcache, cache mémoire réseau qui n’est plus à présenter, et qui a été optimisé par les développeurs de Facebook pour l’occasion. Une brève présentation d’outils « maison » tels que Thrift, Scribe, … est également effectuée en fin de conférence.

[...]

Le sharding ou partitionnement de données entre dans le cadre plus global de la scalabilité. Il s’agit tout simplement du découpage des données d’une base afin d’avoir à requêter sur moins d’occurrences et donc d’avoir un résultat plus rapide donc de meilleures performances. Le sharding est une solution à part entière, mais qui ne convient pas dans tous les cas. Nous verrons également quelles sont les solutions alternatives pour une amélioration des temps de réponse au niveau d’une base de données.

[...]

Ce post va présenter une description détaillée de la mise en place de l’infrastructure sur AWS (Amazon Web Services). Je me base sur ce que j’ai mis en place, en l’occurrence, à destination d’une application sociale à forte sollicitation. Cependant, quelque soit la typologie de l’infrastructure sous AWS, les éléments à mettre en place seront toujours les mêmes.

[...]