அனைவருக்கும் வணக்கம், எனது பெயர் அலெக்சாண்டர், நான் CIAN இல் பொறியியலாளராக பணிபுரிகிறேன், மேலும் கணினி நிர்வாகம் மற்றும் உள்கட்டமைப்பு செயல்முறைகளின் ஆட்டோமேஷனில் ஈடுபட்டுள்ளேன். முந்தைய கட்டுரைகளில் ஒன்றின் கருத்துகளில், ஒரு நாளைக்கு 4 TB பதிவுகளை எங்கிருந்து பெறுகிறோம், அவற்றை என்ன செய்கிறோம் என்பதைச் சொல்லும்படி கேட்கப்பட்டோம். ஆம், எங்களிடம் நிறைய பதிவுகள் உள்ளன, அவற்றைச் செயலாக்க ஒரு தனி உள்கட்டமைப்பு கிளஸ்டர் உருவாக்கப்பட்டது, இது சிக்கல்களை விரைவாக தீர்க்க அனுமதிக்கிறது. இந்தக் கட்டுரையில், தொடர்ந்து வளர்ந்து வரும் தரவுப் பாய்ச்சலுடன் செயல்பட, ஒரு வருடத்தில் அதை எவ்வாறு மாற்றியமைத்தோம் என்பதைப் பற்றி பேசுவேன்.
எங்கிருந்து ஆரம்பித்தோம்?
கடந்த சில ஆண்டுகளில், cian.ru இன் சுமை மிக விரைவாக வளர்ந்துள்ளது, மேலும் 2018 இன் மூன்றாம் காலாண்டில், வள போக்குவரத்து மாதத்திற்கு 11.2 மில்லியன் தனிப்பட்ட பயனர்களை எட்டியது. அந்த நேரத்தில், முக்கியமான தருணங்களில் நாங்கள் 40% பதிவுகளை இழந்தோம், அதனால்தான் சம்பவங்களை விரைவாகச் சமாளிக்க முடியவில்லை மற்றும் அவற்றைத் தீர்ப்பதற்கு நிறைய நேரத்தையும் முயற்சியையும் செலவிட்டோம். எங்களால் அடிக்கடி பிரச்சனைக்கான காரணத்தை கண்டுபிடிக்க முடியவில்லை, சிறிது நேரம் கழித்து அது மீண்டும் வரும். அது நரகம், அதைப் பற்றி ஏதாவது செய்ய வேண்டியிருந்தது.
அந்த நேரத்தில், பதிவுகளைச் சேமிக்க நிலையான குறியீட்டு அமைப்புகளுடன் கூடிய ElasticSearch பதிப்பு 10 உடன் 5.5.2 தரவு முனைகளின் தொகுப்பைப் பயன்படுத்தினோம். இது ஒரு வருடத்திற்கு முன்னர் பிரபலமான மற்றும் மலிவு தீர்வாக அறிமுகப்படுத்தப்பட்டது: பின்னர் பதிவுகளின் ஓட்டம் அவ்வளவு பெரியதாக இல்லை, தரமற்ற கட்டமைப்புகளுடன் வருவதில் எந்த அர்த்தமும் இல்லை.
ஐந்து ElasticSearch ஒருங்கிணைப்பாளர்களில் வெவ்வேறு போர்ட்களில் Logstash மூலம் உள்வரும் பதிவுகளின் செயலாக்கம் வழங்கப்பட்டது. அளவைப் பொருட்படுத்தாமல் ஒரு குறியீடு, ஐந்து துண்டுகளைக் கொண்டிருந்தது. ஒரு மணிநேர மற்றும் தினசரி சுழற்சி ஏற்பாடு செய்யப்பட்டது, இதன் விளைவாக, ஒவ்வொரு மணி நேரத்திற்கும் சுமார் 100 புதிய துண்டுகள் கிளஸ்டரில் தோன்றின. அதிக பதிவுகள் இல்லை என்றாலும், கிளஸ்டர் நன்றாகச் சமாளித்தது மற்றும் அதன் அமைப்புகளுக்கு யாரும் கவனம் செலுத்தவில்லை.
விரைவான வளர்ச்சியின் சவால்கள்
இரண்டு செயல்முறைகள் ஒன்றுடன் ஒன்று இணைந்ததால், உருவாக்கப்பட்ட பதிவுகளின் அளவு மிக விரைவாக வளர்ந்தது. ஒருபுறம், சேவையைப் பயன்படுத்துபவர்களின் எண்ணிக்கை அதிகரித்தது. மறுபுறம், C# மற்றும் Python இல் எங்களது பழைய மோனோலித்களை அறுத்து, மைக்ரோ சர்வீஸ் கட்டிடக்கலைக்கு தீவிரமாக மாறத் தொடங்கினோம். மோனோலித்தின் பகுதிகளை மாற்றியமைக்கப்பட்ட பல டஜன் புதிய மைக்ரோ சர்வீஸ்கள், உள்கட்டமைப்பு கிளஸ்டருக்கான அதிக பதிவுகளை உருவாக்கியது.
கொத்து நடைமுறையில் கையாள முடியாத நிலைக்கு எங்களை அழைத்துச் சென்றது. வினாடிக்கு 20 ஆயிரம் செய்திகள் என்ற விகிதத்தில் பதிவுகள் வரத் தொடங்கியபோது, அடிக்கடி உபயோகமில்லாத சுழல் துகள்களின் எண்ணிக்கையை 6 ஆயிரமாக அதிகரித்தது, மேலும் ஒரு முனைக்கு 600 க்கும் மேற்பட்ட துண்டுகள் இருந்தன.
இது ரேம் ஒதுக்கீட்டில் சிக்கல்களுக்கு வழிவகுத்தது, மேலும் ஒரு முனை செயலிழக்கும்போது, அனைத்து துண்டுகளும் ஒரே நேரத்தில் நகரத் தொடங்கின, போக்குவரத்தைப் பெருக்கி மற்ற முனைகளை ஏற்றியது, இது கிளஸ்டருக்கு தரவை எழுதுவது கிட்டத்தட்ட சாத்தியமற்றது. இந்த காலகட்டத்தில் நாங்கள் பதிவுகள் இல்லாமல் இருந்தோம். சேவையகத்தில் ஏதேனும் சிக்கல் இருந்தால், நாங்கள் அடிப்படையில் 1/10 கிளஸ்டரை இழந்தோம். அதிக எண்ணிக்கையிலான சிறிய குறியீடுகள் சிக்கலைச் சேர்த்தன.
பதிவுகள் இல்லாமல், சம்பவத்திற்கான காரணங்களை நாங்கள் புரிந்து கொள்ளவில்லை, விரைவில் அல்லது பின்னர் மீண்டும் அதே ரேக்கில் அடியெடுத்து வைக்கலாம், மேலும் எங்கள் குழுவின் சித்தாந்தத்தில் இது ஏற்றுக்கொள்ள முடியாதது, ஏனெனில் எங்கள் பணி வழிமுறைகள் அனைத்தும் எதிர்மாறாக வடிவமைக்கப்பட்டுள்ளன - மீண்டும் செய்ய வேண்டாம் அதே பிரச்சினைகள். இதைச் செய்ய, பணியிலுள்ள பொறியாளர்கள் குழு அளவீடுகளிலிருந்து மட்டுமல்ல, பதிவுகளிலிருந்தும் விழிப்பூட்டல்களைக் கண்காணித்ததால், எங்களுக்கு முழு அளவிலான பதிவுகள் மற்றும் அவற்றின் விநியோகம் கிட்டத்தட்ட உண்மையான நேரத்தில் தேவைப்பட்டது. சிக்கலின் அளவைப் புரிந்து கொள்ள, அந்த நேரத்தில் பதிவுகளின் மொத்த அளவு ஒரு நாளைக்கு சுமார் 2 TB ஆக இருந்தது.
பதிவுகளின் இழப்பை முற்றிலுமாக அகற்றுவதற்கும், ஃபோர்ஸ் மஜூரின் போது ELK கிளஸ்டருக்கு அவை வழங்கப்படும் நேரத்தை அதிகபட்சமாக 15 நிமிடங்களுக்குக் குறைப்பதற்கும் இலக்கை நிர்ணயித்துள்ளோம் (பின்னர் இந்த எண்ணிக்கையை உள் KPI ஆக நம்பியுள்ளோம்).
புதிய சுழற்சி நுட்பம் மற்றும் சூடான-சூடான முனைகள்
ElasticSearch பதிப்பை 5.5.2 இலிருந்து 6.4.3 க்கு மேம்படுத்துவதன் மூலம் கிளஸ்டர் மாற்றத்தைத் தொடங்கினோம். மீண்டும் எங்கள் பதிப்பு 5 கிளஸ்டர் இறந்தது, அதை அணைத்து முழுமையாக புதுப்பிக்க முடிவு செய்தோம் - இன்னும் பதிவுகள் எதுவும் இல்லை. எனவே இந்த மாற்றத்தை ஓரிரு மணி நேரத்தில் செய்தோம்.
இந்த கட்டத்தில் மிகப் பெரிய அளவிலான மாற்றம் அப்பாச்சி காஃப்காவை இடைநிலை இடையகமாக ஒருங்கிணைப்பாளருடன் மூன்று முனைகளில் செயல்படுத்துவதாகும். ElasticSearch இல் உள்ள சிக்கல்களின் போது பதிவுகளை இழப்பதில் இருந்து செய்தி தரகர் எங்களைக் காப்பாற்றினார். அதே நேரத்தில், நாங்கள் கிளஸ்டரில் 2 முனைகளைச் சேர்த்து, தரவு மையத்தில் வெவ்வேறு ரேக்குகளில் அமைந்துள்ள மூன்று "சூடான" முனைகளுடன் சூடான-சூடான கட்டமைப்பிற்கு மாறினோம். nginx மற்றும் பயன்பாட்டுப் பிழைப் பதிவுகள் - எந்தச் சூழ்நிலையிலும் இழக்கக் கூடாத முகமூடியைப் பயன்படுத்தி பதிவுகளை அவர்களுக்குத் திருப்பியனுப்பினோம். சிறிய பதிவுகள் மீதமுள்ள முனைகளுக்கு அனுப்பப்பட்டன - பிழைத்திருத்தம், எச்சரிக்கை போன்றவை, மேலும் 24 மணி நேரத்திற்குப் பிறகு, "சூடான" முனைகளிலிருந்து "முக்கியமான" பதிவுகள் மாற்றப்பட்டன.
சிறிய குறியீடுகளின் எண்ணிக்கையை அதிகரிக்காமல் இருப்பதற்காக, நேர சுழற்சியிலிருந்து ரோல்ஓவர் பொறிமுறைக்கு மாறினோம். குறியீட்டு அளவின் மூலம் சுழற்சி மிகவும் நம்பமுடியாதது என்று மன்றங்களில் நிறைய தகவல்கள் இருந்தன, எனவே குறியீட்டில் உள்ள ஆவணங்களின் எண்ணிக்கையால் சுழற்சியைப் பயன்படுத்த முடிவு செய்தோம். ஒவ்வொரு குறியீட்டையும் பகுப்பாய்வு செய்து, சுழற்சி வேலை செய்ய வேண்டிய ஆவணங்களின் எண்ணிக்கையைப் பதிவு செய்தோம். எனவே, நாங்கள் உகந்த துண்டு அளவை அடைந்துள்ளோம் - 50 ஜிபிக்கு மேல் இல்லை.
கிளஸ்டர் தேர்வுமுறை
இருப்பினும், நாங்கள் பிரச்சினைகளில் இருந்து முழுமையாக விடுபடவில்லை. துரதிர்ஷ்டவசமாக, சிறிய குறியீடுகள் இன்னும் தோன்றின: அவை குறிப்பிட்ட அளவை எட்டவில்லை, சுழற்றப்படவில்லை, மேலும் மூன்று நாட்களுக்கு மேல் உள்ள குறியீடுகளை உலகளாவிய சுத்தம் செய்வதன் மூலம் நீக்கப்பட்டன, ஏனெனில் நாங்கள் தேதியின்படி சுழற்சியை அகற்றினோம். இது க்ளஸ்டரிலிருந்து இன்டெக்ஸ் முற்றிலுமாக மறைந்துவிட்டதால் தரவு இழப்புக்கு வழிவகுத்தது, மேலும் இல்லாத குறியீட்டிற்கு எழுதும் முயற்சியானது நிர்வாகத்திற்காக நாங்கள் பயன்படுத்திய கியூரேட்டரின் தர்க்கத்தை உடைத்தது. எழுதுவதற்கான மாற்றுப்பெயர் ஒரு குறியீட்டாக மாற்றப்பட்டது மற்றும் ரோல்ஓவர் தர்க்கத்தை உடைத்தது, சில குறியீடுகளின் கட்டுப்பாடற்ற வளர்ச்சியை 600 ஜிபி வரை ஏற்படுத்தியது.
எடுத்துக்காட்டாக, சுழற்சி கட்டமைப்பிற்கு:
сurator-elk-rollover.yaml
---
actions:
1:
action: rollover
options:
name: "nginx_write"
conditions:
max_docs: 100000000
2:
action: rollover
options:
name: "python_error_write"
conditions:
max_docs: 10000000
மாற்றுப்பெயர் இல்லை என்றால், பிழை ஏற்பட்டது:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
இந்தச் சிக்கலுக்கான தீர்வை அடுத்த மறு செய்கைக்கு விட்டுவிட்டு மற்றொரு சிக்கலை எடுத்துக் கொண்டோம்: உள்வரும் பதிவுகளை செயலாக்கும் (தேவையற்ற தகவல்களை நீக்கி வளப்படுத்துதல்) Logstash இன் இழுக்கும் தர்க்கத்திற்கு மாறினோம். நாங்கள் அதை டோக்கரில் வைத்தோம், அதை நாங்கள் டோக்கர்-கம்போஸ் மூலம் தொடங்குகிறோம், மேலும் லாக்ஸ்டாஷ்-எக்ஸ்போர்ட்டரையும் அங்கு வைத்தோம், இது பதிவு ஸ்ட்ரீமின் செயல்பாட்டுக் கண்காணிப்பிற்காக ப்ரோமிதியஸுக்கு அளவீடுகளை அனுப்புகிறது. இந்த வழியில், ஒவ்வொரு வகை பதிவையும் செயலாக்குவதற்குப் பொறுப்பான லாக்ஸ்டாஷ் நிகழ்வுகளின் எண்ணிக்கையை சீராக மாற்றுவதற்கான வாய்ப்பை நாங்கள் வழங்கினோம்.
நாங்கள் கிளஸ்டரை மேம்படுத்தும் போது, cian.ru இன் போக்குவரத்து மாதத்திற்கு 12,8 மில்லியன் தனிப்பட்ட பயனர்களாக அதிகரித்தது. இதன் விளைவாக, எங்கள் மாற்றங்கள் உற்பத்தியில் ஏற்படும் மாற்றங்களுக்கு சற்று பின்னால் இருப்பதாக மாறியது, மேலும் "சூடான" முனைகளால் சுமைகளை சமாளிக்க முடியவில்லை மற்றும் பதிவுகளின் முழு விநியோகத்தையும் மெதுவாக்கியது என்ற உண்மையை நாங்கள் எதிர்கொண்டோம். தோல்விகள் இல்லாமல் "சூடான" தரவைப் பெற்றோம், ஆனால் மீதமுள்ளவற்றை வழங்குவதில் நாங்கள் தலையிட வேண்டியிருந்தது மற்றும் குறியீடுகளை சமமாக விநியோகிக்க கைமுறையாக மாற்றியமைக்க வேண்டியிருந்தது.
அதே நேரத்தில், கிளஸ்டரில் உள்ள லாக்ஸ்டாஷ் நிகழ்வுகளின் அமைப்புகளை அளவிடுதல் மற்றும் மாற்றுவது இது ஒரு உள்ளூர் டாக்கர்-இயக்குதல் என்பதன் மூலம் சிக்கலானது, மேலும் அனைத்து செயல்களும் கைமுறையாக செய்யப்பட்டன (புதிய முனைகளைச் சேர்க்க, அனைத்தையும் கைமுறையாகச் செல்ல வேண்டியது அவசியம். சர்வர்கள் மற்றும் டாக்கர்-கம்போஸ் அப் -டி எல்லா இடங்களிலும் செய்ய).
பதிவு மறுபகிர்வு
இந்த ஆண்டு செப்டம்பரில், நாங்கள் இன்னும் மோனோலித்தை வெட்டிக் கொண்டிருந்தோம், கிளஸ்டரின் சுமை அதிகரித்து வருகிறது, மேலும் பதிவுகளின் ஓட்டம் வினாடிக்கு 30 ஆயிரம் செய்திகளை நெருங்குகிறது.
வன்பொருள் புதுப்பித்தலுடன் அடுத்த மறு செய்கையைத் தொடங்கினோம். நாங்கள் ஐந்து ஒருங்கிணைப்பாளர்களில் இருந்து மூன்றாக மாறினோம், தரவு முனைகளை மாற்றினோம் மற்றும் பணம் மற்றும் சேமிப்பகத்தின் அடிப்படையில் வெற்றி பெற்றோம். முனைகளுக்கு நாம் இரண்டு கட்டமைப்புகளைப் பயன்படுத்துகிறோம்:
- "ஹாட்" முனைகளுக்கு: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (Hot3 க்கு 1 மற்றும் Hot3 க்கு 2).
- "சூடான" முனைகளுக்கு: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
இந்த மறு செய்கையில், மைக்ரோ சர்வீஸின் அணுகல் பதிவுகளுடன் குறியீட்டை நகர்த்தினோம், இது முன்-வரிசை nginx பதிவுகளின் அதே இடத்தை மூன்று "ஹாட்" முனைகளின் இரண்டாவது குழுவிற்கு நகர்த்தியது. நாங்கள் இப்போது 20 மணிநேரங்களுக்கு "சூடான" முனைகளில் தரவைச் சேமித்து, பின்னர் அவற்றை மீதமுள்ள பதிவுகளுக்கு "சூடான" முனைகளுக்கு மாற்றுவோம்.
சிறிய குறியீடுகள் மறைந்து போகும் சிக்கலை அவற்றின் சுழற்சியை மறுகட்டமைப்பதன் மூலம் தீர்த்தோம். இப்போது குறியீடுகள் ஒவ்வொரு 23 மணிநேரமும் சுழற்றப்படுகின்றன, சிறிய தரவு இருந்தாலும் கூட. இது துண்டுகளின் எண்ணிக்கையை சற்று அதிகரித்தது (அவற்றில் சுமார் 800 இருந்தன), ஆனால் கிளஸ்டர் செயல்திறனின் பார்வையில் இது பொறுத்துக்கொள்ளக்கூடியது.
இதன் விளைவாக, கிளஸ்டரில் ஆறு "சூடான" மற்றும் நான்கு "சூடான" முனைகள் மட்டுமே இருந்தன. இது நீண்ட கால இடைவெளியில் கோரிக்கைகளில் சிறிது தாமதத்தை ஏற்படுத்துகிறது, ஆனால் எதிர்காலத்தில் முனைகளின் எண்ணிக்கையை அதிகரிப்பது இந்த சிக்கலை தீர்க்கும்.
இந்த மறு செய்கையானது அரை தானியங்கி அளவீடு இல்லாமையின் சிக்கலையும் சரிசெய்தது. இதைச் செய்ய, நாங்கள் ஏற்கனவே உற்பத்தியில் பயன்படுத்தியதைப் போன்ற உள்கட்டமைப்பு நாடோடி கிளஸ்டரைப் பயன்படுத்தினோம். இப்போதைக்கு, Logstash இன் அளவு தானாகவே சுமையைப் பொறுத்து மாறாது, ஆனால் நாம் இதற்கு வருவோம்.
எதிர்கால திட்டங்கள்
செயல்படுத்தப்பட்ட உள்ளமைவு அளவீடுகள் செய்தபின், இப்போது நாங்கள் 13,3 TB தரவைச் சேமித்து வைக்கிறோம் - அனைத்து பதிவுகளும் 4 நாட்களுக்கு, இது எச்சரிக்கைகளின் அவசர பகுப்பாய்வுக்கு அவசியம். சில பதிவுகளை அளவீடுகளாக மாற்றுகிறோம், அதை கிராஃபைட்டில் சேர்க்கிறோம். பொறியாளர்களின் பணியை எளிதாக்க, உள்கட்டமைப்பு கிளஸ்டருக்கான அளவீடுகள் மற்றும் பொதுவான சிக்கல்களை அரை தானியங்கி சரிசெய்வதற்கான ஸ்கிரிப்ட்கள் எங்களிடம் உள்ளன. அடுத்த ஆண்டு திட்டமிடப்பட்ட தரவு முனைகளின் எண்ணிக்கையை அதிகரித்த பிறகு, நாங்கள் 4 முதல் 7 நாட்களுக்கு தரவு சேமிப்பகத்திற்கு மாறுவோம். செயல்பாட்டிற்கு இது போதுமானதாக இருக்கும், ஏனெனில் நாங்கள் எப்போதும் சம்பவங்களை விரைவில் விசாரிக்க முயற்சிப்போம், மேலும் நீண்ட கால விசாரணைகளுக்கு டெலிமெட்ரி தரவு உள்ளது.
அக்டோபர் 2019 இல், cian.ru க்கான போக்குவரத்து ஏற்கனவே மாதத்திற்கு 15,3 மில்லியன் தனிப்பட்ட பயனர்களாக வளர்ந்துள்ளது. இது பதிவுகளை வழங்குவதற்கான கட்டடக்கலை தீர்வுக்கான தீவிர சோதனையாக மாறியது.
இப்போது ElasticSearchஐ பதிப்பு 7க்கு புதுப்பிக்கத் தயாராகி வருகிறோம். இருப்பினும், பதிப்பு 5.5 இலிருந்து நகர்ந்து, பதிப்பு 6ல் நீக்கப்பட்டதாக அறிவிக்கப்பட்டதால், எலாஸ்டிக் தேடலில் உள்ள பல குறியீடுகளின் மேப்பிங்கைப் புதுப்பிக்க வேண்டும். 7) இதன் பொருள், புதுப்பிப்புச் செயல்பாட்டின் போது நிச்சயமாக ஒருவித ஃபோர்ஸ் மேஜர் இருக்கும், இது சிக்கல் தீர்க்கப்படும்போது பதிவுகள் இல்லாமல் நம்மை விட்டுவிடும். பதிப்பு 7 இல், மேம்படுத்தப்பட்ட இடைமுகம் மற்றும் புதிய வடிப்பான்களுடன் கிபானாவை நாங்கள் மிகவும் எதிர்பார்க்கிறோம்.
நாங்கள் எங்கள் முக்கிய இலக்கை அடைந்துவிட்டோம்: பதிவுகளை இழப்பதை நிறுத்திவிட்டோம் மற்றும் உள்கட்டமைப்பு கிளஸ்டரின் வேலையில்லா நேரத்தை வாரத்திற்கு 2-3 செயலிழப்புகளிலிருந்து மாதத்திற்கு இரண்டு மணிநேர பராமரிப்பு வேலைகளாகக் குறைத்தோம். உற்பத்தியில் இந்த வேலைகள் அனைத்தும் கிட்டத்தட்ட கண்ணுக்கு தெரியாதவை. எவ்வாறாயினும், இப்போது எங்கள் சேவையில் என்ன நடக்கிறது என்பதை நாம் துல்லியமாக தீர்மானிக்க முடியும், அதை விரைவாக அமைதியான முறையில் செய்யலாம் மற்றும் பதிவுகள் இழக்கப்படும் என்று கவலைப்பட வேண்டாம். பொதுவாக, நாங்கள் திருப்தி, மகிழ்ச்சி மற்றும் புதிய சுரண்டல்களுக்குத் தயாராகி வருகிறோம், அதைப் பற்றி பின்னர் பேசுவோம்.
ஆதாரம்: www.habr.com