Sei reperibile per un servizio web: un load balancer davanti a una flotta di istanze, una cache davanti a un database e un obiettivo di disponibilità del 99,9 %. Ogni minuto il modello calcola ritardo di accodamento, timeout, hit della cache e carico del database da formule da manuale — e quanto costano le tue decisioni.
Soglia minima per la flotta. Alzarla avvia subito le istanze — che hanno comunque bisogno del ritardo di avvio prima di servire.
Tracciamento del target sull'utilizzo; nessun nuovo scale-out finché le istanze sono ancora in avvio. Off = esattamente il minimo.
Più basso = più margine e più costo. L'utilizzo misurato non può superare il 100 %, quindi una flotta satura cresce solo passo dopo passo.
TTL più lungo = più hit, ma le risposte possono essere più vecchie (età media ≈ TTL/2).
Carica le chiavi calde per 6 minuti (+12 % della cache al minuto) al prezzo di 600 query al database in più al secondo.
Quota del 30 % a bassa priorità (prefetch, batch, crawler) respinta al load balancer con „riprova più tardi“.
La funzione pesante aggiunge 20 ms di CPU e una query al database per richiesta. Off = degradazione controllata (graceful degradation).
Rilascia di nuovo l'ultima build funzionante su una flotta nuova (5 min, fatturata due volte), poi sposta il traffico. Premere ancora riavvia la preparazione; se non c'è nessuna build difettosa in produzione, costa solo denaro.
| Burn rate (1 h) | 0,0 × |
|---|---|
| Richieste | 1125 req/s |
| Istanze in servizio | 10 |
| Istanze in avvio | 0 |
| Hit rate della cache | 77 % |
| Utilizzo del database | 19 % |
| Traffico scartato | 0 % |
| Costo della flotta | 4,00 $/h |
| Costo finora | 0,00 $ |
| Età media delle risposte in cache | 30 s |
| Traffico sulla build difettosa | 0 % |
| Raccomandazioni disponibili | 100 % |
Una nuova build esce alle 09:10. Il mese è già stato difficile: resta solo il 20 % dell'error budget. Pochi minuti dopo il deploy scatta la pagina di burn rate. Proteggi il budget.
Un link al servizio si sta diffondendo in fretta e in mattinata è atteso un picco di traffico, senza sapere quando né quanto grande. Oggi le nuove istanze impiegano 8 minuti ad avviarsi. Quando arriva, mantieni bassi errori e latenza senza bruciare denaro in capacità inattiva.
Al picco di mezzogiorno uno script di manutenzione svuota l'intera cache. Ogni richiesta ora va al database, dimensionato per il solito hit rate dell'85 %. Rimetti in piedi il servizio senza sovraccaricare il database.
Ogni relazione usata dal simulatore, con la sua fonte. Le costanti indicate come ipotesi sono tarature illustrative.
λ(t) = base × (1 + 0.25·sin(2π(t + clock − 6 h)/24 h)) × surge(t), clock = time of day at the start (peak at 12:00); count/min ≈ N(60λ, √(60λ)) × (1 + N(0, 0.02))[6]Ipotesi: numero di worker, tempi di servizio, capacità del database, dimensione della cache, velocità di riempimento, prezzi e tasso di errore della build difettosa sono valori illustrativi per un servizio web di medie dimensioni.N = instances × 16 workers, a = λ·S; C(a, N) = B / (1 − (a/N)(1 − B)), B = Erlang B[3][6]P(W > t) = C·e^(−(N/S − λ)·t); timeouts = P(W > 2 s); a ≥ N ⇒ failed share = 1 − N/a[3]p99 ≈ S·ln 100 + ln(C/0.01)/(N/S − λ) (service + waiting quantile, an approximation)[3][6]Approssimazione: sommare i quantili di servizio e di attesa non dà il p99 esatto della loro somma (può risultare un po' alto o basso); la coda è trattata come stazionaria entro ogni minuto perché le richieste durano millisecondi.busy workers L = λ·S ⇒ utilization = λ·S / N[4]hit = warm × rT/(1 + rT), r = λ / 20,000 objects; mean age of a cached answer ≈ T/2[5]DB load = λ·q·(1 − hit); query time = 5 ms/(1 − ρ_db) (≤ 250 ms); S = S_app + (1 − hit)·q·query time[6]Ipotesi: numero di worker, tempi di servizio, capacità del database, dimensione della cache, velocità di riempimento, prezzi e tasso di errore della build difettosa sono valori illustrativi per un servizio web di medie dimensioni.budget = 1 − SLO = 0.1 %; burn = error rate / 0.1 %; Δbudget per min = burn / 43,200; burn (1 h) = mean error rate over the last 60 min / 0.1 % (window pre-filled with the opening minute)[1][2]desired = ⌈serving × utilization / target⌉ (utilization saturates at 100 %); new instances serve after the boot delay[6]Ipotesi: numero di worker, tempi di servizio, capacità del database, dimensione della cache, velocità di riempimento, prezzi e tasso di errore della build difettosa sono valori illustrativi per un servizio web di medie dimensioni.16 workers/instance · app time 50 ms (+20 ms and +1 query with the feature on) · 2 queries/request · DB 4,000 queries/s · 20,000 hot objects · cache refill τ = 30 min (slower while the DB is saturated) · warm-up job +12 %/min for 6 min, +600 queries/s · timeout 2 s · 30 % low-priority traffic · bad build +5 % errors, ×1.25 CPU · rollback 5 min · $0.40 per instance-hour · scale-in by ≤ 20 % of the fleet after 10 quiet minutes · up to 40 instancesIpotesi: numero di worker, tempi di servizio, capacità del database, dimensione della cache, velocità di riempimento, prezzi e tasso di errore della build difettosa sono valori illustrativi per un servizio web di medie dimensioni.Casualità: un generatore mulberry32 con seed; distribuzioni usate: uniforme, esponenziale (CDF inversa), normale (Box–Muller), Poisson (Knuth). Il seed è mostrato e condivisibile.
Modello didattico, non per decisioni operative. Gli impianti reali tarano ogni costante sulle proprie apparecchiature e sui propri dati.