Le but de cet article est de montrer comment avoir un référentiel des instances disponibles sur un compte Amazon (ou autre) avec toutes les informations qui vont bien sans devoir utiliser la console web Amazon. Cette solution permet de pousser l’automatisation un cran plus loin en proposant une liste exhaustive que l’on peut automatiser et la possibilité d’avoir une liste des serveurs disponibles en une ligne de commande pour n’importe quel Devops allergique aux opérations sur navigateur web.

Dans le but de rester élastique dans la démarche, nous allons utiliser deux fonctionnalités DNS des plus intéressantes qui sont :

Nous allons aussi nous aider des API Amazon et tout ça dans un environnement Linux. Notre DNS va donc servir de base de données pour référencer les machines via leurs IP privées.

Liste des pré-requis

Un serveur T1-Micro sur Amazon servant de DNS est largement suffisant. Le package BIND9 doit être installé. Sachant que sur une infrastructure nous préférons utiliser des noms à la place des IP, l’utilisation d’un DNS est fortement conseillée. De plus, la configuration des différents éléments techniques d’une plate-forme est nettement plus souple en utilisant des noms.

Configuration

Pour effectuer des requêtes nsupdate sur un DNS il faut autoriser les IP des machines qui ont le droit d’émettre ces requêtes vers notre DNS (nsupdate et axfr). Ensuite il faut placer les bases du DNS (fichiers db.xxx) dans un endroit ou le process bind a le droit d’écrire. Pour des raisons de sécurité, il est hors de question que ce process puisse avoir un accès en écriture dans le répertoire /etc/ nous allons donc déplacer ces fichiers dans /var/cache/bind/.

Elements de Configuration DNS

Dans le fichier named.conf.local dans la section de la zone que nous voulons contrôler il faut ajouter l’ip de la machine autorisée à faire les requêtes nsupdate :

allow-update { xxx.xxx.xxx.xxx; };

Les requêtes AXFR sont autorisées dans ce même fichier de configuration en ajoutant l’ip des serveurs autorisés dans la sections “allow-transfer” de la zone.
Dans cette même section nous allons déplacer le fichier de la zone en modifiant son chemin :

file « /var/cache/bind/db.xxxx.yyyy »;

Démarche

Une fois cette opération réalisée nous pouvons utiliser les API Amazon pour récupérer les informations qui concernent une instance (par exemple, nous utiliserons ec2-describe-instances dont la documentation est à l’adresse suivante :  DOC API).
Les informations que nous allons récupérer (security groupes, Key, EBS ID…..), vont être réorganisées pour ensuite être injectées dans le DNS sous la forme d’enregistrements TXT en plus de l’enregistrement A utilisé pour référencer une adresse.
Pour réaliser une mise à jour automatique du DNS il est préférable d’exécuter une instruction de “delete” avant l’ajout d’un enregistrement. Vu que nous sommes sur un DNS qui sera utilisé pour les zones de notre infrastructure nous allons prendre en compte les trois enregistrements suivants :

Pour enlever les enregistrements précédents (dans le cas ou le serveur est déjà référencé ou pour enlever le serveur).

nsupdate
> server monserverdns.domain.com
> zone domain.net
> update delete monserver.domain.net A
> update delete monserver.domain.net TXT
> update delete zzz.yyy.xxx.www.in-addr.arpa. PTR
> send

Ensuite on enregistre le serveur.

nsupdate
> server monserverdns.domain.com
> zone domain.net
> update add monserver.domain.net 86400 IN A www.xxx.yyy.zzz
> update add monserver.domain.net 86400 IN TXT informations sur le serveur
> update add zzz.yyy.xxx.www.in-addr.arpa 86400 IN PTR monserver.domain.net.
> send

Nous partons du principe que le DNS est bien déclaré au niveau du fichier /etc/resolv.conf.

Une fois tous les enregistrements en place il suffit de passer la commande suivante pour que la liste apparaisse :

dig @ip_du_dns axfr domain.net

sh-3.2# dig @10.211.55.5 axfr test.net
; <<>> DiG 9.7.3-P3 <<>> @10.211.55.5 axfr test.net;
(1 server found)
;; global options: +cmd
test.net. 604800 IN SOA dns. root.test.net. 4 604800 86400 2419200 604800
test.net. 604800 IN NS dns.
test.net. 604800 IN A 10.211.55.5
test.net. 604800 IN AAAA ::1
s1.test.net. 86400 IN A 1.2.3.4
s1.test.net. 86400 IN TXT « tout » « ce » « que » « l » « on » « peut » « dire » « sur » « un » « serveur »
test.net. 604800 IN SOA dns. root.test.net. 4 604800 86400 2419200 604800
;; Query time: 19 msec
;; SERVER: 10.211.55.5#53(10.211.55.5)
;; WHEN: Mon Jan  9 16:03:56 2012
;; XFR size: 7 records (messages 1, bytes 237)

Nous touchons au but. Il suffit maintenant d’exécuter la même commande avec un grep sur “TXT” pour récupérer la liste qui nous intéresse.

Avec la commande suivante nous allons enlever l’enregistrement TXT du DNS :

nsupdate
> server monserverdns.test.com
> zone test.net
> update delete monserver.test.net TXT
> send

sh-3.2# dig @10.211.55.5 axfr test.net
; <<>> DiG 9.7.3-P3 <<>>
@10.211.55.5 axfr test.net;
(1 server found);;
global options: +cmd
test.net. 604800 IN SOA dns. root.test.net. 5 604800 86400 2419200 604800
test.net. 604800 IN NS dns.
test.net. 604800 IN A 10.211.55.5
test.net. 604800 IN AAAA ::1
s1.test.net. 86400 IN A 1.2.3.4
test.net. 604800 IN SOA dns. root.test.net. 5 604800 86400 2419200 604800
;; Query time: 2 msec
;; SERVER: 10.211.55.5#53(10.211.55.5)
;; WHEN: Mon Jan  9 16:15:30 2012
;; XFR size: 6 records (messages 1, bytes 183)

Nous avons donc une base de données (le serveur DNS) qui va nous servir de référence pour y placer toutes les informations des instances tirées des API Amazon.
Cet article n’aborde pas le côté sécurité de bind et ne fait donc pas référence à la gestion de clé pour les requêtes nsupdate.

Laurent ROUX

1. Champ Libre pour l’Open Source
2. La Portabilité dans le Cloud
3. DevOps
4. AWS, l’Unique ?
5. Cloud Privé : Mythe ou Réalité ?
6. Moteur Hybride
7. Infogérance

En vous souhaitant bon visionnage !

Frédéric FAURE @Twitter @Ysance

Urbandive is an immersive view service launched by the French YellowPages which allows you to travel in cities in France thanks to a 360° view. Urbandive focuses on providing high definition pictures and accurate professional and social content. One of the biggest jobs was to enable a fast scalable architecture, because it was really difficult to forecast the traffic load at production time. Traffic load may be influenced if the service receives attention from users as a result of advertising.

Below you will find a summary of the goals we achieve by using a Ruby scheduler built on top of Puppet on AWS to create a complete infrastructure.

Workflow & XTR-Lucid
Our scalability combo is : a home-made Ruby scheduler (XTR-Lucid) to deal with AWS APIs + the Puppet Master to install services and configure EC2 instances and keep them up-to-date during all the production time. This leads to full automation.

Here is the workflow (for the creation step, there are other workflows for stop/reboot/health-check/…) of our automation tool. The dashboard allows you to select a template (which contains the following informations : AMI id, instance type, availability zone, key, list of security groups, list of EBS – from snapshots or not -, …) and to set a name for the instance in the « create » workflow.

This schema gives the general idea of how it works.

To be more accurate and to explain the workflow just a bit :

• The scheduler can be outside or inside of AWS.
• First an action file is put into the TODO directory, by the web application (simple rhtml dashboard) or by the monitoring tool directly. For posting files from the monitoring tool, we will have to define thresholds after some weeks of use of the application. At this time, we have not enough data feedback as we just commenced production.
• The action file is then processed by the scheduler :

1. Connection to AWS and request to start an EC2 instance from the AMI.
2. Scheduler checks that instance is running, EBS (Elastic Block Store) are available, then in-use, and eventually that EC2 TCP stack is up and SSH is OK. Then it connects to the brand-new instance.
3. Puppet client is installed and started, so it sends a certificate request to the master.
4. Puppet client is stopped to avoid any interaction.
5. Connection to the PuppetMaster : update the main files (nodes files of PuppetMaster, « /etc/hosts » file, roles file of Capistrano) and then accept the certificate request of the client.
6. Capistrano updates the « /etc/hosts » file on all instances of our infrastructure as soon as a new EC2 instance comes up (or down), without having to trigger (puppetrun) the simultaneous « pull configuration » of all the Puppet clients.
7. Connection to the new instance.
8. Puppet client is started.
9. Puppet client connects to the master and authenticate. Then it gets what it needs to install and configure the new instance.
10. The installation occurs on the new instance that will be soon available.

• The scheduler doesn’t wait until the instance is fully configured to end the task : installation by Puppet is asynchronous. The scheduler just ends by updating its repository and the monitoring tool.

Technical note 1 : we use Capistrano mainly for application deployment. In the above case (create instance), we use it to update the « /etc/hosts » file on all instances of our infrastructure as soon as a new EC2 instance comes up (or down – it is the same use for stop instance), without having to trigger (puppetrun) the simultaneous « pull configuration » of all the Puppet clients (bad idea ;ob). That’s just a little tip for this workflow.

Technical note 2 : the Ruby scheduler works in asynchronous mode (for security reasons & to be called by other tools – like a monitoring one) by creating action files from the web application in the TODO directory (which can be filled by the monitoring tool for auto-scalability) checked every minute by a CRON which calls the heart of the automation tool.

Technical facts

• We have actually 40 – 50 servers, that’s our base, but we probably will go higher when the traffic will come with marketing campaigns.
• We use Lucid Lynx Ubuntu OS (from a standard AMI powered by Canonical).
• We use the PuppetMaster installed on Apache with Phusion Passenger to increase performances.
• We took Puppet (standard version) right from the Ubuntu repositories packaged in the AMI.

Why using Puppet (and especially on AWS) ?
Consistency & Flexibility
We have multiple services, so we need to be sure that each group of servers is consistent in terms of configuration. If we need to push a quick change on all nodes of a type at a given time, we can even push (trigger « pull », to be more accurate, with puppetrun) this new setting from the PuppetMaster without waiting the pull of Puppet client (30min period) and we are sure that this one is pushed everywere it is needed.
AWS offer AMIs to « snapshot » an instance and clone this one as many as we want. This is very good for developpement, load tests, .. But when we come into production, we cannot build another AMI each time we do a change on a setting and deploy again EC2 instances from the new AMI. We need something flexible to patch our configurations quickly, keeping consistency at all times.

