🔍 🤴🏾 👩‍❤️‍👨 हम दूरस्थ साइट पर x10 के भार में तेज वृद्धि से कैसे बचे और निष्कर्ष क्या किया 👃🏻 🚑 🏇

हेलो, हेब्र! पिछले कुछ महीनों में हम एक बहुत ही दिलचस्प स्थिति में रहे हैं, और मैं बुनियादी ढाँचे के हमारे इतिहास को साझा करना चाहूंगा। इस समय के दौरान, SberMarket ने ऑर्डर में 4 गुना वृद्धि की और 17 नए शहरों में एक सेवा शुरू की। खाद्य वितरण की मांग में विस्फोटक वृद्धि ने हमें अपने बुनियादी ढांचे को बढ़ाने की आवश्यकता है। बिल्ली के नीचे सबसे दिलचस्प और उपयोगी निष्कर्ष पढ़ें।

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

एक टीम का प्रबंधन करते समय, यह समझना महत्वपूर्ण है कि व्यवसाय के लिए और प्रत्येक विशिष्ट डेवलपर की जरूरतों के बीच संतुलन कैसे बनाया जाए। अब SberMarket साल-दर-साल 13 गुना बढ़ रहा है, और यह उत्पाद को प्रभावित करता है, जिससे विकास की मात्रा और गति में निरंतर वृद्धि की आवश्यकता होती है। इसके बावजूद, हम प्रारंभिक विश्लेषण और उच्च-गुणवत्ता कोड लेखन के लिए डेवलपर्स के लिए पर्याप्त समय समर्पित करते हैं। गठित दृष्टिकोण न केवल एक कार्यशील उत्पाद बनाने में मदद करता है, बल्कि इसके आगे के स्केलिंग और विकास में भी मदद करता है। इस वृद्धि के परिणामस्वरूप, SberMarket पहले से ही खाद्य वितरण सेवाओं के बीच एक नेता बन गया है: हम हर दिन लगभग 18 हजार ऑर्डर देते हैं, हालांकि फरवरी की शुरुआत में उनमें से लगभग 3,500 थे।

एक बार एक ग्राहक ने SberMarket कूरियर से संपर्क करने के लिए उत्पादों को वितरित करने के लिए कहा - सीधे बालकनी पर।

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

पूरी चौकसी में गुलाम

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

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

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

लोड के एक निश्चित स्तर तक, हमारे पास http अनुरोधों को संसाधित करते समय लिखने और पढ़ने दोनों के लिए पर्याप्त विज़ार्ड थे। मार्च के मध्य में, जब Sbermarket ने किसी दूरस्थ साइट पर पूरी तरह से स्विच करने का निर्णय लिया, तो हमने RPS में कई वृद्धि शुरू की। हमारे अधिक से अधिक ग्राहक घर से स्वयं-अलगाव या काम पर चले गए, जो लोड संकेतकों में परिलक्षित होता था।

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

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

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

लेकिन चूंकि हमने न केवल डेटाबेस (उस समय बाकी लगभग 5 घंटे) को डंप किया था, बल्कि एक स्नैपशॉट मास्टर सर्वर भी था, हम 2 घंटे के भीतर प्रतिकृति शुरू करने में कामयाब रहे। सच है, उसके बाद हमें लंबे समय तक प्रतिकृति लॉग को रोल करने की उम्मीद थी (क्योंकि प्रक्रिया एकल-थ्रेडेड मोड में है, लेकिन यह पूरी तरह से अलग कहानी है)।

: , readonly . , .

« »

यद्यपि हम साइट पर कैटलॉग को लगातार अपडेट करते हैं, लेकिन हमने स्लेव सर्वरों से जो अनुरोध किए हैं, वे मास्टर से थोड़ी सी भी चूक की अनुमति देते हैं। जिस समय के दौरान हमने खोज की और "अचानक दूरी छोड़ने" की समस्या को खत्म कर दिया, दास एक "मनोवैज्ञानिक बाधा" से अधिक था (इस समय के दौरान कीमतें अपडेट हो सकती थीं, और ग्राहकों ने पुराने डेटा को देखा होगा), और हमें मुख्य डेटाबेस सर्वर के लिए सभी अनुरोधों को बदलना पड़ा । नतीजतन, साइट ने धीरे-धीरे काम किया ... लेकिन कम से कम यह काम किया। और जब दास ठीक हो रहा था, हमारे पास अनुकूलन के अलावा कोई विकल्प नहीं था।

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

