Pianificazione della potenza e aumento del carico

Breve riepilogo

1. Previsione della domanda (trend base + stagionalità + iventa).

2. Modello di carico (open-model per Internet).

3. Riserva di robustezza (headroom) e budget errato.

4. Ridimensionamento (orizzonte/verticale/auto) + vincoli (rate-limit/backpressure).

5. Finanza: $/1000 RPS, $/mc p95, TCO scenari.

Termini e metriche

Throughput: RPS/QPS/CPS - larghezza di banda effettiva.
Latency p95/p99 - SLO target per percorsi personalizzati.
Saturation: caricamento CPU/memoria/IO/FD/connessioni/code.
Errore rate: 5xx/timeout/429, bilancio non valido per il periodo.
Headroom è la quota di potenza disponibile per il picco di traffico (raccomandato per il 30%).
Burst: picco a breve termine (secondi/minuti), Spike: forte crescita x N.

Modelli e formule di base

Littl's Law (per sistemi in coda)

L = λ W

L è il numero medio di richieste nel sistema, l'intensità media di accesso (RPS) e il tempo medio del sistema. Utile per valutare la profondità delle code.

Fattore di caricamento ( )

ρ = λ / μ

Velocità di servizio (RPS a 100% CPU). Se la latitanza aumenta in modo non lineare, tenete il punto di lavoro 0. 6–0. 75.

Safety factor/scorta

Capacity_required = Peak_load (1 + Headroom) Degradation_factor

Dove Degradation _ factor considera il guasto N, la degradazione della cache, la perdita di un RR/regione (ad esempio 1. 2).

Previsione della domanda

1. Storia: profili diurni/settimanali, stagionalità, correlazione con eventi (partite/striam/pagamenti).
2. Ivent: coefficienti scenici (normale giorno x 1, torneo x 2. 3, finale x 3. 5).
3. Fonti di fluttuazioni, campagne di marketing, comunicati, anomalie dei bot.

4. Unità di previsione: RPS percorsi (login, lobby, catalog, payments), CPS TLS, QPS DB, unità IOPS, egress Gb/s

5. Fiducia: conserva due scenari: conservatore e aggressivo.

Simulazione del carico

Open-model (arrivo Poisson-simile) - È plausibile per API/Web pubbliche - Utilizzare per sizing.
Closed-model (U + think-time) - Adatto per le sequenze interne. Combinare.
Miscele di rotte: quote di peso per endpoint; includere non solo «hot», ma anche «costosi» (registrazione, deposito).
Non dimenticare: retrai, code, limiti di partner (PSP, API di terze parti).

Progettazione di una riserva di robustezza

Headroom target: ≥ 30% a picco (per Internet); per il nucleo di pagamento e le vie critiche - 40-50%.
N + 1/N + 2: resistiamo al rifiuto di 1-2 istanze/zona senza violare l'SLO.
Multi-region: ogni regione trascina il 60% del picco totale (per sopravvivere alla perdita di un vicino).
Modalità Delrade: disabilita le funzioni secondarie, riduce payload, attiva cache/risposte stab.

Sizing per livello

Rete/Edge

CPS/RPS sul fronte, TLS-handshake p95, resumption≥70%, egress Gb/s

Anycast/Geo-routing, limiti CDN/WAF (concordare in anticipo).
Riserva: link/applink, picco x 1. 3, SYN backlog con riserva, UDP/443 per H3.

Bilanciatori/Proxy

RPS per istanza, open connection, code, CPU/IRQ.
Keepalive e connection pooling - riducono le connessioni ai backend.
Riserva: ≤ 0. 7, limiter по CPS/RPS per route.

Applicazioni

Prestazioni mirate per core (RPS/core) nella piattaforma.
Pool (thread/DB/HTTP) - Non passare ai limiti.
Riserva: scale automatico a CPU 60-70% e latency-trigger (p95).

Cache

Hit-ratio, volume hotset, eviction, replica.
Riserva, memoria 1. 2 x hotset, rete headroom 30%.

Database

QPS/TPM, p95 query, blocchi, buffer, WAL/replication lag.
IOPS e latency è la chiave del p95.
Riserva: punto di lavoro CPU 50-65%, blend di replica <target; piano di charding e read-replica.

Unità/Archivi

IOPS (4k/64k), throughput, fsync cost.
Riserva: IOPS a picco x 1. 5, latency p95 nella finestra di destinazione; pool singoli per registro/dati.

GPU/ML (se disponibile online)

Samples/s, latency, VRAM headroom, batching.
Riserva: opzioni batch sotto la sega di carico, warm-pool GPU.

Ridimensionamento automatico

HPA/KEDA: metriche CPU + custome (p95 latency, RPS, coda).
Warm pools - Istanze pre-riscaldate prima degli iventi.
Step-scaling: gradini con cooldown per non «segare».
Tempo di reazione: punta a T _ scale per 1-2 minuti per il livello frontale; per l'OBD, in anticipo.

Limitatori e backpressure

Rate-limit по IP/ASN/device/route; quote per i partner.
Code con TTL, disdetta «cortese» (429/via grey-wall) prima dei timeout.
Idempotenza: chiavi di pagamento; retrai con budget + jitter.
Richiest collapsing/SWR - Non svegliare origin durante il picco.

Esempio di calcolo rapido

La previsione è di un picco di 35k RPS API, p95 da 250 ms, media servizio time di 8 ms per istanza al 60% CPU di RPS/core, 8 core per istanza di 1000 RPS/istanza.
Passo 1 (senza riserva): 35 istanze.
Passo 2 (headroom 30%): 35 x 1. 3 = 46.
Passo 3 (errore di un AZ, + 20%): 46 x 1. 2 ≈ 55.
Fase 4 (arrotondamento + riserva calda 10%): 61 istanze.
Controllo: ≈ 35k/( 61k) ≈ 0. 57 nella zona verde.

Modello finanziario (FinOps)

$/1000 RPS per livello (edge, proxy, app, DB).
$/ms p95 (costo di riduzione della coda).
Script TCO: on-demand vs reserved vs spot (a rischio di interruzioni).
I limiti trimestrali di account/cluster, le quote cloud, i limiti PSP/CDN.

Pronto per guasti e DR

Multi-AZ/region: ogni spalla ha un carico di lavoro del 60%.

Piano failover: withdraw Anycast, GSLB cambio, TTL 60-120 secondi

Dipendenze critiche: limiti PSP/banche, fornitore secondario.
Esercitazioni periodiche: game day disattivato PoP/BG/cache.

Osservabilità e segnali di saturazione precoce

Altezza p95/p99 e code a ingresso stabile.
Caduta della cache hit-ratio, crescita origin egress.
Aumento di retransmits/ECN CE, calo della respumption TLS.
Altezza 429/timeout e retry-rate.
Per il database: aumento dei conflitti, checkpoint time, WAL fsync.

Procedure operative

Capacity review mensilmente: fatto vs piano.
Cambio windows sotto le ive: freeze kernel e limiti.
Prewarm (CDN/DNS/TLS/pool) 10-30 minuti prima del picco.
Versioning dei limiti: fissa i configi rate-limit/pool in Git.

Specifico per iGaming/Fintech

Tornei/partite: profili spike + plateau, percorsi grigi per bot, singoli limiti di registrazione/depositi.
Pagamenti/PSP: quote di provider/metodo, percorsi fallback, pool egress-IP, SLA Time-to-Wallet.
Fornitori di contenuti: distribuzione negli studi, cache hot, shard pool.
Antifrode/AML: limite per regole/scorrimento, degrado a regole light a picco.

Assegno foglio di implementazione

• Previsioni di picchi (base/stagione/ivent), due scenari.
• Il budget SLO/errato e l'headroom target sono 30%.
• Sizing per livello (edge/proxy/app/cache/DB/IO/rete).
• Limitatori: rate-limit, code, idempotency, retry-budget.
• HPA/KEDA + warm pools; il piano di espansione davanti all'iventa.
• Multi-AZ/region, playbook failover, TTL e GSLB.
• Le quote cloud/PSP/CDN sono coerenti e documentate.
• Osservabilità: dashboard capacity, segnali iniziali di saturazione.
• Esercitazioni DR e capacity-review regolari.

Errori tipici

Piano RPS medio senza code o picchi.
ρ≈0. 9 «su carta», la latitanza esplode al minimo rumore.
Ignora i limiti dei servizi esterni (PSP/CDN/Database cluster).
Nessuna modalità degrade e backpressure - feed a cascata.
Scala automatica senza pre-riscaldamento - arriva «dopo» il picco.
Un unico headroom per tutti i livelli - lo stretto migra.

Mini playbook

Prima dell'evento di punta (T-30 min)

1. Ingrandire l'HPA, attivare il warm pool.
2. Scaldare CDN/DNS/TLS/connettori, scaldare la cache.
3. Alzare i limiti dei pool e le quote PSP in accordo.
4. Attivare percorsi/filtri bot grigi, restringere gli endpoint pesanti.

Perdita parziale della regione

1. GSLB è una regione vicina, TTL 60-120.
2. Attiva modalità delrade (cache/rilascio semplificato).
3. Ridistribuire i limiti PSP/egress-IP.
4. Comunicazione dello stato, controllo p95/errori.

Scoppio di retroscena

1. Riduce retry-budget, abilita backoff + jitter.
2. Abilita richiest-collapsing/SWR su GET.
3. Stretta temporaneamente rate-limit per ASN «rumoroso».

Totale

La pianificazione della potenza è una previsione della domanda + modello ingegneristico + robustezza e leva operativa. Formalizzare SLO e headroom, tenere conto dei limiti esterni, automatizzare la scalabilità e il degrado, misurare il costo di millisecondi e eseguire una capacity-review regolare. In questo modo l'aumento del carico di lavoro non si trasformerà in un rischio, ma in una metrica di business controllata.