Operazioni e Gestione → Scalabilità dell'infrastruttura operativa

Scalabilità dell'infrastruttura operativa

1) Perché e cosa considerare «ridimensionamento»

La scalabilità è la capacità della piattaforma di aumentare la larghezza di banda (RPS/TPS, connettori, IOPS, throughput) e la quantità di dati senza perdita di SLO e a costi controllati. Per iGaming/Fintech si tratta direttamente di denaro: conversione di depositi/scommesse, giochi live e calcoli.

• Mantenere lo SLO a X-volte il carico di lavoro e picchi stagionali.
• Fornire tempi di scalabilità prevedibili (min, not hours).
• Salva l'economia: cost/RPS, cost/transazione, cost/1k eventi.

2) Principi della piattaforma scalabile

1. Orizzontale-prima: suddivisione in piccoli servizi stateless; stato - nei cluster dati.
2. Back-pressure e code: antialiasing dei picchi, protezione contro le tempeste.
3. Cache su tutti i livelli: client/edge/servizio/database.
4. Idampotenza e ripetitività: retrai sicuri, outbox, deadup.
5. Le dipendenze con vincoli sono timeout, breaker, isolamento bulkhead, rate-limits.
6. Osservazione dei segnali di capacità: headroom, p95/p99, lag, connettori, quote.
7. Ridimensionamento automatico con gard rail: HPA/VPA/Cluster Autoscaler + condizioni di arresto.
8. Multi-region by design - Aree blast indipendenti, dati locali, feelover sostenibili.

3) Capacity planning - Come calcolare quanto necessario

Gli ingressi del modello includono TPS target, profilo di traffico orario, percorsi critici, coefficienti di cache, media payload, SLO e limiti dei provider.

• RPS → CPU/pol: 'sotto = RPS p99 _ time/efficiente _ CPU _ in _ pol' (con riserva 30-50%).
• Code: 'velocità _ minima _ consumatori' velocità _ picco _ velocità _ produttori 1. 2`.
• Connettori DB: 'max _ conns = pool _ servizi attivi _ media _ pool _ size 1. 3`.
• Cache: dimensioni = «hot working-set per N minuti» + 20-30% di riserva.
• Egress/CDN: picco egress = picco di richiesta media della risposta (vista la compressione).

Headroom: obiettivo 20-40% a picco (livelli). Sotto il 15% il trigger «capacity uplift».

4) Livelli e pattern di zoom

4. 1 Edge / CDN / WAF

Cache a bordo (TTL + SWR), bilanciamento geo, compressione, HTTP/2/3.
Rate-limits sul perimetro IP/JWT/chiave, protezione contro i picchi.
Fan out eventi (jackpot, avvisi live) tramite broker/canali pub/sub.

4. 2 gateway API/Backend-for-Frontend

Ridimensionamento orizzontale in base allo statole-pool, dedicated pool per downstream.
HPA per metriche aziendali: RPS, p99, coda nel pool work - non solo CPU.

4. 3 Code asincrone/streaming (Kafka/Rabbit/Pulsar)

Zoom su partiture e consumatori evitare la skew (chiavi e distribuzione).
Lag-alert + ridimensionamento automatico dei consumatori; DLQ e retry topic.
Retention sotto SLA riconsilazione e replica.

4. 4 Cache (Redis/Memcached)

Modalità cluster, repliche, criteri eviction (LFU), multigiet, pipeline.
Separazione hot-key'e'e attività di fondo, limiti client e policy max-memory.

4. 5 Database

Repliche read e routing di lettura, connection pooling.
Sharding per regione/tenante/intervallo di chiavi.
CQRS: scrittura per la procedura guidata/leader, letture per le repliche.
Indicizzazione e batch workflow (outbox stream).
Archiviazione e dati hot/freddi (tiering).

4. 6 Archivi file/oggetti

Multitasking, caricamento multipart, fronte CDN, trasformazioni asincroni.
Quote del provider, pulizia delle code e budget egress.

4. 7 Provider (PSP/KYC/studio)

Multi-venditore e routing a quote/sLO/costo.
Circuito breaker + rate-limit per ogni provider, coda di retrai, modalità grace.

5) Ridimensionamento automatico e gard rail

• HPA: метрики `rps_per_pod`, `queue_depth`, `p99_latency`; `targetAverageValue`.
• VPA: suggerimenti sulle risorse aggiornare al di fuori del picco.
• Cluster Autocaler - I profili dei gruppi nod (spot + on-demand) con priorità.
• PodDisruptionBudget/ TopologySpreadConstraints: uniformità per zona.
• Protezione contro i deploy ubriachi.

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

• Pausa & Rollback se il canarino p99> 1. 3 x baseline 10 minuti.
• «Freeze scale-down» in prima serata, solo scale-up.
• «Stop retries» a «open _ route = 1» ai colli di bottiglia.

6) Multi-region: attivo/attivo e attivo/passivo

Le regioni blast-isolate sono cluster indipendenti, segreti locali/quote.
Routing globale: latency-/geo-based, health-probes, override manuale.

• Hot - Replica locale + eventual (striam).
• Transazioni critiche - Coerenti con il dominio (ledger/bilanci).
• Playbook Failover: cambio passo per passo della sorgente, TTL, riscaldamento della cache.
• Regolamento di esercizio (DR) - Allenamento trimestrale con obiettivi RTO/RPO.

7) Pattern di rete e assistenza

