Apache APISIX के साथ Sticky Sessions - सिद्धांत

स्टिकी सेशन, जिसे सेशन एफिनिटी के रूप में भी जाना जाता है, एक ऐसी प्रणाली है जिसमें एक रूटिंग घटक जो एक फेसड के रूप में कार्य करता है, हमेशा एक ही अंतर्निहित अपस्ट्रीम नोड पर अनुरोध को रूट करता है। इस पोस्ट में, मैं स्टिकी सेशन के पीछे के कारण, उपलब्ध विकल्पों, और उन्हें Apache APISIX के माध्यम से कैसे लागू किया जाए, इसके बारे में बताऊंगा।

स्टिकी सेशन क्यों?

स्टिकी सेशन तब लोकप्रिय हुए जब हमने डेटाबेस के बजाय अपस्ट्रीम नोड पर स्थिति को संग्रहीत किया। मैं एक सरलीकृत ई-कॉमर्स दुकान के उदाहरण का उपयोग करके और समझाऊंगा।

एक छोटे ई-कॉमर्स साइट की मूल संरचना में एक वेब एप्लिकेशन और एक डेटाबेस शामिल हो सकते हैं।

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

हर बार डेटाबेस पर जाना एक महंगा ऑपरेशन है। यह उन डेटा के लिए ठीक है जिन्हें कम बार एक्सेस किया जाता है। हालांकि, हम हर अनुरोध के लिए कार्ट की सामग्री प्रदर्शित करना चाहते हैं। चीजों को तेज करने के लिए कुछ विकल्प उपलब्ध हैं। यदि हम मान लें कि वेब ऐप सर्वर-साइड रेंडरिंग का उपयोग करता है, तो क्लासिकल समाधान यह है कि कार्ट से संबंधित डेटा को वेब ऐप नोड पर मेमोरी में रखा जाए।

हालांकि, यदि हम यूजर X के कार्ट को नोड 1 पर संग्रहीत करते हैं, तो हमें यह सुनिश्चित करना होगा कि हम यूजर X के हर अनुरोध को उसी नोड पर भेजें। अन्यथा, उन्हें ऐसा लगेगा कि उन्होंने अपने कार्ट की सामग्री खो दी है। स्टिकी सेशन, या सेशन एफिनिटी, वह प्रणाली है जो एक ही यूजर को लगातार एक ही नोड पर रूट करती है।

स्टिकी सेशन की सीमा

आगे बढ़ने से पहले, मुझे स्टिकी सेशन की एक महत्वपूर्ण सीमा को समझाना होगा। यदि वेब ऐप नोड जो डेटा संग्रहीत करता है किसी भी कारण से डाउन हो जाता है, तो डेटा अपूरणीय रूप से खो जाता है। उपरोक्त ई-कॉमर्स परिदृश्य के लिए, इसका मतलब है कि यूजर्स कभी-कभी अपना कार्ट खो देंगे, जो व्यावसायिक दृष्टिकोण से अस्वीकार्य है।

इस कारण से, स्टिकी सेशन को सेशन रेप्लिकेशन के साथ हाथ में हाथ जाना चाहिए: एक नोड पर संग्रहीत डेटा को कॉपी किया जाना चाहिए और अन्य सभी नोड्स के साथ सिंक में रखा जाना चाहिए।

जबकि सेशन रेप्लिकेशन सभी टेक स्टैक्स में मौजूद है, इससे संबंधित कोई विशिष्ट विनिर्देश नहीं है। मैं JVM से परिचित हूं, इसलिए यहां कुछ विकल्प दिए गए हैं:

• टॉमकैट सेशन रेप्लिकेशन प्रदान करता है
• Hazelcast एक क्लस्टर्ड इन-मेमोरी समाधान प्रदान करता है जिसे आप विभिन्न स्तरों पर एकीकृत कर सकते हैं
• Spring Session विशिष्ट समाधानों पर एक एब्स्ट्रक्शन लेयर है

जब डेटा सभी नोड्स (या एक रिमोट क्लस्टर) पर रेप्लिकेट हो जाता है, तो आप सोच सकते हैं कि आपको अब स्टिकी सेशन की आवश्यकता नहीं है। यह सच है यदि केवल उपलब्धता को ध्यान में रखा जाए और प्रदर्शन को नहीं। यह डेटा लोकेशन के बारे में है: नेटवर्क के माध्यम से कहीं और से डेटा प्राप्त करने के बजाय वर्तमान नोड पर डेटा प्राप्त करना तेज होता है।

Apache APISIX पर स्टिकी सेशन

स्टिकी सेशन किसी भी लोड बैलेंसर, रिवर्स प्रॉक्सी, और API गेटवे के लिए एक आवश्यकता है। हालांकि, मुझे यह स्वीकार करना होगा कि Apache APISIX का दस्तावेज़ीकरण इस विषय में आसान प्रवेश बिंदु की आवश्यकता है।

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

हालांकि, अन्य एल्गोरिदम उपलब्ध हैं:

• कंसिस्टेंट हैशिंग
• एक्सपोनेंशियल वेटेड मूविंग एवरेज चार्ट
• लीस्ट कनेक्शन
• एक कस्टम-मेड एल्गोरिदम

कंसिस्टेंट हैशिंग कुछ मान के आधार पर एक ही नोड पर फॉरवर्ड करने की अनुमति देता है: एक NGINX वेरिएबल, एक HTTP हेडर, एक कुकी, आदि।

याद रखें कि HTTP एक स्टेटलेस प्रोटोकॉल है, इसलिए एप्लिकेशन सर्वर पहले प्रतिक्रिया पर एक कुकी सेट करते हैं ताकि HTTP अनुरोधों के बीच यूजर को ट्रैक किया जा सके। इसे हम "सेशन" कहते हैं। हमें अंतर्निहित सेशन कुकी का नाम जानना होगा। विभिन्न एप्लिकेशन सर्वर विभिन्न कुकीज़ प्रदान करते हैं:

• JVM-आधारित सर्वर के लिए JSESSIONID
• PHP के लिए PHPSESSID
• ASP.Net के लिए ASPSESSIONID
• आदि।

मैं एक नियमित टॉमकैट का उपयोग करूंगा, इसलिए सेशन कुकी JSESSIONID है। इसलिए, Apache APISIX का दस्तावेज़ीकरण दो नोड्स के लिए निम्नलिखित है:

routes:
  - uri: /*
    upstream:
      nodes:
        "tomcat1:8080": 1            #1
        "tomcat2:8080": 1            #1
      type: chash                    #2
      hash_on: cookie                #3
      key: cookie_JSESSIONID         #4

1. अपस्ट्रीम नोड्स को परिभाषित करें
2. कंसिस्टेंट हैशिंग एल्गोरिदम चुनें
3. कुकी पर हैश करें
4. परिभाषित करें कि किस कुकी पर हैश करना है

निष्कर्ष

इस पोस्ट में, हमने स्टिकी सेशन के बारे में विस्तार से बताया, कि आपको हमेशा स्टिकी सेशन के साथ सेशन रेप्लिकेशन का उपयोग करना चाहिए, और Apache APISIX पर स्टिकी सेशन को कैसे लागू किया जाए।

आगे जाने के लिए:

• लोड बैलेंसिंग
• अपस्ट्रीम कॉन्फ़िगरेशन
• स्टेटलेसनेस का भ्रम