Le crash d’EC2

Une des nouvelles qui a fait grand bruit sur la toile a été le crash du service de Cloud Computing d’Amazon.com, EC2. Ce dernier a eu beau affirmer offrir un taux de disponibilité de 99,95% (soit environ 4 heures par an), plusieurs sites Web hébergés sur EC2 ont été hors-service pendant plus que ça – certain jusqu’à 36 heures.

Attentes différentes

Le fait qu’un site Web soit hors service n’est en soi n’est rien de nouveau. Les sites Web plantent, les infrastructures informatiques défaillent pour de nombreuses raisons. J’ai personnellement vu des pannes informatiques généralisées parfois dues à une erreur humaine (l’électricien qui déclenche par inadvertance l’alarme incendie dans la salle machine), parfois par malveillance (un employé du service réseau qui a fichu la pagaille après avoir appris qu’il était licencié).

Mais lorsque l’on délègue quelque chose – et que l’on paye pour cela – les attentes sont bien plus importantes. « Ce sont des professionnels, on peut leur faire confiance. » Pas toujours.

Tout d’abord, séparons les compagnies de Cloud Computing qui fournissent de la puissance de traitement pur à la demande des compagnies de SaaS (Service as a Service) qui louent sur site Web sous forme de service. Si ces dernières sont souvent l’interlocuteur du client final, elles hébergent rarement leurs propres serveurs et passent au contraire par des compagnies de Cloud Computing spécialisées. Amazon.com, Microsoft Azure, mais d’autres moins connus tels que GoGrid ou Rackspace Cloud.

Le premier problème est que les compagnies de SaaS se spécialisent plus dans l’aspect applicatif que dans l’aspect haute disponibilité, reléguant ce dernier aux compagnies de Cloud Computing. Mais lorsque l’on a affaire à de la haute disponibilité, tous les éléments de la chaîne peuvent mettre le site Web hors-service. Les machines comme l’application que construisent les compagnies de SaaS.

Dans le cas d’Amazon.com, le problème n’a cependant pas été au niveau du SaaS mais bel et bien du réseau de machines. Les systèmes comme le service EC2 d’Amazon ont des mécanismes de redondance en cas d’indisponibilité de certains éléments du réseau. En d’autres termes, ce sont des mécanismes de type non-Karenine, c’est-à-dire que pour qu’une panne survienne il faut que plusieurs problèmes se superposent. Dans le cas d’EC2, voici dans les grandes lignes ce qui est arrivé :

  • Amazon.com a voulu mettre à jour la capacité de stockage dans son réseau de Virginie. Pour cela, le trafic a dû être rerouté. Pour l’instant, rien d’anormal.
  • Le premier problème est survenu lorsque, du fait d’une erreur humaine, le trafic a été incorrectement rerouté vers un réseau de secours. Ce réseau s’est alors effondré, n’ayant pas la capacité pour supporter l’afflux de trafic.
  • Le deuxième problème a été qu’un bug dans l’architecture d’EC2 a fait que cet effondrement a provoqué la panique générale au sein des serveurs d’EC2.

Quelles sont les chances pour que les deux problèmes arrivent en même temps ? Sur le papier, quasi-impossible – j’ai même lu dans quelques articles que la panne de EC2 était soi-disant « impossible ». Du moins en pratique. Le problème est qu’un système non-Karenine entraîne un faux sentiment de sécurité. Car un ou plusieurs éléments du système ne peuvent ne pas fonctionner (ou ne fonctionnent qu’en intermittence) sans que l’on se rende compte de quoi que ce soit. Après tout, le système fonctionne correctement.

Et c’est ce qui arrivé chez Amazon.com : le bug dans l’architecture d’EC2 existait depuis toujours. Mais il est passé inaperçu pendant des années car le premier problème (le reroutage par inadvertance vers le mauvais réseau) ne s’était jamais produit.

Amazon.com n’est-il donc rempli que d’incapables ? Loin de là ! Rappelons que la compagnie doit génér un site Web qui doit résister au gros volume de ventes à la période de Noël sans jamais tomber en panne – toute mise hors service coûte fort cher en revenus perdus. Amazon.com a donc une expérience en matière de haute disponibilité et de traffic élevé.

Mais plus un système est complexe, plus n’importe quel changement peut entraîner des conséquences auxquelles on n’avait pas pensé. Pour empêcher la panne, Amazon.com aurait dû identifier tous les cas de scénarios de panne. Et si une panne peut être provoquée par la conjonction de N facteurs, s’assurer pour chacune des combinaisons que le réseau fonctionne toujours lorsque N – 1 facteur est présent.

Allez par contre tester ça en pratique…

Explore posts in the same categories: Internet

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s


%d blogueurs aiment cette page :