Scalability & Ease
This is a new Internet service which can have a load peak at anytime depending on marketing campaigns. But we have to deal with financial things too. So we keep a base and have to start quickly full configured up-to-date instances within a few minutes. We achieve this by writing a home-made ruby-script-based scheduler (XTR-Lucid) that deals with AWS APIs to launch/stop EC2, add EBS (empty or from snapshot), add/remove to/from ELB, add/delete the new/old host to/from our monitoring tool, … AWS EC2 instances are kept in a repository on our Ruby scheduler. Then our tool lets Puppet take over which ensures for each brand-new instance started from a standard Lucid Lynx AMI that all services, configurations, security rules are installed/applied. So with the feedback of our monitoring tool, the infrastructure can grow and decrease alone (depending on the thresholds set) or we can deploy and stop instances in just one click on our web dashboard.

Operating
In such a project, there is a lot of various services to monitor for the Ops team (And… Yes ! Ops team is always essential, even with automated infrastructure ! :o)). So this is important to capitalize upon knowledge in Puppet descriptors and XTR-Lucid repository and templates, so that by simply reading the descriptors/repository/templates, the whole team knows all what it needs to know at a glance (no need to look everywhere). Things become a lot easier.

Portable Infrastructure
Because of the diversity of services run in the project, maybe not all will fit into AWS in a long term experience (over one year). Once we have real-life feedback on traffic, some services will stay on AWS, others, maybe, will migrate into our physical datacenter. So it will be easier to migrate because all the configuration is concentrated in Puppet descriptors. This enables us to re-deploy easily a brand-new infrastructure on another plateform (even if it is not in the Cloud).

I hope you enjoyed this. You can find here some more information on the way the Ops job is evolving, based on this experience (among others) : Solutions Linux / Open Source 2011 – Le métier de l’Administration Système avec le Cloud Computing (FR). These slides are the ones used for a talk I gave at Solution Linux 2011 (France).

Frédéric FAURE @Twitter @Ysance

Après quelques formations intra-entreprise, une nouvelle session inter-entreprises est ouverte ! Je vous annonce donc que je donnerai une formation sur les AWS (Amazon Web Services) destinée aux professionnels le Jeudi 8 Septembre 2011. Elle se déroulera à Paris en une journée. Cette formation est éligible au financement par les OPCA (Agefos, FAFIEC …), peut être intégrée à une période de professionnalisation ou à un DIF.

Le but de la formation est de donner une vue d’ensemble des différentes offres (AWS, GAE & Azure) et de leur positionnement et d’expliquer ce qu’est le Cloud Computing (modèle économique et services), puis de se concentrer sur l’offre d’Amazon (architecture, services, résilience, support, sécurité, …) et de la mettre en pratique (EC2, EBS et S3). La dernière partie est une ouverture sur les outils à mettre en place afin d’optimiser l’utilisation de ces ressources (gestionnaire de configuration centralisée, serveur de logs, métrologie, …).

La formation sera axée à la fois sur une approche théorique et pratique, avec 30% du temps de formation passé à réaliser des travaux pratiques (sur les composants principaux que sont EC2, EBS et S3, ainsi que manipulation des outils et gestion de compte AWS), et sur une forte interactivité afin de répondre à toutes vos interrogations.

Qui peut y participer ?
Des chefs de projet, architectes techniques et fonctionnels, administrateurs système, responsables d’équipes de développement, directeur/responsable informatique.

Quel est le programme proposé ?

1ère Demi-journée
Le Cloud Computing

• De quoi s’agit-il ?
• Les acteurs du marché et leurs différentes approches (Amazon, Microsoft, Google, …)

Le cas Amazon

• De quoi s’agit-il ?
• Comparaison d’une infrastructure Cloud AWS avec une infrastructure physique classique
• Les cas d’utilisation
• Les coûts

Les outils

• Gestion de son compte (clés, certificats, facturation, support, …)
• Les consoles d’administration (Console AWS, ElasticFox, S3 Organiser)
• Les APIs

2ème Demi-journée
Les services infrastructure AWS

• Elastic Compute Cloud (EC2)
• Elastic Block Storage (EBS)
• Simple Storage Service (S3)
• Séance de TP sur EC2, EBS et S3

AWS… Encore un peu plus loin

• Overview automatisation & dynamisme : gestion de la configuration centralisée avec Puppet, déploiement automatisé avec Capistrano, monitoring avec Cacti & Centreon/Nagios, gestion des logs avec Syslog-NG, auto-scalability, LVM, …

Les informations utiles

• Forums, sites, liens, livres blancs (sécurité, extension SI, …)

Quelles sont les modalités pratiques ?
Lieu : A venir
Date : Jeudi 8 Septembre 2011
Heure : A venir

Durée : 1 journée
Tarif : 800 euros HT
Toutes les sessions se déroulent dans le centre de Paris. Cette formation est éligible au financement par les OPCA (Agefos, FAFIEC …), peut être intégrée à une période de professionnalisation ou à un DIF. Nous pouvons vous aider à monter votre dossier.

Pour vous inscrire, cliquez ICI.

En espérant que vous viendrez nombreux. :o)

Frédéric FAURE @Twitter @Ysance

De retour du salon Solutions Linux / Open Source 2011 (salon professionnel annuel dédié aux logiciels et solutions libres pour les entreprises), je publie les slides que j’ai présentés en compagnie d’Omer SHALA (Mappy) lors d’une des conférences du salon ayant pour sujet le Cloud Computing. Cette présentation porte sur l’évolution du métier de l’Administration Système avec l’utilisation du Cloud Computing. Nous avons pris comme support notre expérience du projet UrbanDive, le nouveau service de vue immersive en zone urbaine du groupe PagesJaunes.

Omer SHALA, responsable de l’infrastructure du projet, a tout d’abord exposé le contexte du projet, puis a expliqué les éléments de décision qui nous ont amené à choisir le Cloud Computing (et en l’occurrence les Amazon Web Services – AWS) pour mettre en place nos services. Il a finalement fait une synthèse de son expérience de la mise en place de cette infrastructure avec les services d’Amazon (de type IaaS – Infrastructure as a Service), par rapport à ses expériences avec des infrastructures plus classiques (en datacenter) au sein du groupe PagesJaunes.

J’ai repris la seconde partie de la conférence et ai exposé ma vision de l’évolution de l’administration système avec l’utilisation de solutions de type Iaas. Pour finir, j’ai présenté ce que nous avons mis en place pour optimiser le potentiel des services Amazon, notamment via l’automatisation :

• avec le développement d’un ordonnanceur Ruby (XTR-Lucid) pour interfacer les APIs proposées par Amazon et gérer les cinématiques de communication (création/suppression d’instances métier EC2 et disque réseaux EBS, déploiement des services, …) avec les AWS,
• avec l’utilisation d’outils Open Source comme le gestionnaire de configuration centralisé Puppet ou bien le scripteur/exécuteur de tâches Capistrano.

Je vous laisse visionner cette présentation en dessous !

Nous avons également inclus dans cette présentation la matrice de décision sur laquelle nous nous sommes basés pour décider de l’adoption du Cloud Computing pour la mise en place de l’infrastructure.

Frédéric FAURE @Twitter @Ysance

Finalement Cohérent – Construire des systèmes distribués et fiables à l’échelle mondiale exige des compromis entre la cohérence et la disponibilité.

À la base du Cloud Computing de Amazon se trouvent des services d’infrastructure tels S3 (Simple Storage Service) de Amazon, SimpleDB, et EC2 (Elastic Compute Cloud), qui fournissent des ressources pour la construction de plateformes de calcul à l’échelle d’Internet et d’une large gamme d’applications. Les exigences imposées aux dits services en infrastructure sont très strictes : ils doivent afficher de bonnes notes dans les domaines de la sécurité, la scalabilité, la disponibilité, la performance et la rentabilité, et ils doivent satisfaire ces besoins tout en desservant des millions de clients dans le monde, de façon continue.

Sous les couvertures, ces services sont des systèmes distribués colossaux qui opèrent à l’échelle mondiale. Cette échelle crée des défis supplémentaires, car quand un système traite des trillions et des trillions de requêtes, des évènements qui ont habituellement une probabilité d’occurrence faible sont désormais certains de se produire, ce qu’il faut prendre en compte dès le début lors de la conception et dans l’architecture du système. Etant donné l’étendue mondiale de ces systèmes, nous utilisons des techniques de réplication partout afin de garantir une performance cohérente et une haute disponibilité. Bien que la réplication nous rapproche de nos objectifs, elle ne peut les atteindre de façon parfaitement transparente ; sous plusieurs conditions, les clients de ces services seront confrontés avec les conséquences d’avoir utilisé des techniques de réplication au sein des services.

Une des façons par laquelle cela se manifeste est dans le type de cohérence des données fournie, surtout quand le système distribué sous-jacent fournit un modèle de cohérence à terme pour la réplication de données. Lors de la conception de ces systèmes à grande échelle chez Amazon, nous utilisons un jeu de principes et d’abstractions directeurs liés à la réplication de données à grande échelle et nous nous focalisons sur les compromis entre la haute disponibilité et la cohérence des données. Dans cet article je présente une partie du contexte pertinent qui a servi de socle à notre approche pour délivrer des systèmes distribués fiables qui doivent opérer à grande échelle. Une version antérieure de ce texte a été publiée sur le blog All Things Distributed en décembre 2007, et a été beaucoup améliorée grâce à l’aide de ses lecteurs.

Une Perspective Historique

Dans un monde idéal, il n’y aurait qu’un modèle de cohérence : à chaque fois qu’une mise à jour est faite, tous les observateurs la verraient. La première fois que ceci s’est avéré difficile était dans les systèmes de bases de données de la fin des années 70. La meilleure « œuvre historique » sur ce sujet est « Notes on Distributed Databases » , par  Bruce Lindsay et al. ⁵ Elle expose les principes fondamentaux de la réplication de bases de données et examine un certain nombre de techniques qui traitent de la réalisation de la cohérence. Plusieurs de ces techniques tentent d’obtenir la transparence de la distribution – c’est-à-dire que, pour l’utilisateur du système, il semble qu’il n’y ait qu’un seul système, au lieu d’un certain nombre de systèmes collaboratifs. Plusieurs systèmes pendant cette époque ont adopté l’approche qu’il était préférable de désactiver le système entier plutôt que de rompre cette transparence.²

Au milieu des années 90, avec l’essor de systèmes d’Internet plus importants, ces pratiques ont été revues. A cette époque, les gens commençaient à considérer l’idée que la disponibilité était peut-être la propriété la plus importante de ces systèmes, mais ils avaient du mal à décider avec quoi ils pourraient faire le compromis. Eric Brewer, professeur de systèmes à l’Université de Berkeley en Californie, et à l’époque le directeur de Inktomi, a réuni différents compromis dans son discours d’ouverture à la conférence PODC (Principles of Distributed Computing) en 2000.¹ Il a présenté le théorème CAP, qui dit que sur les trois propriétés des systèmes de données partagées – la cohérence des données, la disponibilité du système et la tolérance au partitionnement du réseau – seules deux peuvent être garanties à un moment donné. Une confirmation plus formelle se trouve dans un article publié en 2002 par Seth Gilbert et Nancy Lynch.⁴

