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

આ કામ આજીવિકા તરીકે કોણ કરે છે

શૈક્ષણિક મોડેલ — ઓપરેશનલ નિર્ણયો માટે નહીં. વાસ્તવિક સાઇટ દરેક અચળાંકને પોતાના સાધનો અને ડેટા મુજબ કેલિબ્રેટ કરે છે.