Microblogging Skalierungsprobleme

In letzter Zeit wird Twitter recht viel abgewatscht, weil der Dienst ziemlich instabil läuft. Das ist zwar weniger wichtig, solange man “nur” private Statements wie “Bin verkatert – erstmal’n Käffchen” schreibt, aber der Dienst wird zunehmend auch für ernsthaftere Anwendungen genutzt. Zum Beispiel für Terminhinweise von Veranstaltern oder sonstige Veröffentlichungen.

Kurz: Twitter hat alle Hände voll zu tun, den Dienst stabil und skalierbar zu machen. Von Außenstehenden wurde viel über die Ursachen der Probleme spekuliert. Die beliebtesten Vermutungen: Ruby on Rails skaliert nicht richtig und der Hoster bekommt Last und Traffic nicht in den Griff. Auf dem Entwicklerblog stellt Twitter mit dem Artikel “Twittering About Architecture” nun klar, daß beides nicht die Ursachen sind, sondern grundlegende Fragen der Softwarearchitektur gelöst werden müssen. Zudem ist die Entwicklungsabteilung personell unterbesetzt.

Eine detaillierte Beschreibung der komplexen technischen Herausforderungen für einen Microblogging-Dienst hat Eran Hammer-Lahav in einer kleinen Artikelserie “Scaling a Microblogging Service” beschrieben. Er sah sich bei seinem eigenen Start-up Nouncer mit ähnlichen Herausforderungen konfrontiert und ist daher kompetent. Er unterteilt den Dienst unabhängig von der jeweiligen Implementierung in zwei Bereiche: delivery und retrieval.

Delivery
Hereinkommende Nachrichten zu nehmen und per Instant Message, SMS oder Email an diejenigen weiterzuverteilen, die Follower sind, ist zwar nicht völlig trivial, aber dennoch vergleichweise einfach und es lässt sich leicht skalieren.

Retrieval
Das Problem und die Komplexität steckt in der Abfrage. Hammer-Lahav schreibt dazu:

“Unlike webmail services where refreshing a user’s inbox only queries a very simple data set (is there anything new in MY inbox?), refreshing a user’s home page on Twitter queries a much more complex data set (are there any new updates in ALL my friends’ pages?) and the nature of the service means that the ratio of reads to writes is significantly different from most other web services.“

Eigentlich sind die Abfragen ja noch komplexer, etwa “Gib mir die letzten 20 Nachrichten von allem meinen Kontakten die nicht gesperrt sind und die mich nicht gesperrt haben, sowie alle privaten Nachrichten an mich, absteigend sortiert nach Uhrzeit”. Das funktioniert tadellos, sonlange es nur einige tausend User und einige -zig oder hunderttausend Nachrichten handelt. Die große Menge ist das Problem: partitionierte Datenbanken, was und wie ist zu indizieren, was kann gecached werden etc.

Der Autor vertritt weiterhin die Meinung, daß ein Push-Service mit Inboxen ähnlich wie E-Mail das Problem genausowenig löst, wie ein (in letzter Zeit ja häufig diskutierter) verteilter Service; ja im Gegenteil die Probleme dann nur umso größer würden. Um das zu verdeutlichen entwirft er ein Szenario, in dem 3 User bei verschiedenen Providern (twitter, pownce und Jaiku) sind.

Wirklich interessant: Das nämlich genau das Szenario, für das ich seit kurzem ein simples Push-Protokoll entwerfe. Der Autor kommt auch tatsächlich zu den selben Punkten wie ich, z.B. echte (lokale) Accounts und virtuelle (remote) Accounts. Allerdings bewerte ich sie etwas anders.

Richtig ist: Bei einer zentralen Lösung hat twitter mit einigen Millionen Usern das Skalierungsproblem. Bei einer dezentralen Lösung hat ein Service mit einigen Millionen Usern immer noch dasselbe Skalierungsproblem plus noch einigen anderen Fallstricken, weil er von (vielen) externen Services abhängt.

Aber: Das Problem wird in der Praxis kaum noch auftauchen, wenn die meisten User auf kleineren System sind oder sogar einen eigenen Server betreiben, wie es heute bei E-Mail der Fall ist. Es interessiert mich einfach nicht, wenn Yahoo, GMX, MSN oder wer auch immer ein dickes Problem mit seinen Mailservern hat – ich bin trotzdem per Mail erreichbar. Twittern kann ich aber nur, wenn twitter funktioniert.