ઘણા સ્ટાર્ટઅપ્સ આમાંથી પસાર થયા છે: નવા વપરાશકર્તાઓની ભીડ દરરોજ નોંધણી કરે છે, અને વિકાસ ટીમ સેવા ચાલુ રાખવા માટે સંઘર્ષ કરે છે.

તે એક સરસ સમસ્યા છે, પરંતુ વેબ એપ્લિકેશનને કેવી રીતે સાવધાનીપૂર્વક સેંકડોથી હજારો વપરાશકર્તાઓ સુધી સ્કેલ કરવી તે વિશે વેબ પર થોડી સ્પષ્ટ માહિતી છે. સામાન્ય રીતે ફાયર સોલ્યુશન્સ અથવા તો અડચણ ઉકેલો (અને ઘણીવાર બંને) હોય છે. તેથી, લોકો તેમના કલાપ્રેમી પ્રોજેક્ટને ખરેખર ગંભીર બાબતમાં સ્કેલ કરવા માટે બદલે ક્લિચ્ડ તકનીકોનો ઉપયોગ કરે છે.

ચાલો માહિતીને ફિલ્ટર કરવાનો પ્રયાસ કરીએ અને મૂળભૂત સૂત્ર લખીએ. અમે અમારી નવી ફોટો શેરિંગ સાઇટ ગ્રામિન્સ્ટાને 1 થી 100 વપરાશકર્તાઓ સુધી સ્ટેપ બાય સ્ટેપ સ્કેલ કરવા જઈ રહ્યા છીએ.

ચાલો લખીએ કે જ્યારે પ્રેક્ષકો 10, 100, 1000, 10 અને 000 લોકો સુધી વધે ત્યારે કઈ ચોક્કસ ક્રિયાઓ કરવાની જરૂર છે.

1 વપરાશકર્તા: 1 મશીન

લગભગ દરેક એપ્લિકેશન, તે વેબસાઇટ હોય કે મોબાઇલ એપ્લિકેશન, ત્રણ મુખ્ય ઘટકો ધરાવે છે:

• API
• ડેટાબેઝ
• ક્લાયંટ (મોબાઇલ એપ્લિકેશન પોતે અથવા વેબસાઇટ)

ડેટાબેઝ સતત ડેટા સ્ટોર કરે છે. API આ ડેટાની અને તેની આસપાસની વિનંતીઓ આપે છે. ક્લાયંટ વપરાશકર્તાને ડેટા ટ્રાન્સમિટ કરે છે.

હું નિષ્કર્ષ પર આવ્યો છું કે જો આર્કિટેક્ચરલ દૃષ્ટિકોણથી, ક્લાયંટ અને API એન્ટિટીને સંપૂર્ણપણે અલગ કરવામાં આવે તો એપ્લિકેશનને માપવા વિશે વાત કરવી ખૂબ સરળ છે.

જ્યારે આપણે સૌ પ્રથમ એપ્લિકેશન બનાવવાનું શરૂ કરીએ છીએ, ત્યારે ત્રણેય ઘટકો એક જ સર્વર પર ચલાવી શકાય છે. કેટલીક રીતે, આ આપણા વિકાસ વાતાવરણ જેવું જ છે: એક એન્જિનિયર ડેટાબેઝ, API અને ક્લાયંટને સમાન મશીન પર ચલાવે છે.

સિદ્ધાંતમાં, અમે તેને એક ડિજિટલ ઓશન ડ્રોપલેટ અથવા AWS EC2 ઉદાહરણ પર ક્લાઉડમાં જમાવી શકીએ છીએ, નીચે બતાવ્યા પ્રમાણે:

તે સાથે જણાવ્યું હતું કે, જો કોઈ સાઇટ પર એક કરતાં વધુ વપરાશકર્તા હશે, તો તે હંમેશા ડેટાબેઝ સ્તરને સમર્પિત કરવા માટે અર્થપૂર્ણ બને છે.

10 વપરાશકર્તાઓ: ડેટાબેઝને અલગ સ્તર પર ખસેડવું

