🥇 शीर्ष फेकअप सियान

शुभकामना!

मेरो नाम निकिता हो, र म सियान इन्जिनियरिङ टोलीको टोली प्रमुख हुँ। कम्पनीमा मेरो एउटा जिम्मेवारी भनेको उत्पादनमा पूर्वाधारसँग सम्बन्धित घटनाहरूको संख्या शून्यमा झार्नु हो।
यसपछिको कुराले हामीलाई धेरै पीडा दिएको छ, र यस लेखको उद्देश्य अरूलाई हाम्रा गल्तीहरू दोहोर्याउनबाट रोक्नु हो, वा कम्तिमा तिनीहरूको प्रभावलाई कम गर्नु हो।

प्रस्तावना

धेरै पहिले, जब सियान एक मोनोलिथिक प्रणाली थियो र माइक्रोसर्भिसेसको कुनै संकेत थिएन, हामीले ३-५ पृष्ठहरू जाँच गरेर स्रोत उपलब्धता मापन गर्यौं।

यदि तिनीहरूले प्रतिक्रिया दिए भने, सबै ठीक छ; यदि तिनीहरूले लामो समयसम्म प्रतिक्रिया दिएनन् भने, यो एक चेतावनी हो। घटना मानिन कति समयसम्म उनीहरू तल बस्नुपर्छ भन्ने कुरा बैठकहरूमा निर्णय गरिन्थ्यो। इन्जिनियरिङ टोलीले सधैं घटनाको अनुसन्धानमा भाग लियो। अनुसन्धान पूरा भएपछि, तिनीहरूले पोस्टमार्टम लेखे - एक प्रकारको इमेल रिपोर्ट जसमा के भयो, कति समय लाग्यो, हामीले त्यतिबेला के गर्यौं र भविष्यमा के गर्नेछौं भन्ने विवरण दिइएको थियो।

साइटको मुख्य पृष्ठहरू, वा हामी कसरी थाहा पाउँछौं कि हामी एकदमै तल पुगेका छौं

त्रुटिको प्राथमिकतालाई राम्रोसँग बुझ्नको लागि, हामीले साइटको व्यावसायिक कार्यक्षमताको लागि सबैभन्दा महत्त्वपूर्ण पृष्ठहरू पहिचान गरेका छौं। हामी सफल/असफल अनुरोधहरू र टाइमआउटहरूको संख्या गणना गर्न यी पृष्ठहरू प्रयोग गर्छौं। यसरी हामी अपटाइम मापन गर्छौं।

मानौं हामीले पत्ता लगाएका छौं कि साइटका धेरै महत्वपूर्ण खण्डहरू छन् जुन मुख्य सेवाको लागि जिम्मेवार छन् - खोज र विज्ञापन पेश गर्ने। यदि त्रुटिहरू निम्त्याउने अनुरोधहरूको प्रतिशत १% भन्दा बढी छ भने, यो एक महत्वपूर्ण घटना हो। यदि प्राइम टाइमको समयमा १५ मिनेटको अवधिमा त्रुटि दर ०.१% भन्दा बढी छ भने, यसलाई पनि एक महत्वपूर्ण घटना मानिन्छ। यी मापदण्डहरूले धेरैजसो घटनाहरूलाई समेट्छन्; बाँकी यस लेखको दायराभन्दा बाहिर छन्।

शीर्ष सियान घटनाहरू

त्यसोभए, हामीले निश्चित रूपमा घटना भएको तथ्य निर्धारण गर्न सिकेका छौं।

अब, प्रत्येक घटनालाई विस्तृत रूपमा जिरा महाकाव्यमा प्रतिबिम्बित गरिएको छ। संयोगवश, हामीले यस उद्देश्यका लागि FAIL नामक एउटा छुट्टै परियोजना सिर्जना गरेका छौं, जहाँ केवल महाकाव्यहरू मात्र सिर्जना गर्न सकिन्छ।

यदि तपाईंले पछिल्ला केही वर्षहरूमा सबै असफलताहरू सङ्कलन गर्नुभयो भने, निम्न कुराहरू अग्रणी छन्:

mssql सँग सम्बन्धित घटनाहरू;
बाह्य कारकहरूबाट हुने घटनाहरू;
व्यवस्थापक त्रुटिहरू।

प्रशासकीय त्रुटिहरू, साथै केही अन्य रोचक असफलताहरूलाई नजिकबाट हेरौं।

