Verteiltes Caching mit memcached

Speicherstadt

Hinter dem klangvollen Namen Memcached versteckt sich ein hoch-performantes, verteiltes Caching-System. Obwohl weitgehend anwendungsneutral ausgelegt, puffert es meist in dynamischen Web-Anwendungen die zeitraubenden Datenbankzugriffe. Auf seine Hilfe zählen selbst Branchengrößen, wie Slashdot, Fotolog.com und natürlich sein Vater LiveJournal.com.

Brad Fitzpatrick war frustriert: Zwar lief die von ihm gegründete und maßgeblich mitprogrammierte Blogger-Plattform LiveJournal.com schon auf über 70 potenten Maschinen, ließ aber bei der Geschwindigkeit noch arg zu wünschen übrig. Selbst die bis zu 8 GByte großen Caches der Datenbankserver verschafften kaum Linderung. Es musste also dringend Abhilfe her. Die in solchen Fällen üblichen Gegenmaßnahmen bestanden meist darin, bestimmte Inhalte vorab zu generieren oder einmal ausgelieferte Seiten komplett in einem Cache zu parken. Elemente, die auf mehreren Seiten vorkommen, speichert man damit jedoch doppelt und müllt so langsam den Cache unnötig zu. Sollte der Hauptspeicher knapp werden, könnte man zwar auf Festplatten ausweichen, die aber wieder relativ langsam sind.

In Brad Fitzpatricks Augen musste ein spezielles, neuartiges Cache-System her. Eines, das einzelne Objekte einer Seite separat speicherte und langsame Festplattenzugriffe vermied. Schon nach kurzer Zeit gab er die Suche nach einer bestehenden Lösung erfolglos auf, setzte sich hin und entwarf seinen eigenen Cache. Fitzpatrick hatte auf seinen Servern überall noch freien Hauptspeicher, den er unbedingt für sein Vorhaben einspannen wollte. Zudem sollten alle Maschinen gleichzeitig auf den Cache zugreifen können und geänderte Inhalte jedem Teilnehmer unverzüglich zur Verfügung stehen. Heraus kam schließlich Memcached, das die LiveJournal-Datenbank nach seinen Angaben schlagartig um über 90 Prozent entlastete, gleichzeitig die Seitenladezeiten für die Benutzer reduzierte und nebenbei noch zu einer besseren Ressourcenauslastung der eingesetzten Maschinen führte. Dies alles geschah vor rund vier Jahren. Nach verschiedenen Auf- und Verkäufen von LiveJournal.com kümmert sich heute Danga Interactive um die Weiterentwicklung von Memcached [1]. An der BSD-Lizenz, der das Caching-System seit Anbeginn untersteht, hat sich glücklicherweise nichts geändert.

Kleidertausch

Der Aufbau eines verteilten Caches mit Memcached ist so einfach wie simpel: Auf jedem Server, auf dem man etwas Hauptspeicher für den gemeinsamen Cache abknapsen kann, startet man einen memcached Daemon. Wer mag, darf auf einer Maschine auch gleich mehrere von ihnen aktivieren. Das ist insbesondere auf Betriebssystemen nützlich, die einem Prozess immer nur einen bestimmten Teil des gesamten, verfügbaren Hauptspeichers zugestehen. Dort startet man einfach mehrere Daemons, die jeweils den für sie maximal möglichen Speicher akquirieren und so doch noch den gesamten freien Platz dem Cache zur Verfügung stellen.

Die Schnittstelle zur eigenen (Web-)Anwendung bildet eine spezielle Client-Bibliothek. Sie nimmt die zu speichernde Information entgegen und legt sie unter einem frei wählbaren Schlüsselwort auf einem der vorhandenen Server ab (Abbildung 1). Welcher Memcached-Daemon dabei letztendlich die Daten erhält und in seinem Hauptspeicher parken darf, bestimmt die Client-Bibliothek über ein ausgeklügeltes, mathematisches Verfahren.

Bildlich kann man sich den ganzen Ablauf wie die Garderobe in einem Theater vorstellen: Man gibt seinen Mantel der Dame hinter dem Tresen und nennt ihr eine Nummer. Die Garderobiere nimmt den Mantel entgegen, sucht mit ihm in der Hand den passenden Ständer und hängt das Kleidungsstück schließlich an den Haken mit der entsprechenden Nummer. Nach der Vorstellung läuft das ganz Spiel rückwärts ab: Man nennt der Garderobiere – Pardon, der Client-Bibliothek – wieder die Nummer, woraufhin diese abermals zum passenden Daemon stiefelt, dort die Daten vom Haken nimmt und schließlich bei ihrer Anwendung abliefert.

Das ganze Konzept erinnert frappierend an eine verteilte Datenbank oder ein verteiltes Dateisystem. Bei der Arbeit mit Memcached sollte man jedoch immer im Hinterkopf behalten, dass es sich hier um einen reinen Cache handelt. Mit anderen Worten: Die Garderobiere ist unzuverlässig und vergesslich. Reicht beispielsweise der Platz irgendwann nicht mehr für neue Elemente aus, wirft ein Daemon die am wenigsten nachgefragten Daten über Bord und schafft so neuen Platz. Ähnliches passiert, wenn ein Memcached-Daemon ausfällt – in diesem Fall sind sogar sämtliche von ihm gespeicherten Informationen futsch. Es ist also durchaus möglich, dass man am Ende der Vorstellung seinen Mantel nicht mehr zurück bekommt. Die Anwendung ist dann gezwungen, wieder einmal der Datenbank einen kleinen Besuch abzustatten. Redundanz kennt das memcached System nicht. Muss es auch nicht, denn schließlich ist es nur ein Cache, der schnell Informationen zwischenspeichern und wieder rausrücken muss. Gleichsam ist es unmöglich, über alle Elemente des Caches zu iterieren oder den gesamten Zwischenspeicher ohne Verrenkungen auf die Festplatte zu bannen.

Lauschangriff

Den memcached Daemon stellt Danga Interactive auf einer eigenen Homepage zum Download bereit [1]. Als einzige Voraussetzung verlangt er nach der »libevent« -Bibliothek nebst passendem Entwicklerpaket. Den Daemon selbst übersetzt der bekannte Dreischritt:

configure
make
sudo make install

Einige größere Distributionen verstecken auch fertige, meist jedoch veraltete Memcached-Pakete in ihren Repositories. Nach erfolgreicher Installation aktiviert beispielsweise dieser Befehl den Daemon:

memcached -d -m 2048 -l 192.168.1.111 ↩
-p 11211 -u USERNAME

Damit startet Memcached als Daemon (»-d« ), der auf dieser Maschine »2048« MByte Arbeitsspeicher für den gemeinsamen Cache abknapst (»-m 2048« ). Auf Anfragen von Clients wartet er geduldig unter der IP-Adresse »192.168.1.111« an Port »11211« . Schließlich muss er noch den Benutzernamen erfahren, unter dem er künftig seine Arbeit verrichten soll. Wenn man den Daemon mit der aktuell eingeloggten Benutzer-ID starten möchte, fällt das Anhängsel »-u« einfach weg. Sicherheitsexperten dürften angesichts des letzten Satzes die Haare zu Berge stehen: Standardmäßig darf jeder Benutzer des Linux-Systems einen eigenen Memcached-Daemon starten. Wer das verhindern möchte, muss entsprechende Vorkehrungen treffen und beispielsweise die Zugriffsrechte entziehen. Dies ist nur eine von mehreren Sicherheitsfragen, denen Memcached bewusst aus dem Weg geht (dazu gleich mehr).

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Systemstart mit Systemd unter Linux

In fast allen großen Linux-Distributionen kümmert sich mittlerweile Systemd um den Systemstart. Der SysV-Init-Ersatz geht nicht nur besonders flott zu Werke, er schmeißt auch die alten kryptischen Startskripte über Bord. Linux-Administratoren müssen deshalb früher oder später umlernen. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Ausgabe /2014

Was halten Sie von Zertifizierungen, die Fachkenntnisse und Fertigkeiten nachweisen?

  • Sie sind in der Praxis nutzlos
  • Sind für uns ein wichtiges Einstellungskriterium
  • Liefern einen Anhaltspunkt für die Qualifikation

Microsoft Azure