👨🏼‍🚀 ✌🏽 🏴 हमने सिटीमोबाइल के विकास को कैसे सुनिश्चित किया 🧔🏼 👐🏾 🕙

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

विकास की शुरुआत

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

2018 में, Mail.Ru Group ने CityMobile में निवेश किया और हम तेजी से विकसित होने लगे। मंच को फिर से लिखने, या कम से कम महत्वपूर्ण रीफैक्टरिंग करने का समय नहीं था, हमारे मुख्य प्रतियोगी के साथ पकड़ने और लोगों को जल्दी से काम पर रखने के लिए इसकी कार्यात्मक क्षमताओं को विकसित करना आवश्यक था। जब मैं कंपनी में शामिल हुआ, तो केवल 20 डेवलपर्स बैकएंड में शामिल थे, और उनमें से लगभग सभी परीक्षण पर थे। इसलिए, हमने "कम लटके हुए फल" का फैसला किया: सरल परिवर्तन करने के लिए जो बहुत बड़ा परिणाम देते हैं।

उस समय, हमारे पास PHP में एक मोनोलिथ और गो पर तीन सेवाओं के साथ-साथ MySQL में एक मास्टर बेस था जिसे मोनोलिथ एक्सेस कर रहा था (सेवाओं का उपयोग रेडिस और इलास्टिक खोज के रिपॉजिटरी के रूप में किया गया था)। और धीरे-धीरे, बढ़ते भार के साथ, भारी सिस्टम अनुरोधों ने आधार को धीमा करना शुरू कर दिया।

इससे क्या हो सकता है?

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

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

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

ला;
दास अंतराल;
बंदरगाह की उपलब्धता;
तालों की संख्या, आदि।

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

आगे की वृद्धि

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

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

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

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

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

अब यह हाईलोड सिस्टम को डिजाइन करने के लिए दो बहुत महत्वपूर्ण पैटर्न को याद करने का समय है:

Graceful degradation. , - . , , , , .. , .
Circuit breaker. , . , , , . ? ( - graceful degradation). , FPM- , . - ( ) , . , - , ( ).

इसलिए, हम बहुत कम से कम पैमाने पर शुरू हुए, लेकिन अभी भी विफलता के बिंदु थे।

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

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

आगे क्या होगा?

जब मैं सिटीमोबाइल आया, तो हमारे पास तीन सेवाएं थीं और एक मोनोलिथ थी। आज उनमें से 20 से अधिक हैं। और हमारी विकास की मुख्य बात यह है कि हमारे पास अभी भी एक ही मास्टर बेस है। हम वीरतापूर्वक इसका मुकाबला करते हैं और इसे अलग-अलग आधारों में विभाजित करते हैं।

हम आगे कैसे विकसित होंगे?

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

जाने के लिए जाना।मैं वास्तव में इस भाषा से प्यार करता हूं, लेकिन मैं हमेशा मानता था कि एक भाषा से दूसरी भाषा में काम करने वाले कोड को फिर से लिखना व्यावहारिक नहीं था। लेकिन हाल ही में, अनुभव से पता चला है कि पीएचपी लाइब्रेरी, यहां तक कि मानक और सबसे लोकप्रिय भी, उच्चतम गुणवत्ता के नहीं हैं। यही है, हम कई पुस्तकालयों को पैच करते हैं। मान लीजिए कि SRE टीम ने RabbitMQ के साथ बातचीत करने के लिए मानक पुस्तकालय को पैच कर दिया: यह पता चला कि ऐसा मूल कार्य समय पर काम नहीं करता था। और SRE टीम जितनी गहरी है और मैं इन समस्याओं को समझता हूं, उतना ही यह स्पष्ट हो जाता है कि कुछ लोग PHP में टाइमआउट के बारे में सोचते हैं, कुछ लोग पुस्तकालयों के परीक्षण के बारे में परवाह करते हैं, कुछ लोग ताले के बारे में सोचते हैं। यह हमारे लिए समस्या क्यों बन रहा है? क्योंकि गो सॉल्यूशंस बनाए रखना बहुत आसान है।

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

इसके अलावा, गो में बहुत अच्छे लिंटर हैं - प्रोग्राम जो स्वचालित रूप से आपके लिए सबसे आम त्रुटियां पाते हैं। उनमें से अधिकांश का वर्णन "50 शेड्स ऑफ़ गो" में किया गया है और लिंटर पूरी तरह से उनका पता लगाते हैं।

ठिकानों पर पैनापन जारी रखें। हम सभी सेवाओं पर Vitess पर जाएँगे।

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

हम RabbitMQ की समस्याओं की जांच करेंगे। ऐसा माना जाता है कि RabbitMQ सबसे विश्वसनीय सॉफ्टवेयर नहीं है। हम इस मुद्दे का अध्ययन करेंगे, समस्याओं का पता लगाएंगे और हल करेंगे। शायद हम काफ्का या टारनटूल पर जाने के बारे में सोचेंगे।

हमने सिटीमोबाइल के विकास को कैसे सुनिश्चित किया

विकास की शुरुआत

आगे की वृद्धि

हम आगे कैसे विकसित होंगे?

More articles: