Anda siaga (on call) untuk layanan web: load balancer di depan armada instance, cache di depan database, dan target ketersediaan 99,9 %. Setiap menit model menghitung delay antrean, timeout, cache hit, dan beban database dari rumus buku teks — dan berapa biaya keputusan Anda.
Batas bawah untuk armada. Menaikkannya langsung meluncurkan instance — tetapi masih butuh jeda boot sebelum melayani.
Pelacakan target pada utilisasi; tidak ada scale-out baru selama instance masih booting. Mati = tepat minimum.
Lebih rendah = lebih banyak ruang dan biaya lebih tinggi. Utilisasi terukur tidak bisa melebihi 100 %, sehingga armada jenuh tumbuh hanya langkah demi langkah.
TTL lebih panjang = lebih banyak hit, tetapi jawaban bisa lebih tua (usia rata-rata ≈ TTL/2).
Memuat kunci panas selama 6 menit (+12 % dari cache per menit) dengan biaya 600 kueri database tambahan/dtk.
Bagian dari 30 % prioritas rendah (prefetch, batch, crawler) yang ditolak di load balancer dengan „coba lagi nanti“.
Fitur berat menambah 20 ms CPU dan satu kueri database per permintaan. Mati = degradasi mulus (graceful degradation).
Men-deploy ulang build baik terakhir pada fleet baru (5 mnt, ditagih dua kali), lalu mengalihkan trafik. Menekan lagi akan mengulang persiapan; jika tidak ada build buruk yang aktif, ini hanya menghabiskan uang.
| Burn rate (1 jam) | 0,0 × |
|---|---|
| Permintaan | 1125 req/s |
| Instance melayani | 10 |
| Instance sedang booting | 0 |
| Cache hit rate | 77 % |
| Utilisasi database | 19 % |
| Lalu lintas dibuang | 0 % |
| Biaya armada | 4,00 $/h |
| Biaya sejauh ini | 0,00 $ |
| Usia rata-rata jawaban ter-cache | 30 s |
| Lalu lintas pada build buruk | 0 % |
| Rekomendasi tersedia | 100 % |
Build baru dirilis pukul 09:10. Bulan ini sudah berat: hanya 20 % error budget tersisa. Beberapa menit setelah deploy, halaman peringatan burn-rate berbunyi. Lindungi budget.
Tautan ke layanan menyebar cepat dan lonjakan lalu lintas diperkirakan terjadi sekitar pagi ini — tak seorang pun tahu kapan, atau seberapa besar. Instans baru butuh 8 menit untuk menyala hari ini. Saat lonjakan datang, jaga galat dan latensi tetap rendah tanpa membakar uang untuk kapasitas yang menganggur.
Pada puncak tengah hari skrip pemeliharaan mengosongkan seluruh cache. Setiap permintaan kini menuju database, yang dirancang untuk hit rate 85 % biasa. Pulihkan layanan tanpa membebani database berlebih.
Setiap hubungan yang dipakai simulator, beserta sumbernya. Konstanta yang ditandai sebagai asumsi adalah kalibrasi ilustratif.
λ(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]Asumsi: jumlah worker, waktu layanan, kapasitas database, ukuran cache, kecepatan pengisian, harga, dan laju galat build buruk adalah nilai ilustratif untuk layanan web ukuran menengah.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]Pendekatan: menjumlahkan kuantil layanan dan antrean bukan p99 persis dari jumlah keduanya (bisa sedikit tinggi atau rendah); antrean dianggap stabil dalam setiap menit karena permintaan berlangsung dalam milidetik.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]Asumsi: jumlah worker, waktu layanan, kapasitas database, ukuran cache, kecepatan pengisian, harga, dan laju galat build buruk adalah nilai ilustratif untuk layanan web ukuran menengah.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]Asumsi: jumlah worker, waktu layanan, kapasitas database, ukuran cache, kecepatan pengisian, harga, dan laju galat build buruk adalah nilai ilustratif untuk layanan web ukuran menengah.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 instancesAsumsi: jumlah worker, waktu layanan, kapasitas database, ukuran cache, kecepatan pengisian, harga, dan laju galat build buruk adalah nilai ilustratif untuk layanan web ukuran menengah.Keacakan: generator mulberry32 ber-seed; distribusi yang dipakai — seragam, eksponensial (CDF invers), normal (Box–Muller), Poisson (Knuth). Seed ditampilkan dan dapat dibagikan.
Model edukasi — bukan untuk keputusan operasional. Situs nyata mengkalibrasi setiap konstanta sesuai peralatan dan data mereka sendiri.