🖥️ IT գործառնություններ — ծառայության հուսալիություն Կենդանի մոդել
Դուք հերթապահ եք վեբ ծառայության համար. բեռի հավասարակշռիչ օրինակների նավատորմի առջև, քեշ տվյալների բազայի առջև և 99,9 % հասանելիության նպատակ։ Ամեն րոպե մոդելը հաշվարկում է հերթի ուշացումը, ժամկետի ավարտները, քեշի հարվածները և տվյալների բազայի բեռը դասագրքային բանաձևերից — և թե ինչ են արժենում ձեր որոշումները։
Ինչ կսովորես
Ինչու է ուշացումը պայթում լրիվ օգտագործման մոտ (Erlang C), և ինչու է բեռնման ուշացումով ավտոմատ մասշտաբավորումը միշտ ուշանում։
Ինչպես են SLO-ները, սխալի բյուջեները և այրման արագության ահազանգերը որոշում, թե երբ հետ գլորել։
Ինչպես է սառը քեշը վերածվում տվյալների բազայի անջատման, և որ լծակներն են ժամանակ գնում. դեն նետում, դեգրադացիա, տաքացում։
Սիմուլյատոր
Ժամանակ 0 min
▶Սպասարկող օրինակ
⚙Բեռնվող օրինակ
!Օրինակ վատ տարբերակի վրա
·Ազատ տեղ
•Մուտքային հարցումներ
Կառավարում
Նավատորմի հիմքը։ Բարձրացնելը անմիջապես գործարկում է օրինակներ — նրանք դեռ պետք է բեռնման ուշացում՝ սպասարկելուց առաջ։
Թիրախի հետևում ըստ օգտագործման. նոր ընդլայնում չկա, քանի դեռ օրինակները (instances) դեռ բեռնվում են։ Անջատված = ճիշտ նվազագույնը։
Ավելի ցածր = ավելի շատ պահուստ և ավելի շատ ծախս։ Չափված օգտագործումը չի կարող գերազանցել 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 %
Միտում
Ճգնաժամային սցենարներ
Մակարդակ 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 ժամկետում դեռ սպասող հարցումները ձախողվում են։ Հզորությունից վեր՝ ավելցուկը ձախողվում է։
p99 ուշացում սպասարկման և սպասման ժամանակների քվանտիլներից։
p99 ≈ S·ln 100 + ln(C/0.01)/(N/S − λ) (service + waiting quantile, an approximation)[3][6]Մոտարկում. սպասարկման և սպասման քվանտիլները գումարելը նրանց գումարի ճշգրիտ p99-ը չէ (կարող է մի փոքր բարձր կամ ցածր լինել). հերթը յուրաքանչյուր րոպեի ընթացքում դիտարկվում է որպես կայուն, քանի որ հարցումները տևում են միլիվայրկյաններ։
Լիթլի օրենք. զբաղված աշխատողներ = ժամանման արագություն × ժամանակ սպասարկման մեջ։
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)։ Սերմը ցուցադրվում է և կարող է կիսվել։
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
Ուսումնական մոդել — գործառնական որոշումների համար չէ։ Իրական օբյեկտները յուրաքանչյուր հաստատուն չափաբերում են իրենց սարքավորումներին և տվյալներին համապատասխան։