OCTO était vendredi dernier à la conférence dotScale à Paris. Les différentes sessions de cette conférence tournaient autour du thème des architectures scalables en prenant pour modèle les acteurs du Web et du Cloud.

Durant la journée, de prestigieux speakers se sont relayés dans un format spécial : un enchaînement de keynotes de 20 à 30 minutes. Ainsi se relayaient sur la scène du Théâtre des Variétés des contributeurs majeurs comme Doug Cutting (Cloudera), Shay Bannon (ElasticSearch) ou encore Joshua McKenty (OpenStack).

Suivre les Géants du Web

La scalabilité devient un enjeu majeur des architectures pour répondre aux nouveaux besoins métiers liés à l'exploitation de données générés exponentiellement. C'est d'ailleurs dans cette optique qu'est né Hadoop, comme l'a rappelé Doug Cutting.

Les intervenants de dotScale ont ainsi rappelé des patterns des Géants du Web pour intégrer la notion de scalabilité au sein d'une architecture.

Augmenter la capacité de son architecture

Tout d'abord le principe de divide & conquer (diviser pour régner), bien connu par les étudiants et autres praticiens d'algorithmes, s'applique en architecture. Séparer un traitement en plusieurs sous-traitements, comme le fait Hadoop au travers de MapReduce, permet de lisser la charge de calcul sur différentes machines.

Ce principe reste le même au niveau base de données via le sharding (partitionnement) : une définition détaillée est disponible sur l'article des Géants du Web par Marc Bojoly.

La plateforme de blogging Wordpress, qui supporte un des plus élevés taux de trafic du Web (en prenant en compte les différents blogs) juste derrière Google et Facebook, a expérimenté cette approche de manière incrémentale.

Barry Abrahamson, CTO de Wordpress, explique que pour gérer tous les sites hébergés Wordpress se base sur un sharding selon le type d'utilisateurs : des active shards et inactive shards. Les active shards représentent les sites les plus actifs et ayant le plus de contenu en terme de taille.

En effet, tenter de sharder de manière aléatoire selon un hash pour distribuer une quantité similaire de sites sur les différentes instances du cluster n'est pas applicable au cas Wordpress.

Sur le blog technique de Wordpress, il est indiqué :

The problem with clusters is that is really easy to become overcrowded. Some of our competitors also use clusters but put 100s of customers on a cluster.  This doesn’t work because of a rule we have: If it doesn’t fit into RAM, it’s too slow. Once there’s too many files to fit in the kernel filesystem cache, too much table data to fit into MySQL’s memory, too many objects to fit into memcached, then suddenly all sites become much slower because only the few, largest sites will stay in memory.

Un même nombre de blogs sur un cluster aurait un impact de performance et de disponibilité ou de coût :

• Soit les machines sont dimensionnées au minimum pour coller au plus grand nombre et donc les blogs hébergés sur les mêmes instances que les blogs les plus visités subiraient des faibles performances voire même des temps d'indisponibilité si l'instance tombe.
• Soit l'infrastructure est dimensionnée de manière excessive pour les 10% de blogs les plus visités éparpillés sur l'infrastructure ce qui induit des coûts plus importants pour une minorité de blogs.

Ainsi, les blogs "inactifs" sont en grand nombre une même machine performante disposant d'environnements virtualisés et les blogs "actifs" sont sur des clusters hébergeant moins de sites.

We’re very careful to balance clusters with the right number of customers.  The exact number depends of course on the nature of the traffic and the size of the sites, but we actively monitor the relevant system details to produce an internal “capacity” score per cluster.  We never let it get too high, and we’ll migrate sites between clusters if needed to ensure everyone has enough resources.

Les optimisations de performance utilisées sont :

• SSD
• Caching d'objets via memcached
• Sharding des reads et writes

Des optimisations MySQL de l'ordre de key_buffer (optimisation des indexes en mémoire) et query_cache_* (cache de requête SELECT) ne sont pas utilisées car le nombre de tables étant trop important (plus de 500 millions de tables, 120 shards et 2200 serveurs), la probabilité qu'une requête en mémoire soit exécutée à de nombreuses reprises est trop faible. Cela permet ainsi de ne pas surcharger la RAM de chaque instance.

La scalabilité ne se restreint pas que sur les couches logicielles. Au niveau réseau le principe reste transposable.

Les VLAN ont été crées afin de regrouper des machines au sein d'un réseau virtuel, indépendant de la localisation et du matériel réseau afin de gagner en sécurité et en performance (le broadcast et multicast des messages se restreint à des VLAN plutôt qu'à toutes les machines d'un réseau physique. Cependant, les VLAN imposent une limite à 4096 segments ce qui freine la scalabilité au niveau réseau. Pour garder les bénéfices des VLAN il existe plusieurs solutions : VXLAN ou encore VNT, Virtual Network over TRILL, présenté à dotScale par Thomas Stocking, COO chez Gandi.

