Yandex.Market શોધ કેવી રીતે કાર્ય કરે છે અને જો સર્વરમાંથી એક નિષ્ફળ જાય તો શું થાય છે

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

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

આપણા વિશે થોડું: આપણે કઈ સમસ્યા હલ કરીએ છીએ

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

અમે બધી શોધ વિનંતીઓ પર પ્રક્રિયા કરીએ છીએ: સાઇટ્સ market.yandex.ru, beru.ru, સુપરચેક સેવા, Yandex.Advisor, મોબાઇલ એપ્લિકેશન્સમાંથી. અમે yandex.ru પર શોધ પરિણામોમાં પ્રોડક્ટ ઑફર્સનો પણ સમાવેશ કરીએ છીએ.

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

શું છે: માર્કેટ આર્કિટેક્ચર

હું બજારના વર્તમાન આર્કિટેક્ચરનું ટૂંકમાં વર્ણન કરીશ. તે નીચેની આકૃતિ દ્વારા આશરે વર્ણવી શકાય છે:

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

આવા ઘણા સેવ xml છે. આ ડેટાબેઝમાંથી સર્ચ ઇન્ડેક્સ બનાવવામાં આવે છે. ઇન્ડેક્સ આંતરિક ફોર્મેટમાં સંગ્રહિત છે. ઇન્ડેક્સ બનાવ્યા પછી, લેઆઉટ સેવા તેને સર્ચ સર્વર્સ પર અપલોડ કરે છે.

પરિણામે, ડેટાબેઝમાં સ્ક્વિકર સાથે ગુસ્સે થયેલી બિલાડી દેખાય છે, અને સર્વર પર બિલાડીની અનુક્રમણિકા દેખાય છે.

હું તમને કહીશ કે અમે સર્ચ આર્કિટેક્ચર વિશેના ભાગમાં બિલાડીને કેવી રીતે શોધીએ છીએ.

બજાર શોધ આર્કિટેક્ચર

અમે માઇક્રો સર્વિસિસની દુનિયામાં જીવીએ છીએ: દરેક આવનારી વિનંતી બજાર.yandex.ru ઘણી બધી સબક્વેરીઝનું કારણ બને છે અને તેમની પ્રક્રિયામાં ડઝનેક સેવાઓ સામેલ છે. આકૃતિ ફક્ત થોડા જ બતાવે છે:

સરળ વિનંતી પ્રક્રિયા યોજના

દરેક સેવામાં એક અદ્ભુત વસ્તુ હોય છે - એક અનન્ય નામ સાથેનું પોતાનું બેલેન્સર:

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

બેલેન્સરનું અનન્ય નામ ડેટા સેન્ટર પર આધારિત નથી. જ્યારે સેવા A B ને વિનંતી કરે છે, ત્યારે મૂળભૂત રીતે બેલેન્સર B વિનંતીને વર્તમાન ડેટા સેન્ટર પર રીડાયરેક્ટ કરે છે. જો સેવા અનુપલબ્ધ છે અથવા વર્તમાન ડેટા સેન્ટરમાં અસ્તિત્વમાં નથી, તો વિનંતી અન્ય ડેટા કેન્દ્રો પર રીડાયરેક્ટ કરવામાં આવે છે.

બધા ડેટા કેન્દ્રો માટે એકલ FQDN સેવા A ને સ્થાનોથી સંપૂર્ણપણે અમૂર્ત કરવાની મંજૂરી આપે છે. સેવા B માટે તેમની વિનંતી પર હંમેશા પ્રક્રિયા કરવામાં આવશે. અપવાદ એ કેસ છે જ્યારે સેવા તમામ ડેટા કેન્દ્રોમાં સ્થિત છે.

પરંતુ આ બેલેન્સર સાથે બધું એટલું રોઝી નથી: અમારી પાસે એક વધારાનો મધ્યવર્તી ઘટક છે. બેલેન્સર અસ્થિર હોઈ શકે છે, અને આ સમસ્યા રીડન્ડન્ટ સર્વર્સ દ્વારા ઉકેલવામાં આવે છે. સેવાઓ A અને B વચ્ચે વધારાનો વિલંબ પણ છે. પરંતુ વ્યવહારમાં તે 1 ms કરતા ઓછો છે અને મોટાભાગની સેવાઓ માટે આ મહત્વપૂર્ણ નથી.