Servizio Mesh: mTLS, retry/breaker, outlier detection, per-downstream limiti.
eBPF/Observability a L4/L7, limiti di connessione, protezione da head-of-line.
Gateway API interni per S2S, rate-limit generico e controllo.
VPC/subnet per blast-zone, controllo NAT/Egress, peering con venditori.

8) Prestazioni: test e prove

Load & stress nel profilo prime time + worst-case.
Soak (lunga) - perdite di memoria/descrittori, crescita latency.
Chaos/game-days: riduzione del broker/provider/zona, «provider lento».
Perf-regressione in CI è un insieme di script di riferimento e gate automatici.

9) Dati e storage: strategie di crescita

La crescita verticale al soffitto è orizzontale/charding.
Letture di replica/cache registrazioni di batch/asincrone/registro.
Migrazioni di diagrammi: expand → migrate → contract, senza blocchi globali.
Archiviazione: parti fredde in un magazzino a basso costo + on-demand re-idrazione.
Ricerca: indici separati (OpenSearch/Solr) con pipline di aggiornamenti incrementali.

10) Gestione dei provider e delle quote

Mappa delle quote (TPS, finestre, valore); alert 'usage _ ratio> 0. 9`.
Routing per costo/qualità (smart routing).
Accordi OLA-SLO e processo di aumento delle quote.
Un pool di alternative e un cambio caldo.

11) Osservabilità e segnali di scalabilità

• Capacity headroom по слоям; `queue_lag/backlog growth`; `kafka ISR`; `db connections`/`repl lag`; `redis evictions`; `open_circuit`/`retry_rate`; `quota_usage`.
• Metriche aziendali: success rate/conversione deposito, ora di avvio del gioco.
• Costo: cost/RPS, cost/1k calls.

• Capacity Overview (headroom, rischi top, burn-rate SLO).
• Stream & Queue Panel (lag/backlog, consumer saturation).
• DB & Cache (p99, connettori, hit/evictions).
• Provider & Quote (TPS, timeouts, costo, cambio).
• Change Safety (prima/dopo il lancio, canarino, auto-gate).

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: scalabile a vantaggio

I fattori di efficienza sono cost/RPS, cost/deposito, cost/1k eventi.
Right-sizing: VPA/linee guida, report «over-validioned».
Spot/Preemptile per non critico; Riserved/Committed per il carico di base.
Budget e cache Egress, CDN/edge-offload.
Raccogliere e archiviare i fogli in base al valore (hot vs cold).
Quote di avviso (soft-cap) e ticket automatico per l'estensione.

13) Processi e persone

Cambio Management: canarini, ficcoflagi, stop alle regressioni.
Runbook e «dove aggiungere capacità», «come cambiare regione».
Pianificazione dei picchi: calendario delle partite/tornei/campagne e finestre dei provider.
Giochi-days regolari e esercitazioni DR.
Matrice di proprietà: chi può premere un pulsante su un faulover o aumentare le quote.

14) Assegni di implementazione

• Mappa dei percorsi critici e dei limiti (per strati), obiettivo headroom 30%.
• HPA per metriche aziendali + Cluster Autocaler PDB/SpreadConstraints.
• Code nelle vie calde, idempotency-keys, outbox.
• Cash: obiettivi hit 90%, criteri evictions, indici chiave.
• DB: repliche read, pool di connettori, piano di sharding.
• Provider: multi-vendor, quote, breaker/retrai.
• I dashboard «Capacity/Stream/DB/Providers», gli alert di articolo 11.
• Canarini e autogate «prima/dopo il lancio».
• DR-playbook e un feelover parziale.

• Scaldare la cache, prima dello scale HPA/ASG, le repliche warm-standby.
• Aumento delle quote di provider, attivazione smart-routing.
• Abilita le soppressioni night-mode per gli alert non ritrici.
• Phicheflag «safe mode» è pronto per essere attivato immediatamente.

15) Anti-pattern

L'upgrade verticale «fino alla punta» è invece orizzontale.
Un pool comune di thread/connessioni su tutti i downstream (head-of-line).
I retrai sono sui timeout dei colli di bottiglia, l'assenza di jitter è una tempesta.
Non c'è isteresi negli alerti e negli scale policy.
Un unico database globale senza charding e localizzazione dei dati.
Fede cieca in venditore SDK senza controllo timeout/retrai/osservabilità.
L'assenza di esercitazioni DR è il feelover «solo su carta».

16) KPI scalabilità

Conformità SLO al picco (p95/p99, success rate).
Headroom per strati in prima serata.
MTTS (Mean Time To Scale) - Consente di visualizzare altre risorse.
Backlog/Lag Resolution Time è il momento in cui le code cadono dopo il picco.
Change Failure Rate per un periodo di crescita attiva.
Cost/RPS e risparmi dalla cache/CDN/edge-off.
DR Readehi: RTO/RPO negli esercizi.

17) Esempi di modelli «veloci»

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

Cosa ridimensionare per primo?
A: Colli di bottiglia secondo i dati dei dashboard: code/cache/letture di database. Le vie calde (deposito/puntata/avvio del gioco) sono la priorità.

Q: Come si capisce che il ridimensionamento automatico «peggiora»?
A: Vedi la correlazione: scale- up↑, e non migliorano i p99/errori - forse «ridimensiona il problema» (downstream/quota ristretta). Accendere breaker/degrado.

C'è sempre bisogno di un secondo provider?
Per le vie critiche, sì. Altrimenti almeno «safe mode» con script semplificato e cache.

Q: Active-active или active-passive?
A: Se i requisiti RTO sono bassi e molti attori regionali - active. In caso contrario, iniziate con l'active-passive con il feelover utilizzato.