« Der Niedergang des Mediums Fernsehen | Start | Design-Entwürfe eines Nachwuchskünstlers »

15. Januar 08

Webtechnologie

Wie baut man eine hoch-skalierbare Webanwendung, die auch der Last einer großen Anzahl von gleichzeitigen Benutzern standhält? Bezüglich der Basistechnologien (dem sogenannten Stack) ergibt sich bei den ganz Großen folgendes Bild:

Stacks_2

(Ohne Gewähr, zusammengestellt aus den vielen detaillierten Infos auf highscalability.com, bzw. für Xing von epublica).

Demnach eignen sich prinzipiell alle Programmiersprachen gleichermaßen und bei Datenbank und Betriebssystem liegen MySQL und Linux vorne - das aber sicherlich aus Kostengründen.

Subjektiv liefern Google, Amazon und Xing die beste Stabilität und Performance, aber das wird andere Ursachen haben, als die Wahl des Stacks. Und wenn Twitter für mangelnde Stabilität berüchtigt ist, sollte man deswegen die Programmiersprache Ruby nicht gleich verteufeln.

Alle der oben genannten Anwendungen sind fehlertolerante, verteilte Anwendungen, und laufen auf Serverfarmen, teilweise in mehreren, geographisch verteilten Rechenzentren. Google verfügt über einen Rechnerpark von 450.000 Servern (Stand 2006) und eBay hat 15.000 Applikations-Server parallel im Einsatz. Eher statische Anwendungen wie Wikipedia sind mit 300-400 Servern weitaus genügsamer.

Einige der Lessons Learned auf highscalability.com widersprechen diametral der klassischen Lehre des technischen Managements:

  • Bevorzugt wird durch die Bank Billighardware, denn man bekommt damit in der Summe mehr Performance für sein Geld,
  • Abschätzungen von Hardwareanforderungen und Benchmarking sind nur wenig brauchbar, denn unter Realbedingungen sieht alles ganz anders aus,
  • Im Zweifelsfall lieber selber schreiben, als fertige Softwarekomponenten kaufen.

Generell verschieben die hochskalierbaren Architekturen immer mehr Last in Richtung Client. Server-seitiger State ist verpönt, und klassische Aufgaben der Datenbank werden vom Applikationsserver übernommen (wahrscheinlich der Grund, warum MySQL-Konkurrent Postgres nicht in der ersten Liga spielt). Interessant fand ich auch die Beobachtung der YouTube-Architekten, daß der Long Tail klassisches Caching aushebelt, weil die breite Streuung der Anfragen die Findung einer vernünftigen Cache-Strategie außerordentlich erschwert.

Bei 1000MIKES setzen wir Java/MySQL/Linux ein. Die Wahl von Java ist letztendlich eine Frage der Sozialisation. Für Audioverarbeitung, Streaming und Telefonie haben wir uns Komponenten wie z.B. Icecast angeschaut, uns aber dagegen entschieden, da unsere Anforderungen schwer abbildbar und der Integrationsaufwand zu hoch war. Stattdessen machen wir es selbst, und so wird es eine richtig runde Sache.

Ansonsten setzen wir eine Unzahl von Open-Source-Komponenten ein: Dojo für AJAX, Facelets für die Seitengenerierung, den unverwüstlichen Klassiker Tomcat, Hibernate zur Anbindung der Datenbank, Jain-Sip für die Anbindung des Telefonnetzes, Speex als Sprach-Encoder, Lame als MP3-Encoder, Guice um in Sachen Software-Architektur nicht einzurosten, Subversion, Tortoise, Trac zu Organisationszwecken, und noch viele mehr. Ohne sie wäre ein anspruchsvolles Projekt wie 1000MIKES nicht möglich.

TrackBack

TrackBack-Adresse für diesen Eintrag:
http://www.typepad.com/services/trackback/6a00e54ed66e1b883300e54ff3d8ab8834

Folgende Weblogs beziehen sich auf Webtechnologie:

Kommentare

Heiner Strauß

Zitat:
Server-seitiger State ist verpönt, und klassische Aufgaben der Datenbank werden vom Applikationsserver übernommen (wahrscheinlich der Grund, warum MySQL-Konkurrent Postgres nicht in der ersten Liga spielt).

Was hat das miteinander zu tun ? Ist der jdbc treiber von MySQL von besser als der von PostgreSQL ? Bei Benchmarks hatte ja MySQL mit der Skalierung von parallelen Transaktionen bis jetzt erhebliche Probleme.

FFD

Die Stärken von Postgres (und der Entwicklungsfokus) lagen immer darin, Applikationslogik übernehmen zu können, per Stored Procedures oder über nutzer-definierte Typen. MySQL hat da sehr viel weniger zu bieten. Aber, bei den High-Traffic-Websites ist ja die Datenbank meistens das Bottleneck, daher hat es sich falsche Philosophie herausgestellt, der Datenbank mehr Aufgaben zu übertragen. Selbst die Normalisierung gilt inzwischen als Skalierungskiller. Klar, das heißt nicht, das Postgres schlechter performt, aber die Stoßrichtung war die falsche.

Wo gab es den Benchmark? Würde mich interessieren!

Die Kommentare dieses Eintrags sind geschlossen.