Sababta Aan Server-yada Mythex ugu Guurinay ARM

Bishii 19 Sebtember waxaan production backend-ka Mythex ka guurinay server-yo x86 ah oo u guurnay server-yo Graviton ah oo ARM ku salaysan oo AWS yar, waxaanan database-ka platform-ka iyana u guurinay mishiin Graviton ah. Sababtu waxay ahayd mid fudud: markii aan shaqada culus — ku socodsiinta iyo dhisidda app kasta oo isticmaale — u guurinay sandbox-yo gaar ah oo kala go'an, server-keenii ugu waaweynaa waxay gaareen qiyaastii saddex meelood meel xusuusteeda. Server-yo ARM yar ayaa ku habboon shaqada runta ah, kharashka bisha ahna qiyaastii 30% ayay dhimeen.

Waxa server-keenu hadda sameeyo

Waqtigii hore, server-yada backend-ku shaqo badan ayay si toos ah u qabanayeen. Bartamihii Sebtember waxaan dhammeynay guurinta qaybaha qaaliga ah — ku socodsiinta koodka mashruuc kasta, rakibidda packages-ka, dhisidda app-yada — sandbox-yo gaar ah oo cloud-ka, mid kasta mashruuc. Taasna waxay siisay mashruuc kasta deegaan go'an iyo preview toosan.

Waxa ku hartay server-keenna waa iswaafajinta: API-ga, orchestrator-ka maamula sandboxes-ka iyo daabacaadda, authentication-ka, billing-ka, iyo gateway-ga. Shaqadaas waa joogto oo fudud. Guurinta ka dib, server-yadu waxay gaareen qiyaastii 1.3 GB xusuus oo ah mishiinno qiyaastii saddex jeer ka weyn.

Maxaa ARM loo doortay

Processors-ka Graviton ee AWS waa chips ARM ah oo AWS naqshadeeyay. Lacag isku mid ah waxaad badanaa heleysaa awood ka badan instance x86 la mid ah, ama isku awood oo lacag yar — shaqadayada (Node.js services, Docker, Postgres) ma jiro wax nagu xidha x86.

Waxaan guurinay:

• Laba server app oo ka yimid instances x86 dhexe oo u guureyay instances Graviton yar oo leh 2 GB RAM kasta.
• Database-ka platform-ka oo ka yimid instance database x86 yar oo u guureyay isteeliga Graviton.

Dhibaatada keliya ee run ah: sawirro loo baahan yahay laba architecture

Server-keena staging-ka wali wuxuu ku shaqeeyaa server x86 yar. Production-ku hadda wuxuu ku shaqeeyaa ARM. Container image loo dhisay mid ma shaqayn doono kan kale.

Sidaas darteed sawir kasta hadda waxaa loo dhisay labada architecture tag hal ah hoostiisa — multi-arch image. Docker wuxuu mishiin kasta si toos ah u doortaa noocii saxa ahaa, pipeline-ka deploy-kuna uma baahna inuu ogaado deegaanka uu ku riixayo. Kharashku waa CI build dheer; faa'iidadu waa in staging iyo production ay isla koodka isla tag-ka ka shaqeeyaan.

Qorso dib u celinta ka hor guurinta

Isbeddelka CPU architecture hoosta adeeg firfircoon waa nooca isbeddel aad rabto inaad daminayso daqiiqado gudahood. Ka hor inta aanu beddelin, waxaan:

• ku hayney template-ka server-ka ee hore oo magac u leh bartilmaameed dib u celin,
• snapshot database ah ka qaadnay si toos ah ka hor inta aanu database-ka cabbirin, iyo
• runbook ah qornay oo ku daboolaya guurinta iyo sida dib loogu noqdo.

Ma u baahnayn dib u celinta. Ayaan mar kale sidaas u samayn lahayn.

Waxa aan dhawrayno

Server-yada yaryar waxay leeyihiin meel bannaan oo yar. Laba waxyaabood ayaa ka soo baxa:

1. Haddii shaqada culus mar kale ku soo laabato server-yadan, 2 GB waa uu ku filnaan waayi doonaa. Xalka markaas waa cabbir Graviton oo weyn, ma aha dib loogu noqdo x86.
2. Mishiinada yaryar waxay u baahan yihiin swap. Toddobaad kadib mid ka mid ah server-yadan ayaa ka qabsaday cadaadis xusuus iyada oo aanu farsamo ahaan ku dhicin xusuus dhamaatay — sheekada faylka swap-ka ee maqnaa.

Waxa aan ka barannay

• Dib u cabbir kadib isbeddelka architecture. Guurinta shaqada u dhex diridda sandbox-yada waxay beddeshay waxa server-keenu u baahnaa; cabbirrada instance-ka weli ma ay la kaco.
• ARM waa guul hoose-khatar leh stacks web-ka caadiga ah markii sawirradaadu ay noqdaan multi-arch.
• Qor dib u celinta marka hore. Waxay dhigaysaa isbeddelka mid degan, xitaa haddii aadan waligaa isticmaalin.