आयटी संचालन — साइट विश्वासार्हता लाइव्ह मॉडेल

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

तुम्ही काय शिकाल

सिम्युलेटर

वेळ 0 मि
विनंत्या 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 min, दोनदा बिल केले जाते), मग ट्रॅफिक स्विच करतो. पुन्हा दाबल्यास तयारी पुन्हा सुरू होते; वाईट बिल्ड लाइव्ह नसताना फक्त पैसे खर्च होतात.

निर्देशक

एरर दर
0.00%
सामान्य
p99 लेटन्सी
342ms
सामान्य
उरलेले एरर बजेट (30 दिवस)
50.0%
सामान्य
ताफ्याचा वापर
52%
सामान्य
बर्न रेट (1 h)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

हे काम व्यवसाय म्हणून कोण करतो

शैक्षणिक मॉडेल — कार्यचालन निर्णयांसाठी नाही. खऱ्या साइट प्रत्येक स्थिरांक आपल्या उपकरणांनुसार आणि डेटानुसार जुळवतात.