இணைய கோரிக்கைகளை விரைவுபடுத்தி நிம்மதியாக தூங்குங்கள்

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

டெவூப்ஸ் 2019 இல் சிக்கலான அமைப்புகளை உருவாக்குவதற்கும் ஆதரிப்பதற்கும் நெட்ஃபிக்ஸ் அணுகுமுறையின் தெளிவான உதாரணம் வழங்கப்பட்டது. செர்ஜி ஃபெடோரோவ் - நெட்ஃபிக்ஸ் மேம்பாட்டு இயக்குனர். நிஸ்னி நோவ்கோரோட் மாநில பல்கலைக்கழகத்தின் கணக்கீட்டு கணிதம் மற்றும் கணித பீடத்தின் பட்டதாரி. லோபசெவ்ஸ்கி, செர்ஜி, ஓபன் கனெக்டில் முதல் பொறியாளர்களில் ஒருவர் - நெட்ஃபிக்ஸ் இல் CDN குழு. வீடியோ தரவை கண்காணிப்பதற்கும் பகுப்பாய்வு செய்வதற்கும் அவர் அமைப்புகளை உருவாக்கினார், இணைய இணைப்பு வேகத்தை மதிப்பிடுவதற்கான பிரபலமான சேவையை FAST.com ஐத் தொடங்கினார், மேலும் கடந்த சில ஆண்டுகளாக இணைய கோரிக்கைகளை மேம்படுத்துவதில் பணியாற்றி வருகிறார், இதனால் பயனர்களுக்கு முடிந்தவரை விரைவாக வேலை செய்யும் வகையில் இணைய கோரிக்கைகளை மேம்படுத்தினார்.

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

அவரது அறிக்கையில், செர்ஜி விரிவாகப் பேசினார்

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

இந்த கேள்விகளுக்கான பதில்கள் பெரிய நிறுவனங்களில் பணிபுரிபவர்களுக்கு மட்டுமல்ல.

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

அடுத்தது பேச்சாளரின் பார்வையில் இருந்து கதை.

இணைய வேகத்தின் முக்கியத்துவம்

இணைய கோரிக்கைகளின் வேகம் வணிகத்துடன் நேரடியாக தொடர்புடையது. ஷாப்பிங் துறையை கவனியுங்கள்: அமேசான் 2009 இல் பேசினார்100ms தாமதம் விற்பனையில் 1% இழப்பை ஏற்படுத்துகிறது.

மொபைல் தளங்கள் மற்றும் பயன்பாடுகளைத் தொடர்ந்து அதிகமான மொபைல் சாதனங்கள் உள்ளன. உங்கள் பக்கம் ஏற்றப்படுவதற்கு 3 வினாடிகளுக்கு மேல் எடுத்தால், உங்கள் பயனர்களில் பாதியை இழக்க நேரிடும். உடன் ஜூலை 2018 தேடல் முடிவுகளில் உங்கள் பக்கத்தின் ஏற்றுதல் வேகத்தை Google கணக்கில் எடுத்துக்கொள்கிறது: பக்கம் வேகமாக இருந்தால், கூகிளில் அதன் நிலை அதிகமாகும்.

தாமதம் முக்கியமான நிதி நிறுவனங்களில் இணைப்பு வேகமும் முக்கியமானது. 2015 இல், ஹைபர்னியா நெட்வொர்க்குகள் முடிந்தது நியூயார்க் மற்றும் லண்டன் இடையே $400 மில்லியன் கேபிள் நகரங்களுக்கு இடையே உள்ள தாமதத்தை 6ms குறைக்கிறது. 66 எம்எஸ் தாமதக் குறைப்புக்கு $1 மில்லியன் என்று கற்பனை செய்து பாருங்கள்!

படி ஆய்வு, 5 Mbit/s க்கும் அதிகமான இணைப்பு வேகம், ஒரு பொதுவான வலைத்தளத்தின் ஏற்றுதல் வேகத்தை நேரடியாகப் பாதிக்காது. இருப்பினும், இணைப்பு தாமதத்திற்கும் பக்க ஏற்றுதல் வேகத்திற்கும் இடையே ஒரு நேரியல் தொடர்பு உள்ளது:

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

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

நெட்ஃபிக்ஸ் உள்ளே

