software တွေကို reliable ဖြစ်အောင် ဘယ်လို rollout မလဲ

software version အပြောင်းအလဲတွေမှာ traffic ကို 100% တန်းချိန်းပလိုက်တာမျိုး မလုပ်သင့်ဘူး။ ဘယ်လောက်ပဲ development နဲ့ staging environment တွေမှာ စမ်းသပ်ခဲ့ပြီးပြီလို့ပြောပြော အဲလိုလုပ်တာက တကယ်တမ်း အန္တရာယ်များလွန်းတယ်။ environment တွေက Terraform တို့၊ Chef တို့၊ Puppet တို့လို IaC တွေသုံးပြီး တူအောင် ဆောက်ထားတယ်ပြောပြော လုံးဝဥဿုံ ထပ်တူကျနေမှာတော့ မဟုတ်ဘူး။ ဥပမာ configuration တွေအသေးစိတ် မတူနိုင်ဘူး။ development server မှာ application တွေကို အဖြစ်လောက် တင်ထားတာနဲ့ production server မှာ HA mode လို့ခေါ်တဲ့ ရုတ်တရက် ဆာဗာကျသွားတဲ့ဒဏ်တွေ ခံနိုင်မယ့် ပုံစံမျိုးနဲ့ တင်ထားတာ ကွာမယ်။ staging မှာဆိုရင် database ထဲ data တွေလုံးဝမရှိတဲ့ အသစ်အနေအထားက ပြန်စတာနဲ့ production မှာကတော့ ရှိပြီးသား database ပေါ်ဆက်အလုပ်လုပ်သွားရတာမျိုးတွေ ရှိမယ်။ အဲတော့ ကျွန်တော်တို့ စောစောက ပြောသလို ရှေ့ environment တွေမှာ အဆင်ပြေနေတာပဲဆိုပြီး အသစ်နဲ့အဟောင်း version 2 ခုကို အပြိုင်ထုတ်ပြီး load balancer မှာ endpoint သွားကောက်ချိန်းလိုက်ရုံ လုပ်လို့မရဘူး မလုပ်သင့်ဘူးပေါ့။

ဒီတော့ ဘာလုပ်ရလဲဆိုရင် ဖြေးဖြေးချင်း rollout လုပ်ရတယ်။ အဲလိုလုပ်တဲ့အခါမှာ version အဟောင်းနဲ့အသစ်ကို traffic ခွဲပေးရတယ်။ အဟောင်းကို 90% အသစ်ကို 10% ပေါ့။ အဲလိုကနေ ဖြေးဖြေးချင်း အသစ်ကို ပိုပိုတိုးတိုးပေးသွားမယ်။ 100% ရောက်သွားတဲ့အခါ rollout အောင်မြင်ပြီပေါ့။ ဒီနေရာမှာ မေးစရာမေးခွန်းက ဘယ်အချိန်မှာ ဘယ်လိုအခြေအနေမှာ တိုးပေးမှာလဲဆိုတာပဲ။ အဲဒီမေးခွန်းအတွက် ယေဘုယျကျတဲ့ အဖြေကတော့ ကိုယ့်ကုမ္ပဏီရဲ့ SLA နဲ့ SLO တွေအပေါ် အခြေခံရမယ်ဆိုတာပါ။ ဥပမာ request တွေရဲ့ success rate 95% ရှိရမယ်။ 95% သော request တွေက latency 200ms အောက်ဖြစ်ရမယ်ဆိုတာမျိုး စသဖြင့် SLO တွေပေးထားရင် အဲဒီ rollout ကကိုယ့်ရဲ့ error budget ကိုဘယ်လောက် ယူသုံးသွားလဲဆိုတာမျိုးကို စောင့်ကြည့်ရမှာပေါ့လေ။

ဒီအတွက် ပထမအချက် ကျွန်တော်တို့ application တွေကို mesh လုပ်ဖို့လိုအပ်တယ်။ mesh အကြောင်း ရှေ့မှာသေချာလေး ပြောဖြစ်ထားတော့ သဘောပေါက်လောက်ပြီ ထင်တယ်။ ဒုတိယအချက်က mesh ထားတဲ့ application တွေကနေ အခုဒီ success rate တို့ latency တို့လို metric တွေကို ပေးနိုင်အောင် စီစဥ်ထားရမယ်။ instrument လုပ်တယ် ခေါ်တာပေါ့လေ။ နောက်တတိယအချက်က ဒီ metric တွေကို application တွေဆီက သွားယူဖို့ software တခုသုံးရမယ်။ prometheus ကတော့ ဒီအတွက် စံပဲ။ မသိသေးရင် ဒီမှာ prometheus နဲ့ monitoring အခြေခံ သွားဖတ်စေချင်တယ်။ နံပါတ်လေးအချက်က metric အပြောင်းအလဲကိုကြည့်ပြီး service discovery ကို traffic ratio (အပေါ်မှာပြောခဲ့သလို 9:1, 4:1 စသဖြင့်) လိုအပ်သလို တိုးလျှော့ လှမ်းညှိပေးမယ့် software တွေ script တွေလိုအပ်တယ်။

မဖြစ်မနေ လိုအပ်တာ မဟုတ်ပေမယ့် နောက်ဆုံးတခု ထပ်ဖြည့်ချင်တာက version အသစ်နဲ့အဟောင်းကို သီးသန့်စီ scale ပေးနိုင်မယ့် controller ပါဖို့ပဲ။ ဥပမာ task တွေအထဲမှာမှ long running task တွေချည်း preview (ဗားရှင်းအသစ်) application မှာသွားကျရင် အဟောင်းနဲ့အသစ်ကို တန်းတူ သဘောထားပြီး တပြိုင်တည်း scale လို့မရဘူး။ ဒီလို use case မျိုးတွေဆိုရင် controller သပ်သပ်လိုအပ်တယ်။ အဲသလို controller ကျွန်တော် ရေးဖြစ်ခဲ့တာ ရှိပေမယ့် Argo Project ရဲ့ maintainer တွေနဲ့ အချို့ဟာလေးတွေ ညှိမရလို့ အခုတော့ archive ထားလိုက်ပြီ။ ဆိုတော့ အနှစ်ပြန်ချုပ်ရရင် software version အပြောင်းအလဲတွေမှာ user တွေကို version အသစ်ဆီ တခါတည်း 100% traffic အပြည့်လွှတ်မပေးလိုက်ပဲ ဖြေးဖြေးချင်း validate လုပ်သွားကြဖို့ လိုအပ်တယ်လို့ပါ။