ડેટાબેઝને એમેઝોન આરડીએસ અથવા ડિજિટલ ઓશન મેનેજ્ડ ડેટાબેઝ જેવી વ્યવસ્થાપિત સેવાઓમાં વિભાજીત કરવાથી અમને લાંબા સમય સુધી સારી રીતે સેવા મળશે. તે એક મશીન અથવા EC2 ઉદાહરણ પર સ્વ-હોસ્ટિંગ કરતાં થોડું વધુ ખર્ચાળ છે, પરંતુ આ સેવાઓ સાથે તમને બૉક્સની બહાર ઘણા બધા ઉપયોગી એક્સ્ટેન્શન્સ મળે છે જે ભવિષ્યમાં કામમાં આવશે: મલ્ટિ-રિજન બેકઅપ, પ્રતિકૃતિઓ વાંચો, સ્વચાલિત બેકઅપ, અને વધુ.

આ સિસ્ટમ હવે જેવો દેખાય છે:

100 વપરાશકર્તાઓ: ક્લાયંટને અલગ સ્તર પર ખસેડવું

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

આ કારણે હું ક્લાયન્ટને API થી અલગ તરીકે વિચારવાનું પસંદ કરું છું. આ બહુવિધ પ્લેટફોર્મ માટે વિકાસ કરવા વિશે વિચારવાનું ખૂબ જ સરળ બનાવે છે: વેબ, મોબાઇલ વેબ, iOS, Android, ડેસ્કટોપ એપ્લિકેશન્સ, તૃતીય-પક્ષ સેવાઓ, વગેરે. તે બધા એક જ API નો ઉપયોગ કરતા ક્લાયન્ટ્સ છે.

ઉદાહરણ તરીકે, હવે અમારા વપરાશકર્તાઓ મોટાભાગે મોબાઇલ એપ્લિકેશન રિલીઝ કરવાનું કહે છે. જો તમે ક્લાયંટ અને API એકમોને અલગ કરો છો, તો આ સરળ બને છે.

આવી સિસ્ટમ આના જેવી દેખાય છે:

1000 વપરાશકર્તાઓ: લોડ બેલેન્સર ઉમેરો

વસ્તુઓ જોઈ રહી છે. ગ્રામિન્સ્ટા યુઝર્સ વધુ ને વધુ ફોટા અપલોડ કરી રહ્યા છે. નોંધણીની સંખ્યા પણ વધી રહી છે. અમારા એકલા API સર્વરને તમામ ટ્રાફિકને જાળવી રાખવામાં મુશ્કેલ સમય આવી રહ્યો છે. વધુ આયર્નની જરૂર છે!

લોડ બેલેન્સર એ ખૂબ જ શક્તિશાળી કોન્સેપ્ટ છે. મુખ્ય વિચાર એ છે કે અમે API ની સામે લોડ બેલેન્સર મૂકીએ છીએ, અને તે વ્યક્તિગત સેવાના દાખલાઓ પર ટ્રાફિકનું વિતરણ કરે છે. આ રીતે આપણે આડા સ્કેલ કરીએ છીએ, એટલે કે અમે સમાન કોડ સાથે વધુ સર્વર્સ ઉમેરીએ છીએ, અમે પ્રક્રિયા કરી શકીએ તેવી વિનંતીઓની સંખ્યા વધારીએ છીએ.

અમે વેબ ક્લાયન્ટની સામે અને API ની સામે અલગ લોડ બેલેન્સર મૂકવા જઈ રહ્યા છીએ. આનો અર્થ એ છે કે તમે API કોડ અને વેબ ક્લાયંટ કોડ ચલાવતા બહુવિધ ઉદાહરણો ચલાવી શકો છો. લોડ બેલેન્સર તે સર્વર પર વિનંતીઓ મોકલશે જે ઓછા લોડ થયેલ છે.

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

લોડ બેલેન્સર આપોઆપ સ્કેલિંગ પણ પ્રદાન કરે છે. પીક લોડ પહેલા દાખલાઓની સંખ્યા વધારવા માટે અમે તેને ગોઠવી શકીએ છીએ અને જ્યારે બધા વપરાશકર્તાઓ સૂતા હોય ત્યારે તેને ઘટાડી શકીએ છીએ.

લોડ બેલેન્સર સાથે, API સ્તરને લગભગ અનિશ્ચિત સમય માટે માપી શકાય છે, ફક્ત વિનંતીઓની સંખ્યામાં વધારો થતાં નવા દાખલાઓ ઉમેરીને.

નૉૅધ. અત્યારે અમારી સિસ્ટમ AWS પર Heroku અથવા Elastic Beanstalk જેવી PaaS કંપનીઓ જે ઑફર કરે છે તેના જેવી જ છે (જેના કારણે તેઓ ખૂબ લોકપ્રિય છે). Heroku ડેટાબેઝને અલગ હોસ્ટ પર મૂકે છે, ઓટો-સ્કેલિંગ લોડ બેલેન્સરનું સંચાલન કરે છે, અને તમને API થી અલગથી વેબ ક્લાયંટને હોસ્ટ કરવાની મંજૂરી આપે છે. પ્રારંભિક તબક્કાના પ્રોજેક્ટ્સ અથવા સ્ટાર્ટઅપ્સ માટે Heroku નો ઉપયોગ કરવાનું આ એક સરસ કારણ છે - તમને બધી મૂળભૂત સેવાઓ બોક્સની બહાર મળે છે.

10 વપરાશકર્તાઓ: CDN

કદાચ આપણે આ શરૂઆતથી જ કરવું જોઈએ. વિનંતીઓ પર પ્રક્રિયા કરવી અને નવા ફોટા સ્વીકારવાથી અમારા સર્વર્સ પર વધુ પડતો તાણ આવવા લાગે છે.

આ તબક્કે, તમારે સ્થિર સામગ્રી - છબીઓ, વિડિઓઝ અને ઘણું બધું (AWS S3 અથવા Digital Ocean Spaces) સ્ટોર કરવા માટે ક્લાઉડ સેવાનો ઉપયોગ કરવાની જરૂર છે. સામાન્ય રીતે, અમારા API એ છબીઓ સર્વ કરવા અને સર્વર પર છબીઓ અપલોડ કરવા જેવી વસ્તુઓને હેન્ડલ કરવાનું ટાળવું જોઈએ.

ક્લાઉડ હોસ્ટિંગનો બીજો ફાયદો CDN છે (AWS આ ઍડ-ઑનને ક્લાઉડફ્રન્ટ કહે છે, પરંતુ ઘણા ક્લાઉડ સ્ટોરેજ પ્રદાતાઓ તેને બૉક્સની બહાર ઑફર કરે છે). CDN વિશ્વભરના વિવિધ ડેટા કેન્દ્રોમાં આપમેળે અમારી છબીઓને કેશ કરે છે.

જો કે અમારું મુખ્ય ડેટા સેન્ટર ઓહિયોમાં સ્થિત હોઈ શકે છે, જો કોઈ વ્યક્તિ જાપાનથી છબીની વિનંતી કરે છે, તો ક્લાઉડ પ્રદાતા તેની નકલ કરશે અને તેને તેમના જાપાનીઝ ડેટા સેન્ટરમાં સંગ્રહિત કરશે. જાપાનમાં આ છબીની વિનંતી કરનાર આગલી વ્યક્તિ તેને વધુ ઝડપથી પ્રાપ્ત કરશે. જ્યારે આપણે મોટી ફાઇલો સાથે કામ કરીએ છીએ, જેમ કે ફોટા અથવા વિડિયો, જે ડાઉનલોડ કરવા અને સમગ્ર ગ્રહ પર ટ્રાન્સમિટ કરવામાં લાંબો સમય લે છે ત્યારે આ મહત્વપૂર્ણ છે.

100 વપરાશકર્તાઓ: ડેટા લેયરને સ્કેલ કરી રહ્યાં છે

CDN એ ઘણી મદદ કરી છે: ટ્રાફિક સંપૂર્ણ ઝડપે વધી રહ્યો છે. પ્રખ્યાત વિડિઓ બ્લોગર મેવિડ મોબ્રિકે હમણાં જ અમારી સાથે નોંધણી કરાવી અને તેમની "વાર્તા" પોસ્ટ કરી, જેમ તેઓ કહે છે. લોડ બેલેન્સર માટે આભાર, API સર્વર્સ પર CPU અને મેમરીનો ઉપયોગ ઓછો રાખવામાં આવ્યો છે (દસ API દાખલાઓ ચાલી રહી છે), પરંતુ અમને વિનંતીઓ પર ઘણો સમય સમાપ્ત થવા લાગ્યો છે... આ વિલંબ ક્યાંથી આવે છે?

