1
 
 
Profil
In deinem persönlichen Profilbereich kannst du den Status deiner Bewerbung einsehen, unvollständige Bewerbungen zwischenspeichern und aktuelle News und Events einsehen
EinloggenRegistrieren
19. März 2015

Varnish Developer Day

Betrieb
von
0 Kommentare
 

Worum geht es in dem Artikel?

Am 6. März veranstalteten wir den Varnish Developer Day VDD in unserem Loft 6. Wir sind stolz darauf, der Community einen Ort zu bieten, an dem sie sich treffen und das Open-Source-Projekt Varnish unterstützen kann.

Warum haben wir das gemacht?


Varnish ist eines der wichtigsten Softwareprodukte, die wir in otto.de integriert haben, um unseren Shop schnell zu machen und um unsere Geschäftsziele zu erreichen. Da wir eine "shared nothing" -Softwarearchitektur haben, brauchen wir mindestens ein zentrales System, in dem alles zusammenläuft. Wie soll jede unserer unabhängigen Anwendungen HTTP-Anfragen erhalten? Ein Reverse Proxy erfüllt diese Aufgabe natürlich.

Wir müssen entscheiden, welches vertikale System für welche Anfragen zuständig ist. Und selbst dann, als wir von Intershop auf unsere eigene, maßgeschneiderte Lösung umgestiegen sind, hatten wir sehr viele veraltete Links in Lesezeichen oder anderen Websites, die nicht in 404 enden sollten. Daher verwenden wir Varnish und seine leistungsstarke Varnish Configuration Language VCL, um Anfragen auf der Grundlage von URL-Pfadkomponenten weiterzuleiten. In der VCL ist es sehr einfach, eine Routing-Logik auf der Basis von URLs zu implementieren, zum Beispiel

# route any otto.de/tesla requests to the tesla backend
if (req.url ~ "^//?tesla(/|$)") {
  set req.backend_hint = TESLA.backend();
}

Header Rewriting


Da es mit VCL möglich ist, Regex-Vergleiche gegen jeden Header in der Anfrage und der Backend-Antwort durchzuführen, habt ihr die volle Kontrolle über euren HTTP-Verkehr. Wir haben mit unseren vertikalen Systemen vereinbart, Cookies in verschiedene HTTP-Header umzuwandeln, wenn die vertikalen Systeme auf eine bestimmte Weise reagieren müssen. Um Komplexität zu vermeiden, müssen unsere vertikalen Systeme keine Cookie-Header lesen und parsen - es reicht aus, HTTP-Header-Felder zu verarbeiten. Ihr könnt ein Cookie einfach in einen neuen Header in VCL abtrennen:

import re;
sub vcl_init {
  awesome_regex = new re.regex("\b(awesome_cookie\s*=\s*\w+)");
}
sub convert_awesome_cookie_to_header {
  if (awesome_regex.match(req.http.Cookie)) {
    set req.http.X-Awesome = re.backref(1, "NOMATCH");
  }
}
sub vcl_recv {
  call convert_awesome_cookie_to_header;
  ...
}

VMODs


Im obigen Beispiel verwenden wir ein VMOD re, um Rückverweise mit einer Syntax zu behandeln, die einfacher ist als in der Standard-VCL. VMODs sind Erweiterungsmodule für die VCL, die von Dritten außerhalb der Varnish-Distribution entwickelt werden können. Mit VMODs könnt ihr der VCL Fähigkeiten hinzufügen, die für einen bestimmten Anwendungsfall fehlen könnten; ihr findet viele VMOD-Lösungen im Varnish VMOD-Verzeichnis.

Zentrale Logik


Wenn die unabhängigen vertikalen Systeme eine gemeinsame Anforderung haben, werden wir oft gebeten, diese in VCL zu implementieren. Dies wird Teil unseres Vertrags zwischen dem Betriebsteam und den Softwareentwicklungsteams. Wir betreiben otto.de unter Wahrung der Privatsphäre und des Datenschutzes für unsere Kunden, daher liefern wir alles über ssl/tls aus. Wir leiten alle direkten Zugriffe über http auf https innerhalb von Varnish um, indem wir VCL-Code wie diesen verwenden:

sub http_to_https_redirect {
  if (req.http.X-Https != "true") {
    set req.http.X-Redirect = "https://" + req.http.host + req.url;
    return (synth(601, req.http.X-Redirect));
  }
}
sub vcl_recv {
  call http_to_https_redirect;
  ...
}
sub vcl_synth {
  if (resp.status == 601) {
    set resp.http.Location = resp.reason;
    set resp.status = 301;
    set resp.reason = "Moved Permanently";
    return (deliver);
  }
}

ESI


