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

Application sociale / Cloud Computing : adéquation !
Tout d’abord il est important de souligner l’adéquation entre les besoins, en termes d’infrastructure, des applications sociales et le Cloud Computing : le succès des applications sociales est, en effet, basé sur un phénomène de viralité et celles-ci peuvent connaître le succès du jour au lendemain. Il est alors nécessaire de rentrer dans une phase d’extension/paramétrage de l’infrastructure qui doit être rapide pour répondre à la nouvelle fréquentation explosive de l’application et ne pas prendre le risque de voir le succès brisé sur sa lancée, faute d’ infrastructure permettant la montée en charge. Le succès étant difficile à prévoir sur ce genre d’application, il n’est pas envisageable d’acheter et de conserver à disposition un grand nombre de ressources matérielles en attendant l’hypothétique succès. Ca peut fonctionner, comme ça peut ne pas fonctionner : n’investissons pas… Mais soyons prêts ! C’est tout l’intérêt du Cloud Computing !

Il me paraît important de préciser que quand je parle de « ne pas investir », j’entends en termes de logistique. Faire l’économie d’un investissement sur la réflexion lors de la conception de l’infrastructure et, par la suite, lors de la mise en place des composants de base qui vont supporter l’application, reviendrait à ne pas être prêt, donc à un échec… ou bien à un surcoût dans le meilleur des cas !

Application sociale & conception
Une brève digression à ce niveau me paraît indispensable avant d’entamer le vif du sujet sur l’infrastructure. Il est indispensable de savoir qu’un code optimisé et réfléchi permettra d’économiser beaucoup d’argent et de complexité de l’infrastructure par la suite. Pas des choses compliquées, mais juste un minimum de réflexion :

• Quelles sont les informations que nous mettrons à disposition dans des caches et celles accédées en base ?

• Quelles sont les informations volatiles (en générale à destination du cache) ?

• Comment gérer mes connexions aux ressources pour les maintenir un temps minimal : gestion d’un pool de connexions afin d’optimiser les temps d’accès, respect de la cinématique connexion/récupération des données/fermeture de la connexion/traitement des informations récupérées afin de ne pas maintenir de connexions inutiles, groupage des requêtes, …

• Gérer un code modulaire afin de pouvoir le faire évoluer rapidement en fonction notamment des temps de réponse induits par telle ou telle fonctionnalité en fonction de la montée en charge,

• Séparation de l’IHM et du traitement, séparation des fonctionnalité de l’application et des APIs du réseau social, séparation des ressources et du code… On ne sait jamais ! Si ça fonctionne bien, il serait dommage de se priver d’un portage sur une autre réseau social parce que l’application est mal conçue au niveau découpage.

De part mon expérience, les principales optimisations, en termes de temps de réponse, que l’on peut constater sur une application à forte sollicitation sont réalisées au niveau du code de l’application ! Sur une application présentant des problèmes de conception, il apparaît au fur et à mesure de l’augmentation des capacités de l’infrastructure que le bénéfice retiré sera moindre. On peut rapprocher cela d’une courbe logarithmique : au début l’augmentation des capacités de l’infrastructure compensera les problème liés à la conception de l’application, mais arrivé à un certain seuil le bénéfice en termes de résistance à la charge sera faible par rapport aux investissements sur l’infrastructure.

Ce point est à méditer fortement…

Il était une fois…
RDV sur le site http://aws.amazon.com/ , préparez votre numéro de carte bleue, enregistrez-vous… Bravo ! Vous venez d’acquérir votre passe pour les nuages composé d’une « access key » et d’une « secret key ».

Le Cloud Computing AWS est composé comme son nom l’indique de… services web ! Pour y accéder, rien de plus simple : soit vous utiliser des APIs en ligne de commande, pratique pour l’automatisation des tâches à venir par la suite mais rebutant pour une première expérience, soit vous optez pour Elasticfox (Firefox Extension for Amazon EC2) proposant une IHM permettant d’accéder aux fonctionnalités des AWS et d’avoir un tableau de bord de vos instances, volumes, snapshots, groupes de sécurité, … Vous pouvez télécharger la « console élastique » sur http://developer.amazonwebservices.com/connect/entry.jspa?externalID=609 .

