🥇टारनटूल कार्ट्रिज: लुआ बैकएंड को तीन पंक्तियों में विभाजित करना

Mail.ru ग्रुप में हमारे पास टारनटूल है - यह लुआ में एक एप्लिकेशन सर्वर है, जो डेटाबेस के रूप में भी काम करता है (या इसके विपरीत?)। यह तेज़ और अच्छा है, लेकिन एक सर्वर की क्षमताएं अभी भी असीमित नहीं हैं। ऊर्ध्वाधर स्केलिंग भी रामबाण नहीं है, इसलिए टारनटूल के पास क्षैतिज स्केलिंग के लिए उपकरण हैं - वीएसहार्ड मॉड्यूल [1]. यह आपको कई सर्वरों पर डेटा साझा करने की अनुमति देता है, लेकिन इसे सेट करने और व्यावसायिक तर्क संलग्न करने के लिए आपको इसके साथ छेड़छाड़ करनी होगी।

अच्छी खबर: हमने कुछ बड़े शॉट्स एकत्र किए हैं (जैसे [2], [3]) और एक और ढांचा तैयार किया जो इस समस्या के समाधान को काफी सरल बना देगा।

टारनटूल कार्ट्रिज जटिल वितरित सिस्टम विकसित करने के लिए एक नया ढांचा है। यह आपको बुनियादी ढांचे की समस्याओं को हल करने के बजाय व्यावसायिक तर्क लिखने पर ध्यान केंद्रित करने की अनुमति देता है। कट के नीचे मैं आपको बताऊंगा कि यह ढांचा कैसे काम करता है और इसका उपयोग करके वितरित सेवाओं को कैसे लिखा जाता है।

वास्तव में समस्या क्या है?

हमारे पास टारेंटयुला है, हमारे पास वशार्ड है - आपको और क्या चाहिए?

सबसे पहले, यह सुविधा की बात है. vshard कॉन्फ़िगरेशन को Lua तालिकाओं के माध्यम से कॉन्फ़िगर किया गया है। एकाधिक टारनटूल प्रक्रियाओं की एक वितरित प्रणाली के सही ढंग से काम करने के लिए, कॉन्फ़िगरेशन हर जगह समान होना चाहिए। कोई भी इसे मैन्युअल रूप से नहीं करना चाहता. इसलिए, सभी प्रकार की स्क्रिप्ट, अन्सिबल और परिनियोजन सिस्टम का उपयोग किया जाता है।

कार्ट्रिज स्वयं vshard कॉन्फ़िगरेशन का प्रबंधन करता है, यह इसके आधार पर करता है स्वयं का वितरित विन्यास. यह अनिवार्य रूप से एक साधारण YAML फ़ाइल है, जिसकी एक प्रति प्रत्येक टारनटूल इंस्टेंस में संग्रहीत होती है। सरलीकरण यह है कि फ्रेमवर्क स्वयं अपने कॉन्फ़िगरेशन की निगरानी करता है और यह सुनिश्चित करता है कि यह हर जगह समान है।

दूसरे, यह फिर से सुविधा का मामला है। vshard कॉन्फ़िगरेशन का व्यावसायिक तर्क के विकास से कोई लेना-देना नहीं है और यह केवल प्रोग्रामर को उसके काम से विचलित करता है। जब हम किसी परियोजना की वास्तुकला पर चर्चा करते हैं, तो हम अक्सर व्यक्तिगत घटकों और उनकी बातचीत के बारे में बात करते हैं। किसी क्लस्टर को 3 डेटा केंद्रों तक ले जाने के बारे में सोचना जल्दबाजी होगी।

हमने इन समस्याओं को बार-बार हल किया, और कुछ बिंदु पर हम एक ऐसा दृष्टिकोण विकसित करने में कामयाब रहे जिसने एप्लिकेशन के साथ उसके पूरे जीवन चक्र में काम करना आसान बना दिया: निर्माण, विकास, परीक्षण, सीआई/सीडी, रखरखाव।

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

टारनटूल कार्ट्रिज की मुख्य विशेषताएं:

स्वचालित क्लस्टर ऑर्केस्ट्रेशन;
नई भूमिकाओं का उपयोग करके एप्लिकेशन की कार्यक्षमता का विस्तार करना;
विकास और परिनियोजन के लिए एप्लिकेशन टेम्पलेट;
अंतर्निर्मित स्वचालित शार्डिंग;
लुएटेस्ट परीक्षण ढांचे के साथ एकीकरण;
वेबयूआई और एपीआई का उपयोग करके क्लस्टर प्रबंधन;
पैकेजिंग और परिनियोजन उपकरण।

नमस्ते दुनिया!

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

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

