Tecnologia e Infrastruttura → Architettura cloud e SLA
Architettura cloud e SLA
1) Perché SLA e come gestirli
SLA (Service Level Agreement) è una promessa esterna al business/partner sulla disponibilità, velocità e correttezza del servizio.
SLO - Livelli di destinazione interni per i comandi.
SLI (Service Level Indicator) - Metriche misurabili basate su SLO.
Gli iGaming/Fintech sono caratterizzati da finestre rigide di picchi (tornei, lave, periodi di rendicontazione, giorni di stipendio), una forte dipendenza da PSP/KYC provider e geografia. La SLA deve tenere conto di questo comportamento e l'architettura deve garantire non solo le garanzie medie, ma anche quelle percettive.
2) Terminologia di base
Disponibilità (Availability) - Percentuale di query riuscite per intervallo.
Latenza - P50/P95/P99 per operazioni chiave.
Errore - Identificare con precisione (5xx, timeout, errore aziendale?).
RTO - Quanto tempo è consentito per il ripristino.
RPO - Quanti dati possono essere persi in caso di incidente.
Errore Budget - 1 - SLO, «riserva» per cambiamenti e incidenti.
3) Ossatura dell'architettura cloud sotto SLA
3. 1 Multi-AZ
Replica dello stato (database, cache, code) su un minimo di 2-3 AZ.
Standbai freddo/caldo, failover automatico.
Bilanciatori locali (L4/L7) con assegni health per-AZ.
3. 2 Multiregione
Asset-asset: RTO/RPO basso, più complicato consistenza e costo.
Attivo passivo (hot/warm): più economico, RTO più grande, ma più semplice da controllare.
Routing geografico (GeoDNS/Anycast), isolamento «blast radius».
3. 3 Storage e dati
Database transazionali: replica sincrona all'interno della regione, asincrona interregionale.
Cache: repliche cross-regionali, modalità locale reads + async warmup.
Archivio oggetti: versioning, loop life, cross-region replication.
Code/streaming: cluster mirroring/flussi multi-regionali.
3. 4 Isolamento dei tracciati
Separazione tra servizi critici (payments/wallet) e attività analitiche «pesanti».
Rate-limits/quotas tra i tracciati, in modo che i report non «mangiino» il profumo.
4) Pattern ad alta disponibilità
Bullkhead & Pool Isolation - Isolamento dei pool di connessioni e risorse.
Circuito Breaker + Timeouts - Protezione dalle dipendenze delle integrazioni esterne.
Idempotency - Ripetiamo le richieste senza doppi prelievi.
Graceful Degradation - In caso di degrado, disattiviamo le fitte non sommarie (avatarchi, filtri avanzati).
Backpressure - Controlla il flusso in entrata, non permettere code fino all'orizzonte.
Chaos/Failure Injection - «fallimenti» pianificati per verificare le ipotesi di affidabilità.
5) Strategie DR (Disaster Recovery)
Scelta: pagamenti/portafogli - minimo Hot Standby; contenuto/catalogo - Warm; report - Backup & Restore con finestre chiare.
6) SLI/SLO: come misurare correttamente
6. 1 SLI per livello
SLI client: end-to-end (inclusi gateway e provider esterni).
Servizio SLI: latitanza netta/errori del servizio.
Business SLI: CR (registratsiya→depozit), T2W (time-to-wallet), PSP-decline rate.
6. 2 Esempi SLO
Disponibilità API Core: ≥ 99. 95% in 30 giorni.
P95 da 350 mc, P99 da 700 mc.
Consegna dei siti PSP: 99. 9% per 60 secondi (con retrai).
Report Data Freshness: ≤ 10 min in 95% del tempo.
6. 3 Error Budget Policy
Il 50% del budget è destinato ai cambiamenti (rilasci/esperimenti), il 50% agli incidenti.
Bruciando il budget, frisco, solo stabilizzazione.
7) Prestazioni e scalabilità
HPA/VPA con segnali SLO orientati (non solo CPU, ma anche code/latenza).
Skailing predittivo basato su orari e picchi storici.
Warm pools/pre-riscaldamento delle connessioni al database/PSP prima dei tornei.
Cache e edge - riduce la RTT, soprattutto per le directory di gioco e gli assetti statici.
8) Livello di rete e traffico globale
Anycast/GeoDNS per ridurre al minimo la latitanza e localizzare gli incidenti.
Policy Failover health-test della regione, soglie, «stickansa» con TTL.
mTLS/WAF/Rate Limit sul bordo, protezione dal traffico bot.
Controllo Egress per PSP/KYC su allow-list e SLA-aware retrai.
9) Dati e consistenza
La scelta del livello di coerenza è rigorosa (payments) vs avvenual (directory/rating).
CQRS per scaricare la lettura e le verticali dei comandi critici.
Outbox/Inbox per la consegna degli eventi.
Migrazioni senza downtime: expand-migrate-contract, doppia voce durante le modifiche MAJOR.
10) Osservabilità (Osservabilità) sotto SLA
Trade attraverso gateway: correlazione «trace _ id» con partner/regione/versione API.
SLO-dashboard con burn-rate, «meteo» per regione e provider.
Alert per sintomi, non per sintomi proxy (non CPU, ma P99/errore).
Synthetics - Controlli esterni da paesi targati (TR, BR, EU...).
Controllo e report: esportazione di SLI/SLO in un portale di partner.
11) Sicurezza e compliance
Segmentazione delle reti e gestione del segreto (KMS/Vault).
Crittografia in volo/a, tornizzazione PAN/PII.
Regole di accesso ai ruoli per Ammiraglio/Operatore.
Booleani invariati (WORM) e retensioni per il controllo.
Regolazione: conservazione nella regione, report, dimostrazione di esecuzione della SLA.
12) FinOps: SLA come driver di costo
Scommettere i prezzi delle deviazioni SLO su quanto costa + 0. 01% di disponibilità?
Profilate le finestre di punta, non gonfiate la potenza costante.
Right-sizing e spot dove è possibile per le attività di sfondo.
Quote e budget per tracciati, non permettere il degrado «gratuito».
13) Test di affidabilità
Sessioni GaDay/Chaos: disattivazione AZ/PSP, ritardi nelle code, interruzioni BGP.
DR-Drily è una formazione regolare per cambiare regione con obiettivi RTO.
Load & Soak - Test a lungo termine con i veri profili di scommesse/tornei.
Replay-incidenti - libreria di feed famosi e script di riproduzione.
14) Lato processore SLA
Catalogo SLO proprietario, formula, metriche, fonti, alert.
Modifiche con RFC/ADR - Valutazione dell'impatto su error budget.
Postmortem: miglioramento dell'architettura e dei runbook, regolazione SLO.
Comunicazioni con i partner: mailing, status page, planned mainenance.
15) SLI/SLO/report
15. 1 Formule
SLI_availability = (успешные_запросы / все_запросы) 100%
SLI_latency_P99 = перцентиль_99(латентность_запроса)
SLI_webhook_D+60 = доля вебхуков, доставленных ≤ 60 сек15. 2 Esempio di SLO per Core API
Disponibilità (30 giorni): 99. 95%
P95 endpoint '/v2/payouts/create ': 350 mc
Errori 5xx (slittante 1 ora): <0. 3%
Webhook delivery ≤ 60 сек (P99): ≥ 99. 9%
RPO portafoglio: 60 secondi, RTO 5 min
15. 3 Rapporto SLA (spremuto)
Completato: 99. 97% (SLO 99. 95%) +
Violazioni: 2 episodi per regione BR a causa di timeout PSP (totale 8 min).
Misure aggiunte: smart-routing per codice di guasto, esteso warm pool connessioni PSP-B.
16) Assegno-foglio di implementazione
1. Definite percorsi personalizzati critici e SLI corrispondenti.
2. SLO per 30/90 giorni + errore budget policy.
3. Multisonalità e piano DR con obiettivi RTO/RPO, dribbli regolari.
4. Synthetics da geo-target, dashboard per-region/per-PSP.
5. Pattern di stabilità: circuito breaker, backpressure, idempotency.
6. Criteri di degrado e feature flags per i filetti disattivati.
7. FinOps: budget dei circuiti, previsioni dei picchi, warm pools.
8. Sicurezza: segmentazione, crittografia, controllo.
9. Documentazione SLA per i partner, processo di comunicazione.
10. Retrospettive e revisione SLO ogni 1-2 trimestri.
17) Anti-pattern
Promette SLA senza SLI misurabili e una tecnica di conteggio trasparente.
Considera la disponibilità «all'ingresso del servizio» ignorando il gateway/provider.
Basarsi solo sulla latitanza media ignorando le code P99.
Dottor «carta», mancanza di allenamento.
Risorse «eterne» senza limiti: un solo rapporto cancella il prato.
Mescolare prode e analisi pesanti in un unico cluster/database.
18) Totale
L'architettura cloud SLA è una combinazione di pattern tecnici (multi-AZ/region, isolamento, failover), processi (SLO, errore budget, DR-drily) ed economia (FinOps). Concedetevi il diritto di avere problemi prevedibili: testate la tolleranza, misurate le percentili, limitate il raggio esplosivo e iniziate la comunione. Le promesse della SLA non diventeranno marketing, ma ingegneria gestita.