अपने सेवकों को मारने के 6 तरीके - स्कैलेबिलिटी को जानना कठिन तरीका है

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



कुछ साल पहले मेरे बॉस मेरे पास आए और कहा: “हमारे पास आपके लिए एक नया प्रोजेक्ट है। यह एक साइट स्थानांतरण है जिसमें पहले से ही प्रति माह 1 मिलियन आगंतुक हैं। आपको इसे स्थानांतरित करने और यह सुनिश्चित करने की आवश्यकता है कि भविष्य में उपस्थिति बिना किसी समस्या के बढ़ सकती है। ”मैं पहले से ही एक अनुभवी प्रोग्रामर था, लेकिन स्केलेबिलिटी के क्षेत्र में कोई अनुभव नहीं था। और मुझे स्केलेबिलिटी को कठिन तरीके से सीखना था।



साइट सॉफ्टवेयर PHP में MySQL और स्मार्टी का उपयोग कर एक CMS था। पहला कदम एक होस्टिंग कंपनी की तलाश करना था जिसे अत्यधिक भरी हुई परियोजनाओं में अनुभव था। हमने उन्हें अपना आवश्यक कॉन्फ़िगरेशन प्रदान किया:

• लोड संतुलन (मार्जिन के साथ)
• 2 वेब सर्वर
• MySQL सर्वर (एक मार्जिन के साथ)
• विकास मशीन

हमें क्या मिला (होस्टर ने कहा कि यह पर्याप्त होगा):

• लोड बैलेंसिंग - सिंगल कोर, 1 जीबी रैम, पाउंड
• 2 वेब सर्वर - डुअल कोर, 4 जीबी रैम, अपाचे
• MySQL सर्वर - क्वाड कोर, 8 जीबी रैम
• विकास मशीन - सिंगल कोर, 1 जीबी रैम

फ़ाइलों को सिंक्रनाइज़ करने के लिए, होस्टर ने सक्रिय-सक्रिय कॉन्फ़िगरेशन में DRBD स्थापित किया।



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



फिर फोन अप्रत्याशित रूप से शुरू हुआ: "हम वेबसाइट तक नहीं पहुंच सकते, क्या हो रहा है?" हमने अपने मॉनिटरिंग सॉफ्टवेयर को देखा और देखा कि सर्वर क्रैश हो गए थे और साइट डाउन हो गई थी। बेशक, पहली चीज़ जो हमने होस्ट की थी उसे कॉल किया और कहा: “हमारे सभी सर्वर क्रैश हो गए हैं। क्या हो रहा है? ”उन्होंने सर्वर की जाँच करने और उसके बाद वापस बुलाने का वादा किया। कुछ समय बाद, उन्होंने फोन किया: “आपकी फ़ाइल प्रणाली निराशाजनक रूप से दूषित है। आप क्या कर रहे थे? ”उन्होंने बैलेंसर बंद किया और मुझे एक वेब सर्वर को देखने के लिए कहा। Index.php को खोलकर, मैं हैरान था। इसमें C कोड, त्रुटि संदेश, और लॉग फ़ाइलों के समान कुछ समझ से बाहर के टुकड़े शामिल थे। थोड़ी जांच के बाद, हमने पाया कि इसका कारण हमारा DRBD था।

पाठ संख्या १

स्मार्ट कैश को उच्च लोड के तहत एक सक्रिय-सक्रिय DRBD क्लस्टर में रखें और आपकी साइट क्रैश हो जाएगी।



जब होस्टर वेब सर्वर को पुनर्प्राप्त कर रहा था, मैंने सीएमएस के हिस्से को फिर से लिखा, ताकि स्मार्टी कैश फाइलें स्थानीय फ़ाइल सिस्टम पर संग्रहीत की गईं। समस्या पाई गई और ठीक हो गई और हम ऑनलाइन लौट आए।



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



हमारा मुवक्किल नसों पर था, लेकिन वह समझ गया था कि चलने से आमतौर पर कुछ समस्याएं आती हैं।



हमें किसी तरह लोड कम करने की जरूरत थी और हमने इस पर हॉस्टल के साथ चर्चा की। उनके एक प्रशंसक ने एक अच्छा विचार सुझाया: “आपके सर्वर अब Apache + mod_php पर हैं। लाइटटैप में अनुवाद कर सकते हैं? यह एक छोटी परियोजना है, लेकिन विकिपीडिया भी इसका उपयोग करता है। ”हम सहमत हुए।

पाठ संख्या २

अपने सर्वर पर वेब सर्वर "बॉक्स से बाहर" स्थापित करें, कुछ भी कॉन्फ़िगर न करें और आपकी साइट गिर जाएगी।



प्रशासक ने हमारे सर्वरों को जितनी जल्दी हो सके उतने तेजी से फिर से जोड़ा। उन्होंने अपाचे को छोड़ दिया और लाइटटैप + फास्टसीजीआई + एक्सचे कॉन्फ़िगरेशन पर स्विच कर दिया। इस बार कितने सर्वर बढ़ाए जाएंगे?



हैरानी की बात है कि सर्वर ने अच्छा काम किया। लोड पहले की तुलना में काफी कम था, और औसत प्रतिक्रिया समय अच्छा था। उसके बाद, हमने घर जाने और आराम करने का फैसला किया - यह बहुत देर हो चुकी थी और हम सहमत थे कि अब तक हमारे पास करने के लिए अधिक कुछ नहीं है।



बाद के दिनों में, सर्वरों ने लोड को अपेक्षाकृत अच्छी तरह से नियंत्रित किया, लेकिन चरम समय पर वे गिरने के करीब थे। हमने पाया कि MySQL अड़चन थी और फिर से होस्टर को बुलाया। उन्होंने प्रत्येक वेब सर्वर पर दास के साथ मास्टर-गुलाम MySQL प्रतिकृति की सलाह दी।

पाठ संख्या 3

यहां तक ​​कि एक उत्पादक डेटाबेस सर्वर की सीमाएं हैं - और जब वे पहुंच जाते हैं, तो आपकी साइट क्रैश हो जाएगी।



इस समस्या को ठीक करना इतना आसान नहीं था। सीएमएस इस संबंध में बहुत सरल था और इसमें SQL प्रश्नों को विभाजित करने की अंतर्निहित क्षमता नहीं थी। इसके संशोधन में कुछ समय लगा, लेकिन परिणाम सार्थक रहा।



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

पाठ संख्या ४

आगे की योजना न बनाएं और आपकी साइट जल्द या बाद में गिर जाएगी।



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

पाठ संख्या ५

कुछ भी कैश न करें और नए हार्डवेयर पर पैसा खर्च करें या आपकी साइट गिर जाएगी।



MemCached ने हमें MySQL पर 70-80% तक लोड कम करने में मदद की, जिससे प्रदर्शन में भारी वृद्धि हुई। पेज और भी तेजी से लोड हुआ।



अंत में, हमारा कॉन्फ़िगरेशन सही लग रहा था। यहां तक ​​कि चरम समय पर, हमें संभावित गिरावट या लंबी प्रतिक्रिया समय के बारे में चिंता करने की ज़रूरत नहीं थी। लेकिन अचानक, वेब सर्वरों में से एक ने हमें समस्याएं - त्रुटि संदेश, रिक्त पृष्ठ आदि लाने के लिए शुरू किया। लोड के साथ सब कुछ ठीक था, और ज्यादातर मामलों में सर्वर ने ठीक काम किया, लेकिन केवल "अधिकांश मामलों" में।

पाठ संख्या ६

एक निर्देशिका में कई सौ छोटी फाइलें रखो, इनोड के बारे में भूल जाओ और आपकी साइट गिर जाएगी।



हाँ यह है हम MySQL, PHP और वेब सर्वर को अनुकूलित करने में इतने व्यस्त थे कि हमने फाइल सिस्टम पर पर्याप्त ध्यान नहीं दिया। स्मार्ट स्मार्ट कैश स्थानीय FS में एक निर्देशिका में संग्रहीत किया गया था। समाधान था कि रेसीएफएस के साथ स्मार्टी को एक अलग विभाजन में स्थानांतरित करना। हमने Smarty 'use_subdirs' विकल्प भी शामिल किया है।



अगले वर्षों में, हमने अनुकूलन जारी रखा। हमने स्मार्ट कैश को मेमेकैड में रखा, I / O सिस्टम पर लोड को कम करने के लिए वार्निश स्थापित किया, Nginx पर स्विच किया (लाइटटैप्ड ने यादृच्छिक रूप से 500 की त्रुटि उत्पन्न की), सबसे अच्छा हार्डवेयर खरीदा, और इसी तरह।

निष्कर्ष

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



उच्च प्रदर्शन ब्लॉग के लेखक - स्टीफन कोनेरो के बारे में।