“The Truth Is In The Cloud.” So postulierte es Steve Jobs anlässlich der WWDC 2011 und erntete dafür nicht nur Zustimmung. Tatsächlich muss man sich fragen, ob die ominöse Cloud wahrhaftig so ein guter Ort für geschäftskritische Anwendungen ist. Zum dritten Mal innerhalb weniger Monate brach am gestrigen Abend deutscher Zeit ein Teil der Amazon Web Services zusammen und sorgte für stundenlange Störungen und Ausfälle bei Dutzenden von populären und weniger bekannten Services.
Erneut steht Amazon mit seinen AWS (Amazon Web Services) massiv in der Kritik. Erst im Juni sorgte ein wetterbedingter Ausfall in einem der Datacenter dafür, dass reichweitenstarke Dienste wie Pinterest, Netflix und Instagram über ein komplettes Wochenende unerreichbar waren. Es handelte sich um den zweiten Störfall innerhalb eines Monats. Konnte man Ende Juni noch einen heftigen Sturm als Verursacher ausmachen, ist bislang unklar, womit der gestrige Ausfall zu begründen lässt.
Amazon AWS: Viele Ausfälle und verschleiernde Kommunikation
Auch wenn Amazon in seinem “Service Health Dashboard” stets beschwichtigend mit grüner Symbolik arbeitete und lediglich von “degraded performance” und “issues in a single Availability Zone” sprach, was lediglich leichte Störungen und nicht ganz so rasante Datenraten impliziert, berichteten etliche Betreiber, die sich auf AWS und vor allem auf Amazons EC2 (Elastic Compute Cloud) verlassen, von ganz anderen Ausmaßen. Demnach konnte von Einzelfällen nicht die Rede sein, schnell füllten sich die Kommentarbereiche der großen amerikanischen Tech-Medien mit Statements á la “We are also down.”
Neue Stellenangebote
|
Growth Marketing Manager:in – Social Media GOhiring GmbH in Homeoffice |
|
|
Social Media und PR Specialist (m/w/d) BeA GmbH in Ahrensburg |
|
|
Social Media Manager B2B (m/w/d) WM SE in Osnabrück |
Die Elastic Compute Cloud ist Amazons Angebot skalierbarer Rechenleistung für Anwendungen in der Cloud. Anstelle des Aufbaus eigener Rechnerkapazitäten über eigene Serverfarmen können Dienstbetreiber bei Amazon diese Leistungen einkaufen, verbunden mit dem theoretischen Vorteil, bei steigender Last nahezu unbegrenzt skalieren zu können. Man müsste also nicht selber weitere Server aufstellen, um gestiegenem Traffic Rechnung zu tragen, sondern lediglich ein größeres EC2-Kontingent kaufen. Kein Wunder, dass insbesondere Startups diesen Weg wählen, lässt sich das finanzielle Risiko und der eigene Administrationsaufwand so doch auf einem vergleichsweise niedrigen Level halten. Neben den EC2-Diensten waren zusätzlich verschiedene Datenbank-Dienste betroffen, insbesondere die Relational Database Services, was vermutlich im Mix mit Schwierigkeiten im AWS EB (Elastic Beanstalk) zu den gravierenden Ausfällen führen konnte.
Konkret betroffen waren Größen wie Pinterest, Foursquare, Skitch, Reddit, FastCompany, sowie die Salesforce-Plattform Heroku ebenso wie Airbnb, Github, Coursera und das Multiplayer-Game Minecraft. Ich persönlich vermisste während der Auszeit vor allem FlipBoard und musste mich mit massiven Performance-Problemen bei Wunderlist und Zite arrangieren. Dutzende weiterer Dienste, darunter vor allem kleinere Startups und eher lokal agierende Unternehmen, waren unerreichbar.
Amazon AWS: Wurde der Ausfall durch einen Hacker-Angriff verursacht?
Ein angebliches Anonymous-Mitglied (Anonymous Own3r) behauptet via Twitter, für die Ausfälle verantwortlich zu sein, will aber keinen Grund nennen. Amazon weist diese Darstellung zurück, gibt jedoch bislang keine plausible eigene Erklärung zu den Vorfällen ab.
Auch am heutigen Morgen scheinen längst nicht alle Probleme behoben. Das Service Health Dashboard zeigt nach wie vor Störungen in den bereits am gestrigen Abend betroffenen Bereichen. Zumindest scheint das Ausmaß etwas geringer geworden zu sein, die genannten großen Services sind alle wieder erreichbar.
Amazon AWS: Warum wirken sich Ausfälle einzelner Services so stark aus?
Wieso nimmt ein Ausfall der AWS immer das halbe Internet mit? Diese Frage stellen sich viele Internetsurfer. Und: Was ist das denn für eine Cloud, die jedes Mal zusammenbricht, wenn ein punktuelles Problem auftritt?
Die Antwort auf beide Fragen ist relativ einfach, wenn man sich klar macht, dass die Elastic Compute Cloud wesentliche Grundlage der meisten betroffenen Services ist. Denn die Elastic Compute Cloud wird weltweit nur in vier Datacenters gehostet. Europa wird über Dublin bedient, der gesamte asiatische Raum über Singapur, die amerikanische Westküste über Palo Alto in Kalifornien und die amerikanische Ostküste über Ashburn in Virginia.
Ausfallgefährdet scheint insbesondere das letztgenannte Center in Ashburn zu sein. Alle großen Ausfälle der letzten 16 Monate gingen von dort aus. Worauf das zurück zu führen ist, kann letztlich allein Amazon beantworten. Unter technischen Gesichtspunkten sind viele Ansätze denkbar, natürlich auch strukturelle Mängel in Konzeption und Betrieb. Hierüber ließe sich indes nur spekulieren. Fakt ist, dass Ashburn mit 9 großen Datacenters quasi ein Ballungsgebiet der Branche darstellt und so einen der größten Knotenpunkte der Vereinigten Staaten bildet.
Wie kann man sich gegen einen Ausfall der eigenen Dienste sichern?
Übrigens: In solchen Fällen wird gern den betroffenen Kunden der schwarze Peter zugeschoben. Diese seien selber schuld, wenn sie sich auf eine einzige Availability Zone verließen, man müsse seine Services schon über mehrere dieser Zonen, möglichst über mehrere Datacenters verteilen. Der Rat ist korrekt und entspricht auch dem, was Amazon seinen Kunden empfiehlt. Und viele tun das auch. Allerdings nutzt die Vorgehensweise überhaupt nichts, wenn – wie bereits mehrfach, so auch gestern geschehen – die ELB-Services (Elastic Load Balancing) ebenfalls ausfallen. ELB soll nämlich genau die Übergabe an andere Zonen verwalten und im Bedarfsfalle einleiten. Wenn das nicht passiert, nutzt die Redundanz wenig.
Eine sichere Art, seine Services in der Cloud zu betreiben, ist eine mehrfache Redundanz nicht nur über mehrere Datacenter desselben Providers in verschiedenen Regionen, sondern eine redundante Struktur über mehrere Cloud-Provider. Wenn man dann allerdings wieder sieht, dass sich mancherorts – etwa in Dublin – Datacenter an Datacenter reiht, und wenn man dann einmal schaut, was dadurch so alles passieren kann…
Weitere Links zum Thema:
- Amazon Cloud Service Goes Down and Takes Popular Sites With It – Bits / NYT
- Amazon cloud outage takes down Reddit, Airbnb, Flipboard, Coursera, & more – VentureBeat
- Amazon’s EC2 sees partial outage, taking Reddit, Minecraft, Coursera, Flipboard and others down in tow – The Next Web
- Reddit, Flipboard, ‚Minecraft,‘ and others taken out by another Amazon Web Services outage – The Verge
- Amazon’s Cloud Is Down Again, Taking Heroku and GitHub With It – AllThingsD
(Dieter Petereit)
Ich hätte nicht gedacht, dass dieses Thema der erste Amazon-Artikel des heutigen Tages sein wird. Da steht ja auch noch die E-Book-Geschichte an. 😉
Habe den Ausfall gestern auch bemerkt, als ich auf Heroku aktiv war. Alles schnarchlangsam.
Pirate Bay machts ja aktuell richtig, in dem sie in die Cloud auf mehrere unabhängige Cloudprovider ziehen und dort gehosted werden. Schafft Redundanz nicht nur gegen Serverausfälle. 😉
Schöner Text, doch ein wenig lang…
Guter Text, schließe mich aber Alex an – ein wenig zu lang.
yay drei autoren und nur ein beitrag am Tag….
Finde den Text nicht lang, im Gegenteil sind gute Analysen und Berichte heute selten. Eher weiter so. 🙂
Ich hab diese ganze Cloudmanie noch nie verstanden. Mehrfach hab ich das Thema evaluiert und mich immer für dedicated statt Cloud entschieden. Entweder machen die verdammt gutes Marketing oder ein Gros der Startup CTO’s sind einfach nur unfähig:
1) Cloudservices sind bei gleicher Leistung nicht billiger als dedicated. Wer was anderes behauptend hat sich einfach nicht ausreichend mit dem Thema beschäftigt.
2) Cloudservices sind unzuverlässiger als vernünftig laodbalancte eigene root server (verteilt auf 2 oder mehr datacenter)
3) Gerade bei vielen I/O Vorgängen, sei es nun in App-Servern oder in DB Servern hat man in der Cloud -egal was die einem erzählen- keine dedizierten Ressourcen. Wenn ein anderen Kunde Lastspitzen fährt, leidet die eigene Performance.
4) Skalierbarkeit – das ist das einzige Argument, was für die Cloud spricht. Man kann dort tatsächlich schneller Ressourcen zuschalten, als bei dedicated. Die Frage ist jedoch ob man das wirklich imemr so kurzfristig bracht – ein guter hoster schaltet dir nen dedicated Server innerhalb von 8 Stunden frei. Für ein tüpisches „stetiges“ Wachstum im Startupbereich reicht das vollkommen. Wenn es um Belastungsspitzen geht – man also hoch und runterskalieren will/muss (zb weil man nur am WE viel traffic hat) dann alleine macht das Modell aus meiern Sicht Sinn. Aber bei wem ist das shcon so? Die allermeisten Startups haben tatsächlich eher ausgeglichene Belastungskurven.
Fazit: Für die allermeisten Startups ist Cloud Mist > Holt euch einen guten Admin (der nebenbei auch noch andere Dinge mitmachen kann) und 2 mal dedicated server verteilt auf 2 RZ, macht ein DNS failover LB und gut is.
Guten Tag Herr Petereit,
mal Hand aufs Herz stellen sie sich vor, in einer Autowerkstat würde jedes Werkzeug minutenweise aus einer anderen Firme besorgt werden. Ja manchmal macht das Sinn – aber gleich für jedes Hämmerchen? Schon erstaunlich welchen Software-Zoo Sie vermissen oder (denken) diesen zu brauchen – arbeiten Sie etwa auch noch?
Ihr Unbekannter
Hallo Unbekannter!
Stellen Sie sich mal vor, in für Sie erreichbarer Nähe gäbe es nur einen einzigen Einzelhändler, bei dem Sie sich täglich versorgen, weil er alles führt, was Sie benötigen. Früher, da gab es noch zwei Händler in der Nähe, aber weil sich alle Kunden auf den einen, der alles hat, verlagert haben, wurden die schon vor längerer Zeit geschlossen. Plötzlich schließt dieser Einzelhändler. Was tun Sie jetzt?
Stellen Sie sich mal vor, Sie sind selbständig und haben einen einzigen großen Kunden, der auch umsatzmäßig völlig ausreichend ist. Sie leben prima davon. Früher hatten Sie viele Kunden, aber die umfangreiche Zusammenarbeit mit dem einen Großen hat Sie den anderen gegenüber nachlässig werden lassen. Sie sind abgesprungen. Plötzlich schließt Ihr Großkunde? Was tun Sie jetzt?
Angebotsvielfalt, Risikominimierung, Diversifizierung – alles Begriffe, die ich nicht mit Zoo assoziieren würde. Und ja, das ist Arbeit.
Gruß
D. Petereit
Nun ja, gerade die Angebotsvielfalt ist im Netz wohl Rückläufig und eine Risikominimierung wäre wohl nicht allein auf die Cloud zu setzen oder gar auf einen Server Anbieter wenn die Daten so wichtig sind auch ein Backup bei einen 2. in Betracht ziehen.
Annsonsten würde ich es teilweise schon als Internet „Software-Zoo“ bezeichnen, niemand weiss ob eine Firma oder Dienstleistung dort morgen noch Existiert. Von eventuellen Schadenersatzklagen wohl ganz zu Schweigen bei zig verschiedenen Rechtssprechungen auf der Welt.
Lieber Herr Petereit,
ich nehme Ihnen übel nicht bereits vor 2 Jahren bei BT begonnen zu haben.