Eine kurze Einblendung der Adresse reichte.

Ein Fernsehbericht steht an, innerhalb weniger Tage muss eine skalierende Infrastruktur bereit stehen die mehrere tausend Menschen für ein paar Stunden abfängt und dies möglichst kostengünstig. In den nächsten paar Zeilen will ich versuchen zu beschreiben wie die Vorbereitungen verliefen und was geschah als mehrere tausend Menschen versuchten Deutschlands erste Klosuchmaschine – lootogo.de – an zu surfen.
01. Oktober 2009, Donnerstag
Das Handy klingelt eine Redakteur der RTL Extra Redaktion ist am anderen Ende der Leitung, er will Informationen über Restaurant-Toiletten und später wird ein Interview Termin vereinbart. Übernächsten Montag, den 12. Oktober soll der Beitrag bereits laufen.

03. Oktober 2009, Samstag
In einem ersten kurzen Treffen mit Philipp Strube und Tobias Wilken von cloudControl werden Details über die Software geklärt. Für einen Einsatz der cloudControl-Technologie ist es leider noch zu früh, wir entschieden uns daher für den Amazon Webservice mit Instanzen in Europa. Tobias meinte zudem das ich die Time-to-Life Einträge im DNS auf eine kurze Zeitspanne stelle solle, damit wir bei der Umstellung auf die Amazon Instanzen keine Probleme kriegen.

10. Oktober 2009, Samstag
In einem kurzen Lasttest versuchten wir Schwachstellen in der Software ausfindig zu machen, hierbei konnten wir erhebliche Verbesserungen bei der Datenbank durchführen. Nach Stunden des experimentieren, entschieden wir uns zum Schluss für eine Kombination aus Cache-Servern und dem bisherigen Server als Backend, vor die Cache-Server schalteten wir den Elastic Load Balancing Service von Amazon. Dieser ermöglichte es uns beliebig viele Cache-Server vor den Backend-Server zu schalten um den Ansturm abzufangen.
Unsere geplante Infrastruktur sah nun wie folgt aus:

geplante Infrastruktur

11. Oktober 2009, Sonntag
Wir bereiteten alle Instanzen vor, danach stellen wir die DNS-Einträge auf den IP-Elaested Service von Amazon, mittels eines Cname-DNS Eintrags, um. Dieser zeigte innerhalb weniger Minuten Wirkung, da wir am vergangenden Samstag die Time-to-Life auf 600 Sekunden gestellt hatten.

12. Oktober 2009, Montag 20:00
Philipp wollte lieber das wir den bisherigen Backend-Server durch eine Large-Instanz bei Amazon ersetzten, da der bisherige vServer bei den Lasttests schon gut zu kämpfen hatte. Dies war innerhalb von 60 Minuten erledigt, da hierfür nur die PHP-Scripte und die Datenbank überspielt werden mussten.Unsere laufende Infrastruktur sah um 21:05 wie folgt aus:

Infrastruktur vor dem Beitrag

22:15
Die Sendung begann, mit voller Spannung warteten wir auf den Beitrag. Philipp und Tobias beobachten mit voller Anspannung unseren Cache-Server und Backend-Server.

22:43
Der Beitrag kam, ein kurzes Statements meinerseits über Restaurant-Toiletten und eine kurze Einblendung der Internetadresse. CPU- und RAM-Auslastung waren vollkommen in grünen Bereich, dennoch merkten wir das einige Requests verschluckt wurden. Philipp startet daraufhin vorsichtshalber 7 weitere Cache-Server, Tobias arbeitet diese manuell in den  IP-Elaested Service ein. Nach ca. 5 Minuten konnten wir jeden Request annehmen. In der Zeit von 22:30 bis 23:00 hatten wir durchschnittlich 5.000 Requests in der Minute.

Page Impression am 12. Oktober auf lootogo.de

Infrastruktur kurz nach dem Beitrag

23:43
Der größte Ansturm war vorüber, wir konnten 6 von 8 Cache-Servern abschalten.
Über die Nacht bis zum nächsten Nachmittag ließen wir 2 Cache-Server und den Backend-Server laufen.

13. Oktober 2009
Am Nachmittag überspielten wir die neuere Datenbank vom dem Backend-Server auf den alten vServer und stellen die DNS-Einträge wieder um.

Seitenzugriffe auf lootogo.de

Fazit:
Mit viel Vorbereitungszeit und Steuerung während des Beitrags, konnten wir den Ansturm halbwegs abfangen. Dadurch, dass wir skalieren konnten, war es den Besuchern möglich insgesamt 365 neue Toiletten und 853 neue Bewertungen dem System hinzuzufügen. Der virale Effekt zieht bis heute noch Besucher auf die Seite. In der Zeit in der lootogo.de bei Amazon gehostet wurde enstanden 370MB Incoming-Traffic und 1.600MB Outgoing-Traffic, die Kosten beliefen sich mit den Instanzen, Traffic und dem Elastic Load Balancing Service auf 17$. Insgesamt wurden ca. 93,5 Stunden für die Vor- und Nachbereitungen investiert. Für den nächsten zu erwartenden Ansturm ist Amazon sicherlich eine gute Wahl, dennoch ist viel Know-Now und Zeit nötig um erst einmal eine laufende Infrastruktur zu haben.

Was natürlich niemanden davon abhält Untersuchungen an- und Vermutung aufzustellen.

Amazon EC2 erlaubt es Kunden stundenweise virtuelle Instanzen zu mieten. Soweit so kurz zur Einführung. Diese Instanzen bekommen einzigartige IDs zugewiesen. Guy Rosen ist bei den IDs die er zugewiesen bekommen hat ein Schema aufgefallen. Neugierig hat er daraufhin ein paar Versuche gestartet und kam dabei zu dem Ergebnis, dass Amazon in einer Verfügbarkeitszone an einem Tag im September 2009 50.000 neue Instanzen gespawnt hat.

Insgesamt müsste Amazon seit dem EC2 Start 8.4 Millionen Instanzen gestartet haben.

Beeindruckende Zahlen. Alle Details, wie Guy auf die Zahlen gekommen ist finden sich in seinem Blog:

Anatomy of an Amazon EC2 Resource ID

Bildquelle: Amazon

Einmalpasswörter versprechen Sicherheit durch die Kombination zweier bekannter Eingaben, nämlich Benutzername und Passwort und einer Dritten Zeichenfolge, dem Einmalpasswort. Dieses Einmalpasswort ändert sich in gewissen Zeitabständen und ist wenn nichts schief läuft nicht vorraussagbar. Normalerweise wird das Einmalpasswort auf einem kleinen Gerät angezeigt, von diesem kann man es dann ablesen und mit Benutzername und Passwort eingeben.

Ein solches Verfahren hat Amazon jetzt für die Amazon Web Services eingeführt. Auf diese Weise soll unberechtiger Zugriff auf die AWS Konsole erschwert werden.

Um das Verfahren einzusetzen muss man zuerst das Gerät kaufen, und dann in der Konsole freischalten. Mehr Informationen hat das Amazon Web Services Blog.

Wie sich das für ein Techieblog gehört, beginne ich natürlich bei 0 zu zählen.

Was Programmierer über Caching wissen sollten (Teil 1)

Sky’s the limit (Wortspiel)

Google Axes Mashup Editor to Focus on Cloud Computing Infrastructure (Abgehackt)

Wer weitere Links kennt die hier nicht helfen dürfen ist herzlich eingeladen mich zu kontaktieren.

Der Dienst machte dabei lange Zeit vor allem durch seine fast zur Regel werdenden Ausfälle von sich reden. Auf aussenstehende fast witzig wirkende Anekdoten wie “Is Twitter down?” sind dabei für das betroffene Startup ein wirkliches Problem.

