Decrypt

Voilà un webcast qui a pour objectif de vous aider à comprendre l’offre d’Amazon avec ses AWS (Amazon Web Services) et d’en avoir une vision globale. Les AWS proposent un gamme de services riches en fonctionalités, autant au niveau de l’infrastructure (EC2, S3, MapReduce, SimpleDB, SQS, CloudFront) qu’au niveau de besoins sortant de ce scope et plus spécifiques pour certains métiers (FPS, DevPay, Mechanical Turk, AWIS, Alexa Top Sites, FWS), comme la vente en ligne par exemple.

Le Cloud Computing vu par Amazon est promis à un bel avenir. Il s’inscrit en effet dans la démarche en vogue de restructuration des infrastructures et de réduction des coûts. Il rejoint de plus le modèle économique SaaS par ce que l’on pourrait appeler le modèle HaaS (Hardware as a Service). Ce modèle économique s’inscrit dans l’évolution naturelle des architectures vers les SOA (Services Oriented Architecture) et répond aux besoins des consommateurs.

Version IPhone
Version IPod

Quelques précisions concernant des questions qui m’ont été posées :

Le SLA
Chaque service a son propre SLA qu’il faut bien lire, par exemple pour EC2 le SLA est de 99,95% par région sur une année glissante. Ce que Amazon entend par service inaccessible est que vos instances n’ont plus d’accès externe pendant une période de 5 min et que vous êtes incapables d’en relancer. Cela doit se produire sur plus d’une zone d’accessibilté (donc au moins 2) dans laquelle vous avez des instances. Cela veut donc dire que Amazon part déjà du principe que vous avez redondé votre infrastructure sur 2 zones afin de faire de la haute disponibilité.
Il faut donc bien lire et comprendre les termes du SLA par rapport à l’infrastructure Amazon.
Dans la pratique, je travaille sur une infrastructure non redondée exclusivement sur une zone d’accessibilité et sur 8 mois d’utilisation, je n’ai rencontré un problème d’accessibilité de quelques minutes qu’une seule fois. Je n’ai rien à redire sur le service.

La durabilité d’EBS, EBS/S3 et la fiabilité en général
La durabilité des EBS est assurée par réplication réseau dans une zone d’accessibilité donnée (cela ne sert donc à rien de monter plusieurs EBS dans une zone donnée et de dupliquer les données ;ob Amazon le fait déjà !). Selon Amazon, cela donne une fiabilité de 10 fois supérieure à celle d’un disque standard dans un data center. Il est vrai que je n’ai pas rencontré de problème sur 8 mois d’utilisation avec un parc d’environ 25 EBS.

Par rapport à S3, la différence est que S3 accroit la durabilité, donc faire un backup de vos EBS par snapshot ou bien en effectuant un dump des données est une très bonne pratique de backup. Aucun problème rencontré avec S3 à ce jour pour ma part. Deux différences entre EBS et S3 : la portée, régionale pour S3 et dans la zone d’accessibilité pour l’EBS, et la capacité en I/O optimisée pour l’EBS. Chaque outil de stockage a son rôle !

Sur une quarantaine d’EC2, j’ai perdu 3 instances en 8 mois. Mais comme aucune donnée sensible n’est stockée dessus et que l’infrastructure est automatisée (Cf. Puppet et Capistrano : la clé de l’automatisation), l’intégration d’une nouvelle instance, entre la survenue du problème, la détection, la réparation et la reconfiguration des outils de monitoring/backup, n’a pas excédé une heure. La remise en ligne, elle-même, d’une nouvelle instance (réparation) n’a pris que 10 min !

Pour plus d’info, n’hésitez pas à consulter les article précédents sur le sujet et notamment Conception d’une infrastructure sur AWS : best practices !.

MapReduce… QUID ?
Qu’est ce donc ? Je compare ça à un ETL puisque le but de la manipulation est de partir d’une source de données, un fichier de logs par exemple, d’extraire les éléments que nous souhaitons traiter (fonction de mapping) et de les transformer (fonction de réduction) avant de les remettre à diposition sous forme d’un fichier et de les charger sur S3. Ce qu’il faut, c’est écrire ces fonctions de map et de reduce à appliquer sur vos fichiers pour obtenir ce que vous voulez en sortie (des statistiques par exemple). Pour plus d’infos, MapReduce

Comment calculer l’utilisation de son application avec DevPay ?
C’est Amazon qui s’occupe de calculer l’utilisation, vous avez juste à définir le coût fixe (one-shot ou mensuel) et le coût variable lié à l’utilisation (trafic, …). Et bien sûr mettre à disposition votre application ou votre AMI ! ;ob

Mechanical Turk, comment ça marche ?
Pour ça je vous invite à regarder le site d’Amazon, rubrique Mechanical Turk, qui explique très bien le concept. Mais dans les grandes lignes des personnes souhaitant effectuer ces tâches (tagging d’images, reconnaissance video, transcription de podcast, traduction, enquêtes d’opinion, dédoublonage catalogue produits online, …) se connectent sur le site d’Amazon, sélectionnent et effectuent les tâches que vous avez proposées via l’API web service d’Amazon intégrée dans votre application. L’intégration de la réponse peut être automatique, ou soumise à validation. La validation peut être effectuée sur plusieurs résultats identiques pour une même tâche distribuée à plusieurs personnes et le paiement découle de votre acceptation ou non du travail résultant en fonction de sa qualité. La personne ayant effectué le travail voit donc ses statistiques d’acceptation de travail évoluer et donc obtient un indicateur de compétences.

Frédéric FAURE