လူတစ်ယောက်ကိုမှ မစောင့်စေဘဲ ပိုကြီးတဲ့ Workspace များသို့ ပြောင်းခြင်း

Mythex project တိုင်းမှာ ကိုယ်ပိုင် workspace တစ်ခု ရှိပါတယ်။ ၎င်းက agent က code ရေးပြီး သင့် app ရဲ့ preview run တဲ့ သေးငယ်တဲ့ cloud ကွန်ပျူတာ ဖြစ်ပါတယ်။ အသစ်ဖန်တီးတဲ့ workspace တွေကို memory 1 GB ကနေ 2 GB သို့ တိုးခဲ့ပေမဲ့ အဟောင်းတွေက 1 GB မှာပဲ ကျန်နေခဲ့ပါတယ်။ စစ်ဆေးတဲ့ နေ့မှာ ၎င်းတို့ ထဲက လေးပုံတစ်ပုံ ဖြစ်ပါတယ်။ ပထမ fix က project တစ်ခုကို နောက်တစ်ကြိမ် ဖွင့်တဲ့အခါ workspace ကြီးတဲ့ နေရာသို့ ရွှေ့ပါတယ်။ production မှာ ပထမနေ့တွင် တစ်ဦးက မိနစ် ၇ စောင့်ခဲ့ရပါတယ်။ ကျွန်ုပ်တို့က အချိန်ကန့်သတ်ချက် တင်ပြီး နောက်ဆုံး project ဖွင့်တာကနေ ရွှေ့တာကို ဖယ်ထုတ်လိုက်ပါတယ်။

အဟောင်း workspace တွေ ဘာကြောင့် သေးနေခဲ့သလဲ

ကျွန်ုပ်တို့ sandbox provider က workspace ရဲ့ အရွယ်အစားကို ဖန်တီးတဲ့အချိန်မှာ သတ်မှတ်ပြီး pause နဲ့ resume တိုင်းမှာ ဆက်ထားပါတယ်။ template (workspace အသစ်တွေ တည်ဆောက်တဲ့ နည်းစနစ်) ကို ပြောင်းရင် ပြောင်းပြီးနောက် ဖန်တီးတဲ့ workspace တွေကိုသာ သက်ရောက်ပါတယ်။ ရှိပြီးသားတွေကို ဘယ်သူမှ အရွယ်ပြန်မပြောင်းပါဘူး။

ဒါက အရေးကြီးပါတယ်။ သေးငယ်တဲ့ workspace တစ်ခုက preview စတင်နေစဉ် git push လုပ်တုန်း memory ပြည့်သွားပြီး မိနစ် ၁၁ တုံ့ပြန်မှု မရှိခဲ့ပါဘူး။ publish တစ်ခုဟာ ဒါကြောင့် ပျက်ခဲ့ပါတယ်။

ပထမ ကြိုးစားချက်: နိုးချိန်မှာ project ကို ရွှေ့ခြင်း

workspace တွေဟာ ဘယ်သူမှ မသုံးချိန်မှာ pause လုပ်ပြီး project ကို ဖွင့်တဲ့အခါ နိုးပါတယ်။ နိုးချိန်က project ရွှေ့ဖို့ အကောင်းဆုံး အချိန်လို့ ထင်ခဲ့ပါတယ်၊ ဘာလို့လဲဆိုတော့ သူ့ထဲမှာ မည်သူမျှ အလုပ် မလုပ်သေးတဲ့အချိန်ဖြစ်လို့ပါ။

ရွှေ့ပုံက အောက်ပါအတိုင်း ဖြစ်ပါတယ်:

1. အရွယ်ကို စစ်ဆေးပါ။ workspace က 2 GB ထက် ငယ်ရင် ရွှေ့ပါ။ အရွယ် မသိရင် ဘာမှ မလုပ်ပါ။
2. publish ကို မနှောက်ယှက်ပါနဲ့။ publish က workspace ရဲ့ ဖိုင်တွေကို ဖတ်တာမို့ run နေရင် ရွှေ့တာ ကျော်ပါ။
3. project ကို ထုပ်ပါ။ project ရဲ့ အရာအားလုံးကို archive လုပ်ပါ၊ git history ပါဝင်ပြီး၊ ၎င်းက project ရှိ checkpoint အားလုံး ဖြစ်ပြီး app ရဲ့ .env ဖိုင်လည်း ပါပါတယ် (ပိုင်ရှင်ပိုင်ပါတယ်)။ သို့သော် install လုပ်ထားတဲ့ dependencies (node_modules) ကို ထည့်မထားပါ၊ ဘာလို့လဲဆိုတော့ ပြန် install လုပ်နိုင်လို့ပါ။
4. တိုက်ရိုက် ကူးပါ။ အဟောင်း workspace ကနေ archive ကို 2 GB အသစ်ထဲ stream လုပ်ပါ၊ ဒါကြောင့် ကျွန်ုပ်တို့ရဲ့ server memory ထဲမှာ ထည့်စရာ မလိုပါ။
5. ပြောင်းမီ နှိုင်းယှဉ်ပါ။ ဖိုင်အရေအတွက်၊ နောက်ဆုံး checkpoint, နဲ့ checkpoint အရေအတွက်ကို နှစ် workspace လုံးမှာ ရေတွက်ပါ။ သုံးခုလုံး ကိုက်ညီမှသာ ပြောင်းပါ။
6. ပျက်ရင် အဟောင်းကို ထားပါ။ အမှား ဘာပဲဖြစ်ဖြစ် ဒါမှမဟုတ် မကိုက်ညီရင် workspace အသစ်ကို ပစ်ပြီး project ကို အဟောင်းမှာ ဖွင့်ပါ၊ ယခင်အတိုင်း။

