Betrieb und Management → Skalierung der betrieblichen Infrastruktur

Skalierung der betrieblichen Infrastruktur

1) Warum und was als „Skalierung“ zu betrachten ist

Skalierung ist die Systemfähigkeit der Plattform, den Durchsatz (RPS/TPS, Anschlüsse, IOPS, Durchlauf) und die Datenmenge ohne SLO-Verlust und zu kontrollierten Kosten zu erhöhen. Für iGaming/Fintech geht es direkt ums Geld: Einzahlungs-/Wettumwandlung, Live-Spiele und Abrechnungen.

• Halten Sie SLO bei X-fachem Lastwachstum und saisonalen Spitzen.
• Stellen Sie eine vorhersehbare Skalierungszeit (minutes, not hours) bereit.
• Wirtschaft retten: Kosten/RPS, Kosten/Transaktion, Kosten/1k Ereignisse.

2) Prinzipien einer skalierbaren Plattform

1. Horizontal-first: Unterteilung in kleine, stateless-Dienste; Status - in Datenclustern.
2. Back-pressure und Warteschlangen: Glättung von Ausbrüchen, Schutz vor „Stürmen“.
3. Zwischenspeicherung auf allen Ebenen: client/edge/service/DB.
4. Idempotenz und Wiederholbarkeit: Sichere Retrays, Outbox, Dedup.
5. Abhängigkeiten mit Einschränkungen: Timeouts, Breakers, Bulkhead-Isolation, Rate-Limits.
6. Beobachtbarkeit durch Kapazitätssignale: Kopfraum, p95/p99, lag, Anschlüsse, Quoten.
7. Auto-Skalierung mit Gard Rails: HPA/VPA/Cluster Autoscaler + Stop-Bedingungen.
8. Multi-Region nach Design: unabhängige Blast-Zonen, lokale Daten, nachhaltige Failover.

3) Kapazitätsplanung: Wie man „berechnet, wie viel benötigt wird“

Modelleingänge: Ziel-Peak-TPS, Traffic-Profil (stündlich), „kritische Pfade“, Cash-Hit-Raten, durchschnittliche Payload-Raten, SLOs und Provider-Limits.

• RPS → CPU/Pods: 'Pods = RPS p99_time/effektive _ CPU _ in _ Pods' (c 30-50% Marge).
• Warteschlangen: 'minimum _ speed _ consumers ≥ peak _ speed _ producers 1. 2`.
• DB-Anschlüsse: 'max _ conns = active _ pools _ services medium _ pool _ size 1. 3`.
• Cache: Größe = „Hot-Working-Set in N Minuten“ + 20-30% Bestand.
• Egress/CDN: peak egress = peak requests durchschnittliche Antwortgröße (Kompression berücksichtigen).

Headroom: 20-40% Ziel auf dem Höhepunkt (nach Schichten). Unter 15% → der Auslöser „capacity uplift“.

4) Schichten und Skalierungsmuster

4. 1 Edge / CDN / WAF

Edge-Caching (TTL + SWR), Geo-Balance, Kompression, HTTP/2/3.
Rate-Limits am Perimeter über IP/JWT/Schlüssel, Schutz vor Überspannungen.
Fan-Out von Veranstaltungen (Jackpots, Live-Benachrichtigungen) über Broker/Pub/Sub-Kanäle.

4. 2 API-Gateway/Backend-for-Frontend

Horizontale Skalierung nach Statles-Pods, dedizierte Pools nach Downstreams.
HPA nach Geschäftskennzahlen: RPS, p99, Warteschlange im Work-Pool - nicht nur CPU.

4. 3 Asynchrone Warteschlangen/Streaming (Kafka/Rabbit/Pulsar)

Skala nach Parteien und Konsumenten; vermeiden skew (Schlüssel und Verteilung).
Lag-Alerts + automatische Skalierung von Consumern; DLQ und Retry-Topics.
Retention unter SLA Rekonsiliation und Replikation.

4. 4 Caches (Redis/Memcached)

Cluster-Modi, Replikate, Eviction-Policies (LFUs), Multiget, Pipeline.
Trennung von Hot-Key-Aufgaben und Hintergrundaufgaben, Clientlimits und Max-Memory-Richtlinien.

4. 5 Datenbanken

Read-Replikate und Routing-Lesungen, Verbindungspooling.
Sharding nach Region/Tenant/Schlüsselbereich.
CQRS: Einträge - auf Master/Leader, Lesungen - in Replikaten.
Indizierung und Batch-Schreibworkflow (Outbox → Stream → Sink).
Archivierung und Warm/Kalt-Daten (Tiering).

4. 6 Datei-/Objektspeicher

Multithreading, Multipart-Downloads, CDN-Front, asynchrone Transformationen.
Anbieterquoten, Säuberung der „Schwänze“ und egress Budget.

4. 7 Anbieter (PSP/KYC/Studios)

Multi-Vendor und Quoten-/SLO/Value-Routing.
Circuit Breaker + Rate-Limit für jeden Anbieter, Warteschlange von Retrays, „Grace-Modi“.

5) Auto-Skalierung und Gard Rails