Un système qui n’est pas tolérant aux partitionnements du réseau peut obtenir la cohérence et la disponibilité des données et le réalise souvent via l’utilisation des protocoles de transaction. Afin d’y parvenir, les systèmes client et de stockage doivent faire partie du même environnement : ils échouent comme un ensemble sous certains scénarios, et à ce titre, les clients ne peuvent observer des partitions. Une observation importante est que dans des systèmes distribués à plus grande échelle, les partitionnements du réseau sont un fait ; ainsi, la cohérence et la disponibilité ne peuvent être obtenues en même temps. Cela veut dire qu’il y a deux choix concernant ce que l’on peut laisser tomber : relâcher la cohérence permettra au système de rester hautement disponible sous les conditions du partitionnement, tandis que privilégier la cohérence veut dire que, sous certaines conditions, le système ne sera pas disponible.

Toutes les deux options exigent que le développeur client soit au courant de ce qu’offre le système. Si le système accentue la cohérence, le développeur doit tenir compte du fait que le système pourrait ne pas être disponible pour accepter par exemple une écriture. Si cette écriture échoue à cause de l’indisponibilité du système, alors le développeur devra décider ce qu’il faut faire des données qui restent à écrire. Si le système souligne la disponibilité, il pourra toujours accepter l’écriture, mais sous certaines conditions une lecture ne reflétera pas le résultat d’une écriture récemment complétée. Le développeur doit décider alors si le client a besoin d’accéder à la toute dernière mise à jour tout le temps. Il existe une gamme d’applications qui gèrent bien des données légèrement périmées, et elles sont bien desservies sous ce modèle.

En principe, la propriété de cohérence des systèmes de transactions telle que définie par les propriétés ACID (atomicité, cohérence, isolation, durabilité) est une sorte de garantie de cohérence différente. En ACID, la cohérence se rapporte à la garantie que quand une transaction est terminée, la base de données est dans un état cohérent ; par exemple, lors du transfert d’argent d’un compte à un autre, le montant total contenu dans les deux comptes ne devra pas changer. Dans des systèmes basés sur ACID, ce genre de cohérence est souvent la responsabilité du développeur qui écrit la transaction mais elle peut être appuyée par la gestion des contraintes d’intégrité par la base de données.

La Cohérence - Client et Serveur

Il existe deux perspectives sur la cohérence. L’une du point de vue développeur/client : comment ils observent les mises à jour des données. L’autre du côté du serveur : comment les mises à jour circulent dans le système et quelles garanties peuvent donner les systèmes concernant les mises à jour.

La Cohérence Client

La cohérence client comporte les éléments suivants :

• Un système de stockage. Pour l’instant on peut le considérer comme une simple boîte noire, mais on devrait supposer que, sous son couvercle, il y a quelque chose à grande échelle et hautement distribué, et qu’il a été construit afin de garantir la durabilité et la disponibilité.
• Le processus A. C’est un processus qui effectue les écritures sur et les lectures à partir du système de stockage.
• Les processus B et C. Ces deux processus sont indépendants du processus A, et ils effectuent des écritures sur et des lectures à partir du système de stockage. C’est sans importance si ce sont réellement des processus, ou plutôt des threads au sein du même processus ; ce qui compte est qu’ils sont indépendants et qu’ils doivent communiquer afin de partager des informations.
  La cohérence côté client concerne comment et quand des observateurs (en l’occurrence les processus A, B, ou C) voient les mises à jour effectuées sur un objet de données dans les systèmes de stockage. Dans les exemples suivants qui illustrent les différents types de cohérence, le processus A a effectué une mise à jour sur un objet de données :
• La cohérence forte. Après que la mise à jour soit terminée, tout accès suivant (par A, B, ou C) renverra la valeur actualisée.
• La cohérence faible. Le système ne garantit pas que les accès ultérieurs renverront la valeur actualisée. Un certain nombre de conditions doivent être respectées avant que la valeur ne soit renvoyée. La période entre la mise à jour et l’instant où il est garanti que tout observateur verra toujours la valeur actualisée se nomme la fenêtre d’incohérence.
• La cohérence à terme. C’est une forme spécifique de cohérence faible ; le système de stockage garantit que si aucune nouvelle mise à jour n’est effectuée sur l’objet, tous les accès finiront par renvoyer la dernière valeur actualisée.  Si aucun échec ne se produit, la taille maximale de la fenêtre d’incohérence peut être établie sur la base d’éléments tels les délais de communication, la charge sur le système et le nombre de répliques concernés par le schéma de réplication. Le système le plus répandu qui implémente la cohérence à terme est le DNS (Domain Name System). Les mises à jour d’un nom sont distribuées selon un modèle configuré et en association avec des caches à expiration; à terme, tous les clients finiront par voir la mise à jour.

Le modèle de cohérence à terme a un nombre de variations qu’il est important de considérer:

• La cohérence causale (causal consistency). Si le processus A a communiqué au processus B qu’il a mis à jour un objet de données, un accès ultérieur par le processus B renverra la valeur actualisée, et une écriture est garantie de remplacer l’écriture antérieure. Un accès via le processus C qui n’a pas de relation causale avec le processus A est sujet aux règles de cohérence à terme normales.
• La cohérence « lecture de vos écritures » (read-your-writes consistency). C’est un modèle important où le processus A, après qu’il a mis à jour un objet de données, accède toujours à la valeur actualisée et ne verra jamais une valeur antérieure. C’est un cas particulier du modèle de cohérence causale.
• La cohérence par session (session consistency). Ceci est une version pratique du modèle précédent, où un processus accède au système de stockage dans le cadre d’une session. Tant que la session existe, le système garantit la cohérence « lecture de vos écritures ». Si la session se termine à cause d’un scénario d’échec quelconque, une nouvelle session doit être créée, et les garanties ne recouvrent pas les sessions.
• La cohérence monotonique en lecture. Si un processus a vu une valeur particulière pour l’objet, tout accès ultérieur ne renverra jamais une valeur antérieure.
• La cohérence monotonique en écriture. Dans ce cas, le système garantit de sérialiser les écritures par le même processus. Les systèmes qui ne garantissent pas ce niveau de cohérence sont notoirement difficiles à programmer.

Un certain nombre de ces propriétés peuvent être associées les unes aux autres. Par exemple, on peut obtenir des lectures monotoniques associées à la cohérence par session. D’un point de vue pratique, ces deux propriétés (lectures monotoniques et « lecture de vos écritures ») sont tout à fait souhaitables dans un système de cohérence à terme, mais pas toujours exigées. Ces deux propriétés rendent plus simple pour les développeurs de construire des applications, tout en permettant au système de stockage de relâcher la cohérence et fournir une haute disponibilité.

Comme vous le voyez dans ces variations, un assez grand nombre de scénarios sont possibles. Tout dépend des applications spécifiques, si l’on peut gérer les conséquences ou non.

La cohérence à terme n’est pas une sorte de propriété ésotérique des systèmes distribués extrêmes. Beaucoup de RDBMSs (relational database management systems – systèmes de gestion de bases de données relationnelles) modernes qui fournissent de la fiabilité au niveau du backup principal implémentent leurs techniques de réplication tant en mode synchrone qu’asynchrone.  En mode synchrone, la mise à jour de la réplique fait partie de la transaction. En mode asynchrone, les mises à jour arrivent au backup de manière différée, souvent par l’exportation du log. En ce dernier mode, si le principal échoue avant l’exportation des logs, la lecture du backup promu produira des valeurs anciennes et incohérentes. Aussi, afin de supporter une meilleure performance scalable en lecture, les RDBMSs ont commencé à fournir la possibilité de lire à partir du backup, ce qui est un cas classique de fourniture de garanties de cohérence à terme dans lesquelles les fenêtres d’incohérence dépendent de la périodicité de l’exportation des logs.

La Cohérence Serveur

Pour la cohérence serveur, il nous faut regarder de plus près comment les mises à jour circulent dans le système afin de comprendre ce qui pilote les différents modes que peut rencontrer le développeur qui utilise le système. Etablissons d’abord quelques définitions avant de commencer :

N = le nombre de nœuds qui stockent les répliques des données

W = le nombre de répliques qui doivent accuser réception de la mise à jour avant que celle-ci ne soit complétée

R = le nombre de répliques qui sont contactées quand un objet de données est consulté via une opération de lecture

Si W+R > N, alors le jeu d’écritures et le jeu de lectures se recouvrent toujours et l’on peut garantir une cohérence forte. Dans le scénario de backup principal de RDBMS qui implémente de la réplication synchrone, N=2, W=2 et R=1. Qu’importe la réplique à partir de laquelle lit le client, il recevra toujours une réponse cohérente. Dans la réplication asynchrone quand la lecture du backup est activée, N=2, W=1 et R=1. Dans ce cas R+W=N et la cohérence ne peut être garantie.

Le problème de ces configurations, qui sont des protocoles de quorum de base, est que quand le système ne peut écrire sur les W nœuds à cause des échecs, l’opération d’écriture échoue obligatoirement, ce qui marque l’indisponibilité du système. Quand N=3 et W=3 et seulement deux nœuds sont disponibles, le système sera obligé de mettre l’écriture en échec.

Dans les systèmes de stockage distribué qui doivent fournir de la haute performance ainsi que de la haute disponibilité, le nombre de répliques est en général supérieur à deux. Les systèmes qui se focalisent uniquement sur la tolérance à la panne utilisent souvent N=3 (avec des  configurations W=2 et R=2). Les systèmes qui doivent servir des charges en lecture très élevées répliquent souvent leurs données au-delà de ce qui est requis pour la tolérance à la panne ; N peut être des dizaines, voire des centaines de nœuds, avec R configuré à 1, de telle sorte qu’une seule lecture renverra un résultat. Les systèmes qui s’occupent de la cohérence sont configurés à W=N pour les mises à jour, ce qui peut diminuer la probabilité de la réussite de l’écriture. Une configuration courante pour ces systèmes-là qui sont concernés par la tolérance à la panne mais pas par la cohérence, est d’utiliser W=1 afin d’obtenir la durabilité minimale de la mise à jour et ensuite de s’appuyer sur une technique de propagation épidémique dans le but de mettre à jour les autres répliques.

Comment configurer N, W et R dépend de ce qu’est le cas courant et de quel chemin de performance doit d’être optimisé. En R=1 et N=W nous optimisons pour le cas de la lecture, et en W=1 et R=N nous optimisons pour une écriture très rapide. Bien sûr, dans ce dernier, la durabilité n’est pas garantie en la présence d’échecs, et si W < (N+1)/2, il y a la possibilité d’écritures contradictoires quand les jeux d’écritures ne se recouvrent pas.

La cohérence faible/à terme se produit quand W+R <= N, ce qui signifie qu’il y a la possibilité que les jeux en lecture et en écriture ne se recouvriront pas. Si c’est une configuration délibérée et non basée sur un cas d’échec, alors ça n’a aucun sens de régler R autrement que sur 1.  Il existe deux cas très fréquents où cela se produit : le premier est la réplication à grande échelle pour le scaling en lecture mentionné plus haut ; le second se produit quand l’accès aux données est plus compliqué. Dans un modèle clé-valeur simple, il est facile de comparer des versions afin de déterminer la dernière valeur écrite sur le système, mais dans des systèmes qui renvoient des jeux d’objets, il est plus difficile de déterminer correctement le dernier jeu. Dans la plupart de ces systèmes où le jeu en écriture est plus petit que le jeu de répliques, un mécanisme est en place qui applique les mises à jour aux nœuds restants dans le jeu de répliques via une technique de propagation épidémique (lazy). La période jusqu’à ce que toutes les répliques soient mises à jour s’appelle la fenêtre d’incohérence, comme je l’ai évoquée plus haut. Si W+R <= N, alors le système est vulnérable à la lecture à partir de nœuds qui n’ont pas encore reçu les mises à jour.

