Node.js ऐप्लिकेशन को स्केल करना और ऑटो-स्केलिंग करना

Auto-scaling grows and shrinks the number of instances running your Node.js app as CPU load changes, so busy periods get more capacity and quiet periods cost less. This guide covers the KPanel tab…

Auto-scaling आपके Node.js ऐप्लिकेशन के चलने वाले इंस्टेंस की संख्या को CPU लोड के अनुसार बढ़ाता और घटाता है, इसलिए व्यस्त समय में अधिक क्षमता मिलती है और शांत समय में कम खर्च होता है। यह गाइड KPanel टैब, हर सेटिंग, बिलिंग और ऐप्लिकेशन को स्केल करने के लिए सुरक्षित बनाने के बारे में बताती है।

KPanel में Scaling कहाँ स्थित है

KPanel में साइन इन करें।
बाएँ साइडबार में Websites पर क्लिक करें, फिर साइट पर क्लिक करें।
साइट के टैब स्ट्रिप में, Advanced खोलें, फिर Scaling खोलें।

सीधा पता /websites/<site-id>/autoscale है। पुराना /websites/<site-id>/scaling पता अभी भी काम करता है और आपको एक ही जगह भेजता है।

KPanel में एक Node.js ऐप्लिकेशन के लिए Auto-scaling सेटिंग्स

यह टैब केवल Node.js साइट पर दिखाई देता है। यह WordPress, WooCommerce, static, PHP, Python या Ruby साइट के लिए मेनू में नहीं होगा, क्योंकि तंत्र एक Node.js प्रक्रिया क्लस्टर को स्केल करता है।

एक टैब, एक कॉन्फ़िगरेशन

पहले KPanel के पास यहाँ दो टैब थे, Scaling और Autoscale, एक ही सेटिंग के ऊपर। वे एक ही कॉन्फ़िगरेशन के दो दृश्य थे, जो केवल खो जाने का एक तरीका था, इसलिए अब वे एक ही Scaling टैब हैं: live status, सेटिंग्स, हाल की स्केल events, और वर्तमान बिलिंग अवधि के लिए उपयोग और लागत पैनल, सब कुछ एक जगह पर।

यह कैसे काम करता है

आपका ऐप्लिकेशन एक प्रक्रिया क्लस्टर के रूप में चलता है। Auto-scaling चलने वाले इंस्टेंस के अनुसार औसत CPU को देखता है और आपके द्वारा सेट किए गए थ्रेशहोल्ड के विरुद्ध इंस्टेंस जोड़ता या हटाता है।

Cluster mode आवश्यक है। यदि आपका ऐप्लिकेशन पहले से cluster mode में नहीं चल रहा है, तो auto-scaling को सक्षम करना इसे स्विच कर देता है, जिसमें एक संक्षिप्त restart शामिल है। पृष्ठ आपको बताता है कि यह कब होता है।

Live Status को पढ़ना

स्टेटस कार्ड तीन चीजें दिखाता है:

Instances: अभी कितने चल रहे हैं।
Avg CPU: उन इंस्टेंसों के अनुसार औसत CPU।
Cluster: क्या ऐप cluster mode में है। यदि नहीं कहता है, तो auto-scaling को सक्षम करने से इसे स्विच कर दिया जाएगा।

यदि ऐप्लिकेशन बिल्कुल नहीं चल रहा है, तो कार्ड शून्य दिखाने के बजाय ऐसा कहता है।

टैब Last scale भी दिखाता है, सबसे हाल की scale event का समय, या never।

सेटिंग्स

सेटिंग	रेंज	यह क्या करता है
Min instances	1 से 16	न्यूनतम सीमा। इससे कभी कम स्केल नहीं होता
Max instances	1 से 16	अधिकतम सीमा। इससे कभी अधिक स्केल नहीं होता
Scale up at CPU %	5 से 99	औसत CPU इससे अधिक होने पर एक इंस्टेंस जोड़ता है
Scale down at CPU %	1 से 95	औसत CPU इससे कम होने पर एक को हटाता है
Cooldown (sec)	30 से 3600	स्केल actions के बीच न्यूनतम प्रतीक्षा

मास्टर स्विच सेटिंग्स कार्ड हेडर में टॉगल है। जब auto-scaling बंद होता है, तो सेटिंग्स धूसर होती हैं और आपका ऐप्लिकेशन अपनी वर्तमान इंस्टेंस गणना पर रहता है।

समझदारी भरे शुरुआती मान:

Min instances 1 या 2। दो यदि आप एक एकल इंस्टेंस के restart से ऐप्लिकेशन को ऑफलाइन जाने को सहन नहीं कर सकते।
Max instances जो आप peak पर भुगतान करने के लिए तैयार हैं, ceiling पर नहीं।
Scale up around 70 percent। इतना अधिक कि आप headroom के लिए भुगतान नहीं कर रहे हैं जिसका आप कभी उपयोग नहीं करते, इतना कम कि requests को queue करना शुरू करने से पहले क्षमता जोड़ने का समय हो।
Scale down around 30 percent। दोनों थ्रेशहोल्ड के बीच एक बड़ा अंतर छोड़ें।
Cooldown कुछ मिनट का। यह सबसे कम सराहनीय सेटिंग है।

दोनों CPU थ्रेशहोल्ड को एक दूसरे के करीब सेट करने से flapping होती है: क्लस्टर स्केल ऊपर जाता है, तुरंत scale-down threshold के नीचे गिर जाता है क्योंकि लोड अब व्यापक है, स्केल नीचे जाता है, फिर से स्पाइक करता है, और दोहराता है। एक व्यापक अंतर रखें, और एक उदार cooldown का उपयोग करें। Flapping पैसे की बर्बादी करता है और ऐप्लिकेशन को अस्थिर करता है।

Scale Events

टैब हाल की scale events को list करता है, नवीनतम पहले, प्रत्येक दिशा, पहले और बाद में इंस्टेंस गणना, इसे trigger करने वाली CPU reading, और समय दिखाता है।

यह log है जब ऐप्लिकेशन गलत व्यवहार करे तो पढ़ने के लिए। कुछ मिनट में ऊपर और नीचे events का एक फटना मतलब है कि आपके थ्रेशहोल्ड बहुत करीब हैं या आपका cooldown बहुत कम है। एक एकल scale-up जो कभी नीचे नहीं आया मतलब है कि लोड high रहा, जो एक क्षमता प्रश्न है configuration नहीं। कोई events नहीं जब आप कुछ की उम्मीद करते थे मतलब है कि या तो CPU कभी threshold को cross नहीं किया या auto-scaling बंद है।

Auto-Scaling की लागत क्या है

आपकी plan के base allocation के ऊपर के इंस्टेंस को मीटर किया जाता है और सेकंड के हिसाब से बिल किया जाता है। टैब दिखाता है, वर्तमान अवधि के लिए:

Instance-time used, घंटे और मिनट में, कच्चे instance-seconds के अनुसार।
Spent so far इस अवधि में।
Projected month-end, अब तक के उपयोग से extrapolate किया गया।
Tracking, कितनी usage windows बिल की गई हैं कुल रिकॉर्ड किए गए में से।
Period progress, महीने के दिनों में से कितने दिन बीत गए हैं।

प्रति सेकंड दर एक ही पैनल के शीर्ष पर दिखाई गई है, इसलिए जिस आंकड़े को आप बिल किए जाते हैं वह हमेशा उपयोग के बगल में दिखाई देता है जो इस पर लागू होता है।

प्रोजेक्शन देखने के लिए संख्या है। यह अब तक आपने जो उपयोग किया है उससे extrapolate करता है, इसलिए महीने की शुरुआत में एक असामान्य रूप से व्यस्त सप्ताह इसे overstate करेगा। कुछ दिन में इसे check करें, फिर महीने के मध्य में, निष्कर्ष निकालने से पहले। यदि यह अधिक है जितना आप चाहते हैं, तो maximum instance count को कम करें बजाय scale-up threshold को बढ़ाने के: ceiling एक hard limit है, threshold केवल एक hint है।

न्यूनतम तक स्केल नीचे जाने से metering बंद हो जाती है। यदि आप auto-scaling को पूरी तरह बंद कर देते हैं, तो ऐप्लिकेशन जो भी इंस्टेंस गणना पर है उस पर रहता है, इसलिए यदि लागत का कारण है कि आप स्विच कर रहे हैं तो पहले इसे न्यूनतम तक drop करें।

एक ऐप्लिकेशन को स्केल करने के लिए सुरक्षित बनाना

पृष्ठ पर एक warning है, और यह इस पर सबसे महत्वपूर्ण बात है: आपका Node.js ऐप्लिकेशन instances के अनुसार स्केल करने के लिए cluster-safe होना चाहिए।

व्यावहारिक रूप से इसका मतलब है:

कोई in-memory session state नहीं। यदि एक signed-in user का session एक इंस्टेंस की memory में रहता है, तो वे signed out हो जाते हैं जब भी एक request एक अलग इंस्टेंस पर उतरती है। Sessions को एक shared store में ले जाएँ।

कोई in-memory cache नहीं जिस पर आप correctness के लिए भरोसा करते हैं। प्रत्येक इंस्टेंस के पास अपना है। एक cache जो consistent होना चाहिए उसे shared होना चाहिए।

कोई local filesystem writes नहीं जिन्हें आप वापस पढ़ने की उम्मीद करते हैं। Uploads जो local disk पर एक इंस्टेंस द्वारा लिखे गए हैं वे दूसरों के लिए invisible हैं। Shared storage में लिखें।

कोई unguarded scheduled work नहीं। यदि एक timer ऐप्लिकेशन के अंदर चलता है, तो हर इंस्टेंस इसे चलाता है, इसलिए एक nightly job चार instances पर चार बार चलता है। Scheduled work को एक cron job में ले जाएँ, या इसे एक lock से guard करें। Cron Jobs देखें।

कोई assumption नहीं कि instance count स्थिर है। कुछ भी जो work को instance index के आधार पर partition करता है वह उस क्षण टूट जाता है जब गणना बदलती है।

यदि इनमें से कोई भी आपके ऐप्लिकेशन पर लागू होता है, तो auto-scaling को सक्षम करने से पहले उन्हें ठीक करें। एक ऐप्लिकेशन जो cluster-safe नहीं है intermittent तरीके से विफल होता है और reproduce करना कठिन होता है, क्योंकि यह उस पर निर्भर करता है कि कौन सा इंस्टेंस कौन सी request को serve करता है।

समस्या निवारण

टॉगल enable नहीं होगा। सक्षम करने के लिए site write permission चाहिए। एक read-only role के साथ controls disabled हैं।

जब मैंने auto-scaling सक्षम किया तो ऐप्लिकेशन restart हुआ। अपेक्षित है। Cluster mode में switch करने के लिए एक restart चाहिए, और यह एक बार होता है।

Users यादृच्छिक रूप से signed out हो रहे हैं। क्लासिक non-cluster-safe लक्षण। Sessions memory में हैं और requests अलग instances पर landing हैं।

Instances स्केल ऊपर गए और कभी नीचे नहीं आए। या तो लोड scale-down threshold के ऊपर रहा, या कुछ traffic से independently CPU को high रख रहा है। Events list को check करें और देखें कि ऐप्लिकेशन वास्तव में क्या कर रहा है।

एक scheduled job कई बार चला। हर इंस्टेंस ने इसे चलाया। इसे एक cron job में ले जाएँ या एक lock जोड़ें।

कुछ भी स्केल नहीं होता। पुष्टि करें कि टॉगल on है, ऐप्लिकेशन चल रहा है, और cluster mode सक्षम है। फिर check करें कि क्या CPU वास्तव में events list में आपके scale-up threshold को cross किया है।

लागत अपेक्षा से अधिक है। Events list को flapping के लिए देखें, फिर अपनी maximum instance count को कम करें।