ये दो कमांड कमांड लाइन उपयोगिताओं को स्थापित करेंगे और आपको टेम्पलेट से अपना पहला एप्लिकेशन बनाने की अनुमति देंगे:

$ cartridge create --name myapp

और यही हमें मिलता है:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

यह रेडीमेड "हैलो, वर्ल्ड!" के साथ एक गिट रिपॉजिटरी है। आवेदन पत्र। आइए पहले निर्भरताएं (फ्रेमवर्क सहित) स्थापित करके इसे तुरंत चलाने का प्रयास करें:

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

तो, हमारे पास भविष्य के शार्ड एप्लिकेशन के लिए एक नोड चल रहा है। एक जिज्ञासु आम आदमी तुरंत वेब इंटरफ़ेस खोल सकता है, माउस से एक नोड के क्लस्टर को कॉन्फ़िगर कर सकता है और परिणाम का आनंद ले सकता है, लेकिन अभी आनंद लेना जल्दबाजी होगी। अब तक, एप्लिकेशन कुछ भी उपयोगी नहीं कर सका है, इसलिए मैं आपको बाद में तैनाती के बारे में बताऊंगा, लेकिन अब कोड लिखने का समय आ गया है।

एप्लीकेशन का विकास

ज़रा कल्पना करें, हम एक प्रोजेक्ट डिज़ाइन कर रहे हैं जिसमें डेटा प्राप्त करना होगा, उसे सहेजना होगा और दिन में एक बार रिपोर्ट बनानी होगी।

हम एक आरेख बनाना शुरू करते हैं और उस पर तीन घटक रखते हैं: गेटवे, स्टोरेज और शेड्यूलर। हम आर्किटेक्चर पर आगे काम कर रहे हैं।' चूँकि हम vshard को स्टोरेज के रूप में उपयोग करते हैं, हम स्कीम में vshard-राउटर और vshard-स्टोरेज जोड़ते हैं। न तो गेटवे और न ही शेड्यूलर सीधे स्टोरेज तक पहुंच पाएगा; राउटर इसी के लिए है, इसी के लिए इसे बनाया गया था।

यह आरेख अभी भी सटीक रूप से यह नहीं दर्शाता है कि हम परियोजना में क्या निर्माण करेंगे क्योंकि घटक अमूर्त दिखते हैं। हमें अभी भी यह देखने की ज़रूरत है कि इसे वास्तविक टारनटूल पर कैसे प्रक्षेपित किया जाएगा - आइए अपने घटकों को प्रक्रिया के अनुसार समूहित करें।

vshard-राउटर और गेटवे को अलग-अलग उदाहरणों पर रखने का कोई मतलब नहीं है। यदि यह पहले से ही राउटर की जिम्मेदारी है तो हमें एक बार फिर नेटवर्क सर्फ करने की आवश्यकता क्यों है? उन्हें उसी प्रक्रिया के अंतर्गत चलाया जाना चाहिए। अर्थात्, गेटवे और vshard.router.cfg दोनों को एक प्रक्रिया में प्रारंभ किया जाता है, और उन्हें स्थानीय रूप से इंटरैक्ट करने दिया जाता है।

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

और जब स्टेजिंग या उत्पादन में तैनाती की बात आती है, तो हम हार्डवेयर क्षमताओं के आधार पर प्रत्येक टारनटूल प्रक्रिया को भूमिकाओं का अपना सेट सौंपेंगे:

टोपोलॉजी प्रबंधन

कौन सी भूमिकाएँ कहाँ चल रही हैं, इसकी जानकारी कहीं न कहीं संग्रहित की जानी चाहिए। और यह "कहीं" वितरित कॉन्फ़िगरेशन है, जिसका मैंने पहले ही ऊपर उल्लेख किया है। इसकी सबसे महत्वपूर्ण बात क्लस्टर टोपोलॉजी है। यहां 3 टारनटूल प्रक्रियाओं के 5 प्रतिकृति समूह हैं:

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

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

भूमिकाओं का जीवन

ऐसी वास्तुकला में एक अमूर्त भूमिका के अस्तित्व के लिए, ढांचे को उन्हें किसी तरह प्रबंधित करना होगा। स्वाभाविक रूप से, टारनटूल प्रक्रिया को पुनरारंभ किए बिना नियंत्रण होता है। भूमिकाओं को प्रबंधित करने के लिए 4 कॉलबैक हैं। वितरित कॉन्फ़िगरेशन में जो लिखा गया है उसके आधार पर कार्ट्रिज स्वयं उन्हें कॉल करेगा, जिससे कॉन्फ़िगरेशन को विशिष्ट भूमिकाओं पर लागू किया जा सकेगा।

function init()
function validate_config()
function apply_config()
function stop()

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

