പുതുതായി ലോഞ്ച് ചെയ്ത ഒരു ആപ്പിലേക്ക് ഏതാനും ആയിരം ഉപയോക്താക്കൾ ഒരേസമയം പ്രവേശിക്കുമ്പോൾ ആ ആപ്പ് നിലച്ചുപോകുന്നത് ഡെവലപ്പർമാർക്ക് നേരിട്ട് കാണേണ്ടി വരാറുണ്ട്. ഈ വേഗത കുറയുന്നത് പലപ്പോഴും കോഡിലെ ബഗ് കാരണം ഉണ്ടാകുന്നതല്ല – മറിച്ച് സെർവറിലെ CPU-യും RAM-ഉം സ്ഥലത്തിനായി മത്സരിക്കുന്നതുകൊണ്ടാണ്. പേജുകൾ ലോഡ് ആകാൻ എടുക്കുന്ന സമയം കൂടുകയോ, ടൈം-ഔട്ട് സംഭവിക്കുകയോ, അല്ലെങ്കിൽ ആപ്പ് പൂർണ്ണമായും ക്രാഷ് ആകുകയോ ചെയ്യുന്നത് ഈ തടസ്സത്തിന്റെ ഫലമാണ്. ഇത് ഉപയോക്താക്കളുടെ അനുഭവം (user experience), വരുമാനം, ബ്രാൻഡ് വിശ്വാസം എന്നിവയെ ദോഷകരമായി ബാധിക്കുന്നു.

ലാബിൽ നന്നായി പ്രവർത്തിച്ച ഒരു സെർവർ പ്രൊഡക്ഷനിൽ എത്തുമ്പോൾ എന്തുകൊണ്ട് നിലച്ചുപോകുന്നു

ഡെവലപ്‌മെന്റ് ഘട്ടത്തിൽ ഒരു ഡെവലപ്പർ മാത്രം ഏതാനും റിക്വസ്റ്റുകൾ അയക്കുന്നതിനാൽ, സെർവറിലെ വിഭവങ്ങൾ മിക്കവാറും സമയങ്ങളിൽ ഉപയോഗിക്കാതെ ഇരിക്കുകയാണ്. എന്നാൽ ആപ്പ് ലൈവ് ആകുമ്പോൾ, ഓരോ സന്ദർശകനും രണ്ട് പ്രധാന ഘടകങ്ങൾ ആവശ്യമുള്ള ഒരു റിക്വസ്റ്റ് ഓരോന്നായി നൽകുന്നു:

  • CPU (central processing unit) – ഓരോ ലൂപ്പും ഫങ്ക്ഷനും കണക്കുകൂട്ടലുകളും പ്രവർത്തിപ്പിക്കുന്ന പ്രോസസ്സർ. ഇതിനെ ഒരേസമയം പരിമിതമായ വിഭവങ്ങൾ മാത്രം തയ്യാറാക്കാൻ കഴിയുന്ന ഒരു പാചകക്കാരനായി സങ്കൽപ്പിക്കുക. ഒരു ഓർഡർ വന്നാൽ അത് ഉടൻ തന്നെ തയ്യാറാക്കാം; എന്നാൽ നൂറ് ഓർഡറുകൾ വരുമ്പോൾ പാചകക്കാരൻ അതേ വേഗതയിൽ തന്നെ ജോലി ചെയ്യുമെങ്കിലും ഭക്ഷണം കഴിക്കാൻ വരുന്നവർക്ക് കൂടുതൽ സമയം കാത്തിരിക്കേണ്ടി വരും.
  • RAM (random-access memory) – ഒരു റിക്വസ്റ്റ് കൈകാര്യം ചെയ്യുമ്പോൾ CPU-യ്ക്ക് ആവശ്യമായ ഡാറ്റകൾ സൂക്ഷിക്കുന്ന താൽക്കാലിക സംഭരണം. ഇത് പാചകക്കാരൻ ഓരോ വിഭവത്തിനും ആവശ്യമായ ചേരുവകൾ വെക്കുന്ന ഒരു മേശ പോലെയാണ്. മേശ നിറഞ്ഞുപോയാൽ, സ്ഥലസൗകര്യം ലഭിക്കുന്നത് വരെ പുതിയ ഓർഡറുകൾ എടുക്കുന്നത് പാചകക്കാരന് നിർത്തേണ്ടി വരും.

