Was ist Varnish?
Varnish Cache ist ein HTTP-Beschleuniger: ein Reverse Proxy, der vor deinen Webservern steht und Antworten im Arbeitsspeicher hält. Kommt eine Anfrage, die er schon kennt, antwortet er direkt, und deine Anwendung erfährt nichts davon. Antworten kommen in deutlich unter einer Millisekunde zurück, denn Ausliefern aus dem Arbeitsspeicher ist alles, was dabei passiert.
Konfiguriert wird er in einer eigenen Sprache, VCL, was näher am Schreiben eines kleinen Programms liegt als am Ausfüllen von Einstellungen. Daher kommen sowohl seine Mächtigkeit als auch sein Ruf.
Was sich damit ändert
Die interessante Zahl ist nicht, wie schnell eine zwischengespeicherte Antwort kommt. Es ist die Last, die den Ursprung nie erreicht.
Eine Site, auf der die meisten Anfragen dieselben paar hundert Seiten betreffen und diese Seiten für die meisten Besuchenden identisch sind, kann den grössten Teil ihres Verkehrs ausliefern, ohne Anwendungscode auszuführen. Deine Datenbank sieht einen Bruchteil der Abfragen. Deine Anwendungsserver hören auf, der Engpass zu sein. Lastspitzen treffen einen Cache statt eine Laufzeitumgebung.
Deshalb taucht Varnish oft nach einem Vorfall auf. Das Muster ist vertraut: eine Seite wird breit geteilt, die Site geht in die Knie, und jemand rechnet nach, dass neunzig Prozent dieser Anfragen einem einzigen Artikel galten, der sich seit einer Woche nicht geändert hatte.
VCL, und warum das zählt
Die meisten Caches lassen dich Regeln konfigurieren. Varnish lässt dich sie schreiben.
VCL gibt dir Kontrolle darüber, was wie lange zwischengespeichert wird, welche Cookies und Header beim Entscheid ignoriert werden, ob zwei Anfragen gleich sind, wie Anfragen normalisiert werden, damit sie denselben Cache-Eintrag treffen, wie mit einem ausfallenden Backend umzugehen ist und wie Anfragen und Antworten im Durchlauf verändert werden.
Diese Flexibilität ist wirklich nützlich, denn echte Sites haben sperrige Anforderungen, die eine Einstellungsseite nicht ausdrücken kann. Zugleich liegt darin der ehrliche Nachteil: VCL ist Code. Er braucht Review, Tests und jemanden, der ihn versteht, und ein feiner Fehler darin cached entweder gar nichts oder, viel schlimmer, liefert die Seite einer Person an eine andere aus.
Wann Varnish passt
- Lastige Lesezugriffe auf geteilte Inhalte. Nachrichten, Kataloge, Dokumentation, Marketing-Sites. Je mehr Besuchende dieselben Bytes sehen, desto besser wirkt es.
- Infrastruktur am Ursprung, die du schützen willst, aus Kostengründen oder für die Stabilität.
- Cache-Regeln, die die Konfiguration eines CDN nicht ausdrücken kann. Das ist der stärkste Grund, selbst zu betreiben: wenn die Logik wirklich deine ist.
- Inhalte, die in deiner Rechtsordnung bleiben müssen, wo der Weg durch ein fremdes Netz genau das ist, was du vermeiden willst.
Wann ein CDN die bessere Antwort ist
Das gehört auf eine Seite über Varnish klar gesagt.
Ein CDN legt zwischengespeicherte Inhalte an viele Orte in der Nähe deiner Nutzenden. Varnish ist ein Cache an einem Ort, standardmässig dort, wo dein Ursprung steht. Wenn deine Besuchenden geografisch verteilt sind und die Latenz das Problem ist, schlägt Verteilung einen einzelnen schnellen Cache, und ein CDN ist weniger zu betreiben.
Welches CDN, zählt weniger als der Entscheid, eines zu nutzen. Cloudflare, Fastly und Akamai lösen das Verteilungsproblem alle, und für eine Schweizer oder mehrgleisige CDN-Lösung deckt swiss-cdn.ch diese Seite ab.
Ausschliessen tun sich beide auch nicht. Verbreitet ist ein CDN am Rand und Varnish vor dem Ursprung, wo jedes das tut, worin es gut ist.
Wann es gar nicht passt
Personalisierte Seiten. Wenn jede Antwort pro Person anders ist, gibt es wenig zu teilen, und die Trefferquote bricht ein. Teilweise Techniken gibt es, und sie sind Arbeit.
Schreiblastige Anwendungen. Caching hilft beim Lesen. Eine API, die vor allem Daten entgegennimmt, gewinnt wenig.
Wenn niemand die VCL verantworten kann. Eine ungepflegte Cache-Konfiguration altert schlecht und fällt auf verwirrende Art aus.
Was der Betrieb verlangt
- Die Invalidierung ist der schwierige Teil. Zu entscheiden, was zwischengespeichert wird, ist einfach. Dafür zu sorgen, dass eine Seite sich zeitnah aktualisiert, wenn sich der Inhalt dahinter ändert, ohne alles zu verwerfen, ist die eigentliche Entwurfsarbeit.
- Den Arbeitsspeicher dimensionieren. Der Cache liegt im RAM. Zu klein, und die Trefferquote sinkt ohne Vorwarnung, zu gross, und du bezahlst Arbeitsspeicher, den du nicht nutzt.
- Kaltstarts. Ein neu gestartetes Varnish hat einen leeren Cache, und alle Anfragen gehen auf einmal an den Ursprung. Wenn der Ursprung den vollen Verkehr nicht trägt, brauchen Neustarts Sorgfalt.
- VCL unter Versionskontrolle, geprüft wie jeder andere Code, denn genau das ist es.
- Die Trefferquote beobachten. Ein Cache, der still danebengreift, ist schlechter als keiner: du zahlst den Umweg und bekommst keinen Nutzen.
Wo VSHN ins Bild kommt
VSHN ist das Schweizer Kompetenzzentrum für Varnish Cache und arbeitet an Architektur, VCL-Entwurf und Performance-Optimierung für Varnish-Installationen.
Die erste Frage, die wir meist stellen, lautet, ob Varnish für deine Lage das richtige Werkzeug ist. Denn bei einem verteilten Publikum mit geradlinigen Cache-Regeln lautet die Antwort oft: ein CDN und weniger Infrastruktur. Wo die Regeln wirklich deine sind oder der Inhalt bleiben muss, wo er ist, ist es dieses Werkzeug.