અનપેક્ષિત સાથે વ્યવહાર: શોધ સેવા સંતુલન અને સ્થિતિસ્થાપકતા

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

પરિસ્થિતિ ડરામણી છે, પરંતુ અમે તેના માટે તૈયાર છીએ. હું તમને ક્રમમાં કહીશ.

શોધ ઈન્ફ્રાસ્ટ્રક્ચર કેટલાક ડેટા સેન્ટર્સમાં સ્થિત છે:

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

ચાલો એક જ ડેટા સેન્ટરનો વિચાર કરીએ. દરેક ડેટા સેન્ટરમાં સમાન બેલેન્સર ઓપરેશન સ્કીમ હોય છે:

એક બેલેન્સર ઓછામાં ઓછા ત્રણ ભૌતિક સર્વર છે. આ રીડન્ડન્સી વિશ્વસનીયતા માટે બનાવવામાં આવી છે. બેલેન્સર્સ HAProx પર ચાલે છે.

અમે તેના ઉચ્ચ પ્રદર્શન, ઓછી સંસાધન આવશ્યકતાઓ અને વ્યાપક કાર્યક્ષમતાને કારણે HAProx પસંદ કર્યું છે. અમારું સર્ચ સોફ્ટવેર દરેક સર્વરની અંદર ચાલે છે.

એક સર્વર નિષ્ફળ થવાની સંભાવના ઓછી છે. પરંતુ જો તમારી પાસે ઘણા સર્વર છે, તો ઓછામાં ઓછું એક ડાઉન થવાની સંભાવના વધી જાય છે.

વાસ્તવિકતામાં આવું થાય છે: સર્વર ક્રેશ. તેથી, બધા સર્વરની સ્થિતિનું સતત નિરીક્ષણ કરવું જરૂરી છે. જો સર્વર પ્રતિસાદ આપવાનું બંધ કરે છે, તો તે આપમેળે ટ્રાફિકથી ડિસ્કનેક્ટ થઈ જાય છે. આ હેતુ માટે, HAProxy પાસે બિલ્ટ-ઇન હેલ્થ ચેક છે. તે HTTP વિનંતી “/ping” સાથે સેકન્ડમાં એકવાર બધા સર્વર્સ પર જાય છે.

HAProxy ની બીજી વિશેષતા: agent-check તમને બધા સર્વર્સને સમાનરૂપે લોડ કરવાની મંજૂરી આપે છે. આ કરવા માટે, HAProxy બધા સર્વર્સ સાથે જોડાય છે, અને તેઓ 1 થી 100 સુધીના વર્તમાન લોડના આધારે તેમનું વજન પરત કરે છે. પ્રક્રિયા માટે કતારમાં રહેલી વિનંતીઓની સંખ્યા અને પ્રોસેસર પરના ભારને આધારે વજનની ગણતરી કરવામાં આવે છે.

હવે બિલાડી શોધવા વિશે. શોધ પરિણામો જેવી વિનંતીઓમાં: /search?text=angry+cat. શોધ ઝડપી બનવા માટે, સમગ્ર બિલાડી અનુક્રમણિકા RAM માં ફિટ થવી જોઈએ. SSD માંથી વાંચન પણ પૂરતું ઝડપી નથી.

એક સમયે, ઑફર ડેટાબેઝ નાનો હતો, અને એક સર્વરની રેમ તેના માટે પૂરતી હતી. જેમ જેમ ઑફરનો આધાર વધતો ગયો તેમ તેમ બધું જ આ રેમમાં બંધબેસતું નથી અને ડેટાને બે ભાગમાં વહેંચવામાં આવ્યો: શાર્ડ 1 અને શાર્ડ 2.

પરંતુ આ હંમેશા થાય છે: કોઈપણ ઉકેલ, એક સારો પણ, અન્ય સમસ્યાઓને જન્મ આપે છે.

