IT కార్యకలాపాలు — సైట్ విశ్వసనీయత లైవ్ మోడల్

మీరు ఒక వెబ్ సేవకు ఆన్-కాల్‌లో ఉన్నారు: ఇన్‌స్టాన్స్‌ల ఫ్లీట్ ముందు లోడ్ బ్యాలెన్సర్, డేటాబేస్ ముందు కాష్, 99.9 % లభ్యత లక్ష్యం. ప్రతి నిమిషం నమూనా క్యూ ఆలస్యం, టైమ్‌అవుట్‌లు, కాష్ హిట్‌లు, డేటాబేస్ లోడ్‌ను పాఠ్యపుస్తక సూత్రాల నుండి లెక్కిస్తుంది — మరియు మీ నిర్ణయాల ఖర్చును.

మీరు ఏమి నేర్చుకుంటారు

సిమ్యులేటర్

సమయం 0 నిమి
అభ్యర్థనలు 1125 · ఎర్రర్ రేటు 0.00% · p99 ఆలస్యం 342 ms · సేవ చేస్తున్న ఇన్‌స్టాన్స్‌లు 10 (+0) · కాష్ హిట్ రేటు 77% · డేటాబేస్ వినియోగం 19% · మిగిలిన ఎర్రర్ బడ్జెట్ (30 రోజులు) 50.0%⇉1125 అభ్యర్థనలు/సె▶▶▶▶▶▶▶▶▶▶······························▶ 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 అదనపు డేటాబేస్ క్వెరీల ధరకు.

తక్కువ ప్రాధాన్య 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-సె టైమ్‌అవుట్ వద్ద ఇంకా వేచి ఉన్న అభ్యర్థనలు విఫలమవుతాయి. సామర్థ్యానికి మించి, అధికం విఫలమవుతుంది.
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

దీన్ని వృత్తిగా ఎవరు చేస్తారు

విద్యా మోడల్ — కార్యాచరణ నిర్ణయాలకు కాదు. నిజమైన సైట్లు ప్రతి స్థిరాంకాన్ని తమ సొంత పరికరాలు, డేటాకు అనుగుణంగా క్రమాంకనం చేస్తాయి.