- MAJ le 6 mars 2017 -
Mardi 28 férvier 2017, Amazon Web Services a connu une interruption de service sur l’une de ses briques de service phare : Amazon S3, le service de stockage en mode « objet » d’AWS.
AWS s'est exprimé publiquement sur cet incident, lié à une erreur humaine. Un ensemble de mesure ont été prises pour que cela ne se reproduise plus, et pour une plus grande réactivité de l'AWS Service Health Dashboard. Le communiqué est disponible à cette adresse.
En prenant un peu de hauteur, je vous propose donc de revenir sur cet incident afin de voir quels enseignements nous pouvons en tirer.
Disclaimer : la société Osones travaille et opère sur le Cloud Amazon Web Services (et OpenStack). Nous n’avons donc pas une impartialité exemplaire. Nous allons cependant essayer de rester le plus factuel possible. Cette tribune a pour but de créer la discussion, n’hésitez pas à nous poser des questions sur twitter @osones !
Go #S3 team, the world is watching. I can't begin to imagine what it means to fix a problem at this scale.
— Julien Simon (@julsimon) 28 février 2017
« AWS est down ! » : c’est FAUX
Dès que l’incident est survenu, twitter s’est affolé : c’est le jeu du oueb, et c’est quand même souvent assez drôle.
L'Internet mondial est par terre. #awsoutage #awsdown https://t.co/JKScoWhTWs
— Korben (@Korben) 28 février 2017
Cependant si on prend la totale mesure de l’incident, cela concerne une région précise : US-EAST-1, c’est-à-dire la Virginie du Nord. Pour ceux qui ne sont pas familiers avec l’infrastructure mondiale AWS, il s’agit d’une des 4 régions disponibles aux USA (avec l’Ohio, la Californie du Nord, et l’Oregon), et une seule des 13 régions disponibles dans le monde !
Enfin, et l’idée n’est pas de minimiser l’incident, cela concerne un des 70+ services proposés par AWS – entrainant également dans sa chute des services moins connus reposant sur la solution de stockage Amazon S3. Ainsi, le site et le blog Osones, intégralement en statique et hébergé sur Amazon S3 pour quelques dollars par mois, n’a subi aucun downtime ni aucune perturbation durant cet incident. Et nous n’étions certainement pas les seuls.
Globalement, AWS, et le Cloud, ça marche.
#AWS had the least amount of #downtime in 2015 among the top-4 #cloud providers. #IoT #gapgrid pic.twitter.com/Bgd0s72uGK
— GapGrid (@GapGrid) 19 janvier 2017
(Désolé je n’ai pas trouvé de données plus récentes, je reste ouvert à vos suggestions !)
« Amazon nous ment sur S3 » : c’est FAUX
Amazon S3 est quasi-infaillible. C’est bien ce quasi qui semble poser soucis, et certains se sentent un peu floués.
#AWS S3 with 99.99% availability is down.... pic.twitter.com/7L1YH7oLkp
— Adam Preston (@_apreston) 28 février 2017
Je vais donc revenir sur deux termes importants, qui sont ouvertement communiqués, autant de manière commerciale que contractuelle.
Une disponibilité de 99,99 % annuelle
La disponibilité est définie par le fait de pouvoir ou non accéder aux objets stockés dans S3. 99,99%, c’est beaucoup, mais cela permet une petite heure d’interruption de service par an.
Une durabilité de 99.999999999 % annuelle (dites « onze-neuf »)
La durabilité affiche quant à elle un taux bien plus important ! Ce n’est cependant pas du tout ce dont il est question ici. Il s’agit de la probabilité de perdre définitivement un objet. Et pour cause, chaque objet est redondé au moins trois fois par région AWS, ce qui permet de résister à la perte simultanée de données dans deux installations. Autant dire que celui qui a déjà perdu un fichier S3 ici me tweet dès maintenant !
« Le Cloud est une arnaque » : c'est FAUX
Si l'on reprend plus précisement la structure d'AWS, chaque région est indépendante, composée de Zones de Disponibilités indépendantes et géographiquement assez éloignées les unes des autres pour être soumises à des risques (naturels ou non) différents, et chacune de ces zones est elle même composée d’au moins un datacenter, souvent deux. Et on entend bien par « datacenter » des bâtiments physiquement séparés.
Il est donc possible facilement - et conseillé - de répartir son infra sur plusieurs « datacenters »… et même entre plusieurs régions ! C’est par exemple le cas de Netflix, qui fait de la répartition de charge entre les régions US à l’aide du service de DNS Route53 d’Amazon.
#AWSoutage should be expected, not a SPOF ! Let's see how @Netflix does it : https://t.co/SxTdQOhCCy #Amazon #S3
— Osones (@osones) February 28, 2017
Si Netflix le fait, ce n’est pas le résultat d’une connaissance empirique sans faille. C’est parce que cette même région (assez âgée à présent) leur avait fait défaut par le passé. Tout le monde apprend de ses erreurs, c’est le lot de l’évolution ! Et aujourd’hui, le Cloud donne malgré tout accès à des outils assez impressionnants à des sociétés de toutes tailles.
« Tous condamnés à faire du multi-cloud » : c'est FAUX, mais ca reste possible
« On ne met pas tous ses œufs dans le même panier krkrkr ». C’est pas faux. Cependant dire qu’AWS est un même panier est partiellement vrai comme on l’a vu avec Netflix.
Bien entendu, Netflix a une taille importante. Cependant, répartir 1 TB de données sur deux régions se fait en quelques clics dans la console et revient à deux fois 30 USD par mois. Soit une manœuvre à la portée de quiconque ne pouvant se permettre 2 heures d’interruption de service dans l’année.
Plus globalement, et c'est un avis personnel, je doute que répartir une infra entre une région US sur AWS et une région Europe sur Google Cloud apporte une réduction significative des risques. Que ce soit au niveau de demandes d’agences gouvernementales, de dépendance à une entreprise privée, ou d’attaque de Hackers qui veulent voir le monde brûler. J’ai tendance à considérer que les acteurs majeurs sont globalement perçus de la même manière. OVH en fait d’ailleurs les frais fréquemment.
Par contre, du Multi-Cloud entre du Public (AWS ou autre) et du « privé » (typiquement, de l’OpenStack) peut apporter un filet de sécurité qui sera réellement conséquent. Ce serait overkill pour 99% des scénarii, mais si cette solution rassure assez certaines DSI pour permettre de sauter le pas vers le Cloud Public, pourquoi pas !
« L’informatique c’est nul on est fichus ! » : c'est VRAI ?
Derrière la blague se cache une réalité : non, le risque zéro n’existe pas, et clairement l’informatique n’est pas une exception à la règle. S’il suffisait d’avoir ses serveurs à la maison pour n’avoir aucun downtime, ça se saurait.
Que ce soient des attaques DDoS, des erreurs de routage par les FAI, des SPOF réseau au niveau des DNS à la Dyn… Oui, l’internet est par définition un réseau best-effort. Et en terme d'infra pure, c'est aussi le travail d'adminsys spécialisés dont nous sommes que d'apporter des solutions qui vont permettre de réduire au maximum ces risques.
Et j’ai plutôt tendance à m’émerveiller que quelques heures d’interruptions par an de quelques sites pour quelques utilisateurs suffisent à enflammer la toile. C’est que, quelque part, on n'est pas si mal habitués.
Mes moments préférés sur Internet:
— Lucie Ronfaut (@LucieRonfaut) 28 février 2017
- Quand on fait des blagues sur les keynotes Apple
- Quand AWS déconne et que vous devenez fous
La discussion est ouverte, n'hésitez pas à nous faire vos retours et à poser vos questions sur notre twitter @Osones; nos Experts restent disponibles !
Découvrez les derniers articles d'alter way
- kubevpn
- Kubernetes 1.32
- re:Invent 2024 : AWS mise tout sur l'IA pour son Cloud
- OVHcloud Summit 2024 : L’innovation au cœur d’un cloud souverain et performant
- Big Data & AI Paris 2024 : L'IA au cœur de toutes les transformations.
- Un retour vers l'open-source ? Vos outils DevOps préférés et leurs equivalents open-source.