प्रति घंटे 280,000 आगंतुकों का भार झेलते हुए ऑनलाइन स्टोर कैसे बनाया जाए?

हेलो, हेब्र!

दुर्भाग्य से, इस चरण में हमारे देश में वेब प्रोग्रामिंग के विकास में, एक परियोजना को फिर से दिखाना अक्सर "सभी खराब" मोड में प्रोग्रामर के काम के रूप में माना जाता है और केवल तभी बाहर किया जाता है जब साइट पहले से ही गंभीर स्थिति में हो। हमें 2012 में इसी तरह की स्थिति का सामना करना पड़ा था, जब एक प्रमुख रूसी ऑनलाइन स्टोर निम्नलिखित समस्या के साथ हमारी सेवा में आया था: सुबह 10 बजे शुरू, हर 5 मिनट में साइट 5-10 मिनट के लिए गिर गई और बड़ी मुश्किल से या कठिन रिबूट के बाद ऊपर चली गई । रीबूट के बाद, साइट ने थोड़ा काम किया, और फिर फिर से दुर्घटनाग्रस्त हो गया। विशेष रूप से तीव्र तथ्य यह था कि नया साल करीब आ रहा था, सभी बिक्री साइटों के लिए उच्च मौसम, और इस मामले में, "10 मिनट में एक कंपनी ने दसियों हज़ार डॉलर खो दिए" वाक्यांश एक मजाक नहीं था।


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

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

हालाँकि, यह केवल लगता है। हमारी वास्तविकता में, वेब डेवलपर्स की वास्तविकता, किसी भी सबसे शक्तिशाली हार्डवेयर का अपना अंतहीन चक्र और एक अद्भुत रूपरेखा है। और अक्सर ऐसी परिस्थितियां होती हैं जब सबसे शक्तिशाली हार्डवेयर लिखित कोड को भी नहीं खींचता है।

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

सामान्य ऑपरेशन के लिए किसी तरह का समय प्राप्त करने के लिए, हमने पहले किसी तरह इस परियोजना को स्थिर करने का फैसला किया ताकि यह नए साल तक जीवित रह सके, और फिर इसकी वैश्विक पुनर्रचना और पुन: प्रसंस्करण हो सके।

प्रवेश द्वार पर हमारे पास क्या था?

हम जानते थे कि सिस्टम के विभिन्न हिस्सों पर लोड शेड्यूल काफी सहज होना चाहिए। उदाहरण के लिए, जैसे:



यह इस तथ्य के कारण है कि बहुत मुश्किल से ही एक सेकंड में एक साइट पर शून्य उपयोगकर्ता हैं, और अगले में - पीक लोड के सभी 110,000 उपयोगकर्ता।

हालाँकि, हमने ग्राहक की परियोजना पर जो देखा वह हमारी सारी प्रथा के विपरीत था: सभी अनुसूचियां कूद गईं और एक व्यस्त जीवन का नेतृत्व किया।
यह कुछ इस तरह देखा गया:

अपाचे:


शायद यह शेड्यूल पर बढ़े हुए लोड पर अधिक आनन्दित करने के लायक होगा - अधिक आगंतुक, अधिक पैसा - लेकिन Google Analytics ने कहा कि आगंतुकों की संख्या न केवल बढ़ी, बल्कि गिर भी गई।

एक नियम के रूप में, सिस्टम की एक स्थिर और सही स्थिति में, अपाचे पर लोड में वृद्धि MySQL पर लोड में वृद्धि के साथ सहसंबद्ध है। लेकिन हमारे मामले में, सब कुछ अलग दिख रहा था।

MySQL:


अब MySQL और Apache के ग्राफ की तुलना करते हैं:


कुछ स्पष्ट रूप से गलत हो गया। और हमने एक समस्या की तलाश शुरू कर दी।

हमने क्या पाया?

सबसे पहले, हमने एक संशोधित 1MS-बिट्रिक्स सीएमएस कोर पाया, और यह उन हिस्सों में बदल दिया गया था जो कैश के साथ काम करते थे, जिसका अर्थ इसके साथ संभवतः गलत संचालन था। सिद्धांत रूप में, यह कुछ तर्क था - यदि कैश क्रैश हो जाता है और फ्लश हो जाता है, तो इन क्षणों में अपाचे पर वृद्धि होगी। लेकिन तब MySQL में अधिक फट जाना चाहिए था, लेकिन कोई भी नहीं थे।
दूसरे, परिवर्तित सीएमएस कोर के कारण, इस परियोजना को कई वर्षों तक अद्यतन नहीं किया गया है, क्योंकि किसी भी अद्यतन ने साइट को तोड़ दिया।
तीसरा, सर्वर गलत तरीके से कॉन्फ़िगर किया गया था। चूँकि हमारी कहानी रिफैक्टिंग के बारे में है, इसलिए हम इस बिंदु पर विस्तार से ध्यान नहीं देंगे।
चौथा, परियोजना 2005-2006 के आसपास बनाई गई थी और इसकी गणना पूरी तरह से अलग लोड पर की गई थी - जो वर्तमान की तुलना में 10 गुना कम है। परियोजना की वास्तुकला और कोड पूरी तरह से बढ़े हुए लोड के लिए डिज़ाइन नहीं किए गए थे। पुराने लोड के तहत अनुरोध 0.5 - 1 सेकंड की सहनशीलता के भीतर थे, जब नया लोड पहले से ही 4-15 सेकंड था और धीमी लॉग में गिर गया।
और पांचवें रूप से: परियोजना के वर्षों में विभिन्न ठेकेदारों के साथ ग्राहक सहयोग की प्रक्रिया में, इसमें बहुत सारे डुप्लिकेट कोड दिखाई दिए, अतिरिक्त चक्र और एक अकुशल कैश।

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

उन्होंने बाकी सब कैसे तय किया?

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

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

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

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

परिणाम क्या है?

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

परीक्षण के ग्राफ़ पर, आप बाहर से देख सकते हैं कि सिस्टम को रीएक्टेनियरिंग और रीइंजीनियरिंग से पहले एक साथ 25 उपयोगकर्ताओं के लोड के साथ, पेज लगभग 8s लोड करता है, और इसके बाद केवल 4.2s।
करने के लिए:

के बाद:


क्लस्टर के भीतर से परीक्षणों के रेखांकन पर, यह देखा जा सकता है कि, उदाहरण के लिए, मुख्य पृष्ठ 40 के लिए 200,000 आगंतुकों के साथ 40 के लिए लोड किया गया था, और 1.9 लोड करना शुरू कर दिया।
करने के लिए:

के बाद:

हमने अपने डेवलपर्स को किस चीज से प्रसन्न किया है?

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

ताकि हम लेख के अंत में सभी वेब डेवलपर्स को सलाह देना चाहें:

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

नताल्या चिलिकाइना, एडीवी / वेब-इंजीनियरिंग बिट्रिक्स विकास विभाग के प्रमुख