सही Amazon Aurora एंडपॉइंट चुनना: एक व्यावहारिक मार्गदर्शिका

Amazon Aurora एंडपॉइंट्स को समझना

यदि आपने कभी Aurora Read Replicas का उपयोग किया है, तो आपने देखा होगा कि कई अलग-अलग एंडपॉइंट्स उपलब्ध हैं: क्लस्टर एंडपॉइंट, रीडर एंडपॉइंट, और इंस्टेंस एंडपॉइंट्स। इन सभी विकल्पों के साथ, आप कैसे जानेंगे कि किसका उपयोग कब करना है? किसी भी गैर-तुच्छ प्रणाली की तरह, उत्तर है - यह निर्भर करता है। इस ब्लॉग पोस्ट में, हम विभिन्न एंडपॉइंट्स, उनके उपयोग के मामलों, और उन डिज़ाइन निर्णयों के साथ आने वाले ट्रेड-ऑफ्स को देखेंगे।

उपलब्ध Aurora एंडपॉइंट्स के प्रकार

• क्लस्टर एंडपॉइंट - यह एंडपॉइंट आपके एप्लिकेशन को उस DB क्लस्टर के वर्तमान प्राथमिक DB इंस्टेंस से जोड़ता है। आपका एप्लिकेशन इस इंस्टेंस पर पढ़ और लिख दोनों सकता है।
• रीडर एंडपॉइंट - यह एंडपॉइंट उपलब्ध Read Replicas के पूल में कनेक्शन को लोड-बैलेंस करता है। प्राथमिक DB इंस्टेंस पर भार कम करने के लिए रीड क्वेरीज़ को यहाँ भेजें।
• इंस्टेंस एंडपॉइंट्स - एक इंस्टेंस एंडपॉइंट क्लस्टर में एक विशिष्ट इंस्टेंस से जुड़ता है। क्लाइंट्स को क्वेरी आवंटन पर बारीक नियंत्रण मिलता है, बजाय इसके कि Amazon Aurora कनेक्शन वितरण को संभाले।

तत्काल स्थिरता

कुछ एप्लिकेशन्स डेटा के तत्काल स्थिर होने की अपेक्षा करते हैं। जब ये एप्लिकेशन डेटा लिखते हैं, तो वे कई डिज़ाइन पैटर्न के सख्त अनुपालन में तुरंत डेटा पढ़ते हैं जो कहते हैं, "मॉडल पर भरोसा करें, अपने स्थानीय डेटा पर नहीं"। Amazon Aurora ACID-अनुपालक है; एक सफल राइट कमिट के तुरंत बाद क्लस्टर एंडपॉइंट से पढ़ने पर अपेक्षित डेटा प्राप्त होगा (यह मानते हुए कि बाद के पढ़ने से पहले किसी अन्य लेनदेन ने डेटा को संशोधित नहीं किया)।

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

हालांकि, यदि अंतिम स्थिरता स्वीकार्य है और आपका एप्लिकेशन इसका समर्थन करता है, तो रीडर एंडपॉइंट का उपयोग करना आपके प्राथमिक इंस्टेंस पर भार कम करने का एक शानदार तरीका है।

रीड्स को ऑफलोड करना

यदि लिखने के तुरंत बाद रीड्स ठीक नहीं हैं, तो अलग रीडर एंडपॉइंट होने का क्या मतलब है? कई उपयोग-मामले हैं जहां थोड़ा असंगत डेटा कोई समस्या नहीं है। उदाहरण के लिए: दैनिक रिपोर्टिंग। कल के डेटा से रिपोर्ट जनरेट करने के लिए बैच जॉब्स चलाते समय, 100-मिलीसेकंड प्रतिकृति लैग महत्वहीन है। अन्य परिदृश्यों की कल्पना करना आसान है, जैसे ईकॉमर्स साइट पर उत्पाद विवरण... आपके उपयोगकर्ता के ब्राउज़र में पुराना डेटा होने की संभावना प्रतिकृति लैग से प्रभावित होने की तुलना में अधिक है।

आम तौर पर, रीड-हेवी वर्कलोड जो तत्काल स्थिरता पर भरोसा नहीं करते, उन्हें रीडर एंडपॉइंट का उपयोग करने पर विचार करना चाहिए।

गैर-समान वर्कलोड