पाँचौं स्थान - "हामी हाम्रो DNS लाई व्यवस्थित गर्दैछौं"

मंगलबार आँधीबेहरी थियो। हामीले DNS क्लस्टर सफा गर्ने निर्णय गर्यौं।

म मेरो आन्तरिक DNS सर्भरहरूलाई bind बाट powerdns मा स्थानान्तरण गर्न चाहन्थें, यस उद्देश्यका लागि पूर्ण रूपमा छुट्टै सर्भरहरू छुट्याएर, जहाँ DNS बाहेक अरू केही छैन।

हामीले हाम्रा डाटा सेन्टरहरूको प्रत्येक स्थानमा एउटा DNS सर्भर राख्यौं, र क्षेत्रहरूलाई बाइन्डबाट powerdns मा सार्ने र पूर्वाधारलाई नयाँ सर्भरहरूमा स्विच गर्ने समय आयो।

सबै कुराको, सर्दै जाँदा सर्भरहरूस्थानीय क्यासिङ बाइन्डहरूमा निर्दिष्ट गरिएका सर्भरहरू मध्ये, केवल एउटा मात्र बाँकी रह्यो - सेन्ट पिटर्सबर्ग डाटा सेन्टरमा रहेको। यो डाटा सेन्टर सुरुमा हाम्रो लागि गैर-महत्वपूर्ण घोषित गरिएको थियो, तर अचानक असफलताको एकल बिन्दु बन्यो।
यो संक्रमणकालमा मस्को र सेन्ट पिटर्सबर्ग बीचको च्यानल डाउन भयो। हामी पाँच मिनेटको लागि DNS बिना नै प्रभावकारी रूपमा छोडियौं र जब होस्टर समस्याहरू समाधान गरे।

निष्कर्ष:

हामीले पहिले कामको तयारी गर्दा बाह्य कारकहरूलाई बेवास्ता गर्यौं, तर अब हामीले तिनीहरूलाई हाम्रो योजनामा समावेश गरेका छौं। हामी अब सबै कम्पोनेन्टहरूलाई n-2 मा आरक्षित गर्ने लक्ष्य राख्दैछौं, र हामी कामको क्रममा यो स्तरलाई n-1 मा घटाउन सक्छौं।

आफ्नो कार्य योजना बनाउँदा, सेवा असफल हुन सक्ने बुँदाहरू उल्लेख गर्नुहोस् र सबैभन्दा खराब परिस्थितिको लागि पहिले नै योजना बनाउनुहोस्।
विभिन्न भू-स्थान/डेटा केन्द्र/र्‍याक/स्विच/इनपुटहरूमा आन्तरिक DNS सर्भरहरू वितरण गर्नुहोस्।
प्रत्येक सर्भरमा, स्थानीय क्यासिङ DNS सर्भर स्थापना गर्नुहोस् जसले अनुरोधहरूलाई मुख्य DNS सर्भरहरूमा रिडिरेक्ट गर्दछ, र यदि यो उपलब्ध छैन भने, क्यासबाट प्रतिक्रिया दिनेछ।

चौथो स्थान - "Nginx सफा गर्दै"

एक दिन, हाम्रो टोलीले यो "पर्याप्त" भएको निर्णय गर्‍यो, र हामीले nginx कन्फिगरेसन फाइलहरूको रिफ्याक्टरिङ सुरु गर्‍यौं। मुख्य लक्ष्य कन्फिगरेसन फाइलहरूलाई सहज संरचनामा ल्याउनु थियो। पहिले, सबै कुरा "ऐतिहासिक रूपमा स्थापित" र अतार्किक थियो। अब, हामीले प्रत्येक server_name लाई एउटै नामको फाइलमा सारेका छौं, र सबै कन्फिगरेसन फाइलहरू फोल्डरहरूमा व्यवस्थित छन्। संयोगवश, कन्फिगरेसन फाइलमा २५३,९४९ लाइनहरू, वा ७,८३६,५२० वर्णहरू छन्, र लगभग ७ मेगाबाइटहरू लिन्छ। शीर्ष-स्तरीय संरचना:

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 समावेश निर्देशनमा समावेश गरिएको थिएन। फलस्वरूप, केही होस्टहरू अनुपलब्ध भए र मुख्य पृष्ठमा ३०१ त्रुटिहरू फर्काए। प्रतिक्रिया कोड ५xx/४xx नभएकोले, यो तुरुन्तै, भोलिपल्ट बिहानसम्म याद भएन। त्यसपछि, हामीले पूर्वाधार कम्पोनेन्टहरू प्रमाणित गर्न परीक्षणहरू लेख्न थाल्यौं।

निष्कर्ष:

आफ्नो कन्फिगरेसन फाइलहरू (nginx मात्र होइन) लाई उचित रूपमा संरचना गर्नुहोस् र परियोजनाको सुरुमै संरचनाको बारेमा सोच्नुहोस्। यसले तिनीहरूलाई टोलीलाई अझ बुझ्ने बनाउनेछ, जसले गर्दा TTM कम हुनेछ।
केही पूर्वाधार कम्पोनेन्टहरूको लागि परीक्षणहरू लेख्नुहोस्। उदाहरणका लागि: सबै सर्भर_नाम कुञ्जीहरूले सही स्थिति र प्रतिक्रिया बडी फर्काउँछन् कि भनेर जाँच गर्ने। कम्पोनेन्टको आधारभूत कार्यहरू जाँच गर्ने केही स्क्रिप्टहरू हुनु बिहान ३ बजे जाँच गर्नुपर्ने अरू के के कुराहरू सम्झनु पर्दैन भनेर सम्झन पर्याप्त छ।

तेस्रो स्थान - "क्यासान्ड्रामा अचानक ठाउँ सकियो"

डेटा निरन्तर बढ्दै गयो, र क्यासान्ड्रा क्लस्टरले ठूला किस्पेसहरूमा मर्मत क्र्यास गर्न सुरु नगरेसम्म सबै कुरा ठीक थियो किनभने कम्प्याक्सनले काम गर्न सकेन।

एक वर्षाको दिनमा त्यो झुप्पो लगभग फर्सीमा परिणत भयो, अर्थात्:

क्लस्टरमा जम्मा २०% ठाउँहरू बाँकी थिए;
नोडहरू पूर्ण रूपमा थप्न असम्भव छ किनभने विभाजनहरूमा ठाउँको कमीको कारण नोड थपेपछि सफाई पूरा हुँदैन;
कम्प्याक्सनले काम नगरेको कारणले गर्दा प्रदर्शन बिस्तारै घट्दै जान्छ;
क्लस्टर आपतकालीन मोडमा सञ्चालन भइरहेको छ।

समाधान भनेको सफा नगरी थप पाँचवटा नोडहरू थप्नु थियो, त्यसपछि तिनीहरूले व्यवस्थित रूपमा क्लस्टरबाट हटाउन थाले र ठाउँ सकिएको खाली नोडहरूको रूपमा पुन: घुसाउन थाले। यसले हामीले चाहेको भन्दा धेरै समय लियो। आंशिक वा पूर्ण क्लस्टर अनुपलब्ध हुने जोखिम थियो।

निष्कर्ष:

सबै क्यासान्ड्रा सर्भरहरूमा प्रत्येक विभाजनमा ६०% भन्दा बढी ठाउँ ओगटेको हुनु हुँदैन।
तिनीहरू CPU को ५०% भन्दा बढी लोड हुनु हुँदैन।
क्षमता योजनालाई बेवास्ता नगर्नुहोस्; यसलाई प्रत्येक घटकको लागि यसको विशिष्टताहरूको आधारमा सोच्न आवश्यक छ।
क्लस्टरमा जति धेरै नोडहरू हुन्छन्, त्यति नै राम्रो। थोरै मात्रामा डेटा भएका सर्भरहरू छिटो पुन: लोड हुन्छन्, र यस्तो क्लस्टर पुनर्स्थापना गर्न सजिलो हुन्छ।

दोस्रो स्थान: "कन्सुल कुञ्जी-मान भण्डारणबाट डेटा गायब भयो"

धेरै अरू जस्तै, हामी सेवा खोजको लागि कन्सुल प्रयोग गर्छौं। तर हामी मोनोलिथको नीलो-हरियो तैनातीको लागि यसको कुञ्जी-मान स्टोर पनि प्रयोग गर्छौं। यसले सक्रिय र निष्क्रिय अपस्ट्रिमहरूको बारेमा जानकारी भण्डारण गर्दछ, जुन तैनातीको समयमा स्वैप गरिन्छ। यस उद्देश्यको लागि एक तैनाती सेवा लेखिएको थियो जसले KV सँग अन्तरक्रिया गर्‍यो। कुनै समयमा, KV बाट डेटा हराएको थियो। हामीले यसलाई मेमोरीबाट पुनर्स्थापित गर्यौं, तर धेरै त्रुटिहरू सहित। फलस्वरूप, तैनातीको समयमा अपस्ट्रिमहरूमा लोड असमान रूपमा वितरित गरिएको थियो, र ब्याकएन्ड CPU ओभरलोडको कारण हामीले धेरै 502 त्रुटिहरू प्राप्त गर्यौं। फलस्वरूप, हामीले कन्सुल KV बाट पोस्टग्रेसमा स्थानान्तरण गर्यौं, जहाँबाट तिनीहरूलाई मेटाउन अब त्यति सजिलो छैन।

निष्कर्ष:

कुनै पनि प्रमाणीकरण बिनाका सेवाहरूमा साइटको सञ्चालनको लागि महत्वपूर्ण डेटा हुनु हुँदैन। उदाहरणका लागि, यदि तपाईंसँग ES मा प्रमाणीकरण छैन भने, सबै अनावश्यक स्थानहरूबाट नेटवर्क-स्तर पहुँच ब्लक गर्नु, आवश्यक पहुँच मात्र अनुमति दिनु, र action.destructive_requires_name: true सेट गर्नु उत्तम हुन्छ।
आफ्नो ब्याकअप र रिस्टोर संयन्त्र पहिले नै अभ्यास गर्नुहोस्। उदाहरणका लागि, एउटा स्क्रिप्ट सिर्जना गर्नुहोस् (उदाहरणका लागि, पाइथनमा) जसले ब्याकअप र रिस्टोर दुवै गर्न सक्छ।

पहिलो स्थान - "क्याप्टेन स्पष्ट"

कुनै समयमा, हामीले ब्याकएन्डमा १०+ सर्भरहरू हुँदा NGINX अपस्ट्रिमहरूमा असमान लोड वितरण देख्यौं। राउन्ड-रोबिनले पहिलोबाट अन्तिम अपस्ट्रिममा अनुरोधहरूलाई क्रमबद्ध रूपमा राउट गरेको हुनाले, र NGINX ले सुरुबाट प्रत्येक रिलोड सुरु गरेको हुनाले, पहिलो अपस्ट्रिमहरूले सधैं अरूहरू भन्दा बढी अनुरोधहरू प्राप्त गर्थे। फलस्वरूप, तिनीहरूले ढिलो काम गरे, र सम्पूर्ण साइटले क्षति भोग्यो। ट्राफिक बढ्दै जाँदा यो बढ्दो रूपमा उल्लेखनीय भयो। अनियमितता सक्षम गर्न NGINX अद्यावधिक गर्नाले मात्र काम गरेन - हामीले लुआ कोडको गुच्छा पुन: गर्नुपर्‍यो, जुन संस्करण १.१५ मा काम गरेको थिएन (त्यस समयमा)। अनियमितता समर्थन लागू गर्न हामीले हाम्रो NGINX १.१४.२ प्याच गर्नुपर्‍यो। यसले समस्या समाधान गर्‍यो। यो बगले "क्याप्टेन अब्स्क्योर" पुरस्कार जित्छ।

निष्कर्ष:

यो बग अन्वेषण गर्न धेरै रोचक र रोमाञ्चक थियो)।

यस्ता उतारचढावहरू छिटो पहिचान गर्न मद्दत गर्न आफ्नो अनुगमन प्रणाली निर्माण गर्नुहोस्। उदाहरणका लागि, तपाईंले प्रत्येक अपस्ट्रीमको प्रत्येक ब्याकएन्डको लागि RPS निगरानी गर्न र Nginx को दृष्टिकोणबाट तिनीहरूको प्रतिक्रिया समय ट्र्याक गर्न ELK प्रयोग गर्न सक्नुहुन्छ। यस अवस्थामा, यसले हामीलाई समस्या पहिचान गर्न मद्दत गर्‍यो।

फलस्वरूप, तपाईंले गर्ने काममा अझ सावधानीपूर्वक दृष्टिकोण अपनाएको भए धेरैजसो असफलताहरूबाट बच्न सकिन्थ्यो। मर्फीको नियम सधैं सम्झनुहोस्: जे पनि गलत हुन सक्छ, त्यो गलत हुनेछ, र त्यसमा आधारित कम्पोनेन्टहरू निर्माण गर्नुहोस्।

स्रोत: www.habr.com