Bạn trực on-call cho một dịch vụ web: một bộ cân bằng tải trước một cụm máy, một bộ nhớ đệm trước một cơ sở dữ liệu, và mục tiêu sẵn sàng 99,9 %. Mỗi phút mô hình tính độ trễ hàng đợi, timeout, lần trúng bộ nhớ đệm và tải cơ sở dữ liệu từ các công thức giáo khoa — và các quyết định của bạn tốn bao nhiêu.
Mức sàn của cụm máy. Tăng lên sẽ khởi chạy máy ngay — chúng vẫn cần thời gian khởi động trước khi phục vụ.
Bám theo mức sử dụng mục tiêu; không mở rộng thêm khi các máy còn đang khởi động. Tắt = đúng mức tối thiểu.
Thấp hơn = nhiều dư địa hơn và tốn kém hơn. Mức sử dụng đo được không vượt quá 100 %, nên cụm máy bão hòa chỉ lớn lên từng bước.
TTL dài hơn = nhiều lần trúng hơn, nhưng câu trả lời có thể cũ hơn (tuổi trung bình ≈ TTL/2).
Nạp các khóa nóng trong 6 phút (+12 % bộ nhớ đệm mỗi phút) với giá 600 truy vấn cơ sở dữ liệu/s thêm.
Tỷ lệ trong 30 % ưu tiên thấp (tải trước, tác vụ lô, trình thu thập) bị bộ cân bằng tải từ chối với "thử lại sau".
Tính năng nặng thêm 20 ms CPU và một truy vấn cơ sở dữ liệu cho mỗi yêu cầu. Tắt = suy giảm có kiểm soát.
Triển khai lại bản build tốt gần nhất trên một cụm máy mới (5 phút, tính phí hai lần), rồi chuyển lưu lượng. Bấm lại sẽ khởi động lại khâu chuẩn bị; nếu không có bản build lỗi đang chạy thì chỉ tốn tiền.
| Tốc độ đốt (1 h) | 0,0 × |
|---|---|
| Yêu cầu | 1125 req/s |
| Máy đang phục vụ | 10 |
| Máy đang khởi động | 0 |
| Tỷ lệ trúng bộ nhớ đệm | 77 % |
| Mức sử dụng cơ sở dữ liệu | 19 % |
| Lưu lượng bị loại bớt | 0 % |
| Chi phí cụm máy | 4,00 $/h |
| Chi phí đến nay | 0,00 $ |
| Tuổi trung bình của câu trả lời trong bộ nhớ đệm | 30 s |
| Lưu lượng trên bản dựng xấu | 0 % |
| Gợi ý có sẵn | 100 % |
Một bản dựng mới được phát hành lúc 09:10. Tháng này đã khó khăn sẵn: chỉ còn 20 % ngân sách lỗi. Vài phút sau khi triển khai, cảnh báo tốc độ đốt kêu. Hãy bảo vệ ngân sách.
Một liên kết đến dịch vụ đang lan nhanh và dự kiến có một đợt tăng vọt lưu lượng vào lúc nào đó sáng nay — không ai biết khi nào hay lớn đến đâu. Hiện nay các instance mới cần 8 phút để khởi động. Khi nó đến, hãy giữ lỗi và độ trễ ở mức thấp mà không đốt tiền vào công suất nhàn rỗi.
Vào đỉnh buổi trưa, một script bảo trì xóa toàn bộ bộ nhớ đệm. Mọi yêu cầu giờ đổ vào cơ sở dữ liệu, vốn được định cỡ cho tỷ lệ trúng 85 % thông thường. Đưa dịch vụ trở lại mà không làm quá tải cơ sở dữ liệu.
Mọi quan hệ mà trình mô phỏng sử dụng, kèm nguồn. Các hằng số đánh dấu là giả định là các hiệu chỉnh minh họa.
λ(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]Giả định: số worker, thời gian phục vụ, dung lượng cơ sở dữ liệu, kích thước bộ nhớ đệm, tốc độ nạp lại, giá và tỷ lệ lỗi của bản dựng xấu là giá trị minh họa cho một dịch vụ web cỡ vừa.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]Xấp xỉ: cộng các phân vị của thời gian phục vụ và thời gian chờ không phải là p99 chính xác của tổng chúng (có thể hơi cao hoặc thấp); hàng đợi được coi là ổn định trong mỗi phút vì các yêu cầu chỉ mất vài mili giây.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]Giả định: số worker, thời gian phục vụ, dung lượng cơ sở dữ liệu, kích thước bộ nhớ đệm, tốc độ nạp lại, giá và tỷ lệ lỗi của bản dựng xấu là giá trị minh họa cho một dịch vụ web cỡ vừa.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]Giả định: số worker, thời gian phục vụ, dung lượng cơ sở dữ liệu, kích thước bộ nhớ đệm, tốc độ nạp lại, giá và tỷ lệ lỗi của bản dựng xấu là giá trị minh họa cho một dịch vụ web cỡ vừa.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 instancesGiả định: số worker, thời gian phục vụ, dung lượng cơ sở dữ liệu, kích thước bộ nhớ đệm, tốc độ nạp lại, giá và tỷ lệ lỗi của bản dựng xấu là giá trị minh họa cho một dịch vụ web cỡ vừa.Tính ngẫu nhiên: bộ sinh mulberry32 có seed; các phân phối được dùng — đều, mũ (CDF nghịch đảo), chuẩn (Box–Muller), Poisson (Knuth). Seed được hiển thị và có thể chia sẻ.
Mô hình giáo dục — không dùng để ra quyết định vận hành. Các cơ sở thực tế hiệu chỉnh mọi hằng số theo thiết bị và dữ liệu riêng của họ.