Description

Bien qu’invisibles depuis nos navigateurs des millions de serveurs fonctionnent continuellement pour que le web reste disponible 24h/24. Même si les chiffres restent confidentiels, un seul grand acteur du web peut nécessiter des dizaines, des centaines de milliers de machines comme EC2[1] voire aux alentours de 1 million chez Google[2]. La mise en œuvre d’un si grand nombre de machines représente un défi technique mais surtout économique. La grande majorité de ces acteurs ont relevé ce défi en utilisant du matériel de grande série, du « commodity hardware » - terme que nous allons préciser par la suite.

C’est une des raisons qui conduit les grands du web à utiliser un agencement de nombreuses machines de grande série à la place d’un seul grand système. Un seul service aux utilisateurs, une seule application, peut ainsi s’exécuter sur des centaines de machines. On parle à ce niveau-là de Warehouse Scale Computer[3], des centaines de machines prenant la place d’un seul serveur.

Les besoins métiers

Les grands du web ont en commun un certain nombre de problématiques – déjà évoquées dans nos articles précédents[4] :

• Un business model lié à l’analyse d’énormes quantités de données – par exemple indexer le web (soit près de 50 milliards de pages).
• Des enjeux forts de performance pour que les temps de réponse restent faibles
• Une rémunération indépendante de la quantité de données stockées : publicité, facturation de l’utilisateur au forfait

Les revenus comme la publicité ne sont pas linéaires avec le nombre de recherches et, ramenés à une requête unitaire, restent faibles[5]. Comparativement les coûts unitaires sur des grands serveurs traditionnels restent trop élevés. L’enjeu est donc fort de trouver des architectures avec les coûts par transaction les plus faibles.

Enfin les ordres de grandeur des traitements mis en œuvre sont  sans commune mesure avec les traitements traditionnels d’informatique de gestion dont le nombre d’utilisateurs était jusque-là borné par le nombre d’employés. Aucune machine, aussi grosse soit-elle, ne sera en mesure de répondre à leurs besoins.

En somme ces acteurs ont besoin de scalabilité – coût marginal par transaction constant – ce coût marginal devant rester faible.

Machine de grande série contre serveur haut de gamme

Lorsque la question de la scalabilité se pose, deux grandes alternatives s’opposent :

• Le scale-up ou croissance verticale, consiste à utiliser une machine plus performante. Cette approche a été historiquement utilisée du fait de sa simplicité de mise en œuvre et parce que la loi de Moore permettait aux constructeurs d’offrir régulièrement des machines plus puissantes pour un prix constant.
• Le scale-out ou scalabilité horizontale, consiste à mettre en commun les ressources de plusieurs machines qui peuvent être unitairement moins puissantes. Il n’y a alors plus de limite liée à la taille de la machine.

Or les composants, technologies et architectures issus du monde du PC offrent un ratio puissance/prix très avantageux. Leur relativement faible puissance par rapport à des architectures plus efficientes telles que les architectures RISC est compensée par des prix plus faibles du fait de la production en grande série. Ainsi cette étude [6] menée à partir de résultat du TPC-C montre un coût relatif à la transaction 3 fois moins élevé pour un serveur d’entrée de gamme que pour un serveur haut de gamme.

Aux échelles mises en œuvre par les grands du web – plusieurs milliers de machines coordonnées pour exécuter une seule fonction – d’autres coûts deviennent extrêmement importants : puissance électrique, climatisation, m². Le coût par transaction doit englober ces différents aspects[7].

Ce sont ces constats qui ont amené les grands du web à privilégier la croissance horizontale (scale-out) à base de commodity hardware.

Chez qui cela fonctionne ?

La quasi-totalité des grands du web : Google, Amazon, Facebook, LinkedIn… utilisent aujourd’hui des serveurs de type x86 et du commodity hardware. Cependant l’utilisation de tels composants introduit d’autres contraintes et ces Data Center As A Computer ont des contraintes d’échelle différentes de nos datacenters. C’est ce sur quoi nous allons nous pencher plus en détail.

Des caractéristiques matérielles impactantes pour la programmation

Tout d’abord, les architectures serveurs traditionnelles essayaient autant que possible avec le hardware d’obtenir une « architecture théorique pour le développeur » vue avec un processeur, une mémoire centrale contenant le programme et les données, et un système de fichiers[8]. La programmation que l’on connaît à base de variables, d’appels de fonctions, de threads et de processus nécessite de faire cette hypothèse. Autant les architectures des grands systèmes sont proches de cette « architecture théorique », autant un ensemble de machines dans un datacenter s’en éloigne.

	One server : RAM : 8TB, 39,4 GB/s.<br><br>Disk : 304 TB, 10 ms. , up to 50 GB/s.<br><br>One Processor Book [9]:<br><br>RAM : 1 TB, 133 ns.,  46,6 GB/s.<br><br>Disk : 304 TB, 10 ms. , up to 50 GB/s.<br><br>One Processor :<br><br>RAM : 256 GB, 100 ns., 76,5 GB/s.<br><br>Disk : 304 TB, 10 ms. , up to 50 GB/s.