Otto.de verwendet ESI für die Seitenkomposition ESI ist ein Mittel, um HTML-Seiten mit Fragmenten aus anderen HTTP-Antworten zu komponieren. Auf unserer Website gibt es einen Navigations-Header, der in fast allen unseren Seiten enthalten ist. Wenn unser Shop angefordert wird, sieht die Antwort für Varnish etwa so aus (als stark vereinfachter HTML-Quelltext:

<html>
  <head><title>otto.de</title></head>
  <body>
    <esi:include src="/navigation/header" />
    <p>this is a storefront</p>
  </body>
</html>

Wenn Varnish diese Antwort analysiert, erkennt es das esi:include-Tag und erzeugt eine neue HTTP-Anfrage, um den Inhalt der Navigationskopfzeile zu erhalten. Natürlich gibt es auch andere Technologien wie AJAX, um Fragmente im DOM zu ersetzen, aber durch die Verwendung von ESI wird der für AJAX notwendige Round Trip vermieden, und die Antwort ist vollständig aufgebaut, bevor der Browser sie parsen muss.

Zwischenspeicherung


Um die Last auf den App-Servern zu verringern, werden HTTP-Antworten nach Möglichkeit im Cache gespeichert. Das ist der nächste große Vorteil von Varnish - es ist ein rasend (!!!) schneller Cache. Mit den Möglichkeiten von VCL könnt ihr eure eigenen Regeln für das Caching implementieren. Da ihr die volle Kontrolle über die HTTP-Header haben, bevor ihr den Inhalt an einen Client (meist einen Browser) ausliefert, könnt ihr entscheiden, wie gecacht werden soll.

Zusammen mit der Verwendung von ESI ist es möglich, die Anzahl der an die vertikalen Systeme gesendeten Anfragen zu minimieren. Varnish zwischenspeichert ESI-Fragmente und kann sie zu HTML-Seiten hinzufügen, ohne eine neue Anfrage an ein Backend zu senden.

Wir folgen HTTP, um Caching-Entscheidungen zu treffen - die vertikalen Systeme setzen die Cache-Control-Header, um zu entscheiden, ob und wie lange Varnish eine Antwort cachen soll.

Nachverfolgung


Wir haben den Varnish-Tracking-Log-Reader veröffentlicht, der das Varnish-Protokoll liest und es nach Daten analysiert, die wir in unserem Tracking-System speichern können. Die Varnish Logging API macht es einfach, die Fähigkeiten von Varnish mit unseren eigenen Komponenten zu erweitern.

Einschränkungen und Schlussfolgerung


Was fehlt also wirklich in Varnish? Softwareentwickler fühlen sich durch eine domänenspezifische Sprache wie VCL oft stark eingeschränkt. VCL ist zwar sehr einfach, aber es fehlen viele vertraute Konzepte. Man kann in der Standard-VCL keine Objekte erstellen (obwohl dies mit VMODs möglich ist), es fehlen Variablen und Schleifen, und der Kontrollfluss wird strikt von der Varnish-Zustandsmaschine bestimmt. Aber im Vergleich zu den statischen Konfigurationssprachen anderer Produkte wie Apache, Squid oder Nginx ist die VCL viel leistungsfähiger. Sie ist besser für den Kontrollfluss eines Proxys geeignet, und ihr könnt sogar Inline-C-Code schreiben (was wir nicht empfehlen) oder VCL mit VMODs erweitern (was wir tun). Ihr könnt VCL in einem lesbaren Codestil schreiben, und VCL wird kompiliert. All dies bedeutet, dass wir in der VCL viel mehr mit einer Anfrage machen können als in einer statischen Konfiguration wie der apache.conf.

0Noch keine Kommentare

Dein Kommentar
Antwort auf:  Direkt auf das Thema antworten

Geschrieben von

Ähnliche Beiträge

We want to improve out content with your feedback.

How interesting is this blogpost?

We have received your feedback.

Close

Cookies erlauben?

OTTO und drei Partner brauchen deine Einwilligung (Klick auf "OK") bei einzelnen Datennutzungen, um Informationen auf einem Gerät zu speichern und/oder abzurufen (IP-Adresse, Nutzer-ID, Browser-Informationen).
Die Datennutzung erfolgt für personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen sowie um Erkenntnisse über Zielgruppen und Produktentwicklungen zu gewinnen. Mehr Infos zur Einwilligung gibt’s jederzeit hier. Mit Klick auf den Link "Cookies ablehnen" kannst du deine Einwilligung jederzeit ablehnen.

Datennutzungen

OTTO arbeitet mit Partnern zusammen, die von deinem Endgerät abgerufene Daten (Trackingdaten) auch zu eigenen Zwecken (z.B. Profilbildungen) / zu Zwecken Dritter verarbeiten. Vor diesem Hintergrund erfordert nicht nur die Erhebung der Trackingdaten, sondern auch deren Weiterverarbeitung durch diese Anbieter einer Einwilligung. Die Trackingdaten werden erst dann erhoben, wenn du auf den in dem Banner auf otto.de wiedergebenden Button „OK” klickst. Bei den Partnern handelt es sich um die folgenden Unternehmen:
Google Ireland Limited, Meta Platforms Ireland Limited, LinkedIn Ireland Unlimited Company
Weitere Informationen zu den Datenverarbeitungen durch diese Partner findest du in der Datenschutzerklärung auf otto.de/jobs. Die Informationen sind außerdem über einen Link in dem Banner abrufbar.

mehr Informationen