Яагаад Mythex-ийн серверүүдийг ARM руу шилжүүлсэн бэ

9-р сарын 19-нд бид Mythex-ийн үйлдвэрлэлийн backend-ийг x86 серверүүдээс жижиг ARM-д суурилсан AWS Graviton серверүүд рүү, мөн платформын өгөгдлийн санг ч Graviton instance руу шилжүүлсэн. Шалтгаан энгийн байсан: хүнд ажлыг — хэрэглэгч бүрийн аппыг ажиллуулж, бүтээх — тусгаарлагдсан төсөл бүрийн sandbox руу шилжүүлсний дараа үндсэн серверүүд санах ойн гуравны нэг орчим хэмжээгээр оргилж байв. Жижиг ARM машин бодит ачаалалд тохирч, сарын серверийн төлбөрийг ойролцоогоор 30%-иар бууруулсан.

Одоо серверүүд юу хийдэг вэ

Эхэндээ backend серверүүд ихэнх ажлыг шууд хийдэг байсан. 9-р сарын дундуур бид хамгийн их зардалтай хэсгүүдийг — төсөл бүрийн кодыг ажиллуулах, багц суулгах, аппуудыг бүтээх — төсөл бүрт хувийн cloud sandbox руу шилжүүлж дуусгасан. Энэ нь мөн төсөл бүрт тусгаарлагдсан орчин болон live preview өгдөг.

Бидний өөрийн серверүүд дээр үлдсэн зүйл бол зохицуулалт: API, sandbox болон нийтлэлтийг удирддаг оркестратор, нэвтрэлт, биллинг, gateway. Энэ ажил тогтвортой, хөнгөн. Шилжүүлсний дараа серверүүд ойролцоогоор 1.3 ГБ санах ойд оргилж байсан, харин машин нь гурав дахин их санахтай байв.

Яагаад ARM вэ

AWS-ийн Graviton процессорууд нь AWS-ийн өөрийн зохиосон ARM чип. Ижил мөнгөөр та ихэвчлэн x86 instance-тай харьцуулахад илүү чадал, эсвэл ижил чадлыг бага мөнгөөр авдаг — бидний ачаалалд (Node.js үйлчилгээ, Docker, Postgres) x86-д ямар ч хамаарал байхгүй.

Бид шилжүүлсэн:

• Хоёр аппын сервер дунд хэмжээний x86 instance-аас 2 ГБ санахтай жижиг Graviton instance руу.
• Платформын өгөгдлийн сан жижиг x86 өгөгдлийн сангийн instance-аас түүний Graviton-ийн хувилбар руу.

Нэг жинхэнэ төвөгтэй зүйл: хоёр архитектурт зориулсан image

Манай staging орчин одоо ч жижиг x86 сервер дээр ажилладаг. Үйлдвэрлэл одоо ARM дээр ажилладаг. Нэг архитектурт бүтээсэн container image нөгөө дээр ажиллахгүй.

Тиймээс бүх image одоо хоёр архитектурт нэг tag дор бүтээгдэж байна — multi-arch image. Docker тус бүр дээр зөв хувилбарыг автоматаар сонгодог, мөн deploy pipeline аль орчинд түлхэж байгааг мэдэх шаардлагагүй. Үнэ нь CI build урт болсон; ашиг нь staging болон үйлдвэрлэл яг ижил кодыг яг ижил tag-аас ажиллуулдаг.

Шилжилтээс өмнө буцаах төлөвлөгөө

Амьд үйлчилгээн дээрх CPU архитектурыг өөрчлөх нь хэдэн минутад буцааж болох төрлийн өөрчлөлт. Шилжихээсээ өмнө бид:

• серверийн өмнөх загварын хувилбарыг нэртэй буцаах зорилт болгон хадгалсан,
• өгөгдлийн санг хэмжээ өөрчлөхөөс өмнө шууд агшин авсан, мөн
• шилжилт болон буцах замыг хамарсан runbook бичсэн.

Бид буцаах хэрэггүй болсон. Дахин хийвэл яг ижилхэн хийх байсан.

Юунд анхаарах вэ

Жижиг серверүүдэд толгойн зай бага. Үүнээс хоёр зүйл гарна:

1. Хүнд ажил эдгээр серверүүд рүү буцаж орвол, 2 ГБ хангалтгүй. Засах арга нь x86 руу буцах биш, илүү том Graviton хэмжээ.
2. Жижиг машинд swap хэрэгтэй. Долоо хоногийн дараа эдгээр серверүүдийн нэг нь санах ойн даралтаас царцсан — техникийн утгаар санах ой дуусаагүй. Дутуу swap файлын түүх.

Бидний авсан дүгнэлт

• Архитектур өөрчлөгдсний дараа дахин хэмжээ. Ажлыг sandbox руу шилжүүлэх нь серверүүдийн хэрэгцээг өөрчилсөн; instance-ийн хэмжээ тэр даруй дагаагүй.
• Multi-arch image-тай бол ARM бол ердийн вэб стекийн хувьд эрсдэл бага ашиг.
• Буцаах төлөвлөгөөг эхлээд бич. Хэрэглэхгүй байсан ч өөрчлөлтийг тайван болгодог.