Deployment Strategies: Rolling, Blue-Green, Canary

နားလည်ထားရမယ့် အချက်

rolling, blue-green, canary သုံးမျိုးဟာ မေးခွန်းတစ်ခုတည်းအတွက် အဖြေ သုံးမျိုးပါ — version အသစ် ထွက်နေတဲ့ အချိန်အတွင်း live traffic က ဘာကို မြင်နေရမလဲ ဆိုတဲ့ မေးခွန်းပါ။

rolling deploy က instance တွေကို တစ်စုချင်း အစားထိုးတယ်။ rollout ကြာချိန်တစ်လျှောက် အဟောင်းနဲ့ အသစ် ဘေးချင်းယှဉ် run နေတယ်၊ ဒါကြောင့် နှစ်ခုလုံးက တစ်ခုနဲ့တစ်ခု သည်းခံနိုင်ရမယ် — အရေးကြီးဆုံးက database schema တစ်ခုတည်းကို နှစ်ခုလုံး လက်ခံနိုင်ရမယ်။ capacity အပိုမလိုသလောက်ပဲ လိုလို့ နေရာတိုင်းမှာ default ဖြစ်နေတယ်၊ ဒါပေမယ့် version ဆိုးတစ်ခုက user ဆီ တဖြည်းဖြည်း ရောက်သွားတယ်၊ rollback လုပ်ဖို့ဆိုရင်လည်း အပြန် rollout တစ်ခေါက်လုံး ထပ်လုပ်ရတယ်။

blue-green က environment နှစ်ခုလုံးကို အပြည့်ထားတယ်။ green က အားလပ်နေတယ်၊ အဲဒီမှာ deploy လုပ်၊ တကယ့် infrastructure နဲ့ စမ်း၊ ဒါပေမယ့် တကယ့် user မရှိသေးဘူး၊ ပြီးမှ router ကို လှည့်လိုက်တယ်။ cutover က ချက်ချင်းနီးပါး၊ ပြန်ရုပ်တာလည်း ချက်ချင်းပဲ — ပြန်လှည့်လိုက်ရုံပါပဲ။ အဲဒီအတွက် ပေးရတဲ့ အဖိုးအခက release အချိန်မှာ production footprint နှစ်ဆလောက် ကုန်တာနဲ့၊ လက်ကျန် in-flight request တွေ၊ စွန့်ခွာလိုက်တဲ့ဘက်က နွေးပြီးသား cache တွေရဲ့ ပြဿနာပါ။

canary က traffic အနည်းငယ် — ၁ ရာခိုင်နှုန်း၊ ပြီးရင် ၁၀၊ ပြီးရင် ၅၀ — ကို version အသစ်ဆီ ပို့ပြီး အဆင့်တစ်ခုနဲ့တစ်ခုကြားမှာ error rate နဲ့ latency ကို စောင့်ကြည့်တယ်။ တကယ့် user တွေကမှ ဖြစ်စေတတ်တဲ့ ပြဿနာမျိုးကို ဖမ်းနိုင်တယ်၊ ဒါပေမယ့် traffic ခွဲပေးနိုင်တဲ့ layer တစ်ခုလိုတယ်၊ ပိုခက်တာက promote လား abort လား ဆုံးဖြတ်ပေးမယ့် metric နဲ့ threshold တွေကို ကြိုသဘောတူထားရတယ်။ အဲဒီ analysis မပါရင် canary ဟာ နှေးတဲ့ rolling deploy တစ်ခုသာ ဖြစ်နေမယ်။

"zero downtime" ဆိုတာ ဒီနည်းလမ်းတွေရဲ့ မွေးရာပါ ဂုဏ်သတ္တိ မဟုတ်ဘူး — backward-compatible request, connection draining, တကယ့် readiness ကို မှန်မှန်ပြောပြတဲ့ health check တွေ လိုတယ်။ ပြီးတော့ တကယ်ခက်တဲ့နေရာက app က ရှားရှားပါးပါးပါ။ version နှစ်ခုက database တစ်ခုတည်းကို မျှသုံးနေတဲ့အတွက် schema က နှစ်ခုလုံးနဲ့ ကိုက်ရမယ် — release အများစုကို နစ်စေတာ deploy mechanic မဟုတ်ဘဲ migration ဖြစ်တဲ့ အကြောင်းရင်းက ဒါပါပဲ။

TRAFFIC DISTRIBUTION OVER TIME
------------------------------
TIME ------------------------------------------------------->

ROLLING
  old  #########  ######  ###    #
  new             ##      ####   ######   #########
  both versions live at once; one schema must serve both

BLUE-GREEN
  blue  ###########################|
  green                            |###################
                          switch --+  (instant, reversible)
  cost: two full environments during the release

CANARY
  old  ##########   #######   #####   ###
  new  #            ##        #####   #########
       1%           10%       50%     100%
       |            |         |
       +-- check error rate / latency, then promote or abort

