အကြောင်းကဒီလို… ရုံးမှာက NodeJS သုံးတာ။ လုပ်စရာတွေများတော့ ရုံးကလိုအပ်တဲ့ website တခုကိုအပြင်အပ်မယ်ဆိုပီးလုပ်ကော။ အဲ့ outsource လုပ်တဲ့သူတွေက FE ကို Next သုံးပီး BE ကို Laravel သုံးထားတယ်။ Marketing campaign ဆိုတော့ traffic ကရုတ်တရက်များလာနိုင်တယ်။ သူတို့ကျနော့်လာပြောတဲ့အချိန်ကလဲညဘက်မှာ ဒီ website က ready ဖြစ်ရမှာ။ အဲ့လိုနဲ့ရုံးမှာကျနော်က DevOps ကော PHP/Laravel ကော လက်ရှိ Node နဲ့ကောအလုပ်လုပ်နေတာဆိုတော့ Traffic handle လုပ်ဖို့ကျနော့်စီရောက်လာတယ်။

ကြည့်လိုက်တော့သူတို့ setup က auto scaling မပါ။ Traffic ဘယ်လောက်လောက်လာမလဲခန်းမှန်းခြေမေးကြည့်လိုက်တော့ ဒီ EC2 နဲ့ဘဲဖြစ်လောက်ပါတယ်ပေါ့။ အချိန်ကမရတော့ဘူး သူတို့ load balancer ဘာညာနှင့် auto scaling လုပ်ဖူးတဲ့ပုံလဲမပေါ်ဘူး။ ဒါနဲ့ဒီ EC2 နဲ့ဘဲအရင် သွားမယ်ဆိုပီး load test စစ်တာ။ API load လုပ်ဖို့ရာက 27 seconds လောက်ကြာနေတယ်။ ကုဒ်ရေးတဲ့သူကအဓိကကျနော်တို့ main contact… ကုဒ်ကလဲဟိုပြင်ဒီပြင်ပြင်နေတုန်း သူ့မှာက Devops သမားရှိတယ်။ အဲ့လူနဲ့ဆက်သွယ်ဖို့က သူကနေတဆင့်ဖြစ်နေတာ။ Load testing စစ်ဖို့ပြင်ဖို့ဘာလိုလဲကြည့်ကြည့်ဖို့ပြောတာ ဆရာသမားကမပီးနိုင်ဘူး။ အဲ့ဒါနဲ့ server access တောင်းပီးတော့ server ထဲဝင်ကြည့်လိုက်တော့ CPU/Memory တွေကလဲအဆင်ပြေတယ်။ အဲ့ဒါနဲ့ PHP/Laravel ဖြစ်တဲ့အတွက် .env ထဲမှာ DB connection ကြည့်ပီးတော့ DB size ကြည့်ခိုင်းလိုက်တော့ staging db ကိုချိတ်ထားတာ။ ဒါနဲ့မင်းတို့ DB ဒါချိတ်ထားတယ်ပြင်လိုက်ဦးဆိုပီးပြင်ခိုင်းလိုက်တာ အဆင်ပြေသွားတယ်။ Load testing လုပ်လိုက်တော့လဲအဆင်ပြေတယ်။

ညဘက်လဲရောက်ရော campaign က announce လုပ်လိုက်တော့ user တွေတောက်လျှောက်တက်လာတာ BE ကဘာမှမဖြစ်ဘဲ frontend ကနှေးနေကော။ Frontend က load testing စစ်လိုက်တုန်းကအဆင်ပြေတယ်။ ဒါပေမယ့် user တွေကသုံးလို့ရနေသေးတယ်။ ဒီလိုဘဲ monitor လုပ်နဲ့အဆင်ပြေသွားတယ်။

နောက်နေ့လဲရောက်ကော user တွေက website က lag ဖြစ်နေတယ် loading ကြီးဘဲတက်နေတယ်ဆိုပီး complain လာကော website ကို access လုပ်ကြည့်လိုက်တော့လဲတကယ်နှေးနေတယ်။ ဒါနဲ့ FE server ဝင်ပီးဘာဖြစ်လဲကြည့် logs တွေကြည့်ပေါ့။ CPU usage ကဘာမှသိပ်ကိုမသုံးတာ ဒါနဲ့ဒီဘဲတွေ Next ကိုဘာနဲ့ run နေလဲဆိုပီးသွားကြည့်တော့ pm2 နဲ့ run ထားတာ။ pm2 list လုပ်ပီးကြည့်လိုက်တော့ core တခုထဲမှာဘဲ run နေတာ။ ဒါနဲ့ pm2 ကို cluster mode ပြောင်းခိုင်းလိုက်တော့ website ကအတော်လေးမြန်သွားတယ်။

PM2 မှာ cluster mode နဲ့ fork mode ဘာကွာလဲဆိုတာ ဒီမှာကြည့်လို့ရတယ်

ဒါလဲ website ကနှေးနေသေးတယ်။ SSH နဲ့ FE server ထဲတခါထက်ဝင်ကြည့်လိုက်တော့ ဆရာသမားက pm2 monit ကို run ပီး monitor လုပ်နေတာ။ pm2 monit ကလဲ resoruce ရှယ်ကြိတ်တော့ webstie တွေကနှေးကုန်ကော။ အဲ့ဒါနဲ့ htop နဲ့ process id ကြည့်ပီးတော့ kill သူတို့ကိုလဲအဲ့လို monitor မလုပ်ဖို့ပြောလိုက်တော့ resource တွေကအဆင်ပြေသွားတယ်။

အဲ့ဒါနဲ့ထက်ပီး website ကို စမ်းခေါ်ကြည့်တဲ့အချိန်မှာ BE call တွေမခေါ်တဲ့ web page ဆိုရင်အတော်မြန်ပီးတော့ BE call ပါတဲ့ page တွေကကြာနေတယ်။ သူတို့လဲဘာဖြစ်မှန်းမသိ၊ ကျနော်လဲဘာဖြစ်မှန်းမသိ။ BE server ဝင်ကြည့်တော့လဲ resource တွေက over provision ဖြစ်နေသေးတယ်။ အဲ့ဒါနဲ့ nginx မှာ worker process တွေ limit ဖြစ်ဖူးတာသတိရပီး nginx config ကိုကြည့်တော့ အဲ့ကောင်လဲ configure လုပ်ထားပီးသား။ ဒါနဲ့ logs တွေလိုက်ကြည့် nginx ကလဲအဆင်ပြေတယ်။ PHP FPM logs ကိုကြည့်လိုက်တော့

pm.max_children setting (5), consider raising it

PHP FPM Logs

ဆိုပီးတွေ့လိုက်တယ်။ အရင် company မှာတုန်းက websocket ကို PHP နဲ့ setup လုပ်ပီးဒီပြဿနာတွေကြုံဖူးတာသွားတိရပီးတော့ သတိရပီး PHP FPM နှင့်ပတ်သတ်တဲ့ setting တွေကိုပြင်လိုက်တာအစက 27.8 seconds ကနေပီးတော့ 600 ms လောက်ထိကြသွားတယ်။

PHP FPM pm.max_children နှင့်သူနှင့်သတ်ဆိုင်တာတွေပြောင်းဖို့အတွက် တွက်တာကလဲ formula ရှိတယ်။ အဲ့ကောင်တွေကို ဒီမှာ ဖတ်ကြည့်နိုင်တယ်။

နောက်ဆုံးအားလုံအဆင်ပြေသွားတယ်ပေါ့။

ဒီ process တခုလုံးမှာကျနော်သတိထားမိတာက တချို့ dev တွေက cloud ဘဲသုံနေပီးအထဲ OS မှာပြင်ရတာ configure ရတာတွေဘာမှမသိဘူး။ Run လိုက်တယ် user access ဖြစ်ပီးသုံးလို့ရတယ်ဆိုရပီ။ အဲ့လိုမျိုးဆိုတကယ့် traffic လာတဲ့အချိန်မှာ ဘာလုပ်ရမှန်းမသိတော့ဘူး။ နောက်တခုက traffic လာမယ်များမယ်သိလို့ load testing စစ်တာကိုယ်မှန်းထားတဲ့ load ထက်ပိုနိုင်တာဖြစ်တဲ့အတွက် autoscaling လိုမျိုးကိုစကတည်းကသေချာ plan ထားဖို့လိုတယ်။ Auto scaling လိုမျိုး setup လုပ်မထားဘူးဆိုရင်လဲ ကိုယ် deploy လုပ်တဲ့ environment မှာတကယ့်တကယ် traffic လာပီဆို ဘယ်လိုဟာတွေ configure လုပ်ရလဲဆိုတာတွေသိဖို့လိုတယ်။ ကြိုပြင်ဆင်ထားနိုင်ရင်တော့အကောင်းဆုံးပေါ့။ ဒါကတော့ကျနော်လောလောလတ်လတ်ကြုံခဲ့တဲ့ scaling အတွေ့အကြုံပေါ့။