Mythex серверлерін ARM-ға неге көшірдік

9 қыркүйекте Mythex өндірістік backend-ін x86 серверлерінен кішірек, ARM негізіндегі AWS Graviton серверлеріне көшірдік, ал платформа дерекқорын да Graviton даналығына көшірдік. Себебі қарапайым болды: ауыр жұмысты — әр пайдаланушының қолданбасын іске қосып, құрастыруды — оқшау, жобаға арналған sandbox-қа көшіргеннен кейін, негізгі серверлеріміздің жадының шамамен үштен бірін пайдаланып тұрды. Кішірек ARM машиналары нақты жүктемеге сай келеді және айлық серверлер шығынын шамамен 30% азайтады.

Серверлеріміз қазір не істейді

Бұрын backend серверлері көп жұмысты тікелей атқаратын. Қыркүйек ортасында қымбат бөліктерді — әр жобаның кодын іске қосу, пакеттерді орнату, қолданбаларды құрастыру — жобаға бір жеке бұлттық sandbox арқылы көшіріп бітірдік. Әр жобаның оқшаулануы мен жанды алдын ала көрінісі де осыдан.

Өз серверлерімізде қалғаны — үйлестіру: API, sandbox-тар мен жариялауды басқаратын оркестратор, аутентификация, биллинг және шлюз. Бұл жұмыс тұрақты әрі жеңіл. Көшкеннен кейін серверлер шамамен 1,3 ГБ жад шегіне жетті, ал машиналар оның шамамен үш еселеніп тұрды.

Неліктен ARM

AWS Graviton — AWS жасаған ARM процессорлары. Бірдей ақшаға әдетте x86 данасына қарағанда көбірек қуат аласыз, немесе бірдей қуатты арзанырақ аласыз — ал біздің жүктеме үшін (Node.js сервистері, Docker, Postgres) x86-ға байланыс жоқ.

Біз мыналарды көшірдік:

• Екі қолданба сервері орташа x86 даналарынан 2 ГБ жады бар кішкене Graviton даналарына.
• Платформа дерекқоры кішкене x86 дерекқор данасынан оның Graviton эквивалентіне.

Бір нақты қиындық: екі архитектураға арналған бейнелер

Staging ортамыз әлі шағын x86 серверінде жұмыс істейді. Өндіріс енді ARM-да. Бір архитектураға арналған контейнер бейнесі басқасында іске қосылмайды.

Сондықтан әр бейне енді бір тег астында екі архитектураға арналып құрастырылады — multi-arch бейне. Docker әр машинада дұрыс нұсқаны автоматты түрде таңдайды, ал деплой құбыры қай ортаға жіберіп жатқанын білуі керек емес. Бағасы — ұзағырақ CI құрастыруы; пайдасы — staging мен өндіріс бірдей тегтен бірдей кодты іске қосады.

Көшуден бұрын кері қайтаруды жоспарлау

Жұмыс істеп тұрған сервис астындағы CPU архитектурасын өзгерту — минуттар ішінде қайтаруға болатын өзгеріс. Ауыстырмас бұрын біз:

• алдыңғы сервер шаблонының нұсқасын аталған кері қайтару нысаны ретінде сақтадық,
• дерекқорды өлшемін өзгертер алдында дерекқордың снапшотын түсірдік, және
• көшуді де, кері қайтаруды да қамтитын runbook жаздық.

Кері қайтару қажет болмады. Қайтадан да дәл солай істер едік.

Нені бақылау керек

Кішірек серверлердің бос орны аз. Одан екі нәрсе шығады:

1. Ауыр жұмыс осы серверлерге қайта көшсе, 2 ГБ жеткіліксіз болады. Сонда шешім x86-ға қайту емес, үлкенірек Graviton өлшемі болады.
2. Кішкене машиналарға swap керек. Бір аптадан кейін осы серверлердің біреуі техникалық тұрғыдан жад таусылмаса да, жад қысымынан қатып қалды — жоқ swap файлының оқиғасын қараңыз.

Одан не алдық

• Архитектура өзгергеннен кейін қайтадан өлшеңіз. Жұмыстарды sandbox-тарға көшіру серверлеріміздің қажетін өзгертті; дананың өлшемдері соған әлі жетпеген екен.
• Әдеттегі веб-стектер үшін ARM — көшірмелеріңіз multi-arch болғанда қауіпсіз ұтыс.
• Алдымен кері қайтаруды жазыңыз. Ол өзгерісті тіпті оны ешқашан қолданбасаңыз да тыныштау етеді.