Dernier article de la série consacrée aux services web AMAZON, celui-ci se veut avant tout un retour d'expérience.
Pour rappel dans l’étude menée, nous devions étudier l’offre d’AMAZON sur trois axes : facilité de mise en œuvre, coûts et montée en charge.
L’application que nous avons déployée repose sur un certain nombre de services AWS. Sans rentrer dans les détails, l’application de test assurait les fonctions suivantes :
Pour répondre à ces besoins, nous avons utilisé les services AMAZON suivants :
De nombreux services AWS (CloudFront, SimpleDB, VirtualPrivateCloud …) n’ont pas été mis en oeuvre. Néanmoins, nous pouvons tirer les conclusions suivantes pour ceux utilisés :
Le calcul des coûts par anticipation est quelque chose d’assez complexe, c’est sans doute pourquoi AMAZON propose d’utiliser un outil pour vous aider. La tarification se fait par service mais pour la plupart des services, la bande passante utilisée intervient dans le calcul du prix. Qui plus est, ces données qui traversent les firewalls des data centers d’AMAZON ont des tarifs dégressifs en fonction de leur volumes !
Attardons nous sur cette notion de données entrantes et sortantes des data centers.
Sans rentrer dans la tarification détaillée des AWS, voici quelques indications
La région d’utilisation a un impact sur la plupart des coûts des services.
Pour les services associées à des instances (EC2, RDS), chaque heure débutée est intégralement facturée, que l’instance soit sollicitée ou non.
Pour les prix des instances EC2, il est important de signaler qu’une distinction est faîte entre les OS Linux et Windows. La différence de prix peut selon la configuration s’élever jusqu’à 40 % de plus pour une instance Windows. Ensuite, comme indiqué lors du premier article, le configuration matérielle bas de gamme est 25 fois moins chère que la plus chère (de 0.10$/heure contre 2.88$/heure). Enfin, AMAZON propose diverses offres pour réduire le coût horaire :
CloudWatch ajoute environ 0.015$/heure/instance
Le coût d’une instance RDS va de 0.12$/heure à 3.10$/heure en fonction de la configuration matérielle. L’espace de stockage est facturé 0.10 $/Go/mois et l'espace supplémentaire pour les backups vaut 0.15 $/Go/mois. 0.10$ donne droit à 1 million de requête SQL. L’activation de la réplication entre zones de disponibilités double les prix précédents sauf pour le stokcage des backups et la facturation par requêtes
S3 de 0.15$ à 0.055$/Go/mois en fonction du volume de stockage. La facturation par requête est découpée en deux catégories : les requêtes PUT, COPY, LIST facturées 0.01$ pour 1000 et les autres requêtes dont GET facturées 0.01$ pour 10 000
Les coûts de transfert des données sont communs aux différents AWS :
Cette complexité tarifaire impose d’avoir une grande connaissance de l’application qui va être déployée. Cela peut ne pas poser de trop gros problèmes dans le cas d’une application existante, déjà en exécution au sein d’un SI interne puisque l’obtention de métrique pourra se faire par une instrumentation sommaire si elle n’est pas déjà faite. En revanche, dans le cas d’une conception "from scratch" cela peut être moins aisé. En outre, on notera que la tarification peut impacter les choix d’architecture : comment grouper les services au sein d’une même région pour les limiter les coûts tout en ayant un déploiement sur plusieurs sites ? Quelle granularité pour les messages SQS sachant que la facturation est faite par requête ? …
Pour conclure cette partie, comme souligné dans l’article suivant, il est clair que comparée à une solution d’hébergement classique, une offre d’IaaS comme celle d'AMAZON n’est pas avantageuse si l’on souhaite exécuter des instances en permanence. La vraie force de l’IaaS, c’est l’élasticité, le dimensionnement automatique pour suivre la montée en charge.
Ce point était l’un des plus important pour notre étude. Le service AutoScaling fourni par AMAZON fonctionne correctement : lorsque les critères sont atteints la taille d’un groupe de machines.
Néanmoins, il est important de souligner que la période selon laquelle un groupe d’instances EC2 est dimensionné, doit être déterminée avec attention, au risque de lancer de multiples instances et donc de voir les coûts s’envoler. Supposons qu’un site web ait une courbe d’utilisation qui associée à certains paramètres d’AutoScaling (typiquement la période de dimensionnement d’une heure) produise le diagramme de vie des instances EC2 suivant :
Ainsi, nous aurons consommé : 12 heures pour l’instance 1, 6 heures pour l’instance 2, 4 heures pour l’instance 3 et 2 heures pour les instances 4, 5 et 6. Soit un total de 28 heures machines.
Supposons maintenant que l’échelle de temps du graphique précédent ne soit pas l’heure, mais la minute. Nous avons alors 6 heures machines à payer – car chaque heure consommée est pleinement facturée – pour seulement 12 minutes de fonctionnement. Notons au passage que 4 instances auraient suffi. Cet exemple s'applique sur quelques minutes et quelques machines, imaginons maintenant que cela concerne des dizaines de machines pendant une année...
Dans une première approche, on souhaite disposer d’un système très réactif et donc d’une période de dimensionnement très courte - de l’ordre de quelques minutes. Or ce choix peut s’avérer ruineux.
Tout d’abord, et c’est positif, AMAZON WS existe depuis un certain temps et fonctionne bien : aucun plantage ou message d’erreur, une documentation claire et une communauté importante font qu’il est assez agréable de travailler sur l’infrastructure AMAZON. Par ailleurs la portabilité est là : envie de rapatrier l ‘application chez vous ? C’est faisable.
Par ailleurs, le coté ‘infra’ plus que ‘appli’ peut avoir son importance dans le choix du fournisseur car contrairement à GOOGLE qui annonce : « ne vous inquiétez pas, nous gérons votre appli », AMAZON donne les outils pour gérer et maitriser son soft : nous savons où sont les machines, les données, nous avons la possibilité de rester maître de notre soft. Le revers de la médaille est la quantité de facteurs à gérer.
Le premier de ces facteurs est la réactivité de l’élasticité. Cette élasticité est la raison d’être du cloud computing IaaS, sinon autant aller chez un hébergeur. Voulez-vous dimensionner votre infrastructure toutes les 10 minutes, toutes les heures ou bien tous les jours ? La réponse à cette question passe par une maîtrise avancée de l’application à déployer.
Par ailleurs, et c’est aussi vrai pour Microsoft et GOOGLE, les différents éléments à prendre en compte pour une estimation budgétaire et plus spécifiquement les volumes de données entrants et sortants des data centers AMAZON, nécessitent une maitrise de la volumétrie de son application. L’idéal étant une application existante qu’il ne reste plus qu'à outiller. En outre, l’aspect financier (volumétrie, nombre de requêtes …) peut impacter l’architecture de l’application.
AMAZON est la solution si il s’agit de faire une externalisation d’infra privée vers le Cloud – normal puisqu’il n’y a presque rien à faire ! Pour du développement from scratch, AMAZON se prête mieux à du web-service, du batch ou du site web statique là ou on peut supposer que GOOGLE et MICROSOFT sont meilleurs pour des applis web, mais attention dans ce cas aux problèmes de portabilité. Rien ne vous empêche de déployer une archive WAR sur un TOMCAT au sein d’une instance EC2 mais le niveau d’abstraction offert par les solutions GOOGLE et MICROSOFT permet de faciliter grandement le déploiement, vous avez beaucoup moins de questions à vous poser. Par ailleurs, il est tout à fait possible d’intégrer AMAZON avec une autre solution.
Pour terminer, il faut garder à l’esprit que les choses évoluent très vite dans le monde du Cloud Computing. Ainsi, GOOGLE supporte maintenant le SQL pour les App Engine Business alors que le principal point négatif de GAE était son système de Base de Données non SQL.
De même l’offre AMAZON a encore évolué entre la fin du projet présenté ici (mars 2010) et la rédaction du présent document (Juin 2010) : le service de load balancing gère les sessions http (sticky-sessions) tandis que cloud front supporte le protocole HTTPS