ஆயிரக்கணக்கான வெவ்வேறு சாதனங்கள் Netflix பயன்பாடுகளை ஆதரிக்கின்றன. ஆண்ட்ராய்டு, iOS, டிவி மற்றும் இணைய உலாவிகளுக்கான கிளையண்டின் தனித்தனி பதிப்புகளை உருவாக்கும் நான்கு வெவ்வேறு குழுக்களால் அவை உருவாக்கப்பட்டுள்ளன. மேலும் பயனர் அனுபவத்தை மேம்படுத்துவதற்கும் தனிப்பயனாக்குவதற்கும் நாங்கள் நிறைய முயற்சி செய்கிறோம். இதைச் செய்ய, நாங்கள் நூற்றுக்கணக்கான A/B சோதனைகளை இணையாக இயக்குகிறோம்.

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

விளக்கத்துடன் வீடியோவிற்கான இணைப்பு (6:04-6:23)

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

எங்கள் உள்கட்டமைப்பின் மற்றொரு முக்கிய அங்கம் ஓபன் கனெக்ட் சிடிஎன் ஆகும், இது இறுதிப் பயனருக்கு நிலையான உள்ளடக்கத்தை வழங்குகிறது - வீடியோக்கள், படங்கள், கிளையன்ட் குறியீடு போன்றவை. CDN தனிப்பயன் சேவையகங்களில் (OCA - Open Connect Appliance) அமைந்துள்ளது. உள்ளே NGINX மற்றும் சேவைகளின் தொகுப்புடன் உகந்த FreeBSD இல் இயங்கும் SSD மற்றும் HDD டிரைவ்களின் வரிசைகள் உள்ளன. வன்பொருள் மற்றும் மென்பொருள் கூறுகளை நாங்கள் வடிவமைத்து மேம்படுத்துகிறோம், இதனால் CDN சேவையகம் பயனர்களுக்கு முடிந்த அளவு தரவை அனுப்ப முடியும்.

இணைய போக்குவரத்து பரிமாற்ற புள்ளியில் (இன்டர்நெட் எக்ஸ்சேஞ்ச் - IX) இந்த சேவையகங்களின் "சுவர்" இதுபோல் தெரிகிறது:

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

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

AWS சேவைகளின் தொகுப்பானது வாடிக்கையாளர்களிடமிருந்து CDN சேவையகங்களுக்கு வீடியோ கோரிக்கைகளை அனுப்புவதற்கும், அதே போல் சேவையகங்களை உள்ளமைப்பதற்கும் பொறுப்பாகும் - உள்ளடக்கம், நிரல் குறியீடு, அமைப்புகள் போன்றவற்றைப் புதுப்பித்தல். இரண்டாவதாக, இன்டர்நெட் எக்ஸ்சேஞ்ச் புள்ளிகளில் உள்ள சேவையகங்களை AWS உடன் இணைக்கும் முதுகெலும்பு நெட்வொர்க்கையும் நாங்கள் உருவாக்கினோம். முதுகெலும்பு நெட்வொர்க் என்பது ஃபைபர் ஆப்டிக் கேபிள்கள் மற்றும் திசைவிகளின் உலகளாவிய வலையமைப்பாகும், அதை நாம் நமது தேவைகளின் அடிப்படையில் வடிவமைத்து கட்டமைக்க முடியும்.

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

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

இணைய முடுக்கம் பற்றி

இன்று, Netflix 3 AWS பகுதிகளைக் கொண்டுள்ளது, மேலும் கிளவுட்க்கான கோரிக்கைகளின் தாமதமானது வாடிக்கையாளர் அருகிலுள்ள பிராந்தியத்திலிருந்து எவ்வளவு தொலைவில் இருக்கிறார் என்பதைப் பொறுத்தது. அதே நேரத்தில், நிலையான உள்ளடக்கத்தை வழங்கப் பயன்படும் பல CDN சேவையகங்கள் எங்களிடம் உள்ளன. டைனமிக் வினவல்களை விரைவுபடுத்த இந்த கட்டமைப்பைப் பயன்படுத்த ஏதேனும் வழி உள்ளதா? இருப்பினும், துரதிருஷ்டவசமாக, இந்தக் கோரிக்கைகளை தேக்ககப்படுத்துவது சாத்தியமில்லை - APIகள் தனிப்பயனாக்கப்பட்டவை மற்றும் ஒவ்வொரு முடிவும் தனிப்பட்டது.

