🏘️ 🧒🏾 😡 मानगो से पोस्टग्रेज में पलायन: द गार्जियन अखबार का अनुभव 👦🏿 🐂 🤰🏿

द गार्जियन सबसे बड़े ब्रिटिश समाचार पत्रों में से एक है, इसकी स्थापना 1821 में हुई थी। लगभग 200 वर्षों के अस्तित्व के लिए, संग्रह ने एक उचित राशि जमा की है। सौभाग्य से, यह सब साइट पर संग्रहीत नहीं है - सिर्फ पिछले कुछ दशकों में। डेटाबेस, जिसे स्वयं ब्रिटिश ने सभी ऑनलाइन सामग्री के लिए "सत्य का स्रोत" कहा था, में लगभग 2.3 मिलियन तत्व शामिल हैं। और एक बिंदु पर, उन्होंने महसूस किया कि मोंगो से पोस्टग्रेज एसक्यूएल में प्रवास करने की आवश्यकता है - 2015 में एक जुलाई जुलाई के दिन के बाद, विफलता प्रक्रियाओं का गंभीर परीक्षण किया गया था। प्रवासन में लगभग 3 साल लग गए! ...

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

भाग एक: शुरुआत

गार्जियन में, लेख, ब्लॉग, फोटो गैलरी और वीडियो सहित अधिकांश सामग्री, हमारे अपने सीएमएस, संगीतकार के भीतर निर्मित होती है। कुछ समय पहले तक, संगीतकार ने एडब्ल्यूएस-आधारित मानगो डीबी के साथ काम किया। यह डेटाबेस मूल रूप से सभी गार्जियन ऑनलाइन सामग्री के लिए "सत्य का स्रोत" था - लगभग 2.3 मिलियन तत्व। और हमने बस Monggr से Postgres SQL में माइग्रेशन पूरा किया।

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

हीट: फव्वारे पर नाचने के लिए अच्छा है, डेटा सेंटर के लिए विनाशकारी। फोटो: सारा ली / गार्जियन

तब से, AWS के लिए गार्जियन प्रवास जीवन और मृत्यु का विषय बन गया है। क्लाउड पर माइग्रेट करने के लिए, हमने OpsManager , Mongo DB प्रबंधन सॉफ्टवेयर खरीदने का फैसला किया, और एक Mongo तकनीकी सहायता अनुबंध पर हस्ताक्षर किए। हमने बैकअप, ऑर्केस्ट्रेट का प्रबंधन करने और हमारे डेटाबेस क्लस्टर की निगरानी करने के लिए OpsManager का उपयोग किया।

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

AWS में परिवर्तन के बाद से, डेटाबेस की समस्याओं के कारण हमारे पास दो महत्वपूर्ण क्रैश हुए हैं, जिनमें से प्रत्येक ने कम से कम एक घंटे के लिए theguardian.com पर प्रकाशन की अनुमति नहीं दी। दोनों मामलों में, न तो ऑप्समैनगर और न ही मैंगो तकनीकी सहायक कर्मचारी हमें पर्याप्त सहायता प्रदान करने में सक्षम थे, और हमने खुद समस्या का हल किया - एक मामले में, हमारी टीम के एक सदस्य के लिए धन्यवाद जो अबू धाबी के बाहरी इलाके में रेगिस्तान से टेलीफोन द्वारा स्थिति से निपटने में कामयाब रहे।

समस्याग्रस्त मुद्दों में से प्रत्येक एक अलग पद के हकदार हैं, लेकिन यहां सामान्य बिंदु हैं:

समय पर पूरा ध्यान दें - अपने VPC तक पहुँच को इस हद तक अवरुद्ध न करें कि NTP काम करना बंद कर दे।
एप्लिकेशन स्टार्टअप पर स्वचालित रूप से डेटाबेस इंडेक्स बनाना एक बुरा विचार है।
डेटाबेस प्रबंधन अत्यंत महत्वपूर्ण और कठिन है - और हम इसे स्वयं नहीं करना चाहेंगे।

ऑप्समैनगर ने सरल डेटाबेस प्रबंधन के अपने वादे को नहीं रखा। उदाहरण के लिए, OpsManager का वास्तविक प्रबंधन - विशेष रूप से, OpsManager संस्करण 1 से संस्करण 2 तक का अद्यतन - हमारे OpsManager सेटअप के बारे में बहुत समय और विशेष ज्ञान की आवश्यकता है। वह मानगो डीबी के विभिन्न संस्करणों के बीच प्रमाणीकरण योजना में बदलाव के कारण "एक-क्लिक अपडेट" के अपने वादे को पूरा करने में भी विफल रहा। हमने डेटाबेस के प्रबंधन के लिए प्रति वर्ष इंजीनियरों के कम से कम दो महीने खो दिए।

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

डेटाबेस के प्रबंधन के लिए न्यूनतम प्रयास।
बाकी पर एन्क्रिप्शन।
मोंगो के साथ एक स्वीकार्य प्रवास पथ।

चूंकि हमारी सभी अन्य सेवाएँ AWS चल रही हैं, इसलिए स्पष्ट विकल्प डायनमो, अमेज़न का NoSQL डेटाबेस है। दुर्भाग्य से, उस समय, डायनेमो ने आराम पर एन्क्रिप्शन का समर्थन नहीं किया। इस सुविधा को जोड़ने के लिए लगभग नौ महीने इंतजार करने के बाद, हमने AWS RDS पर Postgres का उपयोग करने का निर्णय लेकर इस विचार को छोड़ दिया।
"लेकिन Postgres एक दस्तावेज़ भंडार नहीं है!" - आप आक्रोश में हैं ... ठीक है, हाँ, यह डॉक रिपॉजिटरी नहीं है, लेकिन इसमें JSONB कॉलम के समान टेबल हैं, जो JSON ब्लॉब टूल के क्षेत्रों में अनुक्रमित के लिए समर्थन के साथ है। हमें उम्मीद थी कि JSONB का उपयोग करके हम अपने डेटा मॉडल में न्यूनतम बदलाव के साथ Mongo से Postgres की ओर पलायन कर पाएंगे। इसके अलावा, अगर हम भविष्य में और अधिक रिलेशनल मॉडल में जाना चाहते हैं, तो हमारे पास ऐसा अवसर होगा। पोस्टग्रेज के बारे में एक और बढ़िया बात यह है कि इसने कितनी अच्छी तरह काम किया: हमारे पास हर सवाल के लिए, ज्यादातर मामलों में जवाब पहले से ही स्टैटर ओवरफ्लो में दिया गया था।

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

भाग दो: दो दशकों की सामग्री प्रवासन बिना डाउनटाइम के चली गई

योजना

अधिकांश डेटाबेस माइग्रेशन समान क्रियाओं का संकेत देते हैं, और हमारा कोई अपवाद नहीं था। यहाँ हमने क्या किया:

एक नया डेटाबेस बनाया गया।
उन्होंने एक नए डेटाबेस (नए एपीआई) को लिखने का एक तरीका बनाया।
हमने एक प्रॉक्सी सर्वर बनाया जो मुख्य के रूप में पुराने का उपयोग करते हुए पुराने और नए डेटाबेस दोनों को ट्रैफ़िक भेजता है।
पुराने डेटाबेस से नए में रिकॉर्ड किए गए।
उन्होंने नए डेटाबेस को मुख्य बनाया।
पुराने डेटाबेस को हटा दिया गया।

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

नई एपीआई

जुलाई 2017 के अंत में नए पोस्टग्रेज-आधारित एपीआई पर काम शुरू हुआ। यह हमारी यात्रा की शुरुआत थी। लेकिन यह समझने के लिए कि यह कैसे था, हमें पहले स्पष्ट करना चाहिए कि हमने कहाँ शुरू किया था।

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

कुछ विश्लेषण के बाद, हम इस निष्कर्ष पर पहुंचे कि इससे पहले कि हम मौजूदा सामग्री को माइग्रेट कर सकें, हमें पुराने API को चालू रखते हुए नए PostgreSQL डेटाबेस से संपर्क करने का एक तरीका चाहिए। आखिरकार, मानगो डीबी हमारा "सत्य का स्रोत" है। नए API के साथ प्रयोग करते समय उसने हमें एक जीवन रेखा के रूप में कार्य किया।

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

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

अगस्त 2017 के अंत तक, हमारे पास एक नया एपीआई तैनात था जो अपने डेटाबेस के रूप में PostgreSQL का उपयोग करता था। लेकिन वह केवल शुरुआत थी। मानगो डीबी में ऐसे लेख हैं जो पहली बार दो दशक पहले बनाए गए थे, और उन सभी को पोस्टग्रेज डेटाबेस में माइग्रेट करना था।

प्रवास

हमें साइट पर किसी भी लेख को संपादित करने में सक्षम होना चाहिए, चाहे वह कब प्रकाशित हुआ हो, इसलिए हमारे डेटाबेस में "सत्य का स्रोत" के रूप में सभी लेख मौजूद हैं।

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

मूल प्रवास क्रम निम्नानुसार था:

मोंगो से सामग्री प्राप्त करें।
पोस्टग्रेज को पोस्ट कंटेंट।
Postgres से सामग्री प्राप्त करें।
सुनिश्चित करें कि उनके उत्तर समान हैं।

डेटाबेस माइग्रेशन तभी सफल माना जा सकता है जब एंड यूजर्स ने इस बात पर गौर नहीं किया हो कि ऐसा हुआ है, और एक अच्छी माइग्रेशन स्क्रिप्ट हमेशा ऐसी सफलता की कुंजी होगी। हमें एक स्क्रिप्ट की जरूरत थी जो:

HTTP अनुरोधों को निष्पादित करें।
सुनिश्चित करें कि कुछ सामग्री को माइग्रेट करने के बाद, दोनों एपीआई की प्रतिक्रिया समान है।
जब कोई त्रुटि होती है, तो रोकें।
समस्याओं के निदान के लिए एक विस्तृत ऑपरेशन लॉग बनाएँ।
सही बिंदु से एक त्रुटि के बाद पुनरारंभ करें।

हमने अमोनिट का उपयोग करके शुरू किया। यह आपको स्काला भाषा में स्क्रिप्ट लिखने की अनुमति देता है, जो हमारी टीम का मूल है। यह कुछ ऐसा प्रयोग करने का एक अच्छा अवसर था जिसे हमने पहले नहीं देखा था कि क्या यह हमारे लिए उपयोगी होगा। यद्यपि अम्मोनियों ने हमें एक परिचित भाषा का उपयोग करने की अनुमति दी, लेकिन हमने इस पर काम करने में कई कमियाँ पाईं। इंटेलीज वर्तमान में अम्मोनाइट का समर्थन करता है , लेकिन यह हमारे प्रवास के दौरान ऐसा नहीं किया - और हमने ऑटो-पूर्ति और ऑटो-आयात खो दिया। इसके अलावा, लंबे समय तक, अमोनाइट स्क्रिप्ट चलने में विफल रही।
अंततः, अम्मोनीइट इस काम के लिए सही उपकरण नहीं था, और इसके बजाय हमने प्रवास करने के लिए sbt प्रोजेक्ट का उपयोग किया। इसने हमें उस भाषा में काम करने की अनुमति दी, जिस पर हमें भरोसा था, साथ ही साथ मुख्य कामकाजी माहौल में लॉन्च करने से पहले कई 'टेस्ट माइग्रेशन' किए।

अप्रत्याशित यह था कि पोस्टग्रेज पर चलने वाले एपीआई के संस्करण की जांच में यह कितना उपयोगी था। हमने कई हार्ड-टू-फाइंड एरर पाए और उन मामलों को सीमित किया, जो हमें पहले नहीं मिले थे।

जनवरी 2018 तक तेजी से आगे बढ़ें जब हमारे पूर्व-ठेस सीओडीई वातावरण में पूर्ण विकसित प्रवास का परीक्षण करने का समय हो।

हमारी अधिकांश प्रणालियों की तरह, CODE और PROD के बीच एकमात्र समानता अनुप्रयोग के लॉन्च होने का संस्करण है। CODE का समर्थन करने वाला AWS इन्फ्रास्ट्रक्चर PROD की तुलना में बहुत कम शक्तिशाली था, केवल इसलिए कि यह बहुत कम कार्यभार प्राप्त करता है।

हमें आशा थी कि CODE वातावरण में परीक्षण प्रवास हमारी सहायता करेगा:

अनुमान लगाएं कि PROD वातावरण में कितना समय लगेगा।
मूल्यांकन करें कि कैसे (यदि बिल्कुल) माइग्रेशन उत्पादकता को प्रभावित करता है।

इन संकेतकों के सटीक माप प्राप्त करने के लिए, हमें दो वातावरणों को पूर्ण पारस्परिक पत्राचार में लाना था। इसमें PROD से CODE तक एक Mongo DB बैकअप बहाल करना और AWS द्वारा समर्थित बुनियादी ढांचे को अपग्रेड करना शामिल था।

केवल 2 मिलियन से अधिक डेटा आइटमों का माइग्रेट करना एक मानक कार्य दिवस की अनुमति देने की तुलना में बहुत अधिक समय लेना चाहिए था। इसलिए, हमने स्क्रिप्ट को रात के लिए स्क्रीन पर चलाया।

माइग्रेशन की प्रगति को मापने के लिए, हमने अपने ELK स्टैक (Elasticsearch, Logstash, और Kibana) में संरचित प्रश्नों (टोकन का उपयोग करके) को भेजा। वहां से, हम सफलतापूर्वक स्थानांतरित किए गए लेखों की संख्या, क्रैश की संख्या और समग्र प्रगति को ट्रैक करके विस्तृत डैशबोर्ड बना सकते हैं। इसके अलावा, सभी संकेतक बड़ी स्क्रीन पर प्रदर्शित किए गए थे ताकि पूरी टीम विवरण देख सके।

डैशबोर्ड माइग्रेशन की प्रगति दिखा रहा है: संपादकीय उपकरण / अभिभावक

एक बार माइग्रेशन पूरा हो जाने के बाद, हमने Postgres और Mongo में प्रत्येक दस्तावेज़ के लिए एक मैच की जाँच की।

भाग तीन: प्रोडक्शंस और प्रक्षेपण

प्रॉक्सी

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

प्रॉक्सी काफी सरल थी:

लोड बैलेंसर से ट्रैफ़िक प्राप्त करें।
मुख्य API और इसके विपरीत ट्रैफ़िक को पुनर्निर्देशित करें।
समान ट्रैफ़िक को अतिरिक्त API पर अग्रेषित करें।
दो उत्तरों के बीच की विसंगतियों की गणना करें और उन्हें एक लॉग में रिकॉर्ड करें।

प्रारंभ में, प्रॉक्सी ने कई विसंगतियों को दर्ज किया, जिसमें दो एपीआई में कुछ कठिन से कठिन लेकिन महत्वपूर्ण व्यवहार संबंधी अंतर शामिल थे जिन्हें ठीक करने की आवश्यकता थी।

संरचित लॉगिंग

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

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

import akka.http.scaladsl.model.HttpRequest import ch.qos.logback.classic.{Logger => LogbackLogger} import net.logstash.logback.marker.Markers import org.slf4j.{LoggerFactory, Logger => SLFLogger} import scala.collection.JavaConverters._ object Logging { val rootLogger: LogbackLogger = LoggerFactory.getLogger(SLFLogger.ROOT_LOGGER_NAME).asInstanceOf[LogbackLogger] private def setMarkers(request: HttpRequest) = { val markers = Map( "path" -> request.uri.path.toString(), "method" -> request.method.value ) Markers.appendEntries(markers.asJava) } def infoWithMarkers(message: String, akkaRequest: HttpRequest) = rootLogger.info(setMarkers(akkaRequest), message) }

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

ट्रैफ़िक प्रतिकृति और प्रॉक्सी रीफ़ैक्टरिंग

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

चूंकि हमारे एपीआई में आने वाले सभी ट्रैफ़िक पहले प्रॉक्सी में गए थे, इसलिए प्रॉक्सी कंटेनरों पर गोर स्थापित करने के लिए समझ में आया। नीचे देखें कि आपके कंटेनर में गोर को कैसे लोड किया जाए और पोर्ट 80 पर ट्रैफिक की निगरानी कैसे शुरू की जाए और इसे दूसरे सर्वर पर भेजा जाए।

  wget https://github.com/buger/goreplay/releases/download/v0.16.0.2/gor_0.16.0_x64.tar.gz tar -xzf gor_0.16.0_x64.tar.gz gor sudo gor --input-raw :80 --output-http http://apiv2.code.co.uk

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

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

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

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

मार्च 2018 तक तेजी से आगे बढ़ें, जब हमने पहले से ही सीओएमएस में एपीआई प्रदर्शन या क्लाइंट अनुभव का त्याग किए बिना सीओडीई के लिए प्रवास पूरा कर लिया है। अब हम CODE से परदे के पीछे लिखने के बारे में सोचना शुरू कर सकते हैं।

पहला कदम एपीआई की प्राथमिकताओं को बदलना था ताकि प्रॉक्सी पहले पोस्टग्रेज के साथ बातचीत करे। जैसा कि हमने ऊपर कहा, यह सेटिंग्स में बदलाव के द्वारा तय किया गया था। हालाँकि, एक कठिनाई थी।

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

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

अब सभी अनुरोध पहले पोस्टग्रेज को भेजे गए, और एपीआई 2 ने किनिस के साथ बातचीत की। प्रतिस्थापन परिवर्तन और पुनर्परिवर्तन के साथ प्रतिस्थापन को स्थायी बनाया जा सकता है।

अगला कदम पोस्टग्रिज एपीआई को विशेष रूप से एक्सेस करने के लिए प्रॉक्सी और फोर्स को पूरी तरह से हटाने का था। चूंकि हमारे पास कई ग्राहक हैं, इसलिए उनमें से प्रत्येक को व्यक्तिगत रूप से अपडेट करना संभव नहीं था। इसलिए, हमने इस कार्य को डीएनएस के स्तर तक बढ़ाया। यही है, हमने DNS में एक CNAME बनाया है जो पहले ELB प्रॉक्सी को इंगित करता है और ELB API को इंगित करने के लिए बदल जाएगा। इसने प्रत्येक व्यक्ति एपीआई क्लाइंट को अपडेट करने के बजाय एक एकल परिवर्तन करने की अनुमति दी।

PROD को स्थानांतरित करने का समय आ गया है। हालांकि यह थोड़ा डरावना था, ठीक है, क्योंकि यह मुख्य काम का माहौल है। यह प्रक्रिया अपेक्षाकृत सरल थी, क्योंकि सेटिंग्स को बदलकर सब कुछ तय किया गया था। इसके अलावा, जैसा कि एक स्टेज मार्कर को लॉग में जोड़ा गया था, केवल किबाना फिल्टर को अपडेट करके पहले निर्मित डैशबोर्ड को फिर से प्रोफाइल करना संभव हो गया।

प्रॉक्सी और मानगो डीबी को अक्षम करना

10 महीने और 2.4 मिलियन माइग्रेट किए गए लेखों के बाद, हम आखिरकार मानगो से संबंधित सभी बुनियादी ढांचे को अक्षम करने में सक्षम थे। लेकिन पहले, हमें वह करना था जो हम सभी इंतजार कर रहे थे: प्रॉक्सी को मारना।

लचीले एपीआई प्रॉक्सी को अक्षम करने वाले लॉग। फोटो: संपादकीय उपकरण / अभिभावक

सॉफ्टवेयर के इस छोटे से टुकड़े ने हमें इतनी परेशानियाँ दीं कि हम इसे जल्द ही खत्म करने के लिए तरस गए! हमें बस इतना करना था कि CNAME रिकॉर्ड को सीधे APIV2 लोड बैलेंसर को इंगित करने के लिए अपडेट किया जाए।
पूरी टीम एक कंप्यूटर के आसपास इकट्ठा हो गई। केवल एक कीस्ट्रोक बनाना आवश्यक था। सबने अपनी सांस रोक रखी थी! पूरी चुप्पी ... क्लिक करें! काम हो गया। और कुछ भी नहीं उड़ा! हम सभी खुशी से झूम उठे।

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

उसके बाद, सब कुछ सुचारू रूप से काम किया। हमने ऑप्समैनगर से मोंगो के सभी उदाहरणों को काट दिया, और फिर उन्हें काट दिया। केवल एक ही काम करना बाकी था। और सो जाओ।

मानगो से पोस्टग्रेज में पलायन: द गार्जियन अखबार का अनुभव

भाग एक: शुरुआत

भाग दो: दो दशकों की सामग्री प्रवासन बिना डाउनटाइम के चली गई

भाग तीन: प्रोडक्शंस और प्रक्षेपण

More articles: