High Performance Magento in der Cloud
Kommentare

Serverinfrastruktur

Beim Hosting in der Cloud geht es nun nicht mehr um einzelne Serverinstanzen, sondern um Gruppen von Servern, die eine bestimmte Funktion erfüllen. Die so genannten „Server-Arrays“

Serverinfrastruktur

Beim Hosting in der Cloud geht es nun nicht mehr um einzelne Serverinstanzen, sondern um Gruppen von Servern, die eine bestimmte Funktion erfüllen. Die so genannten „Server-Arrays“ kümmern sich selbstständig darum, dass immer eine Mindestanzahl von Servern in der jeweiligen Gruppe vorhanden ist, und dass eine ausreichende Anzahl von Servern gebootet und in das Deployment eingebunden wird, um die aktuelle Last verarbeiten zu können.

Anhand eines Voting-Mechanismus, der beispielsweise von der CPU-Last oder auch von businessspezifischen Metriken, wie zum Beispiel Bestellungen pro Minute, abhängen kann, können weitere Server automatisch gebootet werden oder bestehende, nicht mehr benötigte Server heruntergefahren werden. Voraussetzung für das automatische Booten neuer Serverinstanzen ist, dass die Server vollautomatisch provisioniert werden können. Sobald der Server einsatzbereit ist, wird er automatisch von den Load Balancern berücksichtigt und bekommt von nun an Traffic ab.

Für den Betrieb eines Magento-Shops werden vier Server-Arrays benötigt: Die Server im Frontend-Array bedienen alle dynamische Requests der Besucher. Das Backend-Array ist für die Shopadministratoren und -redakteure da. Das Varnish-Server-Array cacht so viel wie möglich und verhindert, dass zu viele Requests beim Frontend-Server-Array auftreffen. Das Worker-Server-Array verarbeitet alle Magento-Crontasks, API-Requests und jede Kommunikation mit anderen externen Systemen.

Jede Komponente in der vorliegenden Architektur muss redundant ausgelegt sein, um die Ausfallsicherheit zu gewährleisten. Daher sind die Server-Arrays so konfiguriert, dass sie immer mindestens zwei Serverinstanzen vorhalten, auch wenn diese sich (wie im Beispiel der sehr effizienten und ressourcensparenden Varnish-Server) langweilen. Fällt ein Server aus, wird automatisch eine neue EC2-Instanz gebootet. Hier ist kein manuelles Eingreifen notwendig.

Die Server der Backend- und Frontend-Server-Arrays werden mithilfe des RightScale-API in der Varnish-Konfiguration als Backends hinterlegt und bei Änderungen automatisch aktualisiert. Die Varnish-Server sind bei einem Load Balancer registriert. Die vier Server-Arrays und der Load Balancer bilden zusammen das „Deployment“.

Als Datenbank wird Amazon RDS verwenden. Dieser Dienst wird als Service angeboten, der sich intern um die Verfügbarkeit und Ausfallsicherheit kümmert und zudem mit automatischen Backups, Snapshots und Read-Replicas viele wichtige Features eines Setups im großen Stil zur Verfügung stellt.

Als persistenter Speicher für Produkt-, Kategorie- und CMS-Bilder wird ein S3-Bucket verwendet. Auch die skalierten Versionen der Bilder werden in den S3-Bucket zurück geschrieben und müssen dadurch nicht mehrmals berechnet werden. Die Bilder werden direkt aus dem S3-Bucket über eine Cloudfront-Domain ausgeliefert. Dadurch ist kein gemeinsames Dateisystem notwendig, auf das alle Server zugreifen müssen.

Ein weiterer Cloudfront-Service, der hier ebenfalls als Reverse Proxy agiert und sich die Dateien über Varnish von den Frontend-Servern zieht, ist dafür zuständig, alle notwendigen Skin-Dateien auszuliefern. Die Anzahl der Zugriffe auf die Webserver wird damit auf die tatsächlichen dynamischen Requests minimiert. Abbildung 2 zeigt die Serverarchitektur im Überblick.

Abb. 2: Die Serverarchitektur im Überblick

Themen der folgenden Seiten

  • A/B-Deployment im großen Stil
  • Varnish verleiht dem Shop Flügel
  • 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 -