Ein Bericht über die Server zwischen 20 - 24 Uhr

Vorweg muss gesagt werden, dass wir keine Systemadministratoren sind. Wir sind Designer und Programmierer, die vor große Herausforderungen gestellt wurden und diese selbst lösen wollten. Nach unserer Philosophie gehört Gestaltung und Programmierung zusammen und nun auch die Systemadministration (DevOps).

Anfangs stellte sich die Frage, welcher Last die Infrastruktur gegenüber stehen würde. Einfach war zunächst noch die Einschätzung, auf wie viele simultane aktive Besucher wir uns vorbereiten sollten. Freunde aus der Startup Szene, die schon bei dieser Show aufgetreten sind, haben uns geholfen einzuschätzen, dass wir nicht mit mehr als 100.000 gleichzeitig aktiven Besuchern rechnen dürften. Viel schwieriger war die Frage zu beantworten, was diese Besucher so alles treiben, was für eine Last Sie verursachen, wie lange dieser Peak überhaupt dauern und welche Anzahl an Requests, vor allem aber Warenkorbaktionen und Bestellungen, das in welchen Zeiträumen bedeuten würde. Als eine gute Strategie hat sich das simple Hochrechnen der Durchschnittswerte der Vergangenheit erwiesen. Wir gingen von einer halbierten Conversion aus. Hochgerechnet gingen wir von 5.000 Bestellvorgänge in 10 Minuten aus und definierten unseren Stresstest mit den üblichen Warenkorbaktionen wie Produkt in den Wwrenkorb legen, Adresse eingeben, Bezahlen und so weiter.

Die Conversion so niedrig anzusetzen stellte sich als Fehleinschätzung herraus – sie war mehr als doppelt so hoch wie üblich. Dies führte zu deutlich mehr Anfragen im Warenkorb, einem der ressourcenhungrigsten Bestandteile eines Webshops.

Die ersten Tests haben gezeigt, dass 1000 Requests pro Sekunde über 1 Minute etwas völlig anderes sein kann als 100 Requests pro Sekunde über 10 Minuten.

Cloudflare

Der wichtigster Schritt der Optimierung war die Trennung von dynamischen und statischen Inhalten und gleichzeitig die HTML Inhalte weitesgehend statisch vorzuhalten. Diese statischen Inhalte können sehr effizient von den eigenen Servern oder noch besser von einem georedundanten CDN ausgeliefert werden. Wir haben uns für letzteres entschieden und mit Cloudflare einen guten Partner gefunden. Im Normalbetrieb konnte die Anzahl der Zugriffe, die an unsere Server gingen, um 80% reduzieren werden.

Cluster

Die Optimierung für die dynamischen Zugriffe (Produkte in den Warenkorb hinzufügen, bezahlen, kommentieren) stellte eine deutlich größere Herausforderung dar. Wir setzen für reishunger.de eine eigene e-commerce Lösung ein, die allerdings in der Bestellabwicklung und im Abgleich mit unserem Warenwirtschaftssystem noch von Magento abhängig ist. Magento ist leider ungewöhnlich ressourcenhungrig. Die geplante vollständige Abschaffung von Magento war leider nicht mehr Möglich und so mussten wir unsere Infrastruktur leistungsfähiger aufstellen und einen Cluster einrichten, der uns neben höhere Performance auch Skalierbarkeit und Ausfallsicherheit bieten sollte.

Cluster Komponenten

nginx dient in unserem Setup als Proxy für die Web Server und als Cache für statische Dateien.

Elasticsearch

Mit Elasticsearch ist die Suchfunktion gelöst. Die Suchergebnisseiten werden zusätzlich statisch gecached.

Memcached

Memcached nutzen wir um die Ergebnisse von komplexen SQL Anfragen zu cachen. Jede der App Nodes hat einen eigenen memcached, so können mit memcached gecachte Daten ohne Netzwerklatenz eingelesen werden.

MariaDB

Die MariaDB Datenbank als klassische Master/Slave Kombination. Der Slave wird von PHP dank mysqlnd-ms für reine Lese-Aufrufe genutzt, sobald in die Datenbank geschrieben wird, gehen alle folgenden Anfragen an den Master. Weiterer Vorteil dieses Aufbaus ist die Redundanz der Datenbank, so dass im Falle eines Defektes am Master sehr einfach und schnell auf den Slave geschaltet werden kann.

Redis

Redis wird in unserem Fall nur für die Einkaufs Sessions benutzt und hat den Zweck die SQL Datenbank massiv zu entlasten.