VNT est une extension de la frame Ethernet classique avec VNI (Virtual Network Identifier) et le protocole TRILL.

VNI permet d'utiliser un segment de 24 bits (supérieur à ce que peut gérer un VLAN) comme annuaire de machines au sein d'un réseau. Chaque machine est donc identifiée par un ID et son adresse MAC. Il est possible d'avoir plusieurs adresses MAC sur le réseau tant qu'elles sont sur différents VNT (VLAN).

TRILL (Transparent Interconnection of Lots of Links) est un protocole "zero configuration" en remplacement des Spanning Tree. Un spanning tree permet le routage de données sans cycle (contrairement à un graphe) afin d'éviter d'envoyer des paquets plusieurs fois sur le même noeud. Plusieurs inconvénients existent dans les spanning tree notamment des chemins peu optimisés d'un noeud à un autre ou encore l'impossibilité de faire du multipath, rendant la connectivité non scalable au travers d'un large réseau.

TRILL permet ainsi d'optimiser le routage via les R-Bridge, switchs compatibles TRILL, qui se référencent mutuellement et n'ont pas besoin d'avoir connaissance des adresses MAC des destinataires au sein du réseau. Ainsi il n'est pas nécessaire de concevoir un réseau acyclique et le multipath devient possible.

Sécuriser son architecture

Une architecture performante n'a que peu d'intérêt si celle-ci n'est pas résiliante.

Le principe commun pour gérer la résilience d'une architecture scalable est l'isolation. Sur du Cloud ou des machines physiques il est important d'isoler des applications (au niveau logiciel ou matériel) afin qu'elles n'aient aucun impact sur les autres en cas de panne. On appelle cela "design for failure", ce que rappelle Jonathan Weiss d'AWS OpsWorks.

Chez Heroku, décrit par Noah Zoschke, cela se traduit par des user groups isolés destinés à chaque application déployée, reprenant le principe de cgroups d'UNIX.

Les VM Ruby MRI sont montées dans des conteneurs LXC (Linux Container) agissant comme un méchanisme de virtualisation pour chaque application. LXC se base pour cela sur les cgroups UNIX pour gérer les différentes instances et la commande clone pour isoler les ressources.

Des pertes de performance sont évidemment induites dues aux nombreuses couches techniques mais Heroku gagne en contrepartie en sécurité et résilience.

Enfin, pour assurer la cohérence des données les géants du web se basent sur Paxos pour la gestion des transactions multi-sites. Google Spanner utilise Paxos pour l'élection d'un maître lors d'une transaction, partage l'espace des clés de sharding entre les sites et synchronise les différents datacenters au travers d'horloges atomiques et GPS.

Brad Fitzpatrick, créateur de memcached, cite également d'autres implémentations de Paxos : Google Chubby, utilisé dans BigTable ainsi que RAFT, une implémentation plus simple du protocole Paxos.

Toujours dans une optique d'isolation, Jonathan Weiss préconise le "one box deployment", déploiement itératif afin de ne pas perturber la production par une application ou instance défaillante :

• Mesurer le comportement d'une machine dans le temps
• Déployer sur une Availability Zone. Mesurer.
• Déployer sur une région. Mesurer.

On peut assimiler cette technique de déploiement au Canary Release.

Pour gérer une plateforme scalable, celle-ci doit être la plus "élastique" possible, c'est-à-dire de pouvoir installer et configurer ses composants de manière industrielle, d'où la nécessité d'automatiser le provisionning des machines et l'installation des applicatifs (pratique DevOps)

Dans cet objectif Solomon Hykes, créateur de dotCloud, a présenté une solution de déploiement nommée Docker. Cette solution permet de gérer un PaaS au travers d'un moteur de déploiement pour applications hétérogènes via conteneur normalisé.

La promesse de Docker est de pouvoir déployer une application, quelque soit sa plateforme, son format et le matériel sous-jacent, d'une manière simplifiée permettant ainsi d'éviter du scripting lourd et difficilement maintenable dans le but de tendre vers une totale automatisation du déploiement.

En conclusion

Ces principes sont poussés depuis quelques années par les Géants du Web. Les intervenants de dotScale n'ont pas apporté de nouveauté particulière mais ont permis d'insister sur l'importance d'appliquer ces patterns.

Pour compléter sur d'autres patterns des Géants du Web : http://www.geantsduweb.com/