လွယ်လွယ်ပြောရရင် Blue-Green Deployment ဆိုတာ app ရဲ့ version အသစ် တင်တဲ့အခါ website ခနလေးတောင် မကျအောင် server အစုံ နှစ်စုံ (အပြာ တစ်စုံ၊ အစိမ်း တစ်စုံ) ကို အလှည့်ကျ သုံးတဲ့ နည်းလမ်း ပါ။
တံတားပြင်တာနဲ့ ဥပမာပေးရအောင်။ မြစ်ကူးတံတား တစ်စင်း ပြင်ချင်တယ် ဆိုပါစို့။ တံတားအဟောင်းကို ပိတ်ပြီး ပြင်ရင် လူတွေ ဖြတ်သန်းလို့ မရတော့ဘူး — ဒါက ရိုးရိုး deployment (downtime ရှိ)။ Blue-green နည်းက ဘေးမှာ တံတားအသစ် တစ်စင်း အရင် ဆောက်တယ်။ ပြီးစီးပြီး စစ်ဆေးပြီးမှ လမ်းကြောင်းကို တံတားအသစ်ဆီ လွှဲပေးလိုက်တယ်။ အဟောင်းမှာ ပြဿနာတွေ့ရင် တစ်မိနစ်အတွင်း လမ်းကြောင်း ပြန်လွှဲလို့ ရတယ်။
အလုပ်လုပ်ပုံ အဆင့်ဆင့် —
Blue = အခု user တွေ သုံးနေတဲ့ version (live)။ Traffic အားလုံး ဒီကို လာနေတယ်
Green = version အသစ် တင်ထားတဲ့ အစုံ။ အပြင်လူ မမြင်ရသေးဘူး၊ ဒါပေမယ့် အသက် ဝင်နေတယ်
Green မှာ စမ်းသပ်မှုတွေ အားလုံး လုပ်တယ် — login ဝင်လို့ ရလား၊ ငွေပေးချေမှု အလုပ်လုပ်လား၊ မြန်နှုန်း အိုကေလား
အဆင်ပြေပြီ ဆိုတာနဲ့ load balancer (ဒါမှမဟုတ် router) က traffic ကို blue ကနေ green ဆီ တစ်ခါတည်း လွှဲပေးလိုက်တယ်။ User တွေ ဘာမှ မသိလိုက်ဘူး
တစ်ခုခု မှားနေတယ် ဆိုရင် traffic ကို blue ဆီ ပြန်လွှဲ — rollback က စက္ကန့်ပိုင်းပဲ ကြာတယ်
ဒီနည်းရဲ့ အကောင်းဆုံး အချက်က rollback မြန်တာ။ ရိုးရိုး deployment မှာ version အသစ် တင်ပြီးမှ bug တွေ့ရင် အဟောင်းကို ပြန်တင်ရတယ် — အဲဒါ မိနစ် ၂၀၊ နာရီဝက် ကြာနိုင်တယ်။ အဲဒီအချိန်မှာ site က ပျက်နေတယ်။ Blue-green မှာတော့ အဟောင်း (blue) က အသက် ဝင်နေတုန်း ဖြစ်နေတော့ switch တစ်ချက် နှိပ်ရုံနဲ့ ပြန်ကောင်းသွားတယ်။
အားသာချက်တွေ —
Zero downtime — user တွေ update တင်နေမှန်း မသိလိုက်ဘူး
Instant rollback — ပြဿနာတက်ရင် စက္ကန့်ပိုင်းနဲ့ ပြန်လည်
Production နဲ့ တူတဲ့ ပတ်ဝန်းကျင်မှာ စမ်းလို့ ရတယ် — green က server အစစ်ပဲ ဖြစ်နေတော့ “ကိုယ့်စက်မှာ အလုပ်လုပ်တယ်” ဆိုတဲ့ ပြဿနာ မရှိဘူး
ဒါပေမယ့် အလကား မရဘူး၊ ပေးဆပ်ရတာတွေ ရှိတယ် —
Server နှစ်ဆ ကုန်တယ်။ Blue လည်း run နေရမယ်၊ green လည်း run နေရမယ်။ Cloud bill နှစ်ဆ တက်နိုင်တယ် (ခနတာပဲ ဖြစ်ပေမယ့်)
Database ကို ဂရုစိုက်ရတယ်။ Blue နဲ့ green နှစ်ခုလုံး database တစ်ခုတည်း သုံးနေရင် version အသစ်က table ပုံစံ ပြောင်းလိုက်မိရင် အဟောင်း ပျက်သွားနိုင်တယ်။ Database migration ကို နောက်ကြောင်း ညီအောင် စီစဉ်ရတယ်
Session/state ပြဿနာ။ User က blue မှာ login ဝင်ထားပြီး green ဆီ ရောက်သွားရင် logout ဖြစ်သွားနိုင်တယ်။ Session ကို Redis လို shared store မှာ ထားမှ အဆင်ပြေတယ်
ဆင်တူတဲ့ နောက်တစ်နည်းက canary deployment — version အသစ်ကို user ၁% လောက်ကိုပဲ အရင် ပေးသုံးပြီး ကြည့်တာ။ Blue-green က “အားလုံး တစ်ခါတည်း လွှဲ” ဖြစ်ပြီး canary က “နည်းနည်း ချင်း စမ်း” ဖြစ်တယ်။ ကုမ္ပဏီကြီးတွေ (Facebook, Google) က နှစ်မျိုးလုံး ရောသုံးကြတယ်။
ကျွန်တော် အရင်က freelance project တစ်ခုမှာ သောကြာနေ့ ည ၁၁ နာရီ update တင်ပြီး site ၄၀ မိနစ် ကျသွားဖူးတယ်။ Client ဖုန်းဆက်လာတော့ ချွေးတွေ ထွက်လာတာ မှတ်မိသေးတယ်။ အဲဒီနေ့ကသာ blue-green သုံးခဲ့ရင် switch တစ်ချက် နှိပ်ရုံနဲ့ ပြီးသွားမှာ။ Deployment ဆိုတာ code ရေးတာထက် စိတ်ပူစရာ ကောင်းတဲ့ အလုပ်ပါ — ဒီနည်းက အဲဒီ စိတ်ပူမှုကို တော်တော် လျှော့ပေးတယ်။ 🙂
