Kapazitätsplanung und Lastwachstum

Kurze Zusammenfassung

1. Bedarfsprognose (Basistrend + Saisonalität + Veranstaltungen).

2. Lastmodell (Open-Model für das Internet).

3. Sicherheitsmarge (Headroom) und fehlerhaftes Budget.

4. Skalierung (Horizont/Vertikal/Auto) + Limits (Rate-Limit/Backpressure).

5. Finanzen: $/1000 RPS, $/ms p95, TCO nach Szenarien.

Begriffe und Metriken

Durchlauf: RPS/QPS/CPS ist der tatsächliche Durchsatz.
Latency p95/p99: Ziel-SLOs für benutzerdefinierte Pfade.
Saturation: die Auslastung CPU/памяти/IO/FD/соединений/очередей.
Fehlerrate: 5xx/timeout/429, fehlerhaftes Budget für den Zeitraum.
Headroom: Anteil der freien Leistung bei Spitzenverkehr (empfohlen ≥ 30%).
Burst: kurzfristiger Anstieg (Sekunden/Minuten), Spike: starker Anstieg × N.

Grundlegende Modelle und Formeln

Little's Law (für Systeme mit Warteschlangen)

L = λ W

L ist die durchschnittliche Anzahl der Anforderungen im System, λ ist die durchschnittliche Eingangsintensität (RPS), W ist die durchschnittliche Zeit im System. Nützlich zum Abschätzen der Tiefe von Warteschlangen.

Lastfaktor (ρ)

ρ = λ / μ

μ - Servicegeschwindigkeit (RPS bei 100% CPU). Bei ρ→1 wächst die Latenz nichtlinear - halten Sie den Arbeitspunkt ρ ≤ 0. 6–0. 75.

Sicherheitsfaktor/Bestand

Capacity_required = Peak_load (1 + Headroom) Degradation_factor

Wobei Degradation_factor N-Fehler, Cache-Degradation, Verlust einer RoR/Region (z. B. 1. 2).

Bedarfsprognose

1. Historie: Tages-/Wochenprofile, Saisonalität, Korrelation mit Ereignissen (Matches/Streams/Auszahlungen).
2. Events: Szenario-Quoten (normaler Tag × 1, Turnier × 2. 3, Finale × 3. 5).
3. Quellen der Fluktuationen: Marketingkampagnen, Releases, Bot-Anomalien.
4. Prognoseeinheiten: RPS nach Routen (Login, Lobby, Katalog, Zahlungen), CPS TLS, QPS DB, Disk IOPS, egress Gbit/s.
5. Vertrauen: Bewahren Sie zwei Szenarien auf - konservativ und aggressiv.

Lastsimulation

Open-Model (Poisson-like parish): plausibel für öffentliche APIs/Web - Verwendung für Sizing.
Closed-model (VU + think-time): geeignet für interne Sequenzen; kombinieren.
Routenmischungen: Gewichtsanteile pro Endpunkt; Schließen Sie nicht nur „heiß“, sondern auch „teuer“ (Registrierung, Anzahlung) ein.
Nicht zu vergessen: Retrays, Warteschlangen, Partner Limits (PSPs, APIs von Drittanbietern).

Auslegung der Sicherheitsmarge

Headroom-Ziel: ≥ 30% zum Peak (für das Internet); für den Zahlungskern und kritische Pfade - 40-50%.
N + 1/N + 2: Wir widerstehen dem Ausfall von 1-2 Instanzen/Zonen ohne Verletzung des SLO.
Multi-Region: Jede Region zieht ≥ 60% der Gesamtspitze (um den Verlust eines Nachbarn zu überleben).
Das Degrade-Regime: wir schalten die nebensächlichen Funktionen ab, wir verringern payload, wir nehmen die Caches/stab-Antworten auf.

Nach Ebenen sortieren

Netzwerk/Edge

CPS/RPS vorne, TLS-Handshake p95, resumption≥70%, egress Gbit/s.
Anycast/Geo-Routing, CDN/WAF-Limits (im Voraus vereinbaren).
Stock: Link/Aplink ≥ Spitze × 1. 3, SYN-Backlog mit Reserve, UDP/443 für H3.

Balancer/Proxy

RPS pro Instance, offene Verbindungen, Warteschlangen, CPU/IRQ.
Keepalive und Connection Pooling - Reduzieren Sie Verbindungen zu Backends.
Vorrat: ρ ≤ 0. 7, limiter по CPS/RPS per route.

Anwendungen

Zielleistung pro Kern (RPS/Core) im Plateau.
Pools (thread/DB/HTTP) - nicht an Grenzen stoßen.
Bestand: Autoscale bis CPU 60-70% und Latenzauslöser (p95).

Caches

Hit-ratio, hotset volume, eviction, replica.
Speicher: Speicher ≥ 1. 2 × Hotset, Netzwerk-Headroom ≥ 30%.

Datenbanken

QPS/TPM, p95 Anfragen, Sperren, Puffer-Cache, WAL/Replikation lag.
IOPS und Festplattenlatenz sind der Schlüssel zu p95.
Lager: CPU-Arbeitspunkt 50-65%, Replikat-Lag <Ziel; Sharding-Plan und Read-Replicas.

Laufwerke/Speicher

IOPS (4k/64k), throughput, fsync cost.
Bestand: IOPS ≥ Peak × 1. 5, Latenz p95 im Zielfenster; separate Pools für Log/Daten.

GPU/ML (bei Online-Inferencing)

Samples/s, latency, VRAM headroom, batching.
Lager: Batch-Parameter für „Säge“ Last, Warm-Pool GPU.

Automatische Skalierung

HPA/KEDA: CPU-Metriken + Custom (p95 latency, RPS, queue).
Warme Pools: vorgewärmte Instances vor den Events.
Step-Scaling: Stufen mit Cooldown, um nicht zu „sägen“.
Reaktionszeit: Ziel im T_scale ≤ 1-2 Minuten für die Frontschicht; für DB - im Voraus.

Begrenzer und Backpress

Rate-limit по IP/ASN/device/route; Quoten für Partner.
Warteschlangen mit TTL, Ablehnung „höflich“ (429/durch graue Ochsen) früher als Zeiträume.
Idempotenz: Schlüssel für Zahlungen; retrai mit budget + jitter.
Request collapsing/SWR: Wecken Sie den Ursprung während des Ausbruchs nicht auf.

Beispiel für eine schnelle Berechnung

Gegeben: 35k RPS-Peakprognose per API, p95 ≤ 250 ms, durchschnittliche Service-Zeit 8 ms pro Instance bei 60% CPU → μ≈125 RPS/Core, 8 Kerne pro Instance → ~ 1000 RPS/Instance.
Schritt 1 (ohne Vorrat): 35 Instances.
Schritt 2 (Hauptraum 30%): 35 × 1. 3 = 46.
Schritt 3 (Ausfall eines AZ, + 20%): 46 × 1. 2 ≈ 55.
Schritt 4 (Rundung + 10% Hot Spare): 61 Instances.
Überprüfung: ρ ≈ 35k/( 61k) ≈ 0. 57 - im grünen Bereich.

Finanzmodell (FinOps)

$/1000 RPS nach Schichten (edge, proxy, app, DB).
$/ms p95 (Kosten des Schwanzabbaus).
TCO-Szenarien: on-demand vs reserved vs spot (mit dem Risiko von Unterbrechungen).
Kapazitätsplan: vierteljährliche Konto-/Clusterlimits, Cloud-Kontingente, PSP/CDN-Limits.

Fehlerbereitschaft und DR

Multi-AZ/Region: Jede Schulter ≈ 60% der Last.
Failover-Plan: Withdraw Anycast, GSLB-Umschaltung, TTL ≤ 60-120 Sekunden.
Kritische Abhängigkeiten: PSP/Banklimits, Zweitanbieter.
Regelmäßige Übungen: Spieltag mit PoP/BG/Cache ausschalten.

Beobachtbarkeit und frühe Sättigungssignale

