Was ist Scalability Testing?

Was ist Scalability Testing?

Scalability Testing misst, wie sich die Performance eines Systems ändert, wenn Sie Ressourcen hinzufügen. Mehr Pods, mehr Nodes, größere Instances, mehr Datenbank-Replicas. Das Ziel ist zu validieren, dass das Hinzufügen von 2× Infrastruktur nahezu 2× Durchsatz liefert (lineares Scaling), nicht 1,2× (sub-linear, teures Scaling) oder 0,5× (negatives Scaling durch Coordination Overhead).

Scalability Testing vs Load Testing

Ein Load Test misst Performance bei einer fixen Infrastrukturgröße. Scalability Testing misst Performance über mehrere Infrastrukturgrößen hinweg:

• Load Test bei 1.000 RPS auf 1 Node → p95-Latenz 600 ms.
• Scalability Test über 1, 2, 4, 8 Nodes → handhaben 8 Nodes 8.000 RPS bei 600 ms (linear), 6.000 RPS bei 600 ms (sub-linear) oder 4.000 RPS bei 1.200 ms (Coordination Overhead dominiert)?

Der Scalability Test ist nicht ein Run. Es ist eine Serie von Load Tests bei zunehmender Kapazität, mit den Daten geplottet, um die Skalierungskurve zu zeigen.

Horizontale vs vertikale Skalierbarkeit

• Horizontale Skalierbarkeit: mehr Nodes / Pods / Container hinzufügen. Testen durch das Ausführen derselben Last gegen 1, 2, 4, 8, 16 Instances.
• Vertikale Skalierbarkeit: die Ressourcen eines Nodes erhöhen (CPU, Memory, Disk IOPS). Testen durch das Ausführen derselben Last gegen kleine, mittlere, große, xlarge Instances.

Die meisten modernen Systeme sollten horizontal sauber skalieren. Stateful-Systeme (besonders Datenbanken) skalieren oft vertikal, bis sie an Hardware-Limits stoßen, dann brauchen sie Sharding oder Read Replicas für weiteres Scale.

Wann Scalability Tests ausführen

• Bevor Sie sich auf Infrastruktur-Budget festlegen. Wenn Sie 10.000 RPS brauchen und jeder Node 1.000 handhabt, brauchen Sie 10 Nodes oder 15? Scalability Testing sagt Ihnen die echte Ratio.
• Validierung von Autoscaling. Autoscaling nimmt an, dass das Hinzufügen von Pods proportionale Kapazität hinzufügt. Scalability Testing bestätigt (oder findet den Coordination Overhead, der die Annahme bricht).
• Pre-Architecture-Change. Migration von Monolith zu Microservices? Die Skalierungs-Charakteristika der neuen Architektur sind unbekannt, bis getestet.
• Datenbank-Scaling-Validierung. Read Replicas hinzufügen, Sharding oder auf einen Managed Scaling Service gehen? Validieren, dass die neue Topologie wie beworben skaliert.
• Vendor-Evaluierung. Vergleichen von Aurora vs RDS vs DynamoDB? Führen Sie denselben Workload bei zunehmender Scale gegen jeden aus und vergleichen Sie.

Wichtige Scalability-Test-Metriken

1. Skalierungsfaktor. Durchsatz bei 2N Nodes / Durchsatz bei N Nodes. Sollte ~2,0 für lineares Scaling sein.
2. Per-Node-Durchsatz. Durchsatz bei Scale geteilt durch Node-Anzahl. Sollte konstant bleiben; wenn er fällt, treffen Sie auf Coordination Overhead.
3. Per-Node-Latenz. Latenz bei Scale vs Latenz bei Single Node. Sollte konstant bleiben oder sich verbessern; wenn sie klettert, ist Coordination teuer.
4. Coordination-Overhead-Aufschlüsselung. Wo geht Zeit hin, wenn Scale wächst? Cross-Node-Network-Calls? Distributed Locks? Consensus-Protokolle? Die Overhead-Quelle zu identifizieren, sagt Ihnen, was zu fixen ist.

Wie einen Scalability Test ausführen

Die Mechanik: führen Sie denselben Load Test gegen das System bei mehreren Infrastrukturgrößen aus. Plotten Sie Durchsatz, Per-Node-Durchsatz und p95-Latenz über die Größen.

In JMeter oder k6 bleibt das Skript zwischen Runs identisch. Ändern Sie nur die Infrastruktur (Deployment skalieren, Instance-Class ändern, Read Replicas hinzufügen). Der Load Test misst dann die resultierende Performance.

Führen Sie von LoadFocus aus für konsistente Lastgenerierung über die Testserie. Dieselben Regionen und dieselbe VU-Anzahl zu verwenden, stellt sicher, dass die einzige Variable Ihre Infrastruktur ist, nicht das Test-Harness.

Für Scalability Tests, die mehrjährige Infrastruktur-Planung informieren, bietet LoadFocus Load Testing Services, wo Ingenieure die Scale-Punkte designen, die Testserie ausführen und die Skalierungskurven-Analyse mit Cost-per-RPS-Implikationen produzieren.