कुबेरनेट्स द्वारा ऑर्केस्ट्रेटेड कंटेनरों में बुनियादी ढाँचे को क्लासिक वीएम से कैसे स्थानांतरित करें

यह ब्लॉग पोस्ट इस बारे में है कि कैसे चार्ट मोगुल DigitalOcean पर अपने बुनियादी ढांचे के अंतिम टुकड़ों को सेवानिवृत्त कर दिया, AWS में इसके प्रवास को पूर्ण के रूप में चिह्नित किया।

यह यात्रा आपकी नियमित AWS माइग्रेशन नहीं थी क्योंकि इसमें हमारे बुनियादी ढांचे को क्लासिक VMs से कुबेरनेट्स द्वारा ऑर्केस्ट्रेटेड कंटेनरों में ले जाना शामिल था।

लेखों की एक श्रृंखला में, हम इसके बारे में अपने अनुभव साझा करेंगे:

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

DigitalOcean के साथ जीवन

2014 में हमारी स्थापना के बाद से और 2021 के मध्य तक, हमारा पूरा बुनियादी ढांचा DigitalOcean बूंदों (स्व-प्रबंधित क्लाउड वर्चुअल मशीन) पर चला है। हमें एक क्लाउड प्रदाता की आवश्यकता थी जो हमें शीघ्रता से, भरोसेमंद और लागत-प्रभावी ढंग से जमीन पर उतार सके।

DigitalOcean ने बहुत समझदारी की और एक बढ़िया विकल्प था। हम जहां हैं, उन्हीं की वजह से हैं। उस विकल्प ने हमें स्केलेबिलिटी और बुनियादी ढांचे की जटिलता के बारे में चिंता किए बिना उत्पाद निर्माण पर ध्यान केंद्रित करने की स्वतंत्रता दी - ऐसे पहलू जो आमतौर पर बाद के चरण में आते हैं।

हमारे बुनियादी ढांचे के हर पहलू को आंतरिक रूप से व्यवस्थित, कॉन्फ़िगर और प्रबंधित किया गया था। हमने चीजों को प्रबंधित करने के लिए कॉन्फ़िगरेशन प्रबंधन और इन्फ्रास्ट्रक्चर को कोड टूल्स (साल्टस्टैक और टेराफॉर्म) के रूप में इस्तेमाल किया।

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

क्यों ले जाएँ और अब क्यों?

DigitalOcean एक बेहतरीन विकल्प के रूप में, हमारा जैविक विकास वर्षों से हमारे सेटअप की सीमाओं को आगे बढ़ा रहा था। हमें कई क्षेत्रों में चुनौतियों का सामना करना पड़ा, कुछ ठीक करने योग्य और रोकने योग्य, कुछ नहीं।

विभिन्न विफलताएं

• तदर्थ अघोषित रखरखाव विंडो जिसने अचानक उत्पादन को तोड़ दिया।

  
  

• कई मौकों पर हार्डवेयर की विफलता, हमारे प्राथमिक - प्रतिकृति डेटाबेस सेटअप को प्रभावित करती है (उदाहरण के लिए, बिना किसी सूचना के "अन्य हार्डवेयर मशीनों के लिए लाइव माइग्रेशन स्थिति" में प्रवेश करने वाली बूंदें, जिसका अर्थ है कि उस छोटी बूंद के लिए 1-2 घंटे का डाउनटाइम।)

  
  

• हमारी मशीनों के बीच विलंबता के साथ अस्पष्टीकृत नेटवर्किंग समस्याएँ जिन्हें DigitalOcean की सहायता टीम ने कभी भी साफ़ नहीं किया (यह हमारे पोस्टग्रेज़ रीड-रेप्लिकस लैग, रेडिस इंस्टेंस और सामान्य रूप से HA के लिए महत्वपूर्ण था)।

AMS2 क्षेत्र बहिष्करण

हमारे DigitalOcean क्षेत्र (AMS2) को "जल्द ही सेवानिवृत्त होने वाले" के रूप में घोषित किया गया था, जिसका अर्थ है सीमित समर्थन। हम मांग पर अतिरिक्त संसाधनों को सुरक्षित नहीं कर सके, और साधारण कार्यों को क्रियान्वित करने का मतलब आमतौर पर लंबी योजना बनाना और संसाधनों को बर्बाद करना था।

