Gestern war es dann wieder einmal soweit. Amazon hatte erneut mit einem schweren Ausfall in seiner Region US-East-1 zu kämpfen und zog direkt die üblichen Verdächtigen Reddit, Foursquare, Heroku und Co. mit. Dabei handelt es sich bereits um den fünften signifikanten Ausfall in den letzten 18 Monaten in dieser Region. Nach April 2011, März 2012 sowie dem 15. und 30. Juni 2012 plus vier weitere Ausfälle innerhalb nur einer Woche im Jahr 2010, nun der nächste Ausfall.

Die Hintergründe des AWS Ausfall

Die Region US-East-1 ist die älteste aller AWS Regionen. Dabei handelt es sich um das Rechenzentrum in Virginia, das erst vor kurzer Zeit wegen schwerer Gewitter in die Schlagzeilen geraten war. Letzte Woche hatte ich noch geschrieben, dass neue Public Cloud Anbieter zwar mittlerweile über aktuellere Technologien verfügen, es für Amazon auf Grund der losen Kopplung sämtlicher Services aber leicht fallen sollte, einen Austausch vorzunehmen. Es scheint, dass der Zeitpunkt mehr als überschritten ist. Das Grab US-East-1 ist größer als vermutet.

Was ist passiert?

Was genau passiert ist, kann der AWS Statusseite zu Beginn verständlicherweise nicht immer direkt entnommen werden. In der Regel wird ein paar Tage nach dem Ausfall ein ausführlicher Blogpost mit ein paar Details veröffentlicht.

Aus den Statusmeldungen lässt sich nur entnehmen, dass es wieder Performanceprobleme “mit einer kleinen Anzahl von EBS Volumes (Elastic Block Store)” gibt.

10:38 AM PDT We are currently investigating degraded performance for a small number of EBS volumes in a single Availability Zone in the US-EAST-1 Region.
11:11 AM PDT We can confirm degraded performance for a small number of EBS volumes in a single Availability Zone in the US-EAST-1 Region. Instances using affected EBS volumes will also experience degraded performance.
11:26 AM PDT We are currently experiencing degraded performance for EBS volumes in a single Availability Zone in the US-EAST-1 Region. New launches for EBS backed instances are failing and instances using affected EBS volumes will experience degraded performance.

12:32 PM PDT We are working on recovering the impacted EBS volumes in a single Availability Zone in the US-EAST-1 Region.
1:02 PM PDT We continue to work to resolve the issue affecting EBS volumes in a single availability zone in the US-EAST-1 region. The AWS Management Console for EC2 indicates which availability zone is impaired.EC2 instances and EBS volumes outside of this availability zone are operating normally. Customers can launch replacement instances in the unaffected availability zones but may experience elevated launch latencies or receive ResourceLimitExceeded errors on their API calls, which are being issued to manage load on the system during recovery. Customers receiving this error can retry failed requests.

2:20 PM PDT We’ve now restored performance for about half of the volumes that experienced issues. Instances that were attached to these recovered volumes are recovering. We’re continuing to work on restoring availability and performance for the volumes that are still degraded.

Zudem waren auch “eine kleine Anzahl von RDS Instanzen (Relational Database Service)” betroffen. Hier kam es zu Problemen bei der Verbindung und ebenfalls bei der Performance.

11:03 AM PDT We are currently experiencing connectivity issues and degraded performance for a small number of RDS DB Instances in a single Availability Zone in the US-EAST-1 Region.
11:45 AM PDT A number of Amazon RDS DB Instances in a single Availability Zone in the US-EAST-1 Region are experiencing connectivity issues or degraded performance. New instance create requests in the affected Availability Zone are experiencing elevated latencies. We are investigating the root cause.

Die üblichen Verdächtigen: Reddit, Foursquare, Heroku und Co.

Interessant ist, dass immer die üblichen Verdächtigen u.a. Reddit, Heroku und Foursquare von einem Ausfall der US-East-1 Region betroffen sind. Das bedeutet im Umkehrschluss, dass alle Beteiligten nicht aus den eigenen Fehlern vorheriger Ausfälle gelernt haben und genau so weitermachen wie zuvor. Das “Schöne” an solchen Ausfällen ist, dass man einen schönen öffentlichen Rundumblick auf die Robustheit der jeweiligen Angebote der Anbieter erhält, die ihre Anwendungen auf den Amazon Web Services laufen lassen. Auch Instagram, dass bekannterweise für 1 Milliarde Dollar an Facebook verkaufte wurde, war bei einem der letzten Ausfälle schwer getroffen. Da scheint die technische Due Diligence Prüfung nicht funktioniert zu haben.

Es stellt sich die Frage, wie lange die Verantwortlichen von Reddit, Foursquare, Heroku (gehört übrigens zu Salesforce) und Co. noch warten, bis etwas an der Architektur geändert wird. Die Systemarchitekten sollten langsam damit beginnen etwas zu ändern. Gute Vorbilder sind Netflix und Okta.

Was ist zu tun?

Das ist im Einzelfall zu entscheiden. Jedoch reicht es zunächst einmal nicht aus, nur eine Region oder eine Availability Zone zu nutzen. Man muss einfach verstehen, dass Cloud Computing viel mehr bedeutet, als nur ein paar Server zu nutzen und miteinander zu verbinden. Es geht um die gesamte Architektur des eigenen Systems bzw. der eigenen Anwendung, die auf der virtuellen Infrastruktur (IaaS) aufgebaut wird. Wie ich schon in einem Artikel für die Computerwoche geschrieben habe:

Viele Unternehmen entwickeln ihre Cloud-Applikation “daheim” in den eigenen vier Wänden. Erst nach der Fertigstellung soll der Rollout auf eine Cloud-Infrastruktur oder Cloud-Plattform erfolgen. Das ist ein Fehler.

Inbesondere IaaS-Umgebungen (Infrastructur as a Service) wie die Amazon Web Services oder Microsoft Windows Azure vermitteln den Eindruck, nur eine Vielzahl von virtuellen Maschine bereitzustellen. Den Rest übernehme die “Cloud automatisch”. Das ist fatalerweise auch der Tenor, der von vielen Medien verbreitet wird und damit ein völlig falscher Eindruck von einer Cloud entsteht.

Eine Cloud-Anwendung ist nur so viel wert wie die Architektur, auf der sie basiert. Eine Anwendung muss direkt für die Cloudentwickelt werden – Skalierbarkeit und Hochverfügbarkeit sind von Beginn an mit zu bedenken. Eine Anwendung sollte eigenständig weitere virtuelle Maschinen hochfahren können, wenn mehr Leistung benötigt wird (Skalierbarkeit) bzw. die nicht mehr benötigten virtuellen Maschinen auch selbstständig wieder herunterfahren. Genauso verhält es sich, wenn eine virtuelle Maschine in einen fehlerhaften Zustand gerät. Auch hier muss die Anwendung selbst dafür sorgen, dass entsprechend eine virtuelle Maschine als Ersatz hochgefahren wird und die defekte Maschine aus dem System verschwindet (Hochverfügbarkeit).

Die Anwendung muss daher in der Lage sein, auf jeder beliebigen virtuellen Maschine (VM) einer Cloud-Infrastruktur zu funktionieren. Das liegt unter anderem daran, dass jederzeit eine VM ausfallen kann und eine andere neu hochgefahren werden muss. Und auch die Daten, auf die eine Anwendung operiert, befinden sich zwangsläufig nicht mehr an einem einzigen Ort, sondern sind über die Cloud verteilt gespeichert.

Mehr…

Für den Fehlerfall vorbereitet sein

Selbstverständlich darf man Amazon von diesem erneuten Ausfall auf keinen Fall freisprechen. Die Region US-EAST-1 in North Virginia scheint das Problemkind zu sein. Dennoch weißt Amazon regelmäßig und vehement darauf hin: “Design for failure!”

Hierfür hat das Unternehmen eine Webseite geschaffen, auf der Whitepapers zum Download bereitstehen, die dabei helfen, fehlertolerante Anwendungen zu entwickeln und Cloud Architekturen zu verstehen. Dazu gehören u.a. die Folgenden.

AWS Cloud Architecture Best Practices Whitepaper

Dieses Whitepaper gibt einen technischen Überblick aller AWS Services und verschiedener Best Practice Ansätze für die architektonische Gestaltung, um damit effiziente und skalierbare Architekturen zu entwerfen.
Link

Building Fault-Tolerant Applications on AWS Whitepaper

In diesem Whitepaper werden Funktionen für die Erhöhung der Fehlertoleranz vorgestellt, die dazu dienen, um hoch zuverlässige und hochverfügbare Anwendungen innerhalb der AWS Cloud zu entwickeln.
Link

Web Hosting Best Practices Whitepaper

Dieses Whitepaper überprüft detailliert Lösungen für das Web Application Hosting. Dazu gehört unter anderem, wie jeder AWS Service genutzt werden kann, um eine hochverfügbare und skalierbare Webanwendung zu entwerfen.
Link

Leveraging Different Storage Options in the AWS Cloud Whitepaper

Dieses Whitepaper dient dazu, einen Überblick über die Speichermöglichkeiten in der AWS Cloud zu geben und darüber hinaus Szenarien vorzustellen, um eine effektive Nutzung zu erzielen.
Link

AWS Security Best Practices Whitepaper

In diesem Whitepaper werden bestimmte Tools, Funktionen und Richtlinien beschrieben, um zu verstehen, wie Cloud Anwendungen innerhalb der AWS Infrastruktur von Grund auf geschützt werden können.
Link

Netflix und sein Chaos Monkey

Ein Grund warum Netflix ein so robustes und hochverfügbares System auf der Amazon Cloud betreibt, ist der selbst entwickelte und sogenannte Chaos Monkey. Der Chaos Monkey hilft Netflix dabei sicherzustellen, dass alle einzelnen Komponenten unabhängig voneinander arbeiten. Dazu zerstört der Chaos Monkey wahllos Instanzen und Services innerhalb der Netflix AWS Infrastruktur, um seinen Entwicklern dabei zu helfen, zu gewährleisten, dass jede einzelne Komponente antwortet, auch wenn die System-Abhängigkeiten nicht einwandfrei funktionieren.

Das gilt für die gesamte Cloud!

Alle genannten Bereiche gelten nicht nur für die Amazon Web Services, sondern ebenfalls für Windows Azure, Rackspace usw. Bevor man in die IaaS-Cloud eines Anbieter geht, sollte man sich vorher damit auseinandersetzen und verstehen, wie die Infrastruktur funktioniert und wie das eigene Systeme daraufhin entwickelt werden muss.