Une infrastructure à part entière
La premier piège à éviter est de considérer votre infrastructure comme une sandbox dans laquelle vous pouvez un peu tout tester et puis vous dire que vous pourrez revenir en arrière par la suite, un peu plus tard, si vos choix ne vous satisfont pas quand votre application commencera à fonctionner… Non ! Il s’agit d’une véritable infrastructure où vous devrez faire des choix, faire preuve de réflexion, anticiper,… Le Cloud Computing vous décharge de nombre de problèmes logistiques, vous permet d’être réactif, de disposer de ressources quasi illimitées, de réduire vos coûts, … Mais vous demandera la même réflexion que pour toute infrastructure.

La prise en main
La première étape de la mise en place d’une infrastructure sur AWS consiste en une prise en main. Une journée de prise en main fera l’affaire, c’est pas compliqué !

Documentation
Il est important dans un premier temps de consulter le site d’Amazon et de prendre connaissances des différentes briques/options à votre disposition, de lire la documentation en quelque sorte ! C’est rapide mais indispensable…

Tests
Vous pouvez ensuite effectuer des tests et vous mettre à l’aise en démarrant des instances EC2, en y attachant des volumes EBS, … Rassurez-vous ca ne coûte pas grand-chose !

RAZ
Vous êtes à l’aise ? Supprimez tout ce que vous avez fait et passez à la phase de conception. Supprimez tout ? Oui ! Premièrement, parce que dépenser de l’argent inutilement, même peu, en laissant des instances fonctionner, c’est pas terrible et surtout parce que l’étape de conception va vous amener à faire des choix fondateurs… Donc supprimez tout !

Réflexion macro…
La seconde étape est de décider :

• de leur répartition géographique,

• du niveau de disponibilité que vous souhaitez accorder à vos services en fonction de leur criticité.

Région et répartition géographique
Il faut tout d’abord sélectionner une région, à savoir « us-east-1 » pour les Etats-Unis (service web endpoint : « us-east-1.ec2.amazonaws.com » ou « ec2.amazonaws.com » – pour retro compatibilité) et « eu-west-1 » pour l’Europe (service web endpoint : « eu-west-1.ec2.amazonaws.com »). Il faut savoir que chaque région est totalement isolée. Il faut donc effectuer un choix en fonction de sa localisation ou plus exactement en fonction de la localisation des utilisateurs (humains ou systèmes) potentiels. Lors de la mise en place de notre application sociale, la région européenne était en beta, nous avons donc sélectionné la région « us-east-1 » pour notre environnement de production, même si la cible majeure de nos utilisateurs était européenne.

Zone d’accessibilité et disponibilité des services
Il faut ensuite choisir si il est nécessaire de mettre en place un système de résistance à la panne (fault tolerance) via les zones d’accessibilité à l’intérieur d’une région. Les zones d’accessibilités sont distinctes et isolées les unes des autres au niveau réseau. Il faut savoir que les ressources AWS n’ont pas la même portée : par exemple une instance EC2 et un volume EBS n’ont une portée que sur la zone d’accessibilité et doivent être dans la même bien évidemment pour être attachés. S3, en revanche, à une portée sur la région et permet d’échanger des données et de générer des EBS à partir de snapshots dans n’importe quelle zone d’accessibilité d’une région donnée. Un doublement du service dans 2 zones différentes doit être chapoté par une « Elastic IP » qu’il est possible de mapper à tel ou tel point d’entrée. Il est à noter qu’une « Elastic IP » peut être mappée sur 2 instances d’une même zone, bien sûr, afin de parer à la défaillance d’une instance (en point d’entrée) plutôt que d’une zone complète. Dans le cas de notre application, nous sommes restés dans une seule zone d’accessibilité, sans « Elastic IP ». La criticité d’une application sociale est moindre et la rupture de service acceptable (dans une certaine limite bien sûr). Nous avons en revanche mis en place une architecture solide dans la zone d’accessibilité sélectionnée.