पोस्टग्रेज संस्करण को अपग्रेड करने और कार्य करने के लिए एक नई मशीन का प्रावधान करने जैसी साधारण चीजें करना असंभव होता जा रहा था।

सीमित हार्डवेयर विकल्प

सब्सक्रिप्शन एनालिटिक्स स्पेस में होने का मतलब है डेटा-गहन संचालन, बड़ी मात्रा में, और अक्सर तदनुसार स्केल करने की क्षमता।

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

आधुनिक क्लाउड सुविधाओं और प्रबंधित सेवाओं का अभाव

विकास दर (और एक साथ तकनीकी ऋण से निपटने) को बनाए रखने के लिए हमारे बुनियादी ढांचे को बनाए रखने के लिए परिचालन कार्य की मात्रा में वृद्धि हुई है।

हमें अपने सेटअप पर कड़ी नज़र रखनी थी और यह समझना था कि क्या एक अलग DigitalOcean क्षेत्र में जाना या एक नया क्लाउड प्रदाता सबसे अच्छा विकल्प था।

हमें रहना चाहिए या जाना चाहिए?

हमने DigitalOcean के साथ रहने और बस एक नए क्षेत्र में जाने के लाभों को देखना शुरू कर दिया - एक अधिक इत्मीनान से, तेज, सस्ता, कम दर्दनाक विकल्प।

लेकिन साथ ही, हमने इस कदम को अपेक्षित उपयोगकर्ता वृद्धि और प्रगति की बढ़ी हुई दर की सेवा में अपने स्टैक के कुछ हिस्सों को आधुनिक बनाने के अवसर के रूप में माना।

हमारे मूल्यांकन के अंत तक, हमने महसूस किया कि विशिष्ट आवश्यकताओं की आवश्यकताओं को रहने और बस क्षेत्रों को बदलने से प्राप्त करना कठिन होगा। सबसे महत्वपूर्ण थे:

• ऑटो-स्केलिंग कंप्यूट संसाधनों में लचीलापन।

• प्रबंधित डेटाबेस।

• अस्थायी उपयोग के आधार पर संसाधनों का प्रावधान।

• कम (एर) विलंबता।

• सर्विस इंटरऑपरेबिलिटी।

• कुबेरनेट्स ऑर्केस्ट्रेशन के साथ कंटेनर-आधारित बुनियादी ढाँचा।

  
  

पिछले खंड में सूचीबद्ध चुनौतियों के साथ आवश्यकताओं की इस सूची ने स्विचिंग प्रदाताओं के पक्ष में पैमाने को इत्तला दे दी।

एडब्ल्यूएस क्यों?

चार्टमोगुल इन्फ्रास्ट्रक्चर को शक्ति प्रदान करने के लिए एक नया क्लाउड प्रदाता चुनना एक लंबी यात्रा थी। हमने बाजार पर शोध किया और कई ट्रेडऑफ़ और लाभों की खोज की जो एक नया प्रदाता तालिका में ला सकता है।

हमारे विकल्प थे Amazon Web Services (AWS), Google Cloud (GCP), और Azure। आखिरकार, हमने एडब्ल्यूएस के साथ जाने का फैसला किया। हम नीचे कुछ मुख्य कारणों की सूची दे रहे हैं।

टीम विशेषज्ञता

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

अनुमापकता

• हम एक बटन के पुश पर AWS इंस्टेंस को ऊपर या नीचे रैंप कर सकते हैं।

  
  

• हम आरडीएस डेटाबेस जैसे संसाधनों का तत्काल प्रावधान कर सकते हैं और अस्थायी रूप से संसाधनों की गणना कर सकते हैं।

  
  

• हम प्रयोगों और अवधारणाओं के प्रमाण के माध्यम से जल्दी से पुनरावृति कर सकते हैं।

  
  

• EC2 ऑटो-स्केलिंग द्वारा समर्थित कुबेरनेट्स नोड पूल के लचीलेपन और मापनीयता को हरा पाना मुश्किल है।

डेटा सुरक्षा और अनुपालन

