आम्ही Mythex चे सर्व्हर ARM वर का हलवले

19 सप्टेंबर रोजी आम्ही Mythex चा production backend x86 सर्व्हरवरून लहान ARM-आधारित AWS Graviton सर्व्हरवर हलवला, आणि प्लॅटफॉर्म डेटाबेसही Graviton इन्स्टन्सवर हलवला. कारण सोपे होते: heavy काम — प्रत्येक वापरकर्त्याचा ॲप चालवणे आणि build करणे — वेगळ्या per-project sandboxes मध्ये हलवल्यानंतर, आमचे मुख्य सर्व्हर त्यांच्या मेमरीच्या सुमारे एक तृतीयांश पातळीवर पोहोचत होते. लहान ARM मशीन प्रत्यक्ष भाराला बसतात आणि मासिक सर्व्हर बिल सुमारे 30% ने कमी होते.

आमचे सर्व्हर आता प्रत्यक्षात काय करतात

पूर्वी backend सर्व्हर अनेक काम थेट करत होते. सप्टेंबरच्या मध्यापर्यंत आम्ही महागडे भाग — प्रत्येक प्रोजेक्टचा कोड चालवणे, packages install करणे, ॲप्स build करणे — खाजगी cloud sandboxes मध्ये हलवले, प्रत्येक प्रोजेक्टसाठी एक. प्रत्येक प्रोजेक्टला स्वतःचे वेगळे वातावरण आणि live preview देखील तेच देते.

आमच्या स्वतःच्या सर्व्हरवर जे राहिले ते समन्वय आहे: API, sandboxes आणि publishing व्यवस्थापित करणारा orchestrator, authentication, billing, आणि gateway. ते काम स्थिर आणि हलके आहे. हलवल्यानंतर, सर्व्हर सुमारे तिप्पट मेमरी असलेल्या मशीनवर सुमारे 1.3 GB वर पोहोचत होते.

ARM का

AWS चे Graviton processors AWS ने डिझाइन केलेले ARM chips आहेत. समान पैशात तुम्हाला सामान्यतः तुलनायोग्य x86 इन्स्टन्सपेक्षा जास्त क्षमता मिळते, किंवा कमी खर्चात तीच क्षमता — आणि आमच्यासारख्या workload साठी (Node.js सेवा, Docker, Postgres) x86 शी बांधील राहण्याचे कोणतेही कारण नाही.

आम्ही हलवले:

• दोन ॲप सर्व्हर मध्यम आकाराच्या x86 इन्स्टन्सेसवरून प्रत्येकी 2 GB RAM असलेल्या लहान Graviton इन्स्टन्सेसवर.
• प्लॅटफॉर्म डेटाबेस लहान x86 database इन्स्टन्सवरून त्याच्या Graviton समतुल्य इन्स्टन्सवर.

एकच खरी गुंतागुंत: दोन architectures साठी images

आमचा staging वातावरण अजूनही लहान x86 सर्व्हरवर चालतो. Production आता ARM वर चालते. एकासाठी build केलेली container image दुसऱ्यावर चालत नाही.

म्हणून प्रत्येक image आता एकाच tag खाली दोन्ही architectures साठी build होते — एक multi-arch image. Docker प्रत्येक मशीनवर योग्य variant आपोआप निवडते, आणि deploy pipeline कोणत्या वातावरणात push करत आहे ते जाणण्याची गरज नसते. त्याची किंमत लांब CI build आहे; फायदा असा की staging आणि production एकाच tag वरून नेमका एकच कोड चालवतात.

हलवण्यापूर्वी rollback नियोजन

चालणाऱ्या सेवेखाली CPU architecture बदलणे हे असे बदल आहे जे काही मिनिटांत उलटता आले पाहिजे. बदलण्यापूर्वी आम्ही:

• मागील सर्व्हर template आवृत्ती नावाने rollback लक्ष्य म्हणून ठेवली,
• डेटाबेस आकार बदलण्यापूर्वी लगेच एक database snapshot घेतला, आणि
• हलवणे आणि परत जाणे दोन्ही समाविष्ट करणारा runbook लिहिला.

आम्हाला rollback ची गरज पडली नाही. तरीही आम्ही तेच करू.

आम्ही काय पाहू

लहान सर्व्हरमध्ये कमी headroom असतो. त्यामुळे दोन गोष्टी होतात:

1. जड काम कधी या सर्व्हरवर परत आले, तर 2 GB पुरेसे नसेल. तेव्हा उपाय x86 कडे परत जाणे नव्हे, तर मोठा Graviton आकार घेणे असेल.
2. लहान मशीनना swap हवा. एका आठवड्यानंतर यातला एक सर्व्हर मेमरी दबावामुळे गोठला, तांत्रिकदृष्ट्या out-of-memory नसताना — गायब झालेल्या swap फाइलची गोष्ट.

त्यातून आम्ही काय शिकलो

• architecture बदलानंतर पुन्हा मोजा. Heavy काम sandboxes मध्ये हलवल्यामुळे आमच्या सर्व्हरना काय लागते ते बदलले; इन्स्टन्स आकार त्याला मागे राहिले.
• तुमच्या images multi-arch झाल्या की सामान्य web stacks साठी ARM हा कमी-धोक्याचा फायदा आहे.
• आधी rollback लिहा. तुम्ही तो कधीच वापरला नाही तरीही बदल शांत होतो.