(suite de l’article sur Amazon Web Service)
La dernière heure de la présentation de Chris Richardson est consacrée à une revue des principaux service d’AWS, en présentant une application de stockage de photo à la FlickR. Une application Web Java sera déployée sur un serveur Tomcat sur une instance Amazon EC2. Le stockage des photos s’effectue sur Amazon S3, un espace de stockage que l’on peut consulter avec une URL. Des vignettes sont générées par un serveur de traitement des photos qui utilise Amazon SQS (Simple Queue System) pour échanger des messages asynchrones avec notre application web. La base de données de l’exemple sera Amazon Simple DB, qui n’est pas une base relationnelle. Il a consacré la dernière heure à passer en revue chacune des technologies, c’était vraiment intéressant.
Un peu de théorie
Je vais vous donner quelques éléments de théorie. Cela vous permettra de briller en société, et votre ArchitecteEnChef aura le bec cloué. Tout d’abord parlons du théorème énnonépar le Dr Eric Brewer de Berkley : the CAP Theorme où CAP signifie Consistency, Availability et Partition tolerance.
Il est établi qu’une application web ne peut pas à un instant donner réunir et couvrir les 3 points suivants :
– Consistency : une donnée écrite dans le système peut être lue par l’ensemble des lecteurs. Une base relationnelle basée sur les principes ACID est l’exemple absolu de la consistance des informations.
– Availability : le système reste disponible même lorsqu’une opération est en cours
– Partition tolerance: le système fonctionne complètement malgré l’arrêt d’une partie du système
Amazon couvre le A et le P du théorème : la donnée lue est garantie comme étant correcte et complète, et le système peut fonctionner et retourner vos données même si une partie est en panne. C’est donc la consistance de la donnée qui est sacrifiée.
En clair voici comment cet effet sera observé sur Amazon S3 par exemple. D’un côté, vous déposez dans un espace une image. De l’autre, avec votre navigateur, vous chargez l’URL de l’image. Et bien il y aura certainement un décalage, l’image ne sera pas trouvée tout de suite de l’autre côté. En effet, Amazon va d’abord répliquer votre donnée, et va aussi s’assurer de son intégrité. Lors de l’envoi vers Amazon S3 d’une ressource, il est maintenant possible d’attacher un checksum MD5 dans le header HTTP d’un simple PUT utilisé lors de l’envoi de l’image. Cela permet à Amazon de vérifier que la donnée n’a pas été endommagée lors du transport. Chris affiche un slide explicite : « A GET might not set a POST ».
Concernant SQS, proche de JMS dans l’idée, un message posté ne va pas apparaître immédiatement du côté de la queue de lecture. Pour relativiser cela, il faut penser que dans bien des cas, ce n’est pas grave.
Concernant notre application d’album photo, lors de l’envoi vers Amazon S3 il sera donc normal de ne pas voir apparaître tout de suite les photos.
Il explique en fait que le système ne peut pas proposer de transaction ACID mais il parle plutôt de BASE : Basically Available Soft-state Eventual consistency.
Amazon S3
Amazon S3 est la solution de stockage de la plateforme Amazon Web Services. Vous pouvez y mettre vos images, vos données statiques, les données sont stockées très simplement. L’intérêt de S3 c’est la haute disponibilité de vos données. Les chances de crashes et de perdre de la donnée sont presque nulles. Pour utiliser S3, il faut créer un Bucket, dans lequel sera rangé sous la forme de clé/valeur les données. Les données peuvent aller de quelques bytes à 5Go maximum. Un bucket est un nom unique qui permet ensuite de créer une url de la forme http://
Les données sont ensuite stockées comme sur un système de fichier virtuel. Par exemple http://letouilleurbucket.s3.amazonaws.com/logo.png.
La création des Buckets en Java est facile grâce à l’API JetS3t qui permet de manipuler facilement Amazon S3 directement à partir de votre code Java. Pour Grails il existe aussi un plugin. L’accès au bucket peut aussi être protégé afin d’en restreindre l’accès. Une API avec des ACLs permet de contrôler les droits de lecture et d’écriture sur les objets du Bucket.
La facturation est calculée sur la base du volume stocké, que multiplie la quantité transféré. Un GET est par exemple 10 fois moins cher qu’un PUT ou un POST. L’opération DELETE est gratuite. Il existe aux USA une solution d’import où vous envoyez votre disque dur par FedEx, Amazon le charge dans un espace S3 et vous le retourne par transporteur. Cela permet de remplir son espace S3 très rapidement, sans payer des coûts prohibitifs.
CloudFront
CloudFront est un cache de données qui se géolocalise selon la demande des visiteurs. Lorsque les données sont stockées sur un serveur en Europe sur S3, les utilisateurs aux USA seront pénalisés par rapport aux performances. Pour répondre à cela, Amazon propose CloudFront. C’est un vrai « Content Delivery Network » capable d’agir de manière transparente, comme un proxy du côté de l’infrastructure d’Amazon. Si par exemple votre planche de Surf Jaune fait un tabac aux USA, l’image sera copiée vers un serveur S3 aux USA de manière transparente. Et l’image sera servie via cet emplacement pour l’Amérique du Nord, pendant 24h. Cela permet d’améliorer les performances de manière transparente. Ce service additionnel est aussi à régler à l’heure selon l’usage.
SimpleDB
SimpleDB est une base non relationnelle sans schéma. En bref : SGBDR tu peux mourir. L’intérêt ? La performance et la montée en charge mon bon monsieur. Voici comment s’organise SimpleDB. Tout d’abord les « Domains » limités à 100 par instance de SimpleDB, représentent vos tables. Un Domain a un nom et contient des Items. Des Items ont un nom et des Attributes. Enfin les Attributes ont un nom et une ou plusieurs valeurs. Il n’y a pas de jointure, pas de transaction, et pas de locking possible… Forcément là vous avez un peu peur.
Vous pouvez utiliser la syntaxe SQL de base, les données stockées dans SimpleDB sont automatiquement indexées.
Mais comment faire une jointure alors ? Les relations de 1 à N par exemple seront représentés par ce que Chris appelle des tables dénormalisées. Il suffit de stocker la même donnée plusieurs fois dans différents Domaines. Le contrôle de l’intégrité sera effectué par l’application. Comment faire des requêtes du type : « Toutes les photos avec Ville=PARIS » ? Il suffit de créer des tables PhotosPriseAParis et d’y stocker toutes les photos prises à Paris. En fait, là où nos réflexes SQL nous permettaient de faire tout et n’importe quoi, ici il faut prévoir les types de requêtes que l’interface pourra envoyer, créer des structures de stockage et y ranger vos données.
J’avoue que j’ai du mal à me voir créer autant de tables que par exemple des critères de tris dans un tableau… Mais c’est ce que fait tout les jours un site comme eBay pour vous montrer la liste des articles par exemple. L’idée du Cloud Computing est de dire que c’est au moment de la création d’une entité qu’il faut mettre à jour le système, et qu’il n’y a plus la magie de la base relationnelle.
Bon cette partie mérite un article à elle toute seule, je vous mets cela sur la commande pour la prochaine fois.
Amazon Simple Queue Service
Pour ajouter de l’asynchronisme à une architecture, Amazon propose SQS. Similaire quoique plus simple que JMS, ce système permet d’envoyer et de recevoir des messages entre machines dans votre propre réseau Amazon. Les messages sont limités en taille à 8kb et sont effacés après 4 jours s’ils ne sont pas lus. Si vous voulez envoyer une grosse photo… vous ne pouvez pas. Il faut la stocker sur S3, envoyer l’URL dans un message, la récupérer dans votre service de découpage des photos avant de réécrire dans un autre endroit sur S3 le fichier découpé par exemple.
Chris montre l’API de SQS, qui me parait plus simple que JMS. La redondance est le point fort de la solution, il est possible de lire plusieurs fois un message sur une Queue (principe du Topic). Il n’y a pas de garantie sur l’ordre d’arrivée des messages (principe CAP vu plus haut).
La GROSSE conclusion
Cette présentation de 3 heures est passée relativement vite. Pour moi, c’est clair, mon projet de Startup sera sur Amazon ou ne sera pas. Je n’imagine pas prétendre arriver à la cheville de ce qu’Amazon propose aujourd’hui. J’ai aussi bien aimé la présentation rapide de CloudFoundry. Ce service permet de créer rapidement son réseau avec quelques machines, et de travailler sans perdre une semaine pour la configuration.
Dans les idées discutées par Chris, l’une d’elle m’a complètement séduit : la gestion des nouvelles versions. Imaginons que votre site de vente de skis hébergé sur 5 machine fonctionne très bien, mais que vous souhaitez maintenant passer à 10 machines. Grâce à la souplesse du principe de l’IaaS, vous allez mettre en place 10 nouvelles machines, tester avec les adresses IP votre application, puis faire la bascule sans même éteindre les 5 anciens serveurs. Si au bout de quelques jours tout fonctionne, vous pourrez alors arrêter et effacer les 5 anciennes machines. Chaque montée de version peut donc s’effectuer sur une nouvelle machine toute neuve ! Les données statiques sont stockées sur S3, la base sur SimpleDB ou avec l’offre MySQL d’Amazon, bref à part la partie Web et votre serveur d’application, j’ai oublié quelque chose ?
Très bonne présentation, je testerai Amazon EC2 rapidement et je vous en reparlerai.
La vrai révolution d’Amazon AWS est qu’il rend soft des ressources qui hier étaient hard. Je peux programmer mon infrastructure! Plutôt que de remplir le formulaire XB12-107 et d’attendre 3 mois que la prod m’authorize à leur livrer un war qu’ils vont déployer pour moi!
l’IaaS c’est la fin de la prod et le pouvoir aux développeurs. Je vous laisse mesurer l’ampleur de la révolution.
Je me permet de glisser un lien vers un de mes billets, ça fait un bon complément:
http://blogpro.toutantic.net/2009/11/17/le-rythme-des-innovations-damazon-aws/
Merci pour ce compte rendu vraiment intéressant, qui je suppose rend bien la qualité de la présentation… Très complet ! Ca donne envie tout ça.
Je viens de réaliser que s3.amazonaws.com est bloqué par le firewall de mon client… Gniééé, aucun risque qu’on teste s3 au boulot ! (et, accessoirement, impossible de télécharger les produits SpringSource, dispos sur S3).
Oui mais il suffira d’un sécateur :
http://libertesinternets.wordpress.com/2009/04/26/il-suffit-dun-secateur-%20pour-paralyser-une-ville-de-50-000-habitants/
pour ruiner les espoirs des xaaS …
donc parler de niveaux DICT ou de QoS pour les xaaS sans prendre en compte cette externalité, c’est quand même du flan.