Yandex.Market தேடல் எவ்வாறு செயல்படுகிறது மற்றும் சேவையகங்களில் ஒன்று தோல்வியுற்றால் என்ன நடக்கும்

வணக்கம், என் பெயர் எவ்ஜெனி. நான் Yandex.Market தேடல் உள்கட்டமைப்பில் வேலை செய்கிறேன். நான் ஹப்ர் சமூகத்திற்கு சந்தையின் உள் சமையலறை பற்றி சொல்ல விரும்புகிறேன் - மேலும் நான் சொல்ல நிறைய இருக்கிறது. முதலில், சந்தை தேடல் எவ்வாறு செயல்படுகிறது, செயல்முறைகள் மற்றும் கட்டமைப்பு. அவசரகால சூழ்நிலைகளை எவ்வாறு கையாள்வது: ஒரு சர்வர் செயலிழந்தால் என்ன ஆகும்? அத்தகைய 100 சேவையகங்கள் இருந்தால் என்ன செய்வது?

ஒரே நேரத்தில் பல சேவையகங்களில் புதிய செயல்பாட்டை எவ்வாறு செயல்படுத்துகிறோம் என்பதையும் நீங்கள் அறிந்து கொள்வீர்கள். மேலும், சிக்கலான சேவைகளை நேரடியாக உற்பத்தியில் எவ்வாறு சோதிப்போம், பயனர்களுக்கு எந்த சிரமத்தையும் ஏற்படுத்தாமல். பொதுவாக, சந்தை தேடல் எவ்வாறு செயல்படுகிறது, இதனால் அனைவருக்கும் நல்ல நேரம் கிடைக்கும்.

எங்களைப் பற்றி கொஞ்சம்: நாங்கள் என்ன சிக்கலை தீர்க்கிறோம்

நீங்கள் உரையை உள்ளிடும்போது, ​​அளவுருக்கள் மூலம் தயாரிப்பைத் தேடும்போது அல்லது வெவ்வேறு கடைகளில் விலைகளை ஒப்பிடும்போது, ​​எல்லா கோரிக்கைகளும் தேடல் சேவைக்கு அனுப்பப்படும். தேடல் என்பது சந்தையில் மிகப்பெரிய சேவையாகும்.

அனைத்து தேடல் கோரிக்கைகளையும் நாங்கள் செயல்படுத்துகிறோம்: தளங்களில் இருந்து market.yandex.ru, beru.ru, Supercheck சேவை, Yandex.Advisor, மொபைல் பயன்பாடுகள். yandex.ru இல் உள்ள தேடல் முடிவுகளில் தயாரிப்பு சலுகைகளையும் நாங்கள் சேர்க்கிறோம்.

தேடல் சேவை மூலம் நான் தேடலை மட்டுமல்ல, சந்தையில் உள்ள அனைத்து சலுகைகளையும் கொண்ட தரவுத்தளத்தையும் குறிக்கிறேன். அளவுகோல் இதுதான்: ஒரு நாளைக்கு ஒரு பில்லியனுக்கும் அதிகமான தேடல் கோரிக்கைகள் செயலாக்கப்படுகின்றன. மற்றும் எல்லாம் விரைவாக வேலை செய்ய வேண்டும், குறுக்கீடுகள் இல்லாமல் எப்போதும் விரும்பிய முடிவை உருவாக்க வேண்டும்.

என்ன: சந்தை கட்டமைப்பு

சந்தையின் தற்போதைய கட்டமைப்பை நான் சுருக்கமாக விவரிக்கிறேன். கீழே உள்ள வரைபடத்தின் மூலம் இதை தோராயமாக விவரிக்கலாம்:

ஒரு பார்ட்னர் ஸ்டோர் நம்மிடம் வருகிறது என்று வைத்துக்கொள்வோம். நான் ஒரு பொம்மையை விற்க விரும்புகிறேன் என்று அவர் கூறுகிறார்: இந்த தீய பூனை ஒரு squeaker. மற்றும் ஒரு squeaker இல்லாமல் மற்றொரு கோபமான பூனை. மற்றும் ஒரு பூனை. சந்தை தேடும் சலுகைகளை கடை தயார் செய்ய வேண்டும். ஸ்டோர் சலுகைகளுடன் ஒரு சிறப்பு xml ஐ உருவாக்குகிறது மற்றும் இணைப்பு இடைமுகம் மூலம் இந்த xmlக்கான பாதையைத் தெரிவிக்கிறது. குறியீட்டாளர் இந்த xml ஐ அவ்வப்போது பதிவிறக்கம் செய்து, பிழைகளை சரிபார்த்து, அனைத்து தகவல்களையும் ஒரு பெரிய தரவுத்தளத்தில் சேமிக்கிறது.

இதுபோன்ற பல சேமித்த எக்ஸ்எம்எல்கள் உள்ளன. இந்தத் தரவுத்தளத்திலிருந்து ஒரு தேடல் அட்டவணை உருவாக்கப்பட்டுள்ளது. குறியீட்டு உள் வடிவத்தில் சேமிக்கப்படுகிறது. குறியீட்டை உருவாக்கிய பிறகு, லேஅவுட் சேவை அதை சர்வர்களில் பதிவேற்றுகிறது.

இதன் விளைவாக, ஒரு squeaker உடன் கோபமான பூனை தரவுத்தளத்தில் தோன்றுகிறது, மேலும் பூனையின் குறியீடு சேவையகத்தில் தோன்றும்.

தேடல் கட்டிடக்கலை பற்றிய பகுதியில் பூனையை எப்படி தேடுகிறோம் என்பதை நான் உங்களுக்கு சொல்கிறேன்.

சந்தை தேடல் கட்டமைப்பு

நாங்கள் மைக்ரோ சர்வீஸ் உலகில் வாழ்கிறோம்: ஒவ்வொரு உள்வரும் கோரிக்கை market.yandex.ru பல துணை வினவல்களை ஏற்படுத்துகிறது, மேலும் டஜன் கணக்கான சேவைகள் அவற்றின் செயலாக்கத்தில் ஈடுபட்டுள்ளன. வரைபடம் சிலவற்றை மட்டுமே காட்டுகிறது:

எளிமைப்படுத்தப்பட்ட கோரிக்கை செயலாக்க திட்டம்

ஒவ்வொரு சேவைக்கும் ஒரு அற்புதமான விஷயம் உள்ளது - தனித்துவமான பெயருடன் அதன் சொந்த பேலன்சர்:

பேலன்சர் சேவையை நிர்வகிப்பதில் எங்களுக்கு அதிக நெகிழ்வுத்தன்மையை அளிக்கிறது: எடுத்துக்காட்டாக, புதுப்பிப்புகளுக்கு அடிக்கடி தேவைப்படும் சேவையகங்களை நீங்கள் முடக்கலாம். பேலன்சர் சேவையகம் கிடைக்காததைக் கண்டு தானாகவே கோரிக்கைகளை பிற சேவையகங்கள் அல்லது தரவு மையங்களுக்குத் திருப்பிவிடும். சேவையகத்தைச் சேர்க்கும்போது அல்லது அகற்றும்போது, ​​சேவையகங்களுக்கு இடையில் சுமை தானாகவே மறுபகிர்வு செய்யப்படும்.

பேலன்சரின் தனித்துவமான பெயர் தரவு மையத்தைப் பொறுத்தது அல்ல. சேவை A B க்கு ஒரு கோரிக்கையை வைக்கும் போது, ​​​​இயல்புநிலை சமநிலை B கோரிக்கையை தற்போதைய தரவு மையத்திற்கு திருப்பிவிடும். சேவை கிடைக்கவில்லை அல்லது தற்போதைய தரவு மையத்தில் இல்லை என்றால், கோரிக்கை மற்ற தரவு மையங்களுக்கு திருப்பி விடப்படும்.

