Wer das heutige Netz kennt, weiß, dass sich die Aufmerksamkeit dank Social Media in Sekundenbruchteilen auf einen Punkt konzentrieren kann. Für diese Konzentration braucht es nicht mal einen Shitstorm. Ereignisse wie das Bekenntnis des ehemaligen Bundesligaprofis Thomas Hitzelsberger zu seiner Homosexualität oder das tragische Attentat auf das Satiremagazin Charlie Hebdo vor einigen Wochen führten spontan zu weit mehr als doppelt so vielen Anfragen als üblich. Eine Situation, in der das gängige Konzept der horizontalen und vertikalen Skalierung – also bessere und mehr Rechner – nicht mehr funktioniert.
Ein solches System funktioniert gut, solange dessen Lastanforderung linear wächst. Man plant es so, dass es zunächst das Doppelte der Normallast aushält. Wenn sich die Lastanforderungen erhöhen, stellt man nach und nach neue Rechner dazu oder baut ältere Maschinen aus, um sie zu ersetzen.
Die Benutzer von ZEIT ONLINE erwarten, dass die Seite gerade bei ungewöhnlichen Nachrichtenlagen verfügbar ist. Dieses Ziel erreichen wir heute nur, weil wir Varnish einsetzen. Varnish ist ein HTTP-Accelerator, der Anfragen via HTTP durch eine in der IT sehr gängige Technik beschleunigt: Caching.
Seit der Version 2.0 ist Varnish bei ZEIT ONLINE im Einsatz. Derzeit ist Version 3 im Betrieb. Im letzten Jahr erschien Version 4. Als ZEIT ONLINE begann, Varnish einzusetzen, war es ein recht junges Projekt von FreeBSD Comitter Poul-Henning Kamp. Entwickelt für die norwegische Zeitung Verdens Gang, um die Auslieferungsgeschwindigkeit des Online-Angebots zu verbessern. Das ist der zweite große Vorteil von Varnish: Das System hält nicht nur mehr Last aus, sondern wird auch schneller.
Das Projekt selbst steht unter der BSD-Lizenz. Es handelt sich also um freie Software. Alle gängigen Linuxdistributionen bieten mittlerweile eine leicht installierbare Version von Varnish über ihre Paketserver.
Varnish ist von außen betrachtet zunächst einmal ein reverse proxy. Das bedeutet, dass er HTTP-Requests entgegennimmt und weiterverteilt. Eine Fähigkeit, die sich Varnish mit etlichen anderen HTTP-Servern teilt, wie zum Beispiel dem weitläufig bekannten Apache.
Genutzt werden reverse proxys gern, um verschiedene Dienste unter einer Domain zu subsummieren. Bei ZEIT ONLINE wird diese Fähigkeit unter anderem für das Freitextblog genutzt. Mit ein bisschen Konfiguration können wir das Blog unter www.zeit.de/freitext verfügbar machen, obwohl es eigentlich auf einem ganz anderen Server mit der Domain blog.zeit.de gehostet wird. Solche Konfigurationen sind Alltag für Systemadministratoren. Sie beschleunigen jedoch nichts.
Genau an diesem Punkt wendet Varnish jedoch einen einfachen Trick an: Es merkt sich für jeden HTTP-Request die Antwort des Backends, also die Antwort des Servers, an den es den Request schickte, und speichert diese mit einem eindeutigen Schlüssel (genannt hash key) in einer Datenstruktur im Hauptspeicher (RAM). Bei einem weiteren Request auf eine so gespeicherte URL wird dann erneut der gleiche Schlüssel erzeugt, aus der Datenstruktur aufgerufen und direkt beantwortet. Die Anfrage wird also nicht mehr an ein Backend weitergeleitet, sondern direkt aus dem RAM bedient. Dies ist ein bemerkenswerter Performancegewinn, da wir davon ausgehen können, dass normalerweise für jeden Request erst eine Antwort berechnet werden muss. Bei ZEIT ONLINE macht dies zwar ein vom eigentlichen CMS getrennter Anwendungsserver, was schnell einige hundert Millisekunden beansprucht. Varnish schafft es in einem Bruchteil der Zeit.
Da im Netz nichts für die Ewigkeit ist, kann die Geschichte hier nicht enden. Sekündlich werden Inhalte erneuert oder veröffentlicht, eine gecachte URL muss also aktualisiert werden können. Hier macht sich Varnish das HTTP-Protokoll zunutze, welches vorsieht, dass eine Response (also das Gegenstück zu einem Request) beispielsweise mit einem Expires-Header angibt, wie lange sie gültig ist. Erlischt diese Gültigkeit, wird sie von Varnish als invalid markiert. Man spricht von einer Invalidierung. Kommt nun ein neuer Request, wird Varnish diesen nicht mehr aus dem Hauptspeicher bedienen, sondern genau das Backend fragen, von dem ursprünglich die passende Response kam. Anschließend wird der Hauptspeicher mit der neuen Response aktualisiert.
Neben der zeitgesteuerten Variante ist es außerdem möglich eine Resource (also zum Beispiel einen Artikel) direkt aus dem Cache zu entfernen. Hier hat sich der Terminus PURGE-Request etabliert, obwohl der HTTP-Standard diese Methode eigentlich nicht vorsieht. Ein PURGE-Request ist ein normaler GET Request mit einem Pragma: no-cache und einem Cache-Control: no-cache Header. Also das, was ein Browser sendet, wenn man einen Shift-Reload macht. Will man nicht, dass jeder Benutzer so den Cache invalidieren kann – da dies schnell die Perfomance des Servers beeinträchtigen könnte – schränkt man diese Requests mit einer IP-Range ein und steuert diese Requests dann zum Beispiel über das CMS.
Für solche Konfigurationen hat Varnish eine eigene Domain Specific Language (DSL), genannt Varnish Configuration Language (VCL). Hier handelt es sich um eine dem C-Dialekt nahe Sprache, die daher für alle, die imperative Programmierung gewohnt sind, leicht lesbar ist. Gegenüber tabellarischen oder XML basierten Konfigurationskonstrukten ist dieser Ansatz auch deutlich intuitiver.
Die VCL bietet zunächst die Möglichkeit, Backends zu definieren. Gibt es für einen Zweck mehrere Backends, zum Beispiel solche, die Bilder ausliefern, können diese mit einem Director in einen Lastverbund genommen werden. Für oben erwähnte IP-Range gibt es die acl Direktive, die access control list.
Die Stärke der VCL liegt jedoch darin, dass man mit ihr innerhalb des oben abgebildeten Zyklus in jede einzelne Phase eingreifen kann, um ein spezielles Backend auszuwählen oder Request und Response zu manipulieren.
In der Phase vcl_recv steht der reine Request zur Verfügung. Die mobile Weiche von ZEIT ONLINE wird beispielsweise größtenteils in dieser Phase realisiert. Anhand des User-Agent-Header wird ausgewertet, ob der Benutzer die klassische Desktopseite oder eine Mobilansicht bekommt. Natürlich muss für beide Ansichten hier jeweils ein Objekt im Cache existieren und daher benötigen beide Seiten einen eigenen Hash, obwohl sie sich die gleiche URL teilen. Per default erstellt Varnish einen Hash aus URL und Host-Header. In der Phase vcl_hash können wir die Erzeugung dieses Werts manipulieren. In vcl_fetch sind bereits die Antwortheader des Backends da. Hier könnte man nun noch eingreifen und zum Beispiel eine Ablage im Cache (vcl_hit) verhindern – oder einen sogenannten Restart des Requests auslösen, falls die Antwort des Backends nicht die erwartete ist.
Die VCL ist ein Schlüsselfeature, da Varnish mit ihrer Hilfe bedienbar wird. In der ZEIT-ONLINE-Technik hat ein Großteil der Entwickler in Backend und Frontend bereits die zentrale VCL unserer Auslieferungsserver bearbeitet und weiterentwickelt. Varnish selbst läuft so zuverlässig und Ressourcen sparend, dass sich die Software mittlerweile zu einem Eckpfeiler in der RESTful basierten Architektur von ZEIT ONLINE entwickelt hat. Eine Bedeutung, die mit dem bevorstehenden Update auf Version 4 sicher weiter ausgebaut wird.
Dies war der erste Teil einer kleinen Serie, in der wir darstellen, warum wir Varnish einsetzen und schätzen. Im nächsten Teil werden wir auf Hilfsprogramme eingehen, die mit Varnish ausgeliefert werden – allen voran das Programm Varnishtest. Ron Drongowski ist Teamleiter Backend bei ZEIT ONLINE.