एडब्ल्यूएस लैम्ब्डा जैसे सर्वरलेस आर्किटेक्चर आने वाले ट्रैफ़िक स्पाइक्स को संभालने के लिए तुरंत स्केल होते हैं। हालांकि, पारंपरिक रिलेशनल डेटाबेस जैसे पोस्टग्रेएसक्यूएल और माईएसक्यूएल को इस क्षणभंगुर स्केलिंग मॉडल के लिए नहीं बनाया गया था। वे लंबे समय तक चलने वाले कनेक्शन के एक स्थिर पूल की उम्मीद करते हैं, न कि सेकंड में बनने और नष्ट होने वाले हजारों अल्पकालिक कनेक्शनों की।
जब सैकड़ों या हजारों लैम्ब्डा फ़ंक्शन्स एक साथ चलते हैं, तो वे आपके डेटाबेस को आसानी से प्रभावित कर सकते हैं, जिससे कनेक्शन पूल की समाप्ति, कैस्केडिंग विफलताएं और एप्लिकेशन डाउनटाइम हो सकता है।
मूल कारण: कनेक्शन का तूफ़ान
एक पारंपरिक सर्वर आर्किटेक्चर में, एक एकल एप्लिकेशन इंस्टेंस एक कनेक्शन पूल (उदाहरण के लिए, २० कनेक्शन) स्थापित करता है और इसे सभी समवर्ती अनुरोधों में साझा करता है। लोड बैलेंसर के पीछे तीन इंस्टेंस का मतलब कुल ६० डेटाबेस कनेक्शन हैं, जो पूरी तरह से अनुमानित और प्रबंधनीय हैं।
सर्वरलेस मॉडल में, यह व्यवस्था पूरी तरह से टूट जाती है:
- प्रत्येक सक्रिय लैम्ब्डा इंस्टेंस अपने स्वयं के पृथक कंटेनर में चलता है।
- प्रत्येक कंटेनर डेटाबेस के लिए अपना स्वयं का कनेक्शन स्थापित करता है।
- यदि आपका एप्लिकेशन १,००० समवर्ती निष्पादन तक स्केल होता है, तो आप अपने डेटाबेस पर १,००० अलग-अलग कनेक्शन अनुरोध करेंगे।
- अधिकांश पोस्टग्रेएसक्यूएल इंस्टेंस डिफ़ॉल्ट रूप से P७ पर सेट होते हैं। एक आरडीएस P८ लगभग १५० कनेक्शन का समर्थन करता है। आपके १,००० लैम्ब्डा इंस्टेंस लगभग तुरंत इस सीमा को पार कर जाएंगे, जिससे P९ त्रुटियां मिलेंगी।
यह समस्या कोल्ड स्टार्ट द्वारा और बढ़ जाती है: जब ट्रैफ़िक स्पाइक होता है, तो लैम्ब्डा एक साथ कई नए कंटेनर लॉन्च करता है। प्रत्येक कंटेनर अनुरोध प्रसंस्करण शुरू होने से पहले स्वतंत्र रूप से एक कनेक्शन खोलता है, जिससे डेटाबेस पर एक साथ कनेक्शन का भारी दबाव पड़ता है।
रणनीति १: वॉर्म इनवोकेशन्स में कनेक्शन का पुन: उपयोग
सबसे सरल अनुकूलन (जिस पर कई टीमें ध्यान नहीं देतीं) हैंडलर फ़ंक्शन के बाहर डेटाबेस क्लाइंट को इनिशियलाइज़ करना है। लैम्ब्डा कंटेनर वॉर्म स्टार्ट के दौरान बने रहते हैं, इसलिए पहले इनवोकेशन पर स्थापित कनेक्शन का उपयोग दोबारा कनेक्शन बनाए बिना बाद के अनुरोधों के लिए किया जा सकता है।
P०
महत्वपूर्ण विवरण:
- पैरामीटराइज्ड क्वेरीज़ (P१०) एसक्यूएल इंजेक्शन को रोकती हैं। उपयोगकर्ता इनपुट को सीधे क्वेरी स्ट्रिंग में कभी न जोड़ें।
- P११ डेटाबेस पर अत्यधिक दबाव होने की स्थिति में फ़ंक्शन को अनिश्चित काल के लिए लटकने से रोकता है।
- निष्क्रिय कनेक्शनों को संभालना अत्यंत महत्वपूर्ण है। लैम्ब्डा इनवोकेशन्स के बीच कंटेनरों को फ़्रीज़ कर देता है। यदि कोई कंटेनर बहुत लंबे समय तक फ़्रीज़ रहता है, तो डेटाबेस सर्वर-साइड से कनेक्शन बंद कर सकता है, लेकिन क्लाइंट अभी भी मृत सॉकेट का संदर्भ रखता है। इस स्थिति से बचने के लिए रीकनेक्शन लॉजिक आवश्यक है।
कंटेनर बंद होने पर सफाई
लैम्ब्डा कंटेनर अंततः रीसायकल किए जाते हैं। आप कनेक्शन को सुरक्षित रूप से बंद करने के लिए एक क्लीनअप हैंडलर रजिस्टर कर सकते हैं:
P१
यह उन अनाथ कंटेनरों से कनेक्शन लीक को रोकता है जिन्हें डेटाबेस अभी भी सक्रिय मान रहा होता है।
रणनीति २: डेटाबेस प्रॉक्सी का उपयोग करें
कनेक्शन का पुन: उपयोग वॉर्म कंटेनरों में मदद करता है, लेकिन यह इस मूल समस्या को हल नहीं करता: एन लैम्ब्डा इंस्टेंस = एन डेटाबेस कनेक्शन। अपने सर्वरलेस कंप्यूट लेयर को डेटाबेस कनेक्शन सीमाओं से पूरी तरह से अलग करने के लिए, आपको एक प्रॉक्सी की आवश्यकता होती है जो कनेक्शनों को पूल कर सके।
एडब्ल्यूएस आरडीएस प्रॉक्सी (प्रबंधित)
एडब्ल्यूएस आरडीएस प्रॉक्सी आपके लैम्ब्डा फ़ंक्शन्स और आपके आरडीएस डेटाबेस के बीच बैठता है। यह डेटाबेस के लिए एक निरंतर कनेक्शन पूल बनाए रखता है और उस पूल के माध्यम से हजारों लैम्ब्डा कनेक्शनों को साझा करता है।
यह कैसे काम करता है: १. आपका लैम्ब्डा फ़ंक्शन सीधे डेटाबेस के बजाय आरडीएस प्रॉक्सी एंडपॉइंट से जुड़ता है। २. आरडीएस प्रॉक्सी वास्तविक डेटाबेस के लिए लंबे समय तक चलने वाले कनेक्शनों का एक पूल बनाए रखता है (जैसे, ५० कनेक्शन)। ३. जब लैम्ब्डा कंटेनर ए एक क्वेरी भेजता है, तो प्रॉक्सी पूल से एक कनेक्शन लेता है, क्वेरी चलाता है, और कनेक्शन को वापस पूल में डाल देता है। ४. लैम्ब्डा कंटेनर बी की क्वेरी कुछ पलों बाद उसी कनेक्शन का पुन: उपयोग करती है।
लाभ:
- कनेक्शन साझाकरण को पारदर्शी रूप से संभालता है, आपके एप्लिकेशन कोड में कोई बदलाव नहीं होता (केवल कनेक्शन स्ट्रिंग बदलें)।
- आईएएम-आधारित प्रमाणीकरण का समर्थन करता है, जिससे एनवायरनमेंट वेरिएबल्स में डेटाबेस पासवर्ड संग्रहीत करने की आवश्यकता समाप्त हो जाती है।
- मुख्य डेटाबेस आउटेज के दौरान रीड रेप्लिका पर स्वचालित रूप से स्विच (फेलओवर) हो जाता है।
लागत: आरडीएस प्रॉक्सी प्रति प्रॉक्सी ~$१५-२५/माह (इंस्टेंस टाइप के आधार पर) और साथ ही $०.०१५ प्रति वीसीपीयू-घंटा चार्ज करता है। बड़े डिप्लॉयमेंट के लिए, यह विकास समय और स्थिरता की तुलना में नगण्य है।
पीजीबाउंसर (स्व-प्रबंधित)
पीजीबाउंसर पोस्टग्रेएसक्यूएल के लिए सबसे व्यापक रूप से उपयोग किया जाने वाला ओपन-सोर्स कनेक्शन पूलर है और यदि आप अधिक नियंत्रण चाहते हैं या एडब्ल्यूएस पर नहीं हैं तो यह एक बेहतरीन विकल्प है।
पीजीबाउंसर तीन मोड में काम करता है:
| मोड | व्यवहार | किसके लिए सर्वश्रेष्ठ |
|---|---|---|
| सत्र | एक क्लाइंट = सत्र की अवधि तक एक सर्वर कनेक्शन | लंबे समय तक चलने वाले ट्रांजेक्शन |
| ट्रांजेक्शन | प्रत्येक ट्रांजेक्शन पूरा होने के बाद कनेक्शन पूल में वापस आ जाता है | अधिकांश सर्वरलेस वर्कलोड |
| स्टेटमेंट | प्रत्येक व्यक्तिगत स्टेटमेंट के बाद कनेक्शन वापस आ जाता है | केवल सरल क्वेरी पैटर्न |
सर्वरलेस आर्किटेक्चर के लिए, ट्रांजेक्शन मोड लगभग हमेशा सही विकल्प होता है। यह ५० सर्वर कनेक्शनों के एक पूल को हजारों लैम्ब्डा कनेक्शनों की सेवा करने की अनुमति देता है, क्योंकि प्रत्येक कनेक्शन केवल एक ट्रांजेक्शन की अवधि के लिए व्यस्त रहता है।
डिप्लॉयमेंट विकल्प:
- ईसी२/ईसीएस पर साइडकार: अपने डेटाबेस के समान वीपीसी में एक छोटे इंस्टेंस पर पीजीबाउंसर चलाएं। लैम्ब्डा पीजीबाउंसर से जुड़ता है; पीजीबाउंसर डेटाबेस से जुड़ता है।
- प्रबंधित सेवाएं: सुपाबेस, नियॉन, और क्रंची ब्रिज जैसे प्रदाता अपनी प्रबंधित पोस्टग्रेएसक्यूएल सेवाओं के साथ अंतर्निहित पीजीबाउंसर प्रदान करते हैं।
कनेक्शन पूलिंग समाधानों की तुलना
| समाधान | प्रकार | पोस्टग्रेएसक्यूएल | माईएसक्यूएल | मूल्य निर्धारण | किसके लिए सर्वश्रेष्ठ |
|---|---|---|---|---|---|
| एडब्ल्यूएस आरडीएस प्रॉक्सी | प्रबंधित | ✅ | ✅ | ~$२०/माह + वीसीपीयू घंटे | एडब्ल्यूएस-नेटिव, नो-ऑप्स |
| पीजीबाउंसर | स्व-प्रबंधित | ✅ | ❌ | केवल ईसी२ इंस्टेंस लागत | पूर्ण नियंत्रण, मल्टी-क्लाउड |
| प्रिज़्मा एक्सेलरेट | प्रबंधित | ✅ | ✅ | फ्री टियर, फिर उपयोग-आधारित | नोड.जेएस/प्रिज़्मा ओआरएम उपयोगकर्ता |
| नियॉन सर्वरलेस ड्राइवर | प्रबंधित | ✅ | ❌ | नियॉन के साथ शामिल | नियॉन पोस्टग्रेएसक्यूएल उपयोगकर्ता |
रणनीति ३: पूल का आकार न्यूनतम रखें
यदि आप अपने लैम्ब्डा फ़ंक्शन के अंदर ओआरएम या कनेक्शन पूल लाइब्रेरी का उपयोग कर रहे हैं, तो अधिकतम पूल आकार (P१२) को १ पर सेट करें। यदि आप पारंपरिक सर्वर पृष्ठभूमि से आ रहे हैं तो यह अजीब लग सकता है, लेकिन लैम्ब्डा के लिए यही सही है:
P२
P१३ क्यों? एक अकेला लैम्ब्डा कंटेनर एक समय में बिल्कुल एक ही अनुरोध को प्रोसेस करता है। एक कंटेनर के अंदर कोई समवर्ती प्रसंस्करण नहीं होता है, इसलिए १० कनेक्शन का पूल रखने का मतलब है कि ९ हमेशा निष्क्रिय रहेंगे और आपके डेटाबेस के P१४ सीमा को व्यर्थ में भरेंगे।
P१५ भी सेट करें। यदि कंटेनर चालू है लेकिन कोई अनुरोध नहीं आ रहा है, तो P१६ सेटिंग एक कनेक्शन को अनावश्यक रूप से खुला रखती है। P१७ के साथ, पूल निष्क्रियता समय के बाद कनेक्शन जारी कर देता है।
रणनीति ४: कोल्ड स्टार्ट कनेक्शन तूफ़ान को नियंत्रित करना
कोल्ड स्टार्ट के समय कनेक्शन की समस्या सबसे गंभीर होती है। ट्रैफ़िक स्पाइक के दौरान, लैम्ब्डा एक साथ सैकड़ों नए कंटेनर लॉन्च कर सकता है, और प्रत्येक कंटेनर उसी क्षण डेटाबेस कनेक्शन स्थापित करने का प्रयास करता है।
प्रोविजंड कॉन्करेंसी
एडब्ल्यूएस लैम्ब्डा की प्रोविजंड कॉन्करेंसी हर समय कंटेनरों की एक विशिष्ट संख्या को पहले से इनिशियलाइज़्ड और वॉर्म रखती है। इन कंटेनरों ने पहले से ही अपने डेटाबेस कनेक्शन स्थापित कर लिए होते हैं, इसलिए जब ट्रैफ़िक स्पाइक होता है, तो पहले से तैयार कंटेनर बिना कोल्ड स्टार्ट कनेक्शन तूफ़ान के शुरुआती अनुरोधों को संभाल लेते हैं।
P३
लागत: आप प्रोविजंड कंटेनरों के लिए भुगतान करते हैं भले ही वे निष्क्रिय हों (~$०.०००००४१६६७/जीबी-सेकंड)। ५० प्रोविजंड इंस्टेंस के साथ ५१२ एमबी फ़ंक्शन के लिए, यह लगभग $२.७०/दिन है। उत्पादन एपीआई के लिए यह लागत सार्थक है; बैच जॉब्स के लिए यह अनावश्यक है।
रिज़र्व्ड कॉन्करेंसी
यदि आप प्रॉक्सी का उपयोग नहीं कर सकते हैं और आपको डेटाबेस कनेक्शन पर एक सख्त सीमा की आवश्यकता है, तो अपने लैम्ब्डा फ़ंक्शन पर रिज़र्व्ड कॉन्करेंसी सेट करें ताकि यह आपके डेटाबेस की कनेक्शन सीमा से मेल खाए:
P४
यह सुनिश्चित करता है कि एक साथ १०० से अधिक लैम्ब्डा कंटेनर न चलें, जिसका अर्थ है अधिकतम १०० डेटाबेस कनेक्शन। इस सीमा से अधिक अनुरोधों को डेटाबेस क्रैश करने के बजाय थ्रॉटल (एचटीटीपी ४२९) कर दिया जाता है।
रणनीति ५: कनेक्शन की निगरानी करें
डेटाबेस स्तर पर क्या हो रहा है, यह देखने के लिए आपको निरंतर निगरानी की आवश्यकता है। कनेक्शन लीक और गलत तरीके से कॉन्फ़िगर किए गए पूल ऐसे छिपे हुए खतरे हैं जो केवल ट्रैफ़िक स्पाइक्स के दौरान सामने आते हैं।
पोस्टग्रेएसक्यूएल सक्रिय कनेक्शन निगरानी
कनेक्शन उपयोग को ट्रैक करने के लिए समय-समय पर इस क्वेरी को चलाएं (या इससे क्लाउडवॉच कस्टम मीट्रिक बनाएं):
P५
क्लाउडवॉच अलार्म
इन प्रमुख मीट्रिक्स पर अलार्म सेट करें:
- P१८ (आरडीएस मीट्रिक): जब कनेक्शन P१९ के ८०% से अधिक हो जाएं तो अलर्ट भेजें। यह विफलता शुरू होने से पहले सुधार का समय देता है।
- लैम्ब्डा P२० मीट्रिक: यदि आप सीमा के रूप में रिज़र्व्ड कॉन्करेंसी का उपयोग कर रहे हैं, तो थ्रॉटल दर की निगरानी करें ताकि पता चल सके कि मांग आपके कनेक्शन बजट से कब अधिक हो रही है।
- लैम्ब्डा P२१: वास्तविक समय में यह जानने के लिए समवर्ती इनवोकेशन्स की निगरानी करें कि आपके फ़ंक्शन को वास्तव में कितने डेटाबेस कनेक्शनों की आवश्यकता है।
टिप: फ़ंक्शन नाम और संस्करण शामिल करने के लिए अपने लैम्ब्डा फ़ंक्शन में P२२ कनेक्शन पैरामीटर सेट करें। यह P२३ आउटपुट को डिबगिंग के लिए तुरंत उपयोगी बनाता है।
P६
निष्कर्ष
सर्वरलेस आर्किटेक्चर को स्केल करने के लिए रिलेशनल डेटाबेस को प्रबंधित करने के तरीके पर मौलिक रूप से पुनर्विचार करने की आवश्यकता होती है। पारंपरिक सर्वर मॉडल, जहां प्रत्येक इंस्टेंस एक कनेक्शन पूल साझा करता है, सर्वरलेस में आपके खिलाफ काम करता है।
सुरक्षा की यह बहु-स्तरीय रणनीति निम्नलिखित का संयोजन करती है:
१. उचित कनेक्शन हैंडलिंग के साथ वॉर्म इनवोकेशन्स के बीच कनेक्शन का पुन: उपयोग करें। २. लैम्ब्डा समवर्ती प्रसंस्करण को डेटाबेस कनेक्शन से अलग करने के लिए एक कनेक्शन प्रॉक्सी (आरडीएस प्रॉक्सी या पीजीबाउंसर) का उपयोग करें। ३. प्रत्येक फ़ंक्शन के अंदर पूल आकार को P२४ तक सीमित करें। ४. कनेक्शन तूफ़ान को रोकने के लिए प्रोविजंड या रिज़र्व्ड कॉन्करेंसी के साथ समवर्ती प्रसंस्करण को नियंत्रित करें। ५. P२५ क्वेरी और क्लाउडवॉच अलार्म के साथ सक्रिय निगरानी करें।
कोई एक रणनीति अकेले काफी नहीं है। व्यावहारिक रूप से, सबसे मजबूत सर्वरलेस आर्किटेक्चर प्राथमिक सुरक्षा के रूप में प्रॉक्सी का उपयोग करते हैं और परिचालन सुरक्षा के लिए अन्य रणनीतियों को लागू करते हैं।