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.

• What is scalable application design
• Tip 1: load balancing the webserver
• Tip 2: scaling from a single DB server to a Master-Slave setup
• Tip 3: Partitioning, Vertical DB Scaling
• Tip 4: Partitioning, horizontal DB Scaling
• Tip 5: Application Level Partitioning
• Tip 6: Caching to get around your database
• Resources
• Closing notes

Lesen: Scalable Web Applications

Leider hab ich kein Video gefunden. Hier ist der Link zur Session bei O’Reilly und es gibt auch die Präsentation zum Download. Ausserdem gibts bei Kris Jordan ein paar kurzweilige Notizen von der Konferenz.

via Highavailability

Es gibt auf dem gesamten Webhostingmarkt keine Lösung die es mir erlaubt klein anzufangen und dann einfach mit dem Bedarf meines Projektes zu wachsen. Ausserdem muss ich immer für Lastspitzen genug Leistung vorhalten, die den größten Teil der Zeit brach liegt. Kurzzeitige Peaks wie durch Digg, Heise oder Slashdot z.B. sind ebenfalls mein Problem.

Kosten sind nicht Verbrauchsabhängig.

Ich zahle feste Paketpreise für Inklusivleistungen die ich entweder garnicht brauche oder nur kurze Zeit brauche. Warum zahle ich nicht für Webhosting wie für Strom. Eine Art Grundgebühr, dafür dass das Projekt online ist und dann Abrechnung nach tatsächlichem Verbrauch? Optional mit Kostenlimit, damit ich jederzeit frei entscheiden kann ob mir mein Projekt das Geld wert ist.

Versteckte Vertragsklauseln im Kleingedruckten.

Was sollen diese unnötig verwirrenden Vertragsklauseln. Jedes vollmundige Versprechen hat zehn kleine Nummern dran die dann für jeden scheiß ne Ausnahme haben. Entschuldigt die Ausdrucksweise, aber darüber rege ich mich jedesmal auf. Bei Mobilfunkverträgen ist es genauso, wenn nicht sogar noch schlimmer.

Unqualifizierte Mitarbeiter.

Wenn ich ein Produkt oder eine Dienstleistung verkaufe, muss ich mir auch die Mühe machen und Leute einstellen die davon Ahnung haben. Wenn ich beim Support anrufe will ich, dass mir jemand hilft. Wenn ich jemandem zuhören  will der mit Mühe und Not in der Lage ist den Fragenkatalog vorzulesen geh ich in die Vorschule. Ausserdem ist es ein Unding optional besseren Support anzubieten. Was soll das? Wenn ich erkenne, dass mein Support scheiße ist muss ich das ändern und nicht so tun als wäre das normal so.

Umständliche Administrationsoberflächen.

Hohe Verweildauer im Administrationsinterface sollte alle Alarmglocken zum läuten bringen. Ich meine ernsthaft, wenn ich im Administrationsinterface eingeloggt bin will ich irgendetwas erledigen. Es ist eher selten, dass ich mir dafür nen Tag Urlaub nehmen will. Die meisten Administrationsinterfaces die ich kennen lernen musste waren ungefähr so intuitiv zu bedienen wie… mir fällt nichtmal ein Vergleich ein der auch nur annähernd so umständlich ist.

Lange Mindestvertragslaufzeiten.

Mindestvertragslaufzeiten sind für Unternehmen die nicht in der Lage sind die Kunden mit der Qualität der eigenen Produkte oder Dienstleistungen an sich zu binden. Um das ganze auf die Spitze zu treiben gibt es dann noch meist völlig unverständliche Kündigungsfristen. Wenn man nicht sechs Monate vor Ablauf der Mindestvertragslaufzeit zu einer Uhrzeit mit ungerader Sekundenzahl kündigt wird der Vertrag automatisch um eine Zeit X verlängert. Gehts noch?

Einrichtungsgebühren.

Genau der selbe Quatsch. Wenn ich mich dann an den Versprechen vorbei zum Kleingedruckten gekämpft habe um rauszufinden was man mir hier wirklich verkaufen will, kann ich erstmal herausfinden wieviele versteckte Zusatzkosten mit dem Vertragsschluss noch verbunden sind.

Unflexible Pakete.

