டாப் ஃபகபோவ் சியான்

வாழ்த்துகள்! 

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

முன்னுரை

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

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

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

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

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

சிறந்த சம்பவங்கள் சியான்

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

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

கடந்த சில ஆண்டுகளில் ஏற்பட்ட தோல்விகளை நீங்கள் சேகரித்தால், தலைவர்கள்: 

• mssql தொடர்பான சம்பவங்கள்;
• வெளிப்புற காரணிகளால் ஏற்படும் சம்பவங்கள்;
• நிர்வாக பிழைகள்.

நிர்வாகிகளின் தவறுகள் மற்றும் வேறு சில சுவாரஸ்யமான தோல்விகள் பற்றி மேலும் விரிவாகப் பார்ப்போம்.

ஐந்தாவது இடம் - “டிஎன்எஸ்ஸில் விஷயங்களை ஒழுங்காக வைப்பது”

அது ஒரு புயல் செவ்வாய்க்கிழமை. DNS கிளஸ்டரில் ஒழுங்கை மீட்டெடுக்க முடிவு செய்தோம். 

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

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

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

முடிவுகளை:

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

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

நான்காவது இடம் - “Nginx இல் விஷயங்களை ஒழுங்காக வைப்பது”

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

Nginx அமைப்பு

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

இது மிகவும் சிறப்பாக ஆனது, ஆனால் கட்டமைப்புகளை மறுபெயரிடுதல் மற்றும் விநியோகிக்கும் செயல்பாட்டில், அவற்றில் சில தவறான நீட்டிப்பைக் கொண்டிருந்தன, மேலும் அவை *.conf கட்டளையில் சேர்க்கப்படவில்லை. இதன் விளைவாக, சில ஹோஸ்ட்கள் கிடைக்காமல் 301ஐ முதன்மைப் பக்கத்திற்குத் திருப்பி அனுப்பியது. மறுமொழி குறியீடு 5xx/4xx இல்லை என்ற உண்மையின் காரணமாக, இது உடனடியாக கவனிக்கப்படவில்லை, ஆனால் காலையில் மட்டுமே. அதன் பிறகு, உள்கட்டமைப்பு கூறுகளை சரிபார்க்க சோதனைகளை எழுத ஆரம்பித்தோம்.

முடிவுகளை: 

• உங்கள் கட்டமைப்புகளை சரியாக கட்டமைக்கவும் (nginx மட்டும் அல்ல) மற்றும் திட்டத்தின் ஆரம்ப கட்டத்தில் கட்டமைப்பை சிந்திக்கவும். இந்த வழியில் நீங்கள் அவர்களை குழுவிற்கு இன்னும் புரியவைப்பீர்கள், இது TTM ஐ குறைக்கும்.
• சில உள்கட்டமைப்பு கூறுகளுக்கான சோதனைகளை எழுதுங்கள். எடுத்துக்காட்டாக: அனைத்து முக்கிய சர்வர்_பெயர்களும் சரியான நிலை + மறுமொழி உடலை வழங்குகின்றனவா என்பதைச் சரிபார்க்கவும். கூறுகளின் அடிப்படை செயல்பாடுகளைச் சரிபார்க்கும் சில ஸ்கிரிப்ட்களை கையில் வைத்திருந்தால் போதுமானது, எனவே அதிகாலை 3 மணிக்கு வேறு என்ன சரிபார்க்க வேண்டும் என்பதை வெறித்தனமாக நினைவில் வைத்துக் கொள்ளக்கூடாது. 

மூன்றாவது இடம் - “திடீரென்று கசாண்ட்ராவில் இடம் இல்லாமல் போனது”

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

ஒரு புயல் நாள் கொத்து கிட்டத்தட்ட பூசணிக்காயாக மாறியது, அதாவது:

• மொத்த இடத்தில் சுமார் 20% கிளஸ்டரில் எஞ்சியிருந்தது;
• முனைகளை முழுமையாகச் சேர்ப்பது சாத்தியமில்லை, ஏனென்றால் பகிர்வுகளில் இடம் இல்லாததால் ஒரு முனையைச் சேர்த்த பிறகு சுத்தம் செய்யாது;
• சுருக்கம் வேலை செய்யாததால் உற்பத்தித்திறன் படிப்படியாக குறைகிறது; 
• கிளஸ்டர் அவசர பயன்முறையில் உள்ளது.

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

முடிவுகளை:

• அனைத்து கசாண்ட்ரா சேவையகங்களிலும், ஒவ்வொரு பகிர்விலும் 60% க்கும் அதிகமான இடத்தை ஆக்கிரமிக்கக்கூடாது. 
• அவை 50% cpu இல் ஏற்றப்படக்கூடாது.
• திறன் திட்டமிடல் பற்றி நீங்கள் மறந்துவிடக் கூடாது மற்றும் ஒவ்வொரு கூறுகளையும் அதன் பிரத்தியேகங்களின் அடிப்படையில் சிந்திக்க வேண்டும்.
• கிளஸ்டரில் அதிக முனைகள், சிறந்தது. ஒரு சிறிய அளவிலான தரவைக் கொண்ட சேவையகங்கள் வேகமாக ஓவர்லோட் செய்யப்படுகின்றன, மேலும் அத்தகைய கிளஸ்டரைப் புதுப்பிக்க எளிதானது. 

இரண்டாவது இடம் - “கான்சல் கீ மதிப்பு சேமிப்பிலிருந்து தரவு மறைந்துவிட்டது”

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

முடிவுகளை:

• எந்த அங்கீகாரமும் இல்லாத சேவைகளில் தளத்தின் செயல்பாட்டிற்கு முக்கியமான தரவு இருக்கக்கூடாது. எடுத்துக்காட்டாக, ES இல் உங்களுக்கு அங்கீகாரம் இல்லையென்றால், நெட்வொர்க் மட்டத்தில் தேவையில்லாத எல்லா இடங்களிலிருந்தும் அணுகலை மறுப்பது நல்லது, தேவையானவற்றை மட்டும் விட்டுவிட்டு, action.destructive_requires_name: true என அமைக்கவும்.
• உங்கள் காப்பு மற்றும் மீட்பு பொறிமுறையை முன்கூட்டியே பயிற்சி செய்யுங்கள். எடுத்துக்காட்டாக, காப்புப் பிரதி எடுத்து மீட்டெடுக்கக்கூடிய ஒரு ஸ்கிரிப்டை முன்கூட்டியே உருவாக்கவும் (எடுத்துக்காட்டாக, பைத்தானில்).

முதல் இடம் - "கேப்டன் தெளிவற்ற" 

சில சமயங்களில், பின்தளத்தில் 10+ சர்வர்கள் இருக்கும் சந்தர்ப்பங்களில், nginx அப்ஸ்ட்ரீம்களில் சுமையின் சீரற்ற விநியோகத்தை நாங்கள் கவனித்தோம். ரவுண்ட்-ராபின் 1வது முதல் கடைசி அப்ஸ்ட்ரீம் வரை கோரிக்கைகளை அனுப்பியதாலும், ஒவ்வொரு nginx ரீலோட் தொடங்கப்பட்டதாலும், முதல் அப்ஸ்ட்ரீம்கள் எப்பொழுதும் மற்றவற்றை விட அதிகமான கோரிக்கைகளைப் பெற்றன. இதன் விளைவாக, அவை மெதுவாகச் செயல்பட்டன மற்றும் முழு தளமும் பாதிக்கப்பட்டது. போக்குவரத்து நெரிசல் அதிகரித்ததால், இது மிகவும் கவனிக்கத்தக்கது. சீரற்றதாக இயக்க nginxஐப் புதுப்பிப்பது வேலை செய்யவில்லை - பதிப்பு 1.15 இல் (அந்த நேரத்தில்) எடுக்காத லுவா குறியீட்டை நாம் மீண்டும் செய்ய வேண்டும். நாங்கள் எங்கள் nginx 1.14.2 ஐ இணைக்க வேண்டும், அதில் சீரற்ற ஆதரவை அறிமுகப்படுத்துகிறோம். இதனால் பிரச்சனை தீர்ந்துவிட்டது. இந்த பிழை "கேப்டன் வெளிப்படையானது" பிரிவில் வெற்றி பெற்றது.

முடிவுகளை:

இந்த பிழையை ஆராய்வது மிகவும் சுவாரசியமாகவும் உற்சாகமாகவும் இருந்தது). 

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

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

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