HARD PART (all three): the database both versions share

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

ဒီ workflow က canary ကို အဆင့်တွေအဖြစ် ခွဲပြထားတယ်။ canary job က traffic ၁၀ ရာခိုင်နှုန်းကို version အသစ်ဆီ ပို့ပြီး၊ ပြီးရင် error rate ကို သတ်မှတ်ထားတဲ့ window အတွင်း စစ်တယ်။ ဒီနေရာမှာ အရေးကြီးတာက check-error-rate script က threshold ကျော်ရင် non-zero exit code ပြန်ပေးရမယ် ဆိုတာပါ — အဲဒါက step ကို fail စေပြီး၊ အဲဒီ fail က ကျန်တဲ့ ဆုံးဖြတ်ချက်တွေကို မောင်းနှင်တယ်။ metric ကို ဖတ်ပြီး လူကိုပဲ ပြသွားတဲ့ script ဆိုရင် canary မဟုတ်တော့ဘူး၊ dashboard တစ်ခုပဲ ဖြစ်သွားမယ်။

promote job က needs: canary ပါလို့ canary အောင်မြင်မှသာ run တယ်။ rollback job ကတော့ if: failure() နဲ့ တွဲထားလို့ canary ကျရင် အလိုအလျောက် traffic ကို stable version ဆီ ပြန်ပို့တယ်။ ဒီ pattern ကို လက်တွေ့မှာ အသုံးဝင်စေတာက ချက်ချင်း ပြန်နိုင်တဲ့ လမ်းကြောင်းက pipeline ထဲမှာ ကြိုရေးထားပြီးသား ဖြစ်နေလို့ပါ — incident ဖြစ်မှ command မှတ်မိအောင် ကြိုးစားစရာ မလိုတော့ဘူး။

blue-green ကို စမ်းချင်ရင် set-traffic-weight.sh ကို ၁၀ အစား ၁၀၀ ထားပြီး အလယ်က စောင့်တဲ့ step ကို ဖြုတ်လိုက်ရုံပါပဲ — အဲဒါက blue-green ဟာ တကယ်တော့ အဆင့်တစ်ဆင့်တည်းရှိတဲ့ canary ဖြစ်တယ် ဆိုတာ ပြပေးတယ်။ ပြီးရင် ကိုယ့် app က version နှစ်ခု တစ်ပြိုင်တည်း run နေတာကို တကယ် ခံနိုင်လား စစ်ပါ။

• rolling က ဈေးသက်သာ၊ blue-green က ပြန်ရုပ်ရ မြန်တယ်
• metric analysis မပါရင် canary က canary မဟုတ်ဘူး
• အခက်ဆုံးက app မဟုတ်၊ shared database ပါ

အတူတူ စမ်းရေးကြည့်မယ်

name: Canary Release
on:
  workflow_dispatch:
    inputs:
      image_tag:
        description: Immutable image tag to release
        required: true
        type: string
permissions:
  contents: read
  id-token: write
jobs:
  canary:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE }}
          aws-region: ap-southeast-1
      - name: Send 10 percent of traffic to the new version
        run: ./scripts/set-traffic-weight.sh ${{ inputs.image_tag }} 10
      - name: Fail if error rate breaches the threshold
        run: ./scripts/check-error-rate.sh --window 10m --max-error-rate 0.01
  promote:
    needs: canary
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE }}
          aws-region: ap-southeast-1
      - name: Send all traffic to the new version
        run: ./scripts/set-traffic-weight.sh ${{ inputs.image_tag }} 100
  rollback:
    needs: canary
    if: failure()
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE }}
          aws-region: ap-southeast-1
      - name: Send all traffic back to the stable version
        run: ./scripts/set-traffic-weight.sh ${{ inputs.image_tag }} 0

workflow ကို image tag တစ်ခုနဲ့ ကိုယ်တိုင် စတင်လိုက်ရင် canary job က traffic ၁၀ ရာခိုင်နှုန်းကို အသစ်ဆီ ရွှေ့ပြီး error rate ကို စောင့်စစ်တယ်။ စစ်တဲ့ step က အောင်မြင်ရင် promote job က ဆက် run ပြီး traffic အားလုံးကို ရွှေ့ပေးတယ်၊ rollback job ကတော့ မ run ဘူး။ error rate က threshold ကျော်ပြီး step က non-zero နဲ့ ထွက်ရင် promote က needs မပြည့်လို့ ကျော်သွားပြီး၊ if: failure() ရှိတဲ့ rollback job က traffic weight ကို သုညပြန်ချပေးတယ်။ job သုံးခုလုံးက production environment ကို သုံးထားလို့ အဲဒီ environment မှာ protection rule ထားရင် canary မစခင်မှာ ပထမဆုံး ရပ်စောင့်ပါလိမ့်မယ်။

Google Cloud Architecture: Application deployment and testing strategies — CI/CD with GitHub Actions