Figure 1 : Source RedPaper 4640 page 34

Les machines de type SMP (Symetric Multi Processor), utilisées dans une optique de scale-up, permettent aujourd’hui d’utiliser la programmation standard (avec accès à toute la mémoire et à tous les disques de façon uniforme). En effet, les chiffres sur le schéma montrent l’effort fait pour que les débits et les latences soient sensiblement identiques entre un processeur, sa mémoire et ses disques qu'ils soient connectés directement, connectés sur le même processor book ou sur des processor books différents. S’il reste une caractéristique NUMA (Non Uniform Memory Access : un accès à la mémoire proche est plus rapide que l’accès à la mémoire dans une autre partie du système), celle-ci se concentre sur la mémoire centrale avec des différences de latence et de bande passante dans un ratio 1 à 2. Les systèmes d’exploitation et middlewares comme Oracle prennent à leur charge ces disparités.

Dans une optique de scale-out, un programme s’exécutera non plus sur un seul grand système mais sur un ensemble de machines que ce programme coordonnera pour remplir cet objectif. Cet agencement de machines de commodity hardware offre une vue bien différente d’une « architecture théorique pour le développeur »  :

Figure 2 : Source Data Center As A Computer page 8 – L1$ : cache de niveau 11, L2$ : cache de niveau 2

Les écarts sont ici de plusieurs ordres de grandeur (facteur 1000 en latence et débit sur la RAM) et concernent également les disques durs attachés de façon séparée à chaque machine. Par ailleurs, les équipements réseaux en entrée du système constituent un facteur limitant par rapport à la bande passante agrégée de toutes les machines. Les systèmes d’exploitation et les couches middleware traditionnelles ne prenant pas en charge de telles limitations, elles devront être traitées au niveau applicatif.

La partie frontale des services, servir les pages web, s’accommode assez facilement de ces contraintes du fait du caractère sans état et facilement routable des requêtes HTTP entre plusieurs machines. Les autres applicatifs devront gérer explicitement les échanges réseau ou se baser sur des nouvelles couches middleware spécifiques. Les problématiques de stockage sur ce genre de matériel sont mises en œuvre chez les grands du web en particulier avec des techniques de sharding[10].

La prise en charge de la tolérance aux pannes

La seconde différence marquante entre les grands systèmes et les Warehouse Scale Computers concerne la tolérance aux pannes. Les grands systèmes ont au fil des décennies proposé des mécanismes avancés au niveau hardware pour réduire au maximum le nombre de pannes (RAID, changement à chaud de matériel, réplication au niveau SAN, correction d’erreur et failover au niveau mémoire et I/O, etc.). Un Warehouse Scale Computer possède la caractéristique inverse pour deux raisons :

• Les composants commodity hardware sont moins fiables
• La disponibilité globale d’un système mettant en œuvre simultanément 100 machines est le produit de la disponibilité de chaque serveur. Ainsi si chaque machine a une indisponibilité de 9 heures, la disponibilité de 100 serveurs sera au mieux de 0,999¹⁰⁰=0,90. Dit autrement, si chacun de 100 serveurs tombe en moyenne en panne 9 heures par an, il y aura pendant en moyenne 36 jours au moins une panne dans le système.

Cela conduit les grands du web à considérer que le système doit pouvoir fonctionner continuellement avec certains composants en panne. Là encore, la couche applicative est responsable d’assurer cette tolérance aux pannes.

Quels sont les critères de choix de ces machines ?

Pour autant, les machines retenues par les grands du web ne ressemblent pas toujours à nos PCs ni même aux serveurs x86 des grands constructeurs comme HP ou IBM. Google est sans doute l’exemple le plus marquant dans le sens où il fabrique lui-même ses machines. Les autres grands acteurs, comme par exemple Amazon font appel à des constructeurs plus spécialisés comme SGI[11].

Le premier critère de choix de leur serveur est bien sûr le prix. L’ajustement des composants au plus près de leurs besoins et le grand nombre de serveurs achetés permet aux grands du web d’avoir un fort pouvoir de négociation. Bien que les chiffres restent confidentiels, on estime que le prix d’un serveur peut frôler les $500.

