अमेज़न वेब सेवाएँ होस्ट वेब अनुप्रयोग क्लस्टरिंग

अत्यधिक भरी हुई एप्लिकेशन का विषय सभी की सुनवाई में है। उन्होंने AWS इन्फ्रास्ट्रक्चर पर एक अत्यधिक लोड किए गए एप्लिकेशन को बनाने के लिए अपने 5 kopecks सम्मिलित करने और अपने अनुभव को साझा करने का निर्णय लिया।


सबसे पहले, मैं भोज करूंगा और अच्छी तरह से ज्ञात सत्य दोहराऊंगा। आवेदन को स्केल करने के 2 तरीके हैं:
1) ऊर्ध्वाधर स्केलिंग सिस्टम के प्रत्येक घटक (प्रोसेसर, रैम, अन्य घटकों) के प्रदर्शन में वृद्धि है;
2) क्षैतिज, जब कई तत्व एक साथ जुड़े होते हैं, और एक पूरे के रूप में सिस्टम में कई कंप्यूटिंग नोड होते हैं जो सामान्य समस्या को हल करते हैं, जिससे सिस्टम की समग्र विश्वसनीयता और उपलब्धता बढ़ जाती है। और सिस्टम में अतिरिक्त नोड्स जोड़कर उत्पादकता में वृद्धि हासिल की जाती है।

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

हाल ही में, हमने एक बार फिर अभ्यास में क्षैतिज स्केलिंग के सभी आयामों को समझ लिया: हमने अमेरिकी फुटबॉल के प्रशंसकों के लिए एक अत्यधिक विश्वसनीय सामाजिक सेवा का निर्माण किया, जिसमें प्रति मिनट 200,000 अनुरोधों के शिखर भार को समझा गया। इसलिए, मैं अमेज़ॅन वेब सर्विसेज इन्फ्रास्ट्रक्चर पर एक उच्च स्केलेबल सिस्टम बनाने के हमारे अनुभव के बारे में बात करना चाहता हूं।

आमतौर पर, एक वेब अनुप्रयोग वास्तुकला इस प्रकार है:

अंजीर। 1. विशिष्ट वेब अनुप्रयोग वास्तुकला

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

सबसे अधिक बार, सिस्टम की अड़चनें आवेदन कोड और डेटाबेस हैं, इसलिए, यह उनके समानांतर होने की संभावना पर विचार करने योग्य है। हमने उपयोग किया:

• विकास भाषा और मुख्य ढांचा - जावा 7 और बाकी जर्सी
• आवेदन सर्वर - tomcat 7
• डेटाबेस - MongoDB (NoSQL)
• कैश सिस्टम - memcached

यह कैसा था, या कांटों के माध्यम से उच्च भार तक

चरण एक: विभाजित और जीतें

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

• एप्लिकेशन सर्वर
• डेटाबेस सर्वर
• स्थैतिक संसाधनों के साथ सर्वर।

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

एप्लिकेशन सर्वर

प्रोसेसर कोर की सबसे बड़ी संख्या (समवर्ती उपयोगकर्ताओं की एक बड़ी संख्या की सेवा) के साथ सर्वर के लिए एक आवेदन सबसे उपयुक्त है। अमेज़ॅन कंप्यूटर अनुकूलित उदाहरणों का एक सेट प्रदान करता है जो इन उद्देश्यों के लिए सबसे उपयुक्त हैं।

डेटाबेस सर्वर

डेटाबेस का काम क्या है? - कई डिस्क I / O ऑपरेशन (डेटा लिखना और पढ़ना)। यहां सबसे तेज हार्ड ड्राइव (उदाहरण के लिए, एसएसडी) वाला सर्वर सबसे अच्छा विकल्प होगा। और फिर, अमेज़ॅन कोशिश करने के लिए खुश है और हमें स्टोरेज ऑप्टिमाइज्ड इंस्टेंस प्रदान करता है, लेकिन सामान्य प्रयोजन (बड़ी या xlarge) लाइन से सर्वर भी उपयुक्त है, क्योंकि भविष्य में मैं उन्हें स्केल करने जा रहा हूं।

स्थैतिक संसाधन

स्थिर संसाधनों के लिए, न तो एक शक्तिशाली प्रोसेसर और न ही बड़ी मात्रा में रैम की आवश्यकता होती है, यहां विकल्प अमेज़ॅन सरल भंडारण सेवा स्थिर संसाधन सेवा पर पड़ता है।

एप्लिकेशन को विभाजित करने के बाद, मैं इसे अंजीर में दिखाए गए सर्किट में लाया। 1।
साझा करने के लाभ:

• सिस्टम का प्रत्येक तत्व मशीन पर काम करता है जितना संभव हो उसकी आवश्यकताओं के अनुकूल;
• डेटाबेस को क्लस्टर करने का एक अवसर है;
• आप कमजोरियों का पता लगाने के लिए सिस्टम के विभिन्न तत्वों का अलग-अलग परीक्षण कर सकते हैं।

लेकिन आवेदन अभी भी गैर-संकुलित है, कैश सर्वर और सत्र प्रतिकृति भी नहीं हैं।

चरण दो: प्रयोग

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

तीन चरण: लोड संतुलन

तो, प्रयोगों से पता चला कि परिणामी प्रदर्शन अभी भी पर्याप्त नहीं है, और एप्लिकेशन वाला सर्वर 100% लोड किया गया था (विकसित एप्लिकेशन का कोड कमजोर लिंक निकला)। मैं समानांतर करता हूं। 2 नए तत्वों को खेल में पेश किया गया है:

• लोड करने वाला
• सत्र सर्वर

लोड संतुलन

जैसा कि यह निकला, विकसित एप्लिकेशन इसे सौंपे गए लोड के साथ सामना नहीं करता है, इसलिए, लोड को कई सर्वरों के बीच विभाजित किया जाना चाहिए।

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

इसलिए, आवेदन के साथ पहले से मौजूद दो सर्वरों के साथ काम करने के लिए बैलेंसर को कॉन्फ़िगर करने के बाद, मैं बैलेंसर के माध्यम से काम करने के लिए डीएनएस को कॉन्फ़िगर करता हूं।

सत्र प्रतिकृति

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

अब सिस्टम इस प्रकार दिखता है (योजना को सरल बनाने के लिए स्थैतिक सर्वर को छोड़ा गया है):

अंजीर। 2. आवेदन क्लस्टरिंग के बाद सिस्टम दृश्य

आवेदन क्लस्टरिंग परिणाम:

• सिस्टम की विश्वसनीयता बढ़ी। एप्लिकेशन के साथ सर्वरों में से एक की विफलता के बाद भी, बैलेंसर इसे मेलिंग सूची से बाहर कर देता है, और सिस्टम कार्य करना जारी रखता है;
• सिस्टम के प्रदर्शन को बढ़ाने के लिए, आपको केवल एप्लिकेशन के साथ एक और कंप्यूटिंग नोड जोड़ना होगा;
• अतिरिक्त नोड्स जोड़कर, हम प्रति मिनट 70,000 अनुरोधों के चरम प्रदर्शन को प्राप्त करने में सक्षम थे।

एप्लिकेशन के साथ सर्वर की बढ़ती संख्या के साथ, डेटाबेस पर लोड भी बढ़ जाता है, जिसे वह समय के साथ सामना नहीं कर पाएगा। डेटाबेस पर लोड को कम करना आवश्यक है।

चरण 4: डेटाबेस के साथ काम का अनुकूलन

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

कैशिंग

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

DB प्रतिकृति

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


अंजीर। पढ़ने के लिए 3 डीबी क्लस्टरिंग

अंतिम: प्रति मिनट 200K अनुरोध

काम के परिणामस्वरूप, हमने वह हासिल किया जो हम चाहते थे: सिस्टम प्रति मिनट 200,000 अनुरोधों को संसाधित करता है।