डेटा सुरक्षा हमेशा दिमाग में सबसे ऊपर रही है। इन वर्षों में, AWS सुरक्षा क्षमताओं में काफी वृद्धि हुई है।

डेटा सुरक्षा के इर्द-गिर्द विकसित की गई नई सेवाओं की संख्या कंटेनर/कुबेरनेट्स स्पेस में हमारी अधिकांश जरूरतों को पूरा करती है।

वे अच्छी तरह से स्थापित सेवाओं जैसे कि निजी वीपीसी अलगाव, नीतियों के बढ़िया नियंत्रण और आईएएम भूमिकाओं के साथ अच्छी तरह से खेलते हैं।

अनुपालन के लिहाज से, हम जल्द से जल्द एसओसी II प्रमाणित बनने की योजना बना रहे हैं, और हमने पाया कि एडब्ल्यूएस अनुपालन कार्यक्रम एक ऐसे लाभ के रूप में हैं जो उस यात्रा को तेजी से ट्रैक करने में मदद कर सकते हैं।

प्रबंधित सेवाएं

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

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

प्रबंधित कुबेरनेट्स विचार करने के लिए एक और प्रमुख कारक था, और यह Google क्लाउड (जीसीपी) के साथ आमने-सामने था। Google के प्रबंधित Kubernetes (GKE) उस समय AWS की तुलना में बेहतर महसूस करते थे, लेकिन RDS की तुलना CloudSQL से करना सुविधा-वार के करीब नहीं था।

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

एडब्ल्यूएस सेवाओं की पागल संख्या

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

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

आपदा बहाली

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

एडब्ल्यूएस क्रेडिट

हमने AWS स्टार्टअप प्रोग्राम के माध्यम से $100k मूल्य का क्रेडिट हासिल किया। हम काफी खर्च के बिना अपने प्रवास की योजना बनाने, परीक्षण करने और उसे पूरा करने में सक्षम थे।

एडब्ल्यूएस में स्थानांतरण

DigitalOcean से AWS में हमारा प्रवास दस महीने की लंबी यात्रा थी। पूरे प्रयास को हमारी सभी इंजीनियरिंग टीमों के स्वयंसेवकों द्वारा समर्थित किया गया था और एक DevOps इंजीनियर, एक बैकएंड इंजीनियर और हमारे इंजीनियरिंग के प्रमुख द्वारा संचालित किया गया था।

कुछ चीजों में परीक्षण और त्रुटि शामिल थी। हमने इसके कई तरीके आजमाए:

• लगभग शून्य डाउनटाइम के साथ डेटा को पोस्टग्रेज से आरडीएस में स्थानांतरित करना।

  
  

• हमारे ऐप और सेवाओं को वीएम-आधारित आर्किटेक्चर से कुबेरनेट्स में कंटेनरीकृत में स्थानांतरित करना।

  
  

• मौलिक रूप से हम जिस तरह से तैनात करते हैं उसे बदल रहे हैं।

एक सही योजना थी, और कागज पर जाने के लिए सब कुछ अच्छा लग रहा था, लेकिन हमने कठिन तरीके से सीखा कि चीजें हमेशा योजना के अनुसार नहीं होंगी।

कभी-कभी, हमारा लगभग-शून्य डाउनटाइम माइग्रेशन लक्ष्य गंभीर जोखिम में था, और हम वापस ड्राइंग बोर्ड पर चले गए।

दृढ़ता, ड्राइव और शानदार टीम प्रयास ने हमें उन चुनौतियों से पार पाने में मदद की जिनका हमने सामना किया।

सावधानीपूर्वक योजना ने चमत्कार भी किया; हमारी क्षमता को देखते हुए, हमने पहले ही यह स्थापित कर लिया था कि वास्तविक प्रवास को तीन चरणों (या दिनों) में तोड़ना सबसे अच्छा काम करेगा।

सप्ताह पूर्व डी-डे

• DigitalOcean से RDS इंस्टेंस के लिए पोस्टग्रेज प्रतिकृति प्रारंभ करें।
• हमारे एडब्ल्यूएस भविष्य के उत्पादन बुनियादी ढांचे की समीक्षा करें।
• रहस्यों का विन्यास (एडब्ल्यूएस पैरामीटर स्टोर)।
• सुनिश्चित करें कि CI/CD पाइपलाइन हमारे नए Kubernetes क्लस्टर में तैनात करने के लिए तैयार हैं।