அனைத்து தரவு மையங்களுக்கும் ஒரே ஒரு FQDN ஆனது சேவை A ஐ இருப்பிடங்களிலிருந்து முழுமையாக சுருக்க அனுமதிக்கிறது. B சேவைக்கான அவரது கோரிக்கை எப்போதும் செயல்படுத்தப்படும். எல்லா தரவு மையங்களிலும் சேவை அமைந்திருக்கும் போது விதிவிலக்கு.

ஆனால் இந்த பேலன்சருடன் எல்லாம் மிகவும் ரோஸியாக இல்லை: எங்களிடம் கூடுதல் இடைநிலை கூறு உள்ளது. பேலன்சர் நிலையற்றதாக இருக்கலாம், மேலும் இந்தச் சிக்கல் தேவையற்ற சேவையகங்களால் தீர்க்கப்படுகிறது. A மற்றும் B சேவைகளுக்கு இடையே கூடுதல் தாமதமும் உள்ளது. ஆனால் நடைமுறையில் இது 1 ms க்கும் குறைவாக உள்ளது மற்றும் பெரும்பாலான சேவைகளுக்கு இது முக்கியமானதாக இல்லை.

எதிர்பாராதவற்றைக் கையாளுதல்: தேடல் சேவை சமநிலை மற்றும் மீள்தன்மை

ஒரு சரிவு இருப்பதாக கற்பனை செய்து பாருங்கள்: நீங்கள் ஒரு பூனையுடன் ஒரு பூனை கண்டுபிடிக்க வேண்டும், ஆனால் சர்வர் செயலிழக்கிறது. அல்லது 100 சர்வர்கள். எப்படி வெளியேறுவது? நாம் உண்மையில் பூனை இல்லாமல் பயனரை விட்டுவிடப் போகிறோமா?

நிலைமை பயமாக இருக்கிறது, ஆனால் நாங்கள் அதற்கு தயாராக இருக்கிறோம். வரிசையாகச் சொல்கிறேன்.

தேடல் உள்கட்டமைப்பு பல தரவு மையங்களில் அமைந்துள்ளது:

வடிவமைக்கும் போது, ​​ஒரு தரவு மையத்தை மூடுவதற்கான சாத்தியக்கூறுகளை நாங்கள் சேர்க்கிறோம். வாழ்க்கை ஆச்சரியங்கள் நிறைந்தது - எடுத்துக்காட்டாக, ஒரு அகழ்வாராய்ச்சி மூலம் நிலத்தடி கேபிளை வெட்ட முடியும் (ஆம், அது நடந்தது). மீதமுள்ள தரவு மையங்களில் உள்ள திறன் உச்ச சுமைகளைத் தாங்க போதுமானதாக இருக்க வேண்டும்.

ஒற்றை தரவு மையத்தைக் கருத்தில் கொள்வோம். ஒவ்வொரு தரவு மையமும் ஒரே சமநிலை செயல்பாட்டுத் திட்டத்தைக் கொண்டுள்ளது:

ஒரு பேலன்சர் குறைந்தது மூன்று இயற்பியல் சேவையகங்கள். இந்த பணிநீக்கம் நம்பகத்தன்மைக்காக செய்யப்படுகிறது. பேலன்சர்கள் HAProx இல் இயங்குகின்றன.

அதன் உயர் செயல்திறன், குறைந்த ஆதாரத் தேவைகள் மற்றும் பரந்த செயல்பாடு ஆகியவற்றின் காரணமாக நாங்கள் HAProx ஐத் தேர்ந்தெடுத்தோம். எங்கள் தேடல் மென்பொருள் ஒவ்வொரு சேவையகத்திலும் இயங்குகிறது.

ஒரு சர்வர் தோல்வியடையும் வாய்ப்பு குறைவு. ஆனால் உங்களிடம் பல சேவையகங்கள் இருந்தால், குறைந்தபட்சம் ஒன்று குறையும் வாய்ப்பு அதிகரிக்கிறது.