CDN சர்வரில் ப்ராக்ஸியை உருவாக்கி அதன் மூலம் டிராஃபிக்கை அனுப்ப ஆரம்பிக்கலாம். அது வேகமாக இருக்குமா?

பொருள்

பிணைய நெறிமுறைகள் எவ்வாறு செயல்படுகின்றன என்பதை நினைவில் கொள்வோம். இன்று, இணையத்தில் பெரும்பாலான போக்குவரத்து HTTPகளைப் பயன்படுத்துகிறது, இது கீழ் அடுக்கு நெறிமுறைகளான TCP மற்றும் TLS ஐப் பொறுத்தது. ஒரு கிளையன்ட் சேவையகத்துடன் இணைக்க, அது ஒரு கைகுலுக்கலை செய்கிறது, மேலும் பாதுகாப்பான இணைப்பை நிறுவ, கிளையன்ட் சேவையகத்துடன் மூன்று முறை செய்திகளை பரிமாறிக் கொள்ள வேண்டும் மற்றும் தரவை மாற்ற குறைந்தபட்சம் ஒரு முறை. ஒரு சுற்றுப்பயணத்திற்கு (RTT) 100 ms தாமதம் இருந்தால், முதல் பிட் தரவைப் பெற 400 ms ஆகும்:

சிடிஎன் சர்வரில் சான்றிதழ்களை வைத்தால், சிடிஎன் நெருக்கமாக இருந்தால் கிளையன்ட் மற்றும் சர்வர் இடையே கைகுலுக்கும் நேரத்தை கணிசமாகக் குறைக்கலாம். CDN சேவையகத்திற்கான தாமதம் 30ms என்று வைத்துக்கொள்வோம். முதல் பிட்டைப் பெற 220 எம்எஸ் எடுக்கும்:

ஆனால் நன்மைகள் அங்கு முடிவதில்லை. ஒரு இணைப்பு நிறுவப்பட்டதும், TCP நெரிசல் சாளரத்தை அதிகரிக்கிறது (இணையாக அந்த இணைப்பில் அனுப்பக்கூடிய தகவல்களின் அளவு). தரவு பாக்கெட் தொலைந்துவிட்டால், TCP நெறிமுறையின் உன்னதமான செயலாக்கங்கள் (TCP New Reno போன்றவை) திறந்த "சாளரத்தை" பாதியாக குறைக்கின்றன. நெரிசல் சாளரத்தின் வளர்ச்சி மற்றும் இழப்பில் இருந்து மீள்வதற்கான வேகம் மீண்டும் சேவையகத்திற்கான தாமதத்தை (RTT) சார்ந்துள்ளது. இந்த இணைப்பு CDN சர்வர் வரை சென்றால், இந்த மீட்பு வேகமாக இருக்கும். அதே நேரத்தில், பாக்கெட் இழப்பு என்பது ஒரு நிலையான நிகழ்வு, குறிப்பாக வயர்லெஸ் நெட்வொர்க்குகளுக்கு.

இணைய அலைவரிசை குறைக்கப்படலாம், குறிப்பாக பீக் ஹவர்ஸில், பயனர்களின் ட்ராஃபிக் காரணமாக, போக்குவரத்து நெரிசல்கள் ஏற்படலாம். இருப்பினும், சில கோரிக்கைகளுக்கு மற்றவற்றை விட முன்னுரிமை கொடுக்க இணையத்தில் வழி இல்லை. எடுத்துக்காட்டாக, பிணையத்தை ஏற்றும் “கனமான” தரவு ஸ்ட்ரீம்களைக் காட்டிலும் சிறிய மற்றும் தாமத உணர்திறன் கோரிக்கைகளுக்கு முன்னுரிமை கொடுங்கள். இருப்பினும், எங்கள் விஷயத்தில், எங்கள் சொந்த முதுகெலும்பு நெட்வொர்க் இருப்பதால், கோரிக்கை பாதையின் ஒரு பகுதியாக - CDN மற்றும் கிளவுட் இடையே இதைச் செய்ய அனுமதிக்கிறது, மேலும் அதை முழுமையாக உள்ளமைக்க முடியும். சிறிய மற்றும் தாமத உணர்திறன் பாக்கெட்டுகளுக்கு முன்னுரிமை அளிக்கப்படுவதை நீங்கள் உறுதிசெய்யலாம், மேலும் பெரிய தரவு ஓட்டங்கள் சிறிது நேரம் கழித்து செல்லும். CDN வாடிக்கையாளருடன் நெருக்கமாக இருப்பதால், செயல்திறன் அதிகமாகும்.