Le second critère de choix est lié à la consommation électrique. Aujourd’hui du fait du très grand nombre de serveurs utilisés, la consommation électrique devient l’un des postes de dépense les plus importants. Récemment Google communiquait sur une puissance moyenne d’environ 260 millions de watts soit une facture de l’ordre de $30 000 par heure. Le choix des composants mais également la capacité à paramétrer au plus fin la consommation de chaque composant permet de faire gagner beaucoup d’argent.

Au final, même s'ils sont constitués de composants issus du monde du PC, la composition et le paramétrage de ces serveurs sont assez différents. Hormis quelques initiatives comme OpenCompute de la part de Facebook, ces détails restent jalousement gardés par les grands du web. Tout au plus peut-on savoir chez Google qu’ils ont remplacé les UPS[12] par des batteries 12V directement au niveau des serveurs[13].

Exceptions

Les exemples de Grands du Web communiquant sur des technologies hors x86 sont quasi inexistants. Si on remontait un peu dans le temps, on pourrait trouver un logo « Powered By Sun » chez SalesForce[14].

Et dans mon entreprise ?

Le « down sizing[15] » c'est-à-dire la volonté de remplacer les serveurs centraux par des machines plus petites a connu son heure de gloire dans les années 90. L’objectif n’est pas ici de plébisciter de la même façon le commodity hardware même si au premier abord on pourrait penser que le x86 a envahi toute l’entreprise. Le choix extensif du commodity hardware va plus loin que cela en transférant sur l’applicatif la responsabilité de la scalabilité et de la tolérance aux pannes. A très grande échelle, comme chez les grands du web, lorsque les coûts électriques et d’investissement deviennent déterminants, il s’agit de la seule solution viable. Pour des applications existantes pouvant se contenter des ressources d’un seul gros serveur multiprocesseurs , le coût du (re)-développement en distribué et le coût du hardware viennent parfois s’équilibrer dans les SI.  L’utilisation du commodity hardware dans votre entreprise doit donc faire partie d’un choix d’architecture plus globale : privilégier le développement existant avec des machines plus haut de gamme ou l’adapter pour migrer (entièrement) sur du commodity hardware. En pratique des applications conçues pour la distribution telles des frontaux web migreront facilement. A l'inverse des applications fortement intégrées comme Oracle nécessiteront forcément une infrastructure spécifique avec redondance des disques peu compatible avec un data center commodity hardware tel que conçu chez les grands du web.

Patterns associés

La distribution est donc indispensable à l’utilisation du commodity hardware. Des patterns comme le sharding doivent nécessairement être implémentés dans votre code pour pouvoir mettre en œuvre du commodity hardware pour le stockage de la donnée.

L’utilisation de très nombreuses machines complexifie également l’administration des serveurs, rendant nécessaire des patterns comme DevOps. Enfin, cette propension à concevoir des ordinateurs ou plutôt des datacenters à leur besoin renvoie bien sûr à la préférence build versus buy des grands du web.

Retrouver toutes les pratiques des Géants du Web sur le site dédié (www.geantsduweb.com) : pdf de l'ouvrage à télécharger, vidéo et compte-rendu de la présentation "Décrypter les secrets des Géants du Web"

Sources

[1] Source SGI

[2] Là encore les estimations restent complexes http://gizmodo.com/5517041/googles-insane-number-of-servers-visualized

[3] Ce concept a été largement décrit par ce très long papier Data Center as a Computer  dont nous ne reprenons ici que quelques concepts. Vous pourrez en trouvez un résumé plus approfondi dans ce résumé par Olivier Malassi

[4] Voir notre article sur le sharding

[5]« "Early on, there was an emphasis on the dollar per (search) query," [Urs] Hoelzle said. "We were forced to focus. Revenue per query is very low." «   http://news.cnet.com/8301-1001_3-10209580-92.html

[6] Toujours dans ce papier Ce très long papier ou dans le résumé au paragraphe 2.

[7] Ce papier détaille les différentes composantes de ces coûts.

[8] Cette architecture est connue sous le nom d’architecture de Von Neumann

[9] Un processor book est un compartiment regroupant processeurs, mémoire et connecteurs d’entrée sortie, comparable en première approche à une carte mère. Les grands systèmes SMP sont constitués d’un ensemble de ces compartiments reliés entre eux par une seconde carte : le midplane.

[10] Voir notre article sur le sharding

[11] SGI est aujourd’hui issu de la fusion de Silicon Graphics, Cray et surtout Rackable qui possèdait l’expertise dans les serveurs x86

[12] Unbreakable Power Systems plus fréquemment appelés onduleurs

[13] http://www.youtube.com/watch?v=Ho1GEyftpmQ

[14] http://web.archive.org/web/20000118010832/http://www.salesforce.com/ et http://techcrunch.com/2008/07/14/salesforce-ditch-remainder-of-sun-hardware/

[15] http://fr.wikipedia.org/wiki/Downsizing_(informatique)