બેલેન્સર હજુ પણ કોઈપણ સર્વર પર ગયો. પરંતુ જે મશીન પર વિનંતી આવી હતી, ત્યાં માત્ર ઇન્ડેક્સનો અડધો ભાગ હતો. બાકીનું અન્ય સર્વર પર હતું. તેથી, સર્વરને પડોશી મશીન પર જવું પડ્યું. બંને સર્વરમાંથી ડેટા પ્રાપ્ત કર્યા પછી, પરિણામોને જોડવામાં આવ્યા હતા અને પુનઃક્રમાંકિત કરવામાં આવ્યા હતા.

બેલેન્સર વિનંતિઓને સરખી રીતે વિતરિત કરે છે, તેથી બધા સર્વર્સ રિ-રેન્કિંગમાં રોકાયેલા હતા, અને માત્ર ડેટા મોકલવામાં જ નહીં.

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

હાલમાં, આઠ શાર્ડ્સનું રૂપરેખાંકન વપરાય છે. વધુમાં, વધુ મેમરી બચાવવા માટે, ઇન્ડેક્સને શોધ ભાગ (જેનો ઉપયોગ શોધ માટે થાય છે) અને સ્નિપેટ ભાગ (જે શોધમાં સામેલ નથી)માં વિભાજિત કરવામાં આવ્યો હતો.

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

સર્વરોને ક્લસ્ટરોમાં જૂથબદ્ધ કરવામાં આવે છે. દરેક ક્લસ્ટરમાં આઠ સર્ચ એન્જિન અને એક સ્નિપેટ સર્વર હોય છે.

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

દસ્તાવેજ ID માત્ર એક અનુક્રમણિકામાં અનન્ય હોવાથી, સ્નિપેટ્સમાં કોઈ દસ્તાવેજો ન હોય તેવી પરિસ્થિતિ ઊભી થઈ શકે છે. સારું, અથવા તે એક ID માટે અલગ સામગ્રી હશે. તેથી, શોધ કાર્ય કરવા અને પરિણામો પરત કરવા માટે, સમગ્ર ક્લસ્ટરમાં સુસંગતતાની જરૂર હતી. અમે તમને સુસંગતતા કેવી રીતે મોનિટર કરીએ છીએ તે હું તમને નીચે જણાવીશ.

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

જરૂરી માહિતી એકત્રિત કર્યા પછી, ઓફર ડેટાબેઝમાં શોધ શરૂ થાય છે. આ કરવા માટે, ક્લસ્ટરના તમામ આઠ સર્વર્સ પર સબક્વેરીઝ બનાવવામાં આવે છે.

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

ક્લસ્ટરમાં શોધ ક્વેરી આના જેવી દેખાય છે: /shard1?text=angry+cat. વધુમાં, ફોર્મની સબક્વેરીઝ ક્લસ્ટરની અંદરના બધા સર્વર્સ વચ્ચે સેકન્ડમાં એક વખત સતત કરવામાં આવે છે: /સ્થિતિ.

તપાસ /સ્થિતિ એવી પરિસ્થિતિ શોધે છે જ્યાં સર્વર ઉપલબ્ધ નથી.

તે એ પણ નિયંત્રિત કરે છે કે સર્ચ એન્જિન સંસ્કરણ અને ઇન્ડેક્સ સંસ્કરણ બધા સર્વર્સ પર સમાન છે, અન્યથા ક્લસ્ટરમાં અસંગત ડેટા હશે.

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

ડેટા ટ્રાન્સફર કરવા માટે, અમે દસ્તાવેજો માટે સાર્વત્રિક કી રજૂ કરી છે. હવે એવી પરિસ્થિતિ માટે અશક્ય છે કે જ્યાં એક કીનો ઉપયોગ કરીને બીજા દસ્તાવેજમાંથી સામગ્રી પરત કરવામાં આવે.

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

અને હવે સુખદ અંત સાથે ડરામણી વાર્તાઓ માટે. ચાલો સર્વરની અનુપલબ્ધતાના ઘણા કિસ્સાઓ ધ્યાનમાં લઈએ.