နှိုင်းယှဉ်မှုမှာ အရေးကြီးတဲ့ အသေးစိတ်တစ်ခု ရှိပါတယ်။ စစ်ဆေးချက်က administrator account အနေနဲ့ run ပြီး git က အခြား user ပိုင်တဲ့ repository ကို ဖတ်ဖို့ ငြင်းပါတယ်။ နှစ်ဘက်လုံးမှာ ဘာမှ print မထုတ်ပါ၊ ဒါကြောင့် "ဘာမှ မရှိ" က "ဘာမှ မရှိ" နဲ့ ကိုက်ညီပြီး history တစ်ခုမှ မနှိုင်းယှဉ်ဘဲ စစ်ဆေးချက် အောင်သွားပါတယ်။ directory ကို ယုံဖို့ git ကို ပြောပြီး၊ ပြန်မဖြစ်အောင် test တစ်ခု ထည့်ခဲ့ပါတယ်။

ပထမနေ့မှာ ဘာဖြစ်ခဲ့လဲ

production မှာ ပထမနေ့မှာ project တစ်ခုကို ထုပ်တဲ့အခါ နိုးနေချိန်ထဲမှာ command timeout ငါးမိနစ် ကို ထိခဲ့ပါတယ်။ ပိုင်ရှင်က workspace ဖွင့်ဖို့ မိနစ် ၇ စောင့်ခဲ့ရပါတယ်။ ရွှေ့တာ ပျက်ခဲ့လို့ project က သေးနေဆဲဖြစ်ပြီး နောက်တစ်ကြိမ် ဖွင့်ရင် ထပ်ကြိုးစားပြီး ထပ်စောင့်စေမှာ ဖြစ်ပါတယ်။

ကိုယ်ပိုင် project ကို ဖွင့်တဲ့အချိန်မှာ လူတစ်ယောက်ကို စောင့်စေတဲ့ migration က ကောင်းတဲ့ ဖလှယ်မှု မဟုတ်ပါ။ နိုးချိန်မှာ လုပ်ရတဲ့ အကြောင်းရင်းက ဘယ်သူမှ မသိအောင်ပါ။

ဒုတိယ ကြိုးစားချက်: hard budget

ထိုနေ့ပဲ အရာလေးခု ပြောင်းလဲခဲ့ပါတယ်:

• ရွှေ့တာ တစ်ခုလုံးအတွက် တစ်မိနစ်။ အဆင့်တိုင်း — အရွယ်စစ်ဆေးတာ၊ ထုပ်တာ၊ workspace အသစ် ဖန်တီးတာ၊ ကူးတာ၊ ဖြုတ်တာ၊ နှိုင်းယှဉ်တာ — တစ်ခုတည်းသော စက္ကန့် ၆၀ budget ကို မျှဝေပါတယ်။ အချိန်ကုန်ရင် project က အဟောင်း workspace မှာ ဖွင့်ပါတယ်။
• ရပ်တာကို အလုပ်ကိုပါ ရပ်ပါ။ ကျွန်ုပ်တို့ဘက်က စောင့်တာ ရပ်လိုက်ရုံနဲ့ မလုံလောက်ပါ၊ ပိုင်ရှင် သုံးတော့မယ့် workspace ထဲမှာ archive ဆက် run နေနိုင်ပါတယ်။ archive command တစ်ခုစီကို budget ကုန်တော့မယ့် ခဏမတိုင်ခင် workspace ထဲမှာ ကိုယ်တိုင် သတ်ပါတယ်။ ကျွန်ုပ်တို့ စောင့်ပြီးနောက် workspace အသစ် ရောက်လာရင် ပစ်ပါတယ်။
• သန့်ရှင်းရေးကို ပိုင်ရှင်က မစောင့်ရစေပါနဲ့။ ယာယီ archive ကို ဖျက်တာ နောက်ကွယ်မှာ လုပ်ပါတယ်။
• ဖွင့်တိုင်း ထပ်မကြိုးစားပါနဲ့။ ရွှေ့မရခဲ့တဲ့ project ကို နာရီ ၂၄ ကြာ ထားပါတယ်၊ ဒါကြောင့် ပျက်တာက တစ်ရက်ကို ဒီလေးတစ်ကြိမ်သာ ကုန်ပြီး ဖွင့်တိုင်း တစ်ကြိမ်မဟုတ်ပါ။