நிஜத்தில் இதுதான் நடக்கிறது: சர்வர்கள் செயலிழக்கச் செய்கின்றன. எனவே, அனைத்து சேவையகங்களின் நிலையை தொடர்ந்து கண்காணிக்க வேண்டியது அவசியம். சேவையகம் பதிலளிப்பதை நிறுத்தினால், அது தானாகவே போக்குவரத்திலிருந்து துண்டிக்கப்படும். இந்த நோக்கத்திற்காக, HAProxy ஒரு உள்ளமைக்கப்பட்ட சுகாதார சோதனையை கொண்டுள்ளது. இது ஒரு வினாடிக்கு ஒருமுறை HTTP கோரிக்கை “/பிங்” மூலம் அனைத்து சேவையகங்களுக்கும் செல்கிறது.

HAProxy இன் மற்றொரு அம்சம்: agent-check ஆனது அனைத்து சேவையகங்களையும் சமமாக ஏற்ற அனுமதிக்கிறது. இதைச் செய்ய, HAProxy அனைத்து சேவையகங்களுடனும் இணைக்கிறது, மேலும் அவை 1 முதல் 100 வரையிலான தற்போதைய சுமையைப் பொறுத்து அவற்றின் எடையைத் திருப்பித் தருகின்றன. செயலாக்கத்திற்கான வரிசையில் உள்ள கோரிக்கைகளின் எண்ணிக்கை மற்றும் செயலியின் சுமை ஆகியவற்றின் அடிப்படையில் எடை கணக்கிடப்படுகிறது.

இப்போது பூனையைக் கண்டுபிடிப்பது பற்றி. இது போன்ற கோரிக்கைகளில் தேடல் முடிவுகள்: /தேட?உரை=கோபம்+பூனை. தேடல் வேகமாக இருக்க, முழு பூனை குறியீடும் RAM இல் பொருந்த வேண்டும். SSD இலிருந்து படிப்பது கூட போதுமான வேகத்தில் இல்லை.

ஒரு காலத்தில், சலுகை தரவுத்தளம் சிறியதாக இருந்தது, அதற்கு ஒரு சர்வரின் ரேம் போதுமானதாக இருந்தது. சலுகை அடிப்படை வளர்ந்ததால், அனைத்தும் இனி இந்த ரேமில் பொருந்தாது, மேலும் தரவு இரண்டு பகுதிகளாக பிரிக்கப்பட்டது: ஷார்ட் 1 மற்றும் ஷார்ட் 2.

ஆனால் இது எப்பொழுதும் நடக்கும்: எந்தவொரு தீர்வும், நல்லதாக இருந்தாலும், மற்ற பிரச்சனைகளுக்கு வழிவகுக்கிறது.

பேலன்சர் இன்னும் எந்த சர்வருக்கும் சென்றது. ஆனால் கோரிக்கை வந்த இயந்திரத்தில், குறியீட்டில் பாதி மட்டுமே இருந்தது. மீதமுள்ளவை மற்ற சேவையகங்களில் இருந்தன. எனவே, சர்வர் சில அண்டை இயந்திரத்திற்கு செல்ல வேண்டியிருந்தது. இரண்டு சேவையகங்களிலிருந்தும் தரவைப் பெற்ற பிறகு, முடிவுகள் ஒன்றிணைக்கப்பட்டு மறுவரிசைப்படுத்தப்பட்டன.

பேலன்சர் கோரிக்கைகளை சமமாக விநியோகிப்பதால், எல்லா சர்வர்களும் தரவை அனுப்பாமல் மறு தரவரிசையில் ஈடுபட்டுள்ளன.

