Heroku betrieb alle Kunden in einer einzigen AWS-Region – dann fiel EBS für 80 Stunden aus

Am 21. April 2011 um 8:15 UTC schlugen bei Heroku überall Überwachungsalarme an: Timeouts trafen seine Web-, Caching- und Routing-Dienste. Der Auslöser lag vorgelagert – um 12:47 Uhr PDT verlagerte eine AWS-Netzwerkänderung in einer einzigen Availability Zone in US-East den primären EBS-Datenverkehr auf ein Replikationsnetz mit geringerer Kapazität, wodurch EBS-Knoten isoliert und ein Re-Mirroring-Sturm ausgelöst wurde, der laut AWS' eigener Darstellung 13 % der Volumes in der Zone festsitzen ließ.

EC2 selbst erholte sich in etwa 12 Stunden, doch EBS blieb mehr als 80 Stunden lang beeinträchtigt. Heroku – das seine gesamte Plattform in US-East betrieb, mit seinen Datenbanken auf EBS – hatte kein Ausweichziel: Es gab keine zweite Region. Die meisten Anwendungen kamen innerhalb von 16 Stunden zurück; kostenlose Apps auf gemeinsam genutzten Datenbankservern brauchten bis zu drei Tage.

Herokus Post-Mortem verweigerte die naheliegende Ausrede: „Heroku übernimmt 100 % der Verantwortung für die Ausfallzeit, die unsere Kunden betrifft.“ Die drei Lehren, die es daraus zog: Availability Zones innerhalb einer Region unterteilen das Risiko nicht so, wie das Team angenommen hatte; Blockspeicher ist keine cloudfreundliche Technologie; und eine Plattform, die verspricht, Infrastruktur zu abstrahieren, trägt die Konsequenzen, wenn diese Infrastruktur ausfällt.

Die meisten Apps kamen innerhalb von 16 Stunden zurück; kostenlose Apps auf gemeinsam genutzten Datenbanken blieben bis zu 3 Tage lang dunkel; EBS in US-East war über 80 Stunden lang beeinträchtigt

Die gesamte Plattform lebte in einer einzigen AWS-Region, und ihre Availability Zones teilten offenbar Ausfallmuster, von denen Heroku angenommen hatte, sie seien voneinander getrennt.

Zustandsbehaftete Dienste lagen auf EBS, das noch lange nach der Erholung von EC2 defekt blieb – eine Abhängigkeit, die Heroku weder umgehen noch mitten im Vorfall ersetzen konnte.

Das Standard-Vorgehen – ungesunde Instanzen beenden, ersetzen, auf AWS warten – ging davon aus, dass Ausfälle ein oder zwei Stunden dauern. Dieser dauerte Tage.

Multi-Region war jahrelang als großes Projekt mit geringem Verfügbarkeitsnutzen zurückgestellt worden. Der April-Ausfall bewertete es an einem einzigen Wochenende neu.

Availability Zones innerhalb einer Cloud-Region sind keine Redundanz. Wenn jeder Kunde in derselben Region auf demselben Blockspeicher läuft, wird ein vorgelagerter Netzwerkfehler zum Ausfall für alle.

Heroku erklärte, Multi-Region deutlich höher zu priorisieren und seine Abhängigkeit von EBS zu verringern, und begann mit architektonischen Änderungen, die es der Plattform ermöglichen sollten, Ausfälle auf IaaS-Ebene zu überstehen. AWS' Zusammenfassung des Ereignisses wurde zu einer der meistgelesenen Ausfallanalysen der Branche, und „nicht alles in eine Region packen“ wurde zur Standard-Cloud-Empfehlung. Heroku behielt danach dennoch jahrelang eine stark auf eine einzige Region ausgerichtete Haltung bei, und die von ihm identifizierte Konzentration tauchte in späteren Vorfällen immer wieder auf.