Spike-Tests: Plötzliche Lastspitzen realistisch simulieren

1. Warum plötzliche Lastspitzen ein eigenes Testverfahren brauchen

Ein System, das eine schrittweise ansteigende Last problemlos bewältigt, kann bei einem abrupten, sekundenschnellen Anstieg trotzdem versagen, da viele Skalierungsmechanismen auf einer gewissen Vorlaufzeit beruhen: Ein Auto-Scaling-System benötigt in der Regel mehrere Minuten, um neue Server-Instanzen hochzufahren und in den Lastverbund aufzunehmen, während ein kalter Cache erst durch tatsächliche Anfragen schrittweise mit häufig angefragten Inhalten befüllt wird. Bei einem echten Traffic-Sprung, wie er nach dem Versand eines großen Newsletters mit einem zeitlich begrenzten Rabattcode typischerweise auftritt, steht diese Vorlaufzeit schlicht nicht zur Verfügung, wodurch genau die Sekunden bis Minuten nach dem Traffic-Anstieg zum kritischsten Zeitfenster werden.

Ein Spike-Test bildet dieses reale Szenario gezielt nach, indem er die virtuelle Nutzerzahl nicht schrittweise, sondern binnen weniger Sekunden von einem niedrigen Grundniveau auf ein deutlich höheres Niveau springen lässt, um genau zu beobachten, wie das System in diesem kritischen Übergangsfenster reagiert, statt nur das Verhalten bei bereits eingeschwungener, hoher Last zu prüfen.

2. Sale-Events und Blitzangebote als realistisches Testszenario

Ein realistisches Spike-Test-Skript für einen Magento-Shop bildet typischerweise das Verhalten nach einer Newsletter- oder Push-Benachrichtigungs-Kampagne nach: eine große Anzahl von Nutzern klickt binnen weniger Minuten auf denselben Link, landet auf derselben Landingpage oder demselben Produkt, und ein signifikanter Anteil davon durchläuft anschließend tatsächlich den Checkout, da die zeitliche Begrenzung des Angebots einen künstlichen Kaufdruck erzeugt.

Wichtig für ein realistisches Spike-Test-Skript ist, diese Konzentration auf wenige, gemeinsame Ressourcen (etwa dieselbe Produktseite oder denselben Rabattcode) abzubilden, statt die Last gleichmäßig über viele verschiedene Seiten zu verteilen, da genau diese Konzentration auf gemeinsam genutzte Ressourcen, etwa einen einzelnen, stark nachgefragten Datenbank-Datensatz für den Lagerbestand, typischerweise die tatsächliche Schwachstelle eines Systems unter Spike-Last darstellt.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  scenarios: {
    sale_spike: {
      executor: 'ramping-arrival-rate',
      startRate: 10,
      timeUnit: '1s',
      preAllocatedVUs: 500,
      maxVUs: 1000,
      stages: [
        { duration: '10s', target: 10 },   // normale Grundlast
        { duration: '5s', target: 300 },   // plötzlicher Sprung
        { duration: '3m', target: 300 },   // Spitze halten
        { duration: '30s', target: 10 },   // Abfall nach Angebotsende
        { duration: '2m', target: 10 },    // Recovery-Fenster beobachten
      ],
    },
  },
};

export default function () {
  const res = http.get('https://shop.example.com/produkt/limited-sale-artikel.html');
  check(res, { 'Produktseite erreichbar': (r) => r.status === 200 });
  sleep(0.5);
}

3. Auto-Scaling-Verhalten gezielt prüfen

Während eines Spike-Tests ist die Reaktionszeit des Auto-Scaling-Systems selbst eine der wichtigsten zu beobachtenden Metriken: Wie viele Sekunden vergehen zwischen dem Erreichen eines definierten Skalierungs-Schwellenwerts (etwa 80 Prozent CPU-Auslastung) und dem tatsächlichen Verfügbarwerden einer neuen, zusätzlichen Server-Instanz, und wie verhält sich die Antwortzeit für Nutzer während genau dieses Übergangsfensters, in dem die bestehenden Instanzen die zusätzliche Last noch alleine tragen müssen.

Ein häufig unterschätzter Aspekt ist dabei, dass Auto-Scaling allein die Kapazitätslücke nicht vollständig schließt, solange gemeinsam genutzte, nicht horizontal skalierende Ressourcen wie eine einzelne primäre Datenbank-Instanz weiterhin einen Flaschenhals darstellen: Zusätzliche Applikations-Server helfen wenig, wenn alle Anfragen letztlich auf dieselbe, bereits ausgelastete Datenbank treffen, ein Umstand, den ein Spike-Test durch gezieltes Monitoring der Datenbank-Metriken parallel zu den Applikations-Metriken sichtbar macht.

4. Recovery-Zeit nach dem Lastabfall messen

Ein oft vernachlässigter, aber wichtiger Teil eines vollständigen Spike-Tests ist die Beobachtung des Systemverhaltens nach dem Abklingen der Lastspitze, nicht nur während ihres Höhepunkts. Ein System kann während der eigentlichen Spitze fehlerfrei funktionieren, aber danach ungewöhnlich lange brauchen, um wieder zu normalen Antwortzeiten zurückzukehren, etwa weil aufgeblähte Connection-Pools erst schrittweise abgebaut werden, oder weil durch Auto-Scaling hochgefahrene, zusätzliche Instanzen erst mit erheblicher Verzögerung wieder heruntergefahren werden.