அருகிலுள்ள சேவையகம் இல்லை என்றால் சிக்கல் ஏற்பட்டது. பல்வேறு முன்னுரிமைகள் கொண்ட பல சேவையகங்களை "அண்டை" சேவையகமாகக் குறிப்பிடுவதே தீர்வு. முதலில், தற்போதைய ரேக்கில் உள்ள சேவையகங்களுக்கு கோரிக்கை அனுப்பப்பட்டது. பதில் வரவில்லை என்றால், இந்தத் தரவு மையத்தில் உள்ள அனைத்து சேவையகங்களுக்கும் கோரிக்கை அனுப்பப்படும். இறுதியாக, கோரிக்கை மற்ற தரவு மையங்களுக்கு சென்றது.
முன்மொழிவுகளின் எண்ணிக்கை அதிகரித்ததால், தரவு நான்கு பகுதிகளாக பிரிக்கப்பட்டது. ஆனால் இது வரம்பு இல்லை.

தற்போது, ​​எட்டு துண்டுகளின் உள்ளமைவு பயன்படுத்தப்படுகிறது. கூடுதலாக, இன்னும் அதிக நினைவகத்தை சேமிக்க, குறியீட்டு ஒரு தேடல் பகுதி (தேடலுக்குப் பயன்படுத்தப்படுகிறது) மற்றும் ஒரு துணுக்கு பகுதியாக (தேடலில் ஈடுபடவில்லை) பிரிக்கப்பட்டது.

ஒரு சர்வரில் ஒரே ஒரு ஷார்டுக்கான தகவல் உள்ளது. எனவே, முழு குறியீட்டையும் தேட, நீங்கள் வெவ்வேறு துண்டுகளைக் கொண்ட எட்டு சேவையகங்களில் தேட வேண்டும்.

சேவையகங்கள் கிளஸ்டர்களாக தொகுக்கப்பட்டுள்ளன. ஒவ்வொரு கிளஸ்டரிலும் எட்டு தேடுபொறிகள் மற்றும் ஒரு துணுக்கு சேவையகம் உள்ளது.

துணுக்கு சேவையகம் நிலையான தரவுகளுடன் முக்கிய மதிப்பு தரவுத்தளத்தை இயக்குகிறது. ஆவணங்களை வழங்க அவை தேவைப்படுகின்றன, எடுத்துக்காட்டாக, ஒரு பூனையுடன் ஒரு பூனையின் விளக்கம். தேடல் சேவையகங்களின் நினைவகத்தை ஏற்றாமல் இருக்க தரவு ஒரு தனி சேவையகத்திற்கு சிறப்பாக மாற்றப்படுகிறது.

ஆவண ஐடிகள் ஒரு குறியீட்டிற்குள் மட்டுமே தனித்துவமானது என்பதால், துணுக்குகளில் ஆவணங்கள் இல்லாத சூழ்நிலை ஏற்படலாம். சரி, அல்லது ஒரு ஐடிக்கு வெவ்வேறு உள்ளடக்கம் இருக்கும். எனவே, தேடல் வேலை செய்வதற்கும், முடிவுகள் திரும்பப் பெறுவதற்கும், முழு கிளஸ்டரிலும் நிலைத்தன்மை தேவைப்பட்டது. நிலைத்தன்மையை நாங்கள் எவ்வாறு கண்காணிக்கிறோம் என்பதை கீழே கூறுகிறேன்.

தேடல் பின்வருமாறு கட்டமைக்கப்பட்டுள்ளது: எட்டு சேவையகங்களில் ஏதேனும் ஒரு தேடல் கோரிக்கை வரலாம். அவர் சர்வர் 1 க்கு வந்தார் என்று வைத்துக் கொள்வோம். இந்த சர்வர் அனைத்து வாதங்களையும் செயலாக்குகிறது மற்றும் எதை எப்படி தேடுவது என்பதைப் புரிந்துகொள்கிறது. உள்வரும் கோரிக்கையைப் பொறுத்து, தேவையான தகவல்களுக்கு வெளிப்புற சேவைகளுக்கு கூடுதல் கோரிக்கைகளை சேவையகம் செய்யலாம். ஒரு கோரிக்கையைத் தொடர்ந்து வெளிப்புறச் சேவைகளுக்கான பத்து கோரிக்கைகள் வரை இருக்கலாம்.

