IT ოპერაციები — საიტის საიმედოობა ცოცხალი მოდელი

თქვენ მორიგე ხართ ვებ-სერვისზე: დატვირთვის გამანაწილებელი ეგზემპლარების ფლოტის წინ, ქეში მონაცემთა ბაზის წინ და 99,9 % ხელმისაწვდომობის მიზანი. ყოველ წუთს მოდელი სახელმძღვანელოს ფორმულებით ითვლის რიგის დაგვიანებას, ვადის გასვლას, ქეშის დაჭერებსა და მონაცემთა ბაზის დატვირთვას — და იმას, რა ღირს თქვენი გადაწყვეტილებები.

რას ისწავლით

სიმულატორი

დრო 0 min
მოთხოვნები 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 მწმ პროცესორს და ერთ მონაცემთა ბაზის მოთხოვნას ამატებს. გამორთული = კონტროლირებადი დეგრადაცია.

ბოლო კარგ ბილდს ახალ ფლოტზე თავიდან განათავსებს (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 მწმ
  • მოცილებული ტრაფიკის საშუალო ≤ 5 %
  • საერთო ხარჯი ≤ $21
  • რეკომენდაციები ხელმისაწვდომია დროის ≥ 85 %-ში

დონე 3 · ცივი ქეში

შუადღის პიკზე მოვლის სკრიპტი მთელ ქეშს ასუფთავებს. ყოველი მოთხოვნა ახლა მონაცემთა ბაზაზე მიდის, რომელიც ჩვეულებრივი 85 % დაჭერისთვის იყო გათვლილი. სერვისი აღადგინეთ მონაცემთა ბაზის გადატვირთვის გარეშე.

  • შეცდომების საშუალო სიხშირე ≤ 1,5 %
  • მონაცემთა ბაზის დატვირთულობა პირველი წუთის შემდეგ არასოდეს 90 %-ზე მაღლა
  • ქეშირებული პასუხების საშუალო ასაკი ≤ 90 წმ საშუალოდ
  • საერთო ხარჯი ≤ $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]დაშვება: ვორკერების რაოდენობა, მომსახურების დროები, მონაცემთა ბაზის ტევადობა, ქეშის ზომა, შევსების სიჩქარე, ფასები და ცუდი ბილდის შეცდომის სიხშირე საილუსტრაციო მნიშვნელობებია საშუალო ზომის ვებ-სერვისისთვის.
ერლანგ 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), ნორმალური (ბოქს–მიულერი), პუასონის (კნუტი). სიდი ნაჩვენებია და გაზიარებადია.

წყაროები

  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

ვინ აკეთებს ამას პროფესიად

საგანმანათლებლო მოდელი — არ არის განკუთვნილი ოპერაციული გადაწყვეტილებებისთვის. რეალური ობიექტები ყველა მუდმივას საკუთარ აღჭურვილობასა და მონაცემებზე ადგენენ.