Chaos chez Amazon EC2 – plus jamais ça!

Cet article a été publié initialement sur mon ancien blog, qui était hébergé par blogspot.com.

Le 21 avril 2011 le service EC2 (Elastic Compute Cloud) d'Amazon a subi une panne qui a duré près de 3 jours. Certains clients ont même perdu une partie de leurs données [1]. Selon Amazon [2] seul 0.07% du volume des données hébergées dans la zone impactée par la panne ont été définitivement perdues. Ce chiffre ne signifie que peu de choses, car nous ne saurons jamais combien de clients ont réellement perdu des données. Nous pouvons aussi nous poser la question, est-ce que ces clients avaient respecté les règles qu'Amazon impose pour que son SLA (service level agreement) soit applicable?

J'ai écrit un article sur la solution d'Amazon en janvier 2010. Dans cet article je parlais de leur SLA. Il est très contraignant et ne dédommage que difficilement les clients en cas de panne.

"Le client peut demander des dédommagements pour autant que l'ensemble de ses instances aient été indisponibles pour plus de 5 minutes et qu'il n'ait pas pu créer de nouvelles instances. Amazon recommande de travailler au moins sur deux zones."

Si les clients qui ont perdu des données et tous les autres impactés par la panne d'Amazon le 21 avril ont respecté la recommandation du SLA: "travailler au moins sur deux zones", nous pouvons nous poser une seconde question: quel aurait été l'impact d'une telle panne, s'ils avaient hébergé leurs données dans leur propre data centre ou chez un hoster (hébergeur) "traditionnel"? L'impact économique et technique aurait sûrement été plus grand, mais il aurait touché moins de clients!

Pour éviter de reproduire ce problème lors d'une prochaine panne, Amazon décrit les mesures qu'ils vont prendre dans un communiqué [2]. De nombreux articles sur le web [3, 4, 5] donnent aussi des recommandations afin de réduire les risques liés à une panne du même type que celle qu'Amazon vient de connaître. Pour moi ces recommandations sont des recommandations de bon sens et doivent être appliquées à tout projet qu'il soit critique ou pas. Ces conseils sont aussi valables pour tout projet hébergé chez d'autres prestataires de service de type Cloud ou des prestataires que nous pourrions appeler "traditionnels".

Dans ces recommandations, le premier point consiste à multiplier les instances de son système d'information. Contrairement à ce qu'Amazon recommandait "travailler au moins sur deux zones", il faut travailler sur au moins 2 régions. Pour Amazon une "région" (Region) est un déploiement de son infrastructure, totalement indépendant des autres "régions". Une zone de disponibilité (Availability Zones) est un sous ensemble d'une région. Les zones de disponibilité permettent de facilement créer un système redondant, car Amazon fournit des mécanismes pour répliquer automatiquement les données entre les différentes zones d'une même région.

Travailler avec plusieurs régions permet de cloisonner les instances de son système d'information, mais nécessite la mise en place de mécanismes complexes pour la synchronisation des instances. Amazon n'offre pas de mécanismes pour synchroniser ses instances entre deux régions.

Le deuxième point consiste à effectuer des backups réguliers de son système d'information. Lors de la panne du 21 avril, la première tâche effectuée par les ingénieurs d'Amazon a été de réaliser un "snapshot" des Elastic Block Store (EBS) impactés. Un snapshot n'est rien d'autre qu'un backup. Amazon recommande de faire des snapshots réguliers des EBS afin de garantir une sauvegarde à long terme de ses données. La technique du snapshot permet aussi de multiplier rapidement les instances. Au sein de nos entreprises, ne faisons-nous pas des backups réguliers? La fréquence et la méthode des backups dépendent évidement de la nature et de l'importance des données.

Le troisième point des recommandations consiste à employer une solution de Cloud de type hybride ou multi-prestataires. Cette solution peut prendre différentes formes:

• Garder les données vitales au sein de son entreprise. Cette solution permet de rassurer sa direction, car l'entreprise garde le contrôle total sur ses données. Par compte elle est souvent aussi couteuse qu'héberger son propre Cloud privé. L'entreprise doit assurer par elle-même l'élasticité de sa solution, mais aussi la sécurité de cette dernière.
• Mettre en place une solution de multiplication d'instance. Nous revenons ainsi au deuxième point, sur les snapshots, que j'ai évoqué ci-dessus. La copie principale du snapshot est conservée au sein de l'entreprise et elle est instanciée autant de fois que nécessaire, en interne et/ou chez un prestataire de service Cloud. Cette solution permet une très grande élasticité, mais elle n'est pas adaptée pour des solutions applicatives où l'utilisateur doit éditer les données.
• Utiliser plusieurs prestataires de service. Cette solution permet de réduire les risques de pannes. Par compte elle est souvent plus difficile à mettre en œuvre, car il n'existe pas de standards.

Pour conclure cet article, je peux dire qu'Amazon ne peut être tenu entièrement responsable pour la perte de données évoquée dans l'article "Panne dans le cloud: Amazon perd des données de ses clients" [1]. Il faut lire attentivement le SLA. En fonction de l'importance de ses données, il faut mettre en place une solution adaptée. Cette solution doit mettre en œuvre les solutions décrites ci-dessus. Elle devra être déployé dans des data centres entièrement indépendant. La solution devra être backupée régulièrement. Idéalement elle devra être hybride et/ou multi-prestataires.

Pour garantir le bon fonctionnement de sa solution Cloud, cette dernière devra être entièrement automatisée du backup à la multiplication d'instances.

[1] Panne dans le cloud: Amazon perd des données de ses clients, Nicolas Paratte - ICT journal, http://www.ictjournal.ch/fr-CH/News/2011/04/29/Panne-dans-le-cloud-Amazon-perd-des-donnees-de-ses-clients.aspx, publié en ligne le 29 avril 2011, consulté le 30 avril 2011

[2] Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region, Amazon web services, http://aws.amazon.com/message/65648/, publié en ligne le 29 avril 2011, consulté le 29 avril 2011

[3] How SmugMug survived the Amazonpocalypse, Don MacAskill, http://don.blogs.smugmug.com/2011/04/24/how-smugmug-survived-the-amazonpocalypse/, publié en ligne le 24 avril 2011, consulté le 28 avril 2011

[4] The Cloud is not a Silver Bullet, Joe Stump, http://stu.mp/2011/04/the-cloud-is-not-a-silver-bullet.html, publié en ligne le 25 avril 2011, consulté le 28 avril 2011

[5] Seven lessons to learn from Amazon's outage, Phil Wainewright ZDNet, http://www.zdnet.com/blog/saas/seven-lessons-to-learn-from-amazons-outage/1296, publié en ligne le 24 avril 2011, consulté le 28 avril 2011