મેટ્રિક્સમાં થોડું ખોદવું, આપણે જોઈએ છીએ કે ડેટાબેઝ સર્વર પર સીપીયુ 80-90% લોડ થયેલ છે. અમે મર્યાદા પર છીએ.

ડેટા લેયરને સ્કેલિંગ કરવું એ કદાચ સમીકરણનો સૌથી મુશ્કેલ ભાગ છે. API સર્વર્સ સ્ટેટલેસ વિનંતીઓ આપે છે, તેથી અમે ફક્ત વધુ API દાખલાઓ ઉમેરીએ છીએ. નાક બહુમત ડેટાબેઝ આ કરી શકતા નથી. અમે લોકપ્રિય રિલેશનલ ડેટાબેઝ મેનેજમેન્ટ સિસ્ટમ્સ (PostgreSQL, MySQL, વગેરે) વિશે વાત કરીશું.

કેશીંગ

અમારા ડેટાબેઝની કામગીરીને વધારવાની સૌથી સરળ રીતોમાંની એક એ છે કે એક નવો ઘટક રજૂ કરવો: કેશ લેયર. સૌથી સામાન્ય કેશીંગ પદ્ધતિ એ ઇન-મેમરી કી-વેલ્યુ રેકોર્ડ સ્ટોર છે, જેમ કે Redis અથવા Memcached. મોટાભાગના ક્લાઉડ્સમાં આ સેવાઓનું મેનેજ્ડ વર્ઝન હોય છે: AWS પર સ્થિતિસ્થાપકતા અને Google Cloud પર Memorystore.

એક કેશ ઉપયોગી છે જ્યારે સેવા સમાન માહિતી પુનઃપ્રાપ્ત કરવા માટે ડેટાબેઝ પર ઘણા પુનરાવર્તિત કોલ્સ કરે છે. અનિવાર્યપણે, અમે ડેટાબેઝને માત્ર એક જ વાર ઍક્સેસ કરીએ છીએ, માહિતીને કેશમાં સંગ્રહિત કરીએ છીએ અને તેને ફરીથી સ્પર્શ કરતા નથી.

ઉદાહરણ તરીકે, અમારી ગ્રામિન્સ્ટા સેવામાં, જ્યારે પણ કોઈ વ્યક્તિ સ્ટાર મોબ્રિકના પ્રોફાઇલ પેજ પર જાય છે, ત્યારે API સર્વર તેની પ્રોફાઇલમાંથી માહિતી માટે ડેટાબેઝને પૂછે છે. આવું વારંવાર થાય છે. Mobrik ની પ્રોફાઇલ માહિતી દરેક વિનંતી સાથે બદલાતી નથી, તે કેશીંગ માટે ઉત્તમ છે.

અમે કી દ્વારા રેડિસમાં ડેટાબેઝમાંથી પરિણામોને કેશ કરીશું user:id 30 સેકન્ડની માન્યતા અવધિ સાથે. હવે, જ્યારે કોઈ વ્યક્તિ Mobrik ની પ્રોફાઇલ પર જાય છે, ત્યારે અમે પહેલા Redis તપાસીએ છીએ, અને જો ડેટા ત્યાં હોય, તો અમે તેને સીધા Redisમાંથી ટ્રાન્સફર કરીએ છીએ. હવે સાઇટ પરની સૌથી લોકપ્રિય પ્રોફાઇલની વિનંતીઓ વ્યવહારીક રીતે અમારા ડેટાબેઝને લોડ કરતી નથી.

મોટાભાગની કેશીંગ સેવાઓનો બીજો ફાયદો એ છે કે તે ડેટાબેઝ સર્વર્સ કરતાં માપવામાં સરળ છે. રેડિસમાં બિલ્ટ-ઇન રેડિસ ક્લસ્ટર મોડ છે. લોડ બેલેન્સર જેવું જ1, તે તમને તમારી Redis કેશને બહુવિધ મશીનો પર વિતરિત કરવાની મંજૂરી આપે છે (જો જરૂરી હોય તો હજારો સર્વર્સમાં).

લગભગ તમામ મોટા પાયે એપ્લિકેશનો કેશીંગનો ઉપયોગ કરે છે; તે ઝડપી API નો સંપૂર્ણ અભિન્ન ભાગ છે. ઝડપી ક્વેરી પ્રોસેસિંગ અને વધુ ઉત્પાદક કોડ બધું જ મહત્વપૂર્ણ છે, પરંતુ કેશ વિના લાખો વપરાશકર્તાઓ માટે સેવાને સ્કેલ કરવી લગભગ અશક્ય છે.

પ્રતિકૃતિઓ વાંચો

જ્યારે ડેટાબેઝમાં ક્વેરીઝની સંખ્યામાં ઘણો વધારો થયો છે, ત્યારે આપણે વધુ એક વસ્તુ કરી શકીએ છીએ તે ડેટાબેઝ મેનેજમેન્ટ સિસ્ટમમાં રીડ પ્રતિકૃતિઓ ઉમેરવાનું છે. ઉપર વર્ણવેલ વ્યવસ્થાપિત સેવાઓ સાથે, આ એક ક્લિકમાં કરી શકાય છે. વાંચેલી પ્રતિકૃતિ મુખ્ય DBમાં વર્તમાન રહેશે અને SELECT સ્ટેટમેન્ટ માટે ઉપલબ્ધ છે.

અહીં હવે અમારી સિસ્ટમ છે:

આગળની ક્રિયાઓ

જેમ જેમ એપ્લિકેશન સ્કેલ કરવાનું ચાલુ રાખે છે, અમે સેવાઓને સ્વતંત્ર રીતે માપવા માટે અલગ કરવાનું ચાલુ રાખીશું. ઉદાહરણ તરીકે, જો આપણે વેબસોકેટ્સનો ઉપયોગ કરવાનું શરૂ કરીએ, તો વેબસોકેટ્સ પ્રોસેસિંગ કોડને અલગ સેવામાં ખેંચવાનો અર્થ છે. અમે તેને અમારા પોતાના લોડ બેલેન્સરની પાછળ નવા દાખલાઓ પર મૂકી શકીએ છીએ, જે ઓપન વેબસોકેટ્સ કનેક્શનના આધારે અને HTTP વિનંતીઓની સંખ્યાને ધ્યાનમાં લીધા વિના સ્કેલ અપ અને ડાઉન કરી શકે છે.

અમે ડેટાબેઝ સ્તરે પ્રતિબંધો સામે લડવાનું પણ ચાલુ રાખીશું. તે આ તબક્કે છે કે ડેટાબેઝ પાર્ટીશન અને શાર્ડિંગનો અભ્યાસ કરવાનો સમય છે. બંને અભિગમોને વધારાના ઓવરહેડની જરૂર છે, પરંતુ તમને ડેટાબેઝને લગભગ અનિશ્ચિત રૂપે સ્કેલ કરવાની મંજૂરી આપે છે.

અમે ન્યૂ રેલિક અથવા ડેટાડોગ જેવી મોનિટરિંગ અને એનાલિટિક્સ સેવા પણ ઇન્સ્ટોલ કરવા માંગીએ છીએ. આ તમને ધીમી ક્વેરી ઓળખવામાં અને ક્યાં સુધારાની જરૂર છે તે સમજવામાં મદદ કરશે. જેમ જેમ આપણે સ્કેલ કરીએ છીએ તેમ, અમે અડચણો શોધવા અને તેને દૂર કરવા પર ધ્યાન કેન્દ્રિત કરવા માંગીએ છીએ - ઘણીવાર અગાઉના વિભાગોના કેટલાક વિચારોનો ઉપયોગ કરીને.

સ્ત્રોતો

આ પોસ્ટ તેમાંથી એક દ્વારા પ્રેરિત છે ઉચ્ચ માપનીયતા વિશે મારી પ્રિય પોસ્ટ્સ. હું પ્રોજેક્ટના પ્રારંભિક તબક્કાઓ માટે લેખને થોડો વધુ વિશિષ્ટ બનાવવા માંગતો હતો અને તેને એક વિક્રેતા પાસેથી ખોલવા માંગતો હતો. જો તમને આ વિષયમાં રસ હોય તો અવશ્ય વાંચો.

ફૂટનોટ્સ

1. બહુવિધ ઉદાહરણોમાં લોડ વિતરણના સંદર્ભમાં સમાન હોવા છતાં, રેડિસ ક્લસ્ટરનું અંતર્ગત અમલીકરણ લોડ બેલેન્સરથી ઘણું અલગ છે. [વાપસી]

સોર્સ: www.habr.com