Digg Architecture

Original: http://highscalability.com/digg-architecture Dienstag, 7. August 2007 01.28
Author: Todd Hoff
Übersetzung: Sebastian Wallroth

Der Traffic, der von Diggs über 1,2 Millionen für ihren Informationshunger berühmten Benutzern generiert wird, kann eine nicht vorbereitete Webseite wegen ihrer CPU-, Speicher und Bandbreitenbeschränkungen kopfüber zum Absturz bringen. Wie kommt Digg mit dieser Last zurecht?

Seite: http://digg.com

Informationsquellen

• Wie Digg.com seinen LAMP-Softwarestapel benutzt, um weiter zu skalieren
• Die Skalierungs- und Leistungsfähigkeit von Diggs PHP

Plattform

• MySQL
• Linux
• PHP
• Lucene
• APC PHP Accelerator
• MCache

Die Fakten

• Gestartet Ende 2004 mit einem einzelnen Linux-Server mit Apache 1.3, PHP 4 und MySQL 4.0 mit der Standard-MyISAM Speicherengine
• Über 1,2 Millionen Benutzer
• Über 200 Millionen Seitenaufrufe pro Monat
• 100 Server in mehreren Datenzentren
• 20 Datenbankserver
• 30 Webserver
• einige Suchserver mit Lucene
• der Rest dient der Mehrfachverfügbarkeit (Redundanz)
• 30 GB Daten
• Keine der Skalierungsherausforderungen hatte etwas mit PHP zu tun. Die größten Aufgaben, denen Digg gegenüberstand, hatten alle etwas mit der Datenbank zu tun.
• Die leichtgewichtige Natur von PHP erlaubte es Digg Berechnungsaufgaben aus der Datenbank nach PHP zu verlagern, um die Skalierung zu verbessern. eBay macht das in radikaler Weise. Sie haben nahezu alle Arbeit aus der Datenbank in die Anwendung verschoben, einschließlich von Joins, einer Operation, die normaler Weise als Job der Datenbank angesehen wird.

Was steckt drin

• Vorn ein Lastverteiler (load balancer), der die Anfragen an die PHP-Server schickt
• Eine MySQL-Master-Slave-Installation
• transaktionslastige Server benutzen die InnoDB-Speicherengine
• OLAPlastige Server benutzen die MyISAM-Speicherengine
• Memcached wird für das Caching verwendet
• Sharding wird verwendet, um die Datenbank in mehrere kleiner zu zerlegen
• Diggs Anwendungsmuster macht es ihm leicht, zu skalieren. Die meisten Leute sehen sich nur die ersten Seiten an und verlassen Digg dann wieder. Deshalb sind 98% der Datenbankzugriffe bei Digg Lesezugriffe. Mit diesem Schwerpunkt der Arbeiten muss sich Digg keine Gedanken über die komplexe Arbeit des Entwurfs von Schreibzugriffen machen, was es Digg viel einfacher macht, zu skalieren.
• Digg hatte Probleme mit seinem Speichersystem, weil es Schreibzugriffe als abgeschlossen meldete, die es aber noch nicht waren. Kontroller tun dass, um die gefühlte Leistungsfähigkeit zu erhöhen. Das führt jedoch zu einem gigantischen Leck in der Datenintegrität. Das ist ein wirklich weit verbreitetes Problem und kann schwer zu beheben sein, abhängig von den Hardwaregegebenheiten.
• Um die Datenbanklast zu verringern, verwendet Digg den APC PHP Accelerator MCache.
• Man kann PHP mit eine Kombination aus Apaches 2 worker threads, FastCGI und einem PHP Accelerator so konfigurieren, dass es nicht bei jeder Anfrage parst und kompiliert. Beim ersten Laden einer Seite wird der PHP-Code kompiliert, so dass jeder weitere Aufruf viel schneller ist.

Gelernte Lektionen

• Verbessere MySQL mit der Wahl der richtigen Datenbankengine. Verwende InnoDB, wenn Du Transaktionen brauchst und MyISAM, wenn nicht. Zum Beispiel können Transaktionstabellen auf dem Master MyISAM als Nur-Lesen-Slave verwenden.
• An einem Punkt ihrer Wachstumskurve konnte Digg nicht mehr durch das Hinzufügen von mehr RAM wachsen, deshalb musste es durch die Architektur wachsen.
• Die Leute beschweren sich oft über die Langsamkeit von Digg. Das liegt vielleicht eher an Diggs riesigen JavaScript-Bibliotheken als an Diggs zu Grunde liegender Architektur.
• Ein Weg, wie Digg skaliert, ist, dass es genau bedenkt, welche Anwendung es in seinem System installiert. Digg passt genau auf, damit keine Anwendungen installiert werden, die zuviel CPU-Last erzeugen. Digg verwendet ganz klar eine Standard-LAMP-Architektur, aber ich denke es gibt noch einen interessanten Punkt. Entwickler haben oft eine Riesenmenge cooler Features, die sie installieren wollen. Aber diese Features können eine Infrastruktur lahm legen, wenn die Infrastruktur nicht zusammen mit den Features wächst. Also stelle die Features zurück, bis dein System mit diesen Features umgehen kann. Das könnte man mit Kapazitätsplanung machen, etwas, das Flickr in seinem Skalierungsprozess betont.
• Glaubst Du, Digg würde, weil es, um seine Infrastruktur nicht zu belasten, neue Funktionen begrenzt, Boden an sich schneller entwickelnde soziale Lesezeichendiesnte verlieren? Vielleicht könnte, wenn Digg seine Infrastruktur einfacher skalieren könnte, es Features schneller hinzufügen, was ihm gegenüber seiner Konkurrenz helfen würde? Andererseits macht es auch nicht viel Sinn, Features nur hinzuzufügen, weil man es kann.
• In der Datenbankschicht liegen die größten Skalierungs- und Leistungsprobleme, die man finden kann und das unabhängig von der Programmiersprache. Du wirst auf sie treffen, egal ob Du Java, PHP, Ruby oder deine Lieblingssprache verwendest.