Amazon S3 Ausfall 28.02.2017

- Erstellt in DevOps

enter image description here

Am 28.02 kurz nach 18:30 Schweizer Zeit ist der Simple Storage Service S3 von Amazon AWS an der US-Ostküste für knapp 3 Stunden ausgefallen. Ein kleiner Ausfall eines Services wäre an sich kein Problem, 3 Stunden Ausfall pro Jahr bedeuten auch dann noch eine Verfügbarkeit von über 99.96% und ist eine sehr gute Gesamtverfügbarkeit — besser als die unserer Kunden, welche Ihre Services selber hosten. In der Schweiz war der Ausfall kurz nach den Bürozeiten, in den USA war der Ausfall jedoch kurz vor dem Mittag und dadurch stark auch im Business spürbar.

Das Problem war, dass viele, darunter auch grosse prominente Webapplikationen, aus Kostengründen ihre Daten nicht redundant, also mehrfach in verschiedenen Regionen bei Amazon oder anderen Cloud Service Providern, gespeichert hatten. Dazu kam der Zufall gemäss Murphy dass die "us-east-1" Region jeweils die erste, bereits ausgewählte, Option beim Erstellen eines neuen Services ist und vermutlich auch darum sehr viele Kunden von Amazon (und auch von VSHN) den Service aus dieser Region beziehen.

Bekannte Namen, die vom Ausfall betroffen waren: Docker Hub, Trello, Travis CI, GitHub.com und GitLab.com, Quora, Medium, Signal, Slack, Imgur, Twitch.tv, Razer, Adobes Cloud Services, Zendesk, Heroku, Coursera, Bitbucket, Autodesk Cloud Services, Twilio, Mailchimp, Citrix, Expedia, Flipboard, Salesforce, Giphy, Nest und ironischerweise, die Service-Status-Webseite von Amazon selbst, die erst eine gute Stunde nach dem Ausfall des Services angepasst werden konnte.

Die Situation normalisierte sich gegen 22:00 Uhr und ab ca. 23:00 Uhr waren auch die letzten Probleme behoben.

Wie kann man einen solchen Ausfall für seine Webapplikation verhindern?

Um auch das letzte Quäntchen Verfügbarkeit aus der Applikation zu holen, gibt es, wie immer in den Ingenieurwissenschaften, verschiedene Möglichkeiten, in aufsteigender Kostenreihenfolge:

  1. Statische Assets die in S3 liegen, per Content Delivery Network (CDN) ausliefern: machen die Meisten vermutlich bereits. Das CDN speichert die bereits häufig angefragten Daten und kann so kurze Ausfälle des darunter liegenden Speichersystems (egal ob S3 oder ein anderes) überbrücken. Leider nützt das nichts für gerade neu erstellte oder hochgeladene Daten; immerhin läuft die Webseite mit den "alten Daten" weiter. Die anderen Vorteile eines CDN (schnellere, weil nähere Auslieferung zum Nutzer, DDoS-Schutz, möglicherweise tiefere Bandbreiten/Traffic-Preise, etc.) gelten natürlich ebenfalls und macht für die meisten Seiten mit globalem Nutzerkreis Sinn.

  2. Redundante Speicherung: Alle Schreib- und Löschoperationen (am besten mittels Queue) in zwei unterschiedliche Speicherservices ausführen, zumindest in unterschiedliche AWS-Regionen oder zu einem anderen Cloud Service Provider, der einen S3-kompatiblen Service anbietet. Beim Zugriff (am besten via CDN zur Zwischenspeicherung, siehe oben) probiert die Applikation wahlweise den einen oder anderen Speicher zu erreichen und liefert die Daten, egal von welchem Storagebackend, an das CDN weiter. Der Nachteil ist neben der zusätzlichen Applikationslogik, die implementiert und gewartet werden muss, natürlich die doppelten Kosten für die Speicherung an zwei Orten.

  3. Ebenfalls sollte dann die Applikation selbst (und ihre anderen Backends wie Datenbanken etc.) an zwei Orten laufen und parallel aktiv-aktiv betrieben werden, um die Gesamtverfügbarkeit nicht zu beeinträchtigen. Auch dafür entstehen Kosten und die Komplexität des Load-balancing über zwei Regionen oder Cloud Service Provider ist nicht zu unterschätzen.

VSHN ist der Schweizer Experte für den sicheren Betrieb von Webapplikationen in den internationalen wie auch den Schweizer Cloud Service Providern. Wir beraten nicht nur, sondern helfen auch gerne dabei, solche Konzepte umzusetzen.

Nachtrag 3. März 2017:

Unterdessen wurde die offizielle Erklärung der Vorkommnisse veröffentlicht:

Die Ursache war ein manueller Fehler: beim routinemässigen Entfernen von alten Servern aus dem System hat sich um 18:37 Schweizer Zeit ein Amazon-Mitarbeiter vertippt und aus Versehen auch eine kritische Gruppe von Servern für den internen S3-Metadaten-Dienst und den S3-Allozier-Dienst gelöscht. Daten sind dabei keine verloren gegangen. Das Hochfahren des Metadaten-Dienstes und die Prüfung der Datenintegrität dauerte länger als geplant, ab 21:26 konnten die ersten Lese-Anfragen wieder abgearbeitet werden und ab 22:18 waren die Lesezugriffe komplett wiederhergestellt. Der S3-Allozier-Dienst, der für Schreibzugriffe benötigt wird, wurde anschliessend wieder hergestellt und war ab 22:54 wieder vollständig verfügbar.

Fehler passieren - an dieser Stelle ein Kompliment an AWS für die professionell verfasste und transparente Zusammenfassung der Ereignisse und der daraus gezogenen Massnahmen ! Diese sogenannten "Postmortems" helfen uns allen aus diesen Erfahrungen zu lernen und uns als Industrie weiter zu entwickeln.

Tags:
---