IT ପରିଚାଳନା — ସାଇଟ୍ ନିର୍ଭରଯୋଗ୍ୟତା ଲାଇଭ୍ ମଡେଲ୍

ଆପଣ ଏକ ୱେବ୍ ସେବା ପାଇଁ ଅନ-କଲ୍: ଇନଷ୍ଟାନ୍ସର ଏକ ଫ୍ଲିଟ୍ ଆଗରେ ଏକ ଲୋଡ୍ ବ୍ୟାଲାନ୍ସର୍, ଏକ ଡାଟାବେସ୍ ଆଗରେ ଏକ କ୍ୟାଶ୍, ଏବଂ 99.9 % ଉପଲବ୍ଧତା ଲକ୍ଷ୍ୟ। ପ୍ରତି ମିନିଟରେ ମଡେଲ୍ ପାଠ୍ୟପୁସ୍ତକ ସୂତ୍ରରୁ ଧାଡ଼ି ବିଳମ୍ବ, ଟାଇମଆଉଟ୍, କ୍ୟାଶ୍ ହିଟ୍ ଓ ଡାଟାବେସ୍ ଲୋଡ୍ ଗଣେ — ଏବଂ ଆପଣଙ୍କ ନିଷ୍ପତ୍ତିର ମୂଲ୍ୟ କେତେ।

ଆପଣ କ'ଣ ଶିଖିବେ

ସିମୁଲେଟର

ସମୟ 0 ମିନି
ଅନୁରୋଧ 1125 · ତ୍ରୁଟି ହାର 0.00% · p99 ଲେଟେନ୍ସି 342 ms · ସେବା କରୁଥିବା ଇନଷ୍ଟାନ୍ସ 10 (+0) · କ୍ୟାଶ୍ ହିଟ୍ ହାର 77% · ଡାଟାବେସ୍ ବ୍ୟବହାର 19% · ବାକି ତ୍ରୁଟି ବଜେଟ୍ (30 ଦିନ) 50.0%⇉1125 req/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

ଏହା କିଏ ଜୀବିକା ପାଇଁ କରେ

ଶିକ୍ଷାମୂଳକ ମଡେଲ୍ — ପରିଚାଳନା ନିଷ୍ପତ୍ତି ପାଇଁ ନୁହେଁ। ପ୍ରକୃତ ସାଇଟ୍ ପ୍ରତ୍ୟେକ ଧ୍ରୁବାଙ୍କକୁ ନିଜ ଉପକରଣ ଓ ତଥ୍ୟ ଅନୁସାରେ କ୍ୟାଲିବ୍ରେଟ୍ କରନ୍ତି।