தேவையான தகவல்களைச் சேகரித்த பிறகு, சலுகை தரவுத்தளத்தில் ஒரு தேடல் தொடங்குகிறது. இதைச் செய்ய, கிளஸ்டரில் உள்ள எட்டு சேவையகங்களுக்கும் துணை வினவல்கள் செய்யப்படுகின்றன.

பதில்கள் கிடைத்தவுடன், முடிவுகள் இணைக்கப்படும். முடிவில், முடிவுகளை உருவாக்க துணுக்கு சேவையகத்திற்கு இன்னும் பல துணை வினவல்கள் தேவைப்படலாம்.

கிளஸ்டரில் உள்ள தேடல் வினவல்கள் இப்படி இருக்கும்: /shard1?text=angry+cat. கூடுதலாக, படிவத்தின் துணை வினவல்கள் கிளஸ்டரில் உள்ள அனைத்து சேவையகங்களுக்கிடையில் வினாடிக்கு ஒரு முறை தொடர்ந்து செய்யப்படுகின்றன: /நிலை.

விசாரணை /நிலை சேவையகம் இல்லாத சூழ்நிலையைக் கண்டறிகிறது.

தேடுபொறி பதிப்பு மற்றும் குறியீட்டு பதிப்பு அனைத்து சேவையகங்களிலும் ஒரே மாதிரியாக இருப்பதையும் இது கட்டுப்படுத்துகிறது, இல்லையெனில் கிளஸ்டருக்குள் சீரற்ற தரவு இருக்கும்.

ஒரு துணுக்கு சேவையகம் எட்டு தேடுபொறிகளிலிருந்து கோரிக்கைகளை செயலாக்குகிறது என்ற உண்மை இருந்தபோதிலும், அதன் செயலி மிகவும் லேசாக ஏற்றப்படுகிறது. எனவே, நாங்கள் இப்போது துணுக்கு தரவை ஒரு தனி சேவைக்கு மாற்றுகிறோம்.

தரவை மாற்ற, ஆவணங்களுக்கான உலகளாவிய விசைகளை அறிமுகப்படுத்தினோம். ஒரு விசையைப் பயன்படுத்தி மற்றொரு ஆவணத்தின் உள்ளடக்கம் திரும்பப் பெறப்படும் சூழ்நிலை இப்போது சாத்தியமற்றது.

ஆனால் மற்றொரு கட்டிடக்கலைக்கு மாறுவது இன்னும் முழுமையடையவில்லை. இப்போது நாம் அர்ப்பணிக்கப்பட்ட துணுக்கு சேவையகத்திலிருந்து விடுபட விரும்புகிறோம். பின்னர் கிளஸ்டர் கட்டமைப்பிலிருந்து முற்றிலும் விலகிச் செல்லவும். இது எளிதாக அளவிடுவதைத் தொடர அனுமதிக்கும். கூடுதல் போனஸ் குறிப்பிடத்தக்க இரும்பு சேமிப்பு ஆகும்.

இப்போது மகிழ்ச்சியான முடிவுகளுடன் பயங்கரமான கதைகளுக்கு. சர்வர் கிடைக்காத பல நிகழ்வுகளைக் கருத்தில் கொள்வோம்.

பயங்கரமான ஒன்று நடந்தது: ஒரு சேவையகம் கிடைக்கவில்லை

ஒரு சர்வர் கிடைக்கவில்லை என்று வைத்துக்கொள்வோம். பின்னர் கிளஸ்டரில் மீதமுள்ள சேவையகங்கள் தொடர்ந்து பதிலளிக்கலாம், ஆனால் தேடல் முடிவுகள் முழுமையடையாது.

