Après quatre jours pénibles, les quelques clients restants encore touchés par la panne majeure d'Amazon reviennent progressivement en ligne. Voici sept leçons clés à tirer de cet épisode.
Depuis la dernière mise à jour cet après-midi sur Tableau de bord de l'état des services d'Amazon, seule une poignée de clients attendent toujours la restauration de leurs instances EBS et RDS après La pénible panne de jeudi. Mais pour toutes les personnes impliquées (notamment le personnel opérationnel d'Amazon), ces quatre jours ont été très longs (voir dernière discussion Techmeme). Quelles sont les leçons à tirer?
1. Lisez le SLA de votre fournisseur de cloud très soigneusement
Étonnamment, cette panne de près de quatre jours a pas a violé le SLA EC2 d'Amazon, qui comme l'explique une FAQ, "garantit une disponibilité de 99,95 % du service au sein d'une région sur une période de 365 heures." Puisqu'il s'agit des services EBS et RDS plutôt que EC2 lui-même qui a échoué (et tous les échecs ont été limités aux zones de disponibilité au sein d'une seule région), le SLA n'a pas été violé, légalement Parlant. Bien entendu, cela n’est pas une consolation pour les personnes touchées, ni une excuse pour les perturbations qu’elles ont subies. Mais cela donne certainement matière à réflexion.
2. Ne prenez pas pour acquis les assurances de votre fournisseur
De nombreux clients concernés payaient un supplément pour héberger leurs instances dans plusieurs zones de disponibilité (AZ). Amazon recommande en fait cette ligne de conduite pour garantir la résilience face aux échecs. Chaque AZ, selon la FAQ d'Amazon, "fonctionne sur sa propre infrastructure physiquement distincte et indépendante, et est conçue pour être hautement fiable. Les points de panne courants tels que les générateurs et les équipements de refroidissement ne sont pas partagés entre les zones de disponibilité. De plus, ils sont physiquement séparés, de sorte que même des catastrophes extrêmement rares telles que des incendies, des tornades ou des inondations ne feraient que affecter une seule zone de disponibilité. » Malheureusement, cela s’est avéré être une spécification technique plutôt qu’une garantie contractuelle. Il faudra pas mal d’efforts à Amazon pour réparer les dommages à sa réputation que cet événement lui a causés.
Justin Santa Barbara, fondateur et PDG de FathomDB, a été franc dans son article de blog sur Pourquoi le ciel tombe:
"AWS n'a pas tenu ses promesses sur les scénarios de défaillance des zones de disponibilité... Les sites en panne ont été correctement conçus conformément au « contrat »; le problème est qu'AWS n'a pas suivi ses propres spécifications. Que cela soit dû à l'incompétence, à la malhonnêteté ou à quelque chose de beaucoup plus pardonnable, nous ne le savons tout simplement pas à ce stade. »
S'il est facile d'être sage après coup, la vulnérabilité d'Amazon à ce type de défaillance a peut-être été visible lors d'un exercice de diligence raisonnable suffisamment approfondi. En tant que scientifique en chef de Joyent, concurrent d'Amazon, Jason Hoffman notes sur le blog de l'entreprise"Il ne s'agit pas d'un 'ralentisseur', d'une 'panne du cloud' ou de 'douleurs de croissance', c'est une conséquence prévisible des décisions architecturales fondamentales prises par Amazon."
3. La plupart des clients pardonneront toujours à Amazon ses échecs
Quelle que soit la gravité de leur impact, les fournisseurs ont chanté les louanges d'Amazon, reconnaissant à quel point cela les a aidés à gérer une infrastructure puissante à moindre coût et avec moins d'efforts. Beaucoup ont préfacé leurs critiques avec gratitude pour ce qu'Amazon a rendu possible, comme Keith Smith, PDG de BigDoor:
« AWS nous a permis de faire évoluer un système complexe rapidement et de manière extrêmement rentable. À tout moment, nous disposons de 12 serveurs de bases de données, 45 serveurs d’applications, six serveurs statiques et six serveurs d’analyse opérationnels. Nos systèmes s'adaptent automatiquement lorsque le trafic ou les exigences de traitement augmentent, et diminuent automatiquement lorsqu'ils ne sont pas nécessaires afin d'économiser de l'argent. »
4. Il existe de nombreuses façons de renforcer la résilience d'un fournisseur de cloud
Comme George Reese d'O'Reilly souligne"Si vos systèmes tombaient en panne dans le cloud Amazon cette semaine, ce n'était pas la faute d'Amazon. Soit vous avez considéré une panne de cette nature comme un risque acceptable, soit vous n'avez pas réussi à concevoir le cloud d'Amazon. modèle informatique." Il est utile de passer en revue les techniques utilisées par les clients pour minimiser leur exposition aux pannes. chez Amazon.
Twilio, par exemple, n'a pas chuté. Bien que la société n'ait pas expliqué exactement quelle était son exposition aux zones de disponibilité concernées de Virginie du Nord, elle a décrit ses principes de conception architecturale dans une première entrée sur son nouveau blog d'ingénierie par le co-fondateur et CTO Evan Cooke. Il s'agit notamment de décomposer les ressources en pools indépendants, de prendre en charge les délais d'attente et les tentatives rapides et d'avoir idempotent interfaces qui permettent plusieurs tentatives de requêtes ayant échoué. Bien sûr, tout cela est plus facile à dire qu'à faire si toute votre expérience consiste à concevoir des piles d'applications d'entreprise étroitement couplées qui supposent un réseau local résilient. Le message de Cooke décrit ensuite certaines des caractéristiques qui rendent l'architecture de Twilio capable de fonctionner de cette manière plus tolérante aux pannes. Pour commencer, « Séparez la logique métier en petits services apatrides qui peuvent être organisés en pools simples et homogènes ». Une autre étape consiste à partitionner la lecture et l'écriture des données: "s'il existe un grand pool de données rarement écrites, séparez les lectures et les écritures dans ce pool données... Par exemple, en écrivant sur une base de données maître et en lisant à partir des esclaves de la base de données, vous pouvez augmenter le nombre d'esclaves en lecture pour améliorer la disponibilité et les performances.
Un autre site qui n'est pas tombé en panne est NetFlix, qui gère toute son infrastructure dans le cloud Amazon. Encore une fois, on ne sait pas exactement dans quelle mesure ses opérations étaient exposées aux ressources amazoniennes affectées, mais un Fil d'actualité sur les hackers résume utilement certains des principes employés.
5. Renforcer la résilience a un coût
Bob Warfield décrit comment une entreprise précédente a utilisé l'infrastructure Amazon.com d'une manière qui lui permettait de "ramener le service dans une autre région si celle dans laquelle nous nous trouvions tombait totalement en panne en 20 minutes et avec pas plus de 5 minutes de données". perte. » Comme il poursuit, les choix que vous faites concernant la durée de la panne que vous êtes prêt à supporter ont des conséquences sur le coût que vos clients ou votre entreprise doivent payer. fonds. "Les utilisateurs intelligents et les fournisseurs PaaS envisageront de regrouper plusieurs options, car vous devez de toute façon être sauvegardé sur S3, et alors vous vous disputez essentiellement et vous payez un supplément pour savoir à quel point le site alternatif est « chaleureux » et combien de choses doivent être créées à partir de zéro via S3."
6. Comprendre les compromis vous aide à déterminer quoi demander
Il y a des questions que vous devriez vous poser pour vous assurer qu'un service cloud sur lequel vous comptez ne vous expose pas à des problèmes similaires. échec (ou du moins, si c'est le cas, vous comprenez cela et êtes prêt à en supporter les conséquences en échange d'un prix moins cher). coût). Se référant à la pratique de NetFlix de tuer au hasard des ressources et des services afin de tester sa résilience, Bob Warfield ajoute ce conseil:
"C'est probablement une autre bonne question à poser à vos fournisseurs PaaS et Cloud: " Arrêtez-vous la production? infrastructure pour tester votre basculement ?" Bien sûr, vous aimeriez voir cela et ne pas vous contenter de les croire sur parole. aussi."
7. Le manque de transparence pourrait être le « talon d'Achille » d'Amazon
Plusieurs clients concernés se sont plaints du manque d’informations utiles fournies par Amazon pendant la panne. Keith Smith, PDG de BigDoor a écrit"Si Amazon avait été plus ouvert à propos de ce qu'il vit, nous aurions pu restaurer nos systèmes plus tôt." Roman Stanek de GoodData a appelé Amazon à abattre son mur du secret:
« Nos développeurs ne peuvent pas lire dans les feuilles de thé comment organiser nos systèmes en termes de performances, d'évolutivité et, surtout, de reprise après sinistre. La différence entre les SLA « raisonnables » et les « cinq-9 » est la différence entre l'improvisation et l'alignement complet de nos processus opérationnels respectifs... Il ne devrait pas y avoir de murs de communication entre les couches IaaS, PaaS, SaaS et client de l'infrastructure cloud. »
Le défi d'Amazon dans les semaines à venir est de montrer qu'il est prêt à fournir à ses clients les informations dont il a besoin pour renforcer cette résilience de manière fiable. S’il ne répond pas à ce besoin et permet aux autres de faire mieux, il pourrait progressivement commencer à perdre sa position dominante aujourd’hui dans la fourniture d’IaaS.