Mythex ၏ Server များကို ARM သို့ ရွှေ့ခဲ့ပုံ

စက်တင်ဘာ ၁၉ တွင် ကျွန်ုပ်တို့သည် Mythex ၏ production backend ကို x86 server များမှ AWS Graviton ARM server ငယ်များသို့ ရွှေ့ခဲ့ပြီး platform database ကိုလည်း Graviton instance သို့ ရွှေ့ခဲ့သည်။ အကြောင်းရင်းမှာ ရိုးရှင်းသည်: အလုပ်ကြီးများ — အသုံးပြုသူတစ်ယောက်စီ၏ အက်ပ်ကို run ခြင်းနှင့် build ခြင်း — ကို သီးခြား per-project sandbox များသို့ ရွှေ့ပြီးနောက် ကျွန်ုပ်တို့၏ main server များသည် memory ၏ သုံးပုံတစ်ပုံခန့်သာ ထိပ်တန်း သုံးနေခဲ့သည်။ ARM စက်ငယ်များသည် အမှန်တကယ် load နှင့် ကိုက်ညီပြီး လစဉ် server ငွေစာရင်းကို ~၃၀% ခန့် လျှော့ခဲ့သည်။

ကျွန်ုပ်တို့ server များ ယခု ဘာလုပ်သလဲ

စောစောက backend server များသည် အလုပ်များစွာကို တိုက်ရိုက် လုပ်ခဲ့သည်။ စက်တင်ဘာ လယ်အထိ ကျွန်ုပ်တို့သည် စရိတ်များသော အစိတ်အပိုင်းများ — project code run ခြင်း၊ package install ခြင်း၊ အက်ပ် build ခြင်း — ကို private cloud sandbox များသို့ ရွှေ့ပြီးဖြစ်သည်၊ project တစ်ခုလျှင် တစ်ခု။ ထိုအရာက project တစ်ခုစီကို ကိုယ်ပိုင် isolated ပတ်ဝန်းကျင်နှင့် live preview ပေးသည်။

ကျွန်ုပ်တို့ server များပေါ်တွင် ကျန်နေသည်မှာ ညှိနှိုင်းမှုဖြစ်သည်: API၊ sandbox နှင့် publishing ကို စီမံသော orchestrator၊ authentication၊ billing နှင့် gateway။ ထိုအလုပ်သည် တည်ငြိမ်ပြီး ပေါ့သည်။ ရွှေ့ပြီးနောက် server များသည် ~၁.၃ GB memory ထိပ်တန်းသုံးပြီး အကြီးဆုံး စက်သည် ~၃ ဆ ခန့်ရှိသည်။

ဘာကြောင့် ARM လဲ

AWS ၏ Graviton processor များသည် AWS ဒီဇိုင်းထုတ်ထားသော ARM chip များဖြစ်သည်။ ငွေတူတူဖြင့် နှိုင်းယှဉ်နိုင်သော x86 instance ထက် ပိုမိုစွမ်းအား သို့မဟုတ် ပိုသက်သာစွာ ရနိုင်သည် — ကျွန်ုပ်တို့ကဲ့သို့ workload (Node.js ဝန်ဆောင်မှုများ၊ Docker၊ Postgres) အတွက် x86 ကို မှီခိုရန် မရှိပါ။

ကျွန်ုပ်တို့ ရွှေ့ခဲ့သည်များ:

• Application server နှစ်ခု အလတ်စား x86 instance မှ RAM 2 GB ရှိသော Graviton ငယ်များသို့။
• Platform database ကို x86 database instance ငယ်မှ ညီမျှသော Graviton သို့။

တစ်ခုတည်းသော ရှုပ်ထွေးမှု: နှစ်မျိုး architecture အတွက် image များ

ကျွန်ုပ်တို့၏ staging environment သည် x86 server ငယ်တစ်ခုတွင် ဆက် run သည်။ Production သည် ယခု ARM ဖြစ်သည်။ တစ်ခုအတွက် build လုပ်ထားသော container image သည် အခြားတစ်ခုတွင် မ run နိုင်ပါ။

ထို့ကြောင့် image တိုင်းကို tag တစ်ခုအောက် architecture နှစ်ခုလုံးအတွက် build လုပ်သည် — multi-arch image ဖြစ်သည်။ Docker က စက်တိုင်းတွင် မှန်ကန်သော variant ကို အလိုအလျောက် ရွေးသည်၊ deploy pipeline က မည်သည့် environment သို့ push လုပ်နေသည်ကို သိရန် မလိုပါ။ ကုန်ကျစရိတ်မှာ CI build ရှည်ခြင်းဖြစ်ပြီး အကျိုးကျေးဇူးမှာ staging နှင့် production သည် tag တူတူမှ ကုဒ်တူတူကို run ခြင်း ဖြစ်သည်။

ပြန်ပြောင်းရန် ရွှေ့မီ စီစဉ်ခြင်း

Live service အောက်တွင် CPU architecture ပြောင်းခြင်းသည် မိနစ်အနည်းငယ်အတွင်း ပြန်ပြင်နိုင်ချင်သော အရာဖြစ်သည်။ မပြောင်းမီ ကျွန်ုပ်တို့သည်:

• ယခင် server template version ကို အမည်ပေးထားသော rollback ပစ်မှတ်အဖြစ် ထားခဲ့ပြီး၊
• Database ကို ပြင်ဆင်မီ ချက်ချင်း database snapshot ယူပြီး၊
• ရွှေ့ခြင်းနှင့် ပြန်ပြောင်းခြင်း အဆင့်များကို runbook တွင် ရေးထားခဲ့သည်။

Rollback မလိုအပ်ခဲ့ပါ။ အလားတူ နည်းလမ်းကိုပင် နောက်တစ်ကြိမ် ထပ်လုပ်မည်။

ကြည့်ရန်ရှိသည်များ

Server ငယ်များတွင် ခေါင်းပြတ်ခန်းနည်းသည်။ ထို့ကြောင့် အရာနှစ်ခု လိုက်သည်:

၁။ Heavy work ပြန်ပြောင်းလာလျှင် 2 GB မလုံလောက်ပါ။ ထိုအချိန် ပြင်ရန် ARM size ကြီးသို့ တက်ရမည်၊ x86 သို့ မပြန်ပါ။ ၂။ စက်ငယ်များသည် swap လိုသည်။ တစ်ပတ်အကြာ ဤ server တစ်ခုသည် memory ဖိအားကြောင့် နည်းပညာအရ out-of-memory မဖြစ်ဘဲ ရပ်သွားခဲ့သည် — swap file ပျောက်နေသော ဇာတ်လမ်း။

ကျွန်ုပ်တို့ ရရှိခဲ့သည့်အရာ

• Architecture ပြောင်းပြီးနောက် ပြန်တိုင်းပါ။ Heavy work ကို sandbox သို့ ရွှေ့ခြင်းက server များ လိုအပ်သည်ကို ပြောင်းလဲစေခဲ့သည်၊ instance အရွယ်အစားများက မလိုက်ပြီးသေးပါ။
• Multi-arch image ရှိပြီဆိုလျှင် ARM သည် ပုံမှန် web stack များအတွက် အန္တရာယ်နည်းသော အကျိုးရှိမှု ဖြစ်သည်။
• ပြန်ပြောင်းနည်းကို ဦးစွာ ရေးပါ။ ဘယ်တော့မှ မသုံးခဲ့သော်လည်း ပြောင်းလဲမှုကို ပိုတည်ငြိမ်စေသည်။