हामीले कसरी CIAN मा टेराबाइट लगहरू नियन्त्रण गर्यौं

सबैलाई नमस्कार, मेरो नाम अलेक्जेन्डर हो, म CIAN मा एक इन्जिनियरको रूपमा काम गर्छु र प्रणाली प्रशासन र पूर्वाधार प्रक्रियाहरूको स्वचालनमा संलग्न छु। अघिल्लो लेखहरू मध्ये एकको टिप्पणीमा, हामीलाई प्रति दिन 4 TB लगहरू कहाँ पाउँछौं र हामी तिनीहरूसँग के गर्छौं भनेर बताउन सोधिएको थियो। हो, हामीसँग धेरै लगहरू छन्, र तिनीहरूलाई प्रशोधन गर्न छुट्टै पूर्वाधार क्लस्टर सिर्जना गरिएको छ, जसले हामीलाई समस्याहरू द्रुत रूपमा समाधान गर्न अनुमति दिन्छ। यस लेखमा म कसरी डाटाको बढ्दो प्रवाहको साथ काम गर्न एक वर्षको अवधिमा यसलाई अनुकूलन गर्यौं भन्ने बारे कुरा गर्नेछु।

हामीले कहाँ सुरु गर्यौं?

विगत केही वर्षहरूमा, cian.ru मा लोड धेरै छिटो बढेको छ, र 2018 को तेस्रो त्रैमासिक सम्म, स्रोत ट्राफिक प्रति महिना 11.2 मिलियन अद्वितीय प्रयोगकर्ताहरू पुग्यो। त्यस समयमा, महत्वपूर्ण क्षणहरूमा हामीले लगहरूको 40% सम्म गुमायौं, जसको कारणले गर्दा हामीले घटनाहरू चाँडै सामना गर्न सकेनौं र तिनीहरूलाई समाधान गर्न धेरै समय र प्रयास खर्च्यौं। हामीले पनि प्रायः समस्याको कारण पत्ता लगाउन सकेनौं, र यो केहि समय पछि दोहोरिनेछ। यो नरक थियो र यसको बारेमा केहि गर्न आवश्यक थियो।

त्यस समयमा, हामीले लगहरू भण्डारण गर्न मानक अनुक्रमणिका सेटिङहरूसँग ElasticSearch संस्करण 10 सँग 5.5.2 डेटा नोडहरूको क्लस्टर प्रयोग गर्यौं। यो एक वर्ष भन्दा पहिले एक लोकप्रिय र किफायती समाधान को रूप मा पेश गरिएको थियो: त्यसपछि लग को प्रवाह यति ठूलो थिएन, गैर-मानक कन्फिगरेसन संग आउन को लागी कुनै मतलब थिएन। 

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

तीव्र वृद्धिका चुनौतीहरू

उत्पन्न लगहरूको मात्रा धेरै छिटो बढ्यो, किनकि दुई प्रक्रियाहरू एकअर्कालाई ओभरल्याप गरे। एकातिर सेवाग्राहीको संख्या बढेको छ । अर्कोतर्फ, हामीले C# र पाइथनमा हाम्रा पुराना मोनोलिथहरू हेर्दै, माइक्रोसर्भिस आर्किटेक्चरमा सक्रिय रूपमा स्विच गर्न थाल्यौं। मोनोलिथका भागहरू प्रतिस्थापन गर्ने धेरै दर्जन नयाँ माइक्रोसर्भिसेसहरूले पूर्वाधार क्लस्टरका लागि उल्लेखनीय रूपमा थप लगहरू उत्पन्न गरे। 

यो स्केलिङ थियो जसले हामीलाई बिन्दुमा पुर्यायो जहाँ क्लस्टर व्यावहारिक रूपमा अव्यवस्थित भयो। जब लगहरू 20 हजार सन्देशहरू प्रति सेकेन्डको दरमा आउन थाले, बारम्बार बेकार रोटेशनले शार्डहरूको संख्या 6 हजारमा बढायो, र त्यहाँ प्रति नोड 600 भन्दा बढी शार्डहरू थिए। 

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

लगहरू बिना, हामीले घटनाको कारणहरू बुझ्न सकेनौं र ढिलो वा पछि फेरि एउटै रेकमा पाइला चाल्न सक्छौं, र हाम्रो टोलीको विचारधारामा यो अस्वीकार्य थियो, किनकि हाम्रा सबै कार्य संयन्त्रहरू उल्टो गर्न डिजाइन गरिएको हो - कहिल्यै दोहोर्याउनुहोस्। उस्तै समस्याहरू। यो गर्नको लागि, हामीलाई लगहरूको पूर्ण मात्रा र तिनीहरूको डेलिभरी लगभग वास्तविक समयमा आवश्यक थियो, किनकि अन-ड्युटी इन्जिनियरहरूको टोलीले मेट्रिक्सबाट मात्र होइन, लगहरूबाट पनि अलर्टहरू निगरानी गर्‍यो। समस्याको मापन बुझ्न, त्यस समयमा लगहरूको कुल मात्रा प्रति दिन लगभग 2 TB थियो। 

हामीले लगहरूको हानिलाई पूर्णतया हटाउने र बल majeure को समयमा ELK क्लस्टरमा तिनीहरूको डेलिभरीको समयलाई अधिकतम 15 मिनेटमा घटाउने लक्ष्य सेट गर्‍यौं (हामीले पछि आन्तरिक KPI को रूपमा यो आंकडामा भर पर्यौं)।

नयाँ रोटेशन मेकानिजम र तातो-तातो नोडहरू

हामीले 5.5.2 बाट 6.4.3 सम्म इलास्टिकसर्च संस्करण अद्यावधिक गरेर क्लस्टर रूपान्तरण सुरु गर्यौं। फेरि हाम्रो संस्करण 5 क्लस्टरको मृत्यु भयो, र हामीले यसलाई बन्द गर्ने र यसलाई पूर्ण रूपमा अद्यावधिक गर्ने निर्णय गर्‍यौं - त्यहाँ अझै कुनै लगहरू छैनन्। त्यसोभए हामीले केही घण्टामा यो संक्रमण गर्यौं।

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

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

क्लस्टर अनुकूलन

तर, समस्याबाट पूर्ण रूपमा मुक्त हुन सकेका छैनौँ । दुर्भाग्यवश, साना अनुक्रमणिकाहरू अझै देखा परेका छन्: तिनीहरू निर्दिष्ट भोल्युममा पुग्न सकेनन्, घुमाइएको थिएन, र तीन दिन भन्दा पुराना अनुक्रमणिकाहरूको विश्वव्यापी सफाईद्वारा मेटाइयो, किनकि हामीले मिति अनुसार रोटेशन हटायौं। क्लस्टरबाट अनुक्रमणिका पूर्ण रूपमा गायब भएको तथ्यको कारणले यसले डेटा हानि गर्‍यो, र अवस्थित नभएको अनुक्रमणिकामा लेख्ने प्रयासले हामीले व्यवस्थापनको लागि प्रयोग गरेको क्युरेटरको तर्कलाई तोड्यो। लेखनको लागि उपनामलाई अनुक्रमणिकामा रूपान्तरण गरियो र रोलओभर तर्कलाई तोडियो, जसले 600 GB सम्म केही अनुक्रमणिकाहरूको अनियन्त्रित वृद्धि निम्त्यायो। 

उदाहरण को लागी, रोटेशन कन्फिगरेसन को लागी:

с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 मिलियन अद्वितीय प्रयोगकर्ताहरूमा वृद्धि भएको थियो। यो लगहरू वितरणको लागि वास्तु समाधानको गम्भीर परीक्षण भयो। 

अब हामी संस्करण 7 मा ElasticSearch अद्यावधिक गर्ने तयारी गर्दैछौं। यद्यपि, यसको लागि हामीले ElasticSearch मा धेरै अनुक्रमणिकाहरूको म्यापिङ अद्यावधिक गर्नुपर्नेछ, किनभने तिनीहरू संस्करण 5.5 बाट सारियो र संस्करण 6 मा अस्वीकार गरिएको घोषणा गरियो (तिनीहरू केवल संस्करणमा अवस्थित छैनन्। ७)। यसको मतलब यो हो कि अद्यावधिक प्रक्रियाको बखत त्यहाँ निश्चित रूपमा कुनै प्रकारको बल majeure हुनेछ, जसले समस्या समाधान हुँदा हामीलाई लगहरू बिना छोड्नेछ। संस्करण 7 को, हामी सुधारिएको इन्टरफेस र नयाँ फिल्टरहरूको साथ किबानाको लागि धेरै तत्पर छौं। 

हामीले हाम्रो मुख्य लक्ष्य हासिल गर्यौं: हामीले लगहरू गुमाउन छोड्यौं र पूर्वाधार क्लस्टरको डाउनटाइमलाई प्रति हप्ता 2-3 क्र्यासबाट प्रति महिना मर्मत कार्यको दुई घण्टामा घटायो। उत्पादन मा यो सबै काम लगभग अदृश्य छ। जे होस्, अब हामी हाम्रो सेवाको साथ के भइरहेको छ भनेर ठ्याक्कै निर्धारण गर्न सक्छौं, हामी यसलाई छिटो शान्त मोडमा गर्न सक्छौं र लगहरू हराउनेछ भनेर चिन्ता नगर्नुहोस्। सामान्यतया, हामी सन्तुष्ट, खुसी र नयाँ शोषणको लागि तयारी गर्दैछौं, जसको बारेमा हामी पछि कुरा गर्नेछौं।

स्रोत: www.habr.com