Que les cohérences « lecture de vos écritures » (read-your-writes), session et monotonique peuvent être obtenues ou pas, dépend en général de l’association (stickiness) des clients au serveur qui exécute le protocole distribué pour eux. S’il s’agit du même serveur à chaque fois, il est alors relativement facile de garantir la « lecture de vos écritures » et les lectures monotoniques. Cela rend un peu plus difficile l’équilibrage de charges et la tolérance à la panne, mais c’est une solution simple. L’utilisation de sessions, qui ont de l’affinité (sticky), rend cela explicite et fournit un niveau d’exposition sur lequel les clients peuvent raisonner.

Parfois le client implémente la « lecture de vos écritures » et les lectures monotoniques. En rajoutant des versions aux écritures, le client rejette les lectures de valeurs ayant des versions qui précèdent la version vue en dernier.

Les partitions se produisent quand certains nœuds ne peuvent atteindre d’autres dans le système, mais tous les deux jeux de nœuds sont accessibles par des groupes de clients. Si vous utilisez une approche de type quorum majoritaire classique, alors la partition qui a W nœuds du jeu de répliques peut continuer à prendre des mises à jour pendant que l’autre partition devient indisponible. C’est également vrai pour le jeu en lecture. Etant donné que ces deux jeux se recouvrent, le jeu minoritaire devient par définition indisponible. Les partitions ne se produisent pas fréquemment, mais ils peuvent s’effectuer entre les datacenters, aussi bien que au sein des datacenters.

Dans certaines applications l’indisponibilité de toute partition est inadmissible, et il est important que les clients qui peuvent accéder à cette partition puissent avancer. Dans ce cas les deux côtés attribuent un nouveau jeu de nœuds de stockage pour recevoir les données, et une opération de fusion est exécutée quand la partition est réparée. Par exemple, chez Amazon, le panier de courses utilise un tel système de write-always (d’écriture permanente) ; dans le cas d’une partition, un client peut continuer d’ajouter des articles dans son panier même si le panier d’origine existe toujours dans d’autres partitions. L’application de gestion de panier aide le système de stockage à fusionner les paniers une fois la partition réparée.

Dynamo de Amazon

Un système qui a réuni toutes ces propriétés sous le contrôle explicite de l’architecture de l’application est Dynamo de Amazon, un système de stockage clé-valeur qui est utilisé en interne dans plusieurs services qui constituent la plateforme e-commerce (commerce électronique) d’Amazon, ainsi que dans les Amazon’s Web Services. Un des objectifs de conception de Dynamo est de permettre au propriétaire du service de l’application qui crée une instance du système de stockage Dynamo – qui s’étend fréquemment sur de multiples datacenters – de faire lui-même le compromis entre la cohérence, la durabilité, la disponibilité et la performance, tout en restant à un certain seuil de coût.³

Conclusion

Il existe deux raisons de tolérer l’incohérence des données dans des systèmes distribués fiables à grande échelle : l’amélioration de la performance en lecture et en écriture dans des conditions hautement concomitantes, et la gestion des cas de partitionnement où un modèle basé sur la majorité rendrait une partie du système indisponible bien que les nœuds soient opérationnels.

Que les incohérences soient admissibles ou non dépend de l’application client. Dans tous les cas le développeur doit savoir que les garanties de cohérence sont fournies par les systèmes de stockage et doivent être prises en compte lorsqu’on développe les applications. Il y a plusieurs améliorations pratiques que l’on peut faire au modèle de cohérence à terme, comme par exemple la cohérence par session et les lectures monotoniques, qui fournissent de meilleurs outils pour le développeur. Très souvent l’application est capable de gérer les garanties de cohérence à terme du système de stockage sans problème. Un cas précis fréquent est un site Web sur lequel on a la notion de la cohérence perçue par l’utilisateur. Dans ce scénario, la fenêtre d’incohérence doit être inférieure au temps estimé avant le retour du client pour le chargement de la page suivante. Ceci permet aux mises à jour de se propager dans le système avant que la lecture suivante ne soit prévue.

Le but de cet article est de sensibiliser le lecteur à la complexité des systèmes d’ingénierie qui doivent opérer à échelle globale et qui exigent un tuning méticuleux afin d’assurer la durabilité, la disponibilité et la performance exigées par leurs applications. L’un des outils du concepteur de systèmes est la durée de la fenêtre d’incohérence, pendant laquelle les clients des systèmes sont potentiellement exposés aux réalités de l’ingénierie des systèmes à grande échelle.

Werner Vogels @allthingsdistributed.com

Source : Eventually Consistent – Revisited
Traduction : Helen CHAUVEAU, Frédéric FAURE

References :

1. Brewer, E. A. 2000. Towards robust distributed systems (abstract). In Proceedings of the 19th Annual ACM Symposium on Principles of Distributed Computing (July 16-19, Portland, Oregon): 7
2. A Conversation with Bruce Lindsay. 2004. ACM Queue 2(8): 22-33.
3. DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall, P., Vogels, W. 2007. Dynamo: Amazon’s highly available key-value store. In Proceedings of the 21st ACM Symposium on Operating Systems Principles (Stevenson, Washington, October).
4. Gilbert , S., Lynch, N. 2002. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant Web services. ACM SIGACT News 33(2).
5. Lindsay, B. G., Selinger, P. G., et al. 1980. Notes on distributed databases. In Distributed Data Bases, ed. I. W. Draffan and F. Poole, 247-284. Cambridge: Cambridge University Press. Also available as IBM Research Report RJ2517, San Jose, California (July 1979).

Cet article constitue un retour d’expérience sur un benchmark CPU sur différents types (tailles) d’instances EC2 sur AWS. L’objectif était de constater le comportement, au niveau des ressources CPU, desdites instances lors d’une montée en charge sur un traitement multi-threadé et de les comparer par rapport à un étalon plus récent (choisi arbitrairement, comme un portable) que celui proposé par AWS : l’ECU ou EC2 Compute Unit.

Tout d’abord, je tiens à remercier Sylvain Terret qui a effectué le test « en ressortant un vieux bout de code du placard » et qui a aussi écrit un billet sur son blog sur le sujet. Ensuite, je fais également écho à un article intéressant (EC2 isn’t 50% slower) qui répond à quelques controverses sur la réalité des ressources CPU mises à disposition lors du lancement d’une instance EC2. Je vous invite à lire cet article synthétique et instructif, ainsi que les commentaires associés.

Pour commencer, le bench a été effectué sur un Ubuntu Lucid Lynx. Le code ci-dessous a été utilisé pour charger les différents types d’instances EC2 : il s’agit d’une multiplication de matrices basée sur l’API OpenMP.

Ce calcul matriciel va être exécuté plusieurs fois en incrémentant à chaque fois le nombre de threads qui vont se partager (parallélisation) le calcul. Ainsi, nous avons pu comparer un même traitement lorsqu’il est exécuté par 1, 2, … 12 threads et constater l’évolution du temps d’exécution en fonction du type d’instance EC2, c’est à dire, dans le cas qui nous intéresse, en fonction du nombre de CPUs disponibles sur chaque type d’instance. Il est à noter que chaque CPU affecté au traitement d’un thread donné est monopolisé à 100% lors de l’exécution du calcul.

Le code source est le suivant :

#include
#include
#include
#include

#define SIZE 2000

double get_time() {
struct timeval tv;
gettimeofday(&tv, (void *)0);
return (double) tv.tv_sec + tv.tv_usec*1e-6;
}

int main(int argc, char const *argv[]) {
int nb, i, j, k;
double t, start, stop;
double* matrice_A;
double* matrice_B;
double* matrice_res;

// Allocations
matrice_A = (double*) malloc(SIZE*SIZE*sizeof(double));
matrice_B = (double*) malloc(SIZE*SIZE*sizeof(double));
matrice_res = (double*) malloc(SIZE*SIZE*sizeof(double));

for(i=0; i for(j=0; j matrice_A[i*SIZE+j] = (double)rand()/(double)RAND_MAX;
matrice_B[i*SIZE+j] = (double)rand()/(double)RAND_MAX;
}
}
printf(« Nb.threads\tTps.\n »);

for(nb=1; nb<=12; nb++){
start = get_time();
#pragma omp parallel for num_threads(nb) private(j,k)
for(i=0; i for(j=0; j matrice_res[i*SIZE+j] = 0.0;
for(k=0; k matrice_res[i*SIZE+j] += (matrice_A[i*SIZE+k] * matrice_B[i*SIZE+j]);
}
}
}
stop = get_time();
t = stop – start;
printf(« %d\t%f\n », nb, t);
}
// Libérations
free(matrice_A);
free(matrice_B);
free(matrice_res);
return EXIT_SUCCESS;
}

Les instances benchées sont les suivantes :

• Standard Instances – Large Instance (M1.LARGE) 7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of local instance storage, 64-bit platform
• Standard Instances – Extra Large Instance (M1.XLARGE) 15 GB of memory, 8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit platform
• High-CPU Instances – High-CPU Extra Large Instance (C1.XLARGE) 7 GB of memory, 20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit platform

A noter, la définition de l’ECU (rien à voir avec une nouvelle-ancienne monnaie unique) qui est l’étalon AWS en termes de puissance CPU et qui correspond à :

EC2 Compute Unit (ECU) – One EC2 Compute Unit (ECU) provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.

Cela, disons-le, ne représente pas grand chose, mais j’y reviendrai plus tard.

A noter également notre étalon qui est constitué d’un portable posé sur le bureau et équipé d’un Core 2 Quad Q8400 @ 2.66 GHz x 1 (4 cores).

Synthèse graphique

CPU benchmark on EC2

Analyse des résultats

• Tout d’abord de manière macro, il est rassurant de voir que doubler le nombre de « virtual cores » (2 => 4 => 8) double les performances pour des « virtual cores » sensiblement identiques (2 virtual cores de 2 ECUs chacun => 4 virtual cores de 2 ECUs chacun => 8 virtual cores de 2.5 ECUs chacun). Comme le dit Sylvain : « Ca sent un peu le Captain Obvious, mais à bien y réfléchir, ce n’est pas une règle d’or dans l’informatique. »
• Le Core 2 Quad posé sur le bureau est plus efficace à nombre de coeurs équivalent que les instances EC2 (une M1.XLARGE avec 4 coeurs de 2 ECUs chacun dans notre cas).
• Ensuite, il est intéressant de noter que nous n’avons obtenu sur le lancement des instances que des processeurs Xeon (Intel) : E5430 @ 2.66 GHz pour les M1.LARGE et M1.XLARGE et E5410 @ 2.33 GHz pour les C1.XLARGE. Quelles auraient été les résultats si nous avions eu des Opteron (AMD) ? Il faut savoir que l’on ne choisit pas son type de processeur au lancement d’une instance. Cependant, cela fait quelques temps que je n’ai plus vu d’Opteron au lancement d’instances EC2 : il faut dire que je travaille depuis quelques temps quasi exclusivement sur la région européenne d’Amazon (par opposition aux EU, voire à l’APAC). Je n’ai pas investigué sur ce sujet beaucoup plus au delà.
• Une anomalie est à noter concernant les tests sur les M1.XLARGE : la différence de performance sur les 3 premiers calculs (de 1 à 3 threads) entre les deux instances M1.XLARGE (4 virtual cores) : une des 2 instances a donné des performances moins bonnes sur le même bench qui a tourné deux fois sur chaque machine (les résultats ont été constants). Je n’ai pas trouvé d’explication sur cette différence entre les 2 instances.
• Ce qui n’apparaît pas sur le graphique et que l’on constate, en se connectant directement sur les instances, via top ou htop : on voit à chaque nouveau calcul exécuté et distribué sur un thread supplémentaire un nouveau CPU passer à 100% (calcul sur 2 threads = 2 CPUs à 100%, …) et lorsque l’on atteint « nombre de threads >= nombre de CPUs de l’instance », on voit apparaître un pourcentage de steal sur les CPUs de l’instance.

