Community Spotlight: Una Thompson sorgt mit Jortage für mehr Übersicht im Fediverse

Der Schlüssel zu vielen einzigartigen Eigenschaften des Fediverse liegt in der Dezentralisierung. Sie kann aber auch dazu führen, dass Instanzen so unübersichtlich werden, dass sie sich nicht mehr verwalten lassen. Una Thompson, Mitglied des Fast Forward Programms und Betreuerin von Jortage, nutzt Fastly, um ein zentrales Problem im Zusammenhang mit der Dezentralisierung zu lösen: die Duplizierung von Inhalten. Wir haben uns mit Una zusammengesetzt, um mehr über dieses Problem und ihren Lösungsansatz zu erfahren.

Das Fediverse ist ein großartiger Ort! Es ermöglicht kleinen, aber miteinander verbundenen Communities, sich selbst zu moderieren und zu entscheiden, mit wem sie zusammenarbeiten. Es gibt Nutzern die Freiheit, ihre Daten selbst zu verwalten und zwischen Instanzen zu migrieren. Aber die Freiheit, die dezentralisierte soziale Netzwerke bieten, hat auch ihren Preis. 

Durch das Föderieren werden viele Inhalte – genauer gesagt, Medienobjekte – zwischen verschiedenen Servern hin und hergeschoben. Jedes Mal, wenn jemand etwas postet, sendet die entsprechende Instanz den Status und die Objekte an die Instanzen aller, die dieser Person folgen, und alle diese Instanzen laden diese Inhalte herunter. Anschließend lädt jede Instanz die heruntergeladenen Daten separat bei ihrem eigenen Storage-Anbieter hoch und dupliziert sie entsprechend der Anzahl der Follower der postenden Instanz.

Das ist ein kniffliges Problem, und Una Thompson hat es mit Jortage auf beeindruckende Weise gelöst. Jortage ist ein Community-Projekt, das Objektspeicher und Hosting anbietet und Poolmitgliedern zu niedrigeren Gesamtspeicherkosten verhilft, indem es den Objektspeicher dedupliziert. Damit die Geschwindigkeit der Medien nicht darunter leidet, dass das Projekt auf über 70 Instanzen rund um den Globus genutzt wird, unterstützt Fastly Jortage beim Beschleunigen von Downloads und beim Caching. Dank Fastly konnte sich Jortage die Investition in eigene Server auf der ganzen Welt ersparen, was zu weiteren Kostensenkungen führt und das Erlebnis, #CatsOfMastodon zu erkunden, schneller und ansprechender macht. :)

Hannah Aubrey: Was hat dich ursprünglich dazu bewegt, Jortage ins Leben zu rufen?

Una Thompson: Das war eines dieser Dinge, die einem einfach so einfallen, während man etwas anderes macht. Ich habe mir damals Gedanken über das Föderieren von Medien gemacht und dachte mir, dass meine Idee eigentlich gar nicht funktionieren kann. Dann habe ich aber einen Prototypen entwickelt, und alles hat bestens funktioniert. Also habe ich das Ganze skaliert und ein paar andere Instanz-Admins mit ins Boot geholt. Der Rest ist Geschichte.

Irgendwann bekam ich eine Direktnachricht von Gargron [Eugen Rochko, CEO von Mastodon], in der er mich fragte, wie es eigentlich sein könne, dass Jortage so gut funktioniert, da FFmpeg und ImageMagick (die von Mastodon zur Verarbeitung eingehender Medien verwendet werden) nicht deterministisch sind. Die ehrliche Antwort ist: Ich weiß es nicht. Eigentlich funktioniert Jortage viel zu gut. :P

Hannah Aubrey: Und wie genau funktioniert Jortage? 

Una Thompson: Die grundlegende Funktionsweise des Storage Pools ist, dass jede hochgeladene Datei mit einem Hash versehen wird und eine MariaDB Datenbank die Zuordnung von Hashes zu Pfaden speichert. Neue Dateien werden dann mit dem Hash als Dateinamen bei unserem Backend-Storage-Anbieter – Wasabi – hochgeladen. An pool.jortage.com</u>​ gerichtete Anfragen suchen in der Datenbank nach dem Pfad und geben bei einem Treffer einen Redirect zu blob.jortage.com</u>​ mit dem relavanten Hash zurück. „pool“ verweist auf einen von mir betriebenen Server und „blob“ verweist direkt auf Wasabi.

Den Storage Pool mit dem CDN zu verbinden ging relativ leicht. Das Komplizierteste an meiner Fastly Konfiguration ist der aufwendige Redirect für den Root-Pfad, der sehr spezifisch für den Storage Pool ist. Außerdem musste ich Segmented Caching</u> aktivieren, damit Jortage auch für Videos funktioniert, und das Upload-Limit bei Mastodon liegt bei 40 MB.   

