Technologie und Infrastruktur → Cloud-Architektur und SLA
Cloud-Architektur und SLA
1) Warum SLAs und wie man sie verwaltet
SLA (Service Level Agreement) - ein externes Versprechen an Unternehmen/Partner über Verfügbarkeit, Geschwindigkeit und Korrektheit des Dienstes.
SLO (Service Level Objective) - Interne Zielebenen für Teams.
SLI (Service Level Indicator) sind messbare Metriken, auf deren Basis der SLO bewertet wird.
iGaming/Fintech zeichnet sich durch enge Spitzenfenster (Turniere, Live-Wetten, Berichtszeiträume, „Gehalt“ -Tage), eine starke Abhängigkeit von PSP/KYC-Anbietern und Geographie aus. SLAs müssen dieses Verhalten berücksichtigen, und die Architektur muss Garantien bieten, die nicht nur durchschnittlich, sondern auch perzentil sind.
2) Grundlegende Terminologie
Verfügbarkeit - Anteil der erfolgreichen Abfragen pro Intervall.
Latenz - P50/P95/P99 für Schlüsseloperationen.
Fehler - genau definieren (5xx, Timeout, Geschäftsfehler?).
RTO (Recovery Time Objective) - wie viel Zeit für die Wiederherstellung erlaubt ist.
RPO (Recovery Point Objective) - Wie viele Daten können bei einem Unfall verloren gehen?
Error Budget - 1 − SLO, „Reserve“ für Änderungen und Vorfälle.
3) Cloud-Architektur Rahmen unter SLA
3. 1 Mehrzonigkeit (Multi-AZ)
Statusreplikation (DB, Cache, Warteschlangen) für mindestens 2-3 AZ.
Kalt/warm Standby, automatischer Failover.
Lokale Balancer (L4/L7) mit Health-Checks per-AZ.
3. 2 Multiregion
Asset-Asset: niedrige RTO/RPO, schwierigere Konsistenz und Kosten.
Asset-Passiv (hot/warm): günstiger, RTO größer, aber einfachere Datenkontrolle.
Geografisches Routing (GeoDNS/Anycast), Isolation „blast radius“.
3. 3 Speicher und Daten
Transaktionale DBs: synchrone Replikation innerhalb einer Region, asynchrone interregionale.
Cache: regionalübergreifende Replikate, Modus „local reads + async warmup“.
Objektspeicher: Versionierung, Lebenszyklen, Cross-Region-Replikation.
Warteschlangen/Streaming: Spiegelcluster/multiregionale Streams.
3. 4 Isolierung der Konturen
Trennung von kritischen Diensten (Zahlungen/Wallet) und „schweren“ analytischen Aufgaben.
Rate-limits/quotas zwischen den Konturen, damit die Berichte nicht „fressen“ prod.
4) Hochverfügbarkeitsmuster
Bulkhead & Pool Isolation - Isolierung von Pools von Verbindungen und Ressourcen.
Circuit Breaker + Timeouts - Schutz vor hängenden externen Integrationen.
Idempotency - Wir wiederholen Anfragen ohne doppelte Abschreibungen.
Graceful Degradation - Wenn degradiert, deaktivieren wir nicht-fundamentale Fici (Avatare, erweiterte Filter).
Backpressure - Steuern Sie den eingehenden Fluss, lassen Sie keine Warteschlangen „bis zum Horizont“ zu.
Chaos/Failure Injection sind geplante „Flops“, um Zuverlässigkeitshypothesen zu testen.
5) DR-Strategien (Disaster Recovery)
Auswahl: Zahlungen/Wallet - Minimum Hot Standby; Inhalt/Verzeichnis - Warm; Berichte - Backup & Restore mit klaren Fenstern.
6) Über SLI/SLO: Wie man richtig misst
6. 1 SLI nach Stufen
Client-SLI: End-to-End (einschließlich Gateway und externer Anbieter).
Service SLI: „reine“ Latenz/Servicefehler.
Business-SLI: CR (registratsiya→depozit), T2W (Time-to-Wallet), PSP-Decline-Rate.
6. 2 Beispiele für SLO
Core-API-Verfügbarkeit: ≥ 99. 95% in 30 Tagen.
Latenz der Payout-Initiation: P95 ≤ 350 ms, P99 ≤ 700 ms.
PSP Webhooks: ≥ 99. 9% für 60 Sekunden (mit Retrays).
Data Freshness Berichte: ≤ 10 min lag in 95% der Zeit.
6. 3 Error Budget Policy
50% des Budgets sind für Änderungen (Releases/Experimente), 50% für Vorfälle.
Die Verbrennung des Budgets → Fries Fich, nur Stabilisierung.
7) Leistung und Skalierung
HPA/VPA mit SLO-orientierten Signalen (nicht nur CPU, sondern auch Warteschlangen/Latenz).
Prädiktives Scaling basierend auf Zeitplänen und historischen Peaks.
Warme Pools/Vorwärmen der Verbindungen zur DB/PSP vor Turnieren.
Caching und Edge - Reduzieren Sie RTT, insbesondere für Spielekataloge und statische Assets.
8) Netzwerkschicht und globaler Verkehr
Anycast/GeoDNS zur Minimierung der Latenz und Lokalisierung von Unfällen.
Failover-Richtlinien: Gesundheitstests der Region, Schwellenwerte, „Stickiness“ mit TTL.
mTLS/WAF/Rate Limit am Rand, Schutz vor Bot-Verkehr.
Egress-Steuerung zu PSP/KYC durch allow-list und SLA-aware Retrays.
9) Daten und Konsistenz
Auswahl der Konsistenzstufe: streng (Zahlungen) vs eventual (Katalog/Bewertungen).
CQRS zum Entladen von Lese- und vertikalen kritischen Befehlen.
Outbox/Inbox für „just-in-once“ Event-Lieferung.
Downtime-freie Migrationen: expand-migrate-contract, doppelter Eintrag während MAJOR-Änderungen.
10) Beobachtbarkeit (Observability) unter SLA
Traces durch das Gateway: Korrelation 'trace _ id' mit Partner/Region/API-Version.
SLO-Dashboards mit Burn-Rate, „Wetter“ nach Region und Anbieter.
Alerts durch Symptome, nicht durch Proxy-Symptome (nicht CPU, sondern P99/Fehler).
Synthetik: externe Kontrollen aus den Zielländern (TR, BR, EU...).
Audit und Reporting: Export von SLI/SLO in das Partnerportal.
11) Sicherheit und Compliance
Segmentierung von Netzwerken und Secret Management (KMS/Vault).
Verschlüsselung im Flug/in Ruhe, PAN/PII Tokenisierung.
Zugriffsrichtlinien nach Rolle für Admins/Operatoren.
Unveränderliche Protokolle (WORM) und Retention für Audits.
Regulatorisch: Lagerung in der Region, Berichte, Nachweisbarkeit der SLA-Ausführung.
12) FinOps: SLA als Werttreiber
Setzen Sie Preise auf SLO-Abweichungen: Wie viel kostet + 0. 01% Verfügbarkeit?
Profilieren Sie Spitzenfenster, blasen Sie nicht konstante Energie auf.
Right-sizing und „spot where can“ für Hintergrundaufgaben.
Quoten und Budgets für Konturen, keine „freie“ Degradierung zulassen.
13) Zuverlässigkeitsprüfung
GameDay/Chaos-Sessions: AZ/PSP ausschalten, Warteschlangenverzögerungen, BGP-Pausen.
DR-Drill: Regelmäßiges Training zur Umstellung der Regionen mit Zielen nach RTO.
Load & Soak: lange Läufe mit echten Wett-/Turnierprofilen.
Replay-Incidents: Bibliothek bekannter Fails und Playback-Skripte.
14) SLA-Prozesseite
SLO-Verzeichnis: Besitzer, Formel, Metriken, Quellen, Warnungen.
Änderungen über RFC/ADR: Abschätzung der Auswirkungen auf das Error Budget.
Post-Mortems: Architektur und Ranbooks verbessern, SLO anpassen.
Kommunikation mit Partnern: Mailings, Status-Seite, geplante Wartung.
15) Beispiele für SLI/SLO/Berichte
15. 1 Formeln
SLI_availability = (успешные_запросы / все_запросы) 100%
SLI_latency_P99 = перцентиль_99(латентность_запроса)
SLI_webhook_D+60 = доля вебхуков, доставленных ≤ 60 сек15. 2 SLO-Kit-Beispiel für Core API
Verfügbarkeit (30 Tage): 99. 95%
P95 Endpoint '/v2/payouts/create': ≤ 350 ms
Fehler 5xx (gleitend 1 h): <0. 3%
Webhook delivery ≤ 60 сек (P99): ≥ 99. 9%
RPO für den Geldbeutel: ≤ 60 Sekunden, RTO ≤ 5 Minuten
15. 3 SLA-Bericht (Quetschung)
Abgeschlossen: 99. 97% (SLO 99. 95%) +
Verstöße: 2 Folgen in der BR-Region wegen PSP-Timeouts (kumuliert 8 Min.).
Maßnahmen: Smart-Routing nach Fehlercodes hinzugefügt, Warmpool der Anschlüsse an PSP-B erhöht.
16) Checkliste Umsetzung
1. Kritische Benutzerpfade und entsprechende SLIs sind definiert.
2. SLO für 30/90 Tage + error budget policy.
3. Multizone und DR-Plan mit RTO/RPO-Zielen, regelmäßige Drill.
4. Synthetics aus Geo-Targeting, Dashboards per-Region/per-PSP.
5. Die Muster der Nachhaltigkeit: Circuit Breaker, Backpressure, Idempotency.
6. Degradationspolitik und Feature-Flags für deaktivierbare Fich.
7. FinOps: Budgets nach Konturen, Prognose von Peaks, warme Pools.
8. Sicherheit: Segmentierung, Verschlüsselung, Audit.
9. SLA-Dokumentation für Partner, Kommunikationsprozess.
10. Retrospektiven und Überarbeitung des SLO alle 1-2 Quartale.
17) Anti-Muster
Versprechen Sie SLAs ohne messbare SLIs und transparente Zählmethode.
Lesen Sie die Verfügbarkeit „am Eingang des Dienstes“ und ignorieren Sie das Gateway/die Anbieter.
Verlassen Sie sich nur auf die durchschnittliche Latenz und ignorieren Sie die P99-Schwänze.
DR „auf dem Papier“, kein echtes Training.
„Ewige“ Ressourcen ohne Grenzen: Ein Bericht fällt prod.
Mischen Sie Prod und Heavy Analytics in einem Cluster/DB.
18) Ergebnis
Die Cloud-Architektur unter SLA ist eine Kombination aus technischen Mustern (Multi-AZ/Region, Isolation, ausfallsichere Daten), Prozessen (SLO, Error Budget, DR-Drill) und Ökonomie (FinOps). Berechtigen Sie sich für vorhersehbare Ausfälle: Testen Sie die Fehlertoleranz, messen Sie an Perzentilen, begrenzen Sie den „Explosionsradius“ und kommunizieren Sie offen. Dann werden aus den SLA-Versprechen kein Marketing, sondern gelenkte Ingenieurpraxis.