एक दिलचस्प प्रभाव यह था कि MySQL नेत्रगोलक के लिए भरी हुई प्रक्रियाओं में मामूली सुधार के लिए भी प्रतिक्रिया करता है। अनुरोधों की एक जोड़ी का अनुकूलन, जिसने कुल भार का केवल 5% दिया, पहले से ही मूर्त CPU अनलोडिंग दिखाया। परिणामस्वरूप, हम डेटाबेस के साथ काम करने और प्रतिकृतियों को पुनर्स्थापित करने के लिए आवश्यक समय प्राप्त करने के लिए मास्टर के लिए संसाधनों की स्वीकार्य आपूर्ति प्रदान करने में सक्षम थे।

निष्कर्ष: यहां तक कि एक छोटा अनुकूलन आपको कई घंटों तक अधिभार के दौरान "जीवित" रहने की अनुमति देता है। प्रतिकृतियों के साथ सर्वरों की वसूली के दौरान यह हमारे लिए पर्याप्त था। वैसे, हम निम्नलिखित पोस्टों में से एक में क्वेरी ऑप्टिमाइज़ेशन के तकनीकी पक्ष पर चर्चा करेंगे। तो अगर यह आपके लिए उपयोगी हो सकता है, तो हमारे ब्लॉग की सदस्यता लें।

भागीदार सेवाओं की प्रदर्शन निगरानी व्यवस्थित करें

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

सहबद्ध सेवाओं के लिए कोटा के अनपेक्षित अतिरिक्त आपके खुद के डाउनटाइम का कारण बन सकते हैं। कई API क्लाइंट को सीमा से अधिक ब्लॉक करते हैं, और कुछ मामलों में, अनुरोधों की अधिकता एक साथी के साथ उत्पादन को अधिभारित कर सकती है।

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

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

: . , « », , . , , .

, « » ()

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

अपेक्षित प्रदर्शन लाभ के बजाय, सर्वर केवल "मर गया"। इसने तुरंत 100% लोड किया और धीरे-धीरे इसका जवाब दिया। शुरुआत में, हमारे पास 2 कोर और 2 जीबी रैम थी। हमने वह करने का फैसला किया जो आमतौर पर मदद करता है - हमने सर्वर को 8 कोर और 32 जीबी दिया। सब कुछ बहुत खराब हो गया है (बिल्कुल कैसे और क्यों - हम एक अलग पोस्ट में बताएंगे)।

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

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

स्टेटलेस - आसान क्षैतिज स्केलिंग की कुंजी

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

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

निष्कर्ष: बिना किसी अपवाद के सभी घटकों के लिए स्टेटलेस नियम का सम्मान किया जाना चाहिए, भले ही ऐसा लगता है कि "हम निश्चित रूप से परेशान नहीं कर रहे हैं"। सभी प्रणालियों के काम के सही संगठन पर थोड़ा समय बिताने से बेहतर है कि जल्दी में कोड को फिर से लिखना और ओवरलोड का सामना करने वाली सेवा की मरम्मत करना।

तीव्र वृद्धि के लिए 7 सिद्धांत

अतिरिक्त क्षमता की उपलब्धता के बावजूद, वृद्धि की प्रक्रिया में हमने कुछ रेक पर कदम रखा। इस समय के दौरान, आदेशों की संख्या में 4 गुना से अधिक की वृद्धि हुई। अब हम पहले से ही 62 शहरों में एक दिन में 17,000 से अधिक ऑर्डर देते हैं और अपने भूगोल को और भी विस्तारित करने की योजना बना रहे हैं - 2020 की पहली छमाही में पूरे रूस में सेवा शुरू होने की उम्मीद है। बढ़ते भार का सामना करने के लिए, पहले से ही पूर्ण धक्कों को ध्यान में रखते हुए, हमने निरंतर विकास की स्थितियों में अपने लिए काम के 7 मूल सिद्धांतों को विकसित किया है:

-. Jira, . . — . , , , , .
. « » . , , . , .
. -, . -, , .
stateless. , . . , , S3. https://12factor.net. , .
. , . , , - . , .
. , . , SMS . , .
. , . , , . API, -. .

नुकसान के बिना नहीं, लेकिन हम इस चरण से बच गए, और आज हम सभी पाए गए सिद्धांतों का पालन करने की कोशिश करते हैं, और प्रत्येक मशीन किसी भी आश्चर्य से निपटने के लिए आसानी से x4 प्रदर्शन को बढ़ाने की क्षमता रखती है।

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

हम दूरस्थ साइट पर x10 के भार में तेज वृद्धि से कैसे बचे और निष्कर्ष क्या किया

पूरी चौकसी में गुलाम

« »

भागीदार सेवाओं की प्रदर्शन निगरानी व्यवस्थित करें

, « » ()

स्टेटलेस - आसान क्षैतिज स्केलिंग की कुंजी

तीव्र वृद्धि के लिए 7 सिद्धांत

More articles: