मूल पोस्ट में मार्कडाउन की बोली के कारण क्रॉस पोस्टिंग में कुछ समस्याएँ हैं। विशेष रूप से उन आरेखों को नहीं दिखाया गया है जो मूल पोस्ट में मौजूद हैं। तो अगर आप रुचि रखते हैं तो कृपया मूल एक को भी देखें। मुझे लगता है कि मूल एक अधिक समझ में आता है

HBase 3 सप्ताह में इवेंट सोर्सिंग और CQRS आर्किटेक्चर के शीर्ष पर अपग्रेड करता है

TL;DR

• हमने इवेंट सोर्सिंग और CQRS आर्किटेक्चर सिस्टम के शीर्ष पर HBase संस्करण अपग्रेड के लिए ब्लू-ग्रीन परिनियोजन रणनीति का उपयोग किया।
• परिनियोजन दृष्टिकोण ने काफी अच्छा काम किया और परियोजना लक्ष्य को पूरा करने में कुल मिलाकर केवल 3 सप्ताह लगे। यह अनुभव हमारे लिए नया और रोमांचक था। इसलिए मैं इसे साझा करना चाहता हूं :)

डेटाबेस अपग्रेड के बारे में

एक डेटाबेस अपग्रेड हमेशा परेशानी भरा होता है और जब भी आप उत्पादन परिदृश्यों में ऐसी परिस्थितियों से निपटते हैं तो आप बहुत घबरा जाते हैं (मैं अन्य उत्पादन कार्यों की तुलना में 100 बार कहूंगा) .

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

साथ ही, यह एक बड़ा छिपा हुआ जोखिम है यदि डेटाबेस "अछूत" हो जाता है और इस समस्या से कैसे निपटें यह एक विषय रहा है, कई डेवलपर्स और ऑपरेटर ऐसी स्थितियों से जूझ रहे हैं

अपग्रेड दृष्टिकोण

सामान्य तौर पर, आपके पास दो विकल्प होंगे।

रोलिंग अपग्रेड

एक रोलिंग अपग्रेड है। डेटाबेस संस्करण को क्रमिक रूप से एक-एक करके अपग्रेड करना।
मुझे यहां एक अच्छी व्याख्या मिली। अगर आप इस शब्द से परिचित नहीं हैं तो कृपया इसे पढ़ें।

सॉफ़्टवेयर विकास में रोलिंग अपग्रेड का क्या अर्थ है?

• पेशेवरों

  • डेटा एक ही स्थान पर है। इसलिए आपको यह सोचने की ज़रूरत नहीं है कि विभिन्न समूहों के बीच डेटा को कैसे सिंक किया जाए और कैसे गारंटी दी जाए कि सिंक पूरी तरह से काम कर रहा है।

• विपक्ष

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

नीला-हरा परिनियोजन

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

BlueGreenDeployment

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

• पेशेवरों

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

• विपक्ष

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

हमारा दृष्टिकोण

मूल रूप से, हमारा दृष्टिकोण नीला-हरा परिनियोजन है। और चूंकि हमारे पास इवेंट सोर्सिंग बस के रूप में काफ्का है, इसलिए ऊपर सूचीबद्ध "विपक्ष" में डेटा सिंक समस्या से निपटना बहुत आसान था।

वर्तमान वास्तुकला

सबसे पहले, मैं बुनियादी वास्तुकला का परिचय देता हूं। बीटीडब्ल्यू, हम पूरे चैट संदेश उप-प्रणाली को "फाल्कन" कहते हैं। यही कारण है कि फाल्कन आइकन आरेख में है।

1. जब कोई अंतिम उपयोगकर्ता चैट संदेश पोस्ट करता है, तो राइट-एपीआई संदेश डेटा को काफ्का में डाल देता है
2. रीड-मॉडल-अपडेटर (संक्षेप में "आरएमयू") काफ्का से डेटा प्राप्त करता है, इसे रीड-मॉडल में परिवर्तित करता है और इसे एचबेस में डालता है
3. जब कोई अंतिम उपयोगकर्ता चैट संदेशों को पढ़ता है, तो HBase से रीड-एपीआई पुल संदेश डेटा

मैं यह नहीं समझाता कि हम इस पोस्ट में CQRS क्यों चुनते हैं। इसलिए, यदि आप विस्तार से जानना चाहते हैं या यदि आप CQRS की अवधारणा से परिचित नहीं हैं, तो कृपया नीचे की स्लाइड्स देखें।
काफ्का शिखर सम्मेलन एसएफ 2017 - काफ्का और काफ्का धाराओं के साथ विश्वव्यापी स्केलेबल और लचीला संदेश सेवा
CQRS द्वारा वर्ल्डवाइड स्केलेबल और रेजिलिएंट मैसेजिंग सर्विसेज और अक्का, काफ्का स्ट्रीम्स और HBase का उपयोग करके इवेंट सोर्सिंग

डेटाबेस अपग्रेड प्रवाह

अब, मैं समझाऊंगा कि हमने इस आर्किटेक्चर के शीर्ष पर डेटाबेस अपग्रेड कैसे किया

चरण1: नए क्लस्टर तैयार करें और बैकअप से प्रारंभिक पुनर्स्थापना करें।

चरण2: काफ्का से नए डेटाबेस क्लस्टर में डेटा सिंक करने के लिए एक और उपभोक्ता (इस आरेख में rmu2) तैयार करें। आप पहले से शुरू होने वाले पुराने काफ्का इवेंट को फिर से चलाएंगे और फिर शुरुआती रिस्टोर करेंगे। सुनिश्चित करें कि आप अपने उपभोक्ता पर idempotency लागू करते हैं। मेरा मतलब है, सिस्टम को ठीक से काम करने की जरूरत है, भले ही एक ही घटना को एक से अधिक बार उपभोग किया गया हो।

चरण3: जब नए उपभोक्ता (rmu2) ने नवीनतम काफ्का संदेशों को पकड़ लिया है, तो नए डेटाबेस क्लस्टर से एक और रीड-एपीआई पुलिंग डेटा तैयार करें। और धीरे-धीरे नए रीड-एपीआई को अनुरोध भेजें।

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

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

चरण4: नए रीड-एपीआई 100% पर स्विच करें और जब आप सुनिश्चित हों कि सब कुछ पूरी तरह से काम करता है तो पुराने क्लस्टर और एप्लिकेशन बंद कर दें।

मुझे क्यों लगता है कि यह तरीका बेहतर है

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

पहला, क्योंकि वे अलग-अलग काम कर रहे हैं, आपको इस बात की परवाह करने की आवश्यकता नहीं है कि प्रत्येक चरण में डेटा कैसे समन्वयित किया जाता है। विशेष रूप से, यदि आप अपग्रेड के बाद वापस लौटने का एक आसान तरीका चाहते हैं, तो आपको नए क्लस्टर से पुराने क्लस्टर में डेटा को सिंक करने में कुछ अतिरिक्त (और ज्यादातर मामलों में काफी कठिन) प्रयास की आवश्यकता होगी। लेकिन इस दृष्टिकोण में, वे सिर्फ स्वतंत्र रूप से काम कर रहे हैं। इसलिए यदि अपग्रेड के बाद कुछ अनपेक्षित समस्या होने लगे तो आप पुराने का उपयोग करने के लिए वापस जा सकते हैं।

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

निष्कर्ष

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

अगली चुनौती

आपको आश्चर्य हो सकता है कि हम काफ्का (इवेंट सोर्सिंग बस) को क्या अपग्रेड करेंगे? हाँ, यह हमारी अगली चुनौती होगी। मुझे उम्मीद है कि सामान्य रोलिंग अपग्रेड और ब्लू-ग्रीन परिनियोजन से बेहतर दृष्टिकोण मौजूद है। इंजीनियर का जीवन चलता रहता है!