Ci-dessous un schéma tiré du site d’Amazon représentant les régions et zones d’accessibilité.

AWS : Regions et Zones

Le tableau ci-dessous résume la portée (scope) des ressources pour Amazon EC2 (globale, régionale ou zone d’accessibilité) :

Ressource - Portée
Compte AWS - globale
Système d’identifiants EC2 (dont AMI ID, Instance ID, EBS Volume ID, EBS Snapshot ID, …) – régionale
Instances EC2 – zone d’accessibilité
AMIs – régionale
Groupe de sécurité – régionale
Clés SSH (Key Pairs) – régionale
Elastic IP – régionale
Volumes EBS – zone d’accessibilité
Snapshot EBS (stockage sur S3) – régionale

 …Et jeu de Légos !
Le choix des briques est fonction de l’application, dans notre cas nous avons utilisé les composants décrits ci-dessous.

EC2 : instances virtuelles
Il est à noter que les informations sur les instances ne sont pas sauvegardées et sont perdues en cas d’arrêt de l’instance, il ne doit donc pas y avoir de données applicatives stockées dessus ou bien elles doivent être backupées régulièrement. Les instance EC2 sont attachées à une zone d’accessibilité. Il est à noter qu’il est possible sur des instances EC2 de rencontrer des « hardware failures ». Cela nous est arrivé 3 fois sur un parc d’une trentaine d’instances EC2 en l’espace de 5 mois. D’où l’importance de ne pas stocker de données applicatives ou de les backuper, de prévoir une remontée rapide des instances (utilisation d’un gestionnaire de configuration centralisé type « Puppet », utilisation d’AMIs, …) et d’utiliser les composants mis à disposition par Amazon comme les volumes EBS ou bien S3 pour le stockage fiable de données critiques.

EBS : volumes de stockage haute performance pour EC2
Les EBS permettent de stocker les données de notre base de données afin d’offrir persistance (contrairement à EC2) et une bien meilleur gestion des i/o nécessaire pour les nombreuses lectures/écritures sur disque. Un EBS est attaché à une unique instance EC2, il est possible d’attacher X EBS à une instance EC2. Les volumes sont alors perçus au niveau des instances EC2 comme des « devices » qu’il est alors possible de formater et de monter. L’EBS peut être détaché et rattaché à une autre instance EC2 à chaud. Les volumes EBS sont attachés à une zone d’accessibilité, il est alors possible de les attacher à des instances EC2 appartenant à la même zone. Concernant la persistance, et plus exactement la durabilité, les données sur EBS sont répliquées sur différents serveurs dans une même zone d’accessibilité, ce qui permet de prévenir la perte de données. La perte est toujours possible, mais 10 fois moins qu’avec une gestion de disque dur classique selon Amazon. Il est à noter que du mirroring entre EBS dans une même zone d’accessibilité ne va pas servir à grand-chose en termes d’amélioration de la durabilité des données. Dans notre cas, nous avons créé des volumes de 20 Go pour stocker les données de nos bases MySQL, mais il est possible d’en créer de 1 Go à 1 To.

