നിങ്ങൾ ഒരു വെബ് സേവനത്തിന്റെ ഓൺ-കോളിലാണ്: ഇൻസ്റ്റൻസുകളുടെ ഫ്ലീറ്റിന് മുന്നിൽ ഒരു ലോഡ് ബാലൻസർ, ഡാറ്റാബേസിന് മുന്നിൽ ഒരു കാഷ്, 99.9 % ലഭ്യതാ ലക്ഷ്യം. ഓരോ മിനിറ്റിലും മോഡൽ പാഠപുസ്തക സൂത്രവാക്യങ്ങളിൽ നിന്ന് ക്യൂ കാലതാമസം, ടൈംഔട്ടുകൾ, കാഷ് ഹിറ്റുകൾ, ഡാറ്റാബേസ് ലോഡ് എന്നിവ കണക്കാക്കുന്നു — നിങ്ങളുടെ തീരുമാനങ്ങൾക്ക് എന്ത് ചെലവാകുമെന്നും.
ഫ്ലീറ്റിനുള്ള അടിത്തറ. ഉയർത്തിയാൽ ഇൻസ്റ്റൻസുകൾ ഉടൻ ആരംഭിക്കും — സേവനം നൽകുംമുമ്പ് അവയ്ക്ക് ബൂട്ട് കാലതാമസം വേണം.
ഉപയോഗത്തിലെ ടാർഗറ്റ് ട്രാക്കിംഗ്; ഇൻസ്റ്റൻസുകൾ ഇപ്പോഴും ബൂട്ട് ആകുമ്പോൾ പുതിയ സ്കെയിൽ-ഔട്ട് ഇല്ല. ഓഫ് = കൃത്യം മിനിമം.
കുറവ് = കൂടുതൽ ഇടവും കൂടുതൽ ചെലവും. അളന്ന ഉപയോഗം 100 % കവിയാൻ കഴിയില്ല, അതിനാൽ പൂരിത ഫ്ലീറ്റ് പടിപടിയായി മാത്രം വളരുന്നു.
ദൈർഘ്യമേറിയ TTL = കൂടുതൽ ഹിറ്റുകൾ, പക്ഷേ ഉത്തരങ്ങൾ പഴയതാകാം (ശരാശരി പ്രായം ≈ TTL/2).
6 മിനിറ്റ് ഹോട്ട് കീകൾ ലോഡ് ചെയ്യുന്നു (മിനിറ്റിൽ കാഷിന്റെ +12 %), 600 അധിക ഡാറ്റാബേസ് ക്വറികൾ/s വിലയിൽ.
“പിന്നീട് ശ്രമിക്കുക” എന്ന് ലോഡ് ബാലൻസറിൽ നിരസിക്കുന്ന കുറഞ്ഞ മുൻഗണനയുള്ള 30 % ന്റെ (പ്രീഫെച്ച്, ബാച്ച്, ക്രോളറുകൾ) വിഹിതം.
കനത്ത ഫീച്ചർ ഓരോ അഭ്യർത്ഥനയ്ക്കും 20 ms CPU യും ഒരു ഡാറ്റാബേസ് ക്വറിയും ചേർക്കുന്നു. ഓഫ് = സൗമ്യമായ തരംതാഴ്ത്തൽ.
അവസാനത്തെ നല്ല ബിൽഡ് പുതിയ ഫ്ലീറ്റിൽ വീണ്ടും ഡിപ്ലോയ് ചെയ്യുന്നു (5 min, രണ്ടുതവണ ബിൽ ചെയ്യും), പിന്നെ ട്രാഫിക് മാറ്റുന്നു. വീണ്ടും അമർത്തിയാൽ തയ്യാറെടുപ്പ് വീണ്ടും തുടങ്ങും; മോശം ബിൽഡ് ലൈവ് ഇല്ലെങ്കിൽ അത് പണച്ചെലവ് മാത്രം.
| ബേൺ റേറ്റ് (1 h) | 0.0 × |
|---|---|
| അഭ്യർത്ഥനകൾ | 1125 req/s |
| സേവനം നൽകുന്ന ഇൻസ്റ്റൻസുകൾ | 10 |
| ബൂട്ട് ആകുന്ന ഇൻസ്റ്റൻസുകൾ | 0 |
| കാഷ് ഹിറ്റ് നിരക്ക് | 77 % |
| ഡാറ്റാബേസ് ഉപയോഗം | 19 % |
| ഒഴിവാക്കിയ ട്രാഫിക് | 0 % |
| ഫ്ലീറ്റ് ചെലവ് | 4.00 $/h |
| ഇതുവരെയുള്ള ചെലവ് | 0.00 $ |
| കാഷ് ചെയ്ത ഉത്തരങ്ങളുടെ ശരാശരി പ്രായം | 30 s |
| മോശം ബിൽഡിലെ ട്രാഫിക് | 0 % |
| ശുപാർശകൾ ലഭ്യം | 100 % |
09:10 ന് ഒരു പുതിയ ബിൽഡ് പുറത്തിറങ്ങുന്നു. മാസം ഇതിനകം കഠിനമായിരുന്നു: പിശക് ബജറ്റിന്റെ 20 % മാത്രമേ ബാക്കിയുള്ളൂ. ഡിപ്ലോയ് കഴിഞ്ഞ് മിനിറ്റുകൾക്കകം ബേൺ-റേറ്റ് പേജ് മുഴങ്ങുന്നു. ബജറ്റ് സംരക്ഷിക്കുക.
സേവനത്തിലേക്കുള്ള ഒരു ലിങ്ക് വേഗത്തിൽ പടരുന്നു, ഇന്ന് രാവിലെ എപ്പോഴെങ്കിലും ഒരു ട്രാഫിക് കുതിപ്പ് പ്രതീക്ഷിക്കുന്നു — എപ്പോൾ എന്നോ എത്ര വലുതെന്നോ ആർക്കും അറിയില്ല. പുതിയ ഇൻസ്റ്റൻസുകൾക്ക് ഇന്ന് ആരംഭിക്കാൻ 8 മിനിറ്റ് വേണം. അത് വരുമ്പോൾ, ഉപയോഗിക്കാത്ത ശേഷിക്ക് പണം പാഴാക്കാതെ പിശകുകളും ലേറ്റൻസിയും കുറച്ച് നിലനിർത്തുക.
ഉച്ചയ്ക്കത്തെ ഉച്ചസ്ഥായിയിൽ ഒരു മെയിന്റനൻസ് സ്ക്രിപ്റ്റ് മുഴുവൻ കാഷും ഫ്ലഷ് ചെയ്യുന്നു. ഇപ്പോൾ ഓരോ അഭ്യർത്ഥനയും സാധാരണ 85 % ഹിറ്റ് നിരക്കിന് രൂപകൽപ്പന ചെയ്ത ഡാറ്റാബേസിലേക്ക് പോകുന്നു. ഡാറ്റാബേസ് ഓവർലോഡ് ആക്കാതെ സേവനം തിരികെ കൊണ്ടുവരിക.
സിമുലേറ്റർ ഉപയോഗിക്കുന്ന ഓരോ ബന്ധവും അതിന്റെ ഉറവിടം സഹിതം. അനുമാനങ്ങളായി അടയാളപ്പെടുത്തിയ സ്ഥിരാങ്കങ്ങൾ ഉദാഹരണത്തിനുള്ള കാലിബ്രേഷനുകളാണ്.
λ(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]അനുമാനം: വർക്കർ എണ്ണം, സേവന സമയങ്ങൾ, ഡാറ്റാബേസ് ശേഷി, കാഷ് വലിപ്പം, റീഫിൽ വേഗത, വിലകൾ, മോശം ബിൽഡിന്റെ പിശക് നിരക്ക് എന്നിവ ഇടത്തരം വെബ് സേവനത്തിനുള്ള ഉദാഹരണ മൂല്യങ്ങളാണ്.N = instances × 16 workers, a = λ·S; C(a, N) = B / (1 − (a/N)(1 − B)), B = Erlang B[3][6]P(W > t) = C·e^(−(N/S − λ)·t); timeouts = P(W > 2 s); a ≥ N ⇒ failed share = 1 − N/a[3]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]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]അനുമാനം: വർക്കർ എണ്ണം, സേവന സമയങ്ങൾ, ഡാറ്റാബേസ് ശേഷി, കാഷ് വലിപ്പം, റീഫിൽ വേഗത, വിലകൾ, മോശം ബിൽഡിന്റെ പിശക് നിരക്ക് എന്നിവ ഇടത്തരം വെബ് സേവനത്തിനുള്ള ഉദാഹരണ മൂല്യങ്ങളാണ്.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). സീഡ് കാണിക്കുകയും പങ്കിടാൻ കഴിയുകയും ചെയ്യും.
വിദ്യാഭ്യാസ മോഡൽ — പ്രവർത്തന തീരുമാനങ്ങൾക്കുള്ളതല്ല. യഥാർത്ഥ സൈറ്റുകൾ ഓരോ സ്ഥിരാങ്കവും സ്വന്തം ഉപകരണങ്ങൾക്കും ഡാറ്റയ്ക്കും അനുസരിച്ച് കാലിബ്രേറ്റ് ചെയ്യുന്നു.