பயன்பாட்டு நிலை நெறிமுறைகள் (OSI நிலை 7) தாமதத்தின் மீதும் தாக்கத்தை ஏற்படுத்துகின்றன. HTTP/2 போன்ற புதிய நெறிமுறைகள் இணையான கோரிக்கைகளின் செயல்திறனை மேம்படுத்துகின்றன. இருப்பினும், புதிய நெறிமுறைகளை ஆதரிக்காத பழைய சாதனங்களுடன் Netflix கிளையண்டுகள் எங்களிடம் உள்ளன. அனைத்து கிளையண்டுகளையும் மேம்படுத்தவோ அல்லது உகந்ததாக உள்ளமைக்கவோ முடியாது. அதே நேரத்தில், CDN ப்ராக்ஸி மற்றும் கிளவுட் இடையே முழுமையான கட்டுப்பாடு மற்றும் புதிய, உகந்த நெறிமுறைகள் மற்றும் அமைப்புகளைப் பயன்படுத்தும் திறன் உள்ளது. பழைய நெறிமுறைகளைக் கொண்ட பயனற்ற பகுதி கிளையன்ட் மற்றும் CDN சேவையகத்திற்கு இடையே மட்டுமே செயல்படும். மேலும், CDN மற்றும் கிளவுட் இடையே ஏற்கனவே நிறுவப்பட்ட இணைப்பில் மல்டிபிளக்ஸ் கோரிக்கைகளை செய்யலாம், TCP மட்டத்தில் இணைப்பு பயன்பாட்டை மேம்படுத்தலாம்:

நாங்கள் அளவிடுகிறோம்

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

• வேகம்: ப்ராக்ஸி வேகமாக இருக்குமா?
• நம்பகத்தன்மை: அடிக்கடி உடையுமா?
• சிக்கலான: பயன்பாடுகளுடன் எவ்வாறு ஒருங்கிணைப்பது?
• செலவு: கூடுதல் உள்கட்டமைப்பைப் பயன்படுத்துவதற்கு எவ்வளவு செலவாகும்?

முதல் புள்ளியை மதிப்பிடுவதற்கான எங்கள் அணுகுமுறையை விரிவாகக் கருதுவோம். மீதமுள்ளவை அதே வழியில் கையாளப்படுகின்றன.

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

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

இரண்டு முறைகளின் நன்மைகளையும் எவ்வாறு இணைப்பது?

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

