Kapazitätsplanung

1) Was ist Kapazitätsplanung und warum ist es notwendig

Kapazitätsplanung (Capacity Planning) ist ein systematischer Prozess zur Bewertung und Bereitstellung der Ressourcen, die erforderlich sind, um gezielte SLOs zu minimalen Kosten zu erreichen. Dabei geht es nicht nur um CPU/Speicher, sondern auch um Netzwerkbandbreite, Speicher, DB/Cache, Warteschlangen/Event-Bus, externe Anbieter (Payments/CUS/Fraud) sowie Personal (On-Call, Support).

• Führen Sie SLO/SLAs auch in Peaks und Degradationen durch.
• Minimieren Sie TCO und einfaches Kapital (Overprovisioning).
• Reduzieren Sie das Risiko von Vorfällen durch Erschöpfung der Ressourcen (Sättigung → p99/Fehler).
• Sicherstellung der Vorhersehbarkeit von Veröffentlichungen und Kampagnen (Marketing, Turniere, Top-Matches).

2) Input und Quellen der Wahrheit

Beobachtbarkeit: RPS/Konkarrentabilität, p50/p95/p99, Fehlerrate, Sättigung (CPU, mem, Disk IOPS, Netzwerk pps/mbps), Warteschlangenlängen, Limitrate.
Business Events: Kampagnenkalender, Saisonalität (Abende/Wochenende/Mega Events), Regionen/Jurisdiktionen.
Tehdolg/fichi: Roadmap von Releases, architektonische Änderungen (z.B. Verschlüsselung, neue Logging).
Anbieter: Quoten und throughput payment/CUS/mail/fraud services.
Vorfälle der Vergangenheit: wo der Engpass ist (DB, Cache, L7-Balancer, Bus, CDN, Disk).

3) Grundbegriffe und Formeln

Headroom - Kapazitätsreserve: 'headroom = (max _ steady _ RPS − ist _ RPS )/max _ steady _ RPS'.
Zielwert in der Spitze 20-40% (für kritische Flüsse).
Saturation - das Verhältnis von belegten zu verfügbaren Ressourcen (CPU%, Speicher/GC, Verbindungen, Dateibeschreibungen, IOPS, Warteschlangentiefe).
Throughput steady - die Geschwindigkeit, mit der p99 und error-rate SLO für eine lange Zeit durchführen (kein einmaliger Anstieg).
Die Kapazitätseinheit (CU) ist eine normierte Leistungseinheit für einen Dienst (z.B. X RPS pro Pod vCPU = 1, RAM = 2 GiB).
Systemlimit - max ohne Degradation:'N _ pods × CU'. Es ist wichtig, die geteilten Abhängigkeiten (DB/Cache/Bus) zu berücksichtigen.

4) Nachfragemodell: Prognose

Statistische Reihen: wöchentliche/tägliche Saisonalität, Feiertage, Sportfinale, regionale Spitzen.
Kohorten: nach Ländern, Zahlungsanbietern, Geräten, VIP-Segmenten.
Event-Deltas: Auswirkungen von Kampagnen/Pushes/Releases/SEO.
„Was wäre wenn“ (Szenarienplanung): + 50% auf den Verkehr um 19: 00-22: 00; der Ausfall des Anbieters A → die Umverteilung auf B (+ 30% zur Latenz).
Echtzeit-Anpassungen: Nowcasting nach Lead-Metriken (Wiederbelebung von Sitzungen, Warteschlange für das Spiel, Körbe).

5) Angebotsmodell: Wo die Kette „bricht“

Das Fließband der Anfrage: Edge/CDN → der L7-Balancer → die App → kesch → BD → äußerlich API → die Reihe/Reifen → die Bearbeiter/ETL.

• Kapazität (CU/Instance), Skalierbarkeit (Horizont ./Drehpunkt.) , Grenzen (Anschlüsse, pps, IOPS), Verzögerungen.
• Opt-Out-Richtlinien (Rate Limit, Circuit Breaker, Degradation).
• SLOs sind lokal und ihr Beitrag zur e2e-SLO.

6) Fehlerbestand und Budget

Wir binden Headroom an das Error Budget: weniger Budget → mehr Bestand.
Für kritische Threads (Zahlung/Verifizierung) ist der Headroom höher, für sekundäre Threads niedriger.
Kalt-/Warmreserven: aktivierbar bei Peak/Crash.

7) Skalierung: Taktik

HPA (nach Lastmetriken): RPS, Latenz, Warteschlangenlänge, benutzerdefinierte SLIs (besser als CPU%).
VPA: Anpassung der Ressourcen an die Pods (genauer mit stateful und p99 GC).
KEDA/Adapter: Skalierung nach externen Quellen (Kafka lag, Redis list length, CloudQueue depth).
Warm-Pools/Warm-Up: Vorgezogene Instanzen, um einen Kaltstart zu vermeiden.
Das Herangehen "Load-as-Code": die Politiker awtoskejla/limitow/tajmautow/retrajew wersionirujutsja gehen review eben.

8) Warteschlangen, Backpress und Tail-Management

Ziel ist es, das lawinenartige Wachstum von p99 zu verhindern.
Wir begrenzen die Parallelität und die Größe der Warteschlange, geben Zeitfenster und Idempotenz ein.
Hedging/Retry-Budget: Begrenzen Sie das Gesamtbudget für Benutzer- und Systemzeit.
Graceful degradation: Deaktivierung von sekundären Fich bei Überlastung.

9) DB, Caches und Speicher

DB: Konnektivitätslimit, Protokollierung/FSync, Indizes, Abfrageplan, Replica Lag, Hot-Keys/Tabellen, max. TPS für Transaktionen.
Keshi: Trefferverhältnis nach Segmenten, „Sturm der Fehlwürfe“ bei Freigabe/Behinderung, Schlüsselverteilung.
Storaj: IOPS/throughput, Verzögerungen, Kompression, TTL, Bereinigung alter Parties/Snap-Shots.
Migrationsschema: expand→migrate→contract ohne Blockaden.

10) Ereignisströme und ETLs

Kafka/Bus: Bandbreite der Parties, Lag, ISR, Compaction, Producer/Consumer Limits.
ETL/Batchi: Startfenster, Laufzeitbudgets, Auswirkungen auf den Prod Storan (throttle I/O).
Idempotenz und exactly-once-like für kritische Flows (Zahlungen/Salden).

11) Netzwerk und Perimeter

L4/L7 Balancer: connection limits, syn backlog, TLS offload, session reuse.
CDN/Edge: Bandbreite, Cache-Richtlinie zur Reduzierung der Ursprungslast.
Netzinterne Limits: pps/mbps im VPC/Subnetz, egress-cost (FinOps).

12) Multi-Region, DR und Jurisdiktionen

Strategien: aktiv-aktiv (GSLB/Anycast), aktiv-passiv (heiß/warm/kalt DR).
N + 1 nach Regionen: dem Verlust von AZ/Region standhalten, während SLO-Core-Streams beibehalten werden.
Rechtliche Lokalisierung: Trennung von Verkehr/Daten nach Ländern, unterschiedliche Limits und SLOs nach Anbietern.
DR-Tests: regelmäßige Spieltage mit echter Lastverlagerung.

13) Externe Anbieter: Quoten und Routen

Zahlungen/KYC/Betrugsbekämpfung/Mail/SMS: TPS, Burst, Tageslimits.
Multi-Provider: Routing nach Latenz/Erfolg, SLO per Provider, Auto-Failover.
SLA-Verträge: e2e-SLO-Compliance, Eskalationskanäle, Status-Webhooks.

14) FinOps: Kosten und Effizienz

TCO: compute + storage + network egress + Lizenzen/Anbieter + Bereitschaften.
Unit Economics: Kosten für 1k Anfragen/1 Einlagengeschäft/1 KYC.
Optimierung: Right-Sizing, Spot/Präfix-Rabatte, Cache-Trefferquote, Log-/Trace-Dedup, Cold-Storage-Levels.
Lastverschiebung im Zeitraffer: nicht kritische Batches in „Nacht“ -Fenster und Billigregionen.

15) Dashboards und Berichterstattung (Mindestsatz)

• Aktuelle Last vs stetiger Durchschlag entlang der Links.
• Headroom nach Dienstleistungen und Regionen; Prognose für 24/72 Stunden.
• FinOps KPI: $/1k Anfragen, $/Einzahlung.

• Top-Engpässe (p99, Sättigung, Lag), Bestand nach DR.

• Erfolg/Latenz und Grenzen der Anbieter; Anteil des Verkehrs auf den Strecken.

• Plan für Upgrades/Indizes/Optimierungen, erwartete Einsparungen/Kapazitätswachstum.

16) Prozesse und Rollen

RACI: Plattform (Infra/Cluster/Balancer), DB/Daten (Indizes, Replikationen), Servicebefehle (Profiling/Cache), SRE (SLO, Alerts), Sec/Compliance (Krypto/Zeitschriften), Finanzen (Budget).
Rhythmus: Wöchentliche Capacity-Review (Roadmap, Prognose, Risiken), monatliche FinOps-Zusammenfassungen, vierteljährliche DR-Tests.
Change Management: Große Kampagnen/Releases durchlaufen ein Capacity-Gate (Checkliste unten).

17) Checkliste für Freigabe und Kampagnen (capacity-gate)

• Lastprognose für Spitze und „+ x% Notschwanz“.
• Verfügbarer Headroom für Core-Streams (Payments/CUS/Login).
• Den Anbietern wurden Quoten bestätigt; Alternativrouten sind aktiv.
• HPA/KEDA Schwellen und Warmpool sind eingerichtet.
• Warteschlangen/Limits und Degradationen überprüft (Playbooks bereit).
• Kanarische Anteile und Auto-Rollback enthalten.
• Dashboards/Alerts (Burn-Rate, Saturation, p99) geprüft.
• Der DR-Plan und die Eskalationskontakte sind relevant.

18) Anti-Muster

„CPU <70% - alles gut“: Grenzen der Abhängigkeiten ignorieren (DB-Anschlüsse, IOPS, Warteschlangen).
Zentralisierte „Black Box“ ohne Per-Link-Metriken - es ist unmöglich zu verstehen, wo das Limit ist.
Fehlende Cache-Strategie - Release-Fehler töten Herkunft.
Der Hardcode der Rückzugslimits ohne Budgets ist ein Sturm von Anfragen.
„One Payment Provider“ ist der Punkt der Ablehnung auf dem Höhepunkt.
Das Ignorieren von Warmreserven ist ein Kaltstart als Ursache für Zwischenfälle.
Es gibt keine regelmäßigen DR-Tests - der Plan funktioniert nicht, wenn er benötigt wird.

19) Minikalkulation (Beispiel)

Service X: nachhaltig 350 RPS pro Pod (vCPU = 1, RAM = 2 GiB). Ziel sind 5.000 RPS, Headroom 25%.
Benötigte Leistung = '5000/0. 75 = 6667 RPS`.
Podov = „ceil (6667/350) = 20“. Plus warm-pool 15% → 3 weitere pods.
DB: 12k TPS Limit, aktuelle 9k TPS Credit, Peak 10 Prognose. 5k TPS → Lager 1. 5k (14%). Erforderlich: Indizes/Sharding/Replikate oder Caching zur Reduzierung auf 8. 5k.
Anbieter A (KYC): 120 rps Quote, 95 rps Spitze, + 40% Kampagne → 133 rps> Quoten → 70% A/30% B Routing.

20) Capacity Planung Implementierungsvorlage

1. Beschreiben Sie den e2e-Weg und die Engpässe.
2. Geben Sie die CU ein und messen Sie den stetigen Durchzug jeder Schicht.
3. Konfigurieren Sie die Saturations- und p99-Metriken auf allen Links.
4. Erstellen Sie einen Veranstaltungs-/Kampagnen-/Veröffentlichungskalender.
5. Erstellen Sie eine Prognose für Kohorten und Was-wäre-wenn-Szenarien.
6. Pin headroom per-stream und per-region (Bindung an error budget).
7. Konfigurieren Sie HPA/VPA/KEDA + warm-pools, limits/retrays/queues.
8. Anbieter-Quoten prüfen, Multi-Routen ermöglichen.
9. Sammle Dashboards und den wöchentlichen Capacity-Review-Rhythmus.
10. Vierteljährlich - DR-Übungen und Modellrevision.

21) Das Ergebnis

Kapazitätsplanung ist ein überschaubares Bündel von Prognosen, architektonischen Einschränkungen und Kosten, nicht „Add CPU“. Wenn jede Schicht des e2e-Pfades eine gemessene Kapazität hat und Headroom- und Degradationsstrategien mit SLO und Error-Budget verbunden sind, dann sind Spitzenlasten, Kampagnen und Unfälle keine Überraschung mehr. Dieser Ansatz reduziert das Risiko von Vorfällen, stabilisiert Geschäftsmetriken und optimiert die Kosten.