Dernier article de la série consacrée aux services web AMAZON, celui-ci se veut avant tout un retour d'expérience.

Alors AWS ?

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.

Facilité de mise en œuvre

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 :

• Stockage : Transfert de fichiers médias depuis le poste client
• Serveur Web : Navigation au sein d’une bibliothèque de fichiers médias
• Conversion : Conversion de fichiers médias dans différents bitrates
• Streaming : Lecture de fichiers médias

Pour répondre à ces besoins, nous avons utilisé les services AMAZON suivants :

• Elastic Compute Cloud (EC2) pour la conversion et la logique de navigation.
  • CloudWatch qui permet de monitorer une application
  • Auto Scaling pour permettre l’allocation dynamique de nouvelles machines virtuelles
  • Simple Queue Service (SQS) : le service de messagerie middleware de type MOM pour la communication entre machines virtuelles
  • Simple Storage service (S3) : stockage de type clé/valeur pour l’accès en streaming aux fichiers média
  • Relational Database Service (RDS) : stockage de type SGBDR basé sur MySQL pour la gestion des utilisateurs et des arborescences de fichiers

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 :

• La compréhension des différents concepts et possibilités des AWS nécessitent un ticket d’entrée non négligeable. Maitriser la terminologie, les cas d’utilisations, les possibilités de chaque service … demande du temps. Ce point est à moduler en fonction du background technique plus ou moins important de l’architecte. Les néophytes en infrastructure y seront d’autant plus sensibles.
• Les ressources liées aux AWS sont nombreuses, qu’il s’agisse de la documentation officielle, claire et complète, des différents projets open source ou encore de la communauté d’utilisateurs. Vous n’êtes pas seul et las AWS ne sont pas des boites noires.
• Enfin, cela peut paraitre évident mais ce ne l'est pas toujours : les services AWS fonctionnent tels qu’annoncés. Nous n’avons pas eu de surprise, que ce soit des bugs ou des comportements étranges.

Coûts

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.

• Il n’y a pas de surcoût lors de l’interaction de services AWS au sein d’une même région. Par exemple, l’accès à un bucket S3 situé en Irlande depuis une instance EC2 exécutant elle aussi en Irlande, ne génèrera pas de frais liés au transfert de données.
• Entre des instances EC2 situées dans différentes zones de disponibilités mais dans la même région, le transfert de données sera facturé à un prix dit Regional Data Transfer.
• Le transfert de données entre des services AWS basés dans différentes régions est facturé au prix dit Internet Data Transfer pour chaque coté du transfert (entrée et sortie).

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 :

  • Reserved Instances - l’utilisateur réserve une instance pour une ou trois années (230$ pour un an ou 350$ pour trois ans dans le cas d’une instance d’entrée de gamme), et bénéficie ainsi de prix horaires réduits (environ 50% de moins).
  • Spot instances - en fonction de la charge du data center, AMAZON établit toutes les 30 minutes un Spot price. Dans ce système d’enchères, l’utilisateur définit un prix maximum, une région, une configuration matérielle et un nombre d’instances. Si le Spot price correspond à l’offre faite par l’utilisateur, celui-ci se voit attribuer les instances demandées.

• 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 :

  • Regional Data Transfer : 0.01$/Go/mois pour le trafic entrant et sortant
  • Internet Data Transfer gratuit jusqu’au 1 novembre 2010, les données entrantes seront facturées 0.10$ /Go/mois. Pour les données sortantes, le premier Go par mois est gratuit, ensuite il vous en coutera 0.15$/Go/mois pour les 10 premiers To où un tarif dégressif s’applique jusqu’à atteindre 0.08$/Go/mois si vous utilisez plus de 150 To/mois

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.

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.

Donc

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