ડેવલપર્સ જુએ છે કે જ્યારે થોડા હજાર યુઝર્સ "go" પર ક્લિક કરે છે, ત્યારે તેમનું તાજેતરમાં લોન્ચ થયેલું એપ અટકી જાય છે, અને આ ધીમા પડવાનું કારણ ભાગ્યે જ કોડમાં રહેલી કોઈ બગ (bug) હોય છે – તે સર્વરના CPU અને RAM વચ્ચેની જગ્યા માટેની લડાઈ છે. આ અવરોધ (bottleneck) લાંબા પેજ લોડ્સ, ટાઈમ-આઉટ અથવા સીધા ક્રેશ તરીકે દેખાય છે, અને તે યુઝર એક્સપિરિયન્સ, આવક અને બ્રાન્ડ પરના વિશ્વાસને નુકસાન પહોંચાડે છે.

શા માટે લેબમાં બરાબર ચાલતું સર્વર પ્રોડક્શનમાં અટકી શકે છે

ડેવલપમેન્ટ દરમિયાન એક સિંગલ ડેવલપર માત્ર થોડીક વિનંતીઓ (requests) મોકલે છે, તેથી સર્વરના રિસોર્સિસ મોટાભાગનો સમય નિષ્ક્રિય રહે છે. જ્યારે એપ લાઈવ જાય છે, ત્યારે દરેક વિઝિટર એક એવી વિનંતી જનરેટ કરે છે જેને બે મુખ્ય ઘટકોની જરૂર હોય છે:

  • 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) – દરેક વધારાના કોર અથવા ગીગાબાઇટનો ખર્ચ અગાઉના કરતા વધુ હોય છે, જ્યારે પરફોર્મન્સમાં થતો વધારો ઘટતો જાય છે.
  • સિંગલ પોઈન્ટ ઓફ ફેઈલ્યોર (Single point of failure) – જો તે વિશાળ સર્વર ડાઉન થઈ જાય, તો આખી સર્વિસ બંધ થઈ જાય છે.

આ મર્યાદાઓને કારણે, ઉદ્યોગના દિગ્ગજો – સ્ટ્રીમિંગ પ્લેટફોર્મ્સ, સર્ચ એન્જિન, ઈ-કોમર્સ સાઇટ્સ – એક વિશાળ મશીનથી દૂર ખસી ગયા છે.

વિકલ્પ: ઘણા નાના બોક્સમાં લોડ વહેંચવો

ઊંચો ટાવર બનાવવાને બદલે, ઓપરેટર્સ મધ્યમ કદના વધુ સર્વર્સ ઉમેરે છે અને તેમને ટ્રાફિક વહેંચવા દે છે. આ હોરિઝોન્ટલ સ્કેલિંગ (horizontal scaling) અભિગમ દરેક મશીનને યોગ્ય પરફોર્મન્સ રેન્જમાં રાખે છે અને વર્ટિકલ અપગ્રેડના વધતા જતા ખર્ચને ટાળે છે.

ઘણા મશીનોનું સંકલન કરવા માટે લોડ બેલેન્સર (load balancer) ની જરૂર પડે છે – એક સોફ્ટવેર અથવા હાર્ડવેર જે દરેક આવતી વિનંતી મેળવે છે અને તેને સૌથી વધુ ઉપલબ્ધ ક્ષમતા ધરાવતા સર્વર પર મોકલે છે. બેલેન્સર ક્લાયન્ટથી જટિલતા છુપાવે છે; યુઝરના દ્રષ્ટિકોણથી સાઇટ હજુ પણ એક સિંગલ એન્ડપોઈન્ટ (single endpoint) જેવી જ દેખાય છે.

હોરિઝોન્ટલ સ્કેલિંગ સ્થિતિસ્થાપકતા (resilience) પણ લાવે છે. જો એક નોડ ક્રેશ થાય છે, તો બેલેન્સર ફક્ત બાકીના કાર્યરત નોડ્સ પર ટ્રાફિક મોકલે છે, જેનાથી સર્વિસ ચાલુ રહે છે.