ആയിരക്കണക്കിന് ഉപയോക്താക്കൾ ഒരേസമയം ലോഗിൻ ചെയ്യുമ്പോൾ, ഓരോ റിക്വസ്റ്റും അതിന്റെതായ CPU സമയവും RAM-ന്റെ ഒരു ഭാഗവും ഉപയോഗിക്കുന്നു. സെർവറിലുള്ള പരിമിതമായ വിഭവങ്ങൾ ഈ റിക്വസ്റ്റുകൾക്കിടയിൽ വിഭജിക്കപ്പെടുമ്പോൾ ക്യൂ (queue) വർദ്ധിക്കുന്നു. സെർവർ തന്നെ സാവധാനത്തിലായിട്ടില്ല; മറിച്ച് ഓരോ റിക്വസ്റ്റിനും കാത്തിരിക്കേണ്ട സമയം വർദ്ധിച്ചു എന്നതാണ് സത്യം.

“വലിയൊരു മെഷീൻ വാങ്ങാം” എന്ന പ്രലോഭനം

ഒരു മെഷീൻ അപ്‌ഗ്രേഡ് ചെയ്യുക എന്നതാണ് ഇതിനുള്ള ആദ്യത്തെ സാധാരണ പ്രതികരണം – ഇതിനെ vertical scaling എന്ന് വിളിക്കുന്നു. കൂടുതൽ CPU കോറുകളോ കൂടുതൽ RAM-ഓ ചേർക്കുന്നത് കപ്പാസിറ്റി വർദ്ധിപ്പിക്കാൻ സഹായിക്കും: ഉദാഹരണത്തിന് 4 കോറുകളിൽ നിന്ന് 16 കോറിലേക്കോ, 8 GB-യിൽ നിന്ന് 64 GB-യിലേക്കോ മാറുന്നത് കോഡിൽ മാറ്റം വരുത്താതെ തന്നെ വലിയ തോതിലുള്ള ട്രാഫിക് കൈകാര്യം ചെയ്യാൻ സഹായിക്കും.

എങ്കിലും, വെർട്ടിക്കൽ സ്കെയിലിംഗിന് ചില പരിമിതികളുണ്ട്:

  • ഭൗതികമായ പരിധികൾ (Physical limits) – ഓരോ മദർബോർഡിനും ഒരു നിശ്ചിത എണ്ണം കോറുകളെയും പരിമിതമായ മെമ്മറിയെയും മാത്രമേ ഉൾക്കൊള്ളാൻ കഴിയൂ.
  • കുറഞ്ഞുവരുന്ന ലാഭം (Diminishing returns) – ഓരോ അധിക കോറ el ദ് അല്ലെങ്കിൽ ഗിഗാബൈറ്റും തൊട്ടുമുമ്പത്തേതിനേക്കാൾ കൂടുതൽ ചിലവ് വരുത്തുന്നു, എന്നാൽ പ്രകടനത്തിലുള്ള വർദ്ധനവ് കുറഞ്ഞുവരുന്നു.
  • സിംഗിൾ പോയിന്റ് ഓഫ് ഫെയിലിയർ (Single point of failure) – ഈ വലിയ സെർവർ പ്രവർത്തനരഹിതമായാൽ, മുഴുവൻ സർവീസും നിലയ്ക്കും.

ഈ പരിമിതികൾ കാരണം, സ്ട്രീമിംഗ് പ്ലാറ്റ്‌ഫോമുകൾ, സെർച്ച് എഞ്ചിനുകൾ, ഇ-കൊമേഴ്‌സ് സൈറ്റുകൾ തുടങ്ങിയ വൻകിട കമ്പനികൾ ഒറ്റ വലിയ മെഷീനെ ആശ്രയിക്കുന്ന രീതിയിൽ നിന്ന് മാറിപ്പോയിട്ടുണ്ട്.

മറ്റൊരു വഴി: ചെറിയ നിരവധി മെഷീനുകളിലായി ലോഡ് വിഭജിക്കുക