Le % steal
Pour analyser un peu plus en détail la présence de steal, nous avons effectué un autre test de performance (merci à Yann Le Van pour le graphe !) en monitorant un MongoDB (toujours sur Ubuntu Lucid Lynx) que nous avons maltraité en y injectant par palier de nombreuses requêtes de géolocalisation non bornées avec des critères de recherche sur des attributs supplémentaires (Cf. requêtes géospatiales et indexation composée). Il apparaît de nouveau clairement qu’un pourcentage non négligeable de steal progresse avec l’utilisation des CPUs de l’instance (les 8 coeurs d’une C1.XLARGE dans ce test).

CPU Benchmark MongoDB

CPU Benchmark MongoDB - Legende

Il ne s’agit pas de puissance CPU que l’on nous dérobe honteusement (ce que j’ai lu dans plusieurs articles concernant ce sujet), mais d’une puissance de calcul utilisé par l’hyperviseur qui gère la virtualisation sur laquelle repose notre OS. Ce test le prouve car le % steal progresse (ou décroit) proportionnellement à notre propre sollicitation de l’instance. Si il s’agissait de la sollicitation de « notre » puissance CPU par une autre instance d’un autre utilisateur sur le même hardware, l’évolution de la valeur du % steal ne serait pas directement reliée à notre utilisation (elle pourrait être constante par exemple).

La valeur du % steal n’est cependant pas négligeable et l’hyperviseur est quelque peu gourmand sur une sollicitation importante des ressources CPU de notre instance.

Conclusion
Comme je disais précédemment concernant l’étalon Amazon, l’ECU, il donne une idée de la puissance comparative des instances EC2 entre elles : si vous faites fonctionner une application multi-threadée sur une instances EC2 et que vous avez besoin de plus de puissance CPU, prendre une instance 2 fois plus puissante en termes d’ECUs vous permettra d’aller 2 fois plus vite (à noter qu’en fonction du type d’instance, un coeur à une puissance de 2 à 3.25 ECUs, si on fait abstraction de la Small Instance et de la Micro Instance qui sont moins puissantes).

Sorti du paradigme AWS, l’ECU ne signifie plus rien car la valeur du GHz dépend de l’architecture, de la génération et du fabricant (Intel, AMD, …) du processeur. Un « 1.0-1.2 GHz 2007 Opteron or 2007 Xeon » ne vous donnera pas une indication très précise sur la puissance réelle dont vous allez disposer, à part le fait qu’à GHz égal, votre ordinateur de bureau équipé de la dernière génération de processeurs vous donnera de meilleurs résultats.

La meilleure (et probablement la seule valable) solution afin de constituer votre choix d’instances à déployer pour votre application est de mettre en place quelques tests de performances afin de constater réellement les ressources utilisées dans le paradigme AWS et de sélectionner les instances et de choisir leur nombre (scale-out) en fonction du résultat obtenu.

Frédéric FAURE @Twitter @Ysance

How do you scale an AWS (Amazon Web Services) infrastructure? In Part Two of the article, I describe the architecture model and the underlying technical components you should use in order to implement a scalable infrastructure. We will look in particular at the optimisation of data access in scale-out-type architectures suitable for implementation as a distributed system, as much at the data model level as the lower layers for I/O optimisation. We will also examine the recommended development concepts such as Stateless, in the finest REST tradition. I will end the article with some tips and tricks. My aim is to help you set up and optimise your infrastructure by understanding how Amazon tools operate and to get the most benefit from them.

Scale-out
Scale-out is the opposite of scale-up: the latter means the dynamic expansion on the fly of a given server’s resources (addition of RAM or CPU). Thus, the application continues running on a single machine whose capacity has been increased. Scale-out (the AWS way), on the other hand, offers to increase the number of servers in order to respond to the increased load of an application. Ultimately, the global potential of the infrastructure increases too, but is divided among several servers. This implies that the application supported on the server had been thought out in terms of distribution, that is, it can be executed in parallel on several servers without the risk of corrupting the business logic (think to shared session management or no session, for example) or creating a problem of access to the resources (which must then be available via the network and not locally on any given server, for example).

Scale-out can be likened to Agent Smith in Matrix. As for scale-up, think more along the lines of the Stay Puft Marshmallow Man in Ghostbusters!

Stateless
The best way to obtain an application that is both easy to distribute and high performing, is to plan for it in stateless mode. This means that it’s the client request which must contain all the information enabling the request to be processed by the server, either via a cookie, or else via the URL parameters. Whenever possible you should choose this approach at any price, compared to the stateful mode in which the server must keep a context for each client to be able to respond to the request. The stateless concept is one of the great REST concepts. While we’re on the subject, I strongly recommend you read this excellent article on REST (in French) by Jean-Paul Figer to appreciate the style in all its simplicity and power.

If you have to manage stateful, you will need to use a network cache such as Memcached, to share the contexts among your different servers. Don’t even consider the local cache and sticky session package, as you will have trouble getting even distribution of the load balancing. It’s not a good idea to use a cluster which communicates in multicast either, because the Amazon network does not allow that … Or all the servers could communicate in unicast with a gateway which takes care of redistributing the communications… Are you sure you don’t prefer stateless? ;ob

The implementation of stateless applications did not arrive with Cloud Computing and AWS: on the other hand, if you don’t think along these lines, you won’t be able to make the most of all the energy and flexibility they provide.

Optimisation of data access
Optimising data access requires two elements:

• The data model and software architecture that are found in scalable architecture, whether you are on an AWS infrastructure or not.
• I/O management, which can be optimised in particular by thoroughly exploiting AWS.

The scalable model
This subject deserves an entire article of its own, but the scalable model is in keeping with a rather classic model within the casual gaming-type applications, or more generally linked to applications based on the social graphs, or centred on a distinct business concept in particular.

To summarize, two methods of data storage are:

• Storage of what we’ll call the meta-model, which is not intended for distribution, built on a structured, indexed relational base (even though essentially used in the form of a key-value access), containing the general information of each user (in the case of a social application the following: name, top score, previous day’s wins, etc.), primarily accessed in read and for which it is possible to alleviate the load via a Memcached in front of it. You can therefore carry out SQL-type set-based requests (ensemblist) and thus recover information by using clauses (WHERE). This base can be a MySQL or a PgSQL for example. I suggest you read this very interesting report by Guillaume Plessis, comparing MySQL installed on an EC2 with the Amazon RDS (Relational Database Service). I don’t risk ruining the suspense by telling you that databases are a real bearded geek affair! :o)
• Storage for more volatile data (such as game data etc.), with a heavy write:read ratio, difficult to cache, and for which you must choose a real, structured, non-relational storage solution of a key-value-type (NoSQL / Not only SQL, some would say), thus enabling easy distribution of the data on X servers. I can mention a few names: Redis, Tokyo Tyrant/Tokyo Cabinet, MemcacheDB.  And also the new peer to peer models such as Cassandra.

Tokyo Cabinet

In this case, Tokyo Tyrant / Tokyo Cabinet is a solution that I have implemented, which I find satisfactory (note that a new tool Kyoto Cabinet has come and one of his worthy features is to optimize the management of multi threading and thread concurrency compared to Tokyo Cabinet). Tokyo Tyrant / Tokyo Cabinet is a twosome, managing the requests from distant servers (network interface) and access to the storage system respectively. Six APIs are available for storing the data:

1. On memory Hash,
2. On memory B+tree,
3. File Hash,
4. File B+tree,
5. Fixed-length Array,
6. Table.

Each of them has its own characteristics and responds to particular requirements in terms of performance and practicality.

Regarding performance: apart from its natural capabilities, it has the notable advantage of not managing authentication (which is usual in key-value storage systems – there are exceptions like SimpleDB, for example – ; security is supposed to be guaranteed at the network level for accessing the storage system and at the applications level for access to data – so that you can only retrieve that which concerns you). This reduces the access rate (no need for authentication requests) compared to a classic database. Furthermore, no reconstruction of onerous index management is required (possible however on the Tokyo Team’s API ‘Table’) … It goes without saying that what’s really time-consuming about data access via the network (between the web or application server and Tokyo Tyrant) is… the network! So in all cases, at the client (API) level you should use ‘mget’ (multi get), for example, by positioning a array of keys that you wish to recover in the parameters rather than performing a ‘get’ N times from the client, therefore creating N network accesses. ‘mget’ will be resolved at the Tokyo Tyrant level.

The arguments concerning this tool should be applied to all key-value-type storage.

I/O management
Now we come to the specific characteristics of AWS in terms of storage: EBS (Elastic Block Stores). EBS volumes are network disks optimised for I/Os, easy to use, ensuring the survival of crucial data during an EC2 (volatile) shutdown. On a purely practical note, I did however notice latency variances: not enormous, but on an application that is much in demand, it does get noticed. This is not insurmountable, it’s simply something to bear in mind. If your servers’ Load Average increases, it’s not necessarily the CPU which is to blame … Think I/Os! ;ob

Firstly think striping, therefore RAID0. No need for mirroring (RAID1), as the data safety in EBS is already guaranteed by Amazon, transparently, by network replication: let’s make the most of this service and concentrate on striping. Remember too to spread the writes of the different physical files (data, update logs, etc.) among different disks (for tools using update logs – and this is the case for MySQL and Tokyo Tyrant for example – do remember to set their capacity parameters). This is what allows you the best optimisations. Next, choose your filesystem carefully with regard to the tool (EXT3, XFS, etc.) and consider the mounting options (noatime, nodiratime, etc.) Finally, check the default scheduler on the EC2 instances that you are starting up: it’s the NOOP scheduler by default (I/O requests in a simple FIFO file). Consider something more efficient, such as CFQ (Completely Fair Queuing). Well, I say that, but it always depends on the top software layer, and if and how it manages the priorities: in this example (which is not on EBS) on the MySQL Performance Blog, it appears that the NOOP and DEADLINE schedulers are the best for improving the InnoDB I/O. It just goes to show, it’s always better to test first for your own particular case! ;ob

Logical Volume Management

