Heroku exécutait tous ses clients dans une seule région AWS — puis EBS est tombé en panne pendant 80 heures

Le 21 avril 2011 à 8 h 15 UTC, des alertes de supervision se sont déclenchées dans toute l'infrastructure de Heroku : des délais d'attente frappaient ses services web, de mise en cache et de routage. Le déclencheur était en amont — à 12 h 47 PDT, une modification réseau d'AWS dans une seule zone de disponibilité de la région US-East a déplacé le trafic EBS principal vers un réseau de réplication de moindre capacité, isolant les nœuds EBS et déclenchant une tempête de re-mirroring qui a laissé 13 % des volumes de la zone bloqués, selon le propre compte rendu d'AWS.

EC2 lui-même s'est rétabli en une douzaine d'heures environ, mais EBS est resté dégradé pendant plus de 80 heures. Heroku — qui exploitait toute sa plateforme dans la région US-East, avec ses bases de données sur EBS — n'avait aucune possibilité de basculement : il n'existait pas de seconde région. La plupart des applications sont revenues en 16 heures ; les applications gratuites hébergées sur des serveurs de bases de données partagés ont mis jusqu'à trois jours.

Le post-mortem de Heroku a refusé l'excuse évidente : « Heroku assume 100 % de la responsabilité de l'indisponibilité subie par ses clients. » Les trois leçons qu'il en a tirées : les zones de disponibilité d'une même région ne cloisonnent pas le risque comme l'équipe l'avait supposé ; le stockage par blocs n'est pas une technologie adaptée au cloud ; et une plateforme qui promet d'abstraire l'infrastructure assume les conséquences lorsque cette infrastructure tombe en panne.

La plupart des applications sont revenues en 16 heures ; les applications gratuites sur bases de données partagées sont restées indisponibles jusqu'à 3 jours ; EBS en US-East est resté dégradé pendant plus de 80 heures

Toute la plateforme vivait dans une seule région AWS, et ses zones de disponibilité se sont révélées partager des modes de défaillance que Heroku avait supposés cloisonnés.

Les services à état reposaient sur EBS, qui est resté en panne bien après le rétablissement d'EC2 — une dépendance que Heroku ne pouvait ni contourner ni remplacer pendant l'incident.

Le manuel standard — tuer les instances défaillantes, les remplacer, attendre AWS — supposait des pannes d'une heure ou deux. Celle-ci a duré des jours.

Le multi-région avait été relégué au second plan pendant des années, considéré comme un gros projet au faible gain de disponibilité. La panne d'avril en a réévalué le coût en un week-end.

Les zones de disponibilité d'une même région cloud ne constituent pas une redondance. Si tous les clients s'exécutent dans la même région sur le même stockage par blocs, une seule erreur réseau en amont devient une panne pour tout le monde.

Heroku a déclaré qu'il ferait du multi-région une priorité bien plus élevée et réduirait sa dépendance à EBS, et a entamé des changements architecturaux destinés à permettre à la plateforme de survivre à des défaillances au niveau de l'IaaS. Le résumé d'AWS sur l'événement est devenu l'une des analyses de panne les plus lues du secteur, et « ne mettez pas tout dans une seule région » est devenu un conseil cloud standard. Heroku a néanmoins conservé une posture fortement mono-région pendant des années par la suite, et la concentration qu'il avait identifiée n'a cessé de réapparaître dans des incidents ultérieurs.