IT संचालन — साइट विश्वसनीयता लाइव मॉडल

आप एक वेब सेवा के ऑन-कॉल हैं: इंस्टेंसों के बेड़े के आगे लोड बैलेंसर, डेटाबेस के आगे कैश, और 99.9 % उपलब्धता का लक्ष्य। हर मिनट मॉडल पाठ्यपुस्तक के सूत्रों से कतार-विलंब, टाइमआउट, कैश हिट और डेटाबेस लोड निकालता है — और यह भी कि आपके फ़ैसलों की क्या कीमत है।

आप क्या सीखेंगे

सिमुलेटर

समय 0 min
अनुरोध 1125 · त्रुटि दर 0.00% · p99 विलंब 342 ms · परोसते इंस्टेंस 10 (+0) · कैश हिट दर 77% · डेटाबेस उपयोग 19% · बची त्रुटि बजट (30 दिन) 50.0%⇉1125 अनुरोध/s▶▶▶▶▶▶▶▶▶▶······························▶ 10 · ⚙ 0 · 52% · p99 342 msबेड़े का उपयोग 52%कैश हिट दर 77%डेटाबेस उपयोग 19%⚠ 0.00% · 🔥 0.0×50%$ 4.00/h · Σ $0.00
  • परोसता इंस्टेंस
  • बूट होता इंस्टेंस
  • खराब बिल्ड पर इंस्टेंस
  • खाली स्लॉट
  • आते अनुरोध

नियंत्रण

बेड़े का तल। इसे बढ़ाने पर इंस्टेंस तुरंत शुरू होते हैं — परोसने से पहले उन्हें बूट विलंब चाहिए।

उपयोग पर लक्ष्य-अनुसरण; इंस्टेंस बूट होते समय कोई नया स्केल-आउट नहीं। बंद = ठीक न्यूनतम।

कम = अधिक गुंजाइश और अधिक लागत। मापा गया उपयोग 100 % से ऊपर नहीं जा सकता, इसलिए संतृप्त बेड़ा केवल कदम-दर-कदम बढ़ता है।

लंबा TTL = अधिक हिट, पर उत्तर पुराने हो सकते हैं (औसत आयु ≈ TTL/2)।

6 मिनट तक हॉट कुंजियाँ लोड करता है (कैश का +12 % प्रति मिनट) 600 अतिरिक्त डेटाबेस क्वेरी/s की कीमत पर।

कम-प्राथमिकता वाले 30 % (प्रीफ़ेच, बैच, क्रॉलर) का वह हिस्सा जो लोड बैलेंसर पर "बाद में पुनः प्रयास करें" के साथ अस्वीकार होता है।

भारी फ़ीचर हर अनुरोध पर 20 ms CPU और एक डेटाबेस क्वेरी जोड़ता है। बंद = सहज अवनति।

आख़िरी अच्छे बिल्ड को नए फ़्लीट पर फिर से तैनात करता है (5 मिनट, दो बार बिल), फिर ट्रैफ़िक बदलता है। दोबारा दबाने से तैयारी फिर शुरू हो जाती है; कोई खराब बिल्ड लाइव न हो तो इससे केवल पैसा खर्च होता है।

संकेतक

त्रुटि दर
0.00%
सामान्य
p99 विलंब
342ms
सामान्य
बची त्रुटि बजट (30 दिन)
50.0%
सामान्य
बेड़े का उपयोग
52%
सामान्य
बर्न रेट (1 घंटा)0.0 ×
अनुरोध1125 req/s
परोसते इंस्टेंस10
बूट होते इंस्टेंस0
कैश हिट दर77 %
डेटाबेस उपयोग19 %
छोड़ा गया ट्रैफ़िक0 %
बेड़े की लागत4.00 $/h
अब तक की लागत0.00 $
कैश किए उत्तरों की औसत आयु30 s
खराब बिल्ड पर ट्रैफ़िक0 %
उपलब्ध सिफ़ारिशें100 %

ट्रेंड

त्रुटि दर: — %20.000.00

संकट परिदृश्य

स्तर 1 · खराब रिलीज़

09:10 पर नया बिल्ड जारी होता है। महीना पहले ही कठिन रहा है: त्रुटि बजट का केवल 20 % बचा है। डिप्लॉय के कुछ मिनट बाद बर्न-रेट पेज बजता है। बजट बचाएँ।

  • अंत में बची त्रुटि बजट ≥ 18.5 %
  • डिप्लॉय के बाद औसत त्रुटि दर ≤ 0.65 %
  • बेड़े की लागत ≤ $9.50

स्तर 2 · अचानक भीड़

सेवा का एक लिंक तेज़ी से फैल रहा है और आज सुबह किसी समय ट्रैफ़िक में उछाल की आशंका है — कोई नहीं जानता कब, या कितना बड़ा। आज नए इंस्टेंस को चालू होने में 8 मिनट लगते हैं। जब वह आए, तो खाली क्षमता पर पैसा फूँके बिना त्रुटियाँ और विलंबता कम रखें।

  • औसत त्रुटि दर ≤ 0.2 %
  • औसत p99 विलंब ≤ 400 ms
  • औसत छोड़ा गया ट्रैफ़िक ≤ 5 %
  • कुल लागत ≤ $21
  • सिफ़ारिशें ≥ 85 % समय उपलब्ध

स्तर 3 · ठंडा कैश

दोपहर के शिखर पर एक रखरखाव स्क्रिप्ट पूरा कैश साफ़ कर देती है। अब हर अनुरोध डेटाबेस पर जाता है, जिसका आकार सामान्य 85 % हिट दर के लिए रखा गया था। डेटाबेस को ओवरलोड किए बिना सेवा वापस लाएँ।

  • औसत त्रुटि दर ≤ 1.5 %
  • पहले मिनट के बाद डेटाबेस उपयोग कभी 90 % से ऊपर नहीं
  • कैश किए उत्तरों की औसत आयु औसतन ≤ 90 s
  • कुल लागत ≤ $9
  • सिफ़ारिशें ≥ 80 % समय उपलब्ध
  • औसत छोड़ा गया ट्रैफ़िक ≤ 5 %

आधार — आँकड़ों के पीछे का मॉडल

सिमुलेटर द्वारा प्रयुक्त हर संबंध, उसके स्रोत के साथ। मान्यता के रूप में चिह्नित स्थिरांक उदाहरणात्मक अंशांकन हैं।

अनुरोध दैनिक वक्र और गड़बड़ियों का अनुसरण करते हैं; प्रति मिनट गिनती यादृच्छिक है (पॉइसन, सामान्य सन्निकटन) और थोड़ी उछाल वाली।
λ(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]मान्यता: वर्कर संख्या, सेवा समय, डेटाबेस क्षमता, कैश का आकार, भरने की गति, कीमतें और खराब बिल्ड की त्रुटि-दर मध्यम आकार की वेब सेवा के लिए उदाहरणात्मक मान हैं।
Erlang C: M/M/N प्रणाली में अनुरोध को खाली वर्कर के लिए प्रतीक्षा करनी पड़ने की संभावना।
N = instances × 16 workers, a = λ·S; C(a, N) = B / (1 − (a/N)(1 − B)), B = Erlang B[3][6]
प्रतीक्षा-समय की पूँछ: t से अधिक प्रतीक्षा की संभावना चरघातांकी रूप से घटती है; 2-s टाइमआउट पर भी प्रतीक्षारत अनुरोध विफल होते हैं। क्षमता से ऊपर, अधिशेष विफल होता है।
P(W > t) = C·e^(−(N/S − λ)·t); timeouts = P(W > 2 s); a ≥ N ⇒ failed share = 1 − N/a[3]
सेवा-समय और प्रतीक्षा-समय के क्वांटाइल से p99 विलंब।
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]
TTL कैश: यादृच्छिक अनुरोधों के साथ हर मिस एक TTL अवधि शुरू करता है जिसमें अनुरोध हिट करते हैं।
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]मान्यता: वर्कर संख्या, सेवा समय, डेटाबेस क्षमता, कैश का आकार, भरने की गति, कीमतें और खराब बिल्ड की त्रुटि-दर मध्यम आकार की वेब सेवा के लिए उदाहरणात्मक मान हैं।
SLO और त्रुटि बजट: बर्न रेट बताती है कि बजट अनुमत गति से कितने गुना तेज़ खर्च हो रहा है।
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)। सीड दिखाया जाता है और साझा किया जा सकता है।

स्रोत

  1. Site Reliability Engineering — Ch. 3 Embracing Risk (error budgets), Ch. 4 Service Level Objectives — Beyer, Jones, Petoff, Murphy (eds.), O'Reilly, 2016
  2. The Site Reliability Workbook — Ch. 5 Alerting on SLOs (burn rate; 14.4× over 1 h = 2 % of a 30-day budget) — Beyer, Murphy, Rensin, Kawahara, Thorne (eds.), O'Reilly, 2018
  3. Teletraffic Engineering Handbook — Erlang C formula; waiting-time distribution for M/M/n, FCFS — ITU-D Study Group 2 Question 16/2 (V. B. Iversen), 2005
  4. J. D. C. Little — A Proof for the Queuing Formula: L = λW — Operations Research 9(3):383–387, 1961
  5. J. Jung, A. W. Berger, H. Balakrishnan — Modeling TTL-based Internet Caches — IEEE INFOCOM 2003, 2003
  6. M. Harchol-Balter — Performance Modeling and Design of Computer Systems: Queueing Theory in Action (M/M/k, server farms, capacity provisioning) — Cambridge University Press, 2013

यह काम करने वाले कौन हैं

शैक्षिक मॉडल — परिचालन निर्णयों के लिए नहीं। वास्तविक साइटें हर स्थिरांक को अपने उपकरणों और डेटा के अनुसार कैलिब्रेट करती हैं।