1. விண்ணப்பத்தை ஏற்றி, ஆரம்ப செயல்பாட்டை முடித்த சிறிது நேரத்திலேயே, நாங்கள் எங்கள் ஆய்வுகளை இயக்குகிறோம்.
2. வாடிக்கையாளர் சேவையகத்திற்கு ஒரு கோரிக்கையை வைக்கிறார் மற்றும் சோதனைக்கான "செய்முறையை" பெறுகிறார். செய்முறை என்பது HTTP(கள்) கோரிக்கையைச் செய்ய வேண்டிய URLகளின் பட்டியலாகும். கூடுதலாக, செய்முறை கோரிக்கை அளவுருக்களை உள்ளமைக்கிறது: கோரிக்கைகளுக்கு இடையே உள்ள தாமதங்கள், கோரப்பட்ட தரவின் அளவு, HTTP(கள்) தலைப்புகள் போன்றவை. அதே நேரத்தில், பல்வேறு சமையல் குறிப்புகளை இணையாகச் சோதிக்கலாம் - உள்ளமைவைக் கோரும்போது, ​​எந்த செய்முறையை வெளியிடுவது என்பதை நாங்கள் தோராயமாக தீர்மானிக்கிறோம்.
3. கிளையண்டில் உள்ள பிணைய ஆதாரங்களின் செயலில் பயன்படுத்தப்படுவதில் முரண்படாமல் இருக்க, ஆய்வு வெளியீட்டு நேரம் தேர்ந்தெடுக்கப்பட்டது. முக்கியமாக, கிளையன்ட் செயலில் இல்லாத போது நேரம் தேர்ந்தெடுக்கப்படுகிறது.
4. செய்முறையைப் பெற்ற பிறகு, கிளையன்ட் ஒவ்வொரு URL களுக்கும் இணையாக கோரிக்கைகளை வைக்கிறார். ஒவ்வொரு முகவரிக்கான கோரிக்கையும் மீண்டும் மீண்டும் செய்யப்படலாம் - என்று அழைக்கப்படும். "துடிப்புகள்". முதல் துடிப்பில், இணைப்பை நிறுவுவதற்கும் தரவைப் பதிவிறக்குவதற்கும் எவ்வளவு நேரம் எடுத்தது என்பதை அளவிடுகிறோம். இரண்டாவது துடிப்பில், ஏற்கனவே நிறுவப்பட்ட இணைப்பில் தரவை ஏற்றுவதற்கு எடுக்கும் நேரத்தை அளவிடுகிறோம். மூன்றாவது முன், நாம் தாமதத்தை அமைக்கலாம் மற்றும் மறு இணைப்பை நிறுவுவதற்கான வேகத்தை அளவிடலாம்.

   சோதனையின் போது, ​​சாதனம் பெறக்கூடிய அனைத்து அளவுருக்களையும் நாங்கள் அளவிடுகிறோம்:

   • DNS கோரிக்கை நேரம்;
   • TCP இணைப்பு அமைவு நேரம்;
   • TLS இணைப்பு அமைவு நேரம்;
   • தரவு முதல் பைட் பெறும் நேரம்;
   • மொத்த ஏற்றுதல் நேரம்;
   • நிலை முடிவு குறியீடு.
5. அனைத்து பருப்புகளும் முடிந்த பிறகு, மாதிரியானது பகுப்பாய்வுக்கான அனைத்து அளவீடுகளையும் ஏற்றுகிறது.

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

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

நடைமுறையில் சோதனைக் கோட்பாடு: முன்மாதிரி

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

• ப்ராக்ஸி முன்மாதிரி உருவாக்கவும்;
• ஒரு CDN இல் முன்மாதிரி வைக்கவும்;
• ஒரு குறிப்பிட்ட CDN சேவையகத்தில் கிளையண்டுகளை ப்ராக்ஸிக்கு எவ்வாறு வழிநடத்துவது என்பதைத் தீர்மானித்தல்;
• ப்ராக்ஸி இல்லாமல் AWS இல் உள்ள கோரிக்கைகளுடன் செயல்திறனை ஒப்பிடுக.

முன்மொழியப்பட்ட தீர்வின் செயல்திறனை முடிந்தவரை விரைவாக மதிப்பிடுவதே பணி. நல்ல நெட்வொர்க்கிங் லைப்ரரிகள் இருப்பதால் முன்மாதிரியை செயல்படுத்த Go ஐ தேர்வு செய்தோம். ஒவ்வொரு CDN சேவையகத்திலும், சார்புகளைக் குறைப்பதற்கும் ஒருங்கிணைப்பை எளிதாக்குவதற்கும் ப்ரோடோடைப் ப்ராக்ஸியை நிலையான பைனரியாக நிறுவியுள்ளோம். ஆரம்ப செயலாக்கத்தில், முடிந்தவரை நிலையான கூறுகளைப் பயன்படுத்தினோம் மற்றும் HTTP/2 இணைப்பு பூலிங் மற்றும் மல்டிபிளெக்சிங் கோரிக்கைக்கு சிறிய மாற்றங்களைப் பயன்படுத்தினோம்.