Another tool I have used with the EBS and which works very well is LVM2 (Logical Volume Management, version 2). I haven’t used it with an architecture with a high number of IOPS (I/O Operations Per Second) and have therefore not tested the striping possibilities (RAID0) offered by the tool. On the other hand, I have used it with an infrastructure which had to be able to tolerate considerable increases in data volume but without interruptions in service. The snapshot and volume re-creation operations of an EBS are too long. LVM provides the solution, because this abstraction layer enables the management of software volumes independent of physical resources: you only need to raise a new EBS resource (a command line), associate it with the EC2 instance (another command line) and add this resource to the LVM resource pool. All that’s needed is to increase the logical volume (still transparent, without service interruption), then extend the file system. That last operation (which is a joint operation with the re-creation of the EBS volume) can necessitate shutting down the service for a few moments (around ten seconds). Note that it is possible to hot-extend your file system with EXT3, personally, I prefer a service interruption of a few seconds on this type of very short but crucial operation. ;ob  And what’s more, it is easy to perform backups on an LVM system offering a snapshot differential option, which you can mount like an independent logical volume: when there is a modification to the origin volume, the initial value is copied in the snapshot volume, so you can snapshot large volumes on a limited space because only the frequency of modification is what counts. You can find further information on LVM2 and EBS by consulting this very good article (in French) by Laurent Roux.

All these examples demonstrate that EBS are a very useful resource: you have to consider them firstly as a means of ensuring the durability of important resources before taking into account the performance aspect. In fact, performance is not necessarily better on an EBS than on the local disks of an EC2 instance (Cf. a simple and interesting test (in French) by Charles-Christian Croix. Or, to see some slightly more complex tests, Google “performance ephemeral disk ebs volume raid”. There are quite a few very interesting cases, and I must confess I find it hard to choose between them ;ob). Nevertheless, when you are committed to ensuring the safety of your data and thus using EBS (which, for those in the know, is comparable to a LUN on a SAN), there are several ways of maximising their performance.

It should be noted that, for a pure performance solution, use them to spread the files (and thus the I/Os) among several EBS disks.

Note however that the EC2 bandwidth is inevitably limiting, once you reach a certain threshold: adding EBS is helpful for smoothing out the variance differentials (in RAID0) or for optimising the throughput, but the fact remains that if you add several EBS to your EC2 instance and they are in great demand… it’s the EC2 bandwidth that jams. You will have to add a new EC2 (scale-out to increase the resources – in this case the bandwidth), attach new EBS to it (don’t forget that an EBS may be attached only to a single EC2 at a time) and partition the data onto it (sharding).

In all cases, handling the EBS is easy and this flexibility is a plus.

Tips & tricks
This last section contains some useful hints.

Aliases & IPs
Remember, on an AWS infrastructure, to position aliases corresponding to your instances’ private IPs in the ‘hosts’ file, which you then deploy via Puppet for greater reactivity, given that the IPs are ‘variable’ (when you shut down one instance and start up another straight away, you will not keep the same IP). By using the the ‘hosts’ file you will avoid provoking internal DNS resolutions for Amazon.

CDN & S3 Headers
For the CDNs (Content Delivery Networks) that you will have to use in a scalable architecture, remember to use S3 in order to provide images and other static content. It’s useless to keep a Web server only for that purpose: that’s what S3 is for, and at minimal cost.

Remember also that in certain cases where your traffic is more moderate and you don’t wish to change over to a CDN (for reasons of cost, for example ;ob), you can always optimise the management of your resources on S3 by using the metadata attributed to the said resources on S3, by positioning, for example, Cache-Control or Expires-type headers. You may visualise the metadata via the new S3 tab of the Amazon management console.

Backups… What else?
S3 is also the solution for backups. I have not found any integrated tools satisfactory for this task: I simply use a command line tool “s3cmd” in order to store my backups. I integrated this tool into Capistrano tasks called by cron. s3cmd is very simple to operate, enables the use of S3 services and offers the possibility of transferring data in HTTPS, and also to store it in encrypted format.

Conclusion
There are many more things to be said on this subject, but the abovementioned points are, in my opinion, the essential ones, in any case with regard to using the services provided by AWS. To sum up:

• Stateless and REST are, generally speaking, better adapted to AWS, since they enable easy sharing of the load on an infrastructure which can adapt to the increased load on a scale-out model.
• Data access always creates a bottleneck in distributed scaling applications. At this level it’s a matter of working on the data model and making good use of the adequate storage systems:
  • SQL technologies for metadata able to necessitate set-based querying (ensemblist) and relational things, while making maximum use of a network cache for information with a high read:write ratio.
  • NoSQL / Not only SQL / key-value technologies for information which can be accessed with a single key, and thereby benefit from the distribution inherent in scale-out.
• Finally, remember the lower layers by selecting an appropriate filesystem and scheduler. You should also consider RAID (striping) and LVM (volume extension and snapshot differential) to get the most out of the EBS’ versatility and allocation of the I/Os on different devices (always being careful with your EC2 bandwidth, which can become restrictive: in that case add one or more EC2 instances to gain bandwidth and partition – shard – the data on new EBS).

I hope you enjoyed this second part of my report on the scalability of AWS infrastructures.

Frédéric FAURE @Twitter @Ysance

How do you scale an AWS (Amazon Web Services) infrastructure? This article will give you a detailed reply in two parts: the tools you can use to make the most of Amazon’s dynamic approach, and the architectural model you should adopt for a scalable infrastructure. I base my report on my experience gained in several AWS production projects in casual gaming (Facebook), e-commerce infrastructures and within the mainstream GIS (Geographic Information System). It’s true that my experience in gaming (IsCool, The Game) is currently the most representative in terms of scalability, due to the number of users (over 800 thousand DAU – daily active users – at peak usage and over 20 million page views every day), however my experiences in e-commerce and GIS (currently underway :o)) provide a different view of scalability, taking into account the various problems of availability and data management. I will therefore attempt to provide a detailed overview of the factors to take into account in order to optimise the dynamic nature of an infrastructure constructed in a Cloud Computing environment, and in this case, in the AWS environment.

The tools
I will provide examples of tools I used in my various production experiments and which won me over with their efficiency. However, it’s not so much the tools themselves which are emphasised, rather the underlying features that must be installed to fully exploit the AWS.

What is the difference between an AWS and a standard infrastructure?
There are two replies:

• Firstly, the AWS enable the Hardware and Infrastructure components to be handled via the code (through the APIs): this gives them momentum which needs to be intensified by correctly selecting your tools. Amazon also offers a certain number of technical guarantees with their services, which should be used to full advantage in order to concentrate on what is essential.
• The second answer should be: ‘None!’ However, it must be acknowledged that often the cosy aspects of ‘home’-hosted infrastructure can lead to a certain lack of rigor on many issues. The fact that Amazon, with its AWS, offers a dynamic and volatile solution for the EC2s, compels you to install mechanisms which should be standard.

Centralised configuration management
In order to instantiate multiple servers (EC2) on the fly to counter a load peak or perform occasional procedures, we have to use a centralised configuration management tool. This has multiple uses:

• Rapid instantiation of a machine corresponding to a pre-defined type: Web server, cache server, etc.
• Ensuring uniform configuration of the entire set of instances of the same type at all times.
• Capitalising on the expertise: packages, configurations, services etc. for each type of instance are contained within a descriptor. This enables new users (and others) to learn the composition of the servers simply by reading the associated descriptor(s.)

Puppet is a very attractive solution for this task. Puppet architecture comprises:

• A Puppet Master, guardian of configurations. It contains the descriptors of the packages to be installed, configuration files to be pushed and services to be started up for a new EC2 instance in order to prepare it according to the type of node or nodes with which you have associated it, or simply to keep an existing instance updated.
• Multiple Puppet clients installed on EC2 instances. The client regularly polls the master to check that his configuration is up to date. It is also possible to trigger the clients from the master to initiate an urgent update.

It is thus very simple to mount a new instance of a given type, and to be sure that from one server to another, the configuration is identical in every way. It should be noted that the Puppet Master descriptors run on a node system, and a server may reference more than one node. You will therefore obtain a very modular configuration.

Puppet Module Descriptor

The centralised configuration manager is indispensable on a scalable infrastructure, which can have a large number of instances, some of which should be mounted rapidly, in order to reply to user requests during load peak.

‘But’, you may say, ‘you do have to install the client on the new instance, don’t you?’ Oh yes, all the more so as there is a system of certificate request/acceptation between the client and the master, so that not just anybody can access the configurations. ‘There’s nothing simpler!’ I reply. Instead of using an HMI (Human Machine Interface) such as ElasticFox to connect to the Amazon services APIs, you need simply to connect with command lines via a script which instantiates an EC2, creates if necessary an EBS volume and associates it, connects with SSH on the new instance and installs the client, connects on the master and accepts the certificate request, reboots the client and ‘Bingo!’ The instance installs and configures itself. In general, the reactive and dynamic capacities inherent in EC2 and AWS require it, otherwise it would be an under-exploitation, or even a misuse of the tool.

And what about the AMIs (instance-store root devices) or the EBS root devices (note that for the latter there is not yet a great choice of templates)? It is however possible to build an AMI or even an EBS root device with the Puppet client installed on it (and to use, if necessary, the user-data at the launch of the instance in order to set the parameters if a ‘static’ configuration on the AMI is not sufficient). However, in a production environment, the AMI and the EBS root device do not allow you to replace a Puppet: if you have to modify the AMI every time you change the parameters and redeploy the EC2… you’ll never finish. The AMI is a good tool for instantiating a basic template, but not for maintaining a production infrastructure in good working order.

To sum up, it is even possible to envisage auto-scalability (a more complete service than the one offered by Amazon’s Auto Scaling, based on CloudWatch), which would amount to starting up this script when a value on a monitoring graph (metrology) exceeds a threshold, thereby instantiating a new instance to weather the peak period, an instance which would be ‘terminated’ after dipping below another threshold on the aforementioned graph. The possibilities are enormous. However, the cost of the final elements to be installed on a large production infrastructure to access the auto-scalability function is considerable (exponential complexity). If you get the chance, it’s an excellent handiwork, otherwise you’ll have to ‘settle’ for an easily scalable solution whereby you simply launch a script manually (or else at a fixed time based on the study of the metrics produced by the metrology, which is a satisfactory alternative). If necessary, manually adding one or two references in a file is a perfectly reasonable alternative.

Execution of automated tasks in parallel
Because of the variation in the number of instances according to the load of a scalable infrastructure, and particularly in the potentially large number of these instances, you cannot envisage carrying out maintenance and deployment operations on an individual basis for each machine (or manually, which is even worse!). This would not only be too time-consuming, but would also lead to errors. It is therefore essential to use tools specialising in automation and parallel task execution, such as Capistrano, which has numerous advantages:

• Scripting a certain number of tasks, whether complex or not (deliveries, backups, site publication/maintenance, etc.) executing them rapidly in parallel on X instances with a single command.
• Ensuring the reproducibility of a task.
• Capitalise on know-how (Cf. Puppet).

Capistrano Task Descriptor

This tool is very practical and easy to use. It executes tasks in parallel (by connecting with SSH – don’t use the ‘root’ key of your EC2 instances in the tool, it’s classier to use a dedicated key…) on one or a group of servers defined by roles.

