வணக்கம், ஹப்ர்! கடந்த இரண்டு மாதங்களாக நாங்கள் மிகவும் சுவாரஸ்யமான சூழ்நிலையில் வாழ்ந்து வருகிறோம், எங்கள் உள்கட்டமைப்பு அளவிடுதல் கதையைப் பகிர்ந்து கொள்ள விரும்புகிறேன். இந்த நேரத்தில், SberMarket ஆர்டர்களில் 4 மடங்கு வளர்ந்துள்ளது மற்றும் 17 புதிய நகரங்களில் சேவையை அறிமுகப்படுத்தியது. மளிகைப் பொருட்களை விநியோகிப்பதற்கான தேவையின் வெடிப்பு வளர்ச்சியால், எங்கள் உள்கட்டமைப்பை அளவிட வேண்டியிருந்தது. வெட்டு கீழ் மிகவும் சுவாரஸ்யமான மற்றும் பயனுள்ள முடிவுகளை பற்றி படிக்கவும்.
என் பெயர் டிமா பாபிலேவ், நான் SberMarket இன் தொழில்நுட்ப இயக்குனர். இது எங்கள் வலைப்பதிவில் முதல் இடுகை என்பதால், என்னைப் பற்றியும் நிறுவனத்தைப் பற்றியும் சில வார்த்தைகளைச் சொல்கிறேன். கடந்த இலையுதிர்காலத்தில் நான் இளம் ரன்னட் தலைவர்களுக்கான போட்டியில் பங்கேற்றேன். போட்டிக்கு ஐ SberMarket இல் நாங்கள் உள் கலாச்சாரம் மற்றும் சேவை மேம்பாட்டிற்கான அணுகுமுறையை எவ்வாறு பார்க்கிறோம் என்பது பற்றி. போட்டியில் வெற்றிபெற முடியவில்லை என்றாலும், தகவல் தொழில்நுட்பச் சூழலின் வளர்ச்சிக்கான அடிப்படைக் கொள்கைகளை நானே வகுத்துக் கொண்டேன்.
ஒரு குழுவை நிர்வகிக்கும் போது, வணிகத்திற்கு என்ன தேவைகள் மற்றும் ஒவ்வொரு தனிப்பட்ட டெவலப்பரின் தேவைகளுக்கும் இடையில் சமநிலையைக் கண்டறிவது முக்கியம். இப்போது SberMarket ஆண்டுக்கு 13 முறை வளர்ந்து வருகிறது, மேலும் இது தயாரிப்பை பாதிக்கிறது, தொடர்ந்து வளர்ச்சியின் அளவையும் வேகத்தையும் அதிகரிக்க வேண்டும். இது இருந்தபோதிலும், பூர்வாங்க பகுப்பாய்வு மற்றும் தரக் குறியீட்டு முறைக்கு டெவலப்பர்களுக்கு போதுமான நேரத்தை நாங்கள் ஒதுக்குகிறோம். உருவாக்கப்பட்ட அணுகுமுறை வேலை செய்யும் தயாரிப்பை உருவாக்குவதில் மட்டுமல்லாமல், அதன் மேலும் அளவிடுதல் மற்றும் மேம்பாட்டிற்கும் உதவுகிறது. இந்த வளர்ச்சியின் விளைவாக, SberMarket ஏற்கனவே மளிகை விநியோக சேவைகளில் முன்னணியில் உள்ளது: பிப்ரவரி தொடக்கத்தில் சுமார் 18 இருந்தபோதிலும், ஒவ்வொரு நாளும் சுமார் 3500 ஆயிரம் ஆர்டர்களை நாங்கள் வழங்குகிறோம்.
ஒரு நாள், ஒரு வாடிக்கையாளர் SberMarket கூரியரிடம் மளிகைப் பொருட்களைத் தொடர்பு இல்லாமல் பால்கனிக்கு வழங்குமாறு கேட்டார்.
ஆனால் விவரங்களுக்கு செல்லலாம். கடந்த சில மாதங்களாக, எங்கள் நிறுவனத்தின் உள்கட்டமைப்பை நாங்கள் தீவிரமாக அளந்து வருகிறோம். இந்த தேவை வெளிப்புற மற்றும் உள் காரணிகளால் விளக்கப்பட்டது. வாடிக்கையாளர் தளத்தின் விரிவாக்கத்துடன், இணைக்கப்பட்ட கடைகளின் எண்ணிக்கை ஆண்டின் தொடக்கத்தில் 90 இல் இருந்து மே நடுப்பகுதியில் 200 க்கும் அதிகமாக வளர்ந்தது. நிச்சயமாக, நாங்கள் தயாராகிவிட்டோம், முக்கிய உள்கட்டமைப்பை ஒதுக்கினோம், மேலும் யாண்டெக்ஸ் கிளவுட்டில் ஹோஸ்ட் செய்யப்பட்ட அனைத்து மெய்நிகர் இயந்திரங்களின் செங்குத்து மற்றும் கிடைமட்ட அளவிடுதலின் சாத்தியத்தை நாங்கள் எண்ணினோம். இருப்பினும், நடைமுறை காட்டுகிறது: "தவறாக நடக்கக்கூடிய அனைத்தும் தவறாகிவிடும்." இந்த வாரங்களில் நடந்த மிகவும் சுவாரஸ்யமான சூழ்நிலைகளை இன்று பகிர்ந்து கொள்ள விரும்புகிறேன். எங்கள் அனுபவம் உங்களுக்கு பயனுள்ளதாக இருக்கும் என்று நம்புகிறேன்.
அடிமை முழு போர் தயார் நிலையில் உள்ளது
தொற்றுநோய் தொடங்குவதற்கு முன்பே, எங்கள் பின்தள சேவையகங்களுக்கான கோரிக்கைகளின் எண்ணிக்கையில் அதிகரிப்பை எதிர்கொண்டோம். ஹோம் டெலிவரிக்கு மளிகைப் பொருட்களை ஆர்டர் செய்யும் போக்கு வேகத்தை அதிகரிக்கத் தொடங்கியது, மேலும் COVID-19 காரணமாக முதல் சுய-தனிமைப்படுத்தல் நடவடிக்கைகள் அறிமுகப்படுத்தப்பட்டதன் மூலம், நாள் முழுவதும் பணிச்சுமை வியத்தகு முறையில் அதிகரித்தது. பிரதான தரவுத்தளத்தின் முதன்மை சேவையகங்களை விரைவாக இறக்கி, சில வாசிப்பு கோரிக்கைகளை பிரதி சேவையகங்களுக்கு (அடிமை) மாற்ற வேண்டிய அவசியம் ஏற்பட்டது.
இந்த நடவடிக்கைக்கு நாங்கள் முன்கூட்டியே தயார் செய்தோம், அத்தகைய சூழ்ச்சிக்காக 2 அடிமை சேவையகங்கள் ஏற்கனவே தொடங்கப்பட்டுள்ளன. கூட்டாளர்களுடன் தரவைப் பரிமாறிக்கொள்வதற்கான தகவல் ஊட்டங்களை உருவாக்கும் தொகுதிப் பணிகளுக்கு அவை முக்கியமாகப் பயன்படுத்தப்பட்டன. இந்த செயல்முறைகள் கூடுதல் சுமையை உருவாக்கியது மற்றும் இரண்டு மாதங்களுக்கு முன்பு சமன்பாட்டிலிருந்து சரியாக எடுக்கப்பட்டது.
ஸ்லேவில் நகலெடுப்பு ஏற்பட்டதால், பயன்பாடுகள் அவற்றுடன் படிக்க மட்டும் பயன்முறையில் மட்டுமே செயல்பட முடியும் என்ற கருத்தை நாங்கள் கடைபிடித்தோம். பேரிடர் மீட்புத் திட்டம், பேரழிவு ஏற்பட்டால், மாஸ்டருக்குப் பதிலாக ஸ்லேவை ஏற்றி, அனைத்து எழுதுதல் மற்றும் வாசிப்பு கோரிக்கைகளை ஸ்லேவுக்கு மாற்றலாம் என்று கருதுகிறது. இருப்பினும், பகுப்பாய்வுத் துறையின் தேவைகளுக்காக நாங்கள் பிரதிகளைப் பயன்படுத்த விரும்பினோம், எனவே சேவையகங்கள் முழுமையாக படிக்க மட்டுமே நிலைக்கு மாறவில்லை, ஆனால் ஒவ்வொரு ஹோஸ்டுக்கும் அதன் சொந்த பயனர்கள் இருந்தனர், மேலும் சிலருக்கு இடைநிலை கணக்கீடு முடிவுகளைச் சேமிக்க எழுதும் உரிமைகள் இருந்தன.
ஒரு குறிப்பிட்ட சுமை நிலை வரை, http கோரிக்கைகளை செயலாக்கும்போது எழுதுவதற்கும் வாசிப்பதற்கும் போதுமான மாஸ்டர் எங்களிடம் இருந்தது. மார்ச் நடுப்பகுதியில், Sbermarket முற்றிலும் தொலைதூர வேலைக்கு மாற முடிவு செய்தபோது, எங்கள் RPS அதிவேகமாக வளரத் தொடங்கியது. எங்கள் வாடிக்கையாளர்களில் அதிகமானோர் சுயமாக தனிமைப்படுத்தப்பட்டனர் அல்லது வீட்டில் இருந்தே பணிபுரிந்தனர், இது எங்கள் பணிச்சுமை குறிகாட்டிகளை பாதித்தது.
"மாஸ்டர்" இன் செயல்திறன் இனி போதுமானதாக இல்லை, எனவே சில கனமான வாசிப்பு கோரிக்கைகளை பிரதிக்கு மாற்றத் தொடங்கினோம். எஜமானருக்கு எழுதும் கோரிக்கைகளை வெளிப்படையாக அனுப்பவும், அடிமையிடம் கோரிக்கைகளைப் படிக்கவும், நாங்கள் ரூபி ரத்தினத்தைப் பயன்படுத்தினோம்." எழுதும் உரிமைகள் இல்லாமல் _readonly postfix மூலம் ஒரு சிறப்புப் பயனரை உருவாக்கியுள்ளோம். ஆனால் ஹோஸ்ட்களில் ஒன்றின் உள்ளமைவில் ஏற்பட்ட பிழை காரணமாக, பொருத்தமான உரிமைகளைக் கொண்ட ஒரு பயனரின் சார்பாக சில எழுதுதல் கோரிக்கைகள் அடிமை சேவையகத்திற்குச் சென்றன.
பிரச்சனை உடனடியாக வெளிவரவில்லை, ஏனென்றால்... அதிகரித்த சுமை அடிமைகளின் பின்னடைவை அதிகரித்தது. தரவுகளின் முரண்பாடு காலையில் கண்டுபிடிக்கப்பட்டது, இரவு இறக்குமதிக்குப் பிறகு, அடிமைகள் எஜமானருடன் "பிடிக்கவில்லை". சேவையில் அதிக சுமை மற்றும் புதிய கடைகளின் துவக்கத்துடன் தொடர்புடைய இறக்குமதிகள் இதற்குக் காரணம். ஆனால் பல மணிநேர தாமதத்துடன் தரவை அனுப்புவது ஏற்றுக்கொள்ள முடியாதது, மேலும் செயல்முறைகளை இரண்டாவது பகுப்பாய்வு அடிமைக்கு மாற்றினோம், ஏனெனில் அதுоபெரிய வளங்கள் மற்றும் வாசிப்பு கோரிக்கைகளுடன் ஏற்றப்படவில்லை (இதன் மூலம் நகலெடுக்கும் பின்னடைவு இல்லாததை நாமே விளக்கினோம்).
முக்கிய அடிமையின் "பரவலுக்கு" காரணங்களை நாங்கள் கண்டறிந்தபோது, அதே காரணத்திற்காக பகுப்பாய்வு ஏற்கனவே தோல்வியடைந்தது. இரண்டு கூடுதல் சேவையகங்கள் இருந்தபோதிலும், முதன்மை தோல்வி ஏற்பட்டால் சுமைகளை மாற்ற நாங்கள் திட்டமிட்டோம், துரதிர்ஷ்டவசமான பிழை காரணமாக முக்கியமான தருணத்தில் எதுவும் கிடைக்கவில்லை.
ஆனால் நாங்கள் தரவுத்தளத்தை மட்டும் கொட்டவில்லை (அந்த நேரத்தில் மறுசீரமைப்பு சுமார் 5 மணிநேரம் எடுத்தது), ஆனால் முதன்மை சேவையகத்தின் ஸ்னாப்ஷாட் கூட, நாங்கள் 2 மணி நேரத்திற்குள் பிரதியை தொடங்க முடிந்தது. உண்மை, இதற்குப் பிறகு நாங்கள் நீண்ட காலமாக நகலெடுக்கும் பதிவை எதிர்கொண்டோம் (ஏனென்றால் செயல்முறை ஒற்றை-திரிக்கப்பட்ட பயன்முறையில் இயங்குகிறது, ஆனால் இது முற்றிலும் மாறுபட்ட கதை).
முடிவுக்கு: இதுபோன்ற ஒரு சம்பவத்திற்குப் பிறகு, பயனர்களுக்கு எழுதுவதைக் கட்டுப்படுத்தும் நடைமுறையைக் கைவிட்டு, முழு சேவையகத்தையும் படிக்க மட்டுமே என்று அறிவிக்க வேண்டியது அவசியம் என்பது தெளிவாகியது. இந்த அணுகுமுறையால், முக்கியமான நேரங்களில் பிரதிகள் கிடைக்கும் என்பதில் சந்தேகமில்லை.
ஒரு கனமான வினவலைக் கூட மேம்படுத்துவது தரவுத்தளத்தை மீண்டும் உயிர்ப்பிக்கும்
தளத்தில் உள்ள அட்டவணையை நாங்கள் தொடர்ந்து புதுப்பித்தாலும், ஸ்லேவ் சேவையகங்களுக்கு நாங்கள் அனுப்பிய கோரிக்கைகள் மாஸ்டரிடமிருந்து சிறிது தாமதத்தை அனுமதித்தன. "திடீரென்று தூரத்தை விட்டு வெளியேறும்" அடிமைகளின் பிரச்சனையை நாங்கள் கண்டுபிடித்து அகற்றிய நேரம் "உளவியல் தடையை" விட அதிகமாக இருந்தது (இந்த நேரத்தில் விலைகள் புதுப்பிக்கப்பட்டிருக்கலாம், மேலும் வாடிக்கையாளர்கள் காலாவதியான தரவைப் பார்த்திருப்பார்கள்), மேலும் நாங்கள் கட்டாயப்படுத்தப்பட்டோம். அனைத்து கோரிக்கைகளையும் பிரதான தரவுத்தள சேவையகத்திற்கு மாற்றவும். இதன் விளைவாக, தளம் மெதுவாக இருந்தது ... ஆனால் குறைந்தபட்சம் அது வேலை செய்தது. ஸ்லேவ் மீண்டு வரும்போது, தேர்வுமுறையைத் தவிர வேறு வழியில்லை.
ஸ்லேவ் சேவையகங்கள் மீண்டு வரும்போது, நிமிடங்கள் மெதுவாக கடந்துவிட்டன, மாஸ்டர் அதிக சுமையுடன் இருந்தார், மேலும் "Pareto Rule" இன் படி செயலில் உள்ள பணிகளை மேம்படுத்த எங்களின் அனைத்து முயற்சிகளையும் மேற்கொண்டோம்: பெரும்பாலான சுமைகளை உருவாக்கும் TOP கோரிக்கைகளைத் தேர்ந்தெடுத்து சரி செய்யத் தொடங்கினோம். . இது பறக்கும்போதே செய்யப்பட்டது.
ஒரு சுவாரஸ்யமான விளைவு என்னவென்றால், MySQL, திறனுடன் ஏற்றப்பட்டது, செயல்முறைகளில் ஒரு சிறிய முன்னேற்றத்திற்கு கூட பதிலளித்தது. மொத்த சுமையில் 5% மட்டுமே உற்பத்தி செய்யும் இரண்டு வினவல்களை மேம்படுத்துவது ஏற்கனவே குறிப்பிடத்தக்க CPU சுமையைக் காட்டியுள்ளது. இதன் விளைவாக, தரவுத்தளத்துடன் பணிபுரிய மாஸ்டருக்கு ஏற்றுக்கொள்ளக்கூடிய வளங்களை வழங்க முடிந்தது மற்றும் பிரதிகளை மீட்டமைக்க தேவையான நேரத்தைப் பெற முடிந்தது.
முடிவுக்கு: ஒரு சிறிய தேர்வுமுறை கூட பல மணிநேரங்களுக்கு அதிக சுமைகளின் கீழ் "உயிர்வாழ" அனுமதிக்கிறது. பிரதிகளுடன் சேவையகங்களை மீட்டமைக்க இது போதுமானதாக இருந்தது. வினவல் தேர்வுமுறையின் தொழில்நுட்ப பக்கத்தை பின்வரும் இடுகைகளில் ஒன்றில் விவாதிப்போம். எனவே உங்களுக்கு பயனுள்ளதாக இருந்தால் எங்கள் வலைப்பதிவிற்கு குழுசேரவும்.
கூட்டாளர் சேவைகளின் செயல்திறனைக் கண்காணிப்பதை ஒழுங்கமைத்தல்
வாடிக்கையாளர்களிடமிருந்து ஆர்டர்களை நாங்கள் செயல்படுத்துகிறோம், எனவே எங்கள் சேவைகள் மூன்றாம் தரப்பு APIகளுடன் தொடர்ந்து தொடர்பு கொள்கின்றன - இவை SMS அனுப்புவதற்கான நுழைவாயில்கள், கட்டண தளங்கள், ரூட்டிங் அமைப்புகள், ஜியோகோடர், ஃபெடரல் டேக்ஸ் சர்வீஸ் மற்றும் பல அமைப்புகள். சுமை வேகமாக வளரத் தொடங்கியதும், நாங்கள் எங்கள் கூட்டாளர் சேவைகளின் API வரம்புகளுக்குள் செல்லத் தொடங்கினோம், நாங்கள் முன்பு கூட யோசிக்கவில்லை.
எதிர்பாராதவிதமாக கூட்டாளர் சேவைகளின் ஒதுக்கீட்டை மீறுவது உங்கள் சொந்த வேலையில்லா நேரத்துக்கு வழிவகுக்கும். பல APIகள் வரம்புகளை மீறும் வாடிக்கையாளர்களைத் தடுக்கின்றன, மேலும் சில சந்தர்ப்பங்களில், பல கோரிக்கைகள் கூட்டாளியின் தயாரிப்பை ஓவர்லோட் செய்யலாம்.
எடுத்துக்காட்டாக, விநியோகங்களின் எண்ணிக்கை அதிகரித்தபோது, அதனுடன் வரும் சேவைகளால் அவற்றை விநியோகிக்கும் மற்றும் வழிகளை நிர்ணயம் செய்யும் பணிகளைச் சமாளிக்க முடியவில்லை. இதன் விளைவாக, ஆர்டர்கள் செய்யப்பட்டன, ஆனால் வழியை உருவாக்கிய சேவை வேலை செய்யவில்லை. இந்த நிலைமைகளின் கீழ் எங்கள் தளவாட வல்லுநர்கள் கிட்டத்தட்ட சாத்தியமற்றதைச் செய்தார்கள் என்று சொல்ல வேண்டும், மேலும் குழுவின் தெளிவான தொடர்பு தற்காலிக சேவை தோல்விகளை ஈடுசெய்ய உதவியது. ஆனால் இதுபோன்ற ஆர்டர்களை எல்லா நேரத்திலும் கைமுறையாகச் செயல்படுத்துவது நம்பத்தகாதது, மேலும் சில காலத்திற்குப் பிறகு ஆர்டர்களுக்கும் அவற்றைச் செயல்படுத்துவதற்கும் இடையில் ஏற்றுக்கொள்ள முடியாத இடைவெளியை எதிர்கொள்வோம்.
பல நிறுவன நடவடிக்கைகள் எடுக்கப்பட்டன மற்றும் குழுவின் நன்கு ஒருங்கிணைந்த பணி நேரத்தைப் பெற உதவியது, அதே நேரத்தில் நாங்கள் புதிய நிபந்தனைகளை ஏற்றுக்கொண்டோம் மற்றும் சில கூட்டாளர்களிடமிருந்து சேவைகளை நவீனமயமாக்குவதற்காக காத்திருந்தோம். அதிக ட்ராஃபிக் ஏற்பட்டால் அதிக சகிப்புத்தன்மை மற்றும் மூர்க்கத்தனமான விகிதங்களை பெருமைப்படுத்தும் பிற APIகள் உள்ளன. எடுத்துக்காட்டாக, தொடக்கத்தில் டெலிவரி பாயின்டின் முகவரியைத் தீர்மானிக்க நன்கு அறியப்பட்ட மேப்பிங் ஏபிஐ ஒன்றைப் பயன்படுத்தினோம். ஆனால் மாத இறுதியில் நாங்கள் கிட்டத்தட்ட 2 மில்லியன் ரூபிள் ஒரு நேர்த்தியான பில் பெற்றோம். அதன் பிறகு, அதை விரைவாக மாற்ற முடிவு செய்தனர். நான் விளம்பரத்தில் ஈடுபட மாட்டேன், ஆனால் எங்கள் செலவுகள் கணிசமாகக் குறைந்துள்ளன என்று கூறுவேன்.
முடிவுக்கு: அனைத்து கூட்டாளர் சேவைகளின் இயக்க நிலைமைகளைக் கண்காணித்து அவற்றை மனதில் வைத்திருப்பது கட்டாயமாகும். இன்று அவர்கள் உங்களுக்கு "பெரிய விளிம்புடன்" இருப்பதாகத் தோன்றினாலும், நாளை அவர்கள் வளர்ச்சிக்குத் தடையாக இருக்க மாட்டார்கள் என்று அர்த்தமல்ல. மற்றும், நிச்சயமாக, சேவைக்கான அதிகரித்த கோரிக்கைகளின் நிதி விதிமுறைகளை முன்கூட்டியே ஒப்புக்கொள்வது நல்லது.
சில நேரங்களில் அது மாறிவிடும் ""(c) உதவாது
பிரதான தரவுத்தளத்திலோ அல்லது பயன்பாட்டு சேவையகங்களிலோ "காக்"களுக்கு நாங்கள் பழக்கமாகிவிட்டோம், ஆனால் அளவிடும் போது, அவை எதிர்பார்க்காத இடங்களில் சிக்கல்கள் தோன்றும். தளத்தில் முழு உரை தேடலுக்கு, நாங்கள் Apache Solr இன்ஜினைப் பயன்படுத்துகிறோம். சுமை அதிகரித்ததால், மறுமொழி நேரம் குறைவதை நாங்கள் குறிப்பிட்டோம், மேலும் சேவையக செயலி சுமை ஏற்கனவே 100% ஐ எட்டியுள்ளது. எளிமையானது என்ன - சோல்ர் கொண்ட கொள்கலனுக்கு அதிக ஆதாரங்களைக் கொடுப்போம்.
எதிர்பார்த்த செயல்திறன் அதிகரிப்புக்கு பதிலாக, சேவையகம் வெறுமனே "இறந்தது". அது உடனடியாக 100% ஏற்றப்பட்டு இன்னும் மெதுவாக பதிலளித்தது. ஆரம்பத்தில் எங்களிடம் 2 கோர்கள் மற்றும் 2 ஜிபி ரேம் இருந்தது. பொதுவாக உதவுவதைச் செய்ய முடிவு செய்தோம் - சேவையகத்திற்கு 8 கோர்கள் மற்றும் 32 ஜிபி கொடுத்தோம். எல்லாம் மிகவும் மோசமாகிவிட்டது (எப்படி, ஏன் என்பதை ஒரு தனி இடுகையில் நாங்கள் உங்களுக்குச் சொல்வோம்).
சில நாட்களில், இந்த சிக்கலின் நுணுக்கங்களை நாங்கள் கண்டறிந்தோம் மற்றும் 8 கோர்கள் மற்றும் 32 ஜிபி மூலம் உகந்த செயல்திறனை அடைந்தோம். இந்த உள்ளமைவு இன்று சுமைகளை தொடர்ந்து அதிகரிக்க அனுமதிக்கிறது, இது மிகவும் முக்கியமானது, ஏனெனில் வளர்ச்சி வாடிக்கையாளர்களில் மட்டுமல்ல, இணைக்கப்பட்ட கடைகளின் எண்ணிக்கையிலும் உள்ளது - 2 மாதங்களில் அவற்றின் எண்ணிக்கை இரட்டிப்பாகியுள்ளது.
முடிவுக்கு: "அதிக இரும்புச் சேர்" போன்ற நிலையான முறைகள் எப்போதும் வேலை செய்யாது. எனவே எந்தவொரு சேவையையும் அளவிடும் போது, அது எவ்வாறு வளங்களைப் பயன்படுத்துகிறது என்பதைப் பற்றி நீங்கள் நன்கு புரிந்து கொள்ள வேண்டும் மற்றும் புதிய நிலைமைகளில் அதன் செயல்பாட்டை முன்கூட்டியே சோதிக்க வேண்டும்.
நிலையற்றது எளிதான கிடைமட்ட அளவிடுதலுக்கான திறவுகோலாகும்
பொதுவாக, எங்கள் குழு நன்கு அறியப்பட்ட அணுகுமுறையைப் பின்பற்றுகிறது: சேவைகளுக்கு உள் நிலை (நிலையற்ற) இருக்கக்கூடாது மற்றும் செயல்படுத்தும் சூழலில் இருந்து சுயாதீனமாக இருக்க வேண்டும். இது வெறுமனே கிடைமட்ட அளவீடு மூலம் சுமை வளர்ச்சியை சமாளிக்க எங்களுக்கு அனுமதித்தது. ஆனால் எங்களிடம் ஒரு விதிவிலக்கு சேவை இருந்தது - நீண்ட பின்னணி பணிகளுக்கான ஹேண்ட்லர். அவர் மின்னஞ்சல் மற்றும் எஸ்எம்எஸ் அனுப்புதல், நிகழ்வுகளை செயலாக்குதல், ஊட்டங்களை உருவாக்குதல், விலைகள் மற்றும் பங்குகளை இறக்குமதி செய்தல் மற்றும் படங்களை செயலாக்குதல் ஆகியவற்றில் ஈடுபட்டார். இது உள்ளூர் கோப்பு சேமிப்பகத்தைப் பொறுத்தது மற்றும் ஒரே நகலில் இருந்தது.
செயலி வரிசையில் உள்ள பணிகளின் எண்ணிக்கை அதிகரித்தபோது (இது இயற்கையாகவே ஆர்டர்களின் எண்ணிக்கையில் அதிகரித்தது), செயலி மற்றும் கோப்பு சேமிப்பகம் அமைந்துள்ள ஹோஸ்டின் செயல்திறன் கட்டுப்படுத்தும் காரணியாக மாறியது. இதன் விளைவாக, வகைப்படுத்தல் மற்றும் விலைகளைப் புதுப்பித்தல், பயனர்களுக்கு அறிவிப்புகளை அனுப்புதல் மற்றும் வரிசையில் சிக்கிக்கொண்ட பல முக்கியமான செயல்பாடுகள் நிறுத்தப்பட்டன. Ops குழு விரைவாக கோப்பு சேமிப்பகத்தை S3 போன்ற பிணைய சேமிப்பகத்திற்கு மாற்றியது, மேலும் இது பின்னணி பணி செயலியை அளவிட பல சக்திவாய்ந்த இயந்திரங்களை உருவாக்க எங்களுக்கு அனுமதித்தது.
முடிவுக்கு: "நாங்கள் நிச்சயமாக இங்கு எதிர்க்க முடியாது" என்று தோன்றினாலும், விதிவிலக்கு இல்லாமல் அனைத்து கூறுகளுக்கும் நிலையற்ற விதி கடைபிடிக்கப்பட வேண்டும். குறியீட்டை அவசரமாக மீண்டும் எழுதி, அதிக சுமை கொண்ட சேவையை சரிசெய்வதை விட, அனைத்து அமைப்புகளின் செயல்பாட்டையும் ஒழுங்காக ஒழுங்கமைக்க சிறிது நேரம் செலவிடுவது நல்லது.
தீவிர வளர்ச்சிக்கான 7 கொள்கைகள்
கூடுதல் திறன் இருந்தபோதிலும், வளர்ச்சியின் செயல்பாட்டில் பல தவறுகளை நாங்கள் செய்துள்ளோம். இந்த நேரத்தில், ஆர்டர்களின் எண்ணிக்கை 4 மடங்குக்கு மேல் அதிகரித்துள்ளது. இப்போது நாங்கள் ஏற்கனவே 17 நகரங்களில் ஒரு நாளைக்கு 000 க்கும் மேற்பட்ட ஆர்டர்களை வழங்குகிறோம் மற்றும் புவியியலை மேலும் விரிவுபடுத்த திட்டமிட்டுள்ளோம் - 62 முதல் பாதியில் ரஷ்யா முழுவதும் இந்த சேவை தொடங்கப்படும் என்று எதிர்பார்க்கப்படுகிறது. வளர்ந்து வரும் பணிச்சுமையை சமாளிக்க, ஏற்கனவே உள்ள முழு கூம்புகளையும் கணக்கில் எடுத்துக்கொள்வதற்காக, நிலையான வளர்ச்சியின் நிலைமைகளில் வேலை செய்வதற்கான 2020 அடிப்படைக் கொள்கைகளை நாங்கள் உருவாக்கியுள்ளோம்:
- சம்பவம் நிர்வாகம். ஜிராவில் ஒரு பலகையை உருவாக்கினோம், அங்கு ஒவ்வொரு சம்பவமும் டிக்கெட் வடிவத்தில் பிரதிபலிக்கிறது. இது உண்மையில் நிகழ்வு தொடர்பான பணிகளை முதன்மைப்படுத்தி செயல்படுத்த உதவும். எல்லாவற்றிற்கும் மேலாக, சாராம்சத்தில், தவறு செய்வது பயமாக இல்லை, ஆனால் ஒரே சந்தர்ப்பத்தில் இரண்டு முறை தவறு செய்வது பயமாக இருக்கிறது. காரணத்தை சரிசெய்யும் முன், சம்பவங்கள் மீண்டும் நிகழும் சந்தர்ப்பங்களில், நடவடிக்கைக்கான வழிமுறைகள் தயாராக இருக்க வேண்டும், ஏனெனில் அதிக சுமைகளின் போது மின்னல் வேகத்தில் செயல்படுவது முக்கியம்.
- கண்காணிப்பு விதிவிலக்கு இல்லாமல் அனைத்து உள்கட்டமைப்பு கூறுகளுக்கும் தேவை. அவருக்கு நன்றி, சுமைகளின் வளர்ச்சியை எங்களால் கணிக்க முடிந்தது மற்றும் நீக்குதலுக்கு முன்னுரிமை அளிப்பதற்கான "தடைகளை" சரியாகத் தேர்ந்தெடுக்க முடிந்தது. பெரும்பாலும், அதிக சுமையின் கீழ், நீங்கள் ஒருபோதும் நினைக்காத அனைத்தும் உடைந்துவிடும் அல்லது மெதுவாகத் தொடங்கும். எனவே, அவற்றைக் கண்காணித்து முன்னறிவிப்பதற்காக, முதல் சம்பவங்கள் நிகழ்ந்த உடனேயே புதிய விழிப்பூட்டல்களை உருவாக்குவது சிறந்தது.
- சரியான எச்சரிக்கைகள் சுமை கூர்மையாக அதிகரிக்கும் போது வெறுமனே அவசியம். முதலில், சரியாக உடைந்ததை அவர்கள் தெரிவிக்க வேண்டும். இரண்டாவதாக, பல விழிப்பூட்டல்கள் இருக்கக்கூடாது, ஏனென்றால் முக்கியமான அல்லாத விழிப்பூட்டல்கள் ஏராளமாக இருப்பதால் அனைத்து விழிப்பூட்டல்களையும் முற்றிலும் புறக்கணிக்க வழிவகுக்கிறது.
- விண்ணப்பங்கள் நிலையற்றதாக இருக்க வேண்டும். இந்த விதிக்கு விதிவிலக்குகள் இருக்கக்கூடாது என்பதில் நாங்கள் உறுதியாக இருக்கிறோம். இயக்க நேர சூழலில் இருந்து நமக்கு முழுமையான சுதந்திரம் தேவை. இதைச் செய்ய, நீங்கள் பகிரப்பட்ட தரவை தரவுத்தளத்தில் சேமிக்கலாம் அல்லது எடுத்துக்காட்டாக, நேரடியாக S3 இல் சேமிக்கலாம். இன்னும் சிறப்பாக, விதிகளைப் பின்பற்றவும்.. நேரத்தின் கூர்மையான அதிகரிப்பின் போது, குறியீட்டை மேம்படுத்த எந்த வழியும் இல்லை, மேலும் கணினி வளங்கள் மற்றும் கிடைமட்ட அளவிடுதல் ஆகியவற்றை நேரடியாக அதிகரிப்பதன் மூலம் நீங்கள் சுமைகளை சமாளிக்க வேண்டும்.
- ஒதுக்கீடுகள் மற்றும் வெளிப்புற சேவைகளின் செயல்திறன். விரைவான வளர்ச்சியுடன், உங்கள் உள்கட்டமைப்பில் மட்டுமல்ல, வெளிப்புற சேவையிலும் சிக்கல் ஏற்படலாம். மிகவும் எரிச்சலூட்டும் விஷயம் என்னவென்றால், இது ஒரு தோல்வியால் அல்ல, மாறாக ஒதுக்கீடுகள் அல்லது வரம்புகளை அடைவதால். எனவே வெளிப்புற சேவைகள் உங்களைப் போலவே அளவிட வேண்டும்.
- தனி செயல்முறைகள் மற்றும் வரிசைகள். நுழைவாயில் ஒன்றில் அடைப்பு இருக்கும்போது இது மிகவும் உதவுகிறது. முழு எஸ்எம்எஸ் அனுப்பும் வரிசைகள் தகவல் அமைப்புகளுக்கு இடையேயான அறிவிப்புகளைப் பரிமாறிக் கொள்வதில் குறுக்கிடாமல் இருந்திருந்தால், தரவு பரிமாற்றத்தில் தாமதங்களைச் சந்தித்திருக்க மாட்டோம். மேலும் தனித்தனியாக வேலை செய்தால் தொழிலாளர்களின் எண்ணிக்கையை அதிகரிப்பது எளிதாக இருக்கும்.
- நிதி உண்மைகள். தரவு ஓட்டங்களில் வெடிக்கும் வளர்ச்சி இருக்கும்போது, கட்டணங்கள் மற்றும் சந்தாக்கள் பற்றி சிந்திக்க நேரமில்லை. ஆனால் நீங்கள் அவர்களை நினைவில் கொள்ள வேண்டும், குறிப்பாக நீங்கள் ஒரு சிறிய நிறுவனமாக இருந்தால். எந்த API இன் உரிமையாளரும், உங்கள் ஹோஸ்டிங் வழங்குநரும் பெரிய பில் செலுத்தலாம். எனவே நீங்கள் ஒப்பந்தங்களை கவனமாக படிக்க வேண்டும்.
முடிவுக்கு
இழப்புகள் இல்லாமல் இல்லை, ஆனால் நாங்கள் இந்த கட்டத்தில் தப்பிப்பிழைத்தோம், இன்று நாங்கள் கண்டுபிடிக்கப்பட்ட அனைத்து கொள்கைகளையும் கடைபிடிக்க முயற்சிக்கிறோம், மேலும் ஒவ்வொரு இயந்திரமும் சில எதிர்பாராத நிகழ்வுகளைச் சமாளிக்க x4 செயல்திறனை எளிதாக அதிகரிக்கும் திறனைக் கொண்டுள்ளது.
பின்வரும் இடுகைகளில், Apache Solr இல் செயல்திறன் சரிவை விசாரிப்பதில் எங்கள் அனுபவத்தைப் பகிர்ந்து கொள்வோம், மேலும் வினவல் மேம்படுத்தல் மற்றும் ஃபெடரல் டேக்ஸ் சேவையுடன் தொடர்புகொள்வது நிறுவனம் பணத்தைச் சேமிக்க உதவுகிறது. எங்கள் வலைப்பதிவிற்கு குழுசேரவும், அதனால் நீங்கள் எதையும் தவறவிடாதீர்கள், மேலும் போக்குவரத்து வளர்ச்சியின் போது உங்களுக்கு இதுபோன்ற சிக்கல்கள் இருந்தால் கருத்துகளில் எங்களிடம் கூறுங்கள்.
பதிவு செய்த பயனர்கள் மட்டுமே கணக்கெடுப்பில் பங்கேற்க முடியும். , தயவு செய்து.
பின்வரும் காரணங்களால் சுமையின் கூர்மையான அதிகரிப்பு காரணமாக நீங்கள் எப்போதாவது சேவையில் மந்தநிலை / சரிவை அனுபவித்திருக்கிறீர்களா:
-
55,6%கணினி வளங்களை விரைவாகச் சேர்க்க இயலாமை10
-
16,7%ஹோஸ்டிங் வழங்குநர் உள்கட்டமைப்பு வரம்புகள்3
-
33,3%மூன்றாம் தரப்பு APIகளின் வரம்புகள்6
-
27,8%அவற்றின் பயன்பாடுகளின் நிலையற்ற கொள்கைகளின் மீறல்கள்5
-
88,9%சொந்த சேவைகளின் உகந்த அல்லாத குறியீடு16
18 பயனர்கள் வாக்களித்தனர். 6 பயனர்கள் வாக்களிக்கவில்லை.
ஆதாரம்: www.habr.com