🥇हमने CIAN में लॉग के टेराबाइट्स को कैसे नियंत्रित किया

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

हमने कहां से शुरुआत की?

पिछले कुछ वर्षों में, cian.ru पर लोड बहुत तेजी से बढ़ा है, और 2018 की तीसरी तिमाही तक, संसाधन ट्रैफ़िक प्रति माह 11.2 मिलियन अद्वितीय उपयोगकर्ताओं तक पहुंच गया। उस समय, महत्वपूर्ण क्षणों में हमने 40% तक लॉग खो दिए, यही कारण है कि हम घटनाओं से तुरंत नहीं निपट सके और उन्हें हल करने में बहुत समय और प्रयास खर्च किया। हम भी अक्सर समस्या का कारण नहीं ढूंढ पाते और कुछ समय बाद यह दोबारा हो जाती है। यह नरक था और इसके बारे में कुछ किया जाना था।

उस समय, हमने लॉग्स को स्टोर करने के लिए मानक इंडेक्स सेटिंग्स के साथ ElasticSearch संस्करण 10 के साथ 5.5.2 डेटा नोड्स के क्लस्टर का उपयोग किया था। इसे एक साल से अधिक समय पहले एक लोकप्रिय और किफायती समाधान के रूप में पेश किया गया था: तब लॉग का प्रवाह इतना बड़ा नहीं था, गैर-मानक कॉन्फ़िगरेशन के साथ आने का कोई मतलब नहीं था।

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

तीव्र विकास की चुनौतियाँ

जेनरेट किए गए लॉग की मात्रा बहुत तेजी से बढ़ी, क्योंकि दो प्रक्रियाएं एक-दूसरे पर ओवरलैप हो गईं। एक ओर, सेवा के उपयोगकर्ताओं की संख्या में वृद्धि हुई। दूसरी ओर, हमने C# और Python में अपने पुराने मोनोलिथ को देखते हुए सक्रिय रूप से माइक्रोसर्विस आर्किटेक्चर पर स्विच करना शुरू कर दिया। मोनोलिथ के हिस्सों को बदलने वाले कई दर्जन नए माइक्रोसर्विसेज ने इंफ्रास्ट्रक्चर क्लस्टर के लिए काफी अधिक लॉग उत्पन्न किए।

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

इससे रैम के आवंटन में समस्याएं पैदा हुईं, और जब एक नोड दुर्घटनाग्रस्त हो गया, तो सभी शार्ड एक साथ चलने लगे, जिससे ट्रैफ़िक बढ़ गया और अन्य नोड्स लोड हो गए, जिससे क्लस्टर में डेटा लिखना लगभग असंभव हो गया। और इस अवधि के दौरान हम बिना लॉग के रह गए थे। और यदि सर्वर में कोई समस्या थी, तो हमने मूल रूप से क्लस्टर का 1/10 हिस्सा खो दिया। बड़ी संख्या में छोटे सूचकांकों ने जटिलता बढ़ा दी।

लॉग के बिना, हम घटना के कारणों को समझ नहीं पाए और देर-सबेर फिर से उसी रास्ते पर कदम रख सकते थे, और हमारी टीम की विचारधारा में यह अस्वीकार्य था, क्योंकि हमारे सभी कार्य तंत्र ठीक इसके विपरीत करने के लिए डिज़ाइन किए गए हैं - कभी न दोहराएं वही समस्याएं. ऐसा करने के लिए, हमें लॉग की पूरी मात्रा और लगभग वास्तविक समय में उनकी डिलीवरी की आवश्यकता थी, क्योंकि ऑन-ड्यूटी इंजीनियरों की एक टीम ने न केवल मेट्रिक्स से, बल्कि लॉग से भी अलर्ट की निगरानी की। समस्या के पैमाने को समझने के लिए, उस समय लॉग की कुल मात्रा लगभग 2 टीबी प्रति दिन थी।

हमने अप्रत्याशित घटना के दौरान लॉग के नुकसान को पूरी तरह से समाप्त करने और ईएलके क्लस्टर में उनकी डिलीवरी के समय को अधिकतम 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".

हमने इस समस्या का समाधान अगले पुनरावृत्ति के लिए छोड़ दिया और एक और मुद्दा उठाया: हमने लॉगस्टैश के पुल लॉजिक पर स्विच किया, जो आने वाले लॉग को संसाधित करता है (अनावश्यक जानकारी को हटाकर और समृद्ध करता है)। हमने इसे डॉकर में रखा है, जिसे हम डॉकर-कंपोज़ के माध्यम से लॉन्च करते हैं, और हमने वहां लॉगस्टैश-एक्सपोर्टर भी रखा है, जो लॉग स्ट्रीम की परिचालन निगरानी के लिए प्रोमेथियस को मेट्रिक्स भेजता है। इस तरह हमने खुद को प्रत्येक प्रकार के लॉग को संसाधित करने के लिए जिम्मेदार लॉगस्टैश इंस्टेंस की संख्या को सुचारू रूप से बदलने का अवसर दिया।

जब हम क्लस्टर में सुधार कर रहे थे, cian.ru का ट्रैफ़िक प्रति माह 12,8 मिलियन अद्वितीय उपयोगकर्ताओं तक बढ़ गया। नतीजतन, यह पता चला कि हमारे परिवर्तन उत्पादन में बदलाव से थोड़ा पीछे थे, और हमें इस तथ्य का सामना करना पड़ा कि "गर्म" नोड्स लोड का सामना नहीं कर सके और लॉग की पूरी डिलीवरी को धीमा कर दिया। हमें बिना किसी असफलता के "हॉट" डेटा प्राप्त हुआ, लेकिन हमें बाकी की डिलीवरी में हस्तक्षेप करना पड़ा और इंडेक्स को समान रूप से वितरित करने के लिए मैन्युअल रोलओवर करना पड़ा।

उसी समय, क्लस्टर में लॉगस्टैश इंस्टेंस की सेटिंग्स को स्केल करना और बदलना इस तथ्य से जटिल था कि यह एक स्थानीय डॉकर-कंपोज़ था, और सभी क्रियाएं मैन्युअल रूप से की गईं (नए सिरे जोड़ने के लिए, सभी को मैन्युअल रूप से पूरा करना आवश्यक था) सर्वर और हर जगह docker-compose up -d करते हैं)।

लॉग पुनर्वितरण

इस साल सितंबर में, हम अभी भी मोनोलिथ को काट रहे थे, क्लस्टर पर भार बढ़ रहा था, और लॉग का प्रवाह प्रति सेकंड 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 थे), लेकिन क्लस्टर प्रदर्शन के दृष्टिकोण से यह सहनीय है।

परिणामस्वरूप, क्लस्टर में छह "गर्म" और केवल चार "गर्म" नोड थे। इससे लंबे समय के अंतराल पर अनुरोधों में थोड़ी देरी होती है, लेकिन भविष्य में नोड्स की संख्या बढ़ने से यह समस्या हल हो जाएगी।

इस पुनरावृत्ति ने अर्ध-स्वचालित स्केलिंग की कमी की समस्या को भी ठीक कर दिया। ऐसा करने के लिए, हमने एक बुनियादी ढांचा घुमंतू क्लस्टर तैनात किया - जो कि हम पहले से ही उत्पादन में तैनात कर चुके हैं। अभी के लिए, लॉगस्टैश की मात्रा लोड के आधार पर स्वचालित रूप से नहीं बदलती है, लेकिन हम इस पर आएंगे।

Планы на будущее

कार्यान्वित कॉन्फ़िगरेशन पूरी तरह से स्केल करता है, और अब हम 13,3 टीबी डेटा संग्रहीत करते हैं - 4 दिनों के लिए सभी लॉग, जो अलर्ट के आपातकालीन विश्लेषण के लिए आवश्यक है। हम कुछ लॉग को मेट्रिक्स में परिवर्तित करते हैं, जिन्हें हम ग्रेफाइट में जोड़ते हैं। इंजीनियरों के काम को आसान बनाने के लिए, हमारे पास बुनियादी ढांचे के क्लस्टर के लिए मेट्रिक्स और सामान्य समस्याओं की अर्ध-स्वचालित मरम्मत के लिए स्क्रिप्ट हैं। डेटा नोड्स की संख्या बढ़ाने के बाद, जो अगले वर्ष के लिए योजना बनाई गई है, हम 4 से 7 दिनों तक डेटा स्टोरेज पर स्विच करेंगे। यह परिचालन कार्य के लिए पर्याप्त होगा, क्योंकि हम हमेशा घटनाओं की जल्द से जल्द जांच करने का प्रयास करते हैं, और दीर्घकालिक जांच के लिए टेलीमेट्री डेटा मौजूद है।

अक्टूबर 2019 में, cian.ru पर ट्रैफ़िक पहले ही प्रति माह 15,3 मिलियन अद्वितीय उपयोगकर्ताओं तक बढ़ गया था। यह लॉग वितरित करने के लिए वास्तुशिल्प समाधान का एक गंभीर परीक्षण बन गया।

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

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

स्रोत: www.habr.com

CIAN में हमने टेराबाइट्स लॉग को कैसे नियंत्रित किया