L'interruption de service d’Amazon - qu'est ce que ça signifie pour l’infonuagique?

Image XKCD traduit par xkcd... en français

Que s’est-il passé?

Amazon Web Services a connu une interruption de service durant 8 heures 33 minutes le dimanche 20 septembre 2015, de 2 h 19 HAP à 10 h 52 HAP. La panne a touché leur bureau de la Virginie du Nord (US-East–1) et a commencé par une interruption de réseau qui a augmenté de façon significative le taux d’erreur sur le service de DynamoDB d’Amazon (sans base de données SQL). Cela engendra une cascade où 37 autres services d’AWS ont commencé à défaillir et à démontrer une augmentation de taux d’erreur de requête d’API.

Parmi ceux-ci, le SQS (Simple Queue Service) d’AWS, EC2, (Elastic Compute Cloud), CloudWatch (surveillance des ressources) et les services Console (gestion basée sur navigateur, GUI). Tôt le matin de ce dimanche, presque tous les services d’AWS dans la région de la Virginie du Nord ont été affectés d’une façon ou d’une autre.

Ce n’est qu’une fois que les ingénieurs d’Amazon ont accéléré la cadence sur leur API, qu’ils ont pu augmenter les capacités et commencer à restaurer les fonctions de services à des niveaux normaux. Fortune et Venture Beat fournissent des rapports compréhensibles sur la panne. Pour ceux qui ont des habiletés techniques, post mortem d’AWS met en lumière le processus par lequel la cascade de défaillance s’est produite et s’est finalement réglée. Cette ligne du temps par Richard I. Cook est aussi assez compréhensible :

La cascade semble avoir dépassé la panne initiale puisque certains clients ont continué de rapporter des problèmes de lancement d’EC2, 2 jours après l’interruption.

Qui a été touché?

Le plus surprenant, c’est le nombre de services qui ont été touchés par la panne et qui sont utilisés tous les jours par le public. Parmi ceux qui ont été touchés par la panne en Virginie du Nord figurent Netflix, IMDB, Tinder, Airbnb, Nest, Medium, Pocket, Reddit, Product Hunt, Viber Buffer, SocialFlow, GroupMe et même Instant Video et Echo services d’Amazon.

La réaction

Plusieurs furent surpris du grand nombre de services Internet qui fonctionnent grâce au nuage d’Amazon. D’autres nous ont rappelé qu’AWS fourni plus de 90 % des capacités infonuagiques utilisées par les 15 plus grands fournisseurs IaaS [1], cela démontre que l’industrie est trop dépendante d’un seul fournisseur infonuagique :

« Il est réellement dangereux, à cause des droits d’auteurs sur les API, de se restreindre à un seul nuage par le biais d’API. » J’ai peur de recréer le Microsoft des années 90 où un seul fournisseur possédait l’intégralité de l’interface de l’informatique moderne. — Joe Beda (@JBeda), 22 septembre 2015.

Une personne l’a soulevé sur Twitter : le DynamoDB d’AWS n’a pas d’ANS énoncés.

« Si DynamoDB peut éviter de plus amples problèmes, il peut certainement reprendre le cours de 99,999 % de ses ANS dans seulement 60 courtes années. » — Dennis (@Opacki), 20 septembre, 2015.

D’autres ont su voir l’humour dans la situation :

Voici ce que j’imagine à quoi #AWS #AWSOutage ressemble actuellement.

— Jess Bahr (@JessaBahr), 20 septembre 2015.

Ian Rae, DG de CloudOps, n’est pas réellement surpris que cela se soit produit dans cette région US-East d’Amazon :

« La Virginie du Nord est le « trou noir » de l’infonuagique ». Ce fut la première région d’AWS et tout le monde veut y être. Si quelqu’un crée une application Web et qu’il veut l’intégrer à dix autres fournisseurs SaaS hébergés par Amazon, il se rendra en Virginie car c’est l’endroit il trouvera le plus faible taux de latence.

Historiquement, la région US-East–1 fut la première à lancer de nouvelles fonctionnalités et manquait toujours de capacités [2]. Le fait est qu’Amazon ne sait même pas quel sera le prochain problème qu’elle rencontrera en Virginie du Nord. Cette situation est un exemple illustrant parfaitement comment les choses peuvent s’effondrer dans un système complexe.

Qu’est-ce que cela signifie pour l’Infonuagique?

Les pannes d’Amazon ne sont pas nouvelles et se produisent de temps en temps[3]. Lorsqu’elles surviennent, certaines personnes paniquent, d’autres déclarent que rien n’a changé et celles qui s’intéressent le plus aux architectures robustes soulignent l’importance de concevoir dans le but d’échouer avec des régions multiples et des multiples nuages.

À l’instar de ces deux derniers points, il y a des leçons à tirer de la façon dont Netflix a su gérer cette récente panne. TechRepublic a publié un excellent rapport sur la manière dont Netflix a pu « affronter la tempête » en créant des systèmes conçus pour résister aux pannes les plus imprévisibles :

Pour Netflix, ce fut une répétition de ce qu’ils appellent « la mécanique du chaos », et qui aide le service à affronter les interruptions.

Par cette approche d’ingénierie, Netflix déploie sa « Simian Army », un logiciel qui tente délibérément de faire des ravages dans son système. La « Simian Army » attaque l’infrastructure de Netflix sur plusieurs fronts — « Chaos Monkey » désactive au hasard les instances de production tandis que « Latency Monkey » cause des délais dans les communications entre les clients et le serveur; puis le plus costaud, « Chaos Gorilla », simule l’interruption de toute une zone de disponibilité d’Amazon.

En provoquant constamment des pannes dans ses systèmes, l’entreprise est capable de se protéger contre des problèmes comme ceux qui ont touché AWS ce dimanche.

Dans ce cas particulier, Netflix a pu rediriger rapidement le trafic de la zone affectée d’AWS vers des centres de données d’une région intacte.

Brandon Butler chez Network World décrit comment Amazon ouvre la voie en partageant ses formules avec les acteurs de l’industrie :

Certains estiment que Netflix est en train de devenir l’une des entreprises infonuagiques les plus importantes dans l’industrie, car non seulement elle prouve qu’une entreprise qui réalise 3.7 milliards de dollars comme chiffre d’affaires annuel peut exploiter le nuage public pour ses charges de travail capitales, mais elle révèle aux développeurs sa façon de procéder et fournit aux autres, une voie à suivre.

D’autres sont moins convaincus que Netflix soit un si bon exemple à suivre, surtout en ce qui concerne les pratiques exemplaires sectorielles. Joe Masters Emirson d’Information Week dénonce le fait que Netflix, par sa dépendance excessive à AWS, montre le mauvais exemple. Par son indifférence à la nouvelle génération de pratiques exemplaires et sa grande influence sur la communauté de source libre, Joe estime que Netflix nous mène vers l’enfermement propriétaire quand nous devrions diriger notre attention vers l’utilisation de plusieurs fournisseurs IaaS dans un environnement à nuages multiples — ce qu’il appelle « Infonuagique 2.0 ».

Comment vous protéger

En fin de compte, lorsque vous gérez et configurez votre infrastructure infonuagique, il y a cinq options importantes à considérer pour éviter ou minimiser le temps d’arrêt lors d’une panne comme celle-là.

1. Concevez votre application pour qu’une panne bascule sur plusieurs zones de disponibilités.

2. Concevez votre application pour qu’une panne bascule sur plusieurs régions.

3. Utilisez une infrastructure infonuagique conçue avec une plus grande redondance au niveau du matériel, comme cloud.ca [4]

4. Configurez un système hybride (nuage privé + public) et n’utilisez le nuage public que pour le basculement et l’éclatement.

5. Concevez votre application pour qu’elle s’étende sur plusieurs nuages, grâce à l’option multinuages.

   • L’entreprise Peerio en est un bon exemple; elle offre un service de chiffrement de bout à bout et utilise cloud.ca ainsi qu’AWS dans sa stratégie multinuages. Lire l’étude de cas ici.

Il existe d’autres options, notamment, l’option par défaut qui consiste à ne rien faire du tout. Si vous ne planifiez pas les pannes de région, ou de zones de disponibilité, qui surviendront assurément, vous devriez au moins avoir une idée de combien vous coûtera ce temps d’arrêt.

Dans ma prochaine publication, je reviendrai de façon plus approfondie sur les cinq points mentionnés plus haut et évaluerai les pour et les contre de chacun. Restez à l’écoute si vous êtes utilisateur d’AWS et désirez solidifier votre infrastructure ou si vous êtes intéressé par un système infonuagique hybride ou multinuages.

Suivez-nous sur Twitter et LinkedIn pour recevoir tous les nouveaux articles du blogue de cloud.ca!

Nous offrons des essais gratuits de 7 jours sur notre infrastructure infonuagique. Essayez cloud.ca aujourd’hui!