वेब अनुप्रयोग सर्वर अनुकूलन पाठ

नमस्कार, हेब्र! मेरा नाम एलेक्सी प्रिस्टावको है, मैं डेटालाइन पर वेब परियोजनाओं का निदेशक हूं। मेरा लेख आज वेब एप्लिकेशन बैकएंड प्रदर्शन समस्याओं को ठीक करने या रोकने के बारे में है।

यह उन वेब अनुप्रयोगों को अनुकूलित करने पर ध्यान केंद्रित करेगा जो स्केलेबिलिटी, प्रदर्शन या विश्वसनीयता के साथ पुरानी समस्याओं से ग्रस्त हैं।
किसी को भी दिलचस्पी - कटौती के तहत आपका स्वागत है!

शब्दावली

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

• आवेदन प्रदर्शन का माप प्रति सेकंड (आरपीएस) और उनके निष्पादन की गति (टीटीएफबी - टाइम टू फर्स्ट टीएस) प्रति संसाधित अनुरोधों की संख्या होगी।
  
• तदनुसार, सिस्टम स्केलेबिलिटी से हमारा मतलब है आरपीएस बढ़ाने के अवसरों का एक पूल।
  

अब विश्वसनीयता के बारे में। यहां दो अवधारणाओं को अलग करना आवश्यक है: गलती सहिष्णुता और आपदा सहिष्णुता।

• विफलता लचीलापन - एक प्रणाली की क्षमता यदि एक या अधिक सर्वर आवश्यक मापदंडों के भीतर काम करना जारी रखने में विफल रहती है।
  
• पूर्ण बैकअप अतिरेक (तथाकथित दूसरे कंधे) के साथ सिस्टम और डेटा केंद्रों में से एक की पूरी विफलता के साथ मजबूत ड्रॉडाउन के बिना काम करने में सक्षम आपदा-प्रतिरोधी माना जाता है ।
  

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

अब जब हमने प्रमुख अवधारणाओं का पता लगा लिया है और वर्तमान शब्दावली को ताज़ा कर दिया है, तो यह अनुकूलन और जीवन हैक की मूल बातें पर सीधे जाने का समय है।

अनुकूलन कहाँ से शुरू करें

कैसे समझें कि अनुकूलन कहाँ से शुरू करें? अनुकूलन करने के लिए दौड़ने से पहले, एक गहरी साँस लें और आवेदन पर शोध करने में समय व्यतीत करें।

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

"क्या? कहाँ? कब? ” - प्रश्नों का अनुकूलन करें

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

आपके अनुरोधों को ट्रैक करने में मदद करने के लिए यहां कुछ तरकीबें दी गई हैं:

• प्रत्येक आने वाले अनुरोध के लिए एक अद्वितीय पहचानकर्ता असाइन करें। इसके लिए Nginx में एक अंतर्निर्मित चर $ request_id है। बैक-एंड पर हेडर में पहचानकर्ता पास करें और सभी लॉग्स पर लिखें। तो आप आसानी से अनुरोधों का पता लगा सकते हैं।
• लॉग न केवल बाहरी घटक के लिए अनुरोध का अंत, बल्कि इसकी शुरुआत भी। तो आप बाहरी कॉल की वास्तविक अवधि को मापते हैं। यह दूरस्थ प्रणाली पर आपके द्वारा देखी जाने वाली चीजों से काफी भिन्न हो सकता है, उदाहरण के लिए, नेटवर्क समस्याओं या DNS ब्रेक के कारण।

तो, डेटा एकत्र किया जाता है। अब समस्या अंक का विश्लेषण करते हैं। निर्धारित करें:

• सबसे अधिक समय कहाँ बिताया जाता है?
• सबसे अनुरोध कहां से आते हैं?
• सबसे लंबे अनुरोध कहां से आते हैं?

नतीजतन, आपको अनुकूलन के लिए सिस्टम के सबसे दिलचस्प वर्गों की एक सूची मिलेगी।

युक्ति: यदि कोई बिंदु बहुत सारे छोटे प्रश्नों को "एकत्रित" करता है, तो उन्हें ओवरहेड को कम करने के लिए एक बड़ी क्वेरी में संयोजित करने का प्रयास करें। लंबे प्रश्नों के परिणाम अक्सर कैश में समझ में आते हैं।

हम समझदारी से कैश करते हैं

सामान्य कैशिंग नियम हैं जिनका आपको अनुकूलन करते समय भरोसा करना चाहिए:

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

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

टिप 1: एज साइड का उपयोग करके Nginx पक्ष पर तैयार पृष्ठ के घटक कैशिंग करें। यह microservice / SOA वास्तुकला के साथ अच्छी तरह से फिट बैठता है और सिस्टम को पूरी तरह से लोड करता है, प्रतिक्रिया की गति में बहुत सुधार करता है।

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

टिप 3: जहां संभव हो, अपने स्वयं के डेटाबेस कैश का उपयोग करें। उचित विन्यास कार्य को गति दे सकता है।

प्रोफाइल लोड करें

हम प्रोफाइल लोड करने के लिए पास करते हैं। जैसा कि आप जानते हैं, दो मुख्य प्रकार हैं: OLAP और OLTP।

• OLAP (ऑनलाइन विश्लेषणात्मक प्रसंस्करण) के लिए, प्रति सेकंड खर्च किए गए ट्रैफ़िक की मात्रा महत्वपूर्ण है।
  
• OLTP (ऑनलाइन लेन-देन प्रसंस्करण) के लिए, प्रमुख संकेतक प्रतिक्रिया गति, मिलीसेकंड समय है।
  

सबसे अधिक बार, इन दो प्रकार के भार को अलग करना प्रभावी है। कम से कम, आपको डेटाबेस के अलग ट्यूनिंग की आवश्यकता होगी और, संभवतः, सिस्टम के अन्य घटकों को।

युक्ति: व्यवस्थापक पैनल से अनुरोध पढ़ें आमतौर पर OLAP प्रकार का उपयोग करके संसाधित किया जाता है। मुख्य कार्य को बंद करने के लिए इस कार्य के लिए डेटाबेस और एक वेब सर्वर की एक अलग प्रतिलिपि बनाएँ।

डेटाबेस

इसलिए, हमने स्वाभाविक रूप से अनुकूलन के सबसे कठिन चरणों में से एक से संपर्क किया - अर्थात्, डेटाबेस अनुकूलन।

मुझे आपको सामान्य नियम याद दिलाना है: डेटाबेस जितना छोटा होगा, उतनी ही तेजी से काम करेगा। डेटाबेस का बहुत संगठन महत्वपूर्ण है जब यह गति के लिए आता है।

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

और फिर से योजना के महत्व के बारे में

अनुकूलन पर पहेली न लगाने के लिए जहां इसकी वास्तव में जरूरत नहीं है, कार्यों के आधार पर हार्डवेयर चुनें।

• छोटे, लेकिन लगातार अनुरोधों के लिए, अधिक प्रोसेसर कोर लेना बेहतर है।
• भारी अनुरोधों के लिए - एक उच्च घड़ी की गति के साथ कम कोर।

डेटाबेस की कार्यशील मात्रा को RAM में रखने का प्रयास करें। यदि यह संभव नहीं है या बड़ी संख्या में लिखित अनुरोध हैं, तो डेटाबेस को एसएसडी में स्थानांतरित करने की ओर देखने का समय है। वे डिस्क के साथ काम करने की गति में उल्लेखनीय वृद्धि देंगे।

स्केलिंग

ऊपर, मैंने इसके भौतिक संसाधनों में वृद्धि के बिना आवेदन प्रदर्शन में सुधार के प्रमुख यांत्रिकी का वर्णन किया।

अब हम इस बारे में बात करेंगे कि स्केलिंग रणनीति का चयन कैसे करें और लचीलापन बढ़ाएं।

सिस्टम स्केलिंग के दो प्रकार हैं:

• ऊर्ध्वाधर - संस्थाओं की संख्या को बनाए रखते हुए संसाधनों की वृद्धि;
  
• क्षैतिज - संस्थाओं की संख्या में वृद्धि।
  

लंबा हो जाना

चलो एक ऊर्ध्वाधर स्केलिंग रणनीति चुनकर शुरू करते हैं।

सबसे पहले, सिस्टम पावर में वृद्धि पर विचार करें। यदि आपका सिस्टम एक सर्वर के भीतर काम करता है, तो आपको वर्तमान सर्वर की क्षमता बढ़ाने या किसी अन्य को खरीदने के बीच चयन करना होगा।

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

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

चौड़ी हो जाना

क्षैतिज स्केलिंग गलती सहिष्णुता और क्लस्टरिंग के बारे में एक कहानी है। सामान्य मामले में, हमारे पास एक इकाई के जितने अधिक उदाहरण हैं, पूरे समाधान की दोष सहिष्णुता उतनी ही अधिक है।

संभवतः पहली चीज जिसे आप स्केल करना चाहते हैं, वह एप्लिकेशन सर्वर है । इसके लिए पहली बाधा केंद्रीयकृत डेटा स्रोतों के साथ काम का संगठन है। डेटाबेस के अलावा, यह सत्र डेटा और स्थिर सामग्री भी है। यहाँ मैं आपको क्या करने की सलाह देता हूं:

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

"पुलिंग" डेटाबेस

डेटाबेस को स्केल करना मुश्किल है। इसके लिए दो मुख्य तकनीकें हैं: पैनापन और प्रतिकृति। उन पर विचार करें।

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

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

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

युक्ति: यदि आपके मामले में कई मास्टर सर्वर के लिए तर्कसंगत नहीं है, तो कम से कम एक घंटे के लिए मास्टर के बिना काम करने वाले सिस्टम की वास्तु संभावना पर विचार करें। दुर्घटना की स्थिति में, यह आपको पूरे सिस्टम के डाउनटाइम के बिना सर्वर को बदलने का समय देगा।

युक्ति: यदि आपको 2 से अधिक डेटाबेस मास्टर्स रखने की आवश्यकता है, तो मेरा सुझाव है कि आप NoSQL समाधानों पर विचार करें, क्योंकि उनमें से कई में एक सुसंगत स्थिति में डेटा लाने के लिए अंतर्निहित तंत्र हैं।

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

याद रखें: किसी भी महत्वपूर्ण डेटा को एक स्वतंत्र, गैर-संपादन योग्य प्रतिलिपि के रूप में बैकअप और संग्रहीत किया जाना चाहिए।

एक निष्कर्ष के बजाय

अंत में, बैक अप के लिए प्रदर्शन युक्तियों के एक जोड़े:

टिप 1: एक अलग डेटाबेस प्रतिकृति से डेटा खींचो ताकि आप सक्रिय सर्वर को अधिभार न डालें।

टिप 2: डेटाबेस के समय प्रतिकृति में एक अतिरिक्त, थोड़ा "लैगिंग" हाथ में है। दुर्घटना की स्थिति में, यह खोए हुए डेटा की मात्रा को कम करने में मदद करेगा।

इस स्थिति में प्रस्तुत किए गए तरीकों और तकनीकों को कभी भी आँख बंद करके उपयोग नहीं किया जाना चाहिए, बिना मौजूदा स्थिति का विश्लेषण किए और समझे कि आप क्या हासिल करना चाहते हैं। आप "अति-अनुकूलन" का सामना कर सकते हैं, और परिणामी प्रणाली केवल 10% तेज होगी, लेकिन दुर्घटनाओं के लिए 50% अधिक कमजोर।

वह सब है। यदि आपके कोई प्रश्न हैं, तो मुझे टिप्पणियों में उनका उत्तर देने में खुशी होगी।