S3 : stockage persistant de données inter zones
S3 peut être utilisé afin de créer des snapshots d’EBS qui seront répliqués et accessibles entre plusieurs zones d’accessibilités, offrant une durabilité accrue et surtout la possibilité de recréer des volumes EBS à partir de ces snapshots sur différentes zones d’accessibilité, S3 ayant un scope inter zones dans une région donnée. S3 permet également de stocker des données et de les rendre disponibles ou non sur le Web via des ACL. Nous utilisons S3, dans notre cas, afin de faire des backups (donc ACL privée et uniquement accessibles par le(s) détenteur(s) de la clé de sécurité) des données des bases (MySQL), mais utilisons un dump standard que nous poussons ensuite sur S3 via un client (s3cmd). Nous préférons cela car ce fonctionnement nous permet d’effectuer si nécessaire un dump « à chaud » sans avoir à locker les tables (même si locker les tables est plus propre et effectué régulièrement lors de la maintenance nocturne) ou plus exactement à freezer l’EBS et préférons en cas de corruption (improbable) de la sauvegarde avoir à traiter avec un dump standard plus simple à « corriger ». Nous stockons également des logs importants et les configurations importantes de nos EC2. Il est à noter que dans le cas de dump, même sans lock, sur des sites très sollicités, cela n’est possible que sur les bases les plus légères et les moins sollicités. Les éléments les plus sollicités ne peuvent être backupés que durant un phase de fermeture du site. Nous utilisons également S3, avec une ACL publique cette fois-ci, afin de mettre à disposition de notre CDN les données statiques (images, bannières de publicité, …). Des clients graphiques simples (comme « Amazon S3 Firefox Organizer » (S3Fox), une extension Firefox sur le modèle de notre « console élastique ») permettent d’interagir avec S3 afin de rendre accessible les buckets (espace de stockage sur S3) aux responsables du contenu du site, par exemple.

Il est à noter que concernant les EC2 et les EBS qu’une limite de 20 instances de chaque par compte utilisateur est positionnée au départ. Ces limites peuvent être augmentées indépendamment l’une de l’autre à 40, puis à 100, … sur simple demande à un contact. La demande est prise en compte dans les 24 heures, prévoyez donc cela un peu à l’avance.

De plus, une offre de support est disponible en version « Silver » ou « Gold » afin de vous accompagner et répondre à vos questions. Vous pouvez consulter http://aws.amazon.com/premiumsupport/ pour plus d’informations.

AMIs
Il faut ensuite sélectionner l’AMI, le système virtuel à installer sur le matériel. Il est à noter qu’en fonction de la configuration matérielle choisie (m1.small, m1.large, m1.xlarge, c1.medium ou c1.xlarge), il y a une architecture sous-jacente (32 ou 64 bits). On ne peut donc pas poser n’importe quel système sur n’importe quelle architecture… Et les services AWS le gèrent bien ! Heureusement !

Il est également possible d’enregistrer vos propres AMIs que vous aurez configurées avec soin afin de les utiliser.

Nous avons opté pour une AMI « ubuntu-8.10-intrepid-base-64 » proposée dans la liste des AMIs disponibles.

Logiciels
Après avoir sélectionné le système, vient la sélection des logiciels. Cette section dépend complètement de l’application que vous allez mettre en place, cependant, sur des applications nécessitant de la scalabilité, on retrouve des axes majeurs et des problématiques récurrentes.

Tout d’abord un balancer Soft (HaProxy, …) distribuant les requêtes sur plusieurs frontaux Web (Apache, lighttpd, …) qui exécutent les traitements dans le cas de langages comme PHP (en CGI ou en mod) ou bien qui eux même redirigent les requête vers des serveurs applicatifs (Tomcat, Jetty, …) exécutants des traitements JAVA par exemple. Il serait possible de faire un post entier rien que sur les optimisations qu’il est possible d’apporter à ces niveaux, sur la gestion des processus et des threads, sur la gestion des piles de connexions, … Nous avons dans notre cas opté pour un HaProxy qui distribue les requêtes sur plusieurs Apache en « mod_php ».

