Guten Tag zusammen, ich heisse Malte Diedrich, blogge seit einigen Jahren unter Treehuggin’ Pussy und arbeite mit Nico zusammen seit einigen Wochen bei Shoppero. Zuständig bin ich für die Technik und beschäftige mich zur Zeit vor allem mit der Koordinierung der Programmierer. Durch den sehr schnellen Aufbau und die damit verbundene Arbeit komme ich erst jetzt dazu, etwas zur Technik zu schreiben, bedanken möchte ich mich an dieser Stelle auch für die zahlreichen Hinweise auf Fehler und Verbesserungsmöglichkeiten, die wir zur Zeit abarbeiten. Sowohl die Mails an improvements@shoppero.com als auch die zahlreichen höflichen und wohlwollenden Anregungen aus der Blogosphäre werden gerne gelesen und umgesetzt (auch wenn wir vielleicht nicht immer jedem antworten können). Ich möchte hier besonders Björn Schotte und Fukami hervorheben, die uns in den letzten Tagen sehr geholfen haben.
Wie bereits erwähnt, läuft Shoppero auf einem Webdienst von Amazon, Electronic Cloud Computing (EC2). Amazon stellt hierbei virtuelle Server zur Verfügung, die man nach Belieben zu- und abschalten kann.
Wir ersparen uns damit den tatsächlichen Umgang mit Hardware und vertrauen darauf, dass die Ingenieure bei Amazon ein Rechenzentrum besser betreiben können als wir.
Um einen Server bei Amazon zu starten, sucht man sich ein Image aus und startet dieses Image über eine Verwaltungsoberfläche oder eine Kommandozeile. Nach ein 2-3 Minuten steht die Maschine dann zur Verfügung, man fragt die IP ab, schaltet bei Bedarf bestimmte Ports frei und kann loslegen. Ab diesem Moment zahlt man auch. Wenn man das Image durchgespielt hat, fährt man es wieder runter und braucht auch nichts mehr zahlen. Nach Amazons Angaben hat man ein Xeon 1,7 GHz Equivalent mit 1 GByte RAM und 160 GByte Speicherplatz zur Verfügung.
Technisch gesehen sind die virtuellen Server Xen-Images. Diese werden entweder von Amazon zur Verfügung gestellt oder von uns selbst hergestellt, wobei man dies praktischerweise gleich auf den Servern von Amazon machen kann und nach dem Bootstrapping mithilfe der Amazon EC2-Tools nach S3 hochgeladen werden. Dort stehen sie dann zur eigenen oder allgemeinen Benutzung zur Verfügung. Es ist auch möglich, eigene Images wieder einzupacken und zurück bei S3 zur Speicherung abzulegen, wodurch wir inzwischen für die Datenbankserver und die Webserver fertige Vorlagen haben, die wir beim Start nur noch kurz aktualisieren müssen und so in kurzer Zeit die Leistung vervielfachen können. Auch wenn wir dies zur Zeit noch per Hand machen, grundsätzlich kann man den gesamten Vorgang auch soweit automatisieren, dass das Gesamtsystem je nach Last quasi mitwächst und wieder kleiner wird. Auch können wir schnell einen Testserver hochziehen, bestimmte Dinge ausprobieren und die Kiste danach wieder wegwerfen.
Wirtschaftlich gesehen ersparen wir uns durch den EC2 Service eine Menge Ausgaben am Anfang des Unternehmens und können die Technik parallel mit dem Wachstum der Seite wachsen lassen. Es wird spannend zu beobachten, ob sich der anfängliche Kostenvorteil später verstärkt oder es zu einem Zeitpunkt günstiger werden wird, eigene Server zu betreiben.
Und um die häufigste Nachfrage gleich zu beantworten: Ich weiss auch nicht, nach welchem System Amazon Leute zu EC2 einlädt und wie man diesen Vorgang beschleunigen kann.
Ich bin mir recht sicher, dass ab einem bestimmten Punkt eigene Server inklusive mit allem, was dazu gehört, die gesamte Betriebsorganisation áuch mit Staff preiswerter ist. Dieser Punkt aber schiebt schiebt mit fortschreitender Reife und Verbilligung der RZ-Ressourcen immer weiter nach hinten. Möglicherweise werdet ihr sehr spät oder nie diesen Punkt erreichen. Ich denke, es kein Thema in den kommenden 12 Monaten.
Cem, das sehen wir ähnlich. EC2/S3 bieten uns die Möglichkeit, bereits am Start gut skalieren zu können. Es ist für mich persönlich auch eine Konsequenz aus anderen Launches, die ich in den letzten Jahren begleitet habe.
Malte, wie kriegt man in so einer Umgebung einen Loadbalancer unter?
Loadbalancing beim Web machen wir zur Zeit mit nem Round-Robin-DNS. Nicht wirklich schön, achtet nicht auf Load, aber einfach zu implementieren und zur Zeit reicht es. Einigen DNS-Providern kann man per URL eine neue IP mitteilen, so dass wir diesen Aufruf in das Startscript integrieren können und sich der Rechner so automatisch beim Start als Webserver anmeldet.
Loadbalancing auf der Datenbank ist zur Zeit noch gar nicht nötig, kann aber durch weitere Maschinen und z. B. Ultramonkey geschaffen werden.
Wenn wir richtig gross werden, müssen wir uns evtl. Gedanken über eigene Hardware machen, aber für die nächste Zeit reicht es.
Wie macht ihr das mit der Datenbank - habt ihr die nur auf EC2 (Falls ja, wie funktioniert dann bei euch die Datensicherung, da EC2-Server im Falle eines Absturzes ja alle Daten verlieren?) oder habt ihr da trotzdem was eigenes? (Ohne spezielle Skalierung - oder wie macht ihr das dann?)
Würd mich interessieren, denn das ist mir ein bisschen suspekt bei Amazon EC2. Meinen Informationen nach kann man ja die Datenbank nicht auf S3 hosten, und einfach viele Server unter EC2 starten, in der Hoffnung, dass nicht alle abstürzen, ist ja auch nicht gerade das gelbe vom Ei…
Es ist richtig, dass man bei S3 keine DB hosten kann, dies ist tatsächlich eine reine Dateiablage.
Die DB liegt zur Zeit auf einer EC2 Instanz und wird alle Daten um Falle eines Absturzes verlieren. Aufgrund der noch geringen Last brauchen wir hier noch kein komplizierteres Setup einsetzen, wappnen uns aber schon dafür. Wir sichern im Moment mit simplen Dumps der DB, viertelstündlich und speichern die ausserhalb des Amazon-Universums weg. Das geht für den Anfang ganz gut, wird aber natürlich keine Lösung für ewig bleiben. Für die Zukunft gibt es mehrere Möglichkeiten:
* Write-Ahead-Logging bei PostgreSQL, was natürlich einen Wechsel der DB zur Folge hat (geplant ist das auch bei MySQL, aber noch weit von stabil entfernt)
* Ein Replication-Setup mit einer Node ausserhalb von Amazon
* Externer Serviceprovider, der sich um die DB kümmert.
* Und die spannendste Möglichkeit: Es wird gemunkelt, dass Amazon selbst auch eine DB-Engine anbieten wird, die ähnlich dem S3 und EC2-Service funktioniert.
Wir sind im Moment noch weit von einem möglichen Problem entfernt, daher gehen wir das ganz entspannt an, testen viel und probieren aus, was zu uns am Besten passt.
Hallo Malte,
bzgl. des Storage Engine Drivers für MySQL:
http://forge.mysql.com/projects/view.php?id=198
Grüße, Björn.
Ja, danke, das Fallenpegasus-Projekt kenne ich. Das ist zwar nur ein paar Wochen alt und ich will lieber noch abwarten, was da passiert, aber es ist durchaus ne Möglichkeit.
Ich finde die Amazon-Dienste auch sehr interessant, was mich allerdings bisher immer davon abhielt, es ernsthaft einzusetzen ist: Die Geschwindigkeit.
Die Server stehen in den USA, und der Ping ist grundsätzlich größer als 100 ms. Auch die Übertragungsrate ist nicht sehr berauschend, die wird wahrscheinlich bei größeren Files besser, aber z.B. 6 Sek. für ein 50 kB File sind sehr viel.
Mein Tipp: gebrauchten Rootserver mit Trafficflat in einem Frankfurter RZ nehmen und Squid als reverse proxy drauf. Gerade für die vielen Bilder bringt das sicher einen ganz erheblichen Vorteil. Ausserdem muss man Amazon weniger Traffic bezahlen.
Cheers,
Eike