Die Recovery-Zeit, also die Zeitspanne zwischen dem Ende der Lastspitze und der tatsächlichen Rückkehr zu normalen Antwortzeiten und normaler Ressourcenauslastung, ist eine eigenständige, wichtige Kennzahl, da eine lange Recovery-Zeit bedeutet, dass ein System nach einem ersten Spike besonders anfällig für einen zweiten, kurz darauf folgenden Spike ist, ein durchaus realistisches Szenario bei mehreren aufeinanderfolgenden Marketing-Aktionen an einem einzigen Sale-Tag.

5. Caching-Verhalten unter Spike-Last

Ein kalter, noch nicht befüllter Full-Page-Cache stellt bei einem Spike-Test ein besonders realistisches Risiko dar, da genau zu Beginn eines Sale-Events, wenn der Traffic-Sprung erstmals auftritt, der Cache für eine neue Landingpage oder ein neues Sale-Produkt typischerweise noch komplett leer ist. Die ersten Anfragen nach dem Traffic-Sprung treffen dadurch ungebremst auf die vollständige Anwendungslogik samt Datenbankzugriffen, statt von einem bereits aufgewärmten Cache bedient zu werden, was genau in diesem kritischen Moment zu besonders hoher Last auf dem Applikationsserver führt.

Ein bewährter Ansatz gegen dieses Problem ist das gezielte Vorwärmen (Cache-Warming) der relevanten Seiten kurz vor dem geplanten Beginn eines Sale-Events, etwa durch automatisierte Anfragen an die betreffenden URLs wenige Minuten vor dem offiziellen Start, wodurch der Cache bereits befüllt ist, wenn der eigentliche Traffic-Sprung eintritt, statt die Cache-Befüllung dem Zufall der ersten echten Nutzeranfragen zu überlassen.

6. CDN und Edge-Caching als zusätzliche Lastabsorption

Ein vorgeschaltetes Content Delivery Network fängt einen erheblichen Teil eines plötzlichen Traffic-Sprungs bereits ab, bevor die Anfrage überhaupt den eigentlichen Applikationsserver erreicht, vorausgesetzt die betroffenen Seiten sind tatsächlich als cachebar konfiguriert und die CDN-Konfiguration erlaubt eine ausreichend lange Cache-Gültigkeit für die jeweilige Sale-Landingpage. Ein Spike-Test sollte deshalb bewusst prüfen, welcher Anteil der Anfragen tatsächlich vom CDN direkt an der Edge beantwortet wird und welcher Anteil bis zum Ursprungsserver durchdringt.

Besonders bei personalisierten oder von der Session abhängigen Inhalten, etwa einem individuellen Warenkorb-Hinweis auf einer sonst statischen Landingpage, greift klassisches CDN-Caching nicht ohne Weiteres, weshalb ein Spike-Test-Szenario realistischerweise einen gemischten Anteil aus cachebaren und nicht cachebaren Anfragen abbilden sollte, statt fälschlicherweise von vollständiger CDN-Absorption auszugehen.

7. Datenbank-Verhalten unter Spike-Last

Ein plötzlicher Ansturm auf denselben, stark nachgefragten Datensatz, etwa den Lagerbestand eines einzelnen, limitierten Sale-Artikels, kann zu Datenbank-Lock-Konflikten führen, wenn viele gleichzeitige Transaktionen versuchen, denselben Datensatz zu lesen und zu schreiben, ein Muster, das bei gleichmäßig verteilter Last kaum auffällt, unter Spike-Bedingungen aber schnell zum dominanten Flaschenhals wird. Ein Spike-Test sollte deshalb gezielt Datenbank-Metriken wie Lock-Wartezeiten und die Anzahl aktiver Transaktionen parallel zu den Antwortzeit-Metriken der Anwendung beobachten.

Bei Magento-Installationen mit einer Read-Replica-Architektur ist zusätzlich die Replikationsverzögerung (Replication Lag) während eines Spikes von Interesse, da eine plötzlich stark ansteigende Schreiblast auf der primären Datenbank dazu führen kann, dass Lesereplikate kurzzeitig veraltete Daten liefern, was etwa bei Lagerbestandsanzeigen zu kurzzeitig inkonsistenten, aber für den Kunden durchaus sichtbaren Informationen führen kann.

8. Alerting während eines echten Traffic-Sprungs richtig konfigurieren

Ein Spike-Test deckt nicht nur technische Schwachstellen im System selbst auf, sondern prüft zusätzlich, ob die Monitoring- und Alarmierungsinfrastruktur eines Teams tatsächlich rechtzeitig und aussagekräftig auf einen plötzlichen Lastanstieg reagiert. Ein Alarm, der erst zehn Minuten nach dem tatsächlichen Beginn eines Traffic-Sprungs ausgelöst wird, weil die zugrunde liegende Metrik über ein zu grobes Zeitfenster gemittelt wird, kommt für eine schnelle, manuelle Reaktion praktisch zu spät.

Ein gut konfiguriertes Alerting-System nutzt für spike-relevante Metriken deshalb bewusst kürzere Aggregationsfenster als für trägere, langfristige Trends, damit ein plötzlicher Anstieg der Fehlerrate oder Antwortzeit binnen ein bis zwei Minuten erkannt wird, statt erst nach einem längeren, für diesen Zweck ungeeigneten Durchschnittsfenster sichtbar zu werden. Ein Spike-Test bietet die ideale Gelegenheit, diese Alarmierungs-Reaktionszeit unter realistischen Bedingungen zu prüfen, statt sie erst während eines echten Vorfalls zum ersten Mal zu testen.

9. Spike-Test-Metriken im Überblick

Die folgende Tabelle fasst die wichtigsten während eines Spike-Tests zu beobachtenden Metriken zusammen.

10. Zusammenfassung

11. FAQ: Spike-Tests: Das Wichtigste auf einen Blick