High Performance Magento in der Cloud
Kommentare

A/B-Deployment im großen Stil

Deployments müssen weitestgehend automatisiert ablaufen und dürfen keine Risiken mit sich bringen. Ein neues Paket zu deployen, heißt nicht automatisch, dass neue Features

A/B-Deployment im großen Stil

Deployments müssen weitestgehend automatisiert ablaufen und dürfen keine Risiken mit sich bringen. Ein neues Paket zu deployen, heißt nicht automatisch, dass neue Features zur Verfügung stehen. Idealerweise sind Features mithilfe von Feature-Flags zunächst deaktiviert und können dann unabhängig vom Deployment-Prozess gezielt ein- und ausgeschaltet werden. Sollte beim Deployment etwas schief gegangen sein oder sollten sich doch Fehler in die neue Version eingeschlichen haben, muss ein Rollback zur vorhergehenden Version möglich sein. Alle Deployment-Vorgänge müssen synchron und atomar passieren und dürfen nicht von DNS-Updates abhängig sein. Außerdem müssen alle Dateien, die gegebenenfalls gecacht worden sind, jetzt den richtigen Inhalt ausliefern oder unter neuen URLs erreichbar sein.

Während eines Deployments darf der laufende Betrieb nicht beeinträchtigt werden. Der Besucher der Webseite sollte nichts davon mitbekommen. Das bedeutet auch, dass alle Caches vorgewärmt werden müssen, bevor der tatsächlich Switch stattfinden. Um all diesen Anforderungen gerecht zu werden, machen wir ein A/B-Deployment im großen Stil. Anstatt das neue Paket auf den existierenden Servern zu installieren und dann einen Symlink umzubiegen, bauen wir ein komplettes Deployment mit neuen Server-Arrays aus. Alle Server, die in diesen neuen Deployments gebootet werden, installieren automatisch das in der Konfiguration hinterlegte neue Paket. Das neue Deployment erhält auch einen eigenen Load Balancer und einen Deployment-spezifischen Cache-Prefix, sodass das parallele Hochfahren einer separaten Infrastruktur keinen Einfluss auf die aktuelle Produktivumgebung hat.

Das Cachewarming für die Magento-internen Caches und die Varnish-Server kann stattfinden, obwohl das Deployment von außen noch nicht erreichbar ist. Die Hauptdomain shop.angrybirds.com zeigt nicht direkt auf den aktiven Load Balancer sondern auf den Amazon-Route-53-Service. Dieser erlaubt in einer atomaren Operation, ohne dass die DNS-Einstellungen der Domain selbst geändert werden müssen, das Deployment umzuschalten, indem man die Konfiguration auf den Load Balancer des neuen Deployments umbiegt, sobald alle Server hochgefahren sind und alle Caches vorgewärmt sind. Dieser Prozess dauert üblicherweise nur wenige Minuten. Ganz ohne Downtime fangen die neue Server-Arrays an, alle Requests zu bearbeiten sobald das Route-53-Konfigurationsupdate geschehen ist.

Sollten unerwartete Probleme auftreten, kann das alte Deployment wieder aktiviert werden indem der Route-53-Service upgedatet wird. Ansonsten können die Server des alten Deployments heruntergefahren und das Deployment archiviert werden. Abbildung 3 zeigt das A/B-Deployment mit ganzen Server-Arrays inklusive Load Balance.

Abb. 3: A/B-Deployment mit ganzen Server-Arrays inklusive Load Balance
Varnish verleiht dem Shop Flügel

Ein zentrales Element der Cloud-Infrastruktur ist der Open Source Reverse Proxy „Varnish“. Eine Analyse hat ergeben, dass bis zu 95 Prozent aller angeforderten Seiten weitestgehend cachebar sind. Logininformation und Angaben zum Warenkorbinhalt können dabei lokal im Browser zwischengespeichert werden und per JavaScript nach dem Laden der Seite eingebettet werden. Auf diese Art und Weise können sowohl alle Produkt- und Kategorieseiten als auch CMS-Seiten und die Startseite komplett von Varnish aus bedient werden. Alle dynamischen Requests (z. B. die Warenkorbaktionen, der Checkout-Prozess und das Kundenkonto) werden weiterhin zu den Frontend-Servern durchgereicht.

Besonders im Angry-Birds-Webshop, wo virale Twitter- und Facebook-Kampagnen in kürzester Zeit Millionen von Besuchern in den Shop locken, die sich dann die Produkte anschauen (und dann allerdings nur ein Bruchteil der Besucher Produkte kaufen) ist ein ausgereiftes Caching-Konzept besonders wichtig.

Das freie Magento-Modul Aoe_Static [3] kümmert sich hierbei um die Kommunikation zwischen Magento und Varnish und sendet die richtigen Anweisungen, um gezielte Inhalte zu cachen (Abb. 4) oder auch automatisch aus dem Cache zu entfernen. Letzteres ist zum Beispiel notwendig, wenn Produkte bearbeitet werden oder sich der Warenbestand ändert.

Abb. 4: Varnish schützt Magento vor der Masse an Requests und liefert gecachte Inhalte direkt aus

Themen der letzten Seite

  • Magento-Caching
  • Magento-Optimierungen
  • Qualitätskontrolle
  • Continuous Integration und die Deployment Pipeline
  • Lessons learned
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -