Am 21. April haben wir es wieder erlebt. Auch eine hochverfügbare Cloud wie die von Amazon ist nicht vor Fehlern geschützt. Natürlich erhalten Kritiker nun wieder die Gelegenheit gegen die Nutzung der Cloud zu argumentieren. Aber um es vorweg zu nehmen, Anbieter wie Hootsuite, Mobypicture, Foursquare und Reddit hätten von dem Ausfall nicht betroffen sein müssen, hätten Sie auf eine ausfallsichere Architektur gesetzt.

Aus diesem Grund ist es nicht nachvollziehbar, dass diese Unternehmen mit dem Finger auf Amazon zeigen und sagen: “Uns trifft keine Schuld, Amazon ist down!”. Es wäre interessant zu wissen, wer zur Rechenschaft gezogen worden wäre, hätten diese Anbieter keinen Public Cloud Service genutzt, sondern betrieben ein eigenes Rechenzentrum. Denn eines ist klar, (solche) Probleme können in jedem Rechenzentrum auftreten und hätten dann bedeutend schwerwiegendere Probleme. Und wenn die Cloud richtig genutzt worden wäre, wären auch die Probleme bei Amazon in der Form nicht sichtbar geworden.

Was ist passiert?

Hintergrund
Die Amazon Cloud besteht aus mehreren Regionen, verteilt über mehrere Kontinente, in denen sich wiederum mehrere sogenannte Availability Zones befinden. Availability Zones sind verschiedene Standorte innerhalb einer Region, die so konstruiert sind, dass sie isoliert betrieben werden und von Fehlern in anderen Availability Zones nicht betroffen sind.

Durch das Starten von Instanzen in separaten Regionen, können Web Anwendungen so konstruiert werden, dass sich diese geographisch in der Nähe von bestimmten Kunden befinden und rechtlichen oder anderen Anforderungen gerecht werden.

Weiterhin werden Anwendungen vor dem Ausfall eines einzelnen Standorts geschützt, indem Instanzen in separaten Availability Zones ausgeführt werden.

Wie das Konzept genau funktioniert, kann unter Das Konzept hinter den AWS Regionen und Verfügbarkeitszonen nachgelesen werden.

Das Problem
Um 1:41 AM PDT begann das Problem mit Latenzen und Fehlerraten innerhalb der EBS Volumes und Verbindungsproblemen zu den EC2 Instanzen in mehreren Availability Zones der Region US-EAST-1.

Das führte dazu, dass die Webseiten bzw. Webanwendungen, die auf den EC2 Instanzen betrieben werden, nicht mehr erreichbar waren.

Design For Failure

Zunächst muss eines klar sein. Amazon stellt “nur” virtuelle Ressourcen zum Aufbau einer eigenen virtuellen Infrastruktur bereit. Amazon ist NICHT für die Anwendung und deren Funktionalität zuständig, sondern stellt nur die Infrastruktur bereit, auf der die Anwendungen ausgeführt werden.

“Everything fails, all the time” Werner Vogels, CTO Amazon.com

Aus diesem Grund rät Amazon: “Design for failure!” und gibt Tipps, dieses umzusetzen:

• Avoid single points of failure
• Assume everything fails, and design backwards
• Goal: Applications should continue to function even if the underlying physical hardware fails or is removed or replaced.

Und nennt Möglichkeiten für die Realisierung des Designs:

• Use Elastic IP addresses for consistent and re-mappable routes
• Use multiple Amazon EC2 Availability Zones (AZs)
• Create multiple database slaves across AZs
• Use Amazon Elastic Block Store (EBS) for persistent file systems

Design for failure! Ist im Prinzip nichts Neues. Im Grunde sollte das ebenfalls bei jedem anderen nicht Cloud Anbieter und im eigenen Rechenzentrum beachtet werden. Der Entwickler sollte immer in der Pflicht stehen, seine Anwendung gegen Hardware oder sonstige Ausfälle abzusichern und die Verfügbarkeit sicherzustellen.

Hootsuite und Mobypicture bspw. haben den Fehler gemacht, sich nur auf eine AWS Region zu konzentrieren, anstatt ihren Service über die gesamte Amazon Cloud hinweg zu verteilen. Speziell bei Mobypicture, als einen europäischen Anbieter mit Sitz in Holland, ist genau dies ein wenig verwunderlich. Die deutsche Seite von Foursquare hingegen war bspw. erreichbar und lief stabil, ebenso die von Reddit.

Nicht alles auf eine Karte setzen

Für jedes Unternehmen, das seinen Service über die Cloud anbietet, gilt es daher: “Nutze die gesamte Cloud eines Anbieters und verlasse Dich nicht nur auf einen einzigen Anbieter!”

Durch die Verteilung einer Anwendung über mehrere Regionen und Availability Zones bei einem Anbieter wird die Verfügbarkeit der Anwendung drastisch erhöht. Zudem ist eine MultiVendor Strategie zwingend erforderlich. Außerdem müssen bereits von Beginn an Fallback Szenarien entwickelt werden, um gegen einen plötzlichen Ausfall vorbereitet zu sein.

Es geht also bspw. darum, Systeme aufzubauen, die im Fehlerfall automatisch eine gespiegelte Infrastruktur bei einem anderen Anbieter aufbauen. Besser wäre es, mehrere Anbieter parallel zu nutzen und die Services über mehrere Anbieter hinweg zu verteilen. Dazu gehört z.B.: Instanzen von unterschiedlichen Anbietern parallel produktiv einzusetzen, um damit das Risiko zu streuen.

Denn: Cloud Computing löst nicht alle Probleme automatisch…

Für die Zukunft

Amazon darf auf keinen Fall von einer Schuld freigesprochen werden, dazu werben sie viel zu deutlich mit der eigenen Verfügbarkeit. Dennoch, beim Cloud Computing handelt es sich um bedeutend mehr als nur das Nutzen von ein paar virtuellen Ressourcen und jeder Nutzer der Cloud ist für die Verfügbarkeit seiner Anwendung selber verantwortlich. Dafür stehen ihm ausreichend Mittel und Wege auf Grund der Cloud zur Verfügung!