डी-डे से पहले का दिन

• हमारे एडब्ल्यूएस अस्थायी वेबहुक रिकॉर्डर इन्फ्रास्ट्रक्चर तैयार करें (हमारे प्रवास के दौरान घटनाओं को खोना एक विकल्प नहीं था)।

  
  

• कुछ डेटा पहले से ले जाएं (उदाहरण के लिए, DigitalOcean Spaces से S3)।

  
  

• सभी पैरामीटर स्टोर सीक्रेट्स को प्रोडक्शन वैल्यू में अपडेट करें।

  
  

• डीएनएस परिवर्तन तैयार करें।

  
  

• सेवाओं को माइग्रेशन के दौरान उत्पादन डेटा तक पहुँचने से रोकने के लिए सभी Kubernetes परिनियोजन को शून्य पॉड पर सेट करें।

डी-डे: स्विच फ़्लिक करना

• सभी वेबहुक को AWS अस्थायी रिकॉर्डर पर पुनर्निर्देशित करें।

  
  

• DigitalOcean पर सभी सेवाओं को बंद करें।

  
  

• नवीनतम अपडेट को पकड़ने के लिए पोस्टग्रेज प्रतिकृति की प्रतीक्षा करें।

  
  

• DigitalOcean और RDS पोस्टग्रेज डेटा की तुलना करें (अखंडता और प्रतिकृति पकड़ सुनिश्चित करने के लिए)।

  
  

• DigitalOcean में चल रहे RDS से Postgres की सदस्यता छोड़ें।

  
  

• RDS रीड रेप्लिकेशंस बनाएं।

  
  

• नए आरडीएस एंडपॉइंट और रहस्यों के साथ हमारे पैरामीटर स्टोर रहस्यों को अपडेट करें।

  
  

• Kubernetes पर परिनियोजित करें और नए कॉन्फ़िगरेशन लोड करने के लिए PgBouncer को पुनरारंभ करें।

  
  

• app.chartmogul.com के DNS रिकॉर्ड्स को AWS में बदलें।

  
  

इस बिंदु पर, हम अपने उत्पादन कार्यभार को चमकदार नए बुनियादी ढांचे पर चला रहे थे! हमने पूरे काम को 10 घंटे में पूरा किया (हमने शुरू में 8 घंटे का अनुमान लगाया था - बहुत बुरा नहीं)।

एडब्ल्यूएस के साथ चुनौतियां

सबसे बड़ा संघर्ष डीएमएस सेवा (डेटाबेस को आरडीएस में स्थानांतरित करने के लिए एडब्ल्यूएस प्रबंधित सेवा) के साथ था।

इसका उपयोग करना उतना आसान नहीं था जितना कि विज्ञापित। पोस्टग्रेज के मामले में, यह मददगार नहीं था। आखिरकार, हमने डेटा को AWS में ले जाने का एक कस्टम तरीका विकसित किया।

हमें यह भी कठिन अहसास हुआ कि शून्य डाउनटाइम वाले डेटाबेस को वेबहुक समर्थन के साथ AWS में ले जाना जटिल है। हमने इस सेटअप का समर्थन करने के लिए एक कस्टम दृष्टिकोण विकसित किया है।

भविष्य के लेखों में इन कस्टम दृष्टिकोणों पर अधिक।

श्रृंखला में भविष्य के लेख

DigitalOcean से AWS तक हमारी प्रवास यात्रा का दस्तावेजीकरण करने वाले भविष्य के लेखों को देखें। हम जैसे विषयों पर स्पर्श करेंगे:

• चार्टमोगुल को सत्ता में लाने के लिए हमने कुबेरनेट्स को क्यों चुना।
• हमने PostgreSQL को RDS में कैसे माइग्रेट किया।
• हमने अपने रेल ऐप को कुबेरनेट्स में कैसे माइग्रेट किया।
• हम AWS VPC के लिए IPSEC सुरंग कैसे स्थापित करते हैं।