நிலை சரிபார்ப்பு மூலம் /நிலை ஒன்று கிடைக்கவில்லை என்பதை அண்டை சர்வர்கள் புரிந்துகொள்கிறார்கள். எனவே, முழுமையைப் பராமரிக்க, கோரிக்கையின்படி கிளஸ்டரில் உள்ள அனைத்து சேவையகங்களும் /பிங் அவர்களும் கிடைக்கவில்லை என்று பேலன்சரிடம் பதிலளிக்கத் தொடங்குகிறார்கள். கிளஸ்டரில் உள்ள அனைத்து சேவையகங்களும் இறந்துவிட்டன (இது உண்மையல்ல). இது எங்கள் கிளஸ்டர் திட்டத்தின் முக்கிய குறைபாடு - அதனால்தான் நாங்கள் அதிலிருந்து வெளியேற விரும்புகிறோம்.

பிழையுடன் தோல்வியுற்ற கோரிக்கைகள் மற்ற சேவையகங்களில் உள்ள பேலன்சரால் மீண்டும் அனுப்பப்படும்.
பேலன்சர் பயனர் போக்குவரத்தை இறந்த சேவையகங்களுக்கு அனுப்புவதை நிறுத்துகிறது, ஆனால் அவற்றின் நிலையை தொடர்ந்து சரிபார்க்கிறது.

சேவையகம் கிடைக்கும்போது, ​​​​அது பதிலளிக்கத் தொடங்குகிறது /பிங். செயலிழந்த சேவையகங்களிலிருந்து பிங்களுக்கான இயல்பான பதில்கள் வரத் தொடங்கியவுடன், பேலன்சர்கள் பயனர் போக்குவரத்தை அங்கு அனுப்பத் தொடங்குகின்றனர். கிளஸ்டர் செயல்பாடு மீட்டெடுக்கப்பட்டது, ஹர்ரே.

இன்னும் மோசமானது: பல சேவையகங்கள் கிடைக்கவில்லை

தரவு மையத்தில் உள்ள சேவையகங்களின் குறிப்பிடத்தக்க பகுதி வெட்டப்பட்டது. என்ன செய்வது, எங்கு ஓடுவது? சமநிலையாளர் மீண்டும் மீட்புக்கு வருகிறார். ஒவ்வொரு பேலன்ஸரும் தற்போதைய நேரடி சேவையகங்களின் எண்ணிக்கையை தொடர்ந்து நினைவகத்தில் சேமிக்கிறது. தற்போதைய தரவு மையம் செயலாக்கக்கூடிய அதிகபட்ச போக்குவரத்தை இது தொடர்ந்து கணக்கிடுகிறது.

டேட்டா சென்டரில் உள்ள பல சர்வர்கள் செயலிழக்கும்போது, ​​இந்த டேட்டா சென்டரில் எல்லா டிராஃபிக்கையும் செயல்படுத்த முடியாது என்பதை பேலன்சர் உணர்ந்து கொள்கிறார்.

பின்னர் அதிகப்படியான போக்குவரத்து மற்ற தரவு மையங்களுக்கு தோராயமாக விநியோகிக்கத் தொடங்குகிறது. எல்லாம் வேலை செய்கிறது, எல்லோரும் மகிழ்ச்சியாக இருக்கிறார்கள்.

நாங்கள் அதை எப்படி செய்கிறோம்: வெளியீடுகளை வெளியிடுதல்

சேவையில் செய்யப்பட்ட மாற்றங்களை எவ்வாறு வெளியிடுகிறோம் என்பதைப் பற்றி இப்போது பேசலாம். இங்கே நாம் செயல்முறைகளை எளிதாக்கும் பாதையை எடுத்துள்ளோம்: ஒரு புதிய வெளியீட்டை வெளியிடுவது கிட்டத்தட்ட முற்றிலும் தானியங்கு.
திட்டத்தில் குறிப்பிட்ட எண்ணிக்கையிலான மாற்றங்கள் குவிந்தால், ஒரு புதிய வெளியீடு தானாகவே உருவாக்கப்பட்டு அதன் உருவாக்கம் தொடங்குகிறது.