• HPA: метрики `rps_per_pod`, `queue_depth`, `p99_latency`; `targetAverageValue`.
• VPA: Empfehlungen für Ressourcen; außerhalb des Peaks aktualisieren.
• Cluster Autoscaler: Nod-Gruppenprofile (Spot + On-Demand) mit Prioritäten.
• PodDisruptionBudget/TopologySpreadConstraints: Gleichmäßigkeit über Zonen hinweg.
• LimitRange/ResourceQuota: Schutz vor „betrunkenen“ Deploys.

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler spec:
scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: api-gw}
minReplicas: 8 maxReplicas: 200 metrics:
- type: Pods pods:
metric:
name: rps_per_pod target:
type: AverageValue averageValue: "120"
- type: Pods pods:
metric:
name: p99_latency_ms target:
type: AverageValue averageValue: "280"
behavior:
scaleUp:
stabilizationWindowSeconds: 90 scaleDown:
stabilizationWindowSeconds: 300

• „Pause & Rollback“ wenn beim Kanarienvogel p99> 1. 3 × baseline 10 Minuten.
• „Freeze scale-down“ zur Primetime, nur Scale-up.
• „Stop retries“ bei 'open _ circuit = 1' zu den Engpässen.

6) Multi-Region: Aktiva/Aktiva und Aktiva/Passiva

Blast-isolierte Regionen: unabhängige Cluster, lokale Geheimnisse/Quoten.
Global Routing: latency-/geo-basiert, health-probes, manuell override.

• Hot - lokal + eventual Replikation (Streams).
• Kritische Transaktionen - Domain-konsistent (Ledger/Salden).
• Failover-Playbooks: schrittweise Quellenänderung, TTL, Aufwärmen der Caches.
• Übung Regulation (DR): vierteljährliches Training mit RTO/RPO Zielen.

7) Netzwerk- und Servicemuster

Service Mesh: mTLS, retry/breaker, outlier detection, per downstream limits.
eBPF/Observability auf L4/L7, Verbindungslimits, Head-of-Line-Schutz.
Interne API-Gateways für S2S, allgemeines Rate-Limit und Audit.
VPC/Subnetze durch Blast-Zonen, NAT/Egress-Kontrolle, Peering mit Anbietern.

8) Leistung: Tests und Nachweise

Load & Stress im Primetime-Profil + Worst-Case.
Soak (lang) - Speicherlecks/Deskriptoren, Latenzwachstum.
Chaos/Spieltage: Sturz Broker/Anbieter/Zone, „langsamer Anbieter“.
Perf-Regressionen in CI: eine Reihe von Referenzszenarien und automatischen Gates.

9) Daten und Speicher: Wachstumsstrategien

Vertikales Wachstum bis zur „Decke“ → horizontal/sharding.
Lesen → Replika/Cache; Einträge → Batchi/Asynchron/Journal.
Schema-Migrationen: expand → migrate → contract, ohne globale Sperren.
Archivierung: Cold Parts in billigem Speicher + On-Demand-Re-Hydrierung.
Suche: einzelne Indizes (OpenSearch/Solr) mit einer Pipeline von inkrementellen Updates.

10) Anbieter- und Quotenmanagement

Quotenkarte (TPS, Fenster, Kosten); alerta 'usage _ ratio> 0. 9`.
Kosten/Qualität Routing (Smart Routing).
OLA ↔ SLO-Vereinbarungen und Quotenerhöhung.
Ein Pool von Alternativen und „heißem“ Umschalten.

11) Beobachtbarkeit und Skalierungssignale

• Capacity headroom по слоям; `queue_lag/backlog growth`; `kafka ISR`; `db connections`/`repl lag`; `redis evictions`; `open_circuit`/`retry_rate`; `quota_usage`.
• Geschäftsmetriken: Erfolgsrate/Einzahlungskonvertierung, Startzeit des Spiels.
• Kosten: Kosten/RPS, Kosten/1k Anrufe.

• Capacity Overview (Kopfraum, Top-Risiken, Burn-Rate SLO).
• Stream & Queue Panel (lag/backlog, consumer saturation).
• DB & Cache (p99, Anschlüsse, Treffer/Anmerkungen).
• Providers & Quotas (TPS, Timeouts, Kosten, Umstellungen).
• Change Safety (vor/nach Release, Kanarienvogel, Autogates).

ALERT HeadroomLowAPI
IF capacity_headroom{layer="api"} < 0. 15 FOR 10m

ALERT KafkaBacklogAtRisk
IF (consumer_lag > 5e6 AND rate(consumer_lag[5m]) > 5e4) AND (hpa_desired == hpa_max) FOR 10m

ALERT DBConnectionsNearMax
IF active_conns / max_conns > 0. 85 FOR 5m

ALERT ProviderQuota90
IF usage_quota_ratio > 0. 9 FOR 5m

12) FinOps: Skalierung ist vorteilhaft

