Original-URL des Artikels: https://www.golem.de/0910/70585.html    Veröffentlicht: 21.10.2009 11:58    Kurz-URL: https://glm.io/70585

Wie Facebook die Daten von 300 Millionen Nutzern verkraftet

30.000 Server, 25 TByte Logfile täglich und 600.000 Fotos pro Sekunde

Facebook ist groß, in jeder Dimension. Das sagt Jeff Rothschild, Vice President für Technologie bei Facebook bei einer Präsentation an der Universität San Diego und unterlegte dies mit Zahlen. Rothschild erläuterte die Architektur hinter Facebook und sprach über künftige technische Herausforderungen.

Facebook verzeichnet mit derzeit 200 Millionen aktiven Nutzern rund 200 Milliarden Pageviews pro Monat und verarbeitet täglich 3,9 Billionen Feed-Aktionen. Täglich werden mehr als 1 Milliarde Chat-Nachrichten über Facebook ausgetauscht und mehr als 100 Millionen Suchanfragen gestellt. Zudem werden wöchentlich mehr als 2 Milliarden Content-Elemente hochgeladen. Facebook Connect kommt auf mehr als 15.000 Webseiten zum Einsatz.

Dazu betreibt Facebook aktuell rund 30.000 Server, so Rothschild und betonte den großen Einfluss, den Facebooks Techniker haben: Statistisch betrachtet ist jeder Techniker bei Facebook für rund 1 Million Nutzer zuständig.

Zu den populärsten Applikationen auf Facebook zählt die Foto-Applikation mit derzeit 20 Milliarden Fotos, von denen jedes in vier Auflösungen gespeichert wird. Insgesamt hostet Facebook also rund 80 Milliarden Fotos, wobei monatlich 2 bis 3 Milliarden hinzukommen. Auch die Nachfrage ist groß: Bis zu 600.000 Fotos liefert Facebook pro Sekunde aus.

Haystack - eigenes Dateisystem für Fotos

Dabei hatte Facebook anfangs den Erfolg seiner Foto-Applikation und die damit einhergehenden Herausforderungen unterschätzt, räumt Rothschild ein. So war das System zunächst in zwei Schichten aufgeteilt: Die Upload-Schicht kümmerte sich um die eigentlichen Uploads, skalierte die Bilder und speicherte sie auf NFS-Server. Die Serving-Schicht lieferte die auf NFS-Servern gespeicherten Bilder aus. Dabei kamen kommerzielle NFS-Server zum Einsatz, doch die verfügbaren Dateisysteme waren nicht gut darin, solch große Datenmengen zu verwalten, so Rothschild. Zudem passten die Metadaten nicht in den Speicher, was zu vielen Festplattenzugriffen führte. Letztendlich war I/O das große Problem, nicht die Speicherdichte.

Um dem Herr zu werden, begann Facebook die am häufigsten abgerufenen Bilder zu cachen und über ein CDN auszuliefern. Das Cachesystem entwickelte Facebook auf Basis von Memcached und Lighty.

Durch solche und weitere Optimierungen sei es gelungen, die Zahl der physischen I/O-Zugriffe pro ausgeliefertem Bild von rund 10 auf rund 3 zu senken. Letztendlich aber entwickelte Facebook mit Haystack ein eigenes Open-Source-Dateisystem zum Speichern großer Bildermengen, das pro ausgeliefertem Bild nur noch einen I/O-Zugriff benötigt. So sei es nun möglich, rund viermal mehr Bilder mit der gleichen Hardware auszuliefern.

PHP für die Webserver

Die grundlegende Architektur der Facebook-Plattform gliedert sich in drei Schichten: ein Loadbalancer reicht Daten an Webserver weiter, die ihrerseits auf Dienste, Memcached und Datenbanken zugreifen. Bei den Webservern setze Facebook auf PHP als Scriptsprache, da PHP leicht zu lernen, zu programmieren und debuggen sei. Dem stehen hohen Runtimekosten gegenüber, denn PHP brauche viel Speicher und Rechenzeit. Zudem sei die Verbindung mit C++ eine Herausforderung und bei großer Codemenge werfe PHP gewisse organisatorische Probleme auf. Auch mache neuer Code alten langsamer, selbst wenn dieser in keinem Zusammenhang stehe, da der Initialisierungsaufwand, der bei jeder Anfrage anfällt, steige.

Um dem entgegen zu wirken, hat Facebook einige Optimierungen vorgenommen und beispielsweise den APC (Advanced PHP Cache) um Lazy-Loading, Cache-Priming und effizientere Locking-Funktionen erweitert. Zudem wurde eine eigene Memcached-Client-Erweiterung sowie Mechanismen zum asynchronen Event-Handling geschrieben. Derzeit arbeitet Facebook an einem Compiler, der PHP in C++ umsetzt, um daraus hoch optimierte ausführbare Dateien zu machen.

Die Webserver greifen auf Backendsysteme zurück, die in aller Regel in C++ implementiert werden, nutzen aber auch andere Sprachen wie Python, Ruby oder Erlang - je nachdem, welche für die aktuelle Aufgabe am besten geeignet ist. Facebooks Suchdienst ein solches Beispiel.

25 TByte Logfiles pro Tag

Ein weiteres Backendsystem ist Scribe, mit dem Facebook seine große Menge an Logfiledaten verarbeitet, denn täglich fallen rund 25 TByte an Logfiles auf den Servern an, die chronologisch konsolidiert werden müssen. Letztendlich verarbeitet ein Hadoop-Cluster mit rund 1.000 Nodes die Daten und erlaubt Analysen des Nutzerverhaltens, um herauszufinden, wie neue Funktionen von Nutzern verwendet werden.

Alle Backenddienste können über eine einheitliche Managementkosnole verwaltet werden, da sie auf dem gemeinsam genutzten Thrift basieren.

Cache als Herzstück der Architektur

Das Herzstück der Facebook-Architektur ist dessen Cache-System, denn traditionelle Ansätze sind den vernetzten Daten eines Social Network nicht gewachsen. Während auf anderen Seiten Nutzer nach ihren eigenen Daten schauen, gucken sie bei Facebook nach den Daten anderer.

Auf seinen Datenbankservern hält Facebook die Daten in normalisierter Form bereit. Nutzer werden zufällig über die Datenbankserver verteilt, ein Clustering nach Gruppen findet nicht statt. Dadurch kommt dem Caching-System zentrale Bedeutung zu, wobei Facebook auf das von Brad Fitzpatrick entwickelte Memcached setzt, das allerdings von Facebook deutlich erweitert wurde. Dies schließt auch Optimierungen am Netzwerkstack und den Ethernettreibern von Linux ein.

Im Hintergrund arbeiten tausende MySQL-Server, verteilt auf mehrere Rechenzentren. Allerdings nutzt Facebook wesentliche Funktionen einer relationalen Datenbank nicht. Beispielsweise nutzt Facebook kaum JOINs. Diese gibt es lediglich in speziellen Systemen wie der Suche, denn JOINs über die verteilten Datenbanken seien nahezu unmöglich. Anfangs liefen 20 MySQL Server auf einzelnen physischen Maschinen, nach und nach wurden diese auf mehr Server verteilt, was so aber recht einfach war.

Lösungen für die nächsten 300 Millionen Nutzer

Die Herausforderungen für Facebook seien heute größer denn je, sagte Rothschild. Ging es früher um die Frage, wie die nächste Million Nutzer untergebracht werden könne, gehe es heute um die Frage, wie mit den nächsten 300 Millionen umzugehen ist. So sucht Facebook nach einem besseren Weg, den Social Graph zu speichern, denn obwohl MySQL einen gut Dienst verrichte, sei eine relationale Datenbank dafür aus Effienzgesichtspunkten nicht ideal. Auch Themen wie Load-Balancing und die Suche unter Einbeziehung des Social Graph nennt Rothschild als wesentliche Forschungsbereiche und wirbt um talentierte Entwickler.

Rothschilds Präsentation "High Performance at Massive Scale - Lessons learned at Facebook" steht auf den Seiten der Universität San Diego als Videostream zur Verfügung. Die von Facebook als Open Source veröffentlichte Software steht unter developers.facebook.com/opensource.php zur Verfügung.  (ji)


Verwandte Artikel:
HSTS: Facebook verschlüsselt alle ausgehenden Links, wenn möglich   
(06.03.2018, https://glm.io/133157 )
Facebook veröffentlicht Tornado-Webserver   
(11.09.2009, https://glm.io/69759 )
Netzwerkdurchsetzungsgesetz: Viel weniger Beschwerden als erwartet   
(03.03.2018, https://glm.io/133125 )
Illegale Inhalte: EU-Kommission fordert Uploadfilter für alle Plattformen   
(01.03.2018, https://glm.io/133092 )
Soziales Netzwerk: Facebook bietet erweiterte Gesichtserkennung für Fotos an   
(28.02.2018, https://glm.io/133055 )

© 1997–2020 Golem.de, https://www.golem.de/