Sunteți de gardă pentru un serviciu web: un load balancer în fața unei flote de instanțe, un cache în fața unei baze de date și un obiectiv de disponibilitate de 99,9 %. În fiecare minut modelul calculează întârzierea de așteptare, timeout-urile, accesările cache-ului și încărcarea bazei de date din formule de manual — și ce costă deciziile voastre.
Pragul inferior al flotei. Creșterea lui lansează instanțe imediat — dar ele au totuși nevoie de întârzierea de pornire înainte să servească.
Urmărire de țintă a utilizării; nicio nouă scalare în sus cât timp instanțele încă pornesc. Oprit = exact minimul.
Mai mic = mai multă marjă și mai mult cost. Utilizarea măsurată nu poate depăși 100 %, deci o flotă saturată crește doar pas cu pas.
TTL mai lung = mai multe accesări reușite, dar răspunsurile pot fi mai vechi (vârsta medie ≈ TTL/2).
Încarcă cheile fierbinți timp de 6 minute (+12 % din cache pe minut) cu prețul a 600 de interogări suplimentare pe secundă la baza de date.
Procentul din cele 30 % cu prioritate mică (prefetch, batch, crawlere) respins la load balancer cu „reîncercați mai târziu”.
Funcția grea adaugă 20 ms de CPU și o interogare de bază de date la fiecare cerere. Oprit = degradare controlată.
Redeployează ultima versiune bună pe o flotă nouă (5 min, facturată de două ori), apoi comută traficul. Dacă apeși din nou, pregătirea reîncepe; dacă nu rulează nicio versiune proastă, doar costă bani.
| Rata de consum (1 h) | 0,0 × |
|---|---|
| Cereri | 1125 req/s |
| Instanțe în serviciu | 10 |
| Instanțe în pornire | 0 |
| Rata de accesări cache | 77 % |
| Utilizarea bazei de date | 19 % |
| Trafic redus | 0 % |
| Costul flotei | 4,00 $/h |
| Cost până acum | 0,00 $ |
| Vârsta medie a răspunsurilor din cache | 30 s |
| Trafic pe versiunea proastă | 0 % |
| Recomandări disponibile | 100 % |
O versiune nouă este lansată la 09:10. Luna a fost deja grea: a mai rămas doar 20 % din bugetul de erori. La câteva minute după lansare se declanșează alerta de rată de consum. Protejați bugetul.
Un link către serviciu se răspândește rapid și se așteaptă un val de trafic cândva în această dimineață — nimeni nu știe când, nici cât de mare. Instanțele noi au nevoie astăzi de 8 minute să pornească. Când vine, mențineți erorile și latența scăzute, fără să ardeți bani pe capacitate inactivă.
La vârful de la amiază, un script de întreținere golește tot cache-ul. Fiecare cerere merge acum la baza de date, dimensionată pentru rata obișnuită de 85 % accesări. Readuceți serviciul fără a supraîncărca baza de date.
Fiecare relație folosită de simulator, cu sursa ei. Constantele marcate ca ipoteze sunt calibrări ilustrative.
λ(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]Ipoteză: numărul de workeri, timpii de servire, capacitatea bazei de date, mărimea cache-ului, viteza de reumplere, prețurile și rata de erori a versiunii proaste sunt valori ilustrative pentru un serviciu web de mărime medie.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]Aproximare: adunarea cuantilelor de serviciu și de așteptare nu dă p99 exact al sumei lor (poate fi puțin mai mare sau mai mică); coada este tratată ca staționară în fiecare minut, deoarece cererile durează milisecunde.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]Ipoteză: numărul de workeri, timpii de servire, capacitatea bazei de date, mărimea cache-ului, viteza de reumplere, prețurile și rata de erori a versiunii proaste sunt valori ilustrative pentru un serviciu web de mărime medie.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]Ipoteză: numărul de workeri, timpii de servire, capacitatea bazei de date, mărimea cache-ului, viteza de reumplere, prețurile și rata de erori a versiunii proaste sunt valori ilustrative pentru un serviciu web de mărime medie.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 instancesIpoteză: numărul de workeri, timpii de servire, capacitatea bazei de date, mărimea cache-ului, viteza de reumplere, prețurile și rata de erori a versiunii proaste sunt valori ilustrative pentru un serviciu web de mărime medie.Aleatoriu: un generator mulberry32 cu seed; distribuțiile folosite — uniformă, exponențială (CDF inversă), normală (Box–Muller), Poisson (Knuth). Seed-ul este afișat și poate fi partajat.
Model educațional — nu pentru decizii operaționale. Site-urile reale calibrează fiecare constantă la propriile echipamente și date.