တတိယ ကြိုးစားချက်: နိုးချိန်ထဲကနေ ထုတ်ပစ်ခြင်း

ဒါက အဆိုးဆုံး အခြေအနေကို တစ်မိနစ်အထိ ကန့်သတ်ပေးခဲ့ပါတယ်။ ဒါပေမဲ့ တစ်မိနစ်ဟာ ကြာပါသေးတယ်၊ ပြီးတော့ ရွှေ့တာက ဘယ်သူ့ လမ်းကြောင်းမှာမှ ရှိစရာမလိုတာ သိလာပါတယ်။

အခုတော့ 1 GB နဲ့ workspace မဖန်တီးတော့ပါဘူး။ ဒါကြောင့် ဒါက ဆက်တိုက် လုပ်ငန်းစဉ် မဟုတ်ပါ၊ workspace စာရင်း သတ်မှတ်ထားတဲ့ တစ်ကြိမ်တည်း job ပါ။ နိုးချိန်ထဲမှာ ထားတာက ရွှေ့တဲ့ အချိန်တိုင်း တကယ်လူတစ်ယောက် ပေးခဲ့ရတာ ဖြစ်ပြီး၊ workspace တစ်ခု မရွှေ့နိုင်ကြောင်း သိတဲ့နည်းလမ်းက ပိုင်ရှင်က စောင့်နေတုန်းမှ သိရတာပါ။

ဒါကြောင့် နိုးချိန်ကနေ ရွှေ့တာကို လုံးဝ ဖယ်ထုတ်လိုက်ပါတယ်။ project ဖွင့်တာက ယခင်အတိုင်း လုပ်ပါတယ်။ ကျန်ရှိတဲ့ သေးငယ်တဲ့ workspace တွေကို supervised batch အနေနဲ့ ကိုင်တွယ်ပါတယ်။ ဘယ်သူမှ စောင့်စရာ မလိုဘဲ၊ ရွှေ့မရတဲ့ workspace ဟာ batch ရဲ့ အစီရင်ခံစာမှာ ပေါ်လာပြီး ကျွန်ုပ်တို့ ကြည့်နိုင်ပါတယ်၊ ပိုင်ရှင်ရှေ့မှာ မဟုတ်ပါ။

ကျွန်ုပ်တို့ ရလိုက်တဲ့ သင်ခန်းစာများ

• အရွယ်ပြောင်းတာ အမြဲ ဖြစ်နိုင်တာ မဟုတ်ပါ။ platform က ဖန်တီးတဲ့အချိန် အရွယ်ကို ပြင်ထားရင် default တိုးတာက အသစ်တွေကိုသာ ကူညီပါတယ်။ အဟောင်းတွေအတွက် ကြိုစီစဉ်ပါ။
• "ဘယ်သူမှ မသုံးသေးဘူး" ဆိုတာ လူတစ်ယောက် စောင့်နေတုန်းဖြစ်နိုင်သေးတယ်။ ထုတ်ကုန်ထဲ ဝင်တဲ့ လမ်းပေါ်မှာ လုပ်တဲ့ အလုပ်ဟာ လူတစ်ယောက် ကြည့်နေတဲ့ အလုပ်ပါ။
• သင့်လမ်းကြောင်းပေါ်က အရာတိုင်းကို budget ထားပြီး အလုပ်ကုန်ရင် ရပ်ပါ။ ကျွန်ုပ်တို့ဘက်က timeout လုပ်ပေမဲ့ command က တခြားနေရာမှာ ဆက်ရှိနေရင် ပြဿနာကို ရွှေ့ရုံသာ ဖြစ်ပါတယ်။
• တစ်ကြိမ်တည်း migration ကို တစ်ကြိမ်တည်း job ထဲ ထည့်ပါ။ နေ့စဉ် လုပ်ဆောင်ချက်တွေထဲ ဝှက်ထားရင် ရေးရလွယ်ပေမဲ့ run ဖို့ ပိုစရိတ်ကြီးပါတယ်။
• Safety check တွေကိုလည်း test လုပ်ပါ။ ဘာမှ မနှိုင်းယှဉ်တဲ့ နှိုင်းယှဉ်မှုက အောင်မြင်တဲ့ နှိုင်းယှဉ်မှုနဲ့ တူတူ ပုံပေါ်ပါတယ်။

Mythex ပေါ်မှာ တည်ဆောက်တဲ့သူတွေအတွက် ဘာမှ လုပ်ဖို့ မလိုပါဘူး။ ရည်ရွယ်ချက်က memory မကုန်တဲ့ workspace နည်းအောင်လုပ်ပြီး project ဖွင့်တာ အရင်လောက် မြန်ဆန်အောင် ထားတာပါ။ workspace တွေ ဘယ်လို pause နဲ့ wake လုပ်လဲ docs ရဲ့ private workspace မှာ ရှိပါတယ်။ memory ကုန်တဲ့ နောက်ထပ် အကြောင်းအရာအတွက် progress label ထဲမှာ ဝှက်နေတဲ့ out-of-memory crash ကို ကြည့်ပါ။