Bei der Planung von Shoppero kam natürlich irgendwann das übliche Thema Serverfarm auf. Ein riesiger Kostenblock, denn man will ja Redundanz und möglichst auch eine stete Erreichbarkeit gewährleisten, aber auch eine ordentliche Performance, damit die User zufrieden sind, und Skalieren soll das Ganze auch noch. Dazu kommt dann immer das Thema Hands-On Service, der auch teuer ist, es sei denn, man macht ihn selber, aber dann können murksige Netzwerkkarten oder kaputte Festplatten durchaus die Freizeit in Mitleidenschaft ziehen. Ich habe schon einige Serverfarmen geplant und aufgesetzt und irgendwie wollte ich bei diesem Startup auf dieses Nervpotential verzichten.

Zusammen mit Malte habe ich mir dann mal die Amazon Web Services angeguckt, genauer gesagt die Dienste Elastic Computing Cloud (EC2) und Simple Storage Service (S3). Auf den ersten Blick fanden wir das ziemlich ansprechend, auf den zweiten auch. Also haben wir uns für die Nutzung von EC2 und S3 für Shoppero entschieden.

EC2 bietet beliebig viele virtuelle Server-Instanzen an. S3 bietet endlosen Festplattenplatz inklusive Auslieferungsmöglichkeit. In der Kombination haben wir jetzt eine virtuelle Serverfarm mit etlichen virtuellen Servern, die nach Bedarf gestartet oder heruntergefahren werden und schier unendlichen Plattenplatz für die Daten. Praktischerweise werden die Bilder dann auch direkt von S3 ausgeliefert, so dass wir uns hier gar keine Sorgen um eine Skalierung machen müssen, das macht S3 von ganz alleine. Dadurch haben unsere Images derzeit alle einen URL a la s3.amazonaws.com, was wir allerdings nicht weiter tragisch finden. Abgerechnet wird pro Stunde bei EC2 und dann noch pro gehostetes GB und pro transferiertes GB. Für die letzten 4 Wochen haben wir für Setup und Testing unserer virtuellen Serverfarm ca. 80 EUR ausgegeben, was uns durchaus erfreut.

Sicherlich gibt es auch beim Betrieb einer virtuellen Serverlandschaft bei EC2 einige Aspekte, die man beachten muß. Beispielsweise kann man CPU, RAM und Plattenplatz der virtuellen Instanz nicht selber frei bestimmen, sondern nimmt das, was EC2 anbietet. Noch dazu kommt der interessante Begeleitumstand, dass man zwar beim Crash einer Instanz nur knapp 4 Minuten benötigt, um eine neue Instanz zu starten, aber dass dabei sämtliche Daten auf dem virtuellen Plattenplatz der Instanz, immerhin 160 Gb, unweigerlich flöten gehen. Also müssen die Daten für den Fall der Fälle ausgelagert werden, beispielsweise auf S3, weil interner Traffic zwischen EC2 und S3 nichts kostet, oder z.B. durch MySQL Master-Slave-Konfigurationen.

Konzeptionell ist die Kombination von EC2 und S3 höchst interessant und hat uns in der Entwicklungsphase einiges an Arbeit und Aufwand erspart. Und wir hatten bislang keine kaputte Festplatte, jedenfalls haben wir nichts bemerkt.