Bis die Balken krachen!

Der gewaltige Ansturm von Usern auf die Funktionalitäten von Social Networks löst einen gewaltigen Druck auf die Architektur solcher Plattformen aus. Obwohl solche Plattformen oft aus Prototypen entstanden sind, müssen diese regelmässig komplett überarbeitet werden. Ich habe gerade einen Bericht von David F. Carr gelesen, der die immensen Probleme bei MySpace treffend beschreibt und darstellt, wie die Plattform in den letzten Jahren mehrfach komplett überarbeitet wurde.

So war es durchaus selbstverständlich, dass an manchen Tagen auf MySpace 20% Fehler-Loggings oder manchmal sogar bis zu 40% erzielt wurden. Zum Vergleich: Yahoo oder Salesforce erzielen da Werte von ca. 1%. Auch bei studiVZ oder anderen beliebten Social Networks wurden vielfach Fehler und Performance Probleme registriert. Kein Wunder sind doch oft diese Plattformen in der Garage entstanden ohne grosse konzeptionellen Überlegungen bezüglich Skalierung. Wer hätte beispielsweise vor einem Jahr gedacht, dass bei studiVZ innerhalb von 12 Monaten an die mehrere Dutzend Millionnen Bilder verwaltete werden müssen, oder dass sich täglich mehr als eine Million Benutzer einloggen, sich gegenseitig Nachrichten schreiben oder Pinnwandeinträge machen.

kaffchen.jpg

Da werden plötzlich am lebenden Modell enorme Skalierungs-Reengineering-Projekte notwendig. Und diese sollen gut geplant werden!

Interessant ist im MySpace Bericht auch erwähnt, welche Meilensteine die Plattform durchlaufen hat. So wurde eben auch MySpace nicht wie ein normales Software Projekt systhematisch aufgebaut, sondern entstand aufgrund von bestehenden Kenntnissen von Entwicklern zuerst in Perl und nach negativen Tests in ColdFusion. Jedoch schon nach 500’000 und danach bei 2 Millionen Usern wurden interne Systemgrenzen erreicht. So brauchten beispielsweise Nachrichten die auf einer Webseite bei einem User hinterlassen wurden, bis zu 5 Minuten bis sie auch wirklich erschienen. Um diesen Problemen zu begegnen wurden die Daten auf mehrere Datenbanken verteilt und die Systemarchitektur sprich die Workload der Server enorm distribuiert.

Mit dem Ausbau der Funktionalität stieg gleichtzeitig auch die Komplexität dieser verteilten System enorm. Jim Benedetto (VP of Technology)beschreibt die verschiedenen Möglichkeiten, die MySpace in dieser Phase hatte. Eines scheint in solchen Phasen sehr verlockend zu sein: Hardware-UpScale. Das heisst Aufrüstung durch mehr Server oder schnellere Server. Dabei muss die Webseite nicht erneuert werden. Oftmals sind aber gerade diese Ausbauschritte enorm teuer. (Hier ein interessanter Bericht zu MySpace Datenbanken-Ausbau vom November 2006)

MySpace machte danach bei der Marke von 9 Millionen Usern einen markanten Wechsel der Entwicklungsstrategie: Von ColdFusion wechselte man auf ASP.NET mit den Programmiersprachen C++ und Java sowie dem .Net Framework von Microsoft. Man schrieb praktisch die ganze Software nochmals neu! Ein enorm mutiger Schritt aus meiner Sicht. Aber er hat sich gelohnt. Aufgrund der Messungen nach der Implementierung, war die Plattform fast doppelt so schnell wie die alte unter ColdFusion entwickelte. Aus meiner Sicht wahrscheinlich ein ganz beachtlicher Performance Gewinn war sicherlich auch der Effekt, dass bestehende Funktionalitäten gut analysiert und sehr effektiv programmiert werden konnten. Damit alleine schätze ich, konnte enorm viel gewonnen werden.

Aber trotz all diesen Schritten hat MySpace mit dem Wachstum auf über 27 Millionen Accounts weitere Grenzen gesprengt. Grenzen, die bis heute nur Microsoft bei ihrem SQL Server gekannt hatten. So crashte die Seite weil MySpace die Zahl der simultanen Zugänge zum SQL Server überschritt. Etwas was vorher noch niemals vorgekommen war.

Zusammenfassend kann man sagen:

1. Ein Social Network schon mal ausfallen kann. Die User sind nachsichtig und loyal. Sehr wichtig ist jedoch die Performance der Plattform. Friendster hat bewiesen, dass der Benutzer sehr wohl bei einer entsprechenden Alternative plötzlich reagieren und umsteigen kann.

2. Bei einem stark frequentierten Netzwerk entstehen enorme Lasten und einen gewaltigen Datenstrom, der verwaltet und bewerkstelligt werden muss. Die Skalierbarkeit ist dementsprechend wichtig.

3. Ein komplettes Redesign oder Reengineering sollte man bei entsprechenden Meilensteinen unbedingt ins Auge fassen und wahrscheinlich eher früher als später machen – dies spart Kosten und sichert längerfristig einen effizienteren Betrieb.

Der gesamte Bericht „Inside MySpace“ findet man hier.

3 Gedanken zu „Bis die Balken krachen!

  1. Ich glaube nicht, dass man von Beginn weg alles so aufbauen kann, dass sowohl 1’000 als auch 10 Mio. Nutzer voll skalierbar abgedeckt werden können. Aber es gibt natürlich heute Erkenntnisse aus dem Aufbau der verschiedenen Social Networks, die einige Fehler bzw. Erfahrungen einschliessen, auf die heutige Entwickler zurückgreifen können. Trotzdem – auch bei einem Reeingineering gibt es ja auch immer wieder die Möglichkeit neue Ideen gleich miteinzubauen oder zu überarbeiten. Deshalb kann oder sollte man dies wohl nie ganz ausschliessen wollen.

  2. studivz hat zwar sehr viele page impressions, aber das hat nicht viel zu sagen, da viele bestätigungsseiten eigebaut sind, auf die man verzichtet könnte. es ist ein aufgeblasenen seiten monster

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s