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.
Pingback: Tweets die Erfahrungsbericht – Wenn eine Webapplikation skalieren muss | Server in den Wolken erwähnt -- Topsy.com
In Lesezeichen, sehr schönes und nützliches Erfahrungsbericht, vielen Dank!
Pingback: uberVU - social comments
Ich finde die Kosten überzeugend gering. Mal abgesehen von den investierten Arbeitsstunden, die ihr sicher in dem Umfang nur bei der initialen Einrichtung hattet. Im Normalbetrieb lauft ihr komplett auf einem herkömmlichen Server?
Ja, im Normalbetrieb läuft lootogo auf einem einfachen vServer. Bei Zukünftigen Lastspitzen würden wir dann wieder auf Amazon Webservice umsteigen, wobei dies eben wieder mit Arbeit verbunden wäre.
Dauerhaft bei AWS zu hosten wäre für uns zu überdimensioniert.
Pingback: Marketing: 10 Tipps, um ein Startup richtig ins Rollen zu bringen » netzwertig.com
Ein richtig interessanter Artikel .. vielen Dank dafür. Ich hatte von AWS bisher noch nichts gehört *schäm*
Wie hoch waren denn die Ausfallzeiten (Überspielen der Daten + DB)?
Die (überschaubaren) Kosten setzten sich aus Server + Traffickosten zusammen oder?
Viele Grüsse
Thorsten
Pingback: nützliche Tweets: 21.10.2009 | preisbiene Blog
Danke für den Erfahrungsbericht!
Hi,
sehr interessanter Artikel. Eine Frage nur, wie haben die Caching Server gecached? Ganz normale Proxyfunktionalität oder wie genau? Welcher Serverdienst war dafür im Einsatz?
Zu den investierten Arbeitsstunden muss man natürlich dazu sagen, dass Tobias und ich auch erstmal Zeit gebraucht haben bis wir die verschiedenen Funktionen verstanden hatten. Insbesondere wie diese sich unter großer Last verhalten würden.
Wer also seine Applikation kennt und keine Angst vor ein paar Kommandozeilene Tools hat sollte das ganze in wesentlich kürzerer Zeit hinbekommen.
@Manuel auf den Cacheservern lief Varnish. Es wurden dort die kompletten Antworten gecached.
Pingback: Server in den Wolken bekommt Zuwachs: Neuer Autor Thomas Ruland | Server in den Wolken
Ein interessanter und anschaulicher Artikel, herzlichen Dank dafür. Ich beschäftige mich derzeit mit dem Cloud Computing und dessen rechtlicher Seite. Um die technische Seite zu verstehen, konnte ich dieses Beispiel gut verwenden.
Mich würde noch interessieren, wie ERP-Software wie beispielsweise Salesforce oder SAP Business by Design skaliert, da diese Vertreter der Branche ja keine zusätzlichen Instanzen starten, sondern vielmehr lediglich eine mehrmandantenfähige Instanz laufen haben und diese dann skalieren.
Ich bin jedenfalls davon überzeugt, dass Cloud Computing die Zukunft gehört und nicht mehr nur als hype, sondern vielmehr als Realität angenommen werden sollte.
Hallo Duke,
wenn im obigen Text von Instanzen gesprochen wird sind damit virtuelle Maschinen gemeint. Grundsätzlich gibt es ja zwei Skalierungsmöglichkeiten. Vertikale und horizontale. Beim Cloud Computing setzt man, durch die Einfachheit neue Instanzen hinzuzufügen häufig auf horizontale Skalierung.
Wie genau SAP das macht weiss ich nicht. Von Salesforce weiss ich aber, dass sie – die Zahl ist schon etwas älter – ca. 1000 Server betreiben um darauf die Anwendung für die Kunden zu betreiben.
Vielen Dank für die Antwort, Philipp. Ich bleibe Euch gewogen und werde regelmäßig reinschauen!