કંઈક ભયંકર થયું: એક સર્વર અનુપલબ્ધ છે

ચાલો કહીએ કે એક સર્વર અનુપલબ્ધ છે. પછી ક્લસ્ટરમાંના બાકીના સર્વર્સ પ્રતિસાદ આપવાનું ચાલુ રાખી શકે છે, પરંતુ શોધ પરિણામો અધૂરા રહેશે.

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

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

જ્યારે સર્વર ઉપલબ્ધ થાય છે, ત્યારે તે પ્રતિસાદ આપવાનું શરૂ કરે છે /પિંગ. મૃત સર્વરમાંથી પિંગ્સ માટે સામાન્ય પ્રતિસાદ આવવાનું શરૂ થતાં જ, બેલેન્સર્સ ત્યાં વપરાશકર્તા ટ્રાફિક મોકલવાનું શરૂ કરે છે. ક્લસ્ટર કામગીરી પુનઃસ્થાપિત છે, હુરે.

તેનાથી પણ ખરાબ: ઘણા સર્વર્સ અનુપલબ્ધ છે

ડેટા સેન્ટરમાં સર્વર્સનો નોંધપાત્ર ભાગ કાપવામાં આવ્યો છે. શું કરવું, ક્યાં દોડવું? બેલેન્સર ફરીથી બચાવમાં આવે છે. દરેક બેલેન્સર લાઇવ સર્વરની વર્તમાન સંખ્યાને સતત મેમરીમાં સંગ્રહિત કરે છે. તે વર્તમાન ડેટા સેન્ટર દ્વારા પ્રક્રિયા કરી શકે તેટલા મહત્તમ ટ્રાફિકની સતત ગણતરી કરે છે.

જ્યારે ડેટા સેન્ટરના ઘણા સર્વર ડાઉન થઈ જાય છે, ત્યારે બેલેન્સરને ખ્યાલ આવે છે કે આ ડેટા સેન્ટર તમામ ટ્રાફિક પર પ્રક્રિયા કરી શકતું નથી.

પછી વધારાનો ટ્રાફિક અન્ય ડેટા કેન્દ્રો પર રેન્ડમ રીતે વિતરિત કરવાનું શરૂ કરે છે. બધું કામ કરે છે, દરેક ખુશ છે.

અમે તે કેવી રીતે કરીએ છીએ: પ્રકાશનોનું પ્રકાશન

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

પછી સેવાને પરીક્ષણ માટે રોલઆઉટ કરવામાં આવે છે, જ્યાં ઓપરેશનની સ્થિરતા તપાસવામાં આવે છે.

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

જો પરીક્ષણમાં પ્રકાશન સફળ થાય, તો પ્રીસ્ટેબલમાં પ્રકાશનનું પ્રકાશન આપમેળે શરૂ થાય છે. પ્રેસ્ટેબલ એ એક વિશિષ્ટ ક્લસ્ટર છે જ્યાં સામાન્ય વપરાશકર્તા ટ્રાફિકને નિર્દેશિત કરવામાં આવે છે. જો તે ભૂલ આપે છે, તો બેલેન્સર ઉત્પાદન માટે ફરીથી વિનંતી કરે છે.

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

બધા શ્રેષ્ઠ વપરાશકર્તાને જાય છે: A/B પરીક્ષણ

સેવામાં ફેરફારો વાસ્તવિક લાભો લાવશે કે કેમ તે હંમેશા સ્પષ્ટ નથી. ફેરફારોની ઉપયોગિતાને માપવા માટે, લોકો A/B પરીક્ષણ સાથે આવ્યા. Yandex.Market શોધમાં તે કેવી રીતે કાર્ય કરે છે તે વિશે હું તમને થોડું કહીશ.

તે બધા નવા CGI પરિમાણ ઉમેરવાથી શરૂ થાય છે જે નવી કાર્યક્ષમતાને સક્ષમ કરે છે. અમારું પરિમાણ થવા દો: બજાર_નવી_કાર્યક્ષમતા = 1. જો ધ્વજ હાજર હોય તો કોડમાં અમે આ કાર્યક્ષમતાને સક્ષમ કરીએ છીએ:

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

