काळजी करणे कसे थांबवायचे आणि मोनोलिथशिवाय जगणे कसे सुरू करावे

आपल्या सर्वांना कथा आवडतात. आम्हाला आगीभोवती बसून आमच्या भूतकाळातील विजय, लढाया किंवा आमच्या कामाच्या अनुभवाबद्दल बोलायला आवडते.

आजचा दिवस असाच आहे. आणि जरी तुम्ही आत्ता आगीत नसले तरी आमच्याकडे तुमच्यासाठी एक कथा आहे. आम्ही टॅरनटूलवर स्टोरेजसह काम कसे सुरू केले याची कथा.

एके काळी, आमच्या कंपनीकडे सर्वांसाठी दोन “मोनोलिथ” आणि एक “सीलिंग” होती, ज्यापर्यंत हे मोनोलिथ हळूहळू पण निश्चितपणे जवळ येत होते, ज्यामुळे आमच्या कंपनीचे उड्डाण, आमचा विकास मर्यादित होता. आणि एक स्पष्ट समज होती: एके दिवशी आपण या कमाल मर्यादेला जोरदार धडक देऊ.

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

आज, CI/CD, K8S, इत्यादी स्वरूपात बदल करण्यासाठी बरीच साधने आणि साधने आहेत. "मोनोलिथिक" काळात, आम्हाला इतक्या परदेशी शब्दांची आवश्यकता नव्हती. डेटाबेसमधील "स्टोरेज" दुरुस्त करणे पुरेसे होते.

पण वेळ पुढे सरकला, आणि विनंत्यांची संख्या त्यासोबत पुढे सरकली, काहीवेळा आमच्या क्षमतेच्या पलीकडे आरपीएस शूट केले. सीआयएस देशांच्या बाजारपेठेत प्रवेश केल्याने, पहिल्या मोनोलिथच्या डेटाबेस प्रोसेसरवरील भार 90% पेक्षा कमी झाला नाही आणि RPS 2400 च्या स्तरावर राहिला. आणि हे फक्त लहान निवडक नव्हते, तर मोठ्या प्रश्नांसह मोठ्या IO च्या पार्श्वभूमीवर जवळजवळ अर्ध्या डेटासाठी चालू शकणारे धनादेश आणि जॉइन.

जेव्हा संपूर्ण ब्लॅक फ्रायडे विक्री दृश्यावर दिसू लागली - आणि वाइल्डबेरी रशियामध्ये त्यांना ठेवणारे पहिले होते - परिस्थिती पूर्णपणे दुःखी झाली. तथापि, अशा दिवसांवर भार तीन वेळा वाढतो.
अरे, या "अखंड काळ"! मला खात्री आहे की तुम्हीही असेच काहीतरी अनुभवले असेल आणि हे तुमच्या बाबतीत कसे घडू शकते हे तुम्हाला अजूनही समजू शकत नाही.

आपण काय करू शकता - फॅशन तंत्रज्ञानामध्ये अंतर्भूत आहे. सुमारे 5 वर्षांपूर्वी, आम्हाला .NET आणि MS SQL सर्व्हरवरील विद्यमान साइटच्या रूपात यापैकी एका मोडचा पुनर्विचार करावा लागला, ज्याने साइटचे सर्व तर्क काळजीपूर्वक संग्रहित केले. मी ते इतके काळजीपूर्वक ठेवले आहे की असा मोनोलिथ पाहणे लांब आणि अजिबात सोपे नाही.
एक लहान विषयांतर.

विविध कार्यक्रमांमध्ये मी म्हणतो: "जर तुम्हाला मोनोलिथ दिसला नाही, तर तुम्ही वाढला नाही!" मला या विषयावरील तुमच्या मतामध्ये स्वारस्य आहे, कृपया टिप्पण्यांमध्ये लिहा.

थंडरचा आवाज

चला आपल्या "बोनफायर" वर परत येऊ. "मोनोलिथिक" कार्यक्षमतेचा भार वितरीत करण्यासाठी, आम्ही ओपनसोर्स तंत्रज्ञानावर आधारित प्रणालीला मायक्रोसर्व्हिसेसमध्ये विभाजित करण्याचा निर्णय घेतला. कारण, कमीतकमी, ते मोजण्यासाठी स्वस्त आहेत. आणि आम्हाला 100% समज होते की आम्हाला मोजावे लागेल (आणि बरेच काही). तथापि, त्या वेळी आधीच शेजारच्या देशांच्या बाजारपेठेत प्रवेश करणे शक्य झाले होते आणि नोंदणीची संख्या तसेच ऑर्डरची संख्या आणखी जोरदार वाढू लागली.

मोनोलिथपासून मायक्रोसर्व्हिसेसकडे जाणाऱ्या पहिल्या उमेदवारांचे विश्लेषण केल्यावर, आम्हाला समजले की त्यांच्यातील 80% लेखन हे बॅक ऑफिस सिस्टममधून आले आहे आणि समोरच्या ऑफिसमधून वाचले गेले आहे. सर्व प्रथम, हे आमच्यासाठी काही महत्त्वाच्या उपप्रणालींशी संबंधित आहे - वापरकर्ता डेटा आणि अतिरिक्त ग्राहक सवलत आणि कूपनच्या माहितीवर आधारित वस्तूंची अंतिम किंमत मोजण्यासाठी एक प्रणाली.

इंडेंट केलेले. आता याची कल्पना करणे भितीदायक आहे, परंतु वर नमूद केलेल्या उपप्रणाली व्यतिरिक्त, उत्पादन कॅटलॉग, वापरकर्ता शॉपिंग कार्ट, एक उत्पादन शोध प्रणाली, उत्पादन कॅटलॉगसाठी फिल्टरिंग सिस्टम आणि विविध प्रकारच्या शिफारसी प्रणाली देखील आमच्या मोनोलिथमधून काढून टाकल्या गेल्या आहेत. त्या प्रत्येकाच्या ऑपरेशनसाठी, अरुंदपणे तयार केलेल्या सिस्टमचे वेगळे वर्ग आहेत, परंतु एकेकाळी ते सर्व एका "घर" मध्ये राहत होते.

आम्ही ताबडतोब आमच्या क्लायंटचा डेटा शार्डेड सिस्टममध्ये हस्तांतरित करण्याची योजना आखली. वस्तूंच्या अंतिम किंमतीची गणना करण्यासाठी कार्यक्षमता काढून टाकण्यासाठी वाचनासाठी चांगली स्केलेबिलिटी आवश्यक आहे, कारण यामुळे सर्वात मोठा RPS लोड तयार झाला आणि डेटाबेससाठी अंमलबजावणी करणे सर्वात कठीण होते (गणनेच्या प्रक्रियेत भरपूर डेटा गुंतलेला आहे).

परिणामी, आम्ही एक योजना आणली जी टॅरनटूलमध्ये बसते.

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

आर्किटेक्चर. पर्याय 1. वापरकर्ता सेवा

सध्या, 24 शार्ड्स आहेत, त्यापैकी प्रत्येकामध्ये 2 उदाहरणे आहेत (प्रत्येक DC साठी एक), सर्व मास्टर-मास्टर मोडमध्ये आहेत.

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

या प्रकरणात, शार्ड्सच्या संदर्भात प्रतिकृती निवड धोरण कॉन्फिगर करणे शक्य आहे. उदाहरणार्थ, राउंडरॉबिन.

आर्किटेक्चर. पर्याय 2. मालाची अंतिम किंमत मोजण्यासाठी सेवा

काही महिन्यांपूर्वी, वस्तूंच्या अंतिम किंमतीची गणना करण्याच्या बहुतेक विनंत्या नवीन सेवेकडे गेल्या, जे तत्त्वतः डेटाबेसशिवाय कार्य करते, परंतु काही काळापूर्वी हुड अंतर्गत टारंटूलसह सेवेद्वारे सर्व काही 100% प्रक्रिया केली गेली होती.

सेवा डेटाबेसमध्ये 4 मास्टर्स असतात ज्यामध्ये सिंक्रोनायझर डेटा संकलित करतो आणि यापैकी प्रत्येक प्रतिकृती मास्टर्स केवळ वाचनीय प्रतिकृतींसाठी डेटा वितरित करतात. प्रत्येक मास्टरकडे अशा अंदाजे 15 प्रतिकृती असतात.

एकतर पहिल्या किंवा दुसर्‍या योजनेत, एक DC अनुपलब्ध असल्यास, अनुप्रयोग दुसर्‍या योजनेत डेटा प्राप्त करू शकतो.

हे लक्षात घेण्यासारखे आहे की टारंटूलमधील प्रतिकृती खूपच लवचिक आहे आणि रनटाइममध्ये कॉन्फिगर केली जाऊ शकते. इतर यंत्रणांमध्ये अडचणी निर्माण झाल्या. उदाहरणार्थ, PostgreSQL मधील max_wal_senders आणि max_replication_slots पॅरामीटर्स बदलण्यासाठी विझार्ड रीस्टार्ट करणे आवश्यक आहे, जे काही प्रकरणांमध्ये ऍप्लिकेशन आणि DBMS मधील कनेक्शन तोडण्यास कारणीभूत ठरू शकते.

शोधा आणि तुम्हाला सापडेल!

आम्ही ते "सामान्य लोकांसारखे" का केले नाही, परंतु एक असामान्य मार्ग निवडला? हे सामान्य मानले जाते यावर अवलंबून असते. बरेच लोक सामान्यतः मोंगोपासून एक क्लस्टर बनवतात आणि ते तीन भौगोलिक-वितरित डीसीमध्ये पसरवतात.

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

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

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

शेवटी आम्ही टारनटूलवर स्थिरावलो.

आवृत्ती १.६ मध्ये असताना आम्ही त्याकडे वळलो. की-व्हॅल्यूचे सहजीवन आणि रिलेशनल डेटाबेसच्या कार्यक्षमतेमुळे आम्हाला त्यात रस होता. दुय्यम अनुक्रमणिका, व्यवहार आणि जागा आहेत, हे सारण्यांसारखे आहेत, परंतु सोपे नाही, आपण त्यामध्ये भिन्न संख्येचे स्तंभ संग्रहित करू शकता. पण टारनटूलचे किलर वैशिष्ट्य म्हणजे की-व्हॅल्यू आणि ट्रान्झॅक्शनॅलिटीसह दुय्यम अनुक्रमणिका.

प्रतिसाद देणारा रशियन भाषिक समुदाय, चॅटमध्ये मदत करण्यास तयार आहे, त्यांनी देखील भूमिका बजावली. आम्ही सक्रियपणे याचा वापर केला आणि थेट चॅटमध्ये राहतो. आणि स्पष्ट चुका आणि चुकांशिवाय सभ्य निरंतर बद्दल विसरू नका. जर तुम्ही टारनटूलसह आमचा इतिहास पाहिला तर, आम्हाला प्रतिकृतीसह खूप वेदना आणि अयशस्वी झाल्या होत्या, परंतु आम्ही डेटाच्या चुकीमुळे कधीही गमावला नाही!

अंमलबजावणीला सुरुवात झाली

त्या वेळी, आमचा मुख्य विकास स्टॅक होता .NET, ज्याला Tarantool साठी कनेक्टर नव्हते. आम्ही लगेच गो मध्ये काहीतरी करायला लागलो. लुआसोबतही ते चांगले काम केले. त्या वेळी मुख्य समस्या डीबगिंगची होती: .NET मध्ये यासह सर्व काही छान आहे, परंतु त्यानंतर एम्बेडेड लुआच्या जगात प्रवेश करणे कठीण होते, जेव्हा आपल्याकडे लॉग वगळता कोणतेही डीबगिंग नसते. याव्यतिरिक्त, काही कारणास्तव प्रतिकृती अधूनमधून तुटली, म्हणून मला टॅरनटूल इंजिनच्या संरचनेचा शोध घ्यावा लागला. चॅटने यात मदत केली आणि काही प्रमाणात कागदपत्रे; कधीकधी आम्ही कोड पाहिला. त्यावेळी कागदपत्रे तशी होती.

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

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

आज हे यापुढे कार्य करणार नाही: तुम्हाला सेवेमध्ये देखरेख आणि लॉगिंग जोडणे आवश्यक आहे, चाचणीसह कार्यक्षमता कव्हर करणे, व्हर्च्युअल मशीन ऑर्डर करणे किंवा कुबेरला वितरण करणे इ. सर्वसाधारणपणे, हे या मार्गाने चांगले होईल, जरी यास जास्त वेळ लागेल आणि अधिक त्रासदायक असेल.

फूट पाडा आणि राज्य करा. लुआशी काय करार आहे?

एक गंभीर पेचप्रसंग होता: काही संघ लुआमध्ये बरेच तर्कशास्त्र असलेल्या सेवेतील बदल विश्वासार्हपणे आणू शकले नाहीत. हे अनेकदा सेवा कार्य करत नाही दाखल्याची पूर्तता होते.

म्हणजेच, विकासक काही प्रकारचे बदल तयार करत आहेत. टारंटूल स्थलांतर करण्यास सुरुवात करते, परंतु प्रतिकृती अद्याप जुन्या कोडसह आहे; काही DDL किंवा इतर काहीतरी प्रतिकृतीद्वारे तेथे पोहोचते आणि कोड फक्त वेगळा पडतो कारण तो विचारात घेतला जात नाही. परिणामी, प्रशासकांसाठी अद्यतन प्रक्रिया A4 शीटवर मांडली गेली: प्रतिकृती थांबवा, हे अद्यतनित करा, प्रतिकृती चालू करा, येथे बंद करा, तेथे अद्यतनित करा. दुःस्वप्न!

परिणामी, आता आम्ही बहुतेकदा लुआमध्ये काहीही करण्याचा प्रयत्न करतो. फक्त iproto (सर्व्हरशी संवाद साधण्यासाठी बायनरी प्रोटोकॉल) वापरा आणि तेच. कदाचित ही विकासकांमधील ज्ञानाची कमतरता आहे, परंतु या दृष्टिकोनातून ही प्रणाली जटिल आहे.

आम्ही नेहमी या स्क्रिप्टचे आंधळेपणाने अनुसरण करत नाही. आज आपल्याकडे काळा आणि पांढरा नाही: एकतर सर्वकाही लुआमध्ये आहे किंवा सर्वकाही गोमध्ये आहे. आम्ही त्यांना कसे एकत्र करू शकतो हे आम्हाला आधीच समजले आहे जेणेकरून आम्हाला नंतर स्थलांतर समस्या येऊ नयेत.

टारंटूल आता कुठे आहे?
टारनटूलचा वापर सवलत कूपन, ज्याला “प्रवर्तक” म्हणूनही ओळखले जाते, विचारात घेऊन मालाची अंतिम किंमत मोजण्यासाठी सेवेमध्ये वापरली जाते. मी आधी म्हटल्याप्रमाणे, तो आता निवृत्त होत आहे: त्याच्या जागी पूर्व-गणना केलेल्या किंमतींसह नवीन कॅटलॉग सेवेद्वारे बदलले जात आहे, परंतु सहा महिन्यांपूर्वी सर्व गणना प्रमोटायझरमध्ये केली गेली होती. पूर्वी, त्याचे अर्धे तर्क लुआमध्ये लिहिलेले होते. दोन वर्षांपूर्वी, सेवेचे स्टोरेज सुविधेत रूपांतर करण्यात आले आणि गो मध्ये तर्क पुन्हा लिहिला गेला, कारण सवलतींचे यांत्रिकी थोडेसे बदलले होते आणि सेवेची कार्यक्षमता कमी होती.

सर्वात गंभीर सेवांपैकी एक म्हणजे वापरकर्ता प्रोफाइल. म्हणजेच, सर्व Wildberries वापरकर्ते Tarantool मध्ये संग्रहित आहेत, आणि त्यापैकी सुमारे 50 दशलक्ष आहेत. वापरकर्ता ID द्वारे शार्ड केलेली प्रणाली, Go सेवांशी जोडलेल्या अनेक DC मध्ये वितरित केली जाते.
RPS च्या मते, प्रमोटर एकेकाळी नेता होता, 6 हजार विनंत्या गाठत होता. एका वेळी आमच्याकडे 50-60 प्रती होत्या. आता RPS मध्ये लीडर युजर प्रोफाईल आहे, सुमारे 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