Obwohl die Ausfälle mitlerweile nicht mehr zur Tagesordnung gehören wird dieses Thema zur Zeit trotzdem wieder aktuell, weil Twitter neben den Phishingversuchen, bedingt durch die Unart jedem Drittanbieterdienst den eigenen Benutzernamen und das eigene Passwort aushändigen zu müssen damit dieser die API nutzen kann, am vergangenen Wochenende noch ein weiteres Problem hatte. Die Accounts verschiedener Prominenter wurden übernommen und für SPAM- und Fakenachrichten (hier mit Screenshots) verwendet. Dies geschah laut Twitter mit Hilfe der twittereigenen Supporttools die dazu verwendet werden Nutzern bei Problemen mit ihrem Accounts zu helfen.

Beides sind, auch wenn ich keine Einzelheiten kenne, Probleme die offensichtlich von Twitter selbst hätten behoben werden können. Software hat Lücken, ohne Frage. Aber angesichts der mitlerweilen starken Verbreitung von Twitter hätte man erwarten sollen, solche zentralen Softwareteile wie Authentifizierung und Verwaltungsbackend hätten die benötigte Aufmerksamkeit erhalten.

Vielleicht bedingt durch die ständigen Performanceprobleme konnte man bei Twitter diese Aufmerksamkeit aber nicht aufbringen. Das Resultat sind zwei überaus unerfreuliche Ereignisse, die vor allem in Kreisen der gut informierten und hervorragend vernetzen Twitteruser schnell für schlechte Stimmung gesorgt haben. Also genau was man als Startup eigentlich nicht will. Die eigenen Nutzer verärgern.

Dieses Beispiel zeigt meiner Meinung nach relativ deutlich, wo bei jedem Startup die Prioritäten liegen sollten. Das eigene Produkt muss oberste Priorität geniessen. Die Infrastruktur ist lediglich Mittel zum Zweck und die Verwaltung derselben darf nicht von den Kernkompetenzen ablenken.

Das übliche Problem, es fehlt das Geld also fängt man klein an und wenn der Erfolg sich einstellt skaliert man horizontal und wirft mehr Hardware auf das Problem. Dadurch bedingt hat man irgendwann eine mittelgroße bis große Anzahl an Servern womöglich noch unterschiedlicher Bauart. Der mit der Administration dieser Serverfarm verbundene Aufwand kann dadurch immens werden. Wenn man dann nicht mit Unsummen an Risikokapital ausgestattet ist, worauf sich in Anbetracht der momentanen Weltwirtschaftslage wohl die meisten Startups einstellen müssen, und sich Arbeitskräfte für die Administration der Server leisten kann wird die Aufgaben nebenher bewältigen müssen.

Das Problem ist dabei ganz einfach, dass die verbreiteten Hostingangebote wie shared Hosting, V-Server und dedizierte Server nicht genug Flexibilität bieten um den Anforderungen eines dynamischen Startups gerecht zu werden. Cloud Computing Plattformen können hier Abhilfe schaffen. Webhosting muss endlich auch im Web2.0 ankommen und flexibler und günstiger werden. Das geht aber nur wenn die Hostingdienstleister die Synnergieeffekte im Form von Preisvorteilen an die Kunden weitergeben.

Schön und überaus passend finde ich in dem Zusammenhang die Aussage von Amazon Chef Jeff Bezos. Der in einer Präsentation zu Amazon EC2 dieses mit Elektrizität verglich. Es würde ja auch niemand mehr seine eigene Elektrizität herstellen. Gleiches muss auch für Rechenleistung gelten.

Das größte Problem bei EC2 Instanzen bisher bestand darin, dass es keine Datenpersistenz gab. Das bedeutet, alle während der Laufzeit einer Instanz geänderten Daten die auf die Festplatte dieser Instanz geschrieben wurden waren verloren wenn die Instanz beendet wurde.

Wie jedem sofort einleuchten wird, ist dies natürlich ein großes Problem, wenn sich eine Maschine auf Grund irgendeines Fehlers während der Laufzeit verabschiedet. Normale Server fährt man wieder hoch und dank der Innovation bei den Journaling-Dateisystemen der letzten zehn Jahre kommt es nur sehr selten zu Datenverlusten. EC2 Instanzen hingegen kann man nicht wieder hoch fahren. Das Prinzip der Wolke ist ja gerade, dass man nur virtuelle Maschinen hat. Es kann einem also egal sein auf welcher physischen Hardware man tatsächlich landet. Weil nach mir höchstwahrscheinlich jemand anderes auf der Maschine landet, ist es sogar in meinem Interesse, dass die Daten nicht auf der Platte bleiben.

Nun stellte die fehlende Persistenz Unternehmen vor 2 Probleme. Das eine Problem ist noch relativ leicht zu verkraften. Während der Laufzeit installierte Software, Sicherheitsupdates oder Konfigurationsänderungen wurden eben auch nicht übernommen. Jedesmal wenn das Image neu gestartet wurde hatte es wieder genau den Stand in dem man es bei S3 abgelegt hatte. Was im übrigen auch Vorteile hat. Man startet dadurch jede neue Instanz in einem genau vorhersehbaren Zustand. Lösungen für dieses Problem gab es zwei, entweder man lud nach seinen Änderungen jedesmal ein neues Image auf den S3 Speicherdienst hoch oder man speicherte die Änderung in kleinen inkrementellen Archiven ab. Diese wurden dann nach dem Start des Image nacheinander eingespielt und enthielten die nötigen Änderungen.

Wirklich problematisch ist, bzw. jetzt war, die fehlende Persistenz bei Datenbankservern. Wenn man nämlich seine komplette Infrastruktur innerhalb von Amazons EC2 betreiben wollte, hatte man immer das Problem, dass man seine Datenbankserver redundant und am besten nochmal irgendwo ausserhalb von EC2 vorhalten musste. Sonst wären nämlich alle Daten in der Datenbank seit dem letzten Backup beim beenden der Instanz verloren gewesen. Sobald eine Webapplikation die Datenbank aber ein bisschen intensiver nutzt als das 0815 Katzencontentblog sind häufige Backups ein echtes Problem.

EBS zur Rettung

EBS steht für Elastic Block Store und ist quasi eine Festplattenwolke. EBS ist ein Blockspeicher, der von jeder EC2 Instanz aus gemountet werden kann. Daten die auf EBS gespeichert sind, sind somit auch von jeder EC2 Instanz aus zu erreichen.

Details wie das ganze technisch umgesetzt ist und wie das ganze genutzt werden kann werde ich in Kürze nachliefern. Dazu möchte ich mir zwecks Recherche ein weniger mehr Zeit nehmen. Jetzt nur so viel, bereits der erste Blick auf die Möglichkeiten von EBS hat mir ein Lächeln ins Gesicht getrieben.

Abgerechnet wird EBS jedenfalls wie alle Amazon Web Services nach tatsächlicher Nutzung.

Ausblick

Mir persönlich fällt damit nur noch ein wirklicher Kritikpunkt bezüglich der Amazon Web Services ein. Es gibt keine SLAs (Service Level Agreements). D.h. Amazon garantiert nicht, dass man innerhalb einer bestimmten Zeit neue Maschinen bekommt. Sei es weil die eine ausgefallen oder man wegen eines Lastanstiegs mehr braucht.

Wer also sehr knapp kalkuliert und das werden junge Startups und Hobbyadmins, die EC2 als Ersatz für einen einzelnen Dedicated Server nutzen möchten, tun, hat ein Problem. Sobald man eine größere Anzahl EC2 Maschinen gleichzeitig nutzt spielt das ganze eine untergeordnete Rolle. Ob jetzt von meinen 3000 Instanzen 3 ausgefallen sind und ich die nächsten Stunden mit 2997 auskommen muss sollte den meisten Admins keine wirklichen Kopfschmerzen bereiten.

Fazit

Alles in allem ist EBS genau der Service der den Amazon Web Services noch gefehlt hat. Genau wie Markus auf Netzwertig.com bin auch ich hellauf begeistert von dieser Neuigkeit. Markus kreidet noch an, dass ein einfaches Benutzerinterface bisher fehlt. Aber wie er auch direkt prognostiziert werden wir da in Zukunft sicher noch einiges sehen. Wenn es nach mir geht in sehr naher Zukunft! Aber mehr kann ich dazu, zum jetzigen Zeitpunkt noch nicht verraten.