Kapazitätsplanung und Performancetests

Kapazität ist ein Plan, keine Hoffnung

Die Kapazitätsplanung beantwortet eine Frage im Voraus: Werden wir von allem genug haben, wenn die Nachfrage ihren Höhepunkt erreicht? Alles umfasst mehr als Server. Dazu gehören Datenbankverbindungen und Schreibdurchsatz, Cache-Speicher, Partitionen des Message Brokers, Kontingente des Cloud-Kontos, Rate Limits von Drittanbietern, Lizenzen und die Personen in Rufbereitschaft. Die Elastizität der Cloud macht manche Kapazität schnell verfügbar, aber nicht jede: Eine primäre Datenbank lässt sich nicht in Sekunden verdoppeln, ein Zahlungsanbieter braucht unter Umständen Wochen Vorlauf, um ein Limit anzuheben, und Autoscaling (behandelt in Abschnitt 9.1) reagiert in Minuten auf einen Lastsprung, der in Sekunden eintrifft.

Die Methode hat vier Schritte, die in einem regelmäßigen Zyklus wiederholt werden (vierteljährlich bei stetigem Wachstum, pro Ereignis bei Produktstarts und Vorverkaufsstarts):

Die Dimensionierung mit Littles Gesetz wurde in Abschnitt 9.1 durchgerechnet; dieser Abschnitt konzentriert sich darauf, wie man vertrauenswürdige Zahlen dafür gewinnt. Der häufigste Fehler in der Kapazitätsplanung ist nicht falsche Arithmetik, sondern eine Kapazität pro Instanz, die unter unrealistischen Bedingungen gemessen wurde, und der zweithäufigste ist eine vergessene gemeinsame Beschränkung, etwa ein Limit eines Drittanbieters, die keine noch so große Kapazitätsreserve auf den eigenen Servern beheben kann.

Arten von Performancetests

Performancetests sind der einzige Weg, Kapazität zu messen, Engpässe zu finden, bevor Kunden sie finden, und zu prüfen, dass ein Release nichts verschlechtert hat. Die Tests unterscheiden sich in der Lastform, die sie anlegen, und in der Frage, die sie beantworten. Ein Lasttest prüft die erwartete Spitze; ein Stresstest geht darüber hinaus, um zu sehen, wie das System ausfällt; ein Soak-Test läuft über Stunden, um schleichende Lecks aufzudecken; ein Spike-Test prüft die Reaktion auf plötzliche Sprünge; ein Breakpoint-Test steigert die Last, bis etwas bricht, um die tatsächliche Grenze zu finden.

Offene und geschlossene Lastmodelle

Lastgeneratoren simulieren Benutzer auf eine von zwei Arten, und die falsche Wahl liefert Ergebnisse, die nicht nur ungenau, sondern gefährlich optimistisch sind. In einem geschlossenen Lastmodell betreibt das Werkzeug eine feste Zahl virtueller Benutzer; jeder sendet eine Anfrage, wartet auf die Antwort, pausiert für eine Denkzeit und wiederholt das. Wird das System langsamer, sendet jeder virtuelle Benutzer weniger Anfragen, sodass die Last von selbst sinkt. In einem offenen Lastmodell treffen Anfragen mit einer festen Rate ein, unabhängig davon, wie schnell frühere beantwortet werden, so wie echte Besucher einer öffentlichen Website: Tausende Fans, die um 10:00 auf „Kaufen“ drücken, warten nicht aufeinander.

Bianca Schroeder, Adam Wierman und Mor Harchol-Balter zeigten (Open Versus Closed: A Cautionary Tale, NSDI 2006), dass die beiden Modelle für dasselbe System und dieselbe durchschnittliche Last sehr unterschiedliche Antwortzeiten liefern können und dass Scheduling- oder Kapazitätsentscheidungen, die unter dem einen Modell optimiert wurden, unter dem anderen falsch sein können. Interne Systeme mit einer festen Population von Clients, etwa eine Callcenter-Anwendung mit 300 Mitarbeitenden, sind einigermaßen geschlossen. Öffentlicher Internet-Traffic, ereignisgesteuerte Consumer, die aus einer Queue gespeist werden, und Vorverkaufsstarts sind offen oder nahezu offen. Für solche Systeme ist ein Test nach dem offenen Modell der realistische; die Executors constant-arrival-rate und ramping-arrival-rate von k6 zum Beispiel setzen ihn um, während der Executor constant-vus geschlossen ist.

Coordinated Omission

Gil Tene von Azul Systems, Autor der Bibliothek HdrHistogram, gab einem Messfehler einen Namen, der viele Latenztests und Monitoring-Werkzeuge betrifft: Coordinated Omission. Ein Lastgenerator mit geschlossener Schleife wartet auf jede Antwort, bevor er die nächste Anfrage sendet. Wenn das System hängt, hängt der Generator mit, sodass die Anfragen, die echte Benutzer während des Hängers gesendet hätten und die alle langsam gewesen wären, nie gesendet und nie gemessen werden. Das Testwerkzeug koordiniert sich mit dem System, das es testet, und lässt genau die schlechten Messwerte aus.

Betrachten Sie einen Test, der 100 Sekunden lang alle 10 ms eine Anfrage an einen Dienst senden soll, der normalerweise in 1 ms antwortet. Bei 50 Sekunden friert der Dienst für 10 Sekunden ein (etwa durch eine lange Garbage-Collection-Pause). Das Testwerkzeug mit geschlossener Schleife zeichnet etwa 9000 schnelle Messwerte und einen 10-Sekunden-Messwert auf und meldet daher ein p99 von 1 ms und sogar ein p99.9 von 1 ms. Nach dem geplanten Zeitplan wären während des Einfrierens jedoch etwa 1000 Anfragen eingetroffen, die zwischen 10 Sekunden und 10 ms gewartet hätten, im Durchschnitt etwa 5 Sekunden. Zehn Prozent aller Anfragen wurden stark verzögert: Das wahre p95 liegt bei etwa 5 Sekunden und das wahre p99 bei etwa 9 Sekunden.

Die Abhilfe besteht darin, für offene Systeme Generatoren nach dem offenen Modell (mit Ankunftsrate) zu verwenden, die Latenz ab dem Zeitpunkt zu messen, zu dem eine Anfrage gesendet werden sollte, und nicht ab dem tatsächlichen Senden, vollständige Histogramme statt Durchschnittswerten aufzuzeichnen und jedem Latenzbericht zu misstrauen, dessen Maximum weit über seinem p99.9 liegt, mit wenigen Messwerten dazwischen. Tenes modifiziertes HTTP-Benchmarking-Werkzeug wrk2 und die Korrekturoptionen von HdrHistogram gibt es genau dafür. Derselbe Fehler tritt im Produktions-Monitoring auf, wenn eine Client-Bibliothek nur die Anfragen misst, die sie senden konnte.

Werkzeuge

Vier Open-Source-Werkzeuge decken die meisten Anforderungen ab. Apache JMeter ist der Veteran: Java-basiert, mit einem grafischen Editor für Testpläne, vielen Protokoll-Plug-ins und Thread-Gruppen, die standardmäßig geschlossen sind. Gatling schreibt Tests als Code (Scala, Java und Kotlin, in jüngerer Zeit auch JavaScript und TypeScript), ist bei hoher Last effizient und bietet offene und geschlossene Injektionsprofile. k6, gepflegt von Grafana Labs, führt JavaScript-Testskripte auf einer in Go geschriebenen Engine aus, hat explizite Executors für das offene und das geschlossene Modell sowie Bestanden-oder-nicht-Schwellenwerte, die sich für Continuous Integration eignen. Locust beschreibt das Benutzerverhalten in Python und verteilt die Last auf Worker-Prozesse; seine Benutzer arbeiten mit geschlossener Schleife. Kommerzielle und in der Cloud gehostete Dienste ergänzen eine verteilte Lasterzeugung in großem Maßstab und Reporting.

Das Szenario ist wichtiger als das Werkzeug. Ein gutes Skript bildet den echten Mix der Journeys nach (aus der Produktionsanalyse: vielleicht 70 % Stöbern, 20 % Änderungen am Warenkorb, 10 % Bezahlvorgang), realistische Denkzeiten, realistische Daten (verschiedene Benutzer, Restaurants und Plätze, nicht 10.000-mal derselbe) und das richtige Lastmodell, und es prüft die Antworten auf Korrektheit, denn eine schnelle Fehlerseite ist keine erfolgreiche Anfrage.

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

export const options = {
  scenarios: {
    onsale: {
      executor: 'ramping-arrival-rate',   // open model: arrivals per second
      startRate: 100, timeUnit: '1s',
      preAllocatedVUs: 2000, maxVUs: 20000,
      stages: [
        { target: 4900, duration: '2m' },  // ramp to 1.5x design load
        { target: 4900, duration: '20m' }, // hold
      ],
    },
  },
  thresholds: {                            // fail the run if missed
    http_req_failed: ['rate<0.005'],
    http_req_duration: ['p(99)<500'],
  },
};

export default function () {
  const res = http.get('https://perf.tickets.example/api/events/42/seats');
  check(res, { 'status is 200': (r) => r.status === 200 });
}

Realistische Umgebungen und Daten

Ein Performancetest ist nur so vertrauenswürdig wie seine Umgebung. Eine Testdatenbank mit 10.000 Zeilen, deren Indizes in den Arbeitsspeicher passen, sagt nichts über die Produktion mit 200 Millionen Zeilen aus, bei denen das nicht der Fall ist. Die folgende Checkliste erfasst die üblichen Unterschiede.

Größe und Form der Daten: Datenmengen in Produktionsgröße und realistische Verteilungen, einschließlich Hot Keys wie der beliebtesten Restaurants oder der besten Plätze, die Konkurrenzsituationen erzeugen, die ein gleichmäßiger Test nie sieht. Dieselben Bausteine: dieselben Instanztypen, Container-Limits, Datenbankkonfiguration, Größen der Verbindungspools und Netzwerktopologie (einschließlich Hops zwischen Zonen). Cache-Zustand: Testen Sie sowohl warme als auch kalte Caches, denn ein Deployment oder Failover leert sie (Abschnitt 7.6). Abhängigkeiten: Dienste von Drittanbietern werden durch Stubs ersetzt, die deren echte Latenzverteilung und Rate Limits nachbilden, nicht durch sofortige Antworten. Isolation: keine Tests anderer Teams in derselben Umgebung, sonst sind die Ergebnisse Rauschen. Der Generator selbst: genug Kapazität für die Lastgeneratoren an den richtigen Standorten; ein Generator, der mit 100 % CPU läuft, misst sich selbst.

Manche Organisationen testen vorsichtig in der Produktion, weil keine Kopie ihr je ganz gleicht: synthetische Benutzer und Testereignisse, die aus dem Geschäftsreporting ausgeschlossen werden, Traffic Shadowing (echte Anfragen werden an eine neue Version kopiert und deren Antworten verworfen) und schrittweise Steigerungen mit automatischen Abbruchbedingungen. Das erfordert dieselben Schutzmaßnahmen wie Chaos-Experimente: einen kleinen Blast Radius, einen Notausschalter und eine genaue Beobachtung der SLOs.

Performance-Budgets

Ein Performance-Budget ist eine Grenze, die eine Änderung nicht überschreiten darf, im Voraus vereinbart und automatisch geprüft, damit die Performance nicht Regression für Regression erodiert. Bei Web-Frontends decken Budgets das Seitengewicht, die Skriptgröße und die Core Web Vitals ab; Googles Schwellenwerte für eine gute Erfahrung, gemessen am 75. Perzentil der Seitenaufrufe, sind dort ein Largest Contentful Paint von höchstens 2,5 Sekunden, eine Interaction to Next Paint von höchstens 200 ms und ein Cumulative Layout Shift von höchstens 0,1.

Bei Backends teilt ein Latenzbudget ein Ende-zu-Ende-SLO auf die Hops einer Journey auf. Der Checkout der Essenslieferplattform hat ein p99-Ziel von 800 ms; das Team weist 20 ms dem Gateway zu, 60 ms dem Bestellservice, 80 ms der Preisgestaltung, 450 ms der Zahlung (das meiste davon für den externen Kartenanbieter), 40 ms der Datenbank, 100 ms Netzwerk und Serialisierung und behält 50 ms in Reserve. Jedes Team kennt nun sein eigenes Ziel, und eine Änderung, die die Preisgestaltung auf 150 ms treibt, wird als Budgetverletzung sichtbar, bevor sie zur SLO-Verletzung wird. Streng genommen addieren sich die Perzentile der Teile nicht zum Perzentil des Ganzen; behandeln Sie die Aufteilung daher als technische Zuteilung und prüfen Sie den Ende-zu-Ende-Wert gesondert.

Budgets werden durchgesetzt, indem in der Delivery-Pipeline ein kurzer, stabiler Performancetest läuft und der Build fehlschlägt, wenn ein Schwellenwert überschritten wird, wie es die k6-Schwellenwerte oben tun. Das ist eine Fitness Function für die Performance. Tests in der Pipeline müssen eher wiederholbar als realistisch sein: dieselbe Umgebung, dieselben Daten, dieselbe Last, damit eine Änderung um 10 % eine echte Regression bedeutet und kein Rauschen.