Seite 2: Vorgehensweisen, Aufbau und Moderation

Inhaltsverzeichnis

c’t: Wie seid ihr vorgegangen, als ihr eure Instanz aufgesetzt habt?

Oswald: Ich arbeite im Bereich IT-Infrastruktur als Leiterin eines Operation-Teams, deswegen konnte ich eine Menge Vorerfahrung einbringen. Mastodon haben wir mit einem Ansible-Playbook (ein Open-Source-Werkzeug zur Automatisierung und Konfiguration, Anm. d. Red.) installiert, das rixx gefunden hatte. Das Playbook haben wir über die Jahre weiterentwickelt.

Anfänglich lief Mastodon noch in einer kleinen virtuellen Maschine mit vier Kernen und 8 GByte RAM. Die VM ist jedoch über die Jahre größer geworden. Bis Anfang 2022 war der Server schon auf 20 GByte-RAM, zehn CPU-Kerne und eine Reihe NVMe-SSDs angewachsen. Die flotten SSDs sind wichtig, weil sonst alles sehr langsam wird. Bis auf wenige Probleme mit Updates lief unsere Instanz ziemlich wartungsarm vor sich hin.

Nach dem großen Ansturm waren wir gezwungen, unsere Architektur zu überdenken und haben die Datenbank auf einen separaten Server ausgelagert. Jetzt haben wir eine VM mit dem Webinterface, dem Streaming-API und Redis als Cache sowie eine weitere VM, wo die Sidekiq-Worker laufen, die alle Jobs verarbeiten, die von intern oder extern kommen. Dazu gibt es einen externen Speicher, auf dem wir die Mediendateien ablegen. Das war eine Bedingung, um die Sidekiq-Worker auslagern zu können. Sonst hätte man ein geteiltes Dateisystem nutzen und Performanceabstriche machen müssen. Die Mediendateien liegen jetzt in einem S3-kompatiblen Object-Storage (ein skalierbarer Cloud-Speicher, Anm. d. Red.). Da setzen wir auf Minio.

c’t: Mastodon ist also keine Anwendung aus einem Guss. Welche Aufgaben erfüllen die einzelnen Komponenten?

Oswald: Der sichtbare Teil ist die Webkomponente, ein Webserver namens Puma, der in Ruby geschrieben ist. Dann gibt es das Streaming-API. Das kümmert sich darum, dass ich nicht immer die ganze Seite neu laden muss, wenn ich als Nutzer neue Toots sehen will, sondern das automatisch via WebSocket gestreamt wird. Die Redis-Datenbank dient als Cache für die Timeline und Benachrichtigungen, speichert und verwaltet aber auch Jobs für Sidekiq. Die Sidekiq-Worker verarbeiten Aktionen wie Likes und Toots, komprimieren Media-Uploads, holen Toots fremder Instanzen und generieren Link-Previews.

All diese Aktionen werden in Warteschlangen einsortiert, die dann von Workern abgearbeitet werden. Dazu kommt unser S3-kompatibler Storage, also ein Webserver mit definiertem API, auf den ich Dateien hochladen und runterladen kann.

c’t: Ist ein externer Object-Storage Pflicht oder kann man auch das lokale Dateisystem nutzen?

Oswald: Ja, das geht, aber man sollte vorher nachdenken, wohin man mit der Instanz möchte. Bei einer Instanz bis 1000 Leuten sollte das lokale Dateisystem ausreichen. Wenn ich aber eine Community habe, von der ich glaube, dass sie schnell wächst, dann sollte man das von Beginn an mitdenken. Die Architektur später umzubauen, ist schwierig. Bis Oktober letzten Jahres haben wir Dateien noch lokal gespeichert. Dann mussten wir im laufenden Betrieb umbauen und 2,4 Millionen Dateien synchronisieren. Das hat zwei Tage gedauert und währenddessen war die Instanz sehr langsam.

Es geht gerade erst los!

Kommentar: Der Peak von Mastodon ist nicht erreicht, es geht erst richtig los

c’t: Hast du noch mehr Tipps, die man beachten sollte, wenn man eine große Instanz aufziehen will?

Oswald: Wie bei jeder Software, die viele Menschen benutzen, sollte man auch bei Mastodon wissen, was man tut und sich der großen Verantwortung bewusst sein. Als Admin hat man Zugriff auf sensible Daten, und die Nutzer vertrauen einem. Deswegen sollte man unbedingt darauf achten, die Instanz sicher zu betreiben und regelmäßig Backups anlegen. Dazu sollten Security-Basics erfüllt werden, beispielsweise Zwei-Faktor-Authentifizierung für Admin-Accounts, SSH-Zugang nur mit passendem Schlüssel und man sollte darauf achten, Mastodon und die restliche Software auf dem Server aktuell zu halten.

Abgesehen vom technischen Aspekt ist die Moderation sehr wichtig. Ich würde niemandem empfehlen, eine Instanz mit mehr als hundert Leuten allein zu betreiben. Das kann dazu führen, dass die Moderation nicht hinterherkommt und die Instanz beispielsweise eine Anlaufstelle rechter Trolle wird. Wenn daraufhin andere Instanzen deinen Server blocken, war all die Arbeit umsonst. Ab 1000 aktiven Nutzerinnen und Nutzern sollte man sich Hilfe holen, beispielsweise um sich bei Moderationsentscheidungen eine zweite Meinung einzuholen. Grundsätzlich würde ich von Instanzen mit mehr als 20.000 Accounts abraten, auch weil dann der dezentrale Ansatz an seine Grenzen stößt.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes Video (Kaltura Inc.) geladen.

Videos immer laden Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Kaltura Inc.) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

c’t: Wie kann man für ein gutes Wohlfühlklima auf seiner Instanz sorgen?

Oswald: Wo viele Menschen zusammenkommen müssen unterschiedliche Wünsche und Ansprüche vermittelt werden. Das zu moderieren ist schwierig und man kann sich als Admin sicher sein, dass irgendwer immer mit einer Entscheidung unzufrieden ist. Als Nutzer kann man den Admins das Leben leichter machen, indem man die Instanzregeln liest und sich daran hält. Wenn ein Post klar gegen die Instanzregeln verstößt, dann sollte man ihn melden und eine Beschreibung des Problems mitliefern. Wenn es kein gravierendes Problem ist, dann reicht es meistens auch, den betreffenden Account einfach selbst zu blocken oder stumm zu schalten.