Arretez Internet : AWS ne répond plus!

Arretez Internet : AWS ne répond plus!

Il y a quelques jours, un incident impactant le fournisseur cloud AWS a eu un écho important chez beaucoup d’entreprises et de services, directement touchés par cette instabilité.

J’ai vu sur les réseaux sociaux de nombreuses réactions, souvent à côté du sujet (malheureusement) et je me suis dit qu’il pouvait être utile de vous donner mon analyse du sujet.

On rembobine

Commençons par rappeler un peu l’incident.

Mercredi soir (heure française), AWS a rencontré un nombre d’erreurs de plus en plus important sur certains de ces services dans la région us-east-1 (North Virginia).

Bien que l’on considère qu’un incident sur une seule zone n’est pas censé avoir un énorme impact sur AWS, il faut considérer que cette zone est la zone "principale" d’AWS. La plupart des services globaux (IAM, CloudFront, Route53, etc.) en dépendent fortement.

Il faut aussi prendre en compte qu’on considère aujourd’hui qu’environ 30 % d’Internet dépend directement d’AWS, ce qui est juste colossal.

Ce n’est pas le premier incident AWS, et ça ne sera pas le dernier. Ce dernier a fait parler de lui en raison de sa durée et de la visibilité qu’on lui a donnée. Beaucoup d’entreprises se sont en effet dédouanées de tout souci en renvoyant la balle à Amazon, mais les choses sont un peu plus compliquées que ça.

"Everything fails all the time."

Cette phrase ne vient pas de moi, mais du CTO d’Amazon Web Services, Werner Vogels.

Elle reprend une règle élémentaire : où que l’on héberge son service, il faut prendre en compte qu’il tombera parfois, comme toute infrastructure.

Faisant de la production depuis plus de 10 ans, je suis rodé sur le sujet, on peut redonder un service, on ne fait que réduire le risque d’incident. Le risque zéro n’existe pas.

Lors de mes formations AWS, c’est d’ailleurs un point qui revient souvent, la question à se poser sur le design de son infrastructure n’est pas "comment faire que mon infrastructure ne tombe pas", mais plutôt "que faire quand mon infrastructure tombe".

Ceux qui, comme moi, travaillent au quotidien sur AWS le savent, il y a des incidents tous les jours, certes moins impactant, mais il y en a tout de même.

Les risques de l’hyperconvergence

Les clouds publics et surtout les GAFAM ont permis une hyperconvergence de beaucoup de services.

En effet, de par les briques proposées, il est très facile de se dire qu’on va placer toutes ses billes chez AWS/Azure/GCP.

Une entreprise peut effectivement trouver de quoi répondre à quasiment tous ses besoins sur étagère, très souvent avec des services directement managés et le support qui va avec.

Cet aspect a été un vecteur d’accélération important ces dernières années, permettant de déployer et donc d’innover toujours plus vite.

Le souci est que cela a aussi fait d’AWS un colosse d’Internet. Beaucoup d’entreprises sont devenues complètement dépendantes de ce fournisseur.

Mais se contenter de dire que le souci est là, c’est voir uniquement la partie émergée de l’iceberg.

Design et évaluation des risques

Dans une DSI, le rôle d’un architecte est de designer une infrastructure résiliente répondant à des besoins technicofonctionnels.

Lorsqu’on parle de résilience, on pense souvent à avoir toujours une application fonctionnant 24/7 avec un taux de disponibilité à 99,99 %.

Dans la réalité c’est plus compliqué que ça.

Évaluation de risques VS coût

Normalement, lorsqu’on design une architecture, on se pose la question du taux de disponibilité visé ainsi que le coût d’une indisponibilité.

De plus, il faut voir si des mécanismes permettent de mitiger une indisponibilité.

Par exemple, imaginons un appareil de domotique : ce dernier envoie ses métriques sur AWS toutes les 10 minutes.

Que se passe-t-il si mon service devant réceptionner ces métriques est indisponible ?

2 choix ici :

  • Je perds mes métriques : la disponibilité de mon service est donc primordiale
  • J’ai un tampon localement sur l’appareil, permettant de temporiser en cas d’indisponibilité : dans ce cas, je peux me permettre une indisponibilité, car je ne perds potentiellement que la partie "temps réel"

Ces deux choix sont déjà déterminés par l’argent que l’on souhaite mettre dans un projet.

Avoir du stockage local coûte en effet du matériel supplémentaire, de la complexité supplémentaire d’assemblage et un coût supplémentaire de développement et de maintien en condition opérationnelle.

De même, cela signifie que mon serveur est capable de gérer en mode "rattrapage".

L’autre aspect, c’est de se demander quel est le coût de l’indisponibilité :

  • En termes de service rendu
  • En termes de pénalités potentielles contractuelles
  • En termes d’image

On met ensuite cette indisponibilité face à la probabilité de cette dernière. Très souvent, de manière simpliste, la disponibilité potentielle d’une infrastructure est celle de l’élément ayant la disponibilité la plus faible.

Ensuite, on peut se poser la question de combien coûtera la couverture de cette indisponibilité.

Ensuite, on fait une simple comparaison, et de manière assez évidente, la solution la plus rentable est celle prise en compte.

C’est pourquoi une indisponibilité n’est pas toujours un problème. C’est le rôle des architectes d’évaluer cette dernière en amont.

La théorie du chaos

Pour avoir confiance dans son infrastructure, il faut l’éprouver. C’est l’idée de base du chaos engineering.

Partir du constat que votre infrastructure va tomber est un point, la faire tomber volontairement, dans un cadre que l’on maîtrise permet :

  • d’augmenter la confiance dans votre haute disponibilité
  • d’éprouver vos procédures et/ou remédiations automatisées

Des outils existent à cette fin, si vous souhaitez en savoir plus, je vous invite à lire les excellents posts de mon collègue Akram à ce sujet sur le blog de WeScale :

Le guide de Chaos Engineering : Partie 1
Le Chaos Engineering (CE) est une discipline d’expérimentation dans les systèmescomplexes et distribués, qui vise à se rassurer sur leur comportement face à desincidents et perturbations. Dans cet article je vais m’attacher à simplementapporter les bases du chaos et quelques définitions pour pose…
Le guide de Chaos Engineering : Partie 2
Introduction Nous avons vu dans la première partie du guide du Chaos Engineering (CE)[/2019/09/26/le-guide-de-chaos-engineering-part-1/] que le CE ne peut pas avoirlieu sans expérimentations. Nous allons continuer notre voyage fantastique dans ce monde en passant par lepays du “Chaos Tools Cou…

Certaines entreprises vont jusqu’à utiliser ces outils en production, par exemple, Netflix utilise sa simian army en production pour s’assurer de la bonne résilience de ses infrastructures.

Détruire en maîtrisant permet aussi de mieux savoir réagir quand votre infrastructure tombe, vu que c’est une habitude.

Pour terminer

Les entreprises qui ont rejeté la faute sur AWS sont les seules fautives.

Soit elles ont sous-estimé l’impact d’une indisponibilité, soit cette indisponibilité coûte moins cher que de la prévoir.

Dans tous les cas, c’est un choix de design de dépendre d’un seul fournisseur, et d’une seule zone de disponibilité. Rejeter la faute sur un fournisseur est lâche et ne représente pas la réalité des choses.

Il est possible de préparer et simuler ces indisponibilités en avance de phase pour réagir au mieux, la répétition crée la confiance.

L’autre souci vient aussi du fait que beaucoup d’entreprises ont tout misé sur AWS, les incidents de ces derniers jours vont peut-être rebattre un peu les cartes, mais est-ce plus mal ?

Prôner à tout pris un fournisseur de cloud souverain n’est pas la solution non plus si l’on met toutes ses billes au même endroit. Encore une fois, bien designer son infrastructure est primordial, mieux vaut prévenir que guérir. Vous pouvez d'ailleurs en savoir plus sur ce sujet avec le post de Damy.R :

AWS tombe, l’internet tremble
Cela ne vous a pas échappé, le cloud AWS a subbit un incident assez important cette semaine. Je vous propose de revenir dessus dans un petit article