AWS பகுதிகளுக்கு இடையில் சமநிலைப்படுத்த, நாங்கள் புவியியல் DNS தரவுத்தளத்தைப் பயன்படுத்தினோம், இது வாடிக்கையாளர்களை சமநிலைப்படுத்தப் பயன்படுத்தப்பட்டது. கிளையண்டிற்கான CDN சேவையகத்தைத் தேர்ந்தெடுக்க, Internet Exchange (IX) சேவையகங்களுக்கு TCP Anycast ஐப் பயன்படுத்துகிறோம். இந்த விருப்பத்தில், அனைத்து CDN சேவையகங்களுக்கும் ஒரு IP முகவரியைப் பயன்படுத்துகிறோம், மேலும் கிளையன்ட் குறைந்தபட்ச IP ஹாப்களுடன் CDN சேவையகத்திற்கு அனுப்பப்படுவார். இணைய வழங்குநர்களால் (ISPகள்) நிறுவப்பட்ட CDN சேவையகங்களில், TCP Anycast ஐ உள்ளமைக்க ரூட்டரின் மீது எங்களிடம் கட்டுப்பாடு இல்லை, எனவே நாங்கள் பயன்படுத்துகிறோம் அதே தர்க்கம், இது வீடியோ ஸ்ட்ரீமிங்கிற்காக வாடிக்கையாளர்களை இணைய வழங்குநர்களிடம் வழிநடத்துகிறது.

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

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

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

இதன் விளைவாக, நாங்கள் பல முக்கியமான விஷயங்களைச் செய்தோம்:

1. CDN ப்ராக்ஸி மூலம் கிளையண்டுகளிடமிருந்து கிளவுட்க்கான கோரிக்கைகளின் எதிர்பார்க்கப்படும் செயல்திறனை மதிப்பீடு செய்தோம்.
2. அனைத்து வகையான சாதனங்களிலிருந்தும் உண்மையான வாடிக்கையாளர்களிடமிருந்து தரவைப் பெற்றோம்.
3. கோட்பாடு 100% உறுதிப்படுத்தப்படவில்லை என்பதையும், CDN ப்ராக்ஸியுடன் ஆரம்ப சலுகை எங்களுக்கு வேலை செய்யாது என்பதையும் நாங்கள் உணர்ந்தோம்.
4. நாங்கள் ஆபத்துக்களை எடுக்கவில்லை - வாடிக்கையாளர்களுக்கான உற்பத்தி உள்ளமைவுகளை நாங்கள் மாற்றவில்லை.
5. எதுவும் உடைக்கப்படவில்லை.

முன்மாதிரி 2.0

எனவே, வரைதல் பலகைக்குத் திரும்பி, செயல்முறையை மீண்டும் செய்யவும்.

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

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

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

1. கிளையன்ட் ஹோஸ்ட்டைப் பயன்படுத்தி DNS சேவையகத்திற்கு கோரிக்கை வைக்கிறது, எடுத்துக்காட்டாக api.netflix.xom.
2. கோரிக்கை எங்கள் DNS சேவையகத்திற்கு வருகிறது
3. இந்த கிளையண்டிற்கு எந்த பாதை வேகமாக உள்ளது என்பதை DNS சர்வர் அறிந்து அதனுடன் தொடர்புடைய IP முகவரியை வழங்குகிறது.

தீர்வு கூடுதல் சிக்கலைக் கொண்டுள்ளது: சர்வாதிகார DNS வழங்குநர்கள் கிளையண்டின் IP முகவரியைக் காணவில்லை மற்றும் கிளையன்ட் பயன்படுத்தும் சுழல்நிலை தீர்வின் IP முகவரியை மட்டுமே படிக்க முடியும்.

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

தீர்க்க, நாங்கள் அதே மாதிரிகளைப் பயன்படுத்துகிறோம், ஒவ்வொரு சுழல்நிலை தீர்வுகளுக்கும் கிளையன்ட்களின் அளவீட்டு முடிவுகளை ஒருங்கிணைத்து, இந்த குழுவை எங்கு அனுப்புவது என்பதைத் தீர்மானிக்கிறோம் - TCP Anycast ஐப் பயன்படுத்தி IX மூலம் ப்ராக்ஸி, ISP ப்ராக்ஸி மூலம் அல்லது நேரடியாக மேகக்கணிக்கு.

நாங்கள் பின்வரும் அமைப்பைப் பெறுகிறோம்:

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

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

இதன் விளைவாக, முடிவுகளை ஒப்பிட்டு, செயல்திறனைப் பற்றிய மதிப்பீட்டைப் பெறுகிறோம்:

இதன் விளைவாக, நாங்கள் பல முக்கியமான விஷயங்களைக் கற்றுக்கொண்டோம்:

1. டிஎன்எஸ் ஸ்டீயரிங் மூலம் கிளையண்டுகளிடமிருந்து கிளவுட்க்கான கோரிக்கைகளின் எதிர்பார்க்கப்படும் செயல்திறனை மதிப்பீடு செய்தோம்.
2. அனைத்து வகையான சாதனங்களிலிருந்தும் உண்மையான வாடிக்கையாளர்களிடமிருந்து தரவைப் பெற்றோம்.
3. முன்மொழியப்பட்ட யோசனையின் செயல்திறன் நிரூபிக்கப்பட்டுள்ளது.
4. நாங்கள் ஆபத்துக்களை எடுக்கவில்லை - வாடிக்கையாளர்களுக்கான உற்பத்தி உள்ளமைவுகளை நாங்கள் மாற்றவில்லை.
5. எதுவும் உடைக்கப்படவில்லை.

இப்போது கடினமான பகுதியைப் பற்றி - நாங்கள் அதை உற்பத்தியில் தொடங்குகிறோம்

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

இவை அனைத்துடனும், அமைப்பின் வளர்ச்சி, வரிசைப்படுத்தல் மற்றும் முழு ஆதரவிற்கும் பொறுப்பான 3 பொறியாளர்கள் குழுவில் உள்ளனர்.

எனவே, அமைதியான மற்றும் ஆரோக்கியமான தூக்கம் பற்றி தொடர்ந்து பேசுவோம்.

வளர்ச்சியைத் தொடர்வது மற்றும் உங்கள் முழு நேரத்தையும் ஆதரவில் செலவிடாமல் இருப்பது எப்படி? எங்கள் அணுகுமுறை 3 கொள்கைகளை அடிப்படையாகக் கொண்டது:

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

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

நிச்சயமாக, பின்னடைவு இருந்தபோதிலும், வளர்ச்சியின் போது நாங்கள் தெளிவான ஒழுக்கத்தை பின்பற்றுகிறோம்:

1. மாதிரி சோதனை.
2. ஏ/பி சோதனை அல்லது கேனரிஸ்.
3. முற்போக்கான வெளியீடு.

மாதிரிகள் மூலம், அணுகுமுறை விவரிக்கப்பட்டுள்ளது - மாற்றங்கள் முதலில் தனிப்பயனாக்கப்பட்ட செய்முறையைப் பயன்படுத்தி சோதிக்கப்படுகின்றன.

கேனரி சோதனைக்கு, மாற்றங்களுக்கு முன்னும் பின்னும் கணினி எவ்வாறு செயல்படுகிறது என்பதை ஒப்பிடக்கூடிய ஒப்பிடக்கூடிய ஜோடி சேவையகங்களைப் பெற வேண்டும். இதைச் செய்ய, எங்கள் பல CDN தளங்களிலிருந்து, ஒப்பிடக்கூடிய டிராஃபிக்கைப் பெறும் ஜோடி சேவையகங்களை நாங்கள் தேர்ந்தெடுக்கிறோம்:

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

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

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

• வாடிக்கையாளர்களிடமிருந்து - அமர்வுகள் மற்றும் கோரிக்கைகளின் எண்ணிக்கை, வீழ்ச்சி விகிதங்கள்;
• ப்ராக்ஸி - கோரிக்கைகளின் எண்ணிக்கை மற்றும் நேரம் பற்றிய புள்ளிவிவரங்கள்;
• DNS - கோரிக்கைகளின் எண் மற்றும் முடிவுகள்;
• கிளவுட் எட்ஜ் - கிளவுட்டில் கோரிக்கைகளை செயலாக்குவதற்கான எண் மற்றும் நேரம்.

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

நாங்கள் கண்காணிக்கிறோம்

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

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

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

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

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

• வாடிக்கையாளர் வீழ்ச்சி சதவீதம் - வாடிக்கையாளர் நடத்தை மதிப்பீடு;
• சதவீத ஆய்வு பிழைகள் - பிணைய கூறுகளின் நிலைத்தன்மை தரவு.

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

1. எங்கள் ப்ராக்ஸி வேலை செய்யவில்லை என்றால் கிளையன்ட் ஃபால்பேக் உள்ளது.
2. சிக்கல்களுக்கு பதிலளிக்கும் தானியங்கி திசைமாற்றி அமைப்பு உள்ளது.

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

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

உதாரணங்கள்:

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

எனவே, கணினி ஆதரவின் கொள்கைகளை பின்வருமாறு உருவாக்கலாம்:

• முறிவுகளின் அளவைக் குறைத்தல்;
• அளவீடுகளை சேகரித்தல்;
• எங்களால் முடிந்தால், முறிவுகளை தானாகவே சரிசெய்கிறோம்;
• அது முடியாவிட்டால், நாங்கள் உங்களுக்கு அறிவிப்போம்;
• விரைவான பதிலுக்காக டாஷ்போர்டுகள் மற்றும் டிரேஜ் டூல்செட் ஆகியவற்றில் பணிபுரிந்து வருகிறோம்.

கற்றுக்கொண்ட பாடங்கள்

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

எங்கள் அனுபவத்தின் அடிப்படையில், பின்வருவனவற்றை நாங்கள் பரிந்துரைக்கலாம்:

1. உங்கள் உள்ளுணர்வை நம்பாதீர்கள்.

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

2. உற்பத்தியிலிருந்து தரவைப் பெறுங்கள்.

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

3. மற்றவர்களின் ஆலோசனை மற்றும் முடிவுகளைப் பின்பற்ற வேண்டாம் - உங்கள் சொந்த தரவைச் சேகரிக்கவும்.

   தரவைச் சேகரித்தல் மற்றும் பகுப்பாய்வு செய்வதற்கான கொள்கைகளைப் பின்பற்றவும், ஆனால் மற்றவர்களின் முடிவுகள் மற்றும் அறிக்கைகளை கண்மூடித்தனமாக ஏற்றுக்கொள்ளாதீர்கள். உங்கள் பயனர்களுக்கு என்ன வேலை செய்கிறது என்பதை நீங்கள் மட்டுமே தெரிந்து கொள்ள முடியும். உங்கள் அமைப்புகளும் உங்கள் வாடிக்கையாளர்களும் மற்ற நிறுவனங்களிலிருந்து கணிசமாக வேறுபட்டிருக்கலாம். அதிர்ஷ்டவசமாக, பகுப்பாய்வு கருவிகள் இப்போது கிடைக்கின்றன மற்றும் பயன்படுத்த எளிதானது. நீங்கள் பெறும் முடிவுகள் Netflix, Facebook, Akamai மற்றும் பிற நிறுவனங்கள் கூறுவது போல் இல்லாமல் இருக்கலாம். எங்கள் விஷயத்தில், TLS, HTTP2 அல்லது DNS கோரிக்கைகளின் புள்ளிவிவரங்களின் செயல்திறன் Facebook, Uber, Akamai ஆகியவற்றின் முடிவுகளிலிருந்து வேறுபடுகிறது - ஏனெனில் எங்களிடம் வெவ்வேறு சாதனங்கள், கிளையண்டுகள் மற்றும் தரவு ஓட்டங்கள் உள்ளன.

4. தேவையில்லாமல் ஃபேஷன் போக்குகளைப் பின்பற்றி செயல்திறனை மதிப்பிடாதீர்கள்.

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

5. புதிய பயன்பாடுகளுக்கு தயாராகுங்கள்.

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

   • AWS பகுதிகள் முழுவதும் போக்குவரத்தை சமப்படுத்தவும் செலவுகளைக் குறைக்கவும்;
   • CDN நிலைத்தன்மையை மாதிரியாக்க;
   • DNS ஐ கட்டமைக்க;
   • TLS/TCP ஐ உள்ளமைக்க.

முடிவுக்கு

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

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

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

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

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

இந்த ஆண்டு மாநாடு ஜூலை 6 முதல் 10 வரை நடைபெறும் ஆன்லைன் வடிவத்தில். DevOps இன் தந்தைகளில் ஒருவரான ஜான் வில்லிஸிடம் நீங்கள் கேள்விகளைக் கேட்கலாம்!

ஆதாரம்: www.habr.com