डाटाबेस इन्फ्रास्ट्रक्चर इवोल्यूशन: डेटाबेस और एप्लिकेशन से एक सर्वर पर स्ट्रीमिंग प्रतिकृति के लिए

नमस्कार, हेब्र!

मेरा नाम एंटोन मार्कोलोव है, मैं संयुक्त ट्रेडर्स में एक ऑप्स इंजीनियर हूं। हम एक तरह से परियोजनाओं में लगे हुए हैं या दूसरे निवेश, आदान-प्रदान और अन्य वित्तीय मामलों से जुड़े हैं। हम एक बहुत बड़ी कंपनी नहीं हैं, लगभग 30 विकास इंजीनियर हैं, तराजू उपयुक्त है - सौ सर्वर से थोड़ा कम। हमारे बुनियादी ढांचे की मात्रात्मक और गुणात्मक वृद्धि के दौरान, क्लासिक समाधान "हम एक ही सर्वर पर एप्लिकेशन और उसके डेटाबेस दोनों को रखते हैं" विश्वसनीयता और गति के मामले में हम दोनों के अनुरूप नहीं है। विश्लेषकों की ओर से, क्रॉस-डेटाबेस प्रश्नों को बनाने की आवश्यकता थी, ऑपरेशन विभाग बैकअप के साथ गड़बड़ करने और बड़ी संख्या में डेटाबेस सर्वरों की निगरानी करने के लिए थक गया था। उसके शीर्ष पर, उसी मशीन पर राज्य को संग्रहीत करने के रूप में आवेदन ने स्वयं संसाधन नियोजन के लचीलेपन और बुनियादी ढांचे के लचीलेपन को कम कर दिया।

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

यह लेख UPTIMEDAY सम्मेलन में मेरी रिपोर्ट का एक सारांश है, हो सकता है कि वीडियो प्रारूप किसी के लिए अधिक आरामदायक होगा, हालांकि लेखक एक मुंह वक्ता की तुलना में मेरे हाथों से थोड़ा बेहतर है।

KDPV के साथ "स्नोफ्लेक मैन" बेशर्मी से मैक्सिम डोरोफीव से उधार लिया गया था।

वृद्धि रोग

हमारे पास एक माइक्रोसैस आर्किटेक्चर है, स्प्रिंग फ्रेम का उपयोग करके सेवाएं मुख्य रूप से जावा या कोटलिन में लिखी जाती हैं। प्रत्येक microservice के आगे एक PostgreSQL बेस है, सब कुछ एक्सेस प्रदान करने के लिए शीर्ष पर nginx द्वारा कवर किया गया है। एक विशिष्ट माइक्रोसर्विस स्प्रिंग बूट पर एक एप्लिकेशन है, जो पोस्टग्रेसीक्यू (उसी समय और क्लिकहाउस में एप्लिकेशन का हिस्सा) के लिए अपना डेटा लिखता है, काफ्का के माध्यम से पड़ोसियों के साथ संचार करता है और बाहरी दुनिया के साथ संचार के लिए कुछ आरईएसटी या ग्राफक्यूएल समापन बिंदु हैं।



पहले, जब हम बहुत छोटे थे, हमने सिर्फ DigitalOcean में कई सर्वर रखे थे, काफ्का अभी तक नहीं था, सभी संचार REST के माध्यम से थे। यही है, हमने एक छोटी बूंद ली, जावा, पोस्टग्रेसीक्यूएल, नग्नेक्स को वहां स्थापित किया, ज़ैबिक्स को वहां लॉन्च किया ताकि यह सर्वर संसाधनों और सेवा समापन बिंदुओं की उपलब्धता पर नजर रखे। उन्होंने सभी चीजों को अंसिबल की मदद से तैनात किया, हमने प्लेबुक को मानकीकृत कर दिया, चार से पांच भूमिकाओं ने पूरी सेवा को लुढ़का दिया। जब तक हमारे पास था, अपेक्षाकृत बोलने, उत्पादन पर 6 सर्वर और परीक्षण पर 3 - आप किसी तरह इसके साथ रह सकते थे।
फिर सक्रिय विकास का दौर शुरू हुआ, अनुप्रयोगों की संख्या बढ़ी, दस माइक्रोसिस्टम चालीस में बदल गए, उनकी कार्यक्षमता बदलने लगी, साथ ही साथ बाहरी सिस्टम जैसे कि सीआरएम, क्लाइंट साइट और जैसे दिखाई देने लगे। हमें पहला दर्द मिला। कुछ अनुप्रयोगों ने अधिक संसाधनों का उपभोग करना शुरू कर दिया, मौजूदा सर्वरों में जाना बंद कर दिया, हमें बूंदें मिलीं, अनुप्रयोगों को आगे और पीछे खींचा, बहुत सारे हाथ उठाए। यह काफी बुरी तरह से चोट लगी है - कोई भी बेवकूफ यांत्रिक काम पसंद नहीं करता है, - मैं जल्दी से फैसला करना चाहता था। इसलिए हम सिर-ऑन कर गए - हमने 10 क्लाउड बूंदों के बजाय सिर्फ 3 बड़े समर्पित सर्वर लिए। इसने कुछ समय के लिए समस्या को बंद कर दिया, लेकिन यह स्पष्ट हो गया कि यह ऑर्केस्ट्रेशन और सर्वर असंतुलन के कुछ विकल्पों के लिए काम करने का समय था। हमने DC / OS और Kubernetes जैसे समाधानों को करीब से देखना शुरू किया और धीरे-धीरे इस क्षेत्र में अपनी विशेषज्ञता को बढ़ाया।

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

सुपर गुलाम

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



हमने विज़ुअलाइज़ेशन के लिए रेडैश लिया, यह जानता है कि ग्राफ़ कैसे बनाएं , शेड्यूल पर अनुरोधों को निष्पादित करें, उदाहरण के लिए, दिन में एक बार, और अधिकारों की एक भारित प्रणाली है, इसलिए हम विश्लेषकों और डेवलपर्स को वहां जाने देते हैं।



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

हमने एक समाधान की तलाश शुरू की जो निम्नलिखित आवश्यकताओं को पूरा करे:

• गलती सहिष्णुता: जब एन सर्वर गिरता है, तो क्लस्टर काम करना जारी रखता है;
• अनुप्रयोगों के लिए, सब कुछ पहले जैसा होना चाहिए, कोड में कोई बदलाव नहीं;
• तैनाती और प्रबंधन में आसानी;
• नियमित PostgreSQL पर अमूर्त की कम परतों;
• आदर्श रूप से, संतुलन संतुलित करें ताकि सभी अनुरोध एक सर्वर पर न जाएं;
• आदर्श रूप में, यह एक परिचित भाषा में लिखा गया है।

कई उम्मीदवार नहीं थे:

• मानक स्ट्रीमिंग प्रतिकृति (repmgr, Patroni, Stolon);
• ट्रिगर-आधारित प्रतिकृति (Londiste, Slony);
• मध्य परत क्वेरी प्रतिकृति (pgpool-II);
• कई कोर सर्वर (बुकार्डो) के साथ तुल्यकालिक प्रतिकृति।

एक बड़े हिस्से के साथ, क्रॉसबेस के निर्माण के दौरान हमारे पास पहले से ही बुरे अनुभव थे, इसलिए पेट्रोनी और स्टोलन बने रहे। पैट्रोनी को पायथन, गो में स्टोलन में लिखा गया है, हमारे पास दोनों भाषाओं में पर्याप्त विशेषज्ञता है। इसके अलावा, उनके पास समान वास्तुकला और कार्यक्षमता है, इसलिए विकल्प व्यक्तिपरक कारणों के लिए बनाया गया था: पैट्रोनी को ज़ालैंडो द्वारा विकसित किया गया था, और हमने एक बार उनके नाकाडी प्रोजेक्ट (कास्ट के लिए रीस्ट एपीआई) के साथ काम करने की कोशिश की, जहां हमें प्रलेखन की भारी कमी का सामना करना पड़ा।

भूस्तरी

स्टोलन की वास्तुकला काफी सरल है: एन सर्वर हैं, लीडर को एल्ड / कॉन्सुल का उपयोग करके चुना जाता है, पोस्टग्रेएसक्यू को विजार्ड मोड में लॉन्च किया जाता है और अन्य सर्वरों को दोहराया जाता है। फिर स्टोलन परदे के पीछे इस पोस्टग्रेसीक्यू-मास्टर में जाते हैं, साधारण पोस्टग्रेज के साथ आवेदन करने का नाटक करते हैं, और क्लाइंट इन प्रॉक्सी में जाते हैं। मास्टर के लापता होने की स्थिति में, फिर से चुनाव होते हैं, कोई और मास्टर बन जाता है, बाकी स्टैंड-बाय हो जाते हैं। अमूर्तता की कुछ परतें होती हैं, PostgreSQL को हमेशा की तरह स्थापित किया गया है, केवल चेतावनी यह है कि PostgreSQL कॉन्फिगरेशन को etcd में संग्रहीत किया गया है, और इसे कुछ अलग तरीके से कॉन्फ़िगर किया गया है।

क्लस्टर का परीक्षण करते समय, हमने काफी कुछ समस्याएं पकड़ी:

• स्टोलन को पता नहीं है कि ज़ूकेपर के शीर्ष पर कैसे काम करना है, केवल कौंसुल या वल्ड;
• आईओडी के प्रति संवेदनशील बहुत संवेदनशील है। यदि आप एक ही सर्वर पर PostgreSQL और etcd रखते हैं, तो आपको निश्चित रूप से तेज SSDs की आवश्यकता होती है;
• एसएसडी पर भी टाइमआउट वगैरह को कॉन्फ़िगर करना आवश्यक है, अन्यथा सब कुछ लोड के तहत टूट जाएगा - क्लस्टर सोचेंगे कि मास्टर गिर गया है और लगातार कनेक्शन तोड़ देगा;
• डिफ़ॉल्ट रूप से, PostgreSQL पर max_connections छोटा है (200), आपको इसे अपनी आवश्यकताओं तक बढ़ाने की आवश्यकता है;
• तीन etcd का एक क्लस्टर केवल एक सर्वर की मृत्यु से बचेगा, आदर्श रूप से आपको कॉन्फ़िगरेशन की आवश्यकता होगी, उदाहरण के लिए 5/3 + 3 वोलन;
• बॉक्स से बाहर, सभी कनेक्शन मास्टर के पास जाते हैं, दास कनेक्शन के लिए सुलभ नहीं होते हैं।

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



निम्न चित्र निकला: अनुप्रयोगों से अनुरोध स्टोलन-प्रॉक्सी पोर्ट पर जाते हैं, जो उन्हें मास्टर पर पुनर्निर्देशित करता है, और विश्लेषकों से अनुरोध (वे हमेशा पढ़े जाते हैं) केवल HAProxy पोर्ट पर जाते हैं, जो उन्हें किसी दास को फेंक देता है।

इसके अलावा, सचमुच आज, स्टोलन में एक पीआर को अपनाया गया था, जिसने स्टोलन के उदाहरणों के बारे में जानकारी को तीसरे पक्ष की सेवा खोज को भेजने की अनुमति दी थी।



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

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

निगरानी करना और त्रुटियों को पकड़ना

इन्फ्रास्ट्रक्चर की वृद्धि और माइक्रोसर्विस की जटिलता के साथ, मैं आवेदन और जावा मशीन के अंदर क्या हो रहा है, इसके बारे में अधिक जानकारी एकत्र करना चाहता था। हम Zabbix को नए परिवेश में नहीं ढाल पाए: यह एक बदलते बुनियादी ढाँचे की स्थितियों में बहुत असुविधाजनक है। मुझे या तो इसके एपीआई के माध्यम से बैसाखी को पीसना था, या अपने हाथों से अंदर चढ़ना था, जो और भी बदतर है। इसका डेटाबेस खराब भार के अनुकूल है, और सामान्य तौर पर यह सब एक संबंधपरक डेटाबेस में डालने के लिए बहुत असुविधाजनक है।

परिणामस्वरूप, हमने निगरानी के लिए प्रोमेथियस को चुना। मेट्रिक्स प्रदान करने के लिए वसंत अनुप्रयोगों के लिए उनके पास एक बॉक्स आउट एक्टुवेटर है, काफ्का के लिए उन्होंने जेएमएक्स एक्सपोर्टर को खराब कर दिया, जो मेट्रिक्स को भी सहज तरीके से प्रदान करता है। जिन निर्यातकों को "बॉक्स में" नहीं मिला था, हमने खुद को पायथन में लिखा था, उनमें से लगभग दस हैं। हम ग्रेफाना की कल्पना करते हैं, ग्रेगल के साथ लॉग इकट्ठा करते हैं (क्योंकि वह अब बीट्स का समर्थन करता है)।

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

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