คุณเป็นผู้เฝ้าระบบ (on call) ของเว็บเซอร์วิส: ตัวกระจายโหลดหน้ากลุ่มอินสแตนซ์ แคชหน้าฐานข้อมูล และเป้าหมายความพร้อมใช้งาน 99.9 % ทุกนาทีแบบจำลองคำนวณความหน่วงจากคิว การหมดเวลา แคชฮิต และโหลดฐานข้อมูลจากสูตรในตำรา — และต้นทุนของการตัดสินใจของคุณ
ค่าพื้นของกลุ่ม การเพิ่มจะเปิดอินสแตนซ์ทันที — แต่ยังต้องรอเวลาบูตก่อนให้บริการ
ติดตามเป้าหมายตามการใช้งาน ไม่ขยายเพิ่มขณะที่อินสแตนซ์ยังบูตอยู่ ปิด = เท่ากับขั้นต่ำพอดี
ต่ำ = มีพื้นที่เหลือมากขึ้นและต้นทุนมากขึ้น การใช้งานที่วัดได้เกิน 100 % ไม่ได้ กลุ่มที่อิ่มตัวจึงโตทีละขั้น
TTL ยาวกว่า = ฮิตมากกว่า แต่คำตอบอาจเก่ากว่า (อายุเฉลี่ย ≈ TTL/2)
โหลดคีย์ที่ใช้บ่อยเป็นเวลา 6 นาที (+12 % ของแคชต่อนาที) โดยแลกกับคำสั่งฐานข้อมูลเพิ่ม 600 ครั้ง/วินาที
สัดส่วนของ 30 % ลำดับต่ำ (prefetch, batch, crawler) ที่ถูกปฏิเสธที่ตัวกระจายโหลดด้วย “ลองใหม่ภายหลัง”
ฟีเจอร์หนักเพิ่ม CPU 20 ms และคำสั่งฐานข้อมูลหนึ่งครั้งต่อคำขอ ปิด = ลดระดับบริการอย่างนุ่มนวล
ปรับใช้บิลด์ที่ดีล่าสุดอีกครั้งบนกลุ่มเซิร์ฟเวอร์ใหม่ (5 นาที คิดค่าใช้จ่ายสองเท่า) แล้วจึงสลับทราฟฟิก การกดซ้ำจะเริ่มการเตรียมใหม่ หากไม่มีบิลด์ที่เสียใช้งานอยู่ก็มีแต่เสียเงิน
| อัตราการเผา (1 ชม.) | 0.0 × |
|---|---|
| คำขอ | 1125 req/s |
| อินสแตนซ์ที่ให้บริการ | 10 |
| อินสแตนซ์ที่กำลังบูต | 0 |
| อัตราแคชฮิต | 77 % |
| การใช้งานฐานข้อมูล | 19 % |
| ทราฟฟิกที่ตัด | 0 % |
| ต้นทุนกลุ่มเซิร์ฟเวอร์ | 4.00 $/h |
| ต้นทุนสะสม | 0.00 $ |
| อายุเฉลี่ยของคำตอบในแคช | 30 s |
| ทราฟฟิกบนบิลด์เสีย | 0 % |
| ระบบแนะนำพร้อมใช้งาน | 100 % |
บิลด์ใหม่ออกเวลา 09:10 เดือนนี้ลำบากอยู่แล้ว: เหลืองบข้อผิดพลาดเพียง 20 % ไม่กี่นาทีหลังดีพลอย การแจ้งเตือนอัตราการเผาดัง ปกป้องงบ
ลิงก์ไปยังบริการกำลังแพร่ออกไปอย่างรวดเร็ว และคาดว่าทราฟฟิกจะพุ่งในช่วงเช้านี้สักเวลา — ไม่มีใครรู้ว่าเมื่อไรหรือใหญ่แค่ไหน อินสแตนซ์ใหม่วันนี้ใช้เวลาบูต 8 นาที เมื่อมันมาถึง ให้รักษาข้อผิดพลาดและความหน่วงให้ต่ำโดยไม่เผาเงินไปกับกำลังที่ว่างเปล่า
ที่จุดสูงสุดตอนเที่ยง สคริปต์บำรุงรักษาล้างแคชทั้งหมด ทุกคำขอจึงไปที่ฐานข้อมูล ซึ่งออกแบบขนาดไว้สำหรับอัตราฮิตปกติ 85 % นำบริการกลับมาโดยไม่ให้ฐานข้อมูลโอเวอร์โหลด
ทุกความสัมพันธ์ที่เครื่องจำลองใช้ พร้อมแหล่งที่มา ค่าคงที่ที่ระบุว่าเป็นสมมติฐานคือการปรับเทียบตัวอย่าง
λ(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]สมมติฐาน: จำนวนเวิร์กเกอร์ เวลาให้บริการ ความจุฐานข้อมูล ขนาดแคช ความเร็วเติม ราคา และอัตราข้อผิดพลาดของบิลด์เสียเป็นค่าตัวอย่างสำหรับเว็บเซอร์วิสขนาดกลาง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]การประมาณ: การบวกควอนไทล์ของเวลาให้บริการและเวลารอไม่ใช่ p99 ที่แน่นอนของผลรวม (อาจสูงหรือต่ำไปเล็กน้อย) คิวถูกถือว่าคงที่ในแต่ละนาที เพราะคำขอใช้เวลาระดับมิลลิวินาที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]สมมติฐาน: จำนวนเวิร์กเกอร์ เวลาให้บริการ ความจุฐานข้อมูล ขนาดแคช ความเร็วเติม ราคา และอัตราข้อผิดพลาดของบิลด์เสียเป็นค่าตัวอย่างสำหรับเว็บเซอร์วิสขนาดกลาง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]สมมติฐาน: จำนวนเวิร์กเกอร์ เวลาให้บริการ ความจุฐานข้อมูล ขนาดแคช ความเร็วเติม ราคา และอัตราข้อผิดพลาดของบิลด์เสียเป็นค่าตัวอย่างสำหรับเว็บเซอร์วิสขนาดกลาง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 instancesสมมติฐาน: จำนวนเวิร์กเกอร์ เวลาให้บริการ ความจุฐานข้อมูล ขนาดแคช ความเร็วเติม ราคา และอัตราข้อผิดพลาดของบิลด์เสียเป็นค่าตัวอย่างสำหรับเว็บเซอร์วิสขนาดกลางความสุ่ม: ตัวสร้าง mulberry32 แบบมีซีด การแจกแจงที่ใช้ — สม่ำเสมอ เอ็กซ์โพเนนเชียล (CDF ผกผัน) ปกติ (Box–Muller) ปัวซง (Knuth) ซีดแสดงให้เห็นและแชร์ได้
โมเดลเพื่อการศึกษา — ไม่ใช่สำหรับการตัดสินใจเชิงปฏิบัติการ ไซต์จริงปรับเทียบค่าคงที่ทุกตัวให้ตรงกับอุปกรณ์และข้อมูลของตนเอง