This tool should be used as a supplement to Puppet and not a replacement, as they do not have the same targets:

Objective
Puppet - Uniform configuration of the server pool.
Capistrano – Task reproducibility and in-parallel execution.

Operating mode
Puppet – Regular pull requests by clients (or even push from the master).
Capistrano - Occasional tasks (manual request or by cron).

Orientation
Puppet - Pre-defined objects / notions such as ‘Package’, ‘Service’, ‘File’, etc.
Capistrano – Generic commands such as ‘upload’, ‘download’, ‘system’, ‘run’, etc.

Target
Puppet - Infrastructure and services.
Capistrano - Services and applications.

Note that Webistrano is an HMI enabling access to the Capistrano features and introducing the notion of project management by managing access to the tasks according to profile, to trace who deployed what on which server and to send email signals in response to certain actions. I find this joint operation with project management very interesting.

Monitoring
This is one of the crucial elements of a scalable architecture, if not the main one. It is essential to have the metrics to hand, precisely so you know when to scale. This enables you to identify the clogged points of the infrastructure, to analyse your site traffic and to make deductions about user behaviour. It also enables signals to be triggered.

The provision of metrics is more representative of metrology than of supervision. We will see that, in the context of an AWS infrastructure, metrology has greater added value than supervision (even if the latter remains indispensable). Speaking of which, there follows a clarification of the two monitoring disciplines that you need to recognise:

• Supervision verifies the state of a host or a service and sends out an alarm upon detecting any abnormal behaviour (over-long response time, status NOK, etc.) and requires immediate action on the part of the interface partner concerned. An alarm must signify that the host or the service is unusable (critical) or may soon be (warning) and must not send back ‘simple information’ which would obstruct the visibility of real incidents.
• Metrology enables data to be archived, and if necessary, processed or filtered, before it is presented in the form of graphs or reports. This data enables corrections to service development or configuration to be carried out after the event, in order to optimise the aforementioned services, and equally to define the resources to be attributed to them in the most effective way. This aspect of monitoring is just as important, for it will enable the service to be improved (and thereby the users feedback) and also to reduce costs. The metrology results should clearly highlight the improvements to be made by correlating the values recovered.

Quite a number of monitoring tools are available on the market, each with its pros and cons, some more supervision-oriented, others more towards metrology. Among them: Centreon/Nagios, Zabbix, Cacti and Munin. Personally I use Centreon/Nagios mainly for supervision and Cacti for software-oriented metrology with pre-packaged graphs such as for Apache, MySQL, Memcached, etc. I tried Munin, it lacks some of the useful features of Cacti but it is really easy to use and it matchs very well with Puppet (configuration based on descriptors and symlinks). I’ve also heard many good things about Zabbix (comprehensive range of features).

Thread Scoreboard Apache - Yearly - 1 Day Average

It should be noted that these tools operate mostly (Centreon, Cacti and Munin) on RRDtool (Round-Robin Database), a database management tool which also enables a graphic representation of the data contained in the base. The big advantage stems from the fact that the stored data volume is minimal, whether for storage of several months, or even years. This is made possible by calculating the averages of the time periods (from 1 minute to 1 day): the recent data is exact, whereas the older data is approximate.  This is very practical, as you have both the recent exact metrics and you keep the historic, a representation of the evolution of your architecture.  This is excellent for visualising the evolution of the key metrics and understanding the impact of the evolution of the components of the aforementioned infrastructure, or the applications supported as and when the different releases are delivered.

As for Cloud Computing-type infrastructures, metrology is the discipline with the highest added value, as it will enable feedback to your automation tools.

Keep in mind also that it’s interesting to be able to integrate dynamically the new instances installed and configured by Puppet in the monitoring tool. Give priority therefore to monitoring tools with modular configuration or simple access via APIs.

Managing centralised logs
It’s undeniable: the more instances you have, the more scattered logs there’ll be on the various instances. Moreover, sending all the logs to the syslog daemon becomes difficult, as the infrastructure components do not necessarily manage it very well (redirection, respecting the syslog protocol, etc.), not to mention the application(s) / functional block(s) which can log in the various files on the server.

Consider trying a tool such as Syslog-NG: it comprises a server and several clients, in fact it’s the same tool but with different configurations. What’s more, it is capable of regularly checking the log files (of business applications for example) and transmitting only the differential, even if it doesn’t respect the syslog protocol:

• The client recovers the files/pipe/unix-dgram/etc. logs and sends the information to the network (TCP/UDP).
• The server recovers the information from the network (TCP/UDP) and registers it in files, databases, etc.

Syslog-NG Architecture

We’re talking about only minimal differences in terms of configuration. The component can also act as a relay on more complex infrastructures by receiving the network logs from diverse clients and sending them back to the network for a server.

It is possible to apply filters before sending the logs to the network in order to send only the essential ones. Next, filters can also be applied at the server level in order to manage differently the logs coming from clients, according to their urgency, sender program, source host, etc.

It’s a simple and non-intrusive tool able to take into account the logs of scattered applications on a server (even if these logs do not respect the syslog protocol format – there is however an advantage to respecting this protocol: greater accuracy of the facilities and priorities).

Keep in mind, the same as for monitoring, that it is interesting to be able to integrate (and withdraw) dynamically the new instances to be managed at the logs system level.

Conclusion
Over and above the tools presented here, it is the underlying functions and capacities which are important. What stands out are the following:

• Tools such as centralised configuration managers, tools for the execution in parallel of automated tasks and also log managers, will become even more important. Working without them on such infrastructures is no longer conceivable.
• Monitoring is still and will remain a key value, but metrology allows you, with the analysis of key defined metrics in your infrastructure, to sustain the automation tools.
• Automation is indeed the key word promoted by AWS: the accessibility of the Hardware and Infrastructure resources via code allows us to move towards ever more autonomous architectures. However you must always position the cursor correctly, in the knowledge that the final stages of complete automation are the most expensive.

I hope that this technical feedback will interest you as much as I enjoyed working on these infrastructures. I will continue in the second part of this article: Choosing the correct architecture model for scalable infrastructures.

Frédéric FAURE @Twitter @Ysance

Comment scaler une infrastructure AWS (Amazon Web Services) ? Je vais décrire dans cette deuxième partie de l’article le modèle de l’architecture et les composants techniques sous-jacents à adopter afin de mettre en place une infrastructure scalable. Nous aborderons tout particulièrement le sujet de l’optimisation de l’accès aux données dans les architectures de type scale-out propices à la distribution, autant au niveau du modèle de données que des couches basses pour l’optimisation des I/O. Nous verrons également les concepts de développement à privilégier tel que le stateless dans la plus pure tradition REST. Je terminerai par quelques trucs et astuces en fin d’article. Le but est de vous permettre de constituer et d’optimiser votre infrastructure en comprenant le fonctionnement des outils proposés par Amazon pour en tirer le meilleur parti.

Le scale-out
Le scale-out est à opposer au scale-up : ce dernier correspond à l’augmentation dynamique des ressources d’un serveur donné (ajout de RAM ou de CPU) à la volée. Ainsi l’application continue à s’exécuter sur une même machine dont le potentiel à augmenté. Le scale-out, lui, pour répondre à la montée en charge d’une application propose d’augmenter le nombre de serveurs. Au final, le potentiel global de l’infrastructure augmente aussi, mais est réparti entre plusieurs serveurs. Cela implique que l’application supportée sur le serveur ait été pensée en termes de distribution, c’est à dire qu’elle puisse s’exécuter en parallèle sur plusieurs serveurs sans que cela n’en corrompe la logique métier ou ne pose des problèmes d’accès aux ressources (qui doivent alors être disponibles via le réseau et non en local sur un serveur donné par exemple).

Le scale-out, c’est un peu l’agent Smith de Matrix. Pour le scale-up, pensez plutôt au gentil bibendum de Ghost Buster !

Stateless
Le meilleur moyen d’obtenir une application facilement distribuable et performante est de la penser en mode stateless. C’est à dire que c’est la requête du client qui doit contenir l’ensemble des informations qui vont permettre le traitement de ladite requête côté serveur, soit via un cookie ou bien via les paramètres de l’URL. Quand cela est possible il faut privilégier cette approche à tout prix par rapport au mode stateful dans lequel la partie serveur doit maintenir un contexte pour chaque client afin de pouvoir résoudre sa requête. La conception stateless fait partie des grands concepts du REST. A ce sujet, je ne peux que vous conseiller de lire cet excellent article sur REST de Jean-Paul Figer dans lequel vous pourrez comprendre toute la simplicité et la puissance du style.

Si vous êtes obligés de gérer du stateful, il vous faudra utiliser un cache réseau, tel que Memcached, pour partager les contextes entre vos différents serveurs. N’envisagez pas la formule cache local et sticky session, car vous aurez du mal à bénéficier d’une répartition fluide au niveau de votre load balancing. N’envisagez pas non plus un cluster qui communique en multicast car le réseau Amazon ne permet pas d’en faire… Ou bien alors il faudrait que tous les serveurs communiquent en unicast avec une gateway qui s’occupe de la redistribution des communications… Vous êtes sûr que vous ne préférez pas du stateless ? ;ob

La mise en place d’applications stateless n’est pas arrivée avec le Cloud Computing et les AWS, en revanche ne pas penser dans ce sens, vous empêcherait de bénéficier de tout le dynamisme et la souplesse proposés par ces services.

Optimisation de l’accès aux données
L’optimisation de l’accès aux données passe par 2 éléments :

• Le modèle de données et l’architecture logicielle que l’on retrouve dans les architectures scalables, que l’on soit sur une infrastructure AWS ou non.
• La gestion des I/O que l’on peut optimiser, notamment via une utilisation approfondie des AWS.

Le modèle scalable
Cela pourrait faire l’objet d’un article à part entière, mais correspond à un modèle assez classique au sein des applications de type casual gaming ou bien plus généralement liées à des applications basées sur les graphes sociaux ou bien centrées sur une notion métier forte en particulier.

Pour résumer, 2 méthodes de stockage de données :

• Un stockage de ce que l’on peut appeler le méta-modèle, qui n’a pas vocation à être distribué, basé sur une base relationnelle (même si essentiellement utilisée sous forme d’accès clé-valeur) structurée, indexée, contenant les informations générales de chaque utilisateur (dans la cas d’une application sociale, avec les informations nom, top score, gains de la veille, …), essentiellement accédées en lecture et dont il est possible d’alléger la charge via un Memcached en frontal. Il est donc possible d’effectuer des requêtes ensemblistes de type SQL et ainsi de récupérer des informations via l’utilisation de clauses (WHERE). Cette base peut être un MySQL ou un PgSQL par exemple. Je vous invite à lire ce comparatif très intéressant de Guillaume Plessis entre l’utilisation de MySQL installé sur un EC2 et l’utilisation du service RDS (Relational Database Service) d’Amazon. Je ne trahirai en rien le suspens en vous disant que la base de données c’est une histoire de barbus ! :o)
• Un stockage pour les données plus volatiles (comme les données de jeu, …), avec un fort rapport écriture/lecture, difficilement cachables, et pour lesquelles il faut opter pour une réelle solution de stockage structurée non relationnelle de type clé-valeur (NoSQL / Not only SQL diront certains), permettant ainsi de distribuer facilement les données sur X serveurs. On peut citer un nombre certain de candidats : Redis, Tokyo Tyrant/Tokyo Cabinet, MemcacheDB, … Et également les nouveaux modèles peer to peer tels que Cassandra, …

