कैसे हमारे काले शुक्रवार को बचाया

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



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

कीमतों के साथ काम करने के इन सभी तंत्रों के साथ व्यापार खुश है, लेकिन हम सेवा के बारे में थोड़ा अलग दृष्टिकोण से बात करना चाहते हैं।

यह कैसे काम करता है

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

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



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

ब्लैक फ्राइडे 2016। और हमने उसकी देखरेख की

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

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

आधी रात से एक घंटे पहले सेवा "चली गई"। यह सब डेटाबेस (उस समय MySQL) के संबंध में एक ब्रेक के साथ शुरू हुआ, जिसके बाद मूल्य गणना सेवा की सभी चलने वाली प्रतियां वापस कनेक्ट नहीं हो सकीं। और जो अभी भी जुड़े हुए थे वे लोड का सामना नहीं करते थे और जवाब देना बंद कर दिया था, आधार ताले पर अटक गया था।

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

जैसे ही कार्यवाही शुरू हुई, इस बारे में विवरण खुलने लगे कि सेवा कितनी उप-स्तरीय है। उदाहरण के लिए, यह पता चला कि एक कूपन की गणना करने के लिए, 28 प्रश्न डेटाबेस से किए गए थे (यह आश्चर्यजनक नहीं है कि सब कुछ 100% सीपीयू उपयोग के साथ काम करता है)। समान ब्लैक फ्राइडे कूपन के साथ ऊपर उल्लिखित उपयोगकर्ताओं ने स्थिति को सरल नहीं किया, खासकर जब से हमारे पास सभी कूपन के लिए एक आवेदन काउंटर था - इसलिए प्रत्येक उपयोग ने इस काउंटर का संदर्भ देकर लोड बढ़ाया।

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


ब्लैक फ्राइडे 2016 के परिणाम

ब्लैक फ्राइडे 2017. हम गंभीरता से तैयारी कर रहे थे, लेकिन ...

एक अच्छा सबक प्राप्त करने के बाद, हमने अगले "ब्लैक फ्राइडे" के लिए अग्रिम रूप से तैयार किया, गंभीरता से पुनर्निर्माण और सेवा को अनुकूलित किया। उदाहरण के लिए, हमने अंततः दो प्रकार के कूपन बनाए: सीमा और असीमित - डेटाबेस तक एक साथ पहुंच से बचने के लिए, हमने लोकप्रिय कूपन को लागू करने के लिए स्क्रिप्ट से डेटाबेस में प्रवेश को हटा दिया। समानांतर में, ब्लैक फ्राइडे से 1-2 महीने पहले, हमने MySQL से पोस्टग्रेक्सेल को सेवा में स्विच किया, जिसने कोड ऑप्टिमाइज़ेशन के साथ मिलकर डेटाबेस कॉल की संख्या 28 से घटाकर 4-5 कर दी। इन सुधारों ने हमें परीक्षण सेवा को SLA आवश्यकताओं - उत्तर तक विस्तारित करने की अनुमति दी। 3 सेकंड में, 95 प्रतिशत 600 RPS पर।

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

ग्राहकों के मुख्य प्रवाह के आगमन के साथ "आपातकाल" के दिन, सेवा पर भार तेजी से बढ़ने लगा। कुछ अनुरोधों को दो मिनट तक संसाधित किया गया था। कुछ अनुरोधों के लंबे प्रसंस्करण के कारण, अन्य श्रमिकों पर भार बढ़ गया।

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

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

ब्लैक फ्राइडे 2018

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



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

हमने इस गर्मियों में एक नई सेवा पर स्विच किया, इसलिए अगली बिक्री से पहले हम इसे अच्छी तरह से परीक्षण करने में कामयाब रहे, जिसमें एक लोड लोड प्रोफाइल शामिल है।

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

सच है, इस साल हमें ऊपर की ओर लोड पूर्वानुमान के साथ गलती हुई थी: हम चोटियों में 6-8 गुना वृद्धि की तैयारी कर रहे थे और इस तरह के अनुरोधों के लिए सेवाओं का अच्छा काम हासिल किया (अतिरिक्त कैश, अक्षम प्रयोगात्मक कार्यों को अग्रिम में, कुछ चीजों को सरल बनाया, अतिरिक्त कुबेरनेट्स नोड्स को तैनात किया। और यहां तक ​​कि प्रतिकृतियों के लिए डेटाबेस सर्वर, जो अंत में आवश्यक नहीं थे)। वास्तव में, उपयोगकर्ता की रुचि में वृद्धि कम थी, इसलिए सब कुछ हमेशा की तरह चला गया। सेवा प्रतिक्रिया समय 95 प्रतिशत पर 50 एमएस से अधिक नहीं था।

हमारे लिए, सबसे महत्वपूर्ण विशेषताओं में से एक यह है कि जब एक कॉपी के लिए पर्याप्त संसाधन नहीं होते हैं तो आवेदन कैसे बढ़ता है। जाओ हार्डवेयर संसाधनों का अधिक कुशलता से उपयोग करता है, इसलिए उसी लोड के साथ आपको कम प्रतियां चलाने की आवश्यकता होती है (अंततः उसी हार्डवेयर संसाधनों पर अधिक अनुरोधों की सेवा)। इस वर्ष, बिक्री के चरम पर, आवेदन के 16 उदाहरण काम कर रहे थे, जिसने प्रति सेकंड 400 अनुरोधों की चोटियों के साथ औसतन 300 अनुरोधों को संसाधित किया, जो सामान्य भार से लगभग दो गुना अधिक है। ध्यान दें कि पिछले साल, पायथन सेवा को 102 उदाहरणों की आवश्यकता थी।

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

एक और "सेटअप" उन कनेक्शनों की संख्या है, जिन्हें कीप-अलाइव के रूप में रखा जाता है। डिफ़ॉल्ट रूप से गो में नियमित http और DB क्लाइंट केवल दो कनेक्शन रखते हैं, इसलिए यदि कई समवर्ती अनुरोध हैं और आपको टीसीपी कनेक्शन सेटअप के ट्रैफ़िक को बचाने की आवश्यकता है, तो क्रमशः MaxIdleConnsPerHost और SetaxaxIdleConns की स्थापना करके इस मान को बढ़ाने के लिए समझ में आता है।

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