ການດຳເນີນງານ IT — ຄວາມໜ້າເຊື່ອຖືຂອງເວັບໄຊ ແບບຈຳລອງສົດ

ທ່ານເປັນຜູ້ເຝົ້າລະວັງສຳລັບບໍລິການເວັບ: load balancer ໜ້າກຸ່ມ instance, cache ໜ້າຖານຂໍ້ມູນ ແລະເປົ້າໝາຍຄວາມພ້ອມໃຊ້ 99.9 %. ທຸກນາທີແບບຈຳລອງຄຳນວນການຊັກຊ້າແຖວ, timeout, cache hit ແລະພາລະຖານຂໍ້ມູນຈາກສູດຕຳລາ — ແລະສິ່ງທີ່ການຕັດສິນໃຈຂອງທ່ານເສຍ.

ສິ່ງທີ່ທ່ານຈະໄດ້ຮຽນ

ຕົວຈຳລອງ

ເວລາ 0 ນາທີ
ຄຳຂໍ 1125 · ອັດຕາຂໍ້ຜິດພາດ 0,00% · ເວລາຕອບສະໜອງ p99 342 ms · instance ກຳລັງໃຫ້ບໍລິການ 10 (+0) · ອັດຕາ cache hit 77% · ການໃຊ້ງານຖານຂໍ້ມູນ 19% · ງົບຂໍ້ຜິດພາດທີ່ເຫຼືອ (30 ວັນ) 50,0%⇉1125 ຄຳຂໍ/ວິ▶▶▶▶▶▶▶▶▶▶······························▶ 10 · ⚙ 0 · 52% · p99 342 msການໃຊ້ງານກຸ່ມ 52%ອັດຕາ cache hit 77%ການໃຊ້ງານຖານຂໍ້ມູນ 19%⚠ 0,00% · 🔥 0,0×50%$ 4,00/h · Σ $0,00
  • instance ກຳລັງໃຫ້ບໍລິການ
  • instance ກຳລັງເລີ່ມ
  • instance ໃນ build ທີ່ບໍ່ດີ
  • ຊ່ອງວ່າງ
  • ຄຳຂໍເຂົ້າ

ການຄວບຄຸມ

ພື້ນຂອງກຸ່ມ. ການເພີ່ມມັນເປີດ instance ທັນທີ — ພວກມັນຍັງຕ້ອງການການຊັກຊ້າການເລີ່ມກ່ອນໃຫ້ບໍລິການ.

ການຕິດຕາມເປົ້າໝາຍຕາມການໃຊ້ງານ; ບໍ່ມີການຂະຫຍາຍອອກໃໝ່ໃນຂະນະທີ່ instance ຍັງກຳລັງເລີ່ມ. ປິດ = ຂັ້ນຕ່ຳພໍດີ.

ຕ່ຳກວ່າ = ຊ່ອງວ່າງຫຼາຍກວ່າ ແລະຄ່າໃຊ້ຈ່າຍຫຼາຍກວ່າ. ການໃຊ້ງານທີ່ວັດບໍ່ສາມາດເກີນ 100 % ສະນັ້ນກຸ່ມທີ່ອີ່ມຕົວເຕີບໂຕເທື່ອລະຂັ້ນເທົ່ານັ້ນ.

TTL ຍາວກວ່າ = hit ຫຼາຍກວ່າ ແຕ່ຄຳຕອບອາດເກົ່າກວ່າ (ອາຍຸສະເລ່ຍ ≈ TTL/2).

ໂຫຼດຄີຮ້ອນ 6 ນາທີ (+12 % ຂອງ cache ຕໍ່ນາທີ) ໃນລາຄາຄຳຖາມຖານຂໍ້ມູນເພີ່ມ 600/s.

ສ່ວນແບ່ງຂອງ 30 % ບູລິມະສິດຕ່ຳ (prefetch, batch, crawler) ທີ່ຖືກປະຕິເສດທີ່ load balancer ດ້ວຍ "ລອງໃໝ່ພາຍຫຼັງ".

ຄຸນສົມບັດໜັກເພີ່ມ CPU 20 ms ແລະໜຶ່ງຄຳຖາມຖານຂໍ້ມູນຕໍ່ຄຳຂໍ. ປິດ = ການຫຼຸດລົງຢ່າງອ່ອນໂຍນ.

ນຳໃຊ້ build ດີຫຼ້າສຸດຄືນໃນຊຸດເຊີບເວີໃໝ່ (5 ນາທີ, ຄິດເງິນສອງເທື່ອ), ຈາກນັ້ນປ່ຽນທຣາຟຟິກ. ການກົດອີກເລີ່ມການກຽມໃໝ່; ຖ້າບໍ່ມີ build ຮ້າຍເຮັດວຽກຢູ່ ມັນພຽງແຕ່ເສຍເງິນ.

ຕົວຊີ້ວັດ

ອັດຕາຂໍ້ຜິດພາດ
0,00%
ປົກກະຕິ
ເວລາຕອບສະໜອງ p99
342ms
ປົກກະຕິ
ງົບຂໍ້ຜິດພາດທີ່ເຫຼືອ (30 ວັນ)
50,0%
ປົກກະຕິ
ການໃຊ້ງານກຸ່ມ
52%
ປົກກະຕິ
ອັດຕາເຜົາ (1 ຊມ)0,0 ×
ຄຳຂໍ1125 req/s
instance ກຳລັງໃຫ້ບໍລິການ10
instance ກຳລັງເລີ່ມ0
ອັດຕາ cache hit77 %
ການໃຊ້ງານຖານຂໍ້ມູນ19 %
ທຣາຟຟິກທີ່ຫຼຸດ0 %
ຄ່າໃຊ້ຈ່າຍກຸ່ມ4,00 $/h
ຄ່າໃຊ້ຈ່າຍມາຮອດຕອນນີ້0,00 $
ອາຍຸສະເລ່ຍຂອງຄຳຕອບໃນ cache30 s
ທຣາຟຟິກໃນ build ທີ່ບໍ່ດີ0 %
ການແນະນຳພ້ອມໃຊ້100 %

ແນວໂນ້ມ

ອັດຕາຂໍ້ຜິດພາດ: — %20,000,00

ສະຖານະການວິກິດ

ລະດັບ 1 · ການປ່ອຍທີ່ບໍ່ດີ

build ໃໝ່ອອກເວລາ 09:10. ເດືອນນີ້ໜັກແລ້ວ: ເຫຼືອພຽງ 20 % ຂອງງົບຂໍ້ຜິດພາດ. ໄລຍະນາທີຫຼັງ deploy ການແຈ້ງເຕືອນອັດຕາເຜົາດັງ. ປົກປ້ອງງົບ.

  • ງົບຂໍ້ຜິດພາດທີ່ເຫຼືອຕອນທ້າຍ ≥ 18.5 %
  • ອັດຕາຂໍ້ຜິດພາດສະເລ່ຍຫຼັງ deploy ≤ 0.65 %
  • ຄ່າໃຊ້ຈ່າຍກຸ່ມ ≤ $9.50

ລະດັບ 2 · ຝູງຊົນທັນທີທັນໃດ

ລິ້ງໄປຫາບໍລິການກຳລັງແຜ່ໄວ ແລະ ຄາດວ່າຈະມີທຣາຟຟິກພຸ່ງຂຶ້ນໃນເວລາໃດໜຶ່ງເຊົ້ານີ້ — ບໍ່ມີໃຜຮູ້ວ່າເມື່ອໃດ ຫຼື ໃຫຍ່ເທົ່າໃດ. instance ໃໝ່ໃຊ້ເວລາ 8 ນາທີເພື່ອເລີ່ມໃນມື້ນີ້. ເມື່ອມັນມາ ຮັກສາຂໍ້ຜິດພາດ ແລະ ເວລາຊັກຊ້າໃຫ້ຕ່ຳ ໂດຍບໍ່ເຜົາເງິນໄປກັບຄວາມຈຸທີ່ວ່າງ.

  • ອັດຕາຂໍ້ຜິດພາດສະເລ່ຍ ≤ 0.2 %
  • ເວລາຕອບສະໜອງ p99 ສະເລ່ຍ ≤ 400 ms
  • ທຣາຟຟິກທີ່ຫຼຸດສະເລ່ຍ ≤ 5 %
  • ຄ່າໃຊ້ຈ່າຍທັງໝົດ ≤ $21
  • ການແນະນຳພ້ອມໃຊ້ ≥ 85 % ຂອງເວລາ

ລະດັບ 3 · cache ເຢັນ

ທີ່ຈຸດສູງສຸດຕອນທ່ຽງ ສະຄຣິບບຳລຸງຮັກສາລ້າງ cache ທັງໝົດ. ຕອນນີ້ທຸກຄຳຂໍໄປຖານຂໍ້ມູນ ເຊິ່ງຖືກກຳນົດຂະໜາດສຳລັບອັດຕາ hit ປົກກະຕິ 85 %. ນຳບໍລິການກັບຄືນໂດຍບໍ່ໂຫຼດຖານຂໍ້ມູນເກີນ.

  • ອັດຕາຂໍ້ຜິດພາດສະເລ່ຍ ≤ 1.5 %
  • ການໃຊ້ງານຖານຂໍ້ມູນບໍ່ເຄີຍສູງກວ່າ 90 % ຫຼັງນາທີທຳອິດ
  • ອາຍຸສະເລ່ຍຂອງຄຳຕອບໃນ cache ≤ 90 s ໂດຍສະເລ່ຍ
  • ຄ່າໃຊ້ຈ່າຍທັງໝົດ ≤ $9
  • ການແນະນຳພ້ອມໃຊ້ ≥ 80 % ຂອງເວລາ
  • ທຣາຟຟິກທີ່ຫຼຸດສະເລ່ຍ ≤ 5 %

ພື້ນຖານ — ແບບຈຳລອງທີ່ຢູ່ເບື້ອງຫຼັງຕົວເລກ

ທຸກຄວາມສຳພັນທີ່ຕົວຈຳລອງໃຊ້ ພ້ອມແຫຼ່ງທີ່ມາ. ຄ່າຄົງທີ່ທີ່ໝາຍເປັນຂໍ້ສົມມຸດແມ່ນການປັບຄ່າຕົວຢ່າງ.

