Black Friday Week: Unsere Server sind ready to rumble

Bevor ich diesen Herbst als Software Engineer zu Digitec Galaxus stiess, habe ich mich bei den grossen Rabatt-Tagen wie Black Friday oder Cyber Monday immer gefragt, was hinter den Kulissen abgeht. Dieses Jahr kann ich nicht nur meine Neugierde stillen, sondern euch auf eine Tour durch die Vorbereitungsetappen mitnehmen. Als Entwickler im Team, das für unsere Community zuständig ist, bin ich dieses Jahr nämlich mittendrin im Geschehen.

November im Juli

An einem heissen Julitag geht es los: Das Organisationskomitee für die diesjährigen Rabatt-Tage kommt erstmals zusammen und erstellt einen ersten Forecast. Diese Fragen stehen im Raum: Mit wie vielen Kundinnen und Kunden rechnen wir? Welche Vorbereitungen müssen wir treffen? Auf welche Spezial-Szenarien müssen sich die Teams vorbereiten? Welche Gefahren gibt es? Die Erkenntnisse aus diesen Analysen helfen dem Product Development (unserer in-house Softwareentwicklung), euch während der Black Friday Week einen möglichst reibungslosen Einkauf zu ermöglichen.

In den folgenden Monaten gibt das Category Management vollen Einsatz und spürt die besten Angebote auf. Natürlich müssen die Objekte der Begierde pünktlich zu den Aktionstagen an Lager sein. Zeitgleich verschiebt unsere Logistikcrew die Aktionsangebote vorsorglich in das automatisierte Lagersystem. So gelangen die bestellten Produkte schneller in die Verpackungsabteilung und sind schon bald auf dem Weg zu euch.

Mehr Server, mehr Leistung

Unser Shop läuft nicht auf irgendeiner Blechkiste bei uns im Büro. Wir hosten so gut wie alle unsere Shop-Systeme in einem sogenannten Kubernetes Cluster auf der Microsoft Azure Cloud. Einfach gesagt besteht ein Kubernetes Cluster aus einer Vielzahl virtueller Server, auch Nodes genannt. Auf diesen Servern laufen unsere Systeme. An 358 Tagen im Jahr reicht die Standardkonfiguration. Während der Black Friday Week erwarten wir aber massiv mehr Traffic auf unseren Shops. Für die Spitzentage erweitern wir den Cluster deshalb um zusätzliche Nodes, damit wir unsere Systeme höher skalieren können. Dieses Vorgehen ist effizient und ökologisch, da die Server nach der Aktionswoche von anderen Kunden der Azure Cloud gemietet werden können und nicht ungenutzt rumstehen.

Doch nicht nur zusätzliche Server sind gefragt. Unsere Entwicklerteams müssen auch die Features in ihrem Zuständigkeitsbereich auf die grosse Last vorbereiten. In meinem Fall geht es um das Laden und Hinzufügen von Kommentaren oder Bewertungen. Dafür verwenden wir ein Tool, mit dem wir eine hohe Nutzlast simulieren, um das Verhalten unseres Shops in diesem Szenario zu testen. Diese Resultate und die angenommenen Nutzerzahlen zeigen uns, wo es noch Engpässe im System gibt. Kurz vor der Aktionswoche gehen wir auf Shoppingtour und mieten die zusätzlichen Nodes, damit wir gerüstet sind für den grossen Ansturm.

Was wir dieses Jahr anders machen

Im letzten Jahr war unser Shop an Black Friday nach Mitternacht für kurze Zeit down. Um der Ursache auf den Grund zu gehen, müssen wir einen Blick in die Struktur des Shops werfen. Unser Shop ist in mehrere Teile unterteilt. Das, was ihr auf dem Bildschirm seht, ist das sogenannte Frontend. Daran arbeite auch ich jeden Tag. Für diesen Teil verwenden wir React JS, Server Side Rendering mit Next JS, Styled Components und Apollo für die Netzwerk Requests. Dann gibt es die GraphQL Middleware. Hier nehmen wir alle Anfragen vom Frontend an, leiten diese an die relevanten Backend-Systeme weiter und geben die Antworten in dem vom Frontend gewünschten Format zurück. Die Backend-Systeme sorgen für die Magie hinter den Kulissen. In diesen Systemen stellen wir sicher, dass alle Daten am richtigen Ort gespeichert und schnell ausgegeben werden.

Zwischen den Backends und der GraphQL Middleware verwenden wir einen Redis Cache für die Zwischenspeicherung von häufig abgerufenen Daten, zum Beispiel zu den Produkten. Dadurch reduzieren wir die Last auf unseren Datenbanken (MongoDB, SQL Server) und anderen Systemen.

