हमने Mythex के सर्वर ARM पर क्यों ले गए

19 सितंबर को हमने Mythex का प्रोडक्शन बैकएंड x86 सर्वरों से छोटे ARM-आधारित AWS Graviton सर्वरों पर ले गए, और प्लेटफ़ॉर्म डेटाबेस को भी एक Graviton इंस्टेंस पर ले गए। कारण सरल था: भारी काम, यानी हर उपयोगकर्ता के ऐप को चलाना और बनाना, अलग-अलग प्रति-प्रोजेक्ट सैंडबॉक्स में चला जाने के बाद, हमारे मुख्य सर्वरों की मेमोरी लगभग एक-तिहाई पर पहुँच रही थी। छोटी ARM मशीनें असली लोड में फ़िट होती हैं और मासिक सर्वर बिल लगभग 30% घटाती हैं।

अब हमारे सर्वर वास्तव में क्या करते हैं

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

जो हमारे सर्वरों पर रहा वह समन्वय है: API, वह ऑर्केस्ट्रेटर जो सैंडबॉक्स और पब्लिशिंग को प्रबंधित करता है, प्रमाणीकरण, बिलिंग और गेटवे। यह काम स्थिर और हल्का है। इस बदलाव के बाद, सर्वर लगभग 1.3 GB मेमोरी पर पहुँचते थे, जबकि मशीनों में उसका लगभग तीन गुना था।

ARM क्यों

AWS के Graviton प्रोसेसर AWS द्वारा डिज़ाइन किए गए ARM चिप्स हैं। उसी कीमत पर आम तौर पर तुलनीय x86 इंस्टेंस से ज़्यादा क्षमता मिलती है, या कम कीमत पर वही क्षमता; और हमारे जैसे काम के लिए (Node.js सर्विसेज़, Docker, Postgres) हमें x86 से कुछ बाँधता नहीं।

हम ले गए:

• दो ऐप सर्वर मध्यम आकार के x86 इंस्टेंस से छोटे Graviton इंस्टेंस पर, हर एक में 2 GB RAM।
• प्लेटफ़ॉर्म डेटाबेस एक छोटे x86 डेटाबेस इंस्टेंस से उसके Graviton समकक्ष पर।

एक असली जटिलता: दो आर्किटेक्चर के लिए इमेज

हमारा स्टेजिंग वातावरण अब भी एक छोटे x86 सर्वर पर चलता है। प्रोडक्शन अब ARM पर चलता है। एक आर्किटेक्चर के लिए बनी कंटेनर इमेज दूसरे पर नहीं चलेगी।

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

स्थानांतरण से पहले रोलबैक की योजना

लाइव सर्विस के नीचे CPU आर्किटेक्चर बदलना ऐसा बदलाव है जिसे आप मिनटों में पलटना चाहेंगे। बदलने से पहले, हमने:

• पिछले सर्वर टेम्पलेट वर्शन को एक नाम वाले रोलबैक लक्ष्य के रूप में रखा,
• डेटाबेस का आकार बदलने से ठीक पहले एक डेटाबेस स्नैपशॉट लिया, और
• स्थानांतरण और वापसी के रास्ते को कवर करने वाला एक रनबुक लिखा।

हमें रोलबैक की ज़रूरत नहीं पड़ी। फिर भी हम इसे उसी तरह करेंगे।

हम किस चीज़ पर नज़र रखेंगे

छोटे सर्वरों में कम हेडरूम होता है। इससे दो बातें निकलती हैं:

1. अगर भारी काम कभी इन सर्वरों पर वापस गया, तो 2 GB काफ़ी नहीं होगा। तब उपाय बड़ा Graviton आकार है, x86 पर वापस जाना नहीं।
2. छोटी मशीनों को स्वैप चाहिए। एक हफ़्ते बाद इनमें से एक सर्वर मेमोरी दबाव से जम गया, बिना तकनीकी रूप से मेमोरी खत्म हुए। गायब स्वैप फ़ाइल की कहानी।

हमने क्या सीखा

• आर्किटेक्चर बदलने के बाद फिर से मापें। सैंडबॉक्स में काम ले जाने ने बदल दिया कि हमारे सर्वरों को क्या चाहिए; इंस्टेंस आकार अभी पीछे थे।
• मल्टी-आर्क इमेज हो तो ARM आम वेब स्टैक के लिए कम जोखिम वाली जीत है।
• रोलबैक पहले लिखें। इससे बदलाव शांत रहता है, भले ही आप उसका इस्तेमाल कभी न करें।