myPEAK.net Blog

Das Anforderungsprofil ist klar. Als Startup sucht man eine Hostinglösung, die möglichst flexibel skalierbar ist, am besten natürlich nach oben sowie nach unten. Sie sollte ausreichend Ausfallsicherheit bieten und selbstverständlich möglichst günstig sein. Zusammenfassend, wir wollen alles und zwar umsonst.

Der erste Teil ist die Wahrheit, der zweite Teil ist Utopie. Die Ziele sind damit ausreichend hoch gesteckt, machen wir uns also daran den passenden Mittelweg zu finden.

Am besten gehen wir der Reihe nach vor.

Die normale vorgehensweise, klein anfangen und wenn die Nutzerzahlen steigen weitere Maschinen nachschieben. Horizontale Skalierung! “Been there done that.” Das ganze so ausgelegt, dass die Leistung für die Stosszeiten ausreichend bemessen ist.

Somit habe ich 2 Möglichkeiten: Zum einen Housing und zum anderen Hosting auf Mietservern. Vorteil des Housing, man kann genau die Hardware anschaffen, die für die eigenen Zwecke optimal ist. Der Nachteil dabei, wenn diese Hardware ausfällt muss man sich selbst darum kümmern sie zu ersetzen. Dabei ist die Zeit das größte Problem. Um Hardware möglichst zeitnah ersetzen zu können muss man diese vorrätig haben und wenn man sie dann doch nicht gebraucht hat lag sie rum und hat Geld gekostet.

Bei Mietservern kümmert sich der Anbieter um den Ersatz der Hardware, die Mehrkosten die dabei anfallen zahlt man zwar auch, doch sinken die Kosten mit steigender Serveranzahl und diesen Vorteil können die Anbieter an die Kunden weiter geben. Nachteil die Mietserver sind Hardware technisch grundsätzlich erstmal so ausgelegt, dass sie allgemein Einsatzfähig sind. Bei einigen Anbietern sind individuelle Server möglich, aber im Prinzip unterscheiden sich die Server der verschiedenen Anbieter nicht.

Ein gemeinsames Problem beider Möglichkeiten ist die Laufzeit. Man bindet sich vertraglich meist min. ein Jahr, zumindest bei den größeren Maschinen. Aber auch eine Mindestvertragslaufzeit von einem Monat ist alles andere als flexibel.

Das Problem ist einfach, dass man die Leistung auf die erwähnten Stosszeiten auslegen muss und den Rest der Zeit dafür zahlt, dass man haufenweise wertvolle CPU Zyklen ungenutzt verstreichen lässt. Tolle Aussichten!

Weder mit Serverhosting noch mit Serverhousing ist diesem Problem effektiv zu begegnen. Der ein oder andere ahnt vielleicht auch schon wo das ganze hier hin führt.

Amazon scheint was unser Problem angeht mit EC2 (Elastic Compute Cloud) zur Rettung zu eilen. So scheint es jedenfalls.

Das Konzept klingt auch sehr viel versprechend. Je nach Bedarf kann ich virtuelle Maschinen anmieten und zahle dann lediglich für die tatsächliche Nutzung. Basierend auf Laufzeit und Trafficaufkommen. Für $ 0,10 pro Stunde und $ 0,20 pro GB bekommt man dann eine Xen DomU mit der Leistung (laut Amazon) eines 1.7Ghz x86 Prozessors mit 1.75GB RAM, 160GB Plattenplatz und 250Mb/s Netzwerkbandbreite. Man kann sein eigenes Betriebssystemimage auf Amazons S3 Speicherservice ablegen und je nach Bedarf einzelne Instanzen davon starten. Nach ca. 2 Minuten ist dies dann geschehen und man hat so lange man es braucht eben die x-Fache Leistung zur Verfügung und zwar genau so lange wie man diese Leistung braucht. Danach beendet man die Instanzen einfach wieder und fährt sie erst wieder hoch wenn man sie wieder benötigt. Es klingt fast zu schön um wahr zu sein. Es muss einen Haken an der Sache geben und den gibt es leider auch.

Jede Instanz startet auf dem Stand des Systemabbilds. Jegliche Änderungen während der Laufzeit gehen verloren. Was das für einen Datenbankserver bedeutet brauche ich hier hoffentlich niemandem zu erklären.

Nun wäre das Internet nicht das Internet, wenn zu diesem Thema sich nicht schon jemand den Kopf zerbrochen hätte und eine Lösung anbietet. Es gibt verschiedene Ansätze die aber im Prinzip auf eines hinaus laufen. Spiegelung des Datenbankservers auf 2 Instanzen. Nachteil, wir suchen ja nach einer günstigen Lösung. Eine dauerhaft laufende Instanz kostet im Monat ca. $ 72 plus Traffic. Vergleichbar performante Mietserver gibt es allerdings schon für unter 100 € und immer häufiger ist dabei jeglicher Traffic inklusive. Bei redundanter Auslegung nehmen sich beide Angebote im Endeffekt also nichts. Der Traffic wird anfangs natürlich gering sein und deshalb die verbrauchsgenaue Abrechnung etwas günstiger, aber kalkulierbare Kosten sind natürlich auch ein Argument.

Um wirklich minimale Hostingkosten zu erzielen, müsste man also einen Weg finden wie man mit nur einer dauerhaft laufenden EC2 Instanz trotzdem nicht Gefahr läuft alle seine Daten zu verlieren wenn diese Instanz sich irgendwann einmal unvorhergesehen beendet. Aus welchen Gründen auch immer. Es müssen also Backups in möglichst kleinen zeitlichen Abständen her, was mit – ja hoffentlich – wachsender Datenmenge, zu einer immer größeren Belastung für den Datenbankserver wird. Mit dem Resultat das andere Anfragen langsamer beantwortet werden.

Ein wenn auch nicht perfekter, aber doch vielversprechender Ansatz wird hier beschrieben. Die Idee dabei ist, auf einer Instanz 2 MySQL Datenbankserver laufen zu lassen, welche untereinander über das MySQL Binärlog repliziert werden. Dann z.B. 10 minütig Backups vom zweiten SQL Server zu machen während der erste normal weiter läuft und Anfragen beantworten kann. Natürlich bedeutet das auch nur halbe Leistung des Gesamtsystems.

Das beschriebene Beispiel geht allerdings davon aus, dass man zwecks Ausfallsicherheit trotzdem immer 2 Instanzen laufen hat. Ausserdem sind täglich ebenfalls Backups der ersten Datenbank vorgesehen, da es aus verschiedenen gründen vorkommen kann, dass die MySQL Replikation zu verschiedenen Datenbeständen führt. Horrorszenario! Reduziert man das ganze aus Kostengründen dann auch noch auf nur eine laufende Instanz muss man damit rechnen, nach einem Ausfall erst das Backup einspielen zu müssen und läuft Gefahr Daten bis 10 Minuten oder sogar bis zu einem Tag zu verlieren. Das Rückspielen dauert mit wachsender Datenmenge natürlich immer länger und diese Zeit ist man dann nicht erreichbar.

Die Vor- und Nachteile wollen sorgsam gegeneinander abgewogen werden. Man sollte auf jeden Fall so kurze Zeit wie möglich mit nur einer Instanz fahren und sobald es finanziell irgendwie machbar ist auf 2 Instanzen setzen. Nutzt man dann die Flexibilität von Amazons EC2 indem man z.B. den Applikationsserver bei Bedarf auf eine dritte Instanz auslagert und dann eine vierte und eine fünfte Instanz mit weiteren Applikationsservern nach Bedarf startet kann dies mittelfristig zu deutlich niedrigeren Kosten führen als wenn man horizontal mit Mietservern skaliert. Was das ganze dabei so interessant macht, dass man bereit sein könnte den ganzen Aufwand auf sich zu nehmen ist ganz einfach die Möglichkeit die Maschinen über die API zu starten und zu stoppen. So könnte die eigene Anwendung selbstständig und abhängig von der aktuellen Auslastung skalieren. Funktionierende und sinnvolle Automation ist eine gute Sache. Um es mit Guy Kawasakis Worten zu sagen: “Life is good!”

Am Rande bemerkt gibt es bereits 2 verschiedene Anbieter (Elastra und RightScale) die sich des Problems mit verschiedenen Lösungsansätzen angenommen haben. Diese Dienste kosten allerdings Geld und deshalb habe ich sie erstmal aussen vor gelassen. Zumindest der RightScale Ansatz liesse sich, da hauptsächlich auf Linux Bordmitteln basierend, – zugegeben – mit einigem Aufwand nachbauen. Aber die Zeit dafür muss auch erstmal aufgebracht werden.

Ausserdem ist zu erwarten, dass Amazon wohl über kurz oder lang ebenfalls eine Lösung für das Problem anbieten wird.

Fazit: Amazons EC2 und S3 (als Datenspeicher für z.B. Backups) sind meiner Meinung nach auf jeden Fall einen Blick wert und für unsere geschlossene Beta deren Beginn für den 1. August geplant ist schliesse ich die Möglichkeit momentan nicht aus. Eine Strategie mit nur einer Instanz ist wahrscheinlich zu riskant sobald die Plattform öffentlich wird. Mittelfristige Kostenvorteile sind allerdings zu erwarten, sobald man den dritten Mietserver angeschafft hätte.

Zum Schluss noch ein Aufruf an alle Gründer sich per Kommentar oder Trackback zum Thema zu äussern, von Ihren Erfahrungen zu berichten und von denen der anderen zu profitieren.