Istio Circuit Breaker- မှားယွင်းနေသော ကွန်တိန်နာများကို ပိတ်ထားသည်။

အားလပ်ရက်များကုန်ဆုံးပြီး Istio Service Mesh စီးရီးတွင် ကျွန်ုပ်တို့၏ဒုတိယပို့စ်နှင့်အတူ ပြန်ရောက်ပါပြီ။

ယနေ့ ခေါင်းစဉ်မှာ ရုရှားလျှပ်စစ်အင်ဂျင်နီယာဘာသာသို့ ပြန်ဆိုထားသည့် Circuit Breaker ဖြစ်ပြီး ဘုံစာကြောင်းအရ "circuit breaker" ဟု အဓိပ္ပါယ်ရသည်။ Istio တွင်သာ ဤစက်သည် တိုတောင်းသော သို့မဟုတ် ဝန်ပိုနေသော ဆားကစ်ကို ဖြတ်တောက်ခြင်းမပြုဘဲ ကွန်တိန်နာများ မှားယွင်းနေပါသည်။

ဒါကို ဘယ်လို စံနမူနာပြုသင့်သလဲ။

Microservices များကို Kubernetes မှ စီမံခန့်ခွဲသည့်အခါ ဥပမာအားဖြင့် OpenShift ပလပ်ဖောင်းအတွင်း၊ ၎င်းတို့သည် ဝန်ပေါ်မူတည်၍ အလိုအလျောက် အရွယ်အစား အတက်အဆင်းရှိသည်။ မိုက်ခရိုဝန်ဆောင်မှုများသည် pods များတွင် လုပ်ဆောင်သောကြောင့်၊ အဆုံးမှတ်တစ်ခုတွင် ကွန်တိန်နာထည့်သွင်းထားသော မိုက်ခရိုဝန်ဆောင်မှု၏ သာဓကများစွာရှိနိုင်ပြီး Kubernetes သည် တောင်းဆိုမှုများကို လမ်းကြောင်းပေးကာ ၎င်းတို့ကြားရှိ လက်ကျန်ငွေများကို တင်ပေးမည်ဖြစ်သည်။ ပြီးတော့ - အကောင်းဆုံးကတော့ - ဒါတွေအားလုံး ပြီးပြည့်စုံစွာ လုပ်ဆောင်သင့်တယ်။

Microservices များသည် သေးငယ်ပြီး ပေါ်ပင်ဖြစ်ကြောင်း ကျွန်ုပ်တို့ သတိရပါ။ ဤနေရာတွင် ပေါ်လာခြင်းနှင့် ပျောက်ကွယ်ရန် လွယ်ကူခြင်းဟု အဓိပ္ပါယ်ရသော ပေါ့ပါးမှုသည် လျှော့တွက်လေ့ရှိသည်။ pod တစ်ခုရှိ microservice ၏နောက်ထပ်ဥပမာတစ်ခု၏မွေးဖွားခြင်းနှင့်သေဆုံးခြင်းတို့သည်အတော်လေးမျှော်လင့်ထားသည့်အရာများဖြစ်သည်၊ OpenShift နှင့် Kubernetes သည်၎င်းကိုကောင်းစွာကိုင်တွယ်ပြီးအရာအားလုံးသည်ကောင်းမွန်စွာအလုပ်လုပ်သည် - သို့သော် သီအိုရီအရထပ်တွေ့သည်။

တကယ်အလုပ်လုပ်ပုံ

ယခုတွင် ကွန်တိန်နာတစ်ခုဖြစ်သည့် microservice ၏ သီးခြားဥပမာတစ်ခုသည် အသုံးမပြုနိုင်တော့ပြီဖြစ်သည်- (error 503) ကို မတုံ့ပြန်ဘဲ ဖြစ်ဖြစ်၊ ပိုစိတ်မကောင်းဖြစ်စရာက တုံ့ပြန်သော်လည်း နှေးကွေးလွန်းပါသည်။ တစ်နည်းဆိုရသော်၊ ၎င်းသည် ချို့ယွင်းသွားခြင်း သို့မဟုတ် တောင်းဆိုမှုများကို တုံ့ပြန်ခြင်းမရှိသော်လည်း ၎င်းကို ရေကန်မှ အလိုအလျောက်ဖယ်ရှားမည်မဟုတ်ပါ။ ဒီကိစ္စမှာ ဘာလုပ်သင့်လဲ။ ထပ်စမ်းကြည့်မလား။ လမ်းကြောင်းအစီအစဉ်မှ ဖယ်ရှားသင့်ပါသလား။ “အရမ်းနှေးတယ်” ဆိုတာ ဘာကိုဆိုလိုသလဲ – အရေအတွက် ဘယ်လောက်ရှိသလဲ၊ အဲဒါတွေကို ဘယ်သူက ဆုံးဖြတ်မလဲ။ ခဏနားပြီး နောက်မှ ထပ်စမ်းကြည့်တာ ဖြစ်နိုင်ပါတယ်။ အဲဒီလိုဆိုရင် ဘယ်လောက်ကြာလဲ။

Istio ရှိ Pool Ejection ဆိုတာဘာလဲ

ဤနေရာတွင် Istio သည် Pool Ejection လုပ်ထုံးလုပ်နည်းကို အကောင်အထည်ဖော်ပြီး မှားယွင်းနေသောကွန်တိန်နာများကို လမ်းကြောင်းတင်ခြင်းနှင့် ဝန်ချိန်ညှိခြင်းဆိုင်ရာ အရင်းအမြစ်ရေကန်မှ ယာယီဖယ်ရှားပေးသည့် ၎င်း၏ Circuit Breaker အကာအကွယ်စက်များဖြင့် ကယ်ဆယ်လာပါသည်။

ပိုသာလွန်သော ထောက်လှမ်းမှုဗျူဟာကို အသုံးပြု၍ Istio သည် လိုင်းပြတ်တောက်နေသော မျဉ်းကွေးကွက်များကို ရှာဖွေတွေ့ရှိပြီး အိပ်ချိန်ဝင်းဒိုးဟုခေါ်သော သတ်မှတ်ထားသော အချိန်အတိုင်းအတာတစ်ခုအထိ အရင်းအမြစ်ရေကန်မှ ၎င်းတို့ကို ဖယ်ရှားသည်။

၎င်းသည် OpenShift ပလပ်ဖောင်းရှိ Kubernetes တွင် မည်သို့အလုပ်လုပ်ကြောင်းပြသရန်၊ repository ရှိ နမူနာမှ ပုံမှန်အလုပ်လုပ်နေသော microservices များ၏ screenshot ဖြင့်စကြပါစို့။ Red Hat Developer Demos. ဤတွင် ကျွန်ုပ်တို့တွင် အကွက်နှစ်ခု၊ v1 နှင့် v2 ရှိပြီး တစ်ခုစီတွင် ကွန်တိန်နာတစ်လုံးစီရှိသည်။ Istio လမ်းကြောင်းသတ်မှတ်ခြင်းဆိုင်ရာ စည်းမျဉ်းများကို အသုံးမပြုသောအခါ၊ Kubernetes သည် အညီအမျှ ဟန်ချက်ညီသော အလှည့်ကျလမ်းကြောင်းကို သတ်မှတ်သည်-

ပျက်ကျမှုအတွက် ပြင်ဆင်နေပါသည်။

Pool Ejection မပြုလုပ်မီ၊ သင်သည် Istio လမ်းကြောင်းသတ်မှတ်ခြင်းစည်းမျဉ်းကို ဖန်တီးရန် လိုအပ်သည်။ 50/50 အချိုးဖြင့် pods များအကြား တောင်းဆိုမှုများကို ဖြန့်ဝေလိုသည်ဆိုကြပါစို့။ ထို့အပြင်၊ ကျွန်ုပ်တို့သည် ဤကဲ့သို့သော v2 ကွန်တိန်နာများ၏ အရေအတွက်ကို တစ်ခုမှ နှစ်ခုအထိ တိုးပေးမည်၊

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

ယခု ကျွန်ုပ်တို့သည် 50/50 အချိုးဖြင့် pods များအကြား traffic ကိုဖြန့်ဝေနိုင်ရန် လမ်းကြောင်းသတ်မှတ်ခြင်းစည်းမျဉ်းကို သတ်မှတ်ခဲ့သည်။

ဤစည်းမျဉ်း၏ ရလဒ်မှာ အောက်ပါအတိုင်းဖြစ်သည်-

ဤစခရင်သည် 50/50 မဟုတ်သော်လည်း 14:9 ဖြစ်သောကြောင့် အချိန်ကြာလာသည်နှင့်အမျှ အခြေအနေ ပိုမိုကောင်းမွန်လာမည်ကို သင် အမှားတွေ့နိုင်သည်။

ချို့ယွင်းချက်တစ်ခု ပြုလုပ်ခြင်း။

ယခု ကျွန်ုပ်တို့တွင် ကျန်းမာသော v2 ကွန်တိန်နာတစ်ခု၊ ကျန်းမာသော v1 ကွန်တိန်နာတစ်ခုနှင့် မှားယွင်းနေသော v2 ကွန်တိန်နာတစ်ခုတို့ရှိစေရန် ယခု v2 ကွန်တိန်နာနှစ်ခုထဲမှ တစ်ခုကို ပိတ်လိုက်ကြပါစို့။

ချို့ယွင်းချက် ပြုပြင်ခြင်း။

ထို့ကြောင့်၊ ကျွန်ုပ်တို့တွင် မှားယွင်းနေသော ကွန်တိန်နာတစ်ခုရှိပြီး Pool Ejection အတွက် အချိန်ကျရောက်ပြီဖြစ်သည်။ အလွန်ရိုးရှင်းသော config ကိုအသုံးပြုခြင်းဖြင့်၊ ဤမအောင်မြင်သောကွန်တိန်နာကို မည်သည့်လမ်းကြောင်းစနစ်မှမဆို 15 စက္ကန့်ကြာ ဖယ်ထုတ်မည်ဖြစ်ပြီး ၎င်းသည် ကျန်းမာသောအခြေအနေသို့ပြန်ရောက်လာမည် (ပြန်လည်စတင်သည် သို့မဟုတ် စွမ်းဆောင်ရည်ပြန်လည်ရရှိမည်) ဟုမျှော်လင့်ချက်ဖြင့် ဖယ်ထုတ်ပါမည်။ ဤအရာသည် ဤဖွဲ့စည်းပုံပုံစံနှင့် ၎င်း၏အလုပ်၏ရလဒ်များဖြစ်သည်-

သင်မြင်သည့်အတိုင်း၊ မအောင်မြင်သော v2 ကွန်တိန်နာကို ရေကန်မှဖယ်ရှားလိုက်သောကြောင့် လမ်းကြောင်းတောင်းဆိုမှုများအတွက် အသုံးမပြုတော့ပါ။ ဒါပေမယ့် 15 စက္ကန့်ကြာပြီးနောက် ရေကန်ထဲကို အလိုအလျောက် ပြန်သွားပါလိမ့်မယ်။ တကယ်တော့၊ Pool Ejection အလုပ်လုပ်ပုံကို ပြသလိုက်ရုံပါပဲ။

ဗိသုကာပညာကို စတင်တည်ဆောက်ကြပါစို့

Istio ၏စောင့်ကြည့်နိုင်မှုစွမ်းရည်များနှင့်ပေါင်းစပ်ထားသော Pool Ejection သည် ချို့ယွင်းနေသောကွန်တိန်နာများကို အလိုအလျောက်အစားထိုးခြင်းအတွက် မူဘောင်တစ်ခုကို စတင်တည်ဆောက်နိုင်မည်ဖြစ်ပြီး၊ မဖယ်ရှားပါက၊ စက်ရပ်ချိန်နှင့် ပျက်ကွက်မှုများကို လျှော့ချနိုင်မည်ဖြစ်သည်။
 
NASA တွင် ကျယ်လောင်သောဆောင်ပုဒ်တစ်ခုရှိသည် - Failure Is Not an Option ၊ ပျံသန်းရေးဒါရိုက်တာဟု ယူဆရသော စာရေးဆရာ၊ Gene Kranz. ၎င်းကို "ကျရှုံးခြင်းသည် ရွေးချယ်စရာမဟုတ်ပါ" ဟု ရုရှားဘာသာသို့ ပြန်ဆိုနိုင်ပြီး ဤနေရာတွင် အဓိပ္ပာယ်မှာ သင့်တွင် ဆန္ဒအလုံအလောက်ရှိလျှင် အရာအားလုံးကို လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။ သို့သော်၊ လက်တွေ့ဘဝတွင်၊ ကျရှုံးမှုများသည် ဖြစ်ပေါ်လာသည်မဟုတ်၊ ၎င်းတို့သည် နေရာတိုင်းနှင့် အရာအားလုံးတွင် မလွဲမသွေဖြစ်သည်။ microservices ကိစ္စမှာ သူတို့ကို ဘယ်လိုဖြေရှင်းမလဲ။ ကျွန်ုပ်တို့၏အမြင်အရ၊ စိတ်အားထက်သန်မှုကို မမှီခိုဘဲ ကွန်တိန်နာများ၏ စွမ်းဆောင်နိုင်မှုအပေါ်တွင်သာ မှီခိုနေခြင်းသည် သာလွန်ကောင်းမွန်ပါသည်။ Kubernetes, RedHat OpenShiftနှင့် Istio.

အထက်တွင်ရေးခဲ့သည့်အတိုင်း Istio သည် ရုပ်ပိုင်းဆိုင်ရာလောကတွင် သူ့ကိုယ်သူကောင်းစွာသက်သေပြခဲ့သည့် circuit breakers ၏သဘောတရားကိုအကောင်အထည်ဖော်သည်။ လျှပ်စစ်ဆားကစ် ဘရိတ်ကာသည် ဆားကစ်တစ်ခု၏ ပြဿနာအပိုင်းကို ပိတ်လိုက်သကဲ့သို့၊ Istio ၏ဆော့ဖ်ဝဲ Circuit Breaker သည် အဆုံးမှတ်နှင့် တစ်စုံတစ်ရာ မှားယွင်းနေသောအခါ၊ ဥပမာ၊ ဆာဗာ ပျက်ကျသောအခါ သို့မဟုတ် စတင်သောအခါ၊ တောင်းဆိုချက်တစ်ခုနှင့် ပြဿနာကွန်တိန်နာကြား ချိတ်ဆက်မှုကို ဖွင့်ပေးသည်။ အရှိန်လျော့သည်။

ထို့အပြင်၊ ဒုတိယကိစ္စတွင်၊ ကွန်တိန်နာတစ်ခု၏ဘရိတ်များသည် ၎င်းကိုဝင်ရောက်သည့်ဝန်ဆောင်မှုများတွင်နှောင့်နှေးစေရုံသာမက၊ ရလဒ်အနေဖြင့် စနစ်တစ်ခုလုံး၏စွမ်းဆောင်ရည်ကိုလျော့ကျစေသည့်အပြင် ထပ်ခါထပ်ခါထုတ်လုပ်နိုင်သောကြောင့်၊ အခြေအနေပိုမိုဆိုးရွားစေသည့် နှေးကွေးသော လည်ပတ်နေပြီဖြစ်သော ဝန်ဆောင်မှုကို တောင်းဆိုပါသည်။

သီအိုရီအရ Circuit Breaker

Circuit Breaker သည် endpoint သို့ တောင်းဆိုမှုများ စီးဆင်းမှုကို ထိန်းချုပ်သည့် proxy တစ်ခုဖြစ်သည်။ ဤအချက်သည် အလုပ်မလုပ်တော့သည့်အခါ သို့မဟုတ် သတ်မှတ်ထားသည့်ဆက်တင်များပေါ် မူတည်၍ နှေးကွေးလာသည်၊ ပရောက်စီသည် ကွန်တိန်နာနှင့် ချိတ်ဆက်မှုကို ဖြတ်တောက်မည်ဖြစ်သည်။ ထို့နောက် အသွားအလာကို ဝန်ချိန်ခွင်လျှာချိန်ညှိမှုကြောင့် အခြားကွန်တိန်နာများသို့ လမ်းကြောင်းပြန်ညွှန်းသည်။ ပေးထားသည့် အိပ်စက်ခြင်းပြတင်းပေါက်တစ်ခုအတွက် ချိတ်ဆက်မှုကို ဖွင့်ထားဆဲဖြစ်ပြီး နှစ်မိနစ်ဟုပြောကာ တစ်ဝက်ဖွင့်သည်ဟု ယူဆပါသည်။ နောက်ထပ်တောင်းဆိုချက်ကို ပေးပို့ရန် ကြိုးပမ်းမှုသည် ချိတ်ဆက်မှု၏ နောက်ထပ်အခြေအနေကို ဆုံးဖြတ်သည်။ ဝန်ဆောင်မှုနှင့် အားလုံး အဆင်ပြေပါက၊ ချိတ်ဆက်မှုသည် အလုပ်အခြေအနေသို့ ပြန်သွားပြီး နောက်တစ်ကြိမ် ပိတ်သွားပါမည်။ ဝန်ဆောင်မှုတွင် တစ်ခုခုမှားယွင်းနေသေးပါက၊ ချိတ်ဆက်မှုပြတ်တောက်ပြီး အိပ်စက်ခြင်းဝင်းဒိုးကို ပြန်လည်ဖွင့်ထားသည်။ ဤသည်မှာ ရိုးရှင်းသော Circuit Breaker state diagram နှင့်တူသည်-

ဤနေရာတွင် ဤအရာအားလုံးသည် စနစ်ဗိသုကာအဆင့်တွင် ဖြစ်သည်ကို သတိပြုရန် အရေးကြီးပါသည်။ ထို့ကြောင့် တစ်ချိန်ချိန်တွင် သင်သည် သင်၏အပလီကေးရှင်းများကို Circuit Breaker ဖြင့်လုပ်ဆောင်ရန် သင်သင်ကြားပေးရမည်ဖြစ်ပြီး၊ တုံ့ပြန်မှုတွင် ပုံသေတန်ဖိုးတစ်ခုပေးခြင်း၊ သို့မဟုတ် ဖြစ်နိုင်ပါက ဝန်ဆောင်မှုတည်ရှိမှုကို လျစ်လျူရှုခြင်းကဲ့သို့သော သင့်အပလီကေးရှင်းများကို သင်ကြားပေးရမည်ဖြစ်ပါသည်။ ၎င်းအတွက် bulkhead ပုံစံကို အသုံးပြုထားသော်လည်း ၎င်းသည် ဤဆောင်းပါး၏ အတိုင်းအတာထက်ကျော်လွန်ပါသည်။

Circuit Breaker ကို လက်တွေ့လုပ်ပါ။

ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် OpenShift တွင် ကျွန်ုပ်တို့၏ အကြံပြုချက် microservice ဗားရှင်းနှစ်မျိုးကို လုပ်ဆောင်ပါမည်။ ဗားရှင်း 1 သည် ကောင်းမွန်သော်လည်း v2 တွင် ဆာဗာတွင် နှေးကွေးမှုများကို အတုယူရန် နှောင့်နှေးမှုကို တည်ဆောက်ပါမည်။ ရလဒ်များကိုကြည့်ရှုရန်၊ ကိရိယာကိုအသုံးပြုပါ။ မြို့ကိုဝိုင်းထား:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

အားလုံးက အလုပ်ဖြစ်ပုံရတယ်၊ ဒါပေမယ့် ဘယ်လောက်ကုန်ကျလဲ။ ပထမတစ်ချက်တွင်၊ ကျွန်ုပ်တို့တွင် 100% ရရှိနိုင်သော်လည်း အနီးကပ်ကြည့်ရှုကြည့်ပါ - အများဆုံးငွေပေးငွေယူကြာချိန်သည် 12 စက္ကန့်ဖြစ်သည်။ ဤသည်မှာ ရှင်းရှင်းလင်းလင်းပင် တစ်ဆို့နေပြီး ချဲ့ထွင်ရန် လိုအပ်သည်။

ထိုသို့လုပ်ဆောင်ရန်၊ နှေးကွေးသောကွန်တိန်နာများသို့ခေါ်ဆိုမှုများကိုဖယ်ရှားရန် Istio ကိုအသုံးပြုပါမည်။ ၎င်းသည် Circuit Breaker ကိုအသုံးပြု၍ သက်ဆိုင်ရာ config နှင့်တူသည်-

httpMaxRequestsPerConnection ပါရာမီတာနှင့် နောက်ဆုံးစာကြောင်းသည် ရှိပြီးသားတစ်ခုအပြင် အခြားတစ်ခု-တစ်စက္ကန့်-ချိတ်ဆက်မှုကို ဖန်တီးရန်ကြိုးစားသည့်အခါ ၎င်းနှင့်ချိတ်ဆက်မှုကို ဖြတ်တောက်သင့်ကြောင်း အချက်ပြသည်။ ကျွန်ုပ်တို့၏ကွန်တိန်နာသည် နှေးကွေးသောဝန်ဆောင်မှုကို အတုယူသောကြောင့်၊ ထိုသို့သောအခြေအနေများသည် အခါအားလျော်စွာ ပေါ်ပေါက်လာမည်ဖြစ်ပြီး၊ ထို့နောက် Istio သည် 503 error ကို ပြန်ပေးလိမ့်မည်၊ သို့သော် ၎င်းသည် ဝိုင်းထားမှုကို ပြသလိမ့်မည်-

အိုကေ၊ ကျွန်ုပ်တို့တွင် Circuit Breaker ရှိသည်၊ နောက်တစ်ခုက ဘာလဲ။

ထို့ကြောင့် ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုများ၏ အရင်းအမြစ်ကုဒ်ကို လုံးဝမထိဘဲ အလိုအလျောက်ပိတ်ခြင်းကို လုပ်ဆောင်ခဲ့ပါသည်။ အထက်တွင်ဖော်ပြထားသော Circuit Breaker နှင့် Pool Ejection လုပ်ထုံးလုပ်နည်းကိုအသုံးပြုခြင်းဖြင့်၊ ကျွန်ုပ်တို့သည် ပုံမှန်အခြေအနေသို့ပြန်ရောက်သည်အထိ အရင်းအမြစ်ရေကန်မှ ဘရိတ်ကွန်တိန်နာများကို ဖယ်ရှားနိုင်ပြီး သတ်မှတ်ထားသောကြိမ်နှုန်းဖြင့် ၎င်းတို့၏အခြေအနေကို စစ်ဆေးနိုင်သည် - ကျွန်ုပ်တို့၏ဥပမာတွင်၊ ဤသည်မှာ နှစ်မိနစ် (sleepWindow ကန့်သတ်ဘောင်) ဖြစ်သည်။

503 အမှားကို တုံ့ပြန်နိုင်စွမ်းသည် အပလီကေးရှင်းတစ်ခု၏ အရင်းအမြစ်ကုဒ်အဆင့်တွင် သတ်မှတ်ထားဆဲဖြစ်ကြောင်း သတိပြုပါ။ အခြေအနေပေါ်မူတည်၍ Circuit Breaker ကိုအသုံးပြုရန် နည်းဗျူဟာများစွာရှိသည်။

နောက်ပို့စ်တွင်- Istio တွင် ထည့်သွင်းထားပြီး သို့မဟုတ် အလွယ်တကူ ထည့်သွင်းထားသည့် ခြေရာခံခြင်းနှင့် စောင့်ကြည့်ခြင်းအကြောင်းနှင့် စနစ်အတွင်းသို့ အမှားအယွင်းများကို ရည်ရွယ်ချက်ရှိရှိ မိတ်ဆက်နည်းတို့ကို ဆွေးနွေးပါမည်။

source: www.habr.com