નવી કાર્યક્ષમતા ઉત્પાદન માટે રોલઆઉટ કરવામાં આવી રહી છે.

A/B પરીક્ષણને સ્વચાલિત કરવા માટે, એક સમર્પિત સેવા છે જે વિગતવાર માહિતી પ્રદાન કરે છે અહીં વર્ણવેલ. સેવામાં એક પ્રયોગ બનાવવામાં આવે છે. ટ્રાફિક શેર સેટ છે, ઉદાહરણ તરીકે, 15%. ટકાવારી પ્રશ્નો માટે નહીં, પરંતુ વપરાશકર્તાઓ માટે સેટ કરવામાં આવે છે. પ્રયોગનો સમયગાળો પણ સૂચવવામાં આવે છે, ઉદાહરણ તરીકે, એક સપ્તાહ.

એક સાથે અનેક પ્રયોગો કરી શકાય છે. સેટિંગ્સમાં તમે સ્પષ્ટ કરી શકો છો કે અન્ય પ્રયોગો સાથે આંતરછેદ શક્ય છે કે કેમ.

પરિણામે, સેવા આપમેળે દલીલ ઉમેરે છે બજાર_નવી_કાર્યક્ષમતા = 1 વપરાશકર્તાઓના 15% સુધી. તે આપમેળે પસંદ કરેલ મેટ્રિક્સની ગણતરી પણ કરે છે. પ્રયોગ પૂર્ણ થયા પછી, વિશ્લેષકો પરિણામો જુએ છે અને તારણો કાઢે છે. તારણોના આધારે, ઉત્પાદન અથવા શુદ્ધિકરણ માટે રોલ આઉટ કરવાનો નિર્ણય લેવામાં આવે છે.

બજારનો કુશળ હાથ: ઉત્પાદનમાં પરીક્ષણ

તે ઘણીવાર થાય છે કે તમારે ઉત્પાદનમાં નવી કાર્યક્ષમતાનું પરીક્ષણ કરવાની જરૂર છે, પરંતુ તમને ખાતરી નથી કે તે ભારે ભાર હેઠળ "લડાઇ" પરિસ્થિતિઓમાં કેવી રીતે વર્તે છે.

ત્યાં એક ઉકેલ છે: CGI પરિમાણોમાં ફ્લેગ્સનો ઉપયોગ ફક્ત A/B પરીક્ષણ માટે જ નહીં, પણ નવી કાર્યક્ષમતા ચકાસવા માટે પણ થઈ શકે છે.

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

સેવા પ્રવાહ રેખાકૃતિ નીચે પ્રસ્તુત છે:

ફ્લેગ મૂલ્યો API દ્વારા સેટ કરવામાં આવે છે. મેનેજમેન્ટ સર્વિસ આ મૂલ્યોને ડેટાબેઝમાં સંગ્રહિત કરે છે. બધા સર્વર્સ દર દસ સેકન્ડમાં એકવાર ડેટાબેઝ પર જાય છે, ધ્વજ મૂલ્યોને બહાર કાઢે છે અને દરેક વિનંતી પર આ મૂલ્યો લાગુ કરે છે.

સ્ટોપ ટેપમાં તમે બે પ્રકારના મૂલ્યો સેટ કરી શકો છો:

1) શરતી અભિવ્યક્તિઓ. જ્યારે કોઈ એક મૂલ્ય સાચું હોય ત્યારે લાગુ કરો. દાખ્લા તરીકે:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

જ્યારે DC3 સ્થાન પર વિનંતીની પ્રક્રિયા કરવામાં આવશે ત્યારે મૂલ્ય "1" લાગુ કરવામાં આવશે. અને beru.ru સાઇટ માટે બીજા ક્લસ્ટર પર વિનંતી પર પ્રક્રિયા કરવામાં આવે ત્યારે મૂલ્ય “4” છે.

