డెవలపర్లు తమ కొత్తగా లాంచ్ చేసిన యాప్ కొన్ని వేల మంది యూజర్లు “go” క్లిక్ చేయగానే ఆగిపోవడాన్ని చూస్తుంటారు. ఈ నెమ్మదించడం అనేది కోడ్‌లో ఉండే బగ్ వల్ల కాదు – ఇది సర్వర్ యొక్క CPU మరియు RAM కోసం జరిగే పోరాటం. ఈ సమస్య వల్ల పేజీ లోడ్ అవ్వడం ఆలస్యం కావడం, టైమ్-అవుట్లు లేదా యాప్ పూర్తిగా క్రాష్ అవ్వడం వంటివి జరుగుతాయి. ఇది యూజర్ ఎక్స్‌పీరియన్స్, రెవెన్యూ మరియు బ్రాండ్ నమ్మకాన్ని దెబ్బతీస్తుంది.

ల్యాబ్‌లో బాగా పనిచేసిన సర్వర్ ప్రొడక్షన్‌లో ఎందుకు ఆగిపోతుంది?

డెవలప్‌మెంట్ సమయంలో ఒకే ఒక్క డెవలపర్ కొన్ని రిక్వెస్ట్‌లను మాత్రమే పంపుతారు, కాబట్టి సర్వర్ వనరులు (resources) ఎక్కువ సమయం ఖాళీగానే ఉంటాయి. యాప్ లైవ్ అయినప్పుడు, ప్రతి విజిటర్ ఒక రిక్వెస్ట్‌ను పంపుతారు, దీనికి రెండు ముఖ్యమైన అంశాలు అవసరం:

  • CPU (central processing unit) – ప్రతి లూప్, ఫంక్షన్ మరియు కాలిక్యులేషన్‌ను నడిపించే ప్రాసెసర్. దీనిని ఒకేసారి పరిమిత సంఖ్యలో వంటకాలు మాత్రమే తయారు చేయగల వంటవాడితో పోల్చవచ్చు. ఒక ఆర్డర్ అయితే వెంటనే వస్తుంది; వంద ఆర్డర్లు వస్తే, వంటవాడు అదే వేగంతో పనిచేస్తాడు కానీ కస్టమర్లు ఎక్కువ సేపు వేచి ఉండాల్సి వస్తుంది.
  • RAM (random-access memory) – ఒక రిక్వెస్ట్‌ను హ్యాండిల్ చేసేటప్పుడు CPUకి అవసరమైన డేటా కోసం ఉపయోగించే తాత్కాలిక స్టోరేజ్. ఇది వంటవాడు ప్రతి వంటకం కోసం పదార్థాలను ఉంచుకునే డెస్క్ లాంటిది. డెస్క్ నిండిపోతే, ఖాళీ అయ్యే వరకు వంటవాడు కొత్త ఆర్డర్లు తీసుకోవడం ఆపేయాలి.

వేలాది మంది యూజర్లు ఒకేసారి లాగిన్ అయినప్పుడు, ప్రతి రిక్వెస్ట్ కొంత CPU సమయాన్ని మరియు కొంత RAM ని ఆక్రమిస్తుంది. సర్వర్‌లోని పరిమిత వనరులు రిక్వెస్ట్‌ల మధ్య విభజించబడతాయి, దీనివల్ల క్యూ (queue) పెరుగుతుంది. సర్వర్ నెమ్మదించలేదు; ప్రతి రిక్వెస్ట్ కోసం వేచి ఉండే సమయం పెరిగింది.

"కేవలం పెద్ద మెషిన్ కొంటే సరిపోతుంది" అనే ఆశ

దీనికి సాధారణంగా ఇచ్చే మొదటి స్పందన ఏమిటంటే మెషిన్‌ను అప్‌గ్రేడ్ చేయడం – దీనినే vertical scaling అంటారు. ఎక్కువ CPU కోర్లు లేదా ఎక్కువ RAM జోడించడం వల్ల సామర్థ్యం పెరుగుతుంది: కోడ్‌ను మార్చకుండానే 4 కోర్ల నుండి 16 కోర్లకు లేదా 8 GB నుండి 64 GBకి మారడం ద్వారా ట్రాఫిక్‌ను తట్టుకోవచ్చు.

అయితే, vertical scaling కి కొన్ని పరిమితులు ఉన్నాయి:

  • Physical limits – ప్రతి మదర్‌బోర్డ్ ఒక నిర్దిష్ట సంఖ్యలో కోర్లను మరియు పరిమిత మెమరీని మాత్రమే కలిగి ఉండగలదు.
  • Diminishing returns – ప్రతి అదనపు కోర్ లేదా గిగాబైట్ ధర మునుపటి దానికంటే ఎక్కువగా ఉంటుంది, కానీ పనితీరులో వచ్చే మెరుగుదల తగ్గుతూ వస్తుంది.
  • Single point of failure – ఒకవేళ ఆ పెద్ద సర్వర్ డౌన్ అయితే, మొత్తం సర్వీస్ ఆగిపోతుంది.

ఈ పరిమితుల వల్ల, స్ట్రీమింగ్ ప్లాట్‌ఫారమ్‌లు, సెర్చ్ ఇంజన్‌లు, ఈ-కామర్స్ సైట్‌ల వంటి పరిశ్రమలోని దిగ్గజాలు ఒకే పెద్ద మెషిన్‌పై ఆధారపడటం మానేశాయి.

ప్రత్యామ్నాయం: లోడ్‌ను అనేక చిన్న మెషిన్‌ల మధ్య పంచడం

ఒక పెద్ద టవర్‌ను నిర్మించే బదులు, ఆపరేటర్లు మధ్యస్థ పరిమాణంలో ఉన్న మరిన్ని సర్వర్‌లను జోడించి, ట్రాఫిక్‌ను వాటి మధ్య పంచుతారు. ఈ horizontal scaling విధానం ప్రతి మెషిన్‌ను సౌకర్యవంతమైన పనితీరు పరిధిలో ఉంచుతుంది మరియు vertical upgrades వల్ల వచ్చే విపరీతమైన ఖర్చులను నివారిస్తుంది.

అనేక మెషిన్‌లను సమన్వయం చేయడానికి ఒక load balancer అవసరం – ఇది ప్రతి రిక్వెస్ట్‌ను స్వీకరించి, అత్యధిక సామర్థ్యం ఉన్న సర్వర్‌కు పంపే సాఫ్ట్‌వేర్ లేదా హార్డ్‌వేర్. బ్యాలెన్సర్ క్లయింట్ నుండి సంక్లిష్టతను దాచిపెడుతుంది; యూజర్ దృష్టిలో సైట్ ఇంకా ఒకే ఎండ్‌పాయింట్‌లా కనిపిస్తుంది.

Horizontal scaling వల్ల స్థితిస్థాపకత (resilience) కూడా లభిస్తుంది. ఒకవేళ ఒక నోడ్ క్రాష్ అయితే, బ్యాలెన్సర్ మిగిలిన ఆరోగ్యకరమైన నోడ్‌లకు ట్రాఫిక్‌ను మళ్లిస్తుంది, తద్వారా సర్వీస్ నిరంతరాయంగా కొనసాగుతుంది.

మీరు మెషిన్‌లను జోడించడం ప్రారంభించినప్పుడు గమనించవలసినవి

  • Stateless design – రిక్వెస్ట్‌లు కేవలం ఒక నిర్దిష్ట సర్వర్ మెమరీలో నిల్వ చేయబడిన డేటాపై ఆధారపడకూడదు; లేకపోతే యూజర్ అవసరమైన డేటా లేని నోడ్‌కు వెళ్లాల్సి రావచ్చు. షేర్డ్ క్యాచెస్ (shared caches) లేదా డేటాబేస్‌లను ఉపయోగించడం దీనికి పరిష్కారం.
  • Health checks – బ్యాలెన్సర్ వైఫల్యం చెందుతున్న సర్వర్‌ను త్వరగా గుర్తించి, దానికి ట్రాఫిక్‌ను పంపడం ఆపివేయగలగాలి.
  • Auto-scaling policies – అనేక క్లౌడ్ ప్లాట్‌ఫారమ్‌లు మీరు కొన్ని పరిమితులను (CPU వినియోగం, రిక్వెస్ట్ లాటెన్సీ) నిర్వచించడానికి అనుమతిస్తాయి, ఇవి డిమాండ్‌కు అనుగుణంగా ఆటోమేటిక్‌గా ఇన్‌స్టెన్స్‌లను ప్రారంభించడం లేదా నిలిపివేయడం చేస్తాయి, తద్వారా ఖర్చులను నియంత్రించవచ్చు.

ఎదురు పాయింట్: vertical scaling ఇంకా అంతరించిపోలేదు

చిన్న టీమ్‌లు లేదా తక్కువ ట్రాఫిక్ ఉన్న యాప్‌ల కోసం, ఒకే శక్తివంతమైన సర్వర్ సరళమైన మరియు చౌకైన పరిష్కారం కావచ్చు. ట్రాఫిక్ పెరుగుదల ముందే ఊహించగలిగేది అయితే (ఉదాహరణకు, షెడ్యూల్ చేసిన ప్రొడక్ట్ లాంచ్), కొత్త ఇన్‌స్టెన్స్‌ల సమూహాన్ని ఏర్పాటు చేయడం కంటే తాత్కాలికంగా vertical upgrade చేయడం మరింత ఆచరణాత్మకం కావచ్చు.

"పెద్ద మెషిన్" పద్ధతి ఎప్పుడు తగిన విలువను ఇవ్వడం ఆగిపోతుందో గుర్తించి, డిస్ట్రిబ్యూషన్ (distribution) కోసం ప్రణాళిక సిద్ధం చేసుకోవడమే కీలకం.

ముగింపు

లాంచ్ చేసిన తర్వాత సర్వర్ నెమ్మదించడం అనేది సాధారణంగా రిసోర్స్-కంటెన్షన్ (resource-contention) సమస్య, కోడ్ లోపం కాదు. CPU సైకిల్స్ మరియు RAM స్లాట్లు పరిమితమైనవి, మరియు అనేక రిక్వెస్ట్‌లు ఒకేసారి వచ్చినప్పుడు అవి క్యూ (queue) అవుతాయి, దీనివల్ల రెస్పాన్స్ టైమ్ పెరుగుతుంది. వర్టికల్ స్కేలింగ్ (Vertical scaling) మీకు కొంత అదనపు సామర్థ్యాన్ని ఇస్తుంది కానీ త్వరలోనే భౌతిక మరియు ఆర్థిక పరిమితులను ఎదుర్కొంటుంది. హారిజాంటల్ స్కేలింగ్ (Horizontal scaling)—అంటే లోడ్ బ్యాలెన్సర్ వెనుక మరిన్ని సాధారణ సర్వర్‌లను జోడించడం—ట్రాఫిక్ పెరిగే కొద్దీ తక్కువ ఖర్చుతో కూడిన మరియు మరింత స్థితిస్థాపకత (resilient) కలిగిన మార్గాన్ని అందిస్తుంది. క్యూ పెరుగుతున్నట్లు మీరు గమనించిన వెంటనే, మరికొన్ని కోర్లు (cores) సరిపోతాయా లేదా లోడ్‌ను అనేక యంత్రాల (machines) మధ్య పంచడం ప్రారంభించాలా అనేది అంచనా వేయాల్సిన సమయం వచ్చినట్లు అర్థం.

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