Tokyo Cabinet

En l’occurrence, Tokyo Tyrant / Tokyo Cabinet est une solution que j’ai mise en place et qui me semble bonne. C’est un couple gérant respectivement les requêtes à partir de serveurs distants (interface réseau) et les accès au système de stockage. 6 APIs sont disponibles afin de stocker les données :

1. On memory Hash,
2. On memory B+tree,
3. File Hash,
4. File B+tree,
5. Fixed-length Array,
6. Table.

Chacune d’entre elles a ses propres spécificités et répond à des besoins particuliers en termes de performances et de fonctionnalités.

Au niveau performances, outre ses performances naturelles, il a l’avantage, notamment, de ne pas gérer l’authentification (standard chez les systèmes de stockage clé-valeur, la sécurité est censée être assurée au niveau réseau pour les accès au système de stockage et au niveau applicatif pour les accès à la donnée – pour ne récupérer que ce qui vous concerne), ce qui allège le nombre d’accès (pas besoin de requêtes d’authentification) par rapport à une base de données classique. De plus, pas de gestion d’index lourds à reconstruire (possible cependant sur l’API « Table » de la Tokyo Team), … Est-il nécessaire de préciser que ce qui vous prendra du temps sur l’accès à la donnée via le réseau (entre le serveur web ou applicatif et Tokyo Tyrant) c’est… Le réseau ! Donc dans tous les cas, préférez l’utilisation au niveau client (API) de « mget » (multi get), par exemple, en positionnant en paramètre le tableau de clés que vous souhaitez récupérer, plutôt que d’effectuer N fois un « get » à partir du client, donc N accès réseau. « mget » se résoudra, lui, au niveau de Tokyo Tyrant.

Ces raisonnements appliqués sur cet outil doivent être appliqués à tout stockage de type clé-valeur.

La gestion des I/O
Venons-en à la spécificité des AWS en termes de stockage : les EBS (Elastic Block Store). Les EBS sont des disques réseau optimisés en I/O, faciles à manipuler, permettant d’assurer la durabilité des données qui ne doivent pas être perdues lors de l’arrêt d’un EC2 (volatile). J’ai cependant constaté de manière empirique des écarts de latence : pas énormes, mais sur une application réellement sollicitée, il y a un ressenti. Ce n’est pas rédhibitoire, il faut juste en tenir compte. Si le Load Average de vos serveurs augmente, ce n’est pas forcément le CPU en cause… Pensez I/O ! ;ob

Tout d’abord penser striping, donc RAID0. Pas besoin de mirroring (RAID1), la durabilité des EBS est déjà assurée par Amazon, de manière transparente, par réplication réseau : tirons parti de ce service et concentrons nous sur le striping. Pensez également à répartir les écritures des différents fichiers physiques (données, updates logs, …) sur différents disques (dans le cas d’outils utilisant des update logs, et c’est le cas pour MySQL et Tokyo Tyrant par exemple, pensez à bien paramétrer leur taille). C’est ce qui permet d’avoir les meilleures optimisations. Ensuite, choisissez bien votre système de fichier par rapport à votre outil (EXT3, XFS, …) et pensez aux options de montage (noatime, nodiratime, …). Finalement vérifiez bien le scheduler/ordonnanceur par défaut sur les instances EC2 que vous démarrez : par défaut, il s’agit de l’ordonnanceur NOOP (requêtes I/O dans une simple file FIFO). Envisagez quelque chose de plus performant comme CFQ (Completely Fair Queuing) par exemple… Enfin je dis ça, mais cela dépend toujours de la couche logiciel au-dessus et si et comment elle gère les priorités : dans cet exemple (qui n’est pas sur EBS) sur MySQL Performance Blog, il apparaît que les ordonnanceurs NOOP et DEADLINE peuvent être de meilleure facture pour améliorer les I/O InnoDB. Comme quoi, il faut quand même mieux tester dans son propre cas ! ;ob

Logical Volume Management

Un autre outil que j’ai utilisé avec les EBS et qui fonctionne très bien est LVM2 (Logical Volume Management, version 2). Je ne l’ai pas utilisé dans le cadre d’une architecture avec un nombre élevé d’IOPS (I/O operations Per Second) et n’ai donc pas testé les possibilités de striping (RAID0) offertes par l’outil. En revanche, je l’ai utilisé dans le cadre d’une infrastructure nécessitant de pouvoir supporter des augmentations conséquentes du volume de données et ceci sans interruption de service. L’opération de snapshot d’un EBS et de recréation du volume est trop longue. LVM est la solution, puisque cette couche d’abstraction permet de gérer des volumes logiques de manière indépendante des ressources physiques : il suffit de lever une nouvelle ressource EBS (une ligne de commande), de l’associer à l’instance EC2 (une autre ligne de commande) et d’ajouter cette ressource au pool de ressources LVM. Il suffit alors d’agrandir le volume logique (toujours transparent et sans arrêt du service), puis d’étendre le système de fichiers. C’est la dernière opération (qui est commune avec celle de la recréation du volume EBS) qui peut nécessiter d’arrêter le service quelques instants (une dizaine de secondes). A noter qu’il est possible d’étendre son système de fichiers à chaud avec EXT3, personnellement, je préfère une interruption de service de quelques secondes sur ce genre d’opérations très courtes mais cruciales. ;ob En prime, il est facile de d’effectuer des backups sur un système LVM qui propose une option de snapshot différentiel que l’on peut monter comme un volume logique indépendant : lorsqu’il y a une modification sur le volume origine, la valeur initiale est copiée dans le volume snapshoté, donc on peut snapshoter des volumes importants sur un espace réduit car seule la fréquence de modification est importante. Vous pourrez trouver de plus amples informations sur LVM2 et EBS en consultant ce très bon article de Laurent Roux.

Tous ces exemples, pour montrer que les EBS sont une ressource très intéressante : il faut les considérer tout d’abord comme un moyen d’assurer la durabilité des ressources importantes avant de considérer l’aspect performance. En effet, la performance n’est pas forcément meilleure sur un EBS que sur les disques locaux d’une instance EC2 (Cf. un test simple et intéressant de Charles-Christian Croix ou bien encore des tests un peu plus complexes que vous pourrez retrouver en tapant « performance ephemeral disk ebs volume raid » dans Google, il y en a un certain nombre de très intéressants et je dois avouer que j’ai du mal à faire mon choix ;ob). Cependant, quand on prend le parti d’assurer la durabilité de ses données et donc d’utiliser un EBS (qui, pour ceux qui connaissent, est comparable à un LUN sur un SAN), il y a divers moyens d’optimiser leur performance.

Il est à noter que les utiliser pour répartir les fichiers (et donc les I/O) sur plusieurs disques EBS peut être une solution de performance pure.

A noter tout de même que la bande passante de l’EC2 est forcément limitant arrivée à un certain seuil : ajouter des EBS est intéressant pour lisser les écarts de variance (en RAID0) ou bien pour optimiser le débit, mais il n’en reste pas moins que si vous ajoutez plusieurs EBS à votre instance EC2 et qu’ils sont tous sollicités fortement… C’est la bande passante de l’EC2 qui bloque. Il va falloir ajouter un nouvel EC2 (scale-out pour augmenter les ressources, en l’occurrence la bande passante), lui attacher de nouveaux EBS (n’oubliez pas qu’un EBS ne peut être attaché qu’à un et un seul EC2) et distribuer la donnée dessus (sharding).

Dans tous les cas, la manipulation des EBS est aisée et cette souplesse est un atout.

Tips & tricks
Cette dernière partie regroupe quelques trucs et astuces.

Alias & IPs
Pensez sur une infrastructure AWS à positionner des alias correspondant aux IPs privées de vos instances dans le fichier des « hosts », que vous pouvez déployer ensuite via Puppet pour plus de réactivité vu que les IPs sont « variables » (lorsque vous arrêtez une instance et que vous en redémarrez une juste après, vous ne conservez pas la même IP). L’utilisation du fichier « hosts » évite des résolutions DNS internes chez Amazon.

CDN & S3 Headers
Pour les CDN (Content Delivery Network) que vous utilisez obligatoirement dans une architecture scalable, pensez à utiliser S3 afin de mettre à disposition les images et autres contenus statiques. Inutile de maintenir un serveur Web à cette seule fin, S3 est là pour ça pour un coût minime.

Pensez également dans certains cas, où votre trafic est plus modéré et où vous ne souhaitez pas passer par un CDN (pour des questions de coût par exemple ;ob), que vous pouvez toujours optimiser la gestion de vos ressources sur S3 en utilisant les méta-données attribuées aux dites ressources sur S3, en positionnant, par exemple, les headers de type Cache-Control ou Expires. Vous pouvez visualiser ces méta-données via le nouvel onglet S3 de la console d’administration Amazon.

Backups… What else ?
S3 est également la solution pour les backups. Je n’ai pas trouvé d’outils intégrés satisfaisants pour cette tâche : j’utilise simplement un outil en ligne de commande « s3cmd » afin de stocker mes backups. J’ai intégré cet outil dans des tâches Capistrano appelées par cron. Très simple d’utilisation, s3cmd permet de consommer les services de S3 et offre la possibilité de transférer les données en HTTPS et également de les stocker sous un format crypté.

Conclusion
Il y aurait encore beaucoup de choses à dire sur ce sujet, mais ce sont à mon avis les principales, en tout cas par rapport à l’utilisation des services mis à disposition par les AWS. Ce qu’il en ressort, c’est :

• Le stateless et REST de manière générale, sont d’autant plus adaptés aux AWS qu’ils permettent de distribuer aisément la charge sur une infrastructure s’adaptant à la montée en charge sur un modèle scale-out.
• L’accès aux données est toujours le goulet d’étranglement des applications distribuées devant scaler. Il s’agit de travailler à ce niveau le modèle de données et de tirer parti des systèmes de stockage adéquates :
  • Technologies SQL pour les méta-données pouvant nécessiter du requêtage ensembliste et de la mise en  relation, tout en utilisant au maximum un cache réseau pour les informations avec un fort ratio lecture sur écriture.
  • Technologies NoSQL / Not only SQL / clé-valeur pour les informations pouvant être accédées par une clé unique, et ainsi bénéficier de la distribution inhérente au scale-out.
• Penser finalement aux couches basses en sélectionnant convenablement le système de fichiers et l’ordonnanceur. Pensez également RAID (striping) et LVM (extension de volume et snapshot différentiel) pour tirer parti de la souplesse d’utilisation des EBS et répartition des I/O sur différents devices (en prenant toujours garde à votre bande passante, au niveau EC2, qui peut devenir limitant : dans ce cas ajouter une ou plusieurs instances EC2 pour gagner en bande passante et distribuer – sharder – la donnée sur de nouveaux EBS).

J’espère que ce deuxième volet de mon retour d’expérience sur la scalabilité des infrastructures AWS vous aura intéressé.

Frédéric FAURE @Twitter @Ysance