Im letzten Jahr war unser GraphQL-System so weit hochskaliert, dass es auf 2000 virtuellen Servern gleichzeitig lief und mehrere zehntausend Anfragen pro Sekunde auf den besagten Redis Cache machte. An einem gewissen Punkt konnte der Cache die Anfragen nicht mehr verarbeiten und es kam zu Fehlern. Hinzu kam ein Applikationsfehler, der ebendiese Anfragen unendlich wiederholte. Dadurch wurde die Last nochmals multipliziert und der Cache wurde in die Knie gezwungen. Als Folge landeten viele Anfragen auf der Datenbank, was den Shop enorm langsam machte und schliesslich zu einer kurzen Downtime führte. Das lassen wir natürlich nicht auf uns sitzen. Seit diesem Vorfall haben wir unsere Caching Strategie überarbeitet und vertrauen nun auf einen Multi-Level Cache.

Als erste Cache Stufe verwenden wir neu einen LRU In-Memory Cache. Darin werden die meistbesuchten Produkte zwischengespeichert. So können die Spitzen bei den Anfragen an unseren Redis Cache abgefedert werden. Den letztjährigen Applikationsfehler haben wir auch behoben, so dass eine fehlerhafte Anfrage nur noch einmal neu versucht wird. Dadurch können wir vermeiden, dass der Redis Cache überlastet wird.

Seit Black Friday und Cyber Monday 2021 haben wir zudem das Backend-System für sogenannte «Special Deals» überarbeitet und vereinfacht. Diese Funktionalität verwenden wir nicht nur für die Angebote während der Black Friday Week, sondern auch für die Tagesangebote, die wir euch das ganze Jahr bieten. Durch die Vereinfachung erhoffen wir uns weniger Probleme mit der Geschwindigkeit der Angebotsseite.

Was wir an Black Friday machen

Soweit die Theorie, am Black Friday folgt die Praxis. Kurz vor dem Start der Angebote skalieren die Teams Teile ihrer Systeme wie Caches oder Datenbanken manuell auf zuvor definierte Grössen hoch. Für Black Friday wollen wir auf Nummer sicher gehen und greifen bei ebendiesen kritischen Stellen manuell ein, damit genügend Server verfügbar sind, um die initiale Welle nach Mitternacht zu bewältigen. Für die anderen Teile schafft unser System automatisch mehr Kapazität, falls es Engpässe gibt. Somit sind unsere Server ready to rumble.

Dann werden Funktionen im Shop, die für Black Friday nicht essentiell sind, über «feature flags» ausgeschaltet. Der Livefeed wird euch für einmal nicht auf dem Laufenden halten, wer von wo was bestellt. Ebenfalls verzichten wir auf die Empfehlungen für Produkte und Community-Beiträge.

Die Aktionsangebote hinterlegen wir in unseren internen Systemen als sogenannte Werbekampagnen. Wir definieren für alle Produkte einen Gültigkeitszeitraum und legen die Verfügbarkeit fest. Danach lassen wir das System für uns arbeiten. Es zeigt die Angebote automatisch im Shop an und graut sie aus, wenn sie nicht mehr verfügbar sind.

Worauf wir auch während der Aktionswoche nicht verzichten, ist unser Continuous Deployment. Einen «Code Freeze» gibt es bei uns nicht. Wenn ich als Entwickler also eine Änderung im Versionierungssystem freigeben möchte und dies eine Mitarbeiterin oder ein Mitarbeiter im betroffenen Shop-Bereich bestätigt, dann seht ihr als Kundinnen und Kunden die Änderung innerhalb von wenigen Minuten. Hier vertrauen wir auf unsere automatisierten Tests, die vor jeder Freigabe laufen, sowie die Verantwortung unserer Engineering Crews.

In der Nacht auf Dienstag (dieses Jahr unser erster Tag mit Aktionen), der Nacht auf Black Friday sowie der Nacht auf Cyber Monday gibt es jeweils um Mitternacht Emergency Teams Calls. Hier sind Entwickler und Entwicklerinnen aus allen Bereichen des Shops dabei und können sofort reagieren, falls etwas schiefgeht.

Mit meiner Spurensuche habe ich viele meiner Fragen als Newbie beantwortet. Nun fiebere ich meiner ersten Black Friday Woche entgegen. Geht es dir ähnlich oder willst du noch mehr von mir wissen? Angebote verrate ich keine, aber technische Fragen beantworte ich gerne in den Kommentaren.