सामान्य ऑटोस्केलिंग पैटर्न
इस इकाई में, हम ऑटोस्केलिंग के पैटर्न को देखते हैं।
ऑटोस्केलिंग एक त्वरित समाधान नहीं है। बस किसी सिस्टम में संसाधन जोड़ना या किसी प्रक्रिया के अधिक इंस्टेंस चलाना सिस्टम के लिए बेहतर प्रदर्शन की गारंटी नहीं देता है। ऑटोस्केलिंग रणनीति तैयार करते समय निम्नलिखित बिंदुओं पर विचार करें:
सिफारिशों
बाधाओं की पहचान करें: स्केलिंग आउट हर प्रदर्शन समस्या के लिए एक जादू फिक्स नहीं है। उदाहरण के लिए, यदि आपका बैकएंड डेटाबेस अड़चन है, तो यह अधिक वेब सर्वर जोड़ने में मदद नहीं करता है। समस्या पर अधिक उदाहरण फेंकने से पहले सिस्टम में बाधाओं को पहचानें और हल करें। सिस्टम के स्टेटफुल हिस्से बाधाओं का सबसे संभावित कारण हैं।
स्केलेबिलिटी आवश्यकताओं द्वारा वर्कलोड को विघटित करें: अनुप्रयोगों में अक्सर स्केलिंग के लिए विभिन्न आवश्यकताओं के साथ कई वर्कलोड होते हैं। उदाहरण के लिए, किसी अनुप्रयोग में पब्लिक-फ़ेसिंग साइट और एक अलग व्यवस्थापन साइट हो सकती है. सार्वजनिक साइट पर ट्रैफ़िक में अचानक उछाल आ सकता है, जबकि व्यवस्थापन साइट का भार छोटा, अधिक पूर्वानुमानित होता है.
संसाधन-गहन कार्यों कोऑफ़लोड करें: जिन कार्यों के लिए कई CPU या I/O संसाधनों की आवश्यकता होती है, उन्हें संभव होने पर पृष्ठभूमि कार्यों में ले जाया जाना चाहिए। ऑफलोडिंग कार्य सामने के छोर पर लोड को कम करता है जो उपयोगकर्ता अनुरोधों को संभाल रहा है।
अंतर्निहित ऑटोस्केलिंग सुविधाओं का उपयोग करें: यदि एप्लिकेशन में अनुमानित, नियमित कार्यभार है, तो शेड्यूल पर स्केल आउट करें। उदाहरण के लिए, व्यावसायिक घंटों के दौरान स्केल आउट करें। अन्यथा, यदि कार्यभार अनुमानित नहीं है, तो ऑटोस्केलिंग को ट्रिगर करने के लिए CPU या अनुरोध कतार लंबाई जैसे प्रदर्शन मीट्रिक का उपयोग करें।
महत्वपूर्ण कार्यभार के लिए आक्रामक ऑटोस्केलिंग पर विचार करें: महत्वपूर्ण कार्यभार के लिए, आप मांग से आगे रहना चाहते हैं। अन्य ट्रैफ़िक को संभालने के लिए भारी भार के तहत नए उदाहरणों को जल्दी से जोड़ना बेहतर है, और फिर धीरे-धीरे वापस स्केल करें।
में पैमाने के लिए डिजाइन: याद रखें कि लोचदार पैमाने के साथ, आवेदन में पैमाने की अवधि होती है, जब उदाहरण हटा दिए जाते हैं। एप्लिकेशन को हटाए जा रहे उदाहरणों को इनायत से संभालना चाहिए। स्केल-इन को संभालने के कुछ तरीके यहां दिए गए हैं:
- शटडाउन घटनाओं के लिए सुनें जब वे उपलब्ध हों और सफाई से बंद करें।
- क्षणिक गलती से निपटने का समर्थन करें और पुनः प्रयास करें।
- लंबे समय तक चलने वाले कार्यों के लिए काम को तोड़ने पर विचार करें।
- कार्य आइटम्स को कतार में रखें ताकि यदि कोई आवृत्ति संसाधन के बीच में निकाल दी जाती है तो कोई अन्य आवृत्ति कार्य को उठा सके.
सूचनाएँ
- सभी autoscale विफलताओं गतिविधि लॉग करने के लिए लॉग ऑन हैं। फिर आप एक गतिविधि-लॉग चेतावनी कॉन्फ़िगर कर सकते हैं जो आपको ईमेल, लघु संदेश सेवा (एसएमएस), या वेबहुक के माध्यम से सूचित करता है जब भी कोई ऑटोस्केल विफलता होती है।
- इसी तरह, सभी सफल स्केल क्रियाएँ गतिविधि लॉग में पोस्ट की जाती हैं। फिर आप एक गतिविधि-लॉग अलर्ट कॉन्फ़िगर कर सकते हैं ताकि जब भी कोई सफल ऑटोस्केल कार्रवाई हो, तो आपको ईमेल, एसएमएस या वेबहुक के माध्यम से सूचित किया जा सके। आप ऑटोस्केल सेटिंग पर सूचनाएं टैब के माध्यम से सफल स्केल क्रियाओं के लिए अधिसूचित होने के लिए ईमेल या वेबहुक सूचनाओं को भी कॉन्फ़िगर कर सकते हैं।
Azure में अपने संसाधन को स्केल करने के लिए सामान्य पैटर्न
मांग के आधार पर स्केल
ग्राहक की माँग बढ़ने पर आप कार्य दिवस की शुरुआत में सेवा आवृत्तियों की संख्या स्वचालित रूप से बढ़ा सकते हैं. कार्य दिवस के अंत में, एप्लिकेशन उपयोग कम होने पर रातोंरात संसाधन लागत को कम करने के लिए एप्लिकेशन इंस्टेंस की संख्या में स्वचालित रूप से स्केल करें।
सप्ताह के दिनों बनाम सप्ताहांत पर अलग-अलग पैमाने पर
शाम या सप्ताहांत पर, आपके पास आवेदन की मांग कम हो सकती है। यदि यह लोड समय की किसी अवधि के लिए संगत है, तो आप स्केल सेट में सेवा आवृत्तियों की संख्या कम करने के लिए autoscale नियम कॉन्फ़िगर कर सकते हैं। इस स्केल-इन कार्रवाई को करने से आपके स्केल सेट को चलाने की लागत कम हो जाती है क्योंकि आप केवल वर्तमान मांग को पूरा करने के लिए आवश्यक उदाहरणों की संख्या चलाते हैं।
छुट्टियों के दौरान अलग-अलग स्केल करें
यदि आपके पास महीने या वित्तीय चक्र के कुछ हिस्सों में किसी सेवा के लिए भारी उपयोग है, तो आप उनकी अतिरिक्त मांगों को समायोजित करने के लिए स्वचालित रूप से सेवा उदाहरणों की संख्या बढ़ा सकते हैं। जब कोई मार्केटिंग इवेंट, प्रचार या अवकाश बिक्री होती है, तो आप अपेक्षित ग्राहक मांग से पहले सेवा आवृत्तियों की संख्या को स्वचालित रूप से बढ़ा सकते हैं।
कस्टम मीट्रिक के आधार पर स्केल
अंत में, अपने ऑटोस्केलिंग नियमों को सावधानीपूर्वक परिभाषित करना सबसे अच्छा है। उदाहरण के लिए, डिनायल ऑफ सर्विस (DoS) हमले के परिणामस्वरूप आने वाले ट्रैफ़िक की बड़े पैमाने पर आमद होने की संभावना है। DoS हमले के कारण अनुरोधों में वृद्धि को संभालने की कोशिश करना बेकार और महंगा होगा। ये अनुरोध वास्तविक नहीं हैं, और संसाधित होने के बजाय इन्हें छोड़ दिया जाना चाहिए। एक बेहतर समाधान यह है कि इस तरह के हमले के दौरान होने वाले अनुरोधों का पता लगाने और फ़िल्टरिंग को आपकी सेवा तक पहुंचने से पहले लागू किया जाए।
autoscaling नियमों को कॉन्फ़िगर करने के बाद, समय के साथ अपने अनुप्रयोग के प्रदर्शन की निगरानी करें। इस निगरानी के परिणामों का उपयोग उस पैटर्न को समायोजित करने के लिए करें जिसमें सिस्टम स्केल करता है, यदि आवश्यक हो।