🅿️ 🛀🏽 🌚 हमने स्कूलों को दूरस्थ शिक्षा पर स्विच करने में मदद की और लोड के साथ मुकाबला किया 🐝 🌁 🥓

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

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

एक समय में साइट पर अद्वितीय उपयोगकर्ताओं की चोटी की संख्या 240 हजार तक पहुंच गई, हमने 30 हजार लोगों पर वर्तमान स्कूल वर्ष की पिछली अधिकतम दर्ज की। इस बिंदु पर, हर दिन लोड बढ़ता गया, और हमने साइट को स्थिर करने के लिए घड़ी के चारों ओर काम किया।

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

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

खुद पर भरोसा करें

यातायात से पहले संकट के दौरान, आप एक टीम के रूप में एक हो जाते हैं। यह आपके कर्मचारियों पर निर्भर करेगा कि आप समाधान पाएंगे, संकट का सामना करेंगे या नहीं।

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

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

विस्तारित बादल

आप सभी संकटों के खिलाफ बीमा नहीं कर सकते, लेकिन लचीला होना ज़रूरी है। क्लाउड स्टैक ने हमें इस तरह की नाटकीयता और लोड में नाटकीय वृद्धि के साथ भी दूर रहने का मौका दिया।

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

अपग्रेड किए गए निगरानी उपकरण

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

अनुकूलित कैश संग्रहण

कुंजी-मूल्य वाले स्टोर के साथ एक समस्या भी उत्पन्न हुई। एक आवेदन में, रेडिस सामना नहीं कर सका - एक प्रति में यह केवल एक कोर पर काम कर सकता है। इसलिए, उन्होंने KeyDB नामक एक Redis कांटा का इस्तेमाल किया, जो कई थ्रेड्स में काम कर सकता है।

किसी अन्य एप्लिकेशन में बैंडविड्थ बढ़ाने के लिए, हमने 10 स्वतंत्र Redis'ov उठाए हैं। वे हमारे सर्विस मेश द्वारा अनुमानित हैं, जिसमें कुंजियाँ भी हैं। यहां तक कि अगर एक या दो रेडिस क्रैश होते हैं, तो यह लगातार हैशिंग के कारण समस्याएं पैदा नहीं करेगा। साथ ही, उन्हें व्यावहारिक रूप से प्रशासित होने की आवश्यकता नहीं है।

नेटवर्क का विस्तार किया

जैसा कि आप जानते हैं, 640 Kb सभी के लिए पर्याप्त है। हमने हमेशा निजी / 24 सबनेट का उपयोग किया, लेकिन संगरोध की पृष्ठभूमि के खिलाफ हमें तत्काल / 22 तक विस्तार करना पड़ा। अब नेटवर्क चार बार कई सर्वरों को समायोजित करता है, हमें उम्मीद है कि यह सुनिश्चित करने के लिए पर्याप्त होगा।

PgBouncer अलग से किया जाता है

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

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

हमने बाउंसरों को एक अलग सर्वर में स्थानांतरित कर दिया, जिससे हमें प्रत्येक डेटाबेस सर्वर पर 20-25% सीपीयू बचाने में मदद मिली।

आश्चर्य से सामना हुआ

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

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

खेल के नियमों को स्वीकार किया

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

इस साल ऐसा ही एक मजेदार वसंत है। जब ऐसा लगता है कि सब कुछ संभव हो गया है, तो कभी-कभी यह पता चलता है कि यह केवल शुरुआत है।

हमने स्कूलों को दूरस्थ शिक्षा पर स्विच करने में मदद की और लोड के साथ मुकाबला किया