Ce premier billet est le point de départ d’une série de 3 articles consacrés à un retour d’expérience sur la mise en œuvre d’une application sur la plateforme cloud-computing d’AMAZON (AWS - AMAZON Web Services).
Voici brièvement le contexte : nous sommes en janvier 2010, sur une étude qui doit traiter l’offre AMAZON selon les points suivants :
Les deux premiers articles combinent deux formes : source d’information et tutoriel, tandis que la dernière partie est une synthèse moins technique.
Dans ce premier billet, nous verrons le pourquoi du choix AMAZON puis après une rapide description des services proposés, nous détaillerons l’utilisation d’EC2 - la partie exécution.
La liste des compagnies qui offrent des services liés au cloud-computing est assez conséquente. Quelles plateformes sont les plus pertinentes ? Trois noms reviennent fréquemment : AMAZON, GOOGLE et MICROSOFT. Les autres acteurs, comme Salesforces.com, RightScale, GoGrid et bien d’autres, ont eux aussi des offres pertinentes. Il n’en reste pas moins que les « big three » sont incontournables, que ce soit par leur statut de précurseur du cloud-computing (cas d’AMAZON) ou bien leur position de leader sur le secteur informatique (cas de GOOGLE et MICROSOFT).
Le choix d’AMAZON répond aux critères de sélection définis au lancement de l’étude, à savoir : une plateforme qui impacte le plus faiblement possible la portabilité des applications, que ce soit pour porter une application interne sur le cloud ou bien rapatrier une application du cloud vers une infrastructure interne, tout en étant intéressante au niveau des coûts. Nous plaçons donc la portabilité et le coût comme critères clés.
Le critère du coût n’est pas déterminant puisque les trois offres semblent être alignées.
Il reste donc l'aspect portabilité pour différencier les trois prétendants. A ce stade, je vous invite à consulter l'article de Marc BOJOLY sur la segmentation des offres de cloud Computing. Outre la classification par types de contrats (IAAS, PAAS, SAAS), l'un des points importants relevé par Marc est que le choix d'une solution PAAS créera un lien entre le fournisseur et le client puisque les applicatifs devra utiliser une API propre au fournisseur. A contrario une solution IAAS préservera l'indépendance de l'application vis à vis du contexte d'exécution. Etant la seule offre IAAS, notre choix s'est porté sur AMAZON.
Néanmoins, il convient de modérer la « portabilité » d’AMAZON selon les services utilisés. En effet, la partie exécution d’AWS offre une grande indépendance vis à vis de la plateforme puisqu’elle basée sur des machines virtuelles gérées par l'utilisateur. Mais cela devient de moins en moins vrai au fur et à mesure que l’on intègre d’autres services AWS tels que la messagerie middleware (SQS) ou le stockage non-relationnel (SimpleDB), puisque même si ils reposent sur des standards (SOAP/REST), ces services nécessiteront des modifications de code lors d’un rapatriement depuis AWS. A contrario, les choix de GOOGLE avec notamment son système de base de données issus de sa R&D (BigTable) et les limitations de prises en charge de certaines librairies JAVA, offriront une plus grande rapidité de développement et une promesse de scalabilité plus importante en compensation d’une portabilité limitée. AMAZON propose donc une plateforme plus intéressante que celle de GOOGLE si l’on privilégie la portabilité.
Par souci de clarté, avant d’aller plus loin dans la description des services AMAZON que nous avons utilisés, en voici un bref récapitulatif. Pour plus de détails, vous pouvez consulter l’article de Marc BOJOLY.
Il s’agit de la brique de base de toute application s’exécutant sur AWS. EC2 permet à un utilisateur de lancer plusieurs instances EC2 en parallèle à partir de la même image. Le Service Level Agreement est de 99,95 % soit un peu plus de 4 heures 20 minutes de pannes par an.
Le service EC2 est indissociable de la notion d’Amazon Machine Image – AMI. L’AMI est en effet l’image d’une machine virtuelle qui va être exécutée. Puisqu’EC2 repose sur une virtualisation XEN, il est assez aisé de déplacer des serveurs XEN vers EC2.
Pour utiliser EC2, un utilisateur lambda doit suivre les étapes suivantes :
Nous en reparlerons dans les billets suivants mais l’API EC2 peut être appelée de différentes manières :
Les AMI sont des images de machines virtuelles. Elles peuvent être publiques (visibles par tout utilisateur AWS) ou privées (visibles par un seul utilisateur AWS), gratuites ou payantes.
De plus, une distinction est faite entre les AMI qui sont stockées sur un instantané de volume EBS (EBS backed AMI) et celles stockées directement dans S3 (instance store).
Voici un comparatif des deux types d'AMI :
| Caractéristique | EBS backed AMI | Instance Store |
| Temps de démarrage | Moins d’une minute | Moins de 5 minutes |
| Taille limite | 1 To | 10 Go |
| Emplacement | Volume EBS | S3 |
| Persistance des données | Les données persistent en cas d’arrêt imprévu et peuvent persister après un arrêt de l’instance EC2 | Les données persistent aussi longtemps que l’instance EC2 est en exécution. Il est possible de monter des volumes EBS en supplément |
| Mise à jour | Le type d’instance, la RAM et les données utilisateur peuvent être changé lorsque l’instance est arrêtée | Les attributs de l’instance EC2 sont figés tant que l’instance est lancée |
| Tarification | Selon l’utilisation de l’instance EC2 et du volume EBS. En outre, le stockage de l’AMI sur l’instantané EBS est payant | Selon l’utilisation de l’instance EC2 plus le stockage de l’AMI sur S3. |
| Création de l’AMI | Appel à une seule commande | Requiert l’installation d’outils spécifiques (AMI tools) |
| Arrêt | Peut être placée dans un état d’arrêt (équivalent d'un état de pause) où l’instance EC2 n’est pas en exécution mais peut être relancée. | L’instance est en exécution ou non. Une fois terminée, l'instance ne peut pas être récupérée. |
Dans notre cas, nous avons opté pour des AMI ‘instance store’ pour deux raisons :
Il existe des centaines d’AMI avec une large variété d’OS (Windows, Linux, Solaris).
Voici comment créer une AMI instance store contenant à partir d’une AMI Ubuntu.
Ssh –i key.pem ubuntu @ec2-79-125-39-141.eu-west-1.compute.amazonaws.com
ec2-bundle-vol -k pk-XXXXXXXX.pem -c cert-XXXXXX.pem -u votre_uid_sans_tiret –r i386
ec2-upload-bundle -b bucket_de_destination -m image.manifest.xml -a votre_access_key_id -s votre_cle_secrete
ec2-register bucket_de_destination /image.manifest.xml -n votre_nom_d_image, qui retourne l’ami-id de la nouvelle AMI.
Pour ceux qui sont allergiques aux lignes de commande, voici un tutoriel qui explique comment lancer une instance EC2 et s’y connecter avec AWS Management Console.
Il est aussi possible de convertir des images au format AMI vers ou depuis des images VMWare.