सेवा की क्षमता का मूल्यांकन कैसे करें और लोड के तहत नहीं आते हैं

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

किसी अनुभवी डेवलपर / DevOps / SRE / व्यवस्थापक को प्रश्नों को संबोधित करके विश्लेषणात्मक रूप से उत्तर प्राप्त किए जा सकते हैं। मूल्यांकन की विश्वसनीयता कारकों की एक बड़ी संख्या पर निर्भर करती है: सिस्टम को कार्यक्षमता के साथ भरने की गति से शुरू होता है और घटकों के बीच संबंधों का ग्राफ और उस समय के साथ समाप्त होता है जो विशेषज्ञ ने सुबह यातायात में बिताया था। अधिक जटिल प्रणाली, विश्लेषणात्मक मूल्यांकन की पर्याप्तता में अधिक संदेह है।

मेरा नाम मैक्सिम कुप्रियनोव है, पांच साल से मैं यैंडेक्स.मार्केट में काम कर रहा हूं। आज मैं हबर के पाठकों को बताऊंगा कि हमने अपनी सेवाओं की क्षमता का मूल्यांकन कैसे किया और यह क्या हुआ।

हम स्थिति पर जाते हैं

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

अब इसके बारे में बात करते हैं जिसके बिना उद्देश्य मूल्यांकन का निर्माण असंभव है: सेवा के मीट्रिक के बारे में। यदि सेवा अनुरोधों की संख्या DAU पर निर्भर करती है, तो हमें निश्चित रूप से मीट्रिक "अनुरोध प्रति सेकंड" (अनुरोध प्रति सेकंड, RPS) की आवश्यकता है। इसके अलावा, सेवा की गुणवत्ता का आकलन करने के लिए, आपको त्रुटियों का प्रतिशत और प्रतिक्रिया समय (अनुरोध समय) जानने की आवश्यकता है। त्रुटि को 500 या अधिक के HTTP कोड के साथ प्रतिक्रिया माना जाएगा। 4xx रेंज से त्रुटियां क्लाइंट-साइड हैं और आम तौर पर काम करने वाले सिस्टम में आमतौर पर सेवा समस्याओं के बारे में कुछ नहीं कहा जाता है। समय के अनुसार, यह हमारे लिए प्रतिक्रिया समय के 80 वें, 95 वें, 99 वें और 99.9 वें प्रतिशत पर गणना करने और संग्रहीत करने के लिए प्रथागत है, लेकिन एक विशिष्ट सेट सेवा से सेवा में थोड़ा भिन्न हो सकता है।

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

ठीक है, हमने कार्य पर निर्णय लिया: प्रतिक्रिया समय और त्रुटियों के प्रतिशत को समझौतों के रूप में ठीक करने और अधिकतम आरपीएस प्राप्त करने के लिए जो सिस्टम इन परिस्थितियों में सामना कर सकता है। हम कैसे तय करेंगे?

हमने निशाने पर गोली मारी

यहां समस्या को हल करने के लिए एक क्लासिक दृष्टिकोण है: हम एक परीक्षण साइट एकत्र करते हैं, उत्पादन वातावरण से सिस्टम लॉग का उपयोग करते हैं, उनमें से कारतूस बनाते हैं और सिस्टम को आग लगाते हैं, अनुरोधों की आवृत्ति बढ़ाते हैं, जब तक कि साइट प्रतिक्रिया समय और / या त्रुटियों में महत्वपूर्ण गिरावट नहीं दिखाती है। इस बिंदु पर, हम अनुरोधों की आवृत्ति (बहुत ही आरपीएस) को रोकते हैं और ठीक करते हैं। जीतना? कोई फर्क नहीं पड़ता कि कैसे। और यहाँ क्यों है:

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

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

वास्तविकता का अनुकरण करें

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

• बाहरी घटकों के साथ बातचीत करने की समस्या हल नहीं होती है, क्योंकि यह पूरे उत्पादन वातावरण की एक प्रति बनाने के लिए बहुत महंगा है;
• दर्पण प्रणाली से अनुरोध लॉग गलती से उत्पादन वातावरण से लॉग के साथ मिश्रण कर सकते हैं, जिसका अर्थ है कि दर्पण यातायात के अंकन के साथ एक प्रणाली का निर्माण करना आवश्यक है ताकि इसे तब पाया और साफ किया जा सके;
• अनुरोधों को आम तौर पर या तो पूर्ण रूप में या कुल के प्रतिशत के रूप में दिखाया जाता है, और ऐसी सटीकता हमें शोभा नहीं देती है (लेकिन इसे हल किया जा सकता है, हम इस दिशा में काम कर रहे हैं)।

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

उत्पादन में सीधे परीक्षण

और फिर हम अंत में स्वादिष्ट हो गए। प्रत्येक परीक्षण किए गए घटक के लिए, हम उत्पादन में एक अलग उदाहरण जुटाते हैं, जिसके लिए अनुरोधों की आवृत्ति को उच्च सटीकता के साथ बैलेंसर से विनियमित किया जाता है। पिछली बार, पाठकों ने हमसे पूछा : "क्या आपके लिए HAProxy पर्याप्त है? क्या अपना खुद का कुछ लिखने की ज़रूरत थी? ” इसलिए, यह बहुत ही दुर्लभ मामला है जब यह पर्याप्त नहीं था और मुझे लिखना था।

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

आइए रेखांकन देखें

यह है कि हम परीक्षण किए गए उदाहरण के लिए यातायात के प्रवाह को कैसे नियंत्रित करते हैं। चरण 1 आरपीएस के किसी भी एकाधिक हो सकता है। चित्रण के लिए, चित्रण के लिए, हमने तीन मिनट के अंतराल के साथ चढ़ाई की: पहले, 650 से 1K RPS तक 50 की वेतन वृद्धि में, और फिर 200 से 1K RPS में 100 की वृद्धि में। आइए आपको याद दिलाता हूं, यह वास्तविक उपयोगकर्ता ट्रैफ़िक है जिसका ग्राहकों को जवाब मिला।



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



सेवा अनुरोधों की आवृत्ति और लोड जो एक उदाहरण का सामना कर सकते हैं स्पष्ट रूप से दिखाई दे रहे हैं।



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

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

Refleksiruem

यह पद्धति बाजार में एक वर्ष से अधिक समय से काम नहीं कर रही है, और हम टिप्पणियों और सिफारिशों को साझा कर सकते हैं:

• लोड किए गए उदाहरण के आगे, एक सामान्य नियंत्रण होना चाहिए, और अधिमानतः भाप, क्योंकि गिरावट अक्सर होती है क्योंकि उदाहरण अतिभारित नहीं होता है, लेकिन समग्र रूप से सेवा के साथ सामान्य समस्याओं के कारण।
• तकनीक केवल उन घटकों के साथ अच्छी तरह से काम करती है जिनका लोड किसी स्थान के लिए प्रति सेकंड सैकड़ों अनुरोधों से अधिक है। कारण काफी सरल है: हमें परीक्षण किए गए उदाहरण और एक या दो नियंत्रण वाले दोनों को लोड करने की आवश्यकता है। यदि पर्याप्त यातायात नहीं है, तो हम संतृप्ति तक नहीं पहुंचेंगे या हम ईमानदारी से तुलना करने में सक्षम नहीं होंगे। और यदि प्रति उदाहरण RPS की सीमा बहुत छोटी है, तो अनुरोध आवृत्ति को 1 RPS में बदलने का न्यूनतम चरण बहुत अधिक मोटा हो सकता है।
• विभिन्न स्थानों पर मोर्चों और बैकेंड्स का परीक्षण करना बेहतर है, ताकि लोड परीक्षण बैकेंड की कलाकृतियां सामने की क्षमता के अनुमान को प्रभावित न करें।
• जब हम प्रतिक्रिया समय का विश्लेषण करते हैं और गिरावट के संकेतों की तलाश करते हैं, तो हम आम तौर पर पांच मिनट समुच्चय लेते हैं और माध्यिका की गिनती करते हैं ताकि यादृच्छिक फटने पर प्रतिक्रिया न करें।
• मुख्य कारण सेवा क्रैश का लोड किया गया उदाहरण लॉग फ़ाइलों (लॉग) के लिए डिस्क स्थान है। वे हमेशा उसके बारे में भूल जाते हैं।
• वेब-सर्वरों की I / O- भरी हुई डिस्क पर लॉगिंग SSDs पर भी समय बिगड़ने का एक बहुत ही सामान्य कारण है। हमेशा बफ़रिंग, एसिंक्रोनस रिकॉर्डिंग, और कुछ भी चालू करें, बस रिकॉर्डिंग समाप्त होने तक प्रतीक्षा न करें।
• रात्रि भार सांकेतिक नहीं है, क्योंकि रोबोट के बड़े हिस्से के कारण अनुरोध औसत रूप से भारी हैं। इसलिए, क्षमता का अनुमान लगाने के लिए, दिन के पारंपरिक हल्के समय से रेंज को ठीक करना बेहतर है, और रात में केवल अनुरोधों के प्रवाह को कम करने के लिए यदि गिरावट के संकेत दिखाई देते हैं।
• प्रतिक्रिया समय का 99.9 वां प्रतिशत क्षमता अनुमान के लिए बेकार है, क्योंकि नेटवर्क उपलब्धता की गारंटी शायद ही कभी 99% से अधिक हो।
• एक टाइमलाइन और रिकॉर्ड सर्विस रिलीज़ और अन्य महत्वपूर्ण घटनाओं को शुरू करें। यह खोजने में मदद करता है कि क्षमता में कमी के कारण क्या हुआ।
• गिरावट के कारणों के विस्तृत विश्लेषण में, अनुरेखण भी उपयोगी है: प्रत्येक सेवा अनुरोध में एक मार्कर हेडर जोड़ा जाता है, जो सामने से अंतिम बैकेंड तक जाता है और सभी लॉग में प्रवेश करता है। इस तरह आप पूरे अनुरोध पथ का पता लगा सकते हैं और समझ सकते हैं कि क्या देरी होती है।