Jortage basiert auf der nutzerdefinierten Software poolmgr</u>. Man könnte es also als ein Projekt bezeichnen, das auf den Schultern von Riesen steht. Ohne S3Proxy</u> und Apache JClouds</u> wäre es viel schwieriger gewesen, dieses Projekt in die Tat umzusetzen. poolmgr stellt also eine S3-kompatible API zur Verfügung, mit der Mastodon (sowie Pleroma, Akkoma, Misskey usw.) kommuniziert. Der größte Teil des Speichers einer Mastodon Instanz entfällt aber auf den S3-Anbieter, sodass knapp 70 Instanzen dennoch von Fastly profitieren. (Einige grobe Benchmarks, die ich aufgestellt habe, als ich auf die DNS-Propagierung warten musste, deuten darauf hin, dass die Gesamt-Downloadzeit von Fastly 2-5 Mal schneller ist als die unseres vorherigen Anbieters, nicht gecachte Requests eingeschlossen).

Die datenintensivsten Funktionen von Mastodon lassen sich nicht wirklich mit einem CDN lösen. Bei Dingen wie dem Jobmanager (Sidekiq) und Föderierungsanfragen ist ein CDN sogar eher ein Hindernis, wie man an all den Instanzen sehen kann, die hinter Cloudflare laufen und bei denen es immer wieder zu mysteriösen Föderierungsproblemen kommt. Und gerade bei Medien sind große Dateien keine Seltenheit.

Einige grobe Benchmarks, die ich aufgestellt habe, als ich auf die DNS-Propagierung warten musste, deuten darauf hin, dass die Gesamt-Downloadzeit von Fastly 2-5 Mal schneller ist als die unseres vorherigen Anbieters, nicht gecachte Requests eingeschlossen.

Hannah Aubrey: Glaubst du, dass es bei besonders großen Dateien eine Lösung gibt, Föderierungsanfragen und die Ausführung von Sidekiq effizienter zu gestalten?

Una Thompson: Meines Wissens gibt es noch keinen webbasierten Service, auf den man verweisen kann und den man bedenkenlos als „effizient“ bezeichnen könnte. „RESTful“ Services, die wie verrückt JSON-Dateien hin- und herschicken, sind alles andere als effizient – egal, wie man es betrachtet. Ich bin zwar definitiv keine Expertin für ActivityPub, aber im Allgemeinen ist es nicht das, was man als effizientes Protokoll bezeichnen würde. 

Deine Instanz sendet jeden einzelnen Post an alle Instanzen, die dir folgen. Das führt wiederum dazu, dass diese Instanzen an deine Instanz eine Anfrage für den Thread-Kontext stellen, was wiederum weitere Requests zur Folge haben kann. Außerdem werden deine aktuellen Profilinformationen abgefragt. Dies führt dazu, dass die Links in deinem Profil geladen werden und nach „rel=me“-Links gesucht wird, um die Verifizierung durchzuführen. Auch etwaige Anhänge werden allesamt heruntergeladen. Jede dieser Aufgaben erzeugt Jobs in der Sidekiq Warteschlange, die in der Standardkonfiguration von Mastodon aus einer sehr geringen Anzahl von Threads besteht und als ein einziger Prozess ausgeführt wird. Es steht noch nicht einmal fest, dass Sidekiq mit mehreren Prozessen möglich ist. Für viele von uns war davon zum ersten Mal in diesem Blogpost von Nora Tindall</u> die Rede. 

Natürlich bedeutet das zusätzlichen Overhead (Sidekiq verbraucht schwindelerregend hohe Speicherressourcen). Deshalb habe ich mich für die TruffleRuby Lösung interessiert, die alles in einem Prozess zusammenfasst und eine bessere GC bietet.

Wenn man das Hin- und Herschieben von Anfragen durch eifriges Pushen von Daten bei der ersten Föderation ersetzen könnte, wäre das vermutlich hilfreich. Es gibt auch noch ein weiteres Jortage Projekt, das sich mit der Linkauflösung beschäftigt: jort.link</u>.

Das liegt größtenteils daran, dass dieses Projekt auf dem Ruby Interpreter läuft und eines meiner beiläufigen Projekte darin besteht, Mastodon über TruffleRuby unter GraalVM zum Laufen zu bringen. Ich denke, dass Sidekiq von der Einführung von JIT-Kompilierung und echtem Multithreading stark profitieren würde. Durch die Festlegung auf einen globalen Interpreter ist die parallele Ausführung in herkömmlichem Ruby ziemlich fehleranfällig (dasselbe gilt für herkömmliches Python und gehört zu den größten Vorteilen von PyPy). 

Die Zentralisierung von Jortage ist zwar nicht gut für die Nachhaltigkeit, aber der Betrieb wirklich unabhängiger, skalierbarer Services kostet ein Vermögen.

**Hannah Aubrey: Was würdest du anderen Entwicklern raten, die eine Instanz einrichten möchten?**

Una Thompson: Überlegt es euch gut. Eine Instanz zu betreiben bedeutet, eine Community aufzubauen und eine Community zu betreiben, und ist ein langfristiges (im Grunde endloses) Commitment. Hinzu kommt, dass es ausgesprochen schwierig ist, eine Instanz angemessen zu moderieren. Ich betreibe eine geschlossene Instanz, aber man muss nicht lange nach Geschichten von Leuten suchen, die beim (unvorbereiteten) Betrieb einer öffentlichen Instanz ihr blaues Wunder erlebt haben.

Wenn Sie mehr über Jortage erfahren oder mit Una Thompson in Kontakt treten möchten, schauen Sie auf der Homepage</u> von Jortage vorbei und sagen Sie im Fediverse Hallo</u>.