NGINX रीलोड कैसे काम करता है? NGINX हॉट-रीलोड क्यों नहीं कर रहा है?

मैंने हाल ही में Reddit पर एक पोस्ट देखी जिसमें कहा गया था "NGINX हॉट रीलोडिंग का समर्थन क्यों नहीं करता?"। अजीब बात है, NGINX, दुनिया का सबसे बड़ा वेब सर्वर, हॉट रीलोडिंग का समर्थन नहीं करता? क्या इसका मतलब है कि हम सभी nginx -s reload का गलत तरीके से उपयोग कर रहे हैं? इस सवाल के साथ, आइए जांचें कि NGINX रीलोड कैसे काम करता है।

NGINX क्या है

NGINX एक क्रॉस-प्लेटफॉर्म ओपन-सोर्स वेब सर्वर है जो C भाषा में विकसित किया गया है। आंकड़ों के अनुसार, शीर्ष 1000 सबसे अधिक ट्रैफिक वाली वेबसाइटों में से 40% से अधिक NGINX का उपयोग कर रही हैं ताकि वे बड़ी संख्या में अनुरोधों को संभाल सकें।

NGINX इतना लोकप्रिय क्यों है

NGINX के पास क्या फायदे हैं जो इसे अन्य वेब सर्वरों से आगे रखते हैं और हमेशा उच्च उपयोग दर बनाए रखते हैं?

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

इसके अलावा, अन्य कारण भी हैं जैसे:

अत्यधिक मॉड्यूलर डिज़ाइन NGINX को विशाल फीचर-रिच आधिकारिक और विस्तारित तृतीय-पक्ष मॉड्यूल प्रदान करता है।
सबसे स्वतंत्र BSD लाइसेंस डेवलपर्स को NGINX में योगदान देने के लिए प्रेरित करता है।
हॉट रीलोडिंग का समर्थन NGINX को 24/7 सेवाएं प्रदान करने में सक्षम बनाता है।

उपरोक्त कारणों में से, हॉट रीलोडिंग हमारा आज का मुख्य विषय है।

हॉट रीलोड क्या करता है

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

किन परिस्थितियों में हमें हॉट रीलोडिंग की आवश्यकता होती है? क्लाउड नेटिव युग में, माइक्रोसर्विसेज इतने लोकप्रिय हो गए हैं कि अधिक से अधिक एप्लिकेशन परिदृश्यों में सर्वर-साइड संशोधनों की आवश्यकता होती है। ये संशोधन, जैसे डोमेन ऑनलाइन/ऑफलाइन का रिवर्स प्रॉक्सी, अपस्ट्रीम पते में परिवर्तन, और IP व्हाइटलिस्ट/ब्लॉकलिस्ट परिवर्तन, हॉट रीलोडिंग से संबंधित हैं।

तो NGINX हॉट रीलोडिंग कैसे प्राप्त करता है?

NGINX हॉट रीलोडिंग का सिद्धांत

जब हम हॉट रीलोड कमांड nginx -s reload को निष्पादित करते हैं, तो यह NGINX के मास्टर प्रोसेस को एक HUP सिग्नल भेजता है। जब मास्टर प्रोसेस HUP सिग्नल प्राप्त करता है, तो यह क्रमिक रूप से लिसनिंग पोर्ट्स खोलेगा और एक नया वर्कर प्रोसेस शुरू करेगा। इसलिए, दो वर्कर प्रोसेस (पुराना और नया) एक साथ मौजूद होंगे। नया वर्कर प्रोसेस प्रवेश करने के बाद, मास्टर प्रोसेस पुराने वर्कर प्रोसेस को QUIT सिग्नल भेजेगा ताकि इसे सही तरीके से बंद किया जा सके। जब पुराना वर्कर QUIT सिग्नल प्राप्त करता है, तो यह पहले लिसनिंग हैंडलर को बंद करेगा। अब, सभी नए कनेक्शन केवल नए वर्कर प्रोसेस में प्रवेश करेंगे, और सर्वर पुराने प्रोसेस को बंद कर देगा एक बार यह सभी शेष कनेक्शनों को प्रोसेस कर लेता है।

सिद्धांत रूप में, क्या NGINX की हॉट रीलोडिंग हमारी आवश्यकताओं को पूरी तरह से पूरा कर सकती है? दुर्भाग्य से, जवाब नहीं है। तो, NGINX की हॉट रीलोडिंग में किस तरह की कमियां हैं?

NGINX रीलोड डाउनटाइम का कारण बनता है

बहुत अधिक बार हॉट रीलोडिंग कनेक्शन को अस्थिर बना सकती है और व्यावसायिक डेटा खो सकता है।

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

उदाहरण के लिए, जब हम WebSocket प्रोटोकॉल को प्रॉक्सी करते हैं, तो हम यह नहीं जान सकते कि एक अनुरोध प्रोसेस हो चुका है या नहीं क्योंकि NGINX हेडर फ्रेम को पार्स नहीं करता है। इसलिए, भले ही वर्कर प्रोसेस मास्टर प्रोसेस से क्विट कमांड प्राप्त करता है, यह तब तक बाहर नहीं निकल सकता जब तक कि ये कनेक्शन अपवाद उठाते हैं, टाइम आउट होते हैं, या डिस्कनेक्ट होते हैं।