Wachstum von p95/p99 und Warteschlangen bei stabilem Eingang.
Das Hit-Ratio des Caches fällt, das Origin-Egress-Wachstum.
Retransmits/ECN CE-Anstieg, TLS-Resumptionsabfall.
Wachstum 429/Timeout und Retry-Rate.
Für DB - wachsende Konflikte, Checkpoint-Zeit, WAL fsync.

Betriebliche Praktiken

Capacity Review monatlich: Tatsache vs Plan.
Fenster für Events ändern: Kernel-Freeze und Limits.
Prewarm (CDN/DNS/TLS/Pools) 10-30 min vor dem Peak.
Limits versionieren: Rate-Limit/Pools in Git fixieren.

Spezifität für iGaming/Fintech

Turniere/Matches: Spike + Plateau-Profile, graue Routen für Bots, separate Anmelde-/Einzahlungslimits.
Zahlungen/PSP: Quoten nach Anbieter/Methode, Fallback-Routen, Egress-IP-Pools, SLA Time-to-Wallet.
Content Provider: Verteilung auf Studios, Hot Caches, Shard Pools.
Anti-Fraud/AML: Limit für Regeln/Scoring, Degradierung zu Lichtregeln beim Peak.

Checkliste für die Implementierung

• Prognose der Spitzen (Basis/Saison/Events), zwei Szenarien.
• SLO/fehlerhaftes Budget und Zielkopf ≥ 30%.
• Layer-Sizing (edge/proxy/app/cache/DB/IO/network).
• Limiter: rate-limit, queues, idempotency, retry-budget.
• HPA/KEDA + warm pools; Promotion-Plan vor der Veranstaltung.
• Multi-AZ/region, failover-playbooks, TTL und GSLB.
• Cloud/PSP/CDN-Quoten werden vereinbart und dokumentiert.
• Beobachtbarkeit: Capacity Dashboards, frühe Sättigungssignale.
• DR-Übungen und regelmäßige Capacity-Review.

Typische Fehler

Plan für einen durchschnittlichen RPS ohne Tails/Bursts.
ρ≈0. 9 „auf Papier“ - die Latenz explodiert mit dem geringsten Geräusch.
Grenzen externer Dienste (PSP/CDN/DB-Cluster) ignorieren.
Keine Degrade-Modi und Backpressure - kaskadierende Fails.
Auto-Maßstab ohne Vorheizen - schafft es „nach“ dem Peak.
Ein einziger Kopfraum für alle Schichten - der Flaschenhals wandert ab.

Mini-Playbooks

Vor dem Peak-Event (T-30 Min)

1. Erhöhen Sie minReplicas/target HPA, aktivieren Sie den Warmpool.
2. CDN/DNS/TLS/Anschlüsse aufwärmen, Caches aufwärmen.
3. Poollimits und PSP-Kontingente nach Vereinbarung erhöhen.
4. Graue Routen/Bot-Filter einschalten, schwere Endpunkte eingrenzen.

Teilverlust der Region

1. GSLB → Nachbarregion, TTL 60-120 s.
2. Degrade-Modus aktivieren (Cache/vereinfachte Ausgabe).
3. PSP/egress-IP-Limits neu zuweisen.
4. Statuskommunikation, p95/Fehlerüberwachung.

Anstieg der Retrays

1. Retry-Budget senken, Backoff + Jitter einschalten.
2. Request-collapsing/SWR auf GET aktivieren.
3. Das Rate-Limit für „laute“ ASNs vorübergehend verschärfen.

Ergebnis

Die Kapazitätsplanung ist eine Bedarfsprognose + Engineering-Modell + Sicherheitsmarge + Bedienhebel. Formalisieren Sie SLO und Headroom, berücksichtigen Sie externe Limits, automatisieren Sie Skalierung und Degradation, messen Sie die „Kosten einer Millisekunde“ und führen Sie regelmäßige Capacity-Reviews durch. Dann wird das Lastwachstum nicht zu einem Risiko, sondern zu einer überschaubaren Geschäftskennzahl.