Leistungskennzahlen: Kosten/RPS, Kosten/Einzahlung, Kosten/1k Veranstaltungen.
Right-sizing: VPA/Empfehlungen, Berichte zu „over-provisioned“.
Spot/Preemptible für nicht-kritische; Reserviert/Zugeteilt für Grundlast.
Egress-Budget und Caching, CDN/Edge-Offload.
Erfassung und Archivierung von Protokollen nach Wertstufe (hot vs cold).
Warnquoten (Soft-Cap) und Auto-Tickets für die Erweiterung.

13) Prozesse und Menschen

Change Management: Kanarienvögel, Ficheflags, Stopps bei Regressionen.
Incident-Readiness: runbook 'und „wo man Kapazität hinzufügt“, „wie man eine Region wechselt“.
Peak-Planung: Spiel-/Turnier-/Kampagnenkalender und Anbieterfenster.
Regelmäßige Spieltage und DR-Übungen.
Besitzmatrix: Wer kann „den Knopf drücken“ auf den Failover/Quotenerhöhung.

14) Checklisten zur Umsetzung

• Karte der kritischen Pfade und Grenzen (nach Schichten), das Headroom-Ziel ≥ 30%.
• HPA für Geschäftskennzahlen + Cluster Autoscaler; PDB/SpreadConstraints.
• Warteschlangen auf heißen Pfaden, idempotency-keys, outbox.
• Caches: Hit-Ziele ≥ 90%, Politik evictions, Schlüsselindizes.
• DB: Read-Replikate, Konnektivitäts-Pool, Sharding-Plan.
• Anbieter: Multi-Vendor, Quoten, Breaker/Retrays.
• Dashboards „Kapazität/Stream/DB/Anbieter“, Warnungen aus § 11.
• Kanarienvogel und Autogates „vor/nach Release“.
• DR-Playbook und ein Teilfailover-Training.

• Aufwärmen von Caches, HPA/ASG Pre-Scale, Warm-Standby Repliken.
• Erhöhung der Anbieterquoten, Einbeziehung von Smart-Routing.
• Aktivierung des Nachtmodus der Unterdrückung für unkritische Warnmeldungen.
• Der Ficheflag „safe mode“ ist sofort einsatzbereit.

15) Anti-Muster

Vertikales Upgrade „bis zum Anschlag“ statt horizontal.
Ein gemeinsamer Pool von Threads/Verbindungen auf allen Downstreams (Head-of-Line).
Retrays auf Zeiträumen von Engpässen, Mangel an Jitter → Sturm.
Es gibt keine Hysterese in Alerts und Scale-Policies → „Sägen“.
Eine einzige globale Datenbank ohne Sharding und Datenlokalisierung.
Blindes Vertrauen in das SDK des Anbieters ohne Kontrolle von Timeouts/Retrays/Beobachtbarkeit.
Fehlende DR-Übung: Failover „nur auf dem Papier“.

16) Skalierbarkeit KPI

SLO-Compliance auf dem Höhepunkt (p95/p99, Erfolgsrate).
Headroom durch Schichten in der Prime Time.
MTTS (Mean Time To Scale) - bevor zusätzliche Ressourcen verfügbar sind.
Backlog/Lag Resolution Time - Die Zeit, in der Warteschlangen nach dem Peak zusammenbrechen.
Change Failure Rate für eine Periode des aktiven Wachstums.
Kosten/RPS und Einsparungen durch Cache/CDN/Edge-Offload.
DR Readiness: RTO/RPO in Übungen.

17) Beispiele für „schnelle“ Muster

partitions(topic="bets") = ceil(peak_msgs_per_sec / target_msgs_per_partition)
consumers = min(partitions, max_pods); rebalance_on: skew > 1. 5x scale_up_if: lag > 5e5 && rate(lag[5m]) > 5e4

max_connections = poolers pool_size 1. 3 read_routing: primary (write), replicas (read majority)
shard_key: tenant_id or region_id

maxmemory-policy: allkeys-lfu cluster-replicas: 1 evict-alert: rate(evictions[5m]) > 0 && used_mem/limit > 0. 8

guardrails:
- metric: api_p99_ms, threshold: 1. 3 baseline_1d, window: 10m, action: pause_and_rollback
- metric: error_rate, threshold: 2 baseline_1d, window: 5m, action: pause max_step: 10%
step_interval: 15m

18) FAQ

Q: Was zuerst skalieren?
A: Engpässe laut Dashboards: Warteschlangen/Caches/DB-Lesungen. Die heißen Wege (Einzahlung/Wette/Spielstart) haben Priorität.

F: Wie kann man verstehen, dass Auto-Skalierung „schlimmer macht“?
A: Sehen Sie die Korrelation: scale - up↑ und p99/Fehler verbessern sich nicht - vielleicht „skalieren Sie das Problem“ (enger Downstream/Quote). Schalten Sie Breaker/Degradation ein.

F: Wird immer ein zweiter Anbieter benötigt?
A: Für kritische Pfade ja. Ansonsten zumindest „safe mode“ mit vereinfachtem Skript und Cache.

Q: Active-active или active-passive?
A: Wenn die RTO-Anforderungen niedrig sind und viele regionale Spieler aktiv-aktiv sind. Ansonsten starten Sie aktiv-passiv mit einem verbrauchten Failover.