જ્યારે તમે મશીનો ઉમેરવાનું શરૂ કરો ત્યારે શું ધ્યાન રાખવું

  • સ્ટેટલેસ ડિઝાઇન (Stateless design) – વિનંતીઓ માત્ર ચોક્કસ સર્વરની મેમરીમાં સંગ્રહિત ડેટા પર આધારિત ન હોવી જોઈએ; અન્યથા યુઝરને એવા નોડ પર મોકલી શકાય છે જેની પાસે જરૂરી સંદર્ભ (context) નથી. શેર કરેલા કેશ (caches) અથવા ડેટાબેઝનો ઉપયોગ આ સમસ્યાનો ઉકેલ લાવે છે.
  • હેલ્થ ચેક્સ (Health checks) – બેલેન્સર ખામીયુક્ત સર્વરને ઝડપથી શોધી શકવું જોઈએ અને તેને ટ્રાફિક મોકલવાનું બંધ કરવું જોઈએ.
  • ઓટો-સ્કેલિંગ પોલિસીઝ (Auto-scaling policies) – ઘણા ક્લાઉડ પ્લેટફોર્મ્સ તમને થ્રેશોલ્ડ (CPU વપરાશ, વિનંતી લેટન્સી) વ્યાખ્યાયિત કરવા દે છે જે આપમેળે ઇન્સ્ટન્સ શરૂ કરે છે અથવા બંધ કરે છે, જેનાથી ખર્ચ માંગ મુજબ જ રહે છે.

વિરોધ પક્ષ: વર્ટિકલ સ્કેલિંગ મરી ગયું નથી

નાની ટીમો અથવા ઓછા ટ્રાફિક ધરાવતી એપ્સ માટે, એક શક્તિશાળી સર્વર સૌથી સરળ અને સસ્તો ઉકેલ હોઈ શકે છે. જો ટ્રાફિકમાં વધારો અનુમાનિત હોય (દા.ત. શેડ્યુલ કરેલ પ્રોડક્ટ લોન્ચ), તો નવા ઇન્સ્ટન્સનો આખો ફ્લીટ તૈયાર કરવા કરતાં કામચલાઉ વર્ટિકલ અપગ્રેડ વધુ વ્યવહારુ હોઈ શકે છે.

મુખ્ય વાત એ છે કે જ્યારે "મોટું બોક્સ" વાળી યુક્તિ પ્રમાણસર મૂલ્ય આપવાનું બંધ કરે ત્યારે તેને ઓળખવી અને વિતરણ (distribution) માટે આયોજન શરૂ કરવું.

મુખ્ય વાત

લોન્ચ પછી સર્વરની ગતિ ધીમી પડવી એ સામાન્ય રીતે રિસોર્સ-કન્ટેન્શન (resource-contention) ની સમસ્યા છે, કોડની ખામી નથી. CPU સાયકલ અને RAM સ્લોટ્સ મર્યાદિત છે, અને જ્યારે ઘણા બધા રિક્વેસ્ટ એકસાથે આવે છે ત્યારે તેઓ કતારમાં (queue) લાગે છે, જેનાથી પ્રતિસાદનો સમય (response time) વધી જાય છે. વર્ટિકલ સ્કેલિંગ (Vertical scaling) તમને થોડી વધુ ક્ષમતા આપે છે પરંતુ તે ટૂંક સમયમાં ભૌતિક અને આર્થિક મર્યાદાઓનો સામનો કરે છે. હોરિઝોન્ટલ સ્કેલિંગ—લોડ બેલેન્સરની પાછળ વધુ સામાન્ય સર્વર્સ ઉમેરવા—ટ્રાફિક વધવાની સાથે સસ્તો અને વધુ સ્થિતિસ્થાપક માર્ગ પૂરો પાડે છે. જે ક્ષણે તમે કતાર લાંબી થતી જુઓ, ત્યારે એ મૂલ્યાંકન કરવાનો સમય આવી જાય છે કે થોડા વધુ કોર્સ (cores) પૂરતા રહેશે કે તમારે લોડને ઘણા મશીનો પર ફેલાવવાનું શરૂ કરવું જોઈએ.

સ્ત્રોત: dev.to લેખ “Why Servers Slow Down – CPU, RAM and the hidden cost of every request.”