2) બિનશરતી મૂલ્યો. જો કોઈપણ શરતો પૂરી ન થાય તો ડિફૉલ્ટ રૂપે અરજી કરો. દાખ્લા તરીકે:

મૂલ્ય, મૂલ્ય!

જો કોઈ મૂલ્ય ઉદ્ગારવાચક બિંદુ સાથે સમાપ્ત થાય છે, તો તેને ઉચ્ચ અગ્રતા આપવામાં આવે છે.

CGI પેરામીટર પાર્સર URL ને પાર્સ કરે છે. પછી સ્ટોપ ટેપમાંથી મૂલ્યો લાગુ કરે છે.

નીચેની પ્રાથમિકતાઓ સાથેના મૂલ્યો લાગુ કરવામાં આવે છે:

1. સ્ટોપ ટેપ (ઉદ્ગારવાચક ચિહ્ન) થી વધેલી અગ્રતા સાથે.
2. વિનંતીમાંથી મૂલ્ય.
3. સ્ટોપ ટેપથી ડિફોલ્ટ મૂલ્ય.
4. કોડમાં ડિફૉલ્ટ મૂલ્ય.

ત્યાં ઘણા ધ્વજ છે જે શરતી મૂલ્યોમાં દર્શાવેલ છે - તે અમને જાણીતા તમામ દૃશ્યો માટે પૂરતા છે:

• માહીતી મથક.
• પર્યાવરણ: ઉત્પાદન, પરીક્ષણ, પડછાયો.
• સ્થળ: બજાર, બેરુ.
• ક્લસ્ટર નંબર.

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

જો તમને કોઈ સમસ્યા દેખાય છે, તો તમે તરત જ ધ્વજને તેના પાછલા મૂલ્ય પર પરત કરી શકો છો અને ફેરફારો પાછા રોલ કરવામાં આવશે.

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

સ્ટોપ ટેપ એપ્રોચ સારી રીતે કામ કરે છે જ્યારે તમારી પાસે પહેલેથી જ પ્રોડક્શન માટે રોલઆઉટ થવા માટે સ્થિર કોડ તૈયાર હોય. તે જ સમયે, તમને હજી પણ શંકા છે, અને તમે "લડાઇ" પરિસ્થિતિઓમાં કોડને તપાસવા માંગો છો.

જો કે, સ્ટોપ ટેપ વિકાસ દરમિયાન પરીક્ષણ માટે યોગ્ય નથી. વિકાસકર્તાઓ માટે એક અલગ ક્લસ્ટર છે જેને "શેડો ક્લસ્ટર" કહેવાય છે.

ગુપ્ત પરીક્ષણ: શેડો ક્લસ્ટર

ક્લસ્ટરોમાંથી એકની વિનંતીઓ શેડો ક્લસ્ટરમાં ડુપ્લિકેટ કરવામાં આવે છે. પરંતુ બેલેન્સર આ ક્લસ્ટરના પ્રતિભાવોને સંપૂર્ણપણે અવગણે છે. તેની કામગીરીનો આકૃતિ નીચે પ્રસ્તુત છે.

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

અને બેલેન્સર પ્રતિસાદોને સંપૂર્ણપણે અવગણતું હોવાથી, અંતિમ વપરાશકર્તાઓ શેડો ક્લસ્ટરમાંથી પ્રતિસાદો જોઈ શકશે નહીં. તેથી, ભૂલ કરવી ડરામણી નથી.

તારણો

તો, અમે બજાર શોધ કેવી રીતે બનાવી?

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

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

સારું, ઉત્પાદનમાં પરીક્ષણ, અલબત્ત. હજારો સર્વર પર ગોઠવણી બદલવાની જરૂર છે? સરળ, સ્ટોપ ટેપનો ઉપયોગ કરો. આ રીતે તમે તરત જ તૈયાર જટિલ સોલ્યુશનને રોલ આઉટ કરી શકો છો અને જો સમસ્યાઓ ઊભી થાય તો સ્થિર સંસ્કરણ પર પાછા ફરો.

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

સોર્સ: www.habr.com