Wenn ich Webhosting will, will ich nicht zusätzlich noch ne SIM-Karte für mein Handy, oder nen DSL-Anschluss. Irgendwelche drittklassige Software zum Bearbeiten von Photos oder Erstellen von Webseiten sollte sowieso verboten werden und nicht auch noch mit dem Paket angepriesen. Ha und am besten werd ich während des Bestellvorgangs noch mit irgendwelchen Virenscannertestversionen beworfen.

Unnötig verwirrende Produktpakete.

Als wären die umständlichen Ausnahmen im Kleingedruckten nicht genug um den Kunden zu verwirren werden unzählige Pakete geschnürt die dann mit völlig bescheuerten Namen bestückt werden. Power, Plus, Ultra, Ultraplus, Powerultra, PowerultraPlusultra oder PlusplusUltraulra. Man sollte die Leute mal zwingen sich die Namen der Produkte gegenseitig laut vorzulesen.

Benachteiligung von bestehenden Kunden.

Jeder Anbieter lockt Neukunden mit unzähligen Versprechungen. 3 Monate halber Preis, oder garkeine Zahlungen. Es gibt eigentlich immer irgendeine Aktion, dass die Einrichtungsgebühr wegfällt. Da könnte man es auch gleich lassen… Oder wenn bis zum Ende des Monats bestellt wird gibt es lebenslang kostenlosesn Premiumsupport dazu. Was kriege ich als Bestandskunde? Bescheidenen Support, umständliche Administrationskonsolen, lange Vertragslaufzeiten und bescheuerte Kündigungsfristen. Wenn doch mal die Preise auch für Bestandskunden gesenkt werden muss man noch extra Bescheid geben, dass man auch weniger zahlen möchte.

Bei dem ein oder anderen Punkt mag man mir jetzt entgegen halten, dass man immer bekommt was man bezahlt. Aber wenn ich ein Produkt oder eine Dienstleistung zu einem Preis anbiete, dann sollten zumindest alle Leistungen die ich verspreche ihren grundsätzlichen Zweck erfüllen. Support bei dem mir nicht geholfen wird weil der Mitarbeiter keine Ahnung hat, ist kein Support. Wenn das mit dem Preis nicht möglich ist, kann ich den Preis nicht anbieten oder muss klar und deutlich angeben, dass man zu dem Preis keinen Support erwarten kann.

Ehrlichkeit ist im Prinzip das Schlüsselwort. Ich hasse es, dass ich als Kunde das Gefühl habe verarscht zu werden.

Wie würdet ihr sortieren, was ist eure Reihenfolge in meiner Top Ten? Gerne könnt ihr natürlich auch die Kommentare nutzen um der Liste weitere Punkte hinzuzufügen. Das Widget will irgendwie nicht bei mir im Blog. Hier der Link falls jemand bei Woobby sortieren möchte.

photo credit: liber

Man kann übersichtlich neue Musik der Künstler mit denen man innerhalb des Dienstes verbunden ist hören, man kann eigene Musik an andere senden und Soundcloud bietet zusätzlich noch einen Player um die eigene Musik in andere Seiten einzubinden und dort anhörbar zu machen. Die Versandfunktion will das versenden von großen Dateien erleichtern. Selbst ausprobiert habe ich den Dienst nicht. Bin aber auch wahrlich kein Musiker.

Warum ich jetzt über Soundcloud schreibe ist dieser Blogpost. Bei Soundcloud kam es im Zuge eines zur Behebung von Geschwindigkeitsproblemen ohnehin geplanten Serverumzuges zu einem Fehler mit den Festplatten des Datenbankservers. Dadurch ging die Seite offline und weil man sich gerade im Umzug befand blieb sie dies auch bis der Umzug abgeschlossen war. Für geschlagene zwölf Stunden.

Solche Vorfälle passieren immer wieder. Ob jetzt menschliches Versagen oder einfach Pech die Ursache dafür waren ist eigentlich nebensächlich. Fakt  ist, sowas darf nicht passieren wenn man ein Unternehmen aufbauen will.

Das Problem, die Skalierung der eigenen Plattform mit den Anforderungen ist schon tausendmal gelöst worden. Doch trotzdem muss es jedes Startup für sich selbst neu lösen. Warum? Weil die Hostingunternehmen nicht in der Lage sind funktionierende Lösungen zu schaffen um dieses Problem zu lösen.

Man ruht sich lieber auf seinen Lorbeeren aus und übertrifft sich gegenseitig mit Absenz jeglicher Innovation.

Auf den ersten Blick scheint die Rechnung natürlich aufzugehen. Aber auf den zweiten Blick muss man sich dann fragen, wer soll die ganze Hardware denn administrieren. Denn Serveradministration ist sehr zeitaufwendig. In den meisten Startups bleibt diese Administrationsarbeit dann aber an genau den Entwicklern hängen, deren Zeit eben als zu teuer bewertet wurde. Was hat man also gewonnen? Genau, nichts!

Echte Systemadministratoren, und vor allem auch gute, einzustellen ist aber ebenfalls teuer. Oftmals fällt die Entscheidung dann zumindest in den Anfangsphasen doch lieber auf noch nen Entwickler und die Systemadministration muss nebenher laufen. Wie riskant es ist Sicherheitsupdates und Backups zu vernachlässigen muss ich hier hoffentlich niemandem erzählen.

Mit mehr Hardware steigen aber auch die Probleme die zu bewältigen sind. Web- und Cachingservern sagt man eine fast lineare Skalierung nach. Bei Datenbankservern sieht das ganz anders aus. Sharding verkompliziert Backup und Redundanzanforderungen und Replikation erhöht die Applikationskomplexität enorm.

Hardware an sich ist wirklich nicht teuer. Die Administration derselben aber zeitaufwendig und damit alles andere als günstig. Für jeden dessen Fokus nicht primär die Systemadministration ist, sondern das eigene Produkt oder Projekt kann ein Dienstleister die bessere Wahl sein. Ganz nebenbei kann geteilte Rechenleistung wie ich sie im vorherigen Post beschrieben habe nochmals die Kosten senken. Die Leistungsreserven moderner Hardware reizt man oft nicht aus. Ausfallsicherheitsanforderungen erhöhren das Problem noch und es steht noch mehr Hardware ungenutzt in der Gegend rum und muss bezahlt werden.

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.

Zu Beginn nimmt sich der Artikel dabei die Zeit einige Begriffe zu erklären. Besonders hervorzuheben ist dabei die wichtige Unterscheidung zwischen Geschwindigkeit (Performance) und Skalierbarkeit. Der Unterschied ist nämlich, dass es bei Geschwindigkeit darum geht wie schnell ein System eine einzelne Anfrage beantworten kann, wohingegen Skalierbarkeit sich auf die Qualität des Systems unter Last bezieht.

Der Artikel will dabei die Frage beantworten, wieso unterteilen wir unsere Daten und wie hilft uns diese Unterteilung die Skalierbarkeit sicherzustellen. Dazu wirft der Autor zuersteinmal einen Blick auf verschiedene Anwendungszenarien an Hand derer man dann die beste Shardingstrategie für die eigenen Daten ableiten können soll. Die verschiedenen Szenarien gehen allerdings alle von bereits bestehenden Datensets aus. Wenn man noch garnicht genau weiss, wie die eigenen Daten aussehen werden helfen einem die Beispiele erstmal auch nicht übermässig. Gerade was Datum- bzw. Zeitabhängige Unterteilung angeht, denn diese ist nur dann sinnvoll, wenn die Datensätze auch gleichmässig über die Zeit verteilt sind. Dies wird allerdings nur bei den wenigsten Anwendungsszenarien von vorneherein absehbar sein. Auf dieses Problem geht der Artikel allerdings ebenfalls ein und widmet sich in einem eigenen Abschnitt der später vielleicht notwendig gewordenen Neuverteilung.

Im Anschluss beschäftigt sich der Artikel zusätzlich noch mit der Frage, wie das beschriebene System noch zusätzlich Hochverfügbar gemacht werden kann.

Hier gehts lang!

Dabei zeigt sich recht deutlich, dass der Administrationsaufwand noch viel mehr als die Kosten gerade für Startups ein Problem darstellen. Hier können Cloud Computing Dienste die Lösung sein. Allerdings muss dabei sichergestellt sein, dass erstens die Anwendung nicht speziell für den einen Dienst entwickelt werden muss, damit jederzeit der Wechsel zu einem anderen Anbieter oder auf eigene Infrastruktur möglich ist und zweitens neben der Qualität des Dienstes vor allem auch die Sicherheit stimmen muss.

Morgen gehts dann vielleicht noch mal speziell um Cloud Computing. Das wird sicher spannend und ich werde natürlich dabei sein und dann selbstverständlich auch an dieser Stelle davon berichten.