ST-KEDA: Predictive Cost-Aware Autoscaling for Kubernetes Microservices via Spectral- Temporal Demand Forecasting

आधुनिक सॉफ़्टवेयर अक्सर एक एकल, विशाल प्रोग्राम के रूप में नहीं, बल्कि छोटे, स्वतंत्र भागों के संग्रह के रूप में चलता है जिन्हें माइक्रोसर्विसेज (microservices) कहा जाता है। ये भाग एक जटिल समस्या को हल करने के लिए नोट्स पास करने वाली विशेषज्ञों की एक टीम की तरह लगातार एक-दूसरे से बात करते हैं। इस टीम को सुचारू रूप से चलाने के लिए, उन्हें होस्ट करने वाले कंप्यूटरों को स्वचालित रूप से अपनी शक्ति को समायोजित करना चाहिए। यदि एक साथ बहुत अधिक लोग वेबसाइट पर आते हैं, तो सिस्टम को तुरंत अधिक कार्यकर्ता जोड़ने की आवश्यकता होती है। यदि ट्रैफ़िक कम हो जाता है, तो इसे पैसे बचाने के लिए कार्यकर्ताओं को जाने देना चाहिए। यह स्वचालित समायोजन ऑटोस्केलिंग (autoscaling) कहलाता है। वर्तमान में, अधिकांश सिस्टम किसी समस्या को देखने तक प्रतीक्षा करते हैं—जैसे कि धीमी प्रतिक्रिया समय—इससे पहले कि वे प्रतिक्रिया दें। इस प्रतिक्रिया में कई मिनट लगते हैं, जो डिजिटल दुनिया में एक अनंत काल जैसा महसूस होता है, जिससे उपयोगकर्ताओं को लैग या त्रुटियों का अनुभव होता है। इसके अलावा, इन सिस्टमों का प्रबंधन करने वाले लोगों के पास अक्सर इस बात का स्पष्ट, तत्काल दृश्य नहीं होता कि प्रत्येक विशिष्ट समायोजन की लागत कितनी है, जिससे प्रदर्शन और बजट के बीच संतुलन बनाना कठिन हो जाता है।

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

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

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

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

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

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

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

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