டெவலப்பர்கள் தங்களின் புதிதாகத் தொடங்கப்பட்ட ஆப் (app), சில ஆயிரம் பயனர்கள் பயன்படுத்தத் தொடங்கியவுடன் முடங்குவதைக் காண்கிறார்கள். இந்தத் தாமதம் என்பது அரிதாகவே குறியீட்டில் (code) உள்ள பிழையாக இருக்கும் – உண்மையில் இது சர்வரின் CPU மற்றும் RAM இடத்திற்காகப் போராடுவதால் ஏற்படுகிறது. இந்தத் தடை (bottleneck), பக்கங்கள் தாமதமாகத் திறப்பது, டைம்-அவுட் (time-outs) அல்லது ஆப் முழுமையாக முடங்குவது போன்ற வடிவங்களில் வெளிப்படும்; இது பயனரின் அனுபவம், வருவாய் மற்றும் பிராண்ட் மீதான நம்பிக்கையைப் பாதிக்கிறது.

ஆய்வகத்தில் (lab) நன்றாக இயங்கிய ஒரு சர்வர், நேரடிப் பயன்பாட்டில் (production) ஏன் முடங்கிப் போகிறது?

மேம்படுத்தும் (development) போது, ஒரு டெவலப்பர் மட்டுமே சில கோரிக்கைகளை (requests) அனுப்புவதால், சர்வரின் வளங்கள் (resources) பெரும்பாலான நேரங்களில் பயன்படுத்தப்படாமல் அப்படியே இருக்கும். ஆப் நேரடிப் பயன்பாட்டிற்கு வரும்போது, ஒவ்வொரு பார்வையாளரும் ஒரு கோரிக்கையை உருவாக்குகிறார்கள், அதற்கு இரண்டு முக்கியக் கூறுகள் தேவைப்படுகின்றன:

  • CPU (central processing unit) – ஒவ்வொரு லூப் (loop), செயல்பாடு (function) மற்றும் கணக்கீட்டையும் இயக்கும் செயலி. இதை ஒரே நேரத்தில் ஒரு குறிப்பிட்ட எண்ணிக்கையிலான உணவுகளை மட்டுமே தயாரிக்கக்கூடிய ஒரு சமையல்காரராகக் கருதலாம். ஒரு ஆர்டர் உடனடியாகத் தயாராகிவிடும்; ஆனால் நூறு ஆர்டர்கள் வரும்போது, சமையல்காரர் அதே வேகத்தில் வேலை செய்தாலும், உணவருந்த வருபவர்கள் நீண்ட நேரம் காத்திருக்க வேண்டியிருக்கும்.
  • RAM (random-access memory) – ஒரு கோரிக்கையை கையாளும் போது CPU-க்குத் தேவையான தரவுகளுக்கான தற்காலிக சேமிப்பு. இது சமையல்காரர் ஒவ்வொரு உணவிற்கும் தேவையான பொருட்களை வைக்கும் மேஜையைப் போன்றது. மேஜை நிரம்பிவிட்டால், இடம் கிடைக்கும் வரை சமையல்காரர் புதிய ஆர்டர்களைப் பெறுவதை நிறுத்த வேண்டியிருக்கும்.

ஆயிரக்கணக்கான பயனர்கள் ஒரே நேரத்தில் லாக்-இன் (log in) செய்யும்போது, ஒவ்வொரு கோரிக்கையும் தனக்கென ஒரு குறிப்பிட்ட CPU நேரத்தையும், RAM அளவையும் கோருகிறது. சர்வரின் வரையறுக்கப்பட்ட வளங்கள் கோரிக்கைகளுக்கு இடையே பிரிக்கப்படுவதால், வரிசை (queue) நீடிக்கிறது. சர்வர் மெதுவானதாக மாறவில்லை; ஒவ்வொரு கோரிக்கைக்கான காத்திருப்பு நேரம் அதிகரித்துள்ளது.

"பெரிய இயந்திரத்தை மட்டும் வாங்கிக்கொள்ளலாம்" என்ற தூண்டுதல்

ஒரு பொதுவான முதல் எதிர்வினை என்பது இயந்திரத்தை மேம்படுத்துவதாகும் – இது vertical scaling என்று அழைக்கப்படுகிறது. கூடுதல் CPU கோர்களை (cores) அல்லது கூடுதல் RAM-ஐச் சேர்ப்பது திறனை மேம்படுத்தும்: 4 கோர்களில் இருந்து 16 கோர்களுக்கோ அல்லது 8 GB-யிலிருந்து 64 GB-யிற்கோ மாறுவது, எந்தக் குறியீட்டையும் மாற்றாமல் அதிகப்படியான டிராஃபிக்கை (traffic) கையாள உதவும்.

இருப்பினும், vertical scaling ஒரு குறிப்பிட்ட எல்லையை எட்டிவிடும்:

  • இயற்பியல் வரம்புகள் (Physical limits) – ஒவ்வொரு மதர்போர்டும் (motherboard) ஒரு குறிப்பிட்ட எண்ணிக்கையிலான கோர்களையும், வரையறுக்கப்பட்ட அளவு நினைவகத்தையும் மட்டுமே கொண்டிருக்க முடியும்.
  • குறைந்து வரும் பலன்கள் (Diminishing returns) – ஒவ்வொரு கூடுதல் கோர் அல்லது கிகாபைட்டும் முந்தையதை விட அதிக விலை கொண்டதாக இருக்கும், அதே சமயம் அதன் செயல்திறன் அதிகரிப்பு குறைந்து கொண்டே வரும்.
  • ஒற்றைப் புள்ளித் தோல்வி (Single point of failure) – ஒருவேளை அந்தப் பெரிய சர்வர் செயலிழந்தால், முழுச் சேவையும் நின்றுவிடும்.

இந்தத் தடைகள் காரணமாக, ஸ்ட்ரீமிங் தளங்கள், தேடுபொறிகள் (search engines), இ-காமர்ஸ் தளங்கள் போன்ற துறையின் முன்னணி நிறுவனங்கள், ஒரு பெரிய இயந்திரத்தை மட்டும் சார்ந்திருப்பதைத் தவிர்த்துவிட்டன.

மாற்று வழி: சுமையைத் பல சிறிய இயந்திரங்களுக்குப் பிரித்து வழங்குதல்

ஒரு உயரமான கோபுரத்தைக் கட்டுவதற்குப் பதிலாக, இய ऑपरेटர்கள் மிதமான அளவுள்ள கூடுதல் சர்வர்களைச் சேர்த்து, டிராஃபிக்கைப் பகிர்ந்து கொள்ளச் செய்கிறார்கள். இந்த horizontal scaling அணுகுமுறை, ஒவ்வொரு இயந்திரத்தையும் அதன் சிறந்த செயல்திறன் வரம்பிற்குள் வைத்திருக்கிறது மற்றும் செங்குத்து மேம்பாடுகளின் (vertical upgrades) அதீத செலவைத் தவிர்க்கிறது.

பல இயந்திரங்களை ஒருங்கிணைக்க ஒரு load balancer தேவைப்படுகிறது – இது வரும் ஒவ்வொரு கோரிக்கையையும் பெற்று, அதிகத் திறன் கொண்ட சர்வருக்கு அனுப்பும் ஒரு மென்பொருள் அல்லது வன்பொருள் ஆகும். இந்த பேலன்சர் (balancer) சிக்கல்களைப் பயனரிடமிருந்து மறைத்துவிடுகிறது; பயனரின் பார்வையில் அந்தத் தளம் இன்னும் ஒரு ஒற்றைப் புள்ளியாகவே (single endpoint) தோன்றும்.

Horizontal scaling மீள்திறனையும் (resilience) வழங்குகிறது. ஒரு நோட் (node) செயலிழந்தால், பேலன்சர் டிராஃபிக்கை மற்ற ஆரோக்கியமான நோடுகளுக்குத் திருப்பி அனுப்பி, சேவையைத் தொடர்ந்து இயங்கச் செய்கிறது.

நீங்கள் இயந்திரங்களைச் சேர்க்கத் தொடங்கும்போது கவனிக்க வேண்டியவை

  • Stateless design – கோரிக்கைகள் ஒரு குறிப்பிட்ட சர்வரின் நினைவகத்தில் மட்டும் சேமிக்கப்பட்டுள்ள தரவைச் சார்ந்திருக்கக் கூடாது; இல்லையெனில், ஒரு பயனர் தேவையான தகவல்கள் இல்லாத மற்றொரு நோடிற்குத் திருப்பி விடப்படலாம். பகிர்ந்துகொள்ளப்பட்ட கேஷ்கள் (shared caches) அல்லது தரவுத்தளங்களைப் (databases) பயன்படுத்துவது இதற்குத் தீர்வாகும்.
  • Health checks – செயலிழக்கும் ஒரு சர்வரை பேலன்சர் விரைவாகக் கண்டறிந்து, அதற்கு டிராஃபிக்கை அனுப்புவதை நிறுத்த வேண்டும்.
  • Auto-scaling policies – பல கிளவுட் தளங்கள் (cloud platforms) சில வரம்புகளை (CPU பயன்பாடு, கோரிக்கை தாமதம் போன்றவை) வரையறுக்க அனுமதிக்கின்றன. இவை தேவைக்கேற்ப தானாகவே இன்ஸ்டன்ஸ்களை (instances) உருவாக்கவோ அல்லது நிறுத்தவோ செய்து, செலவைச் சரியாகப் பராமரிக்கின்றன.

மாற்றுக்கருத்து: vertical scaling இன்னும் முடிந்துவிடவில்லை

சிறிய குழுக்கள் அல்லது குறைந்த டிராஃபிக் கொண்ட ஆப்ஸ்களுக்கு, ஒரு வலுவூட்டப்பட்ட (beefed-up) சர்வரே எளிமையான மற்றும் மலிவான தீர்வாக இருக்கலாம். டிராஃபிக் அதிகரிப்பு முன்கூட்டியே கணிக்கக்கூடியதாக இருந்தால் (உதாரணமாக, திட்டமிடப்பட்ட தயாரிப்பு அறிமுகம்), புதிய இன்ஸ்டன்ஸ்களின் தொகுப்பை உருவாக்குவதை விட தற்காலிகமான vertical upgrade மிகவும் நடைமுறைக்கு ஏற்றதாக இருக்கலாம்.

"பெரிய இயந்திரம்" என்ற தந்திரம் எப்போது விகிதாச்சார மதிப்பைக் கொடுப்பதை நிறுத்துகிறது என்பதை உணர்ந்து, விநியோகிக்கப்பட்ட (distribution) கட்டமைப்பிற்காகத் திட்டமிடத் தொடங்குவதே முக்கியமாகும்.

முக்கியக் கருத்து (Takeaway)

தொடங்குவதற்குப் பிறகு சர்வர் வேகம் குறைவது என்பது பொதுவாக வளப் போட்டி (resource-contention) தொடர்பான பிரச்சினையே தவிர, குறியீடு (code) குறைபாடு அல்ல. CPU சுழற்சிகள் மற்றும் RAM இடங்கள் வரையறுக்கப்பட்டவை; எனவே, பல கோரிக்கைகள் (requests) ஒரே நேரத்தில் வரும்போது அவை வரிசையில் சேருகின்றன, இது பதிலளிக்கும் நேரத்தை (response times) நீட்டிக்கிறது. Vertical scaling உங்களுக்குச் சற்று கூடுதல் திறனை வழங்கினாலும், அது விரைவில் இயற்பியல் மற்றும் பொருளாதார வரம்புகளைச் சந்திக்கும். Horizontal scaling—அதாவது ஒரு load balancer-க்கு பின்னால் கூடுதல் சாதாரண சர்வர்களைச் சேர்ப்பது—போக்குவரத்து அதிகரிக்கும் போது மலிவான மற்றும் அதிக மீள்திறன் கொண்ட ஒரு பாதையை வழங்குகிறது. வரிசை நீளுவதை நீங்கள் கவனிக்கும் தருணமே, இன்னும் சில cores போதுமானதா அல்லது சுமையைத் பல இயந்திரங்களுக்குப் பரப்பத் தொடங்க வேண்டுமா என்பதை மதிப்பிடும் நேரம் வந்துவிட்டது.

ஆதாரம்: dev.to கட்டுரை “Why Servers Slow Down – CPU, RAM and the hidden cost of every request.”