Webbasierte Software für für E-Sport und Business

High-Traffic Setup für Auftritt von Rankwerk in der TV-Löwenhöhle mit AWS

Veröffentlicht von Henrik Braune am 22.04.2020

Henrik Braune

Eine Aufgabe, die uns schon lange gereizt hat: Nun hatten wir die Gelegenheit eine Infrastruktur-Lösung aufzubauen, die dem Peak-Traffic während der Ausstrahlung der bekannten TV-Show Die Höhle der Löwen standgehalten hat.

Am gestrigen Abend wurde das Finale des diesjährigen Staffel von Die Höhle der Löwen ausgestrahlt. Mit dabei war auch das Kieler Startup Rankwerk, das Bio-Saatgut und Zubehör für das Urban Gardening herstellt und darüber hinaus ein neues Abo-Modell eingeführt hat, das in der TV-Show vorgestellt wurde. Um kurz vor 22 Uhr hatten die beiden Gründer Hannes Popken und Dennis Lizarzaburu ihren Auftritt und nur wenige Sekunden später erreichte eine hohe Zahl paralleler Anfragen die Server-Infrastruktur, die darauf vorbereitet und optimiert war.

Worin besteht die Herausforderung?

Webseiten und Online-Shops haben in der Regel Zugriffszahlen, die berechenbar sind und sich an den Gewohnheiten der Nutzer ausrichten. So sinken die Zugriffe in der Nacht (wenn wir uns auf eine Region der Welt beschränken) und steigen am Tag und Abend. Steigenden Zugriffszahlen über die Zeit kann durch eine Erweiterung der Hardware und Optimierung der Software begegnet werden. Werbemaßnahmen führen in der Regel zu einer zeitlich konzentrierten Erhöhung der Zugriffszahlen. Je höher die Reichweite der Maßnahmen, desto höher die Auslastung der Server. Einen Extremfall ist die TV-Werbung, bei der eine Reichweite von mehreren Millionen Zuschauern erreicht werden kann. Wenn nur ein Bruchteil der Zuschauer auf einem Second-Screen die Webseite oder den Shop besucht, handelt es sich um einen sprunghaften Anstieg auf mehrere zehntausend Zugriffe, die zeitgleich (!) erfolgen. Eine darauf nicht optimierte Lösung fällt dann innerhalb einer Sekunde aus und reagiert nicht mehr – so geschehen bei einer Vielzahl von Startups, die in früheren Folgen aufgetreten sind. In der Folge "verpufft" die Werbemaßnahme, weil die Conversion nicht ausgeführt werden kann in Ermangelung einer funktionierenden Webseite.

Grundsätze einer skalierbaren Infrastruktur

Bereits in der Vergangenheit haben wir durch unsere Arbeit für Electronic Arts und die Virtual Bundesliga viel Erfahrung sammeln können im Umgang mit Traffic-Spitzen, die sich innerhalb weniger Sekunden aufbauen und Server bis an die Grenze belasten. Auf dieser Grundlage gilt es folgende Grundsätze zu berücksichtigen:

  • Die Startseite der Aktion (in diesem Fall: https://abo.rankwerk.de) muss zu 100% statisch sein. Das heißt: Nur HTML, CSS und Javascript. Keine Requests an einen Server, der dynamische Inhalte ausliefert.
  • Nicht-statische Anfragen (z.B. Checkout-Logik) erfolgen im zweiten Schritt. Dabei wird über eine API kommuniziert, die Rohdaten (hier: JSON) zurückliefert, das Rendering erfolgt im Browser. Die API muss einen möglichst geringen Speicherabdruck haben.
  • Komplexe Datenbanklogik ist zu vermeiden, nach Möglichkeit ebenso relationale Datenbanken wie MySQL. Daten werden in dokumentenbasierte Datenbanken geschrieben, die repliziert werden können um die Last zu verteilen (z.B. MongoDB) 
  • Die statische Landing-Page und die API müssen über ein Cluster an Servern ausgeliefert werden, alle Anfragen müssen über Load Balancer an die einzelnen Server verteilt werden, um die Last auf einzelne Maschinen zu reduzieren.

Unsere Lösung auf Basis von AWS

Aufgrund der erfolgten Lernkurve in anderen Projekten haben wir uns für die Nutzung von AWS als Grundlage der Infrastruktur-Lösung entschieden (Amazon Webservices). Dabei wurden eine Vielzahl von Diensten von AWS genutzt.

Cloudfront und S3

Die statische Landing-Page wurde vollständig über die AWS CDN Cloudfront mit verbundenem S3-Hosting ausgeliefert. Die AWS Cloudfront ist ein Netzwerk von Servern, das eine hochverfügbare Auslieferung von Inhalten über regionale Nähe zu den Nutzern garantiert. Die Preise sind nutzungsabhängig, weshalb eine Optimierung der Dateigrößen aller Assets (Bilder, CSS, JS) empfohlen ist.

AWS Elastic Container Service und Load Balancing

Die auf Symfony basierende API für den Checkout inkl. Payment-Abwicklung von Stripe und Paypal wurde als Docker-Image in einer Gitlab Registry zur Verfügung gestellt. In AWS wurde ein Cluster definiert mit einem Service definiert, das den Docker-Container unter Verwendung von Umgebungsvariablen ausgeführt hat. In der Spitze wurden mehrere Dutzend virtuelle Maschinen auf Grundlage des Docker-Images betrieben, die Anfragen wurden über einen klassischen Application Load Balancer verteilt. Verzichtet haben wir auf ein Auto-Scaling des Clusters aufgrund des unmittelbaren Anstiegs des Traffics.

Darüber hinaus wurde auch PHP-FPM für das Cluster und den verfügbaren Speicher optimiert. Der "Process Manager" wurde so konfiguriert, dass neuen Prozesse nicht dynamisch erstellt wurden, sondern statisch vorgehalten wurden. Das füllt zwar den Speicher auf, reduziert aber die CPU Nutzung für das "Spawning" der Prozesse und verringert die Antwortzeiten aufgrund der bereits bereitstehenden Prozesse. 

DocumentDB

Als Datenbank wurde ein DocumentDB-Cluster eingerichtet, mit einer Writer- und mehrerer Reader-Instanzen. Die Anbindung der Datenbank an die ECS-Container erfolgte innerhalb der Security Group von AWS über die Doctrine MongoDB Abstraktion von Symfony.

 

Durchführung von Lasttests

Auf dem Graph ist zu sehen, dass es bereits am Nachmittag einen noch höheren Ausschlag gab. Wir haben Annahmen über das zu erwartende Nutzeraufkommen getroffen und dieses noch einmal verdoppelt. So wollten wir sichergehen, dass die Server in jedem Fall reagieren und einen Ausfall vermeiden. Um dies zu verifizieren, haben wir mittels flood.io Lasttests durchgeführt, die die zu erwartende Anzahl paralleler Nutzer über ein eigenes Cluster simuliert. So, und nur so, konnten wir unter realen Bedingungen den Peak simulieren, der am Abend folgen sollte.

© 2020, Braune Digital GmbH, Niemannsweg 69, 24105 Kiel, +49 (0) 431 55 68 63 59