Ensuite vient la base, avec le choix de la base en fonction des besoins (PostgreSQL, MySQL, …) : nous avons opté pour MySQL. A partir de là, les choix clés en termes de stockage : quel stockage ? InnoDB ou MyISAM ? Pour les tables essentiellement accédées en lecture ou nécessitant de la recherche « full text » : MyISAM ! Pour celles accédées en écriture : InnoDB (avec son système de row locking) ! Un mixte des 2 est possible en fonction des données (attention en revanche, les jointures inter stockages sont déconseillées) et pourquoi pas de la réplication sur les données vitales et fortement accédées avec un master InnoDB pour l’écriture et un slave MyISAM pour la lecture ? Non, il y a beaucoup trop d’accès et la réplication du master vers le slave ne sera pas encore effective pour la phase de lecture de certaines données, on optera pour 2 InnoDB avec un seul accédé en lecture/écriture, cela nous permettant lors d’un problème sur le master de le remplacer par le slave qui sera également performant en écriture (en MyISAM, les écritures saturent la base…). On limite les jointures pour bénéficier des avantages du système MySQL. Tout ça sans parler du paramétrage de chaque mode de stockage (InnoDBBufferPool, …) en fonction des opérations et de la volumétrie du site… Plus la volumétrie sera importante, plus le positionnement des index sera vital ! Nous avons également fait du sharding de données (découpage horizontal) via un modulo afin de répartir les données ne nécessitant pas de requêtes ensemblistes sur plusieurs serveurs et permettre de meilleurs temps de réponse et la possibilité d’une meilleure montée en charge.

Une couche de cache gérée par Memcached pour soulager les bases des données les plus souvent accédées…

Et voilà ! Un bref aperçu de la partie qui nous a probablement pris le plus de temps et qu’il est bien souvent nécessaire d’optimiser, une fois les grands axes retenus, au fil de la montée en charge de l’application.

Security Groups
Une fois les logiciels sélectionnés, il faut mettre en place les groupes de sécurité AWS. Ces groupes vont permettre de limiter les interactions des machines entre elles mais aussi de restreindre les accès de l’extérieur. Un groupe de sécurité se paramètre « tout simplement » comme un firewall avec le protocole utilisé (udp, tcp, icmp, …), le port ou la plage de ports (1 à 65535) ouverts pour les ayants-droits définis soit par un couple « identifiant de compte AWS :groupe », soit par une adresse IP d’un réseau ou d’un host. Cela s’effectue au niveau de la console « Elastic Fox », comme beaucoup de paramétrages.

Exemples :

• le groupe « Load-Balancer » octroiera pour tcp sur le port 80 (HTTP) les IPs du réseau extérieur 0.0.0.0/0 ,

• le groupe « Web » octroiera pour tcp sur le port 80 (HTTP) les machines de mon compte AWS appartenant au groupe « Load-Balancer »,

• le groupe « SQL » octroiera pour tcp sur le port 3306 (MySQL) les machines de mon compte AWS appartenant au groupe « Web »,

• …

• tous les groupes octroieront pour tcp sur le port 22 (SSH) l’ IP extérieure de l’administrateur de l’infrastructure AWS x.x.x.x/32 ,

• tous les groupes octroieront pour udp sur le port 161 (SNMP) les machines de mon compte AWS appartenant au groupe « Monitoring ».

Attention : une fois un EC2 démarré dans un groupe, il n’est pas possible d’en changer, c’est pour cela qu’il est important d’avoir défini les groupes au préalable. C’est de plus un très bon exercice de réflexion afin de concevoir l’infrastructure.

De plus, une même instance peut appartenir à plusieurs groupes, par exemple un EC2 hébergeant un MySQL et un Memcached appartiendra au groupe définissant les règles d’accès aux serveurs MySQL et à celui définissant les règles d’accès aux serveurs Memcached. Cela permet une structuration et une granularité/découpage des règles par fonctionnalités.

Les 2 dernières règles précédentes pourront donc s’écrire :

• toutes les machines appartiendront à un groupe supplémentaire qui octroiera pour tcp sur le port 22 (SSH) l’ IP extérieure de l’administrateur de l’infrastructure AWS x.x.x.x/32 ,

• toutes les machines appartiendront à un groupe supplémentaire qui octroiera pour udp sur le port 161 (SNMP) les machines de mon compte AWS appartenant au groupe « Monitoring ».

Comme précisé, cela permet de découper la sécurité par fonctionnalité.

Il est à noter également que les modifications des règles de sécurité d’un groupe donné sont instantanées.

Ressources et pricing
L’étape suivante est de définir les ressources dont nous aurons besoin pour l’application en termes de puissance et de stockage. Etablir une prévision de l’utilisation des ressources est indispensable afin d’avoir une vision claire des coûts sur le mois, les coûts horaires/trafic ne permettant pas cette vue d’ensemble. Il faut prendre en compte le coût fixe (facilement prédictible) des ressources et également les coût associés au trafic réseau en effectuant une prévision qu’il sera possible d’ajuster en fonction de l’évolution de la fréquentation sur le site. Au final, une bonne feuille Excel résumera pleinement la situation sur le mois et à l’année.

Concernant la puissance (RAM, CPU, …), il est en effet important de prendre ce dont nous avons besoin et de ne pas surestimer les besoins, en effet le prix de chaque configuration dépendant des ressources associées. De plus sur ce genre d’infrastructure, il faut réfléchir en termes de scalabilité et donc de distribuer la charge sur X machines plus réduite que sur une trop importante afin d’avoir la possibilité de lisser au mieux la charge.

Je n’aborderai pas ici le sujet de la conception d’applications « complètement » distribuées, sujet qui n’est pas trivial, loin de là. Il est très peu commun (comprendre rare ;o)) de voir des applications distribuées à tous les niveaux permettant par simple multiplication du service (et des éléments sous-jacents) d’augmenter les capacités de réponse, bien souvent la source de données est un goulet d’étranglement non distribué. La distribution est à mon avis la clé de ce genre d’application mais engendre bien souvent un coût de conception bien trop important. Disons le autrement : nous n’avons pas pris l’habitude de réfléchir naturellement dans ce sens et n’avons pas de modèles/standards évidents et donc le coût de réflexion associé augmente…

Tadaaa !
Il ne vous reste plus qu’à lancer les instances EC2 à partir de la console « Elastic Fox » en sélectionnant l’AMI retenue (la vôtre ou une « standard »), en lui attribuant une configuration (m1.small, m1.large, m1.xlarge, c1.medium ou c1.xlarge), une clé de sécurité, une zone d’accessibilité et finalement un ou plusieurs groupes de sécurité. Il reste à récupérer 15 secondes plus tard le nom DNS public de la machine et à vous y connecter via un client SSH. Il vous sera également possible de démarrer un volume EBS en précisant sa taille en Go, sa zone d’accessibilité et éventuellement le snapshot à partir duquel il va être généré. Reste ensuite à associer le volume à une instance EC2 en précisant le nom du device qu’il prendra (par exemple « /dev/sdd »). Et voilà, c’est parti !

Il est très important de noter que chaque machine possède un nom DNS privé qu’il est indispensable d’utiliser pour une communication entre les machines car le trafic interne entre les EC2 n’est pas facturé contrairement au trafic entrant via le nom DNS public ou bien une « Elastic IP » ! Une erreur de configuration pourrait avoir comme conséquence une hausse des coûts inutile.

Conclusion
La conception d’une infrastructure sur AWS demande autant de réflexion que n’importe quelle infrastructure pour la mener à bien. Il faut bien comprendre les spécificités des services Amazon et plus généralement sa conception pour les utiliser au mieux. Cependant, une fois appréhendés, les AWS permettent de monter une infrastructure modulaire et performante en un minimum de temps puisque sortie des considérations logistiques, dynamique et réactive de part les possibilités en termes de scalabilité et pour des coûts correspondant à vos réels besoins.

Il reste à noter qu’il faut également suivre l’évolution des services Amazon qui proposent au fur et à mesure de nouvelles fonctionnalités intéressantes (voir par exemple http://aws.amazon.com/contact-us/new-features-for-amazon-ec2/) qui suivent la cinématique standard de diffusion privée, diffusion publique en beta puis diffusion publique. Il est nécessaire de se tenir informé afin d’avoir toujours une vue exhaustive des composants à disposition et d’utiliser au mieux les briques mises en place en standard.

Il reste à présent la mise en place d’une telle infrastructure et il convient pour un service hébergé de la sorte de mettre en place un certains nombres de composants en place afin d’automatiser et d’homogénéiser l’infrastructure. Cela fera l’objet de mon prochain post.

Frédéric FAURE