ຄຳຂໍຕາມເສັ້ນໂຄ້ງລາຍວັນບວກການລົບກວນ; ຈຳນວນຕໍ່ນາທີແມ່ນສຸ່ມ (Poisson, ການປະມານແບບປົກກະຕິ) ດ້ວຍການຮຸນແຮງເລັກນ້ອຍ.
λ(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]ຂໍ້ສົມມຸດ: ຈຳນວນ worker, ເວລາບໍລິການ, ຄວາມຈຸຖານຂໍ້ມູນ, ຂະໜາດ cache, ຄວາມໄວການຕື່ມ, ລາຄາ ແລະອັດຕາຂໍ້ຜິດພາດຂອງ build ທີ່ບໍ່ດີເປັນຄ່າຕົວຢ່າງສຳລັບບໍລິການເວັບຂະໜາດກາງ.
Erlang C: ຄວາມນ່າຈະເປັນທີ່ຄຳຂໍຕ້ອງລໍ worker ວ່າງໃນລະບົບ M/M/N.
N = instances × 16 workers, a = λ·S; C(a, N) = B / (1 − (a/N)(1 − B)), B = Erlang B[3][6]
ຫາງເວລາລໍຖ້າ: ໂອກາດລໍດົນກວ່າ t ຫຼຸດລົງແບບເອັກໂປເນັນຊຽນ; ຄຳຂໍທີ່ຍັງລໍຢູ່ທີ່ timeout 2 ວິນາທີລົ້ມເຫຼວ. ເກີນຄວາມຈຸ ສ່ວນເກີນລົ້ມເຫຼວ.
P(W > t) = C·e^(−(N/S − λ)·t); timeouts = P(W > 2 s); a ≥ N ⇒ failed share = 1 − N/a[3]
ເວລາຕອບສະໜອງ p99 ຈາກ quantile ຂອງເວລາບໍລິການ ແລະເວລາລໍຖ້າ.
p99 ≈ S·ln 100 + ln(C/0.01)/(N/S − λ) (service + waiting quantile, an approximation)[3][6]ການປະມານ: ການບວກ quantile ຂອງການບໍລິການ ແລະການລໍຖ້າບໍ່ແມ່ນ p99 ທີ່ແນ່ນອນຂອງຜົນບວກຂອງມັນ (ອາດສູງ ຫຼືຕ່ຳເລັກນ້ອຍ); ຄິວຖືວ່ານິ່ງພາຍໃນແຕ່ລະນາທີ ເພາະຄຳຮ້ອງຂໍໃຊ້ເວລາເປັນມິນລິວິນາທີ.
ກົດຂອງ Little: worker ທີ່ຫຍຸ້ງ = ອັດຕາມາຮອດ × ເວລາໃນບໍລິການ.
busy workers L = λ·S ⇒ utilization = λ·S / N[4]
TTL cache: ດ້ວຍຄຳຂໍສຸ່ມ ທຸກ miss ເລີ່ມໄລຍະ TTL ທີ່ຄຳຂໍ hit.
hit = warm × rT/(1 + rT), r = λ / 20,000 objects; mean age of a cached answer ≈ T/2[5]
cache miss ໂຫຼດຖານຂໍ້ມູນ; ການຊັກຊ້າແຖວຂອງມັນເຮັດໃຫ້ທຸກຄຳຂໍທີ່ແຕະມັນຊ້າລົງ ເຊິ່ງຍັງເຮັດໃຫ້ app worker ເຕັມ.
DB load = λ·q·(1 − hit); query time = 5 ms/(1 − ρ_db) (≤ 250 ms); S = S_app + (1 − hit)·q·query time[6]ຂໍ້ສົມມຸດ: ຈຳນວນ worker, ເວລາບໍລິການ, ຄວາມຈຸຖານຂໍ້ມູນ, ຂະໜາດ cache, ຄວາມໄວການຕື່ມ, ລາຄາ ແລະອັດຕາຂໍ້ຜິດພາດຂອງ build ທີ່ບໍ່ດີເປັນຄ່າຕົວຢ່າງສຳລັບບໍລິການເວັບຂະໜາດກາງ.
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]
ຕົວປັບຂະໜາດອັດຕະໂນມັດທີ່ຕິດຕາມເປົ້າໝາຍ ດ້ວຍການຊັກຊ້າການເລີ່ມ ແລະ cooldown.
desired = ⌈serving × utilization / target⌉ (utilization saturates at 100 %); new instances serve after the boot delay[6]ຂໍ້ສົມມຸດ: ຈຳນວນ worker, ເວລາບໍລິການ, ຄວາມຈຸຖານຂໍ້ມູນ, ຂະໜາດ cache, ຄວາມໄວການຕື່ມ, ລາຄາ ແລະອັດຕາຂໍ້ຜິດພາດຂອງ build ທີ່ບໍ່ດີເປັນຄ່າຕົວຢ່າງສຳລັບບໍລິການເວັບຂະໜາດກາງ.
ຄ່າຄົງທີ່ການດຳເນີນງານອື່ນໆທີ່ແບບຈຳລອງໃຊ້.
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ຂໍ້ສົມມຸດ: ຈຳນວນ worker, ເວລາບໍລິການ, ຄວາມຈຸຖານຂໍ້ມູນ, ຂະໜາດ cache, ຄວາມໄວການຕື່ມ, ລາຄາ ແລະອັດຕາຂໍ້ຜິດພາດຂອງ build ທີ່ບໍ່ດີເປັນຄ່າຕົວຢ່າງສຳລັບບໍລິການເວັບຂະໜາດກາງ.

ຄວາມສຸ່ມ: ຕົວສ້າງ mulberry32 ທີ່ມີແກ່ນ; ການກະຈາຍທີ່ໃຊ້ — ເອກະພາບ ເລກກຳລັງ (CDF ກັບຄືນ) ປົກກະຕິ (Box–Muller) Poisson (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

ໃຜເຮັດອາຊີບນີ້

ແບບຈຳລອງເພື່ອການສຶກສາ — ບໍ່ສຳລັບການຕັດສິນໃຈປະຕິບັດການ. ສະຖານທີ່ຈິງປັບທຸກຄ່າຄົງທີ່ຕາມອຸປະກອນ ແລະຂໍ້ມູນຂອງຕົນເອງ.