Amazon Aurora उच्च-उपलब्धता रणनीतियाँ: एक व्यापक मार्गदर्शिका

Amazon Aurora और उच्च उपलब्धता

यदि आप इसे पढ़ रहे हैं, तो आपने शायद Amazon Aurora के बारे में सुना होगा। जैसा कि आप जानते हैं, Amazon Aurora AWS द्वारा RDS सेवाओं के सूट के हिस्से के रूप में प्रदान की जाने वाली एक PaaS सेवा है। यह एक पूरी तरह से प्रबंधित संबंधात्मक डेटाबेस प्रबंधन प्रणाली (RDBMS) प्रदान करता है जो दो फ्लेवर्स में आती है: MySQL और PostgreSQL, जबकि दोनों के साथ वायर संगतता बनाए रखती है। लेकिन यह आपकी उच्च उपलब्धता रणनीतियों और विकल्पों को कैसे प्रभावित करता है?

चिंताओं का पृथक्करण

आम तौर पर, एक RDBMS को आम तौर पर उपलब्ध हार्डवेयर पर चलना पड़ता है। इसका मतलब है कि कार्यान्वयन को OS और हार्डवेयर द्वारा लगाई गई सीमाओं के भीतर काम करना होगा ताकि उन सभी सुविधाओं को पूरा किया जा सके जिनकी हम एक आधुनिक डेटाबेस से उम्मीद करते हैं, जैसे: DML और DDL प्रोसेसिंग, ACID-अनुपालक लेनदेन, प्रतिकृति, उच्च-उपलब्धता (HA), और फॉल्ट टॉलरेंस। यदि, हालांकि, कार्यान्वयन को आम तौर पर उपलब्ध हार्डवेयर पर चलने की आवश्यकता नहीं थी बल्कि केवल एक ऐसे वातावरण में जो विशेष रूप से डेटाबेस के लिए डिज़ाइन किया गया था, तो विभिन्न जिम्मेदारियों को परतों में अलग किया जा सकता था, जिससे डेटाबेस इंजन और स्टोरेज इंजन केंद्रित और विशिष्ट हो सकते थे। परिणामस्वरूप, उच्च-उपलब्धता और प्रदर्शन को काफी बढ़ाया जा सकता है - मानक MySQL से 5 गुना अधिक प्रदर्शन और मानक PostgreSQL से 3 गुना अधिक।

ठीक है, यह तेज़ है, लेकिन एक विशिष्ट डेटाबेस और स्टोरेज इंजन HA के साथ कैसे मदद करता है? कई तरीके हैं जिनसे यह हमें HA प्राप्त करने में मदद करता है। इससे पहले कि हम उसमें जाएं, आइए जल्दी से देखें कि Aurora स्टोरेज इंजन कैसे काम करता है ताकि हम समझ सकें कि HA इस पृथक्करण से कैसे प्राप्त होता है।

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

डेटाबेस इंजन से स्टोरेज चिंता को हटाकर, कई HA रणनीतियाँ उपलब्ध हो जाती हैं।

रीड रेप्लिकाज़

जबकि Read Replicas की अवधारणा Aurora से बहुत पहले की है, ओपन-सोर्स समाधानों में कार्यान्वयन में लॉग शिपिंग या क्वेरी रीप्ले शामिल हैं। Aurora के साथ, Read Replicas को मास्टर के समान स्टोरेज के लिए रीड-ओनली एक्सेस होता है। इसका मतलब है कि डेटा लिखे जाने से लेकर Read Replica को दिखाई देने तक बहुत कम प्रतिकृति विलंबता (इस परिदृश्य में प्रतिकृति लैग एक मिथ्या नाम होगा)। जब कई Read Replicas की आवश्यकता होती है, तो सभी Read Replicas समान डेटा देखते हैं, जिससे मास्टर पर ओवरहेड और जटिलता दूर हो जाती है, जो मानक MySQL और PostgreSQL कार्यान्वयन में पाई जाती है। ये सुविधाएँ एक साथ मिलकर एक Read Replica को तुरंत संभालने की अनुमति देती हैं यदि मास्टर विफल हो जाता है। इसके अलावा, AWS प्रावधानित क्षमता को पूरा करने के लिए एक नए इंस्टेंस के साथ विफल इंस्टेंस को बदलने और DNS को नए मास्टर पर इंगित करने के लिए अद्यतन करता है।

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

ऑटोस्केलिंग

ऑटोस्केलिंग आपके उपलब्ध सर्वरों के सेट से क्षैतिज रूप से स्केल आउट (इंस्टेंस जोड़ना) या स्केल इन (इंस्टेंस हटाना) करने की क्षमता है। आपने EC2 इंस्टेंसेज़ के लिए ऑटोस्केलिंग के बारे में सुना होगा, लेकिन क्या आप जानते हैं कि आप अपने Aurora Read Replicas में भी लोच रख सकते हैं? आमतौर पर, आप अपने बेस लोड को संभालने के लिए न्यूनतम संख्या में Read Replicas कॉन्फ़िगर करेंगे और मांग बदलने पर इंस्टेंस जोड़ने या हटाने के लिए ऑटोस्केलिंग नीतियाँ रखेंगे। लोच का लाभ उठाने की क्षमता इस तथ्य का एक और व्युत्पन्न है कि स्टोरेज इंजन डेटाबेस इंजन से अलग है।

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

क्रॉस-रीजन प्रतिकृति

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

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

बाह्य प्रतिकृति

उन स्थितियों के बारे में क्या जहां आपको Aurora क्लस्टर के बाहर डेटा की आवश्यकता है? ऐसी स्थितियाँ हैं जहां कॉर्पोरेट नीतियाँ या नियामक वातावरण इसकी मांग करते हैं, या आपको डेटा को प्रोसेस करने या Aurora के बाहर रिपोर्ट चलाने की आवश्यकता है। इन सभी मामलों को बाह्य प्रतिकृति का उपयोग करके संभाला जा सकता है।

Amazon EC2 MySQL इंस्टेंस, MySQL चलाने वाले Amazon EC2 इंस्टेंस, या यहां तक कि आपके कॉर्पोरेट डेटा सेंटर में चल रहे MySQL इंस्टेंस में Aurora को डेटा दोहराना आसान है। इस एक-तरफा प्रतिकृति का उपयोग करके, आपका डेटा हमेशा आपके Aurora क्लस्टर के साथ सिंक में रहता है और Aurora के बाहर उपयोग के लिए उपलब्ध होता है।

सर्वरलेस

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

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

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

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

निष्कर्ष

Amazon Aurora को उपलब्धता, स्थायित्व, और मापनीयता को ध्यान में रखकर बनाया गया है। यदि मानक ओपन-सोर्स कार्यान्वयन की तरह उपयोग किया जाता है, तो आपके पास एक ठोस, विश्वसनीय, और प्रदर्शनकारी डेटाबेस है। Aurora की क्षमताओं और उनका लाभ उठाने के पैटर्न पर थोड़ी गहरी नज़र डालकर, आप स्थानीय रीड ऑफलोडिंग से लेकर विश्व स्तर पर वितरित उपलब्धता तक, अपनी आवश्यकताओं को पूरा करने के लिए एक समाधान लागू कर सकते हैं।