104 $ pro Monat für die günstigeste Variante

[sttn]

Das ist schon sehr teuer... wenn man es mit einem normalen und guten Provider wie Hetzner vergleicht.

[Suckerpunch]

Naja der Sinn ist ja Performance für ein paar Stunden zu mieten , monatlich gesehen ist da nen root sicherlich einfacher/günstiger.

[Buchkam]

Und vorallendingen geht es darum Leistungsspitzen abzufangen. Wenn Du in den Abendstunden genug Anfragen hast um damit 20 Server auszulasten, aber den Rest des Tages nur genug für einen Server, ist es sicherlich günstiger die App bei Google (oder AWS) laufen zu lassen.

Ich denke allerdings, dass an 25.000 requests pro Sekunde nur sehr wenige Apps rankommen.

[am (golem.de)]

Es geht bei solchen Lösungen nicht darum, dort sein normales Webangebot zu betreiben. Vielmehr geht es darum, in kürzester Zeit Power aufbauen zu können, wenn Lastspitzen entstehen. Bei Amazons EC2 kannst du z. B. mit einem Mausklick mal eben 100 Server und mehr sofort starten, wenn du die API nutzt, sogar scriptgesteuert automatisiert.

Beispiel: Du betreibst einen Webshop namens superkauf-forever.de und hast das supertolle Gadget, das plötzlich jeder haben will, weil Sascha Lobo drüber getwittert hat. Mit einem Schlag hast du massenhaft Traffic und dein Server geht in die Knie.
Nun hast du dich aber präpariert und ein vorbereitetes Systemimage bei Amazon EC2 hinterlegt. Du sagst EC2 er soll 100 Server mit dem Image hochfahren. Nach dem 30sek Startup startet dein eigenes Init-Script und es meldet sich jeder der EC2-Server bei deinem Backend sagen, dass sie bitte noch die aktuellen Datenupdates brauchen, dass sie innerhalb von 10min ziehen. Schließlich sagen sie noch deinem Webproxy Bescheid, dass sie jetzt auch für Anfragen unter superkauf-forever.de bereitstehen und schon kommt jeder in deinem Shop und du wirst reich. Gleichzeitig prüft ein Script den ständige Traffic und wenn es merkt, dass er sich verringert, schaltet es die Server auch wieder nacheinander ab, so dass dich die Kosten nicht auffressen.

Solche Lösungen kannst du mit Hetzner&Co ohne (teuere) Spezialverträge vergessen.

Grüße,
Alexander Merz (golem.de)

[MArc.]

Eurer Argument "kurzzeitig Lastspitzen abzufangen" ist leider Quatsch - zumindest bei AWS.

Ich hatte November letzten Jahres ein Projekt mit ein dutzend c1.xlarge Maschinen dort und hatte extreme Probleme, den Traffic überhaupt auf die Maschinen zu bekommen. Begründung von den Technikern: Der LoadBalancer (ELB) braucht seine Zeit, bis er "hochgefahren" ist, um den Traffic dann schneller/komplett durchzurouten. "Seine Zeit" war in unserem Fall aber über eine Stunde und selbst dann konnte er nicht alles zügig durchlassen. Leider viel zu lange für eine Lastspitze.

In der Zeit hätte mir Hetzner mehrere Maschinen installiert. Wäre günstiger, als die ein dutzend der dicksten Maschinen für zwei Wochen. Zumal die HetznerMaschinen _deutlich_ schneller sind.

Seit dem meiden wir AWS, um euere Szenarios zu lösen. Bin daher auch sehr gespannt, ob Google es da nun besser macht.



3 mal bearbeitet, zuletzt am 29.06.12 00:54 durch MArc..

[am (golem.de)]

Ich bin etwas irritiert, ich kenne bislang nur Lösungen, bei denen du selbst die Lastverteilung machst.
Meinst du eventuell das ELB bei AWS? Das musste ich jetzt erstmal nachgucken - das wird dort aber primär als Methode zur Stabilisierung angepriesen, nicht zur Skalierung.

Grüße,
Alexander Merz (golem.de)

[Buchkam]

Wenn Loadbalancing und Skalierung ein Thema ist, könntest Du es mal mit cloudcontrol.com probieren. :)

[MArc.]

am (golem.de) schrieb:
--------------------------------------------------------------------------------
> Ich bin etwas irritiert, ich kenne bislang nur Lösungen, bei denen du
> selbst die Lastverteilung machst.

Dann hast Du aber nicht mehr den Vorteil von automatischen Hoch-/Runterfahren der Maschinen usw. Natuerlich kann man das auch selber scripten irgendwie, aber genau fuer das ist ja der ELB da.

am (golem.de) schrieb:
--------------------------------------------------------------------------------
> Meinst du eventuell das ELB bei AWS? Das musste ich jetzt erstmal
> nachgucken - das wird dort aber primär als Methode zur
> Stabilisierung angepriesen, nicht zur Skalierung.

Ja, genau den. Wir hatten dadurch, dass wir ein ungewoehnlich starke Anforderungen und mit fuenfstelligen-Summen/Monat geplant hatten, direkten Kontakt zum AWS Techniker. Der hat unser Konzept, das den ELB als Lastenverteilung/Autoskalierung eingeplante hatte, so als best-practise abgehakt.

Dass das leider dann so endete konnten wir natuerlich nicht wissen, umso energischer schauen wir nun zu Google.