Suite de l’USI, Olivier Mallassi et André Nedelcoux d’OCTO Technology présentent les architectures des grands du Web comme Google, eBay et Amazon, afin de remettre en cause nos réflexes d’architecte. J’ai beaucoup aimé.
La session débute avec quelques chiffres qui ont le mérite de rendre humble : Google c’est 39 centres de données dans le monde, 2.5 % de la consommation électrique aux USA. C’est 400 serveurs qui tombent en panne par jour. En cherchant quelques chiffres pour renforcer mon article, j’ai lu que YouTube coûte 2 millions de dollar par jour à Google avec 75 milliard de vidéo pour 375 millions de visiteurs uniques en 2009. Le coût de la bande passante et du stockage est d’environ 2$ par visiteur. La bande passante coûterait 1 million par jour, les datacenters seulement 36 000 dollar par jour selon Credit Suisse…
Revenons à notre présentation. eBay c’est 250 millions d’objet en vente, 44 milliards de requêtes Web par jour, 6 millions de ligne de code. Forcément on se sent petit.
Un slide suivante montre l’effet « Michael Jackson » sur le trafic de la première page de Google. D’ailleurs Google a cru un moment à une attaque. Le 25 juin à 15h00 c’est un tsunami qui s’est abattu sur le moteur de recherche.
Je me dis à cet instant, que Reuters devrait surveiller les recherches Google pour détecter l’actualité avant qu’elle ne devienne de l’actualité.
Tout d’abord ces grands sites ont quelques caractéristiques auxquelles nous devrions penser : leur croissance est très rapide et continue de s’accélérer. Amazon qui était un site Internet, a aujourd’hui plus de trafic sur sa plateforme Amazon de Cloud-Computing que sur la librairie. Olivier explique qu’ils sont passés de simple site internet à plateforme. Google de même avec Google App Engine.
eBay n’a pas hésité au cours du temps à remettre son architecture en question plusieurs fois. Nous sommes passés du Perl au C++ puis au Java, plus facilement maintenanable et tout aussi performant. Les bases de données sont structurées différemment des bases que nous voyons au quotidien dans nos applications de gestion. Ces bases sont en général faiblement relationnelles. La validation du modèle se fait maintenant dans le monde objet plutôt qu’au niveau de la base elle-même. Il n’y a pas de contraintes d’intégrité dans la base de données. Les données sont stockées sur différents serveurs tout d’abord verticalement. Pour faire simple : un serveur pour l’ensemble des CD, un serveur pour les DVD et un serveur pour les livres. Un partitionnement horizontal des données accélère encore le stockage : les Livres dont le titre débute par « A » sont sur le serveur 1, les Livres « B » sur le serveur 2, etc.
C’est donc une segmentation physique intelligente qui permet de monter en charge.
La réplication des données est vitale, et elle fait partie intégrante des architectures de ces grands comme Amazon ou eBay. Différentes stratégies comme l’utilisation de Merkle Tree (autre nom pour Hash Tree) permettent de s’assurer de la validité des données. Pour maintenir l’information sur les serveurs en panne, des systèmes basés sur ce que l’on appelle « Gossip protocol » (gossip=ragôt) permettent au réseau de s’auto-informer sur les machines en panne.
Les architectures des grands du Web sont donc performantes, distribuées, résistantes à la panne et basées sur des plate-formes de Cloud Computing. Olivier rappelle qu’Amazon et eBay ont 6h d’indisponibilité par an… Cela force le respect.
Leur synthèse nous propose ensuite de prendre un peu de recul. Ne pas partionner de prime abord, cela vous crée des problèmes pour en résoudre d’autres que vous n’avez pas encore. Le mode relationnel n’est pas l’unique solution, pensez à diviser verticalement vos traitements dans votre application. La question de l’utilité de la base classique se pose, lorsque l’on voit que les grands du Web ne s’en servent pratiquement pas… La gestion des Transactions est complexe, prévoir des services de nettoyage qui vérifient l’intégrité des données à posteriori pour gérer les rares cas des transactions techniques abandonnées.
La gestion des transactions est assez exemplaire. André explique le Théorème de CAP d’Eric Brewer, utile lorsque l’on parle de données massivement partagées :
– Strong Consistency: all clients see the same view, even in presence of updates
– High Availability: all clients can find some replica of the data, even in the presence of failures
– Partition-tolerance: the system properties hold even when the system is partitioned
Ce qui donne en français :
– L’ensemble des clients voient la même vue, même lorsqu’il y a des mises-à-jour
– Massivement disponible : tous les clients peuvent trouver de la donnée répliquée, même lorsqu’un crash survient
– Partitionable : votre app-serveur et votre base de données peuvent être installé sur 2 machines, votre système est tolérant au partitionnement.
Il s’avère que seul 2 des 3 postulats peuvent être respectés en même temps. Olivier explique qu’Amazon par exemple a fait une architecture en suivant les points 2 et 3. Le besoin en « High-Availability » et en « Partition-tolerance » sont plus importants que la Consistence. Cela crée des fenêtres d’inconsistance, mais avons-nous besoin absolument à la seconde prêt de la consistance des données ? A réflechir !
Pour monter en charge, tout ce qui peut être traité avec de l’asynchronisme comme la préparation d’une facture par exemple, la validation d’une commande… doit être traité de cette façon. Cette architecture « Fire and Forget » est très intéressante. Tout d’abord Olivier explique que les données ne sont pas véhiculées, simplement l’endroit où elles se trouvent. L’architecture accède à la donnée le plus tardivement possible. Les systèmes sont fait de telle sorte que si un message est reçu plusieurs fois, cela n’a pas d’impact. L’ordre des messages ne doit pas être important. Pensez à votre lecteur de mail, lorsque vous prenez une conversation en cours, vous relisez les anciens messages commentés dans le message complet par exemple… La synchronisation tue l’architecture distribuée.
Chef on fait une mise en prod
J’ai franchement bien aimé cette partie, merci d’en avoir parlé. Après avoir parlé grosse architecture, les 2 présentateurs enfoncent le clou et parlent de la mise en production. Et là j’ai appris pas mal de choses.
eBay est entièrement redéployé toutes les 2 semaines. Cette mise à jour peut prendre 3 jours. Le déploiement du code est différent de l’activation d’une nouvelle fonction. Chaque fonction d’Amazon par exemple est activable/désactivable. La mise en prod d’une fonction revient donc à mettre en marche du code… qui est peut-être en production depuis 3 semaines. Les fonctions sont cachées et activées par un switch !
En cas de panne sur une fonction, on peut même imaginer qu’un administrateur système « éteigne » la fonction en cause. Vive OSGi !
On recherche donc plutôt la robustesse applicative au lieu de la robustesse d’infrastructure. Ils savent que le système va planter, l’architecture est donc construite en fonction de ce postulat, afin que les systèmes reprennent automatiquement lorsqu’une autre partie du réseau repart.
La présentation continue ensuite sur la partie humaine de ces projets. Comment font-ils ? Combien de développeurs ? Comment travaillent-ils ?
Amazon c’est 1500 développeurs, 30 architectes. Pas beaucoup pour 6 millions de ligne de code. Werner Vogels, CTO d’Amazon.com a une phrase simple : « You build it ? You run it ! ». Tu l’as fabriqué ? Et bien tu vas le faire marcher. Il demande aux équipes du support de réveiller à 3h du matin le chef de projet du module qui a planté afin que celui-ci se déplacer. Rien de plus efficace pour s’assurer de la qualité des développements.
Amazon c’est 55 millions de clients actifs. Entre 100 et 150 équipes collaborent pour créer une seule page d’Amazon.com. Chaque équipe est autonome, et elle ne dépasse pas 10 personnes. Werner dit « If you need more than 2 american pizzas to feed a team, split-it ». Yahoo! est aussi l’un des premiers utilisateurs de Scrum, l’Agilité est un standard.
L’esprit « on est en béta tout le temps » permet aussi de recevoir du feedback des clients. Ces sites marchent car ils écoutent les clients. Amazon.com ouvre son système avec des Web Services, cela permet à des communautés de développeurs de travailler avec Amazon et d’accroître les ventes. Prenez GMail, en béta depuis 5 ans… Bref comme notre univers avance très vite, il est vital d’aller mettre en ligne le plus vite possible une version light de votre architecture, afin de commencer à prendre du recul et à écouter le client. Ne partez pas dans un effet tunnel, faîtes de l’incrémental, trouvez un moyen de mettre en ligne chaque mois par exemple. Le fantasme spécification-codage-testage-mise en prod-merdouillage-debuggage-remise en prod-merde ça marche pas-debuggage n’est pas du tout le modèle des grands du Web.
Conclusion
Présentation vraiment sympathique, pas du tout « consultant-SOA-on se la raconte » mais très concrète et très bien tournée.
En sortant mes tags sur cette présentation sont : humilité / partager / petite équipe / 400 serveurs par jour se plantent chez Google.
Il y a un monde entre l’univers des gens qui tartinent du Word et du PowerPoint avec une cravate et les autres, qui vont vraiment vous construire une architecture, mettre en place des outils, trouver une solution à l’arrache sans craquer, motiver et diriger une équipe.
Le jour où un pingouin de 25 ans viendra vous parler de SOA, demandez-lui s’il sait comment fonctionne Amazon, eBay, Google… et par extension, d’autres sites comme SalesForce.com ou même… le Touilleur Express.
Bien entendu lorsque l’on parle de ces grands sites, et que dans la vraie vie on est juste entrain de faire l’extranet d’un Assureur Suédois, il y a un monde… Mais prendre le temps de regarder ce qu’ils font nous donne des idées concrètes pour ne pas se planter, et continuer à se faire plaisir.
Et entre nous, les Suédoises, ça scale horizontalement non ?
Références
http://highscalability.com/amazon-architecture
à lire pour retrouver quelques idées et chiffres de la présentation.
J’ai peut-être mélangé eBay et Amazon lorsque je cite certains chiffres, n’hésitez pas à corriger.
Oui c’est intéressant. Ebay s’était fait aidé initialement par Sun pour son premier upgrade d’archi et ils avaient obligés de dire qu’ils n’utilisaient pas les EJBs… mouarf !
Ceci étant dit, c’est absolument irréaliste d’imaginer que tu peux mettre en place ces archis pour ton projet d’assureur suédois : les économies d’échelle n’y sont pas et justement, les « petites » archi à base de transactions ACID en mode synchrone évitent bien des déboires de dev et surtout de maintenance : tu imagines le niveau des équipes d’exploitation pour maintenir tout çà ? Ah oui, c’est vrai: c’est les équipes de dev…
Salut Philippe
Pour mon site d’assurance suédoise, je me dis qu’il serait pas mal de prendre quelques principes.
Quelque part je vois les projets classiques comme des projets WaterFall, là où un projet à la Amazon est un projet Agile. Entre les deux extrêmes je me dis qu’il doit être possible de construire une architecture évolutive, avec des équipes motivées, et surtout en restant plus simple en regardant comment travaillent ces mastodontes.
Et sinon je bosse pas dans l’assurance, c’était une image d’illustration comme on dit.
🙂
Nicolas
Salut Nicolas,
Merci pour ce résumé de l’USI. Je m’intéresse aux « grandes » architectures du web depuis un moment déjà et c’est vraiment bien d’en parler dans ton blog, ces principes architecturaux sont trop peu connus. Et je partage complètement ton avis, même si on n’utilise pas ces principes sur le premier projet qui vient, connaître ces principes donne un recul permettant de mieux concevoir les « petites » architectures 😉
Par ailleurs, un article qui m’a particulièrement marqué tant il est bien écrit et met le doigts sur l’essence du fonctionnement de ces « grande » architecture est l’article de Dan Pritchett sur BASE.
http://queue.acm.org/detail.cfm?id=1394128
Dan Pritchett est un ancien membre du pôle d’architecture d’eBay. Je t’invite à lire cet article si tu ne l’a pas déjà fait, il est passionnant, ça a été une révélation pour moi. Il décris en détails les principes que tu évoques ici.
A très bientôt,
Cédric Vidal
Pas de problème, j’avais bien compris que c’était un exemple alors je l’ai aussi pris comme exemple 🙂
Je suis d’accord avec toi sur les principes et l’organisation. On voit bien qu’amazon a fait quelque chose de très décentralisé. Mais bon, ils peuvent recruter les meilleurs de la terre et les payer. Dans des boites normales, je crois que les gens seraient épuisés bien vite dans une telle organisation.
Sinon, ma remarque concernait plutot les aspects techniques : oui c’est attirant pour des « architectes » de faire des gros machins comme amazon (moi, par exemple, je trouverais çà absolument passionant de tout remettre en cause et repousser les limites). Mais combien de sites ont réellement leurs requirements ? Je pense qu’on peut les compter sur les doigts de la main au niveau mondial
« Amazon c’est 1500 développeurs, 30 architectes. Pas beaucoup pour 6 millions de ligne de code »
Hum, j’imagine qu’un des chiffres n’est pas correct. 4000 lignes de code à maintenir par développeur, c’est un ratio qui doit faire rêver toute l’industrie.
En fait, la leçon des grands acteurs, c’est que la mode ne fait pas une bonne architecture : il y a 15 ans, la mode, c’était « le client-serveur sinon rien », aujourd’hui, c’est « des EJB, Spring, Hibernate sur une base relationnelle sinon rien », …
Or une bonne architecture, c’est d’abord une architecture adaptée à ses besoins. Faire des EJB si on s’interdit de déployer l’applicatif sur plusieurs serveurs, c’est idiot. Passer son temps à créer des beans passe-plats pour faire transiter les données de couche en couche n’est pas forcément ce qu’il y a de plus adapté pour réduire la complexité (il y a d’autres moyens de mettre en œuvre des mécanismes d’abstraction). Se servir d’une base de données relationnelle comme un simple entrepôt pour consulter des données, c’est rarement approprié (et quand c’est pour écrire du log, c’est carrément inepte !).
Enfin, la grande leçon de ces grands acteurs, c’est que, malgré ce que leurs promoteurs prétendent, les solutions « à la mode » ne sont pas les plus scalables et les mieux à même de réduire la complexité du problème posé. Même si le syndrome Make-It-All-By-Yourself est un véritable danger, le métier d’architecte ne se réduit pas à celui d’intégrateur de technologies…
SAlut Nico,
Merci pour le résumé : quelle prose.
y a effectivement quelques erreurs/inversion eBay/AMazon mais peu importe. sinon ce n’et pas 150 équipes mais 150 services 😉
@+
oliv’
Interessant de voir qu’on en revient toujours aux fondamentaux des systèmes distribués.
Interessant de voir aussi que les plus grands du web ont des développeurs en nombre et en interne (pas d’outsourcing), qu’ils concoivent eux memes leur logiciels (voire leur hardware pour Google).
Enfin, si la présentation des architectures est linéaire et policée, elle masque néanmoins les nombreuses évolutions de l’architecture, des essais et des échecs, qu’ils ont du mettre en place, sans oublier les contraintes du legacy (et oui tout le monde en a).
Enfin, j’ai rien contre le site d’assurance suédois, mais, on ne compare pas un rafale à un planeur.
Sur EBay, il y a aussi cet article – http://www.infoq.com/articles/ebay-scalability-best-practices
qui m’avait assez sidéré à l’époque. Il avait remis en cause pas mal de choses, notamment, la gestion des transactions, des entrepots de données, des requetes, le compromis nécessaire entre différents aspects d’une archi, etc etc. Bien, bien!
Bel article, on est un peu comme des mecs qui lisent les spécifications des F1. Après on regarde sa Citroën Saxo et on se dit qu’on lui mettrait bien un petit spoiler…
@Gabriel j’imagine le méga spoiler sur mon Scenic, tu commences à parler comme moi 🙂
J’adore : « Il y a un monde entre l’univers des gens qui tartinent du Word et du PowerPoint avec une cravate et les autres, qui vont vraiment vous construire une architecture, mettre en place des outils, trouver une solution à l’arrache sans craquer, motiver et diriger une équipe. »
ça te dérange si je m’emprunte ta phrase magique l’envoyer à ma très estimée hiérarchie ? 😀
@Damien : vas-y sers toi c’est open bar