Storm Forecast Blog

On APIs, Load Testing, Performance and StormForger.


Quizduell, Last und Testing

Dear English reader. This post is about an event happened yesterday evening. tl;dr: A new interactive TV show had technical issues sustaining the load.

Das Quizduell (eine Adaption von der Quizduell App) mit Jörg Pilawa startete mit technischen Pannen und es folgte stundenlange Häme auf Twitter und Facebook. Die Online-Ausgaben diverser Medien berichteten teilweise noch während des Geschehens.

Was war geschehen?

Jörg Pilawa sagte während der Sendung, dass die Server überlastet seien und später, dass ein einzelner User über 15.000 Server blockieren würde. Andere Medien (Welt, Focus, Süddeutsche, Süddeutsche, Spiegel) berichteten sofort über einen Hackerangriff, wovon allerdings in der Pressemeldung vom NDR gestern Abend nichts mehr zu lesen ist. Auch auf Twitter wird schlicht ein Softwarefehler und/oder der Benutzeransturm als Vermutung propagiert.

Technische Hintergründe

Das Mobile Mass Response System läuft nach Informationen von grandcentrix (Betreiber und Hersteller der App und des Backends) auf Google Infrastruktur (also entweder Google Compute Engine oder Google App Engine). Die Aussage, dass mindestens 15.000 Server zum Einsatz gekommen sind, halte ich allerdings für eine Fehlinformation. Denn bei 173.000 Anmeldungen im Vorfeld würde das etwa 11,5 Benutzer pro Server bedeuten. Ich vermute, es sind Prozesse auf App Engine gemeint.

Weitere technische Details sind öffentlich leider nicht zu finden. Eventuell ist auf der Interactive Cologne mehr über die Architektur, den Vorfall und deren Hintergründe zu erfahren. Über ein Post-Mortem oder einen „Lessons Learned“ Vortrag würde ich micht sehr freuen.

Lässt sich so etwas verhindern?

grandcentrix hat mit dem Voting-Systems des Eurovision Song Contest bewiesen, dass sie in der Lage sind, solch anspruchsvolle Architekturen zu entwickeln und zu betreiben. Lassen sich solche Zwischenfälle überhaupt verhindern?

Ob sich prinzipiell solche Ausfälle wie beim Quizduell verhindern lassen, ist zumindest fraglich. Es ist eine gute Mischung aus Know-How und vielleicht einem externen Auditing notwendig um Risiken zu minimieren. Trotzdem bergen solche Events enormes Potential für Probleme, da im Vorfeld nicht klar ist, mit welchen Mengen an Anfragen zu rechnen ist, ob es enorme Lastspitzen geben wird und wie sich das System unter solchen Voraussetzungen verhält.

Daher ist es unerlässlich, umfangreiche, nicht-funktionale Lasttests durchzuführen. Dabei sind Tests – vor allem in dieser Größenordnung – ein nicht triviales Unterfangen, selbst wenn die API auf den ersten Blick vermutlich relativ einfach erscheinen mag. Viele Testframeworks scheitern schon daran, viele hunderttausende Benutzer zuverlässig über längere Zeiträume zu simulieren; der Test und die Lastgeneratoren selber muss überwacht werden, um Überlastung zu verhindern? Wie testet man API Clients mit langsamer Verbindung? Wie bildet man dynamisches Verhalten ab? Sind die Testszenarien realistisch genug? usw.

Ursächlich für solche Probleme unter Last sind neben der Anwendungssoftware selbst, oft Probleme mit der (Cloud-)Infrastruktur, Lastverteilern, System- oder Netzwerkkonfigurationen der Application Server. Ein reiner Audit auf Basis von Quellcode oder Modell-basierte Analysen sind daher nicht ausreichend. Besonders problematisch ist der Betrieb solcher Systeme basierend auf Infrastruktur wie dem von Google betriebenen Google App Engine, da hier der Nutzer wenig unmittelbare Kontrolle und Einfluss auf die Umgebung nehmen kann.

Fazit

Technisch skalierbare und Cloud-basierte Architekturen sind nicht notwendigerweise ein Garant für einen reibungslosen Ablauf. Vor allem bei Events wie dem Eurovision Song Contest oder dem Quizduell ist mit enormen Lastspitzen, „seltsamem“ Traffic oder „Angriffen“ zu rechnen. Ohne Lasttests, die den gesamten Stack (vom Loadbalancer bis zum Application Server) testen, kann auf Grund der Komplexität der eingesetzten Systeme keine verlässliche Aussage über das Verhalten eines Systems getroffen werden.

Create repeatable Performance & Load Tests easily using our JavaScript DSL to verify your HTTP APIs. StormForger enables you to do continuous performance testing to make the web a faster place. Learn more...

definition.setTarget("API.EXAMPLE.COM");

definition.setArrivalPhases([
  {
    duration: 5 * 60,  // 5min in seconds
    rate: 1.0,         // clients per seconds to launch
  },
]);

definition.session("hello world", function(session) {
  session.get("/", { tag: "root" });
});