பின்னர் சேவை சோதனைக்கு அனுப்பப்படுகிறது, அங்கு செயல்பாட்டின் நிலைத்தன்மை சரிபார்க்கப்படுகிறது.

அதே நேரத்தில், தானியங்கி செயல்திறன் சோதனை தொடங்கப்பட்டது. இது ஒரு சிறப்பு சேவையால் கையாளப்படுகிறது. நான் இப்போது அதைப் பற்றி பேசமாட்டேன் - அதன் விளக்கம் ஒரு தனி கட்டுரைக்கு தகுதியானது.

சோதனையில் வெளியீடு வெற்றிகரமாக இருந்தால், prestable இல் வெளியீடு தானாகவே தொடங்கப்படும். Prestable என்பது ஒரு சிறப்பு கிளஸ்டர் ஆகும், அங்கு சாதாரண பயனர் போக்குவரத்து இயக்கப்படுகிறது. அது பிழையை அளித்தால், பேலன்சர் உற்பத்திக்கு மீண்டும் கோரிக்கை வைக்கிறது.

prestable இல், மறுமொழி நேரம் அளவிடப்பட்டு, உற்பத்தியில் முந்தைய வெளியீட்டுடன் ஒப்பிடப்படுகிறது. எல்லாம் சரியாக இருந்தால், ஒரு நபர் இணைக்கிறார்: சுமை சோதனையின் வரைபடங்கள் மற்றும் முடிவுகளை சரிபார்த்து, பின்னர் உற்பத்திக்கு உருட்டத் தொடங்குகிறார்.

அனைத்து நல்வாழ்த்துக்களும் பயனருக்குச் செல்கின்றன: A/B சோதனை

சேவையில் மாற்றங்கள் உண்மையான பலன்களைத் தருமா என்பது எப்போதும் தெளிவாகத் தெரியவில்லை. மாற்றங்களின் பயனை அளவிட, மக்கள் A/B சோதனையை கொண்டு வந்தனர். Yandex.Market தேடலில் இது எவ்வாறு செயல்படுகிறது என்பதைப் பற்றி நான் உங்களுக்குச் சொல்கிறேன்.

புதிய செயல்பாட்டை செயல்படுத்தும் புதிய CGI அளவுருவைச் சேர்ப்பதன் மூலம் இது தொடங்குகிறது. எங்கள் அளவுரு இருக்கட்டும்: market_new_functionality=1. குறியீட்டில் கொடி இருந்தால் இந்த செயல்பாட்டை இயக்குவோம்:

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

புதிய செயல்பாடு உற்பத்திக்கு கொண்டு வரப்படுகிறது.

A/B சோதனையை தானியக்கமாக்க, விரிவான தகவலை வழங்கும் ஒரு பிரத்யேக சேவை உள்ளது இங்கே விவரிக்கப்பட்டுள்ளது. சேவையில் ஒரு சோதனை உருவாக்கப்பட்டது. போக்குவரத்து பங்கு அமைக்கப்பட்டுள்ளது, எடுத்துக்காட்டாக, 15%. சதவீதங்கள் வினவல்களுக்காக அமைக்கப்படவில்லை, ஆனால் பயனர்களுக்காக. பரிசோதனையின் கால அளவும் சுட்டிக்காட்டப்படுகிறது, எடுத்துக்காட்டாக, ஒரு வாரம்.

பல சோதனைகளை ஒரே நேரத்தில் இயக்கலாம். அமைப்புகளில், பிற சோதனைகளுடன் குறுக்குவெட்டு சாத்தியமா என்பதை நீங்கள் குறிப்பிடலாம்.

இதன் விளைவாக, சேவை தானாகவே ஒரு வாதத்தைச் சேர்க்கிறது market_new_functionality=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