एक कार्य init पर्याप्त नहीं हो सकता. कार्ट्रिज भूमिकाओं को टोपोलॉजी को संग्रहीत करने के लिए उपयोग किए जाने वाले वितरित कॉन्फ़िगरेशन का लाभ उठाने की अनुमति देता है। हम उसी कॉन्फ़िगरेशन में एक नया अनुभाग घोषित कर सकते हैं और उसमें व्यावसायिक कॉन्फ़िगरेशन का एक टुकड़ा संग्रहीत कर सकते हैं। मेरे उदाहरण में, यह शेड्यूलर भूमिका के लिए डेटा स्कीमा या शेड्यूल सेटिंग्स हो सकती है।

क्लस्टर कॉल validate_config и apply_config हर बार वितरित कॉन्फ़िगरेशन बदलता है। जब कोई कॉन्फ़िगरेशन दो-चरण कमिट द्वारा लागू किया जाता है, तो क्लस्टर जाँचता है कि प्रत्येक भूमिका इस नए कॉन्फ़िगरेशन को स्वीकार करने के लिए तैयार है और, यदि आवश्यक हो, तो उपयोगकर्ता को एक त्रुटि की रिपोर्ट करता है। जब हर कोई सहमत होता है कि कॉन्फ़िगरेशन सामान्य है, तो apply_config.

भूमिकाओं की भी एक विधि होती है stop, जो भूमिका के आउटपुट को साफ़ करने के लिए आवश्यक है। यदि हम कहते हैं कि इस सर्वर पर अब शेड्यूलर की आवश्यकता नहीं है, तो यह उन फाइबर को रोक सकता है जिनसे इसकी शुरुआत हुई थी init.

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

एक अन्य महत्वपूर्ण बिंदु दोष सहनशीलता सुनिश्चित करना है। कार्ट्रिज स्वास्थ्य की निगरानी के लिए SWIM प्रोटोकॉल का उपयोग करता है [4]. संक्षेप में, प्रक्रियाएँ यूडीपी पर एक-दूसरे के साथ "अफवाहों" का आदान-प्रदान करती हैं - प्रत्येक प्रक्रिया अपने पड़ोसियों को नवीनतम समाचार बताती है, और वे प्रतिक्रिया देते हैं। यदि अचानक उत्तर नहीं आता है, तो टारनटूल को संदेह होने लगता है कि कुछ गड़बड़ है, और थोड़ी देर बाद वह मृत्यु का पाठ करता है और यह समाचार आसपास के सभी लोगों को बताना शुरू कर देता है।

इस प्रोटोकॉल के आधार पर, कार्ट्रिज स्वचालित विफलता प्रसंस्करण का आयोजन करता है। प्रत्येक प्रक्रिया अपने वातावरण की निगरानी करती है, और यदि नेता अचानक प्रतिक्रिया देना बंद कर देता है, तो प्रतिकृति उसकी भूमिका ले सकती है, और कार्ट्रिज चल रही भूमिकाओं को तदनुसार कॉन्फ़िगर करता है।

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

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

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

परिनियोजन उपकरण

मैंने यह दिखाने का वादा किया कि कार्ट्रिज अनुप्रयोगों को तैनात करने में कैसे मदद करता है। दूसरों के जीवन को आसान बनाने के लिए, फ्रेमवर्क RPM पैकेज पैकेज करता है:

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

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

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

यहां एक दिलचस्प बारीकियां है. केवल बाइनरी प्रोटोकॉल पोर्ट निर्दिष्ट करने के बजाय, हम होस्टनाम सहित प्रक्रिया का संपूर्ण सार्वजनिक पता निर्दिष्ट करते हैं। यह आवश्यक है ताकि क्लस्टर नोड्स को पता चले कि एक दूसरे से कैसे जुड़ना है। विज्ञापन_यूरी पते के रूप में 0.0.0.0 का उपयोग करना एक बुरा विचार है; यह एक बाहरी आईपी पता होना चाहिए, सॉकेट बाइंड नहीं। इसके बिना, कुछ भी काम नहीं करेगा, इसलिए कार्ट्रिज आपको गलत विज्ञापन_यूरी के साथ एक नोड लॉन्च नहीं करने देगा।

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

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

कॉन्फ़िगरेशन में, हमने HTTP पोर्ट निर्दिष्ट किया है जिस पर कार्ट्रिज वेब इंटरफ़ेस परोसता है - 8080। आइए इस पर जाएं और एक नज़र डालें:

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

आइए अपने पसंदीदा पेय का एक गिलास डालें और लंबे कार्य सप्ताह के बाद आराम करें। एप्लिकेशन का उपयोग किया जा सकता है.