ऐसी स्थितियाँ हैं जहां इंस्टेंस एंडपॉइंट्स का उपयोग करना समझ में आता है। मान लें कि आपके पास एक एप्लिकेशन है जिसमें Elastic Load Balancer के पीछे कई स्टेटलेस माइक्रोसर्विसेज हैं। इस स्थिति में, यह मानना उचित है कि क्वेरीज़ क्लाइंट्स में समान रूप से वितरित हैं, और इसलिए, रीडर एंडपॉइंट का उपयोग करते समय Read Replicas में भी।

लेकिन उस स्थिति का क्या जहां प्रत्येक क्लाइंट का वर्कलोड समान रूप से वितरित नहीं है? यदि मिश्रण में एक रिपोर्टिंग सर्विस जोड़ दी जाती है, तो एक Read Replica पर दूसरों की तुलना में असमान रूप से उच्च भार होता है। यदि ऊपर वर्णित माइक्रोसर्विसेज भी इस Read Replica का उपयोग करते हैं, तो रिपोर्टिंग सर्विस द्वारा उपयोग किए जा रहे इंस्टेंस को क्वेरी करते समय खराब क्वेरी प्रदर्शन की उच्च संभावना है। इससे बचने का एक दृष्टिकोण क्लाइंट साइड पर कनेक्शन के वितरण को प्रबंधित करना है, बजाय इसके कि Amazon Aurora आपके लिए ऐसा करे। सौभाग्य से, यह रीडर एंडपॉइंट के बजाय इंस्टेंस एंडपॉइंट्स का उपयोग करके आसानी से किया जाता है। MySQL के लिए MariaDB Connector/J या PostgreSQL के लिए Fast Failover के साथ, ड्राइवर को उन व्यक्तिगत इंस्टेंसेज़ के बारे में जागरूक किया जा सकता है जिन्हें आप Read Replicas के रूप में उपयोग करना चाहते हैं, जिससे ड्राइवर सीधे प्रबंधित कर सकता है कि क्वेरीज़ को व्यक्तिगत इंस्टेंसेज़ में कैसे वितरित किया जाए।

DNS कैशिंग प्रबंधित करें

अपने वर्कलोड की प्रकृति को समझने के अलावा, यह समझना महत्वपूर्ण है कि कनेक्शन कैसे आवंटित किए जाते हैं ताकि Aurora की उच्च उपलब्धता और रीडर एंडपॉइंट लोड बैलेंसिंग प्रदान की जा सके।

स्वचालित क्लस्टर एंडपॉइंट फेलओवर और रीडर एंडपॉइंट लोड बैलेंसिंग का प्रबंधन DNS (Amazon Route 53) के माध्यम से किया जाता है, IP, TCP, या डेटाबेस क्लाइंट प्रोटोकॉल लेयर्स पर नहीं। DNS के माध्यम से कनेक्शन वितरण को संभालने का मतलब है कि आपके एप्लिकेशन को प्रत्येक नए कनेक्शन अनुरोध के लिए DNS क्वेरी करनी होगी। जो एप्लिकेशन DNS कैशिंग का उपयोग करते हैं, उन्हें कैश टाइमआउट को Amazon Aurora के लिए DNS रिकॉर्ड TTL से मेल खाने के लिए समायोजित करना चाहिए। Aurora DNS रिकॉर्ड TTL से अधिक समय तक DNS प्रतिक्रियाओं को कैश करने से कुछ त्रुटि स्थितियाँ उत्पन्न होंगी। यदि उच्च-उपलब्धता (HA) फेलओवर इवेंट होता है, यानी एक Read Replica को प्राथमिक बनाया जाता है, तो एक कैश्ड DNS प्रतिक्रिया का मतलब होगा कि आपका एप्लिकेशन पुराने, विफल इंस्टेंस से पुनः कनेक्ट करने का प्रयास करेगा। रीडर एंडपॉइंट के मामले में, DNS प्रतिक्रिया को कैश करने के परिणामस्वरूप कई कनेक्शन एक विशिष्ट Read Replica पर जाएंगे बजाय उपलब्ध Read Replicas में वितरित होने के।

निष्कर्ष

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

अपने एप्लिकेशन की प्रकृति को समझना, Aurora एंडपॉइंट्स कैसे व्यवहार करते हैं, और उस ज्ञान को सही ढंग से लागू करना एक अधिक मजबूत एप्लिकेशन वातावरण की ओर ले जाएगा, जो आपके और आपके ग्राहकों के लिए बहुत महत्वपूर्ण है। कोई भी आधी रात को आउटेज कॉल नहीं चाहता।