🥇तरनटूल काडतूस: लुआ बॅकएंडला तीन ओळींमध्ये शार्डिंग

Mail.ru ग्रुपमध्ये आमच्याकडे टारंटूल आहे - हे लुआ मधील ॲप्लिकेशन सर्व्हर आहे, जे डेटाबेस म्हणून दुप्पट होते (किंवा उलट?). हे वेगवान आणि मस्त आहे, परंतु एका सर्व्हरची क्षमता अद्याप अमर्यादित नाही. व्हर्टिकल स्केलिंग देखील रामबाण उपाय नाही, म्हणून टारंटूलमध्ये क्षैतिज स्केलिंगसाठी साधने आहेत - vshard मॉड्यूल [1]. हे तुम्हाला अनेक सर्व्हरवर डेटा शार्ड करण्यास अनुमती देते, परंतु ते सेट करण्यासाठी आणि व्यवसाय तर्क जोडण्यासाठी तुम्हाला त्यात टिंकर करावे लागेल.

चांगली बातमी: आम्ही काही मोठे शॉट्स गोळा केले आहेत (उदा [2], [3]) आणि आणखी एक फ्रेमवर्क तयार केले जे या समस्येचे निराकरण लक्षणीयरीत्या सुलभ करेल.

टारनटूल काडतूस जटिल वितरण प्रणाली विकसित करण्यासाठी एक नवीन फ्रेमवर्क आहे. हे तुम्हाला पायाभूत सुविधांच्या समस्या सोडवण्याऐवजी व्यवसाय तर्कशास्त्र लिहिण्यावर लक्ष केंद्रित करण्यास अनुमती देते. कट खाली मी तुम्हाला हे फ्रेमवर्क कसे कार्य करते आणि ते वापरून वितरित सेवा कसे लिहायचे ते सांगेन.

नेमकी समस्या काय आहे?

आमच्याकडे टारंटुला आहे, आमच्याकडे व्हशार्ड आहे - तुम्हाला आणखी काय हवे आहे?

प्रथम, ही सोयीची बाब आहे. vshard कॉन्फिगरेशन Lua टेबलद्वारे कॉन्फिगर केले आहे. एकाधिक टॅरनटूल प्रक्रियांची वितरित प्रणाली योग्यरित्या कार्य करण्यासाठी, कॉन्फिगरेशन सर्वत्र समान असणे आवश्यक आहे. कोणीही हे व्यक्तिचलितपणे करू इच्छित नाही. म्हणून, सर्व प्रकारच्या स्क्रिप्ट, उत्तरदायी आणि उपयोजन प्रणाली वापरल्या जातात.

कार्ट्रिज स्वतः vshard कॉन्फिगरेशन व्यवस्थापित करते, ते त्याच्या आधारावर हे करते स्वतःचे वितरित कॉन्फिगरेशन. ही मूलत: एक साधी YAML फाईल आहे, ज्याची प्रत प्रत्येक Tarantool उदाहरणामध्ये संग्रहित केली जाते. सरलीकरण हे आहे की फ्रेमवर्क स्वतःच त्याच्या कॉन्फिगरेशनचे निरीक्षण करते आणि ते सर्वत्र समान असल्याची खात्री करते.

दुसरे म्हणजे, ही पुन्हा सोयीची बाब आहे. vshard कॉन्फिगरेशनचा व्यवसाय तर्कशास्त्राच्या विकासाशी काहीही संबंध नाही आणि केवळ प्रोग्रामरला त्याच्या कामापासून विचलित करते. जेव्हा आपण एखाद्या प्रकल्पाच्या आर्किटेक्चरवर चर्चा करतो तेव्हा आपण बहुतेकदा वैयक्तिक घटक आणि त्यांच्या परस्परसंवादाबद्दल बोलतो. 3 डेटा सेंटरवर क्लस्टर आणण्याचा विचार करणे खूप लवकर आहे.

आम्ही या समस्यांचे पुन:पुन्हा निराकरण केले आणि काही क्षणी आम्ही एक दृष्टीकोन विकसित करण्यात व्यवस्थापित केले ज्यामुळे अनुप्रयोगासह संपूर्ण जीवन चक्रात कार्य करणे सोपे होते: निर्मिती, विकास, चाचणी, CI/CD, देखभाल.

कार्ट्रिज प्रत्येक टारनटूल प्रक्रियेसाठी भूमिकेची संकल्पना सादर करते. भूमिका ही एक संकल्पना आहे जी विकसकाला कोड लिहिण्यावर लक्ष केंद्रित करण्यास अनुमती देते. प्रोजेक्टमध्ये उपलब्ध असलेल्या सर्व भूमिका एका टारंटूल उदाहरणावर चालवल्या जाऊ शकतात आणि हे चाचण्यांसाठी पुरेसे असेल.

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

स्वयंचलित क्लस्टर ऑर्केस्ट्रेशन;
नवीन भूमिका वापरून अनुप्रयोगाची कार्यक्षमता वाढवणे;
विकास आणि उपयोजनासाठी अनुप्रयोग टेम्पलेट;
अंगभूत स्वयंचलित शार्डिंग;
Luatest चाचणी फ्रेमवर्कसह एकत्रीकरण;
WebUI आणि API वापरून क्लस्टर व्यवस्थापन;
पॅकेजिंग आणि उपयोजन साधने.

नमस्कार, जग!

मी फ्रेमवर्क स्वतः दर्शवण्यासाठी प्रतीक्षा करू शकत नाही, म्हणून आम्ही आर्किटेक्चरची कथा नंतरसाठी सोडू आणि काहीतरी सोप्या गोष्टीसह प्रारंभ करू. जर आपण असे गृहीत धरले की टारनटूल स्वतः आधीच स्थापित केले आहे, तर जे काही बाकी आहे ते करणे बाकी आहे

$ 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-storage जोडतो. गेटवे किंवा शेड्युलर यापैकी कोणीही थेट स्टोरेजमध्ये प्रवेश करणार नाही; राउटर त्यासाठीच आहे, त्यासाठीच ते तयार केले आहे.

हा आकृती अद्यापही आम्ही प्रकल्पात काय तयार करणार आहोत याचे नेमके प्रतिनिधित्व करत नाही कारण घटक अमूर्त दिसत आहेत. खऱ्या टॅरनटूलवर हे कसे प्रक्षेपित केले जाईल हे आम्हाला अद्याप पाहण्याची आवश्यकता आहे - चला प्रक्रियेनुसार आमचे घटक गटबद्ध करूया.

vshard-राउटर आणि गेटवे वेगळ्या उदाहरणांवर ठेवण्यात फारसा अर्थ नाही. जर राउटरची ही जबाबदारी आधीच असेल तर आम्हाला पुन्हा एकदा नेटवर्क सर्फ करण्याची आवश्यकता का आहे? ते त्याच प्रक्रियेत चालवले पाहिजेत. म्हणजेच, गेटवे आणि vshard.router.cfg दोन्ही एकाच प्रक्रियेत सुरू केले जातात आणि त्यांना स्थानिक पातळीवर संवाद साधू द्या.

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

आणि जेव्हा स्टेजिंग किंवा उत्पादनासाठी तैनातीचा प्रश्न येतो, तेव्हा आम्ही हार्डवेअर क्षमतांवर अवलंबून प्रत्येक टॅरनटूल प्रक्रियेला त्याच्या स्वतःच्या भूमिकांचा संच नियुक्त करू:

टोपोलॉजी व्यवस्थापन

कोणत्या भूमिका कुठे चालू आहेत याची माहिती कुठेतरी संग्रहित करणे आवश्यक आहे. आणि हे "कुठेतरी" वितरित कॉन्फिगरेशन आहे, जे मी आधीच वर नमूद केले आहे. त्यातील सर्वात महत्त्वाची गोष्ट म्हणजे क्लस्टर टोपोलॉजी. येथे 3 टारंटूल प्रक्रियेचे 5 प्रतिकृती गट आहेत:

आम्ही डेटा गमावू इच्छित नाही, म्हणून आम्ही चालू असलेल्या प्रक्रियांबद्दल माहिती काळजीपूर्वक हाताळतो. कार्ट्रिज दोन-फेज कमिट वापरून कॉन्फिगरेशनचा मागोवा ठेवते. एकदा आम्हाला कॉन्फिगरेशन अपडेट करायचे आहे, ते प्रथम तपासते की सर्व उदाहरणे उपलब्ध आहेत आणि नवीन कॉन्फिगरेशन स्वीकारण्यास तयार आहेत. यानंतर, दुसरा टप्पा कॉन्फिगरेशन लागू करतो. अशाप्रकारे, जरी एक प्रत तात्पुरती अनुपलब्ध झाली तरी काहीही वाईट होणार नाही. कॉन्फिगरेशन फक्त लागू केले जाणार नाही आणि तुम्हाला आगाऊ त्रुटी दिसेल.

तसेच टोपोलॉजी विभागात, प्रत्येक प्रतिकृती गटाचा नेता म्हणून महत्त्वपूर्ण पॅरामीटर सूचित केले आहे. सहसा ही प्रत असते जी रेकॉर्ड केली जाते. बाकीचे बहुतेक वेळा केवळ वाचनीय असतात, जरी अपवाद असू शकतात. कधीकधी धाडसी विकसक संघर्षांना घाबरत नाहीत आणि समांतरपणे अनेक प्रतिकृतींवर डेटा लिहू शकतात, परंतु काही ऑपरेशन्स आहेत जे काहीही असले तरी, दोनदा केले जाऊ नयेत. यासाठी एका नेत्याची चिन्हे आहेत.

भूमिकांचे जीवन

अशा आर्किटेक्चरमध्ये अमूर्त भूमिका अस्तित्त्वात येण्यासाठी, फ्रेमवर्कने त्यांना कसे तरी व्यवस्थापित केले पाहिजे. स्वाभाविकच, टॅरनटूल प्रक्रिया पुन्हा सुरू केल्याशिवाय नियंत्रण होते. भूमिका व्यवस्थापित करण्यासाठी 4 कॉलबॅक आहेत. वितरीत कॉन्फिगरेशनमध्ये काय लिहिले आहे यावर अवलंबून कार्ट्रिज स्वतःच त्यांना कॉल करेल, त्याद्वारे विशिष्ट भूमिकांसाठी कॉन्फिगरेशन लागू करेल.

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

प्रत्येक भूमिकेचे एक कार्य असते init. जेव्हा भूमिका सक्षम केली जाते किंवा टॅरनटूल रीस्टार्ट केले जाते तेव्हा ते एकदा कॉल केले जाते. तेथे सोयीस्कर आहे, उदाहरणार्थ, box.space.create सुरू करणे, किंवा शेड्युलर काही पार्श्वभूमी फायबर लाँच करू शकतो जे विशिष्ट वेळेच्या अंतराने कार्य करेल.

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

क्लस्टर कॉल validate_config и apply_config प्रत्येक वेळी वितरित कॉन्फिगरेशन बदलते. जेव्हा कॉन्फिगरेशन दोन-फेज कमिटद्वारे लागू केले जाते, तेव्हा क्लस्टर तपासते की प्रत्येक भूमिका हे नवीन कॉन्फिगरेशन स्वीकारण्यास तयार आहे आणि आवश्यक असल्यास, वापरकर्त्यास त्रुटीची तक्रार करते. जेव्हा प्रत्येकजण सहमत असेल की कॉन्फिगरेशन सामान्य आहे, तेव्हा apply_config.

भूमिकांनाही एक पद्धत असते stop, जे रोलचे आउटपुट साफ करण्यासाठी आवश्यक आहे. या सर्व्हरवर शेड्युलरची यापुढे आवश्यकता नाही असे आम्ही म्हणत असल्यास, ते ज्या फायबरपासून सुरू झाले ते थांबवू शकते init.

भूमिका एकमेकांशी संवाद साधू शकतात. आम्हाला लुआमध्ये फंक्शन कॉल लिहिण्याची सवय आहे, परंतु असे होऊ शकते की दिलेल्या प्रक्रियेमध्ये आम्हाला आवश्यक भूमिका नसते. नेटवर्कवरील कॉल्स सुलभ करण्यासाठी, आम्ही rpc (रिमोट प्रक्रिया कॉल) सहाय्यक मॉड्यूल वापरतो, जे टारनटूलमध्ये तयार केलेल्या मानक नेटबॉक्सच्या आधारावर तयार केले जाते. उदाहरणार्थ, तुमचा गेटवे एक दिवस थांबण्याऐवजी शेड्युलरला थेट काम करण्यास सांगू इच्छित असल्यास हे उपयुक्त ठरू शकते.

आणखी एक महत्त्वाचा मुद्दा म्हणजे दोष सहिष्णुता सुनिश्चित करणे. आरोग्यावर लक्ष ठेवण्यासाठी कार्ट्रिज SWIM प्रोटोकॉल वापरते [4]. थोडक्यात, प्रक्रिया UDP वर एकमेकांशी “अफवा” ची देवाणघेवाण करतात—प्रत्येक प्रक्रिया आपल्या शेजाऱ्यांना ताज्या बातम्या सांगते आणि ते प्रतिसाद देतात. जर अचानक उत्तर आले नाही, तर टारंटूलला काहीतरी गडबड असल्याची शंका येऊ लागते आणि थोड्या वेळाने तो मृत्यूची आठवण करतो आणि आजूबाजूच्या सर्वांना ही बातमी सांगू लागतो.

या प्रोटोकॉलवर आधारित, कार्ट्रिज स्वयंचलित अपयश प्रक्रिया आयोजित करते. प्रत्येक प्रक्रिया त्याच्या वातावरणाचे निरीक्षण करते, आणि जर नेता अचानक प्रतिसाद देणे थांबवले, तर प्रतिकृती त्याची भूमिका घेऊ शकते आणि कार्ट्रिज त्यानुसार चालू भूमिका कॉन्फिगर करते.

आपण येथे सावधगिरी बाळगणे आवश्यक आहे, कारण वारंवार मागे-पुढे स्विच केल्याने प्रतिकृती दरम्यान डेटा संघर्ष होऊ शकतो. अर्थात, तुम्ही यादृच्छिकपणे स्वयंचलित फेलओव्हर सक्षम करू नये. काय घडत आहे हे आपण स्पष्टपणे समजून घेतले पाहिजे आणि नेता पुनर्संचयित केल्यानंतर आणि मुकुट त्याच्याकडे परत केल्यावर प्रतिकृती खंडित होणार नाही याची खात्री बाळगली पाहिजे.

या सर्वांवरून, तुम्हाला अशी भावना येऊ शकते की भूमिका मायक्रोसर्व्हिसेससारख्याच आहेत. एका अर्थाने, ते फक्त तेच आहेत, फक्त टॅरनटूल प्रक्रियेतील मॉड्यूल्स म्हणून. पण त्यातही अनेक मूलभूत फरक आहेत. प्रथम, सर्व प्रकल्प भूमिका समान कोड बेसमध्ये राहणे आवश्यक आहे. आणि सर्व टॅरनटूल प्रक्रिया एकाच कोड बेसवरून लाँच केल्या पाहिजेत, जेणेकरुन जेव्हा आम्ही शेड्यूलर सुरू करण्याचा प्रयत्न करतो तेव्हा त्यासारखे कोणतेही आश्चर्य नाही, परंतु ते अस्तित्वात नाही. तसेच, आपण कोड आवृत्त्यांमधील फरकांना अनुमती देऊ नये, कारण अशा परिस्थितीत सिस्टमच्या वर्तनाचा अंदाज लावणे आणि डीबग करणे खूप कठीण आहे.

डॉकरच्या विपरीत, आम्ही फक्त भूमिका "प्रतिमा" घेऊ शकत नाही, ती दुसर्या मशीनवर नेऊ आणि तेथे चालवू शकत नाही. आमच्या भूमिका डॉकर कंटेनरसारख्या वेगळ्या नाहीत. तसेच, आपण एका प्रसंगावर दोन समान भूमिका करू शकत नाही. भूमिका एकतर अस्तित्वात आहे किंवा ती नाही; आणि तिसरे म्हणजे, संपूर्ण प्रतिकृती गटामध्ये भूमिका समान असणे आवश्यक आहे, कारण अन्यथा ते हास्यास्पद असेल - डेटा समान आहे, परंतु कॉन्फिगरेशन भिन्न आहे.

उपयोजन साधने

मी कार्ट्रिज अनुप्रयोग तैनात करण्यास कशी मदत करते हे दर्शविण्याचे वचन दिले. इतरांसाठी जीवन सोपे करण्यासाठी, फ्रेमवर्क पॅकेजेस RPM पॅकेजेस:

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

स्थापित पॅकेजमध्ये आपल्याला आवश्यक असलेली जवळजवळ प्रत्येक गोष्ट समाविष्ट आहे: अनुप्रयोग आणि स्थापित अवलंबित्व दोन्ही. RPM पॅकेजचे अवलंबित्व म्हणून टारंटूल सर्व्हरवर देखील येईल आणि आमची सेवा सुरू होण्यास तयार आहे. हे systemd द्वारे केले जाते, परंतु प्रथम तुम्हाला थोडे कॉन्फिगरेशन लिहावे लागेल. किमान, प्रत्येक प्रक्रियेचा URI निर्दिष्ट करा. उदाहरणार्थ तीन पुरेसे आहेत.

$ 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

येथे एक मनोरंजक सूक्ष्मता आहे. फक्त बायनरी प्रोटोकॉल पोर्ट निर्दिष्ट करण्याऐवजी, आम्ही होस्टनावासह प्रक्रियेचा संपूर्ण सार्वजनिक पत्ता निर्दिष्ट करतो. हे आवश्यक आहे जेणेकरून क्लस्टर नोड्स एकमेकांशी कसे जोडले जावे हे कळेल. advertise_uri पत्ता म्हणून 0.0.0.0 वापरणे ही एक वाईट कल्पना आहे, तो एक बाह्य IP पत्ता असावा, सॉकेट बाइंड नाही. त्याशिवाय, काहीही कार्य करणार नाही, म्हणून कार्ट्रिज तुम्हाला चुकीच्या जाहिरातीसह नोड लॉन्च करू देणार नाही.

आता कॉन्फिगरेशन तयार आहे, तुम्ही प्रक्रिया सुरू करू शकता. एक नियमित सिस्टीम युनिट एकापेक्षा जास्त प्रक्रिया सुरू करण्यास परवानगी देत नाही, कार्ट्रिजवरील अनुप्रयोग तथाकथित द्वारे स्थापित केले जातात. इन्स्टंटिएटेड युनिट्स जे याप्रमाणे कार्य करतात:

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

कॉन्फिगरेशनमध्ये, आम्ही HTTP पोर्ट निर्दिष्ट केला आहे ज्यावर कार्ट्रिज वेब इंटरफेस सेवा देतो - 8080. चला त्यावर जाऊ आणि एक नजर टाकूया:

आम्ही पाहतो की प्रक्रिया चालू असल्या तरी त्या अद्याप कॉन्फिगर केलेल्या नाहीत. काडतूस अद्याप माहित नाही की कोणाची प्रतिकृती कोणाशी करावी आणि तो स्वतः निर्णय घेऊ शकत नाही, म्हणून तो आपल्या कृतीची वाट पाहत आहे. परंतु आमच्याकडे जास्त पर्याय नाही: नवीन क्लस्टरचे आयुष्य पहिल्या नोडच्या कॉन्फिगरेशनपासून सुरू होते. मग आम्ही इतरांना क्लस्टरमध्ये जोडू, त्यांना भूमिका नियुक्त करू आणि या टप्प्यावर तैनाती यशस्वीरित्या पूर्ण केली जाऊ शकते.

चला आपल्या आवडत्या पेयाचा ग्लास ओतूया आणि दीर्घ कामाच्या आठवड्यानंतर आराम करूया. अनुप्रयोग वापरला जाऊ शकतो.