यहां एक और उदाहरण है, जब NGINX TCP और UDP के लिए रिवर्स प्रॉक्सी के रूप में कार्य करता है, तो यह नहीं जान सकता कि एक अनुरोध को अंततः बंद करने से पहले कितनी बार अनुरोध किया जा रहा है।

इसलिए, पुराना वर्कर प्रोसेस आमतौर पर लंबा समय लेता है, विशेष रूप से लाइव स्ट्रीमिंग, मीडिया, और स्पीच रिकग्निशन जैसे उद्योगों में। कभी-कभी, पुराने वर्कर प्रोसेस का रीसाइक्लिंग समय आधे घंटे या उससे भी अधिक तक पहुंच सकता है। इस बीच, यदि उपयोगकर्ता सर्वर को बार-बार रीलोड करते हैं, तो यह कई शट डाउन प्रोसेस बना देगा और अंततः NGINX OOM का कारण बनेगा, जो व्यवसाय को गंभीर रूप से प्रभावित कर सकता है।

# हमेशा पुराने वर्कर प्रोसेस में मौजूद:
nobody 6246 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 6247 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 6247 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 6248 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 6249 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 7995 10419 0 10:30 ? 00:20:37 nginx: worker process is shutting down  <= यहां
nobody 7995 10419 0 10:30 ? 00:20:37 nginx: worker process is shutting down
nobody 7996 10419 0 10:30 ? 00:20:37 nginx: worker process is shutting down

संक्षेप में, हम nginx -s reload को निष्पादित करके हॉट रीलोडिंग प्राप्त कर सकते हैं, जो अतीत में पर्याप्त था। हालांकि, माइक्रोसर्विसेज और क्लाउड नेटिव के तेजी से विकास ने इस समाधान को उपयोगकर्ताओं की आवश्यकताओं को पूरा नहीं करने दिया।

यदि आपके व्यवसाय का अपडेट फ्रीक्वेंसी साप्ताहिक या दैनिक है, तो यह NGINX रीलोडिंग अभी भी आपकी आवश्यकताओं को पूरा कर सकता है। हालांकि, यदि अपडेट फ्रीक्वेंसी प्रति घंटे या प्रति मिनट हो जाती है तो क्या होगा? उदाहरण के लिए, मान लीजिए कि आपके पास 100 NGINX सर्वर हैं, और यह प्रति घंटे एक बार रीलोड होता है, तो इसे प्रति दिन 2400 बार रीलोड करने की आवश्यकता होगी; यदि सर्वर प्रति मिनट रीलोड होता है, तो इसे प्रति दिन 8,640,000 बार रीलोड करने की आवश्यकता होगी, जो अस्वीकार्य है।

हमें एक ऐसे समाधान की आवश्यकता है जो प्रोसेस स्विचिंग के बिना हो, और यह तुरंत सामग्री अपडेट भी प्राप्त कर सके।

मेमोरी में तुरंत प्रभावी होने वाली हॉट रीलोडिंग

जब Apache APISIX का जन्म हुआ, तो इसे NGINX हॉट रीलोडिंग समस्या को हल करने के लिए डिज़ाइन किया गया था। APISIX NGINX और Lua के टेक स्टैक पर विकसित किया गया है, और यह एक क्लाउड-नेटिव, उच्च-प्रदर्शन, पूरी तरह से डायनामिक माइक्रोसर्विस API गेटवे है जो etcd को अपने कोर कॉन्फ़िगरेशन सेंटर के रूप में उपयोग करता है। सर्वर को रीबूट करने की आवश्यकता नहीं है ताकि नए सर्वर कॉन्फ़िगरेशन को रीलोड किया जा सके, जिसका अर्थ है कि किसी भी अपस्ट्रीम सेवाओं, रूट्स, या प्लगइन परिवर्तनों के लिए सर्वर को रीबूट करने की आवश्यकता नहीं होगी। लेकिन APISIX NGINX की सीमाओं को कैसे समाप्त कर सकता है ताकि यह NGINX टेक स्टैक पर विकसित होने के बावजूद पूर्ण हॉट रीलोडिंग प्राप्त कर सके?

पहले, आइए Apache APISIX के सॉफ्टवेयर आर्किटेक्चर को देखें:

आर्किटेक्चर

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

अब, आइए एक क्लासिक परिदृश्य का परिचय दें; उदाहरण के लिए, यदि हम एक नए डोमेन के लिए रिवर्स प्रॉक्सी जोड़ना चाहते हैं, तो हमें केवल APISIX में एक अपस्ट्रीम बनाने और एक नया रूट जोड़ने की आवश्यकता है। इस प्रक्रिया के दौरान NGINX को रीबूट करने की आवश्यकता नहीं है। यहां प्लगइन सिस्टम के लिए एक और उदाहरण है: APISIX IP-restriction प्लगइन का उपयोग करके IP व्हाइटलिस्ट/ब्लॉकलिस्ट फीचर प्राप्त कर सकता है। ये सभी फीचर अपडेट डायनामिक हैं और सर्वर को रीबूट करने की आवश्यकता नहीं है। etcd के लिए धन्यवाद, कॉन्फ़िगरेशन स्ट्रेटेजी एड-ऑन का उपयोग करके तुरंत अपडेट प्राप्त कर सकती है, और सभी कॉन्फ़िगरेशन तुरंत प्रभावी हो सकते हैं और सर्वश्रेष्ठ उपयोगकर्ता अनुभव प्रदान कर सकते हैं।

निष्कर्ष

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

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