Web-zerbitzu baten guardian zaude: instantzia-flota baten aurrean karga-orekatzaile bat, datu-base baten aurrean cache bat, eta % 99,9ko erabilgarritasun-helburua. Minutu bakoitzean ereduak ilara-atzerapena, denbora-mugak, cache-hitak eta datu-basearen karga kalkulatzen ditu testuliburuko formuletatik — eta zure erabakiek zer kostatzen duten.
Flotaren zorua. Igotzeak instantziak berehala abiarazten ditu — hala ere abiatze-atzerapena behar dute zerbitzatu aurretik.
Erabileraren araberako helburu-jarraipena; ez da eskala-handitze berririk instantziak oraindik abiatzen ari diren bitartean. Itzalita = gutxienekoa zehazki.
Baxuagoa = tarte gehiago eta kostu gehiago. Neurtutako erabilera ezin da % 100 gainditu, beraz asetutako flota urratsez urrats bakarrik hazten da.
TTL luzeagoa = hit gehiago, baina erantzunak zaharragoak izan daitezke (batez besteko adina ≈ TTL/2).
6 minutuz gako beroak kargatzen ditu (cache-aren +% 12 minutuko) 600 datu-base kontsulta/s gehigarriren prezioan.
Lehentasun baxuko % 30aren (aurrekarga, batch, crawlerrak) zati bat, karga-orekatzailean “saiatu berriro geroago” mezuarekin baztertua.
Funtzio astunak 20 ms CPU eta datu-base kontsulta bat gehitzen dizkio eskaera bakoitzari. Itzalita = degradazio samurra.
Azken build ona berriro zabaltzen du flota berri batean (5 min, bi aldiz fakturatzen da), eta gero trafikoa aldatzen du. Berriro sakatzeak prestaketa berrabiarazten du; build txarrik martxan ez badago, dirua bakarrik kostatzen du.
| Erreketa-tasa (1 h) | 0,0 × |
|---|---|
| Eskaerak | 1125 req/s |
| Zerbitzatzen ari diren instantziak | 10 |
| Abiatzen ari diren instantziak | 0 |
| Cache-aren hit-tasa | 77 % |
| Datu-basearen erabilera | 19 % |
| Baztertutako trafikoa | 0 % |
| Flotaren kostua | 4,00 $/h |
| Orain arteko kostua | 0,00 $ |
| Cacheko erantzunen batez besteko adina | 30 s |
| Build txarreko trafikoa | 0 % |
| Gomendioak eskuragarri | 100 % |
Build berri bat 09:10ean kaleratzen da. Hilabetea dagoeneko gogorra izan da: errore-aurrekontuaren % 20 baino ez da geratzen. Zabaldu eta minutu gutxira erreketa-tasaren alerta jotzen du. Babestu aurrekontua.
Zerbitzurako esteka azkar zabaltzen ari da eta trafiko-gorakada bat espero da goiz honetan noizbait — inork ez daki noiz, ez zein handia izango den. Gaur instantzia berriek 8 minutu behar dituzte abiatzeko. Iristen denean, mantendu erroreak eta latentzia baxu, ahalmen ez-aktiboan dirua erre gabe.
Eguerdiko gailurrean mantentze-script batek cache osoa husten du. Eskaera guztiak orain datu-basera doaz, ohiko % 85eko hit-tasarako neurtuta zegoen datu-basera. Berreskuratu zerbitzua datu-basea gainkargatu gabe.
Simulagailuak erabiltzen duen erlazio bakoitza, bere iturriarekin. Hipotesi gisa markatutako konstanteak kalibrazio ilustratiboak dira.
λ(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]Hipotesia: langile-kopuruak, zerbitzu-denborak, datu-basearen ahalmena, cache-aren tamaina, betetze-abiadura, prezioak eta build txarraren errore-tasa web-zerbitzu ertain baten balio ilustratiboak dira.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]Hurbilketa: zerbitzu- eta itxaron-kuantilen batura ez da haien baturaren p99 zehatza (apur bat altuagoa edo baxuagoa izan daiteke); ilara egonkortzat hartzen da minutu bakoitzean, eskaerek milisegundoak irauten baitute.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]Hipotesia: langile-kopuruak, zerbitzu-denborak, datu-basearen ahalmena, cache-aren tamaina, betetze-abiadura, prezioak eta build txarraren errore-tasa web-zerbitzu ertain baten balio ilustratiboak dira.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]Hipotesia: langile-kopuruak, zerbitzu-denborak, datu-basearen ahalmena, cache-aren tamaina, betetze-abiadura, prezioak eta build txarraren errore-tasa web-zerbitzu ertain baten balio ilustratiboak dira.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 instancesHipotesia: langile-kopuruak, zerbitzu-denborak, datu-basearen ahalmena, cache-aren tamaina, betetze-abiadura, prezioak eta build txarraren errore-tasa web-zerbitzu ertain baten balio ilustratiboak dira.Ausazkotasuna: hazi bidezko mulberry32 sorgailua; erabilitako banaketak — uniformea, esponentziala (alderantzizko CDF), normala (Box–Muller), Poisson (Knuth). Hazia erakusten da eta partekatu daiteke.
Hezkuntza-eredua — ez eragiketa-erabakietarako. Benetako guneek konstante guztiak beren ekipamenduari eta datuei egokitzen dizkiete.