ഒരു വലിയ ടവർ നിർമ്മിക്കുന്നതിന് പകരം, മിതമായ വലിപ്പമുള്ള കൂടുതൽ സെർവറുകൾ ചേർക്കുകയും അവ ട്രാഫിക് പങ്കിടാൻ അനുവദിക്കുകയും ചെയ്യുന്നു. ഈ horizontal scaling രീതി ഓരോ മെഷീനെയും സുരക്ഷിതമായ പ്രവർത്തന പരിധിക്കുള്ളിൽ നിലനിർത്താനും വെർട്ടിക്കൽ അപ്‌ഗ്രേഡുകളിൽ ഉണ്ടാകുന്ന അമിത ചിലവ് ഒഴിവാക്കാനും സഹായിക്കുന്നു.

ധാരാളം മെഷീനുകളെ ഏകോപിപ്പിക്കുന്നതിന് ഒരു load balancer ആവശ്യമാണ് – ഇത് വരുന്ന ഓരോ റിക്വസ്റ്റും സ്വീകരിക്കുകയും ഏറ്റവും കൂടുതൽ ശേഷിയുള്ള സെർവറിലേക്ക് അത് എത്തിക്കുകയും ചെയ്യുന്ന ഒരു സോഫ്റ്റ്‌വെയർ അല്ലെങ്കിൽ ഹാർഡ്‌വെയർ ആണ്. ഈ ബാലൻസർ സങ്കീർണ്ണതകൾ ഉപയോക്താവിൽ നിന്ന് മറച്ചുവെക്കുന്നു; ഉപയോക്താവിന്റെ കാഴ്ചപ്പാടിൽ സൈറ്റ് ഇപ്പോഴും ഒരു സിംഗിൾ എൻഡ്പോയിന്റ് (single endpoint) ആയി തന്നെ തോന്നും.

ഹൊറിസോണ്ടൽ സ്കെയിലിംഗ് പ്രതിരോധശേഷിയും (resilience) നൽകുന്നു. ഒരു നോഡ് (node) ക്രാഷ് ആയാൽ, ബാലൻസർ ബാക്കിയുള്ള പ്രവർത്തനക്ഷമമായ നോഡുകളിലേക്ക് ട്രാഫിക് റൂട്ട് ചെയ്യുന്നു, അങ്ങനെ സർവീസ് തടസ്സമില്ലാതെ മുന്നോട്ട് കൊണ്ടുപോകുന്നു.

മെഷീനുകൾ ചേർക്കാൻ തുടങ്ങുമ്പോൾ ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

  • സ്റ്റേറ്റ്‌ലെസ് ഡിസൈൻ (Stateless design) – റിക്വസ്റ്റുകൾ ഒരു പ്രത്യേക സെർവറിന്റെ മെമ്മറിയിൽ മാത്രം സൂക്ഷിച്ചിരിക്കുന്ന ഡാറ്റയെ ആശ്രയിച്ചാകരുത്; അല്ലാത്തപക്ഷം, ആവശ്യമായ വിവരങ്ങൾ ഇല്ലാത്ത മറ്റൊരു നോഡിലേക്ക് ഉപയോക്താവ് എത്തിപ്പെട്ടേക്കാം. ഷെയർഡ് കാഷെകളോ (shared caches) ഡാറ്റാബേസുകളോ ഉപയോഗിക്കുന്നത് ഇതിന് പരിഹാരമാണ്.
  • ഹെൽത്ത് ചെക്കുകൾ (Health checks) – പ്രവർത്തനരഹിതമായ ഒരു സെർവറിനെ വേഗത്തിൽ തിരിച്ചറിയാനും അതിലേക്ക് ട്രാഫിക് അയക്കുന്നത് നിർത്താനും ബാലൻസർക്ക് കഴിയണം.
  • ഓട്ടോ-സ്കെയിലിംഗ് പോളിസികൾ (Auto-scaling policies) – പല ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമുകളും നിശ്ചിത പരിധികൾ (CPU ഉപയോഗം, റിക്വസ്റ്റ് ലേറ്റൻസി) നിശ്ചയിക്കാൻ അനുവദിക്കുന്നു. ഇത് ആവശ്യാനുസരണം ഇൻസ്റ്റൻസുകൾ സ്വയമേവ തുടങ്ങാനോ നിർത്താനോ സഹായിക്കുകയും ചിലവ് നിയന്ത്രിക്കുകയും ചെയ്യുന്നു.

മറ്റൊരു വശം: വെർട്ടിക്കൽ സ്കെയിലിംഗ് ഇന്നും പ്രസക്തമാണ്

ചെറിയ ടീമുകൾക്കോ കുറഞ്ഞ ട്രാഫിക് ഉള്ള ആപ്പുകൾക്കോ, കരുത്തുറ്റ ഒരു സിംഗിൾ സെർവർ തന്നെ ഏറ്റവും ലളിതവും ചിലവ് കുറഞ്ഞതുമായ പരിഹാരമായിരിക്കാം. ട്രാഫിക് വർദ്ധനവ് മുൻകൂട്ടി അറിയാൻ കഴിയുന്നതാണെങ്കിൽ (ഉദാഹരണത്തിന് ഒരു നിശ്ചിത സമയത്തെ പ്രൊഡക്റ്റ് ലോഞ്ച്), പുതിയ ഇൻസ്റ്റൻസുകളുടെ ഒരു നിര തന്നെ സജ്ജീകരിക്കുന്നതിനേക്കാൾ ഒരു താൽക്കാലിക വെർട്ടിക്കൽ അപ്‌ഗ്രേഡ് കൂടുതൽ പ്രായോഗികമായിരിക്കും.

"വലിയൊരു മെഷീൻ" എന്ന തന്ത്രം പ്രതീക്ഷിച്ച ഫലം നൽകുന്നില്ല എന്ന് തിരിച്ചറിയുകയും, വിതരണ രീതിയിലേക്ക് (distribution) മാറാൻ പ്ലാൻ ചെയ്യുകയും ചെയ്യുക എന്നതാണ് പ്രധാനം.

ചുരുക്കത്തിൽ

ലോഞ്ചിന് ശേഷം സെർവറിന്റെ വേഗത കുറയുന്നത് സാധാരണയായി റിസോഴ്സ് കോണ്ടൻഷൻ (resource-contention) മൂലമാണ്, അല്ലാതെ കോഡിലെ പിഴവുകൾ (code defect) കൊണ്ടല്ല. CPU സൈക്കിളുകളും RAM സ്ലോട്ടുകളും പരിമിതമാണ്; ഒരേസമയം ധാരാളം റിക്വസ്റ്റുകൾ വരുമ്പോൾ അവ ക്യൂ (queue) ആകുകയും, ഇത് റെസ്പോൺസ് സമയം വർദ്ധിപ്പിക്കുകയും ചെയ്യുന്നു. വെർട്ടിക്കൽ സ്കെയിലിംഗ് (Vertical scaling) വഴി നിങ്ങൾക്ക് അല്പം കൂടി ശേഷി ലഭിക്കുമെങ്കിലും, അത് വൈകാതെ തന്നെ ഭൗതികവും സാമ്പത്തികവുമായ പരിമിതികളിൽ എത്തിച്ചേരും. ഹൊറിസോണ്ടൽ സ്കെയിലിംഗ് (Horizontal scaling)—അതായത് ഒരു ലോഡ് ബാലൻസറിന് (load balancer) പിന്നിൽ കൂടുതൽ ചെറിയ സെർവറുകൾ ചേർക്കുന്നത്—ട്രാഫിക് കൂടുമ്പോൾ കുറഞ്ഞ ചിലവിലും കൂടുതൽ കരുത്തുറ്റതുമായ ഒരു മാർഗ്ഗമാണ്. ക്യൂ നീളുന്നത് ശ്രദ്ധയിൽപ്പെട്ടാൽ തന്നെ, കുറച്ച് കോറുകൾ (cores) കൂടി കൂട്ടിയാൽ മതിയോ അതോ ലോഡ് പല മെഷീനുകളിലായി വിതരണം ചെയ്യേണ്ടതുണ്ടോ എന്ന് വിലയിരുത്തേണ്ട സമയമായിക്കഴിഞ്ഞു.

Source: dev.to article “Why Servers Slow Down – CPU, RAM and the hidden cost of every request.”