चिंता करना कैसे बंद करें और मोनोलिथ के बिना रहना कैसे शुरू करें

हम सभी को कहानियाँ पसंद हैं। हम आग के पास बैठना और अपनी पिछली जीतों, लड़ाइयों या बस अपने कार्य अनुभव के बारे में बात करना पसंद करते हैं।

आज का दिन ही ऐसा है. और भले ही आप अभी आग पर नहीं हैं, हमारे पास आपके लिए एक कहानी है। हमने टारनटूल पर भंडारण के साथ काम करना कैसे शुरू किया इसकी कहानी।

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

यह अब उपकरण से लेकर व्यावसायिक तर्क तक हर चीज और हर किसी को अलग करने की प्रचलित विचारधारा है। परिणामस्वरूप, उदाहरण के लिए, हमारे पास दो डीसी हैं जो नेटवर्क स्तर पर व्यावहारिक रूप से स्वतंत्र हैं। और फिर सब कुछ बिल्कुल अलग था.

आज, CI/CD, K8S इत्यादि के रूप में परिवर्तन करने के लिए बहुत सारे उपकरण और उपकरण मौजूद हैं। "अखंड" समय में हमें इतने अधिक विदेशी शब्दों की आवश्यकता नहीं थी। यह डेटाबेस में "भंडारण" को ठीक करने के लिए पर्याप्त था।

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

जब पूरी तरह से ब्लैक फ्राइडे की बिक्री दृश्य में दिखाई देने लगी - और वाइल्डबेरीज़ रूस में उन्हें आयोजित करने वाले पहले लोगों में से एक था - स्थिति पूरी तरह से दुखद हो गई। आख़िर ऐसे दिनों में भार तीन गुना बढ़ जाता है।
ओह, ये "अखंड समय"! मुझे यकीन है कि आपने भी कुछ ऐसा ही अनुभव किया होगा, और आप अभी भी नहीं समझ पा रहे हैं कि आपके साथ ऐसा कैसे हो सकता है।

आप क्या कर सकते हैं - फैशन प्रौद्योगिकी में निहित है। लगभग 5 साल पहले, हमें .NET और MS SQL सर्वर पर मौजूदा साइट के रूप में इनमें से एक मॉड पर पुनर्विचार करना पड़ा, जिसने साइट के सभी तर्कों को सावधानीपूर्वक संग्रहीत किया। मैंने इसे इतनी सावधानी से रखा कि इस तरह के मोनोलिथ को देखना एक लंबा और आसान आनंद नहीं था।
एक छोटा सा विषयांतर।

विभिन्न आयोजनों में मैं कहता हूं: "यदि आपने एक पत्थर का खंभा नहीं देखा, तो आप विकसित नहीं हुए!" मुझे इस मामले पर आपकी राय जानने में दिलचस्पी है, कृपया इसे टिप्पणियों में लिखें।

और वज्रपात हुआ

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

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

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

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

परिणामस्वरूप, हम एक ऐसी योजना लेकर आए जो टारनटूल के साथ अच्छी तरह फिट बैठती है।

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

वास्तुकला। विकल्प 1. उपयोगकर्ता सेवा

वर्तमान समय में, 24 शार्ड हैं, जिनमें से प्रत्येक में 2 उदाहरण हैं (प्रत्येक डीसी के लिए एक), सभी मास्टर-मास्टर मोड में हैं।

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

इस मामले में, शार्ड के संदर्भ में प्रतिकृति चयन नीति को कॉन्फ़िगर करना संभव है। उदाहरण के लिए, राउंडरोबिन।

वास्तुकला। विकल्प 2. माल की अंतिम लागत की गणना के लिए सेवा

कुछ महीने पहले, माल की अंतिम लागत की गणना के लिए अधिकांश अनुरोध एक नई सेवा के पास गए, जो सिद्धांत रूप में, डेटाबेस के बिना काम करता है, लेकिन कुछ समय पहले हुड के तहत टारनटूल के साथ एक सेवा द्वारा सब कुछ 100% संसाधित किया गया था।

सेवा डेटाबेस में 4 मास्टर होते हैं जिनमें सिंक्रोनाइज़र डेटा एकत्र करता है, और इनमें से प्रत्येक प्रतिकृति मास्टर डेटा को केवल पढ़ने योग्य प्रतिकृतियों में वितरित करता है। प्रत्येक मास्टर के पास लगभग 15 ऐसी प्रतिकृतियाँ होती हैं।

या तो पहली या दूसरी योजना में, यदि एक डीसी अनुपलब्ध है, तो एप्लिकेशन दूसरे में डेटा प्राप्त कर सकता है।

यह ध्यान देने योग्य है कि टारनटूल में प्रतिकृति काफी लचीली है और इसे रनटाइम पर कॉन्फ़िगर किया जा सकता है। अन्य प्रणालियों में कठिनाइयाँ उत्पन्न हुईं। उदाहरण के लिए, PostgreSQL में max_wal_senders और max_replication_slots पैरामीटर को बदलने के लिए विज़ार्ड को पुनः आरंभ करने की आवश्यकता होती है, जिससे कुछ मामलों में एप्लिकेशन और DBMS के बीच कनेक्शन विच्छेद हो सकता है।

खोजो और खोजो!

हमने इसे "सामान्य लोगों की तरह" क्यों नहीं किया, बल्कि एक असामान्य तरीका चुना? यह इस पर निर्भर करता है कि क्या सामान्य माना जाता है। कई लोग आम तौर पर मोंगो से एक क्लस्टर बनाते हैं और इसे तीन भू-वितरित डीसी में फैलाते हैं।

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

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

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

आख़िरकार हम टारनटूल पर बस गए।

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

बातचीत में मदद के लिए तैयार उत्तरदायी रूसी भाषी समुदाय ने भी भूमिका निभाई। हमने सक्रिय रूप से इसका उपयोग किया और सीधे चैट में रहते हैं। और स्पष्ट भूलों और गलतियों के बिना सभ्य दृढ़ता के बारे में मत भूलना। यदि आप टारनटूल के साथ हमारे इतिहास को देखें, तो हमें प्रतिकृति के साथ बहुत दर्द और विफलताओं का सामना करना पड़ा, लेकिन हमने इसकी गलती के कारण कभी भी डेटा नहीं खोया!

कार्यान्वयन की शुरुआत कठिन रही

उस समय, हमारा मुख्य विकास स्टैक .NET था, जिसमें टारनटूल के लिए कोई कनेक्टर नहीं था। हमने तुरंत गो में कुछ करना शुरू कर दिया। इसने लुआ के साथ भी अच्छा काम किया। उस समय मुख्य समस्या डिबगिंग के साथ थी: .NET में इसके साथ सब कुछ बढ़िया है, लेकिन उसके बाद एम्बेडेड लुआ की दुनिया में उतरना मुश्किल था, जब आपके पास लॉग के अलावा कोई डिबगिंग नहीं थी। इसके अलावा, किसी कारण से प्रतिकृति समय-समय पर विफल हो गई, इसलिए मुझे टारनटूल इंजन की संरचना में गहराई से जाना पड़ा। चैट ने इसमें और कुछ हद तक दस्तावेज़ीकरण में मदद की; कभी-कभी हमने कोड को देखा। उस समय, दस्तावेज़ीकरण इतना ही था।

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

ये विशेष समय थे. परंपरागत रूप से, तब आप अगली टेबल पर व्यवस्थापक के पास जा सकते हैं और पूछ सकते हैं: "मुझे एक वर्चुअल मशीन दीजिए।" लगभग तीस मिनट बाद कार आपके पास थी। आपने खुद को कनेक्ट किया, सब कुछ इंस्टॉल किया और ट्रैफ़िक आपके पास भेज दिया गया।

आज यह काम नहीं करेगा: आपको सेवा में निगरानी और लॉगिंग जोड़ने, परीक्षणों के साथ कार्यक्षमता को कवर करने, वर्चुअल मशीन ऑर्डर करने या कुबेर को डिलीवरी आदि की आवश्यकता है। सामान्य तौर पर, यह इस तरह से बेहतर होगा, हालांकि इसमें अधिक समय लगेगा और अधिक परेशानी होगी।

फूट डालो और शासन करो। लुआ के साथ क्या डील हुई है?

एक गंभीर दुविधा थी: कुछ टीमें लुआ में बहुत सारे तर्क के साथ किसी सेवा में परिवर्तन को विश्वसनीय रूप से लागू करने में असमर्थ थीं। इसके साथ अक्सर सेवा काम नहीं करती थी।

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

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

हम हमेशा इस स्क्रिप्ट का आँख बंद करके अनुसरण नहीं करते हैं। आज हमारे पास काला और सफेद नहीं है: या तो सब कुछ लुआ में है, या सब कुछ गो में है। हम पहले से ही समझते हैं कि हम उन्हें कैसे जोड़ सकते हैं ताकि हमें बाद में प्रवासन समस्याओं का सामना न करना पड़े।

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

सबसे महत्वपूर्ण सेवाओं में से एक उपयोगकर्ता प्रोफ़ाइल है। यानी, सभी वाइल्डबेरी उपयोगकर्ता टारनटूल में संग्रहीत हैं, और उनमें से लगभग 50 मिलियन हैं। उपयोगकर्ता आईडी द्वारा साझा किया गया एक सिस्टम, गो सेवाओं से जुड़े कई डीसी में वितरित किया गया है।
आरपीएस के अनुसार, प्रमोटर एक समय अग्रणी था, जो 6 हजार अनुरोधों तक पहुंच गया था। एक समय हमारे पास 50-60 प्रतियां थीं। अब आरपीएस में अग्रणी उपयोगकर्ता प्रोफाइल हैं, लगभग 12 हजार। यह सेवा उपयोगकर्ता आईडी की श्रेणियों द्वारा विभाजित कस्टम शार्डिंग का उपयोग करती है। सेवा 20 से अधिक मशीनों को सेवा प्रदान करती है, लेकिन यह बहुत अधिक हैं; हम आवंटित संसाधनों को कम करने की योजना बना रहे हैं, क्योंकि 4-5 मशीनों की क्षमता इसके लिए पर्याप्त है।

सत्र सेवा vshard और Cartridge पर हमारी पहली सेवा है। vshard को सेट करने और कार्ट्रिज को अपडेट करने के लिए हमें कुछ प्रयास की आवश्यकता थी, लेकिन अंत में सब कुछ ठीक हो गया।

वेबसाइट और मोबाइल एप्लिकेशन पर विभिन्न बैनर प्रदर्शित करने की सेवा टारनटूल पर सीधे जारी होने वाली पहली सेवाओं में से एक थी। यह सेवा इस तथ्य के लिए उल्लेखनीय है कि यह 6-7 साल पुरानी है, यह अभी भी चालू है और इसे कभी भी रीबूट नहीं किया गया है। मास्टर-मास्टर प्रतिकृति का प्रयोग किया गया। कभी कुछ नहीं टूटा.

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

प्रतीक्षा सूची, ग्राहक सदस्यता, वर्तमान में फैशनेबल कहानियाँ और स्थगित सामान की सेवाएँ भी टारनटूल के साथ काम करती हैं। मेमोरी में अंतिम सेवा लगभग 120 जीबी लेती है। यह उपरोक्त में से सबसे व्यापक सेवा है।

निष्कर्ष

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

विषय पर और क्या पढ़ना है

• टारनटूल का उपयोग करके स्क्रैच से एक उच्च-लोड एप्लिकेशन बनाना habr.com/ru/company/mailru/blog/510440
• टारनटूल कार्ट्रिज में विश्वसनीय नेता की पसंद habr.com/ru/company/mailru/blog/513912
• उत्पाद के बारे में समाचार के साथ टेलीग्राम चैनल टारनटूल t.me/tarantool_news
• सामुदायिक चैट में टारनटूल पर चर्चा करें t.me/tarantoolru

स्रोत: www.habr.com