અમે દૂરસ્થ રીતે x10 વર્કલોડના વધારાથી કેવી રીતે બચી ગયા અને અમે કયા તારણો કાઢ્યા

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

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

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

એક દિવસ, એક ક્લાયન્ટે એક SberMarket કુરિયરને કરિયાણાની ચીજવસ્તુઓ તેને સંપર્ક વિના પહોંચાડવા કહ્યું - સીધું બાલ્કનીમાં.

પરંતુ ચાલો સ્પષ્ટીકરણો પર નીચે જઈએ. છેલ્લા કેટલાક મહિનાઓથી, અમે અમારી કંપનીના ઇન્ફ્રાસ્ટ્રક્ચરને સક્રિયપણે સ્કેલ કરી રહ્યા છીએ. આ જરૂરિયાત બાહ્ય અને આંતરિક પરિબળો દ્વારા સમજાવવામાં આવી હતી. તેની સાથે જ ગ્રાહક આધારના વિસ્તરણ સાથે, કનેક્ટેડ સ્ટોર્સની સંખ્યા વર્ષની શરૂઆતમાં 90 થી વધીને મેના મધ્ય સુધીમાં 200 થી વધુ થઈ ગઈ. અલબત્ત, અમે અમારી જાતને તૈયાર કરી, મુખ્ય ઈન્ફ્રાસ્ટ્રક્ચર આરક્ષિત કર્યું અને યાન્ડેક્ષ ક્લાઉડમાં હોસ્ટ કરાયેલા તમામ વર્ચ્યુઅલ મશીનોના વર્ટિકલ અને હોરિઝોન્ટલ સ્કેલિંગની શક્યતા પર ગણતરી કરી. જો કે, પ્રેક્ટિસ બતાવે છે: "જે ખોટું થઈ શકે છે તે બધું ખોટું થશે." અને આજે હું આ અઠવાડિયામાં બનેલી સૌથી વિચિત્ર પરિસ્થિતિઓ શેર કરવા માંગુ છું. મને આશા છે કે અમારો અનુભવ તમારા માટે ઉપયોગી થશે.

સંપૂર્ણ લડાઇ તત્પરતામાં ગુલામ

રોગચાળાની શરૂઆત પહેલા જ, અમને અમારા બેકએન્ડ સર્વર્સ પર વિનંતીઓની સંખ્યામાં વધારો થયો હતો. હોમ ડિલિવરી સાથે કરિયાણા મંગાવવાના વલણે વેગ પકડવાનું શરૂ કર્યું, અને COVID-19 ના સંબંધમાં સ્વ-અલગતાના પ્રથમ પગલાંની રજૂઆત સાથે, સમગ્ર દિવસ દરમિયાન અમારી આંખો સમક્ષ ભાર નાટકીય રીતે વધ્યો. મુખ્ય ડેટાબેઝના મુખ્ય સર્વરોને ઝડપથી અનલોડ કરવાની અને કેટલીક વાંચેલી વિનંતીઓને પ્રતિકૃતિ સર્વર્સ (સ્લેવ) પર સ્થાનાંતરિત કરવાની જરૂર હતી.

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

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

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

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

સમસ્યા તરત જ પ્રગટ થઈ ન હતી, કારણ કે. વધેલા ભારથી ગુલામોનો બેકલોગ વધ્યો. ડેટાની અસંગતતા સવારે મળી આવી હતી, જ્યારે, રાત્રિની આયાત પછી, ગુલામો માસ્ટર સાથે "પકડતા" ન હતા. અમે આ માટે સેવા પરના ઊંચા ભાર અને નવા સ્ટોર્સની શરૂઆત સાથે સંકળાયેલ આયાતને આભારી છીએ. પરંતુ ઘણા કલાકોના વિલંબ સાથે ડેટા આપવાનું અસ્વીકાર્ય હતું, અને અમે પ્રક્રિયાઓને બીજા વિશ્લેષણાત્મક સ્લેવ પર સ્વિચ કરી, કારણ કે તેમાંоમોટા સંસાધનો અને વાંચવા માટેની વિનંતીઓ સાથે લોડ કરવામાં આવ્યા ન હતા (જે રીતે અમે પ્રતિકૃતિ લેગનો અભાવ પોતાને સમજાવ્યો હતો).

જ્યારે અમે મુખ્ય ગુલામના "પ્રસાર" માટેના કારણો શોધી કાઢ્યા, ત્યારે વિશ્લેષણાત્મક એક જ કારણસર નિષ્ફળ ગયો હતો. બે વધારાના સર્વરની હાજરી હોવા છતાં, જેમાં અમે માસ્ટર ક્રેશની ઘટનામાં લોડને સ્થાનાંતરિત કરવાની યોજના બનાવી હતી, કમનસીબ ભૂલને કારણે, તે બહાર આવ્યું છે કે નિર્ણાયક ક્ષણે એક પણ ન હતું.

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

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

એક ભારે ક્વેરી પણ ઑપ્ટિમાઇઝ કરીને ડેટાબેઝને જીવંત બનાવી શકાય છે

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

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

એક રસપ્રદ અસર એ હતી કે MySQL, આંખની કીકી પર લોડ થયેલ છે, પ્રક્રિયાઓમાં થોડો સુધારો પણ કરે છે. કુલ લોડના માત્ર 5% ક્વેરીઝને ઑપ્ટિમાઇઝ કરીને પહેલેથી જ નોંધપાત્ર CPU ઑફલોડ દર્શાવ્યું છે. પરિણામે, અમે ડેટાબેઝ સાથે કામ કરવા અને પ્રતિકૃતિઓ પુનઃસ્થાપિત કરવા માટે જરૂરી સમય મેળવવા માટે માસ્ટર માટે સંસાધનોનો સ્વીકાર્ય અનામત પ્રદાન કરવામાં વ્યવસ્થાપિત થયા. 

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

ભાગીદાર સેવાઓના સ્વાસ્થ્યનું નિરીક્ષણ ગોઠવો

અમે ગ્રાહકો પાસેથી ઓર્ડર પર પ્રક્રિયા કરીએ છીએ, અને તેથી અમારી સેવાઓ સતત તૃતીય-પક્ષ APIs સાથે ક્રિયાપ્રતિક્રિયા કરે છે - આ SMS, ચુકવણી પ્લેટફોર્મ, રૂટીંગ સિસ્ટમ્સ, જીઓકોડર, ફેડરલ ટેક્સ સર્વિસ અને અન્ય ઘણી સિસ્ટમ્સ મોકલવા માટેના ગેટવે છે. અને જ્યારે ભાર ઝડપથી વધવા લાગ્યો, ત્યારે અમે અમારી ભાગીદાર સેવાઓની API ની મર્યાદાઓમાં દોડવાનું શરૂ કર્યું, જેના વિશે અમે પહેલાં વિચાર્યું પણ ન હતું.

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

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

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

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

ક્યારેક તે બહાર વળે છે કેવધુ સોનાની જરૂર છે"(c) મદદ કરતું નથી

અમે મુખ્ય ડેટાબેઝમાં અથવા એપ્લિકેશન સર્વર્સ પર "ગૅગ્સ" કરવા માટે વપરાય છે, પરંતુ જ્યારે સ્કેલિંગ કરવામાં આવે છે, ત્યારે મુશ્કેલીઓ આવી શકે છે જ્યાં તેઓની અપેક્ષા ન હતી. સાઇટ પર સંપૂર્ણ-ટેક્સ્ટ શોધ માટે, અમે અપાચે સોલર એન્જિનનો ઉપયોગ કરીએ છીએ. જેમ જેમ લોડ વધતો ગયો તેમ, અમે પ્રતિભાવ સમયમાં ઘટાડો જોયો અને સર્વર CPU લોડ 100% સુધી પહોંચ્યો. શું સરળ હોઈ શકે છે - સોલર કન્ટેનરને વધુ સંસાધનો આપો.

પ્રદર્શનમાં અપેક્ષિત વધારાને બદલે, સર્વર ખાલી "મૃત્યુ પામ્યું". તે તરત જ 100% લોડ થયું અને વધુ ધીમેથી પ્રતિસાદ આપ્યો. શરૂઆતમાં, અમારી પાસે 2 કોર અને 2 GB RAM હતી. અમે સામાન્ય રીતે મદદ કરે છે તે કરવાનું નક્કી કર્યું - અમે સર્વરને 8 કોરો અને 32 જીબી આપ્યા. બધું વધુ ખરાબ થઈ ગયું (અમે તમને એક અલગ પોસ્ટમાં બરાબર કેવી રીતે અને શા માટે કહીશું). 

થોડા દિવસોમાં, અમે આ મુદ્દાની જટિલતાઓ શોધી કાઢી, અને 8 કોરો અને 32 GB સાથે શ્રેષ્ઠ પ્રદર્શન પ્રાપ્ત કર્યું. આ રૂપરેખાંકન અમને આજે લોડ વધારવાનું ચાલુ રાખવા દે છે, જે ખૂબ જ મહત્વપૂર્ણ છે, કારણ કે વૃદ્ધિ માત્ર ગ્રાહકોની દ્રષ્ટિએ જ નથી, પણ કનેક્ટેડ સ્ટોર્સની સંખ્યામાં પણ છે - 2 મહિનામાં તેમની સંખ્યા બમણી થઈ ગઈ છે. 

ઉપસંહાર: "વધુ આયર્ન ઉમેરો" જેવી માનક પદ્ધતિઓ હંમેશા કામ કરતી નથી. તેથી કોઈપણ સેવાને માપતી વખતે, તમારે તે કેવી રીતે સંસાધનોનો ઉપયોગ કરે છે તેની સારી સમજ હોવી જરૂરી છે અને અગાઉથી તેનું પરીક્ષણ, નવી પરિસ્થિતિઓમાં તેનું કાર્ય. 

સ્ટેટલેસ એ સરળ આડી સ્કેલિંગની ચાવી છે

સામાન્ય રીતે, અમારી ટીમ જાણીતા અભિગમનું પાલન કરે છે: સેવાઓની આંતરિક સ્થિતિ (સ્ટેટલેસ) ન હોવી જોઈએ અને રનટાઇમ વાતાવરણથી સ્વતંત્ર હોવી જોઈએ. આનાથી અમને સરળ આડી સ્કેલિંગ દ્વારા ભારમાં વધારાને ટકી રહેવાની મંજૂરી મળી. પરંતુ અમારી પાસે એક સેવા અપવાદ હતો - લાંબા પૃષ્ઠભૂમિ કાર્યો માટે હેન્ડલર. તે ઈમેઈલ અને એસએમએસ મોકલવા, ઈવેન્ટ્સની પ્રક્રિયા કરવા, ફીડ જનરેટ કરવા, કિંમતો અને સ્ટોક આયાત કરવા અને ઈમેજીસ પ્રોસેસિંગમાં સામેલ હતો. એવું બન્યું કે તે સ્થાનિક ફાઇલ સ્ટોરેજ પર આધારિત હતું અને એક જ નકલમાં હતું. 

જ્યારે પ્રોસેસરની કતારમાં કાર્યોની સંખ્યામાં વધારો થયો (અને આ કુદરતી રીતે ઓર્ડરની સંખ્યામાં વધારા સાથે થયું), પ્રોસેસર અને ફાઇલ સ્ટોરેજને હોસ્ટ કરનાર હોસ્ટનું પ્રદર્શન મર્યાદિત પરિબળ બની ગયું. પરિણામે, શ્રેણી અને કિંમતો અપડેટ કરવી, વપરાશકર્તાઓને સૂચનાઓ મોકલવી અને કતારમાં અટવાયેલા અન્ય ઘણા મહત્વપૂર્ણ કાર્યો અટકી ગયા. ઑપ્સ ટીમે ઝડપથી ફાઇલ સ્ટોરેજને S3-જેવા નેટવર્ક સ્ટોરેજમાં સ્થાનાંતરિત કર્યું, અને આનાથી અમને પૃષ્ઠભૂમિ કાર્ય હેન્ડલરને સ્કેલ કરવા માટે ઘણા શક્તિશાળી મશીનો ઉભા કરવાની મંજૂરી મળી.

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

સઘન વૃદ્ધિ માટે 7 સિદ્ધાંતો

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

1. ઘટના વ્યવસ્થાપન. અમે જીરામાં એક બોર્ડ બનાવ્યું છે, જ્યાં દરેક ઘટના ટિકિટના રૂપમાં પ્રતિબિંબિત થાય છે. આ તમને વાસ્તવમાં ઘટના-સંબંધિત કાર્યોને પ્રાથમિકતા આપવા અને પૂર્ણ કરવામાં મદદ કરશે. ખરેખર, સારમાં, ભૂલો કરવી તે ભયંકર નથી - તે જ પ્રસંગે બે વાર ભૂલો કરવી તે ભયંકર છે. તે કિસ્સાઓ માટે જ્યારે ઘટનાઓ કારણને સુધારી શકાય તે પહેલાં પુનરાવર્તિત થાય છે, પગલાં માટેની સૂચનાઓ તૈયાર કરવી જોઈએ, કારણ કે ભારે ભાર દરમિયાન વીજળીની ગતિ સાથે પ્રતિક્રિયા કરવી મહત્વપૂર્ણ છે.
2. મોનીટરીંગ અપવાદ વિના તમામ માળખાકીય ઘટકો માટે જરૂરી છે. તે તેના માટે આભાર હતો કે અમે ભારની વૃદ્ધિની આગાહી કરી શક્યા અને નાબૂદીને પ્રાથમિકતા આપવા માટે "અડચણો" યોગ્ય રીતે પસંદ કરી શક્યા. સંભવત,, ઉચ્ચ ભાર હેઠળ, તમે જે વિશે વિચાર્યું પણ ન હતું તે બધું તૂટી જશે અથવા ધીમું થવાનું શરૂ કરશે. તેથી, પ્રથમ ઘટનાઓની શરૂઆત પછી તરત જ નવી ચેતવણીઓ બનાવવાનું શ્રેષ્ઠ છે જેથી કરીને તેનું નિરીક્ષણ અને અપેક્ષા રાખવામાં આવે.
3. સાચી ચેતવણીઓ ભારમાં તીવ્ર વધારો સાથે માત્ર જરૂરી છે. પ્રથમ, તેઓએ બરાબર જાણ કરવી જોઈએ કે શું તૂટી ગયું છે. બીજું, ત્યાં ઘણી ચેતવણીઓ હોવી જોઈએ નહીં, કારણ કે બિન-જટિલ ચેતવણીઓની વિપુલતા સામાન્ય રીતે તમામ ચેતવણીઓને અવગણવા તરફ દોરી જાય છે.
4. અરજીઓ સ્ટેટલેસ હોવી જોઈએ. અમે ખાતરી કરી છે કે આ નિયમમાં કોઈ અપવાદ ન હોવો જોઈએ. તમારે રનટાઇમ પર્યાવરણથી સંપૂર્ણ સ્વતંત્રતાની જરૂર છે. આ કરવા માટે, તમે ડેટાબેઝમાં શેર કરેલ ડેટા સ્ટોર કરી શકો છો અથવા, ઉદાહરણ તરીકે, સીધા S3 માં. હજી વધુ સારું, નિયમોનું પાલન કરો. https://12factor.net. સમયના તીવ્ર વધારા દરમિયાન, કોડને ઑપ્ટિમાઇઝ કરવાનો કોઈ રસ્તો નથી, અને તમારે કમ્પ્યુટિંગ સંસાધનો અને આડી સ્કેલિંગને સીધું વધારીને ભારનો સામનો કરવો પડશે.
5. ક્વોટા અને બાહ્ય સેવાઓનું પ્રદર્શન. ઝડપી વૃદ્ધિ સાથે, સમસ્યા ફક્ત તમારા ઇન્ફ્રાસ્ટ્રક્ચરમાં જ નહીં, પણ બાહ્ય સેવામાં પણ ઊભી થઈ શકે છે. સૌથી હેરાન કરનારી બાબત એ છે કે જ્યારે આ નિષ્ફળતાને કારણે નહીં, પરંતુ ક્વોટા અથવા મર્યાદા સુધી પહોંચવાના કારણે થાય છે. તેથી બાહ્ય સેવાઓનું પ્રમાણ તમારી સાથે જ હોવું જોઈએ. 
6. અલગ પ્રક્રિયાઓ અને કતાર. જ્યારે કોઈ એક ગેટવે પર પ્લગ થાય ત્યારે આ ઘણી મદદ કરે છે. અમને ડેટા ટ્રાન્સમિશનમાં વિલંબનો સામનો કરવો પડ્યો ન હોત જો SMS મોકલવા માટેની સંપૂર્ણ કતાર માહિતી સિસ્ટમો વચ્ચે સૂચનાઓના વિનિમયમાં દખલ ન કરે. અને જો તેઓ અલગથી કામ કરે તો કામદારોની સંખ્યા વધારવી સરળ બનશે.
7. નાણાકીય વાસ્તવિકતાઓ. જ્યારે ડેટા પ્રવાહમાં વિસ્ફોટક વૃદ્ધિ થાય છે, ત્યારે ટેરિફ અને સબ્સ્ક્રિપ્શન્સ વિશે વિચારવાનો સમય નથી. પરંતુ તેઓને યાદ રાખવું આવશ્યક છે, ખાસ કરીને જો તમે નાની કંપની છો. એક મોટું બિલ કોઈપણ API ના માલિક તેમજ તમારા હોસ્ટિંગ પ્રદાતા દ્વારા સેટ કરી શકાય છે. તેથી કરાર કાળજીપૂર્વક વાંચો.

નિષ્કર્ષ

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

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

ફક્ત નોંધાયેલા વપરાશકર્તાઓ જ સર્વેમાં ભાગ લઈ શકે છે. સાઇન ઇન કરો, મહેરબાની કરીને.

શું તમે ક્યારેય આના કારણે લોડમાં તીવ્ર વધારા દરમિયાન સેવામાં મંદી/ઘટાડો કર્યો છે:

• 55,6%કમ્પ્યુટિંગ સંસાધનો ઝડપથી ઉમેરવામાં અસમર્થતા10

• 16,7%હોસ્ટિંગ પ્રદાતા ઇન્ફ્રાસ્ટ્રક્ચર મર્યાદા3

• 33,3%તૃતીય પક્ષ API6 મર્યાદા

• 27,8%સ્ટેટલેસ તેમની અરજીઓના સિદ્ધાંતોનું ઉલ્લંઘન5

• 88,9%પોતાની સેવાઓનો બિન-શ્રેષ્ઠ કોડ16

18 વપરાશકર્તાઓએ મતદાન કર્યું. 6 વપરાશકર્તાઓ દૂર રહ્યા.

સોર્સ: www.habr.com