Fault Tolerance နှင့် Redundancy

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

Scale သေးငယ်တဲ့အခါ server crash ဆိုတာ ရှားပါးပြီး သတိထားထိုက်တဲ့ event တစ်ခုပါ။ Server ရာနဲ့ချီ ဒါမှမဟုတ် ထောင်နဲ့ချီရှိတဲ့ scale ရောက်တဲ့အခါတော့ သင်္ချာက ပြောင်းသွားပါတယ် — server တစ်ခုချင်းစီမှာ နေ့စဉ် fail ဖြစ်နိုင်ခြေ အနည်းငယ်ရှိရင်တောင် fleet ကြီးတစ်ခုလုံးမှာ တစ်ခုခုက အချိန်တိုင်းနီးပါး fail ဖြစ်နေပါတယ်။ ဒါက ဒီဇိုင်းပြဿနာတစ်ခုလုံးကို ပြန်လည် framing လုပ်ပေးပါတယ် — failure မဖြစ်ဘူးလို့ ယူဆတဲ့ system တစ်ခု ဒီဇိုင်းမလုပ်နိုင်တော့ပါဘူး၊ failure ဖြစ်နေတဲ့အချိန်မှာတောင် ဆက်အလုပ်လုပ်နိုင်တဲ့ system တစ်ခု ဒီဇိုင်းလုပ်ရပါလိမ့်မယ်။ Redundancy ဟာ အခြေခံ technique ပါ — အရေးကြီးတဲ့ အရာတိုင်းကို instance တစ်ခုတည်းနဲ့ run ခြင်း လုံးဝမလုပ်ပါနဲ့၊ ဒါမှ failure တစ်ခုက capability တစ်ခုလုံးကို မဖယ်ရှားဘဲ capacity ရဲ့ အစိတ်အပိုင်းလေးကိုသာ ဖယ်ရှားမှာပါ။ Failover ဟာ automated အပိုင်းပါ — instance တစ်ခု ကျန်းမာမှုမရှိမှန်း (health check တွေကတစ်ဆင့်) ရှာဖွေပြီး ကျန်းမာတဲ့ instance တွေဆီကို traffic ကို လူတစ်ယောက် တုံ့ပြန်နိုင်တာထက် မြန်မြန် ပြန်ညွှန်းပေးခြင်းပါ။ Circuit breaker pattern က ပိုနက်နဲတဲ့ failure mode တစ်ခုကို ဖြေရှင်းပါတယ် — downstream service တစ်ခု ပြဿနာရှိနေတဲ့အခါ ဒီဟာဆီ call တွေကို ရိုးရိုးရှင်းရှင်း ပြန်ကြိုးစားနေတာက အထောက်အကူ မဖြစ်ပါဘူး — အလွန်အကျွံ overwhelm ဖြစ်နေပြီးသား system အပေါ် load ထပ်ဖြည့်ပေးသလို caller ကိုယ်တိုင်ရဲ့ resource တွေ (thread, connection) ကိုလည်း ဘယ်လိုမှ မအောင်မြင်နိုင်တော့တဲ့ timeout တွေကို စောင့်နေရင်း ချုပ်ကိုင်ထားပါတယ်။ Circuit breaker က မကြာသေးမီက failure rate ကို track လုပ်ပြီး threshold ကျော်တဲ့အခါ 'ဖွင့်' လိုက်ပါတယ် — network call တောင် မကြိုးစားဘဲ call တွေကို ချက်ချင်း fail ဖြစ်စေပါတယ် — downstream service ကို ပြန်ကောင်းလာဖို့ နေရာပေးပြီး အချိန်ကာလအလိုက် trial call ကို ပြန်ပို့ပြီး ပြန်စလို့ ရ၊ မရ စမ်းသပ်ပါတယ်။

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

Tutorial Platform က region များစွာမှာ server ဆယ်ချီ run နေတာကြောင့် server တစ်ခုချင်းစီ fail ဖြစ်တာ တစ်ပတ်တစ်ခါလောက် ဖြစ်တတ်ပါတယ်၊ ဘယ်တော့မှ မဖြစ်တာမဟုတ်ပါဘူး — disk ပြည့်တာ၊ process crash ဖြစ်တာ၊ maintenance အတွက် VM restart ဖြစ်တာမျိုးတွေပါ။ Service တစ်ခုချင်းစီဟာ health check ပါတဲ့ load balancer နောက်မှာ redundant instance အနည်းဆုံး သုံးခုနဲ့ run နေတာကြောင့် instance တစ်ခု fail ဖြစ်သွားရင် စက္ကန့်အနည်းငယ်အတွင်း အလိုအလျောက် ပြန်ညွှန်းပေးပြီး student အများစုက ဘာမှ သတိမမူကြပါဘူး။ Recommendation-service — critical-path မဟုတ်ဘဲ ရှိရင်ကောင်းတဲ့ feature တစ်ခု — က သူ့ကိုယ်ပိုင် load spike အောက်မှာ timeout ဖြစ်လာတဲ့အခါ ဒီဟာကို ခေါ်တဲ့ lesson-service မှာ circuit breaker တစ်ခု ဒီ call ကို wrap လုပ်ထားပါတယ် — failure အနည်းငယ်ဖြစ်ပြီးနောက် recommendation-service ကို 30 second စာ လုံးဝ ခေါ်တာ ရပ်လိုက်ပြီး generic 'popular lessons' fallback ကို အစားထိုးပေးပါတယ်၊ ပြဿနာရှိနေပြီးသား service ကို စောင့်နေရင်း page load တိုင်းကို hang ဖြစ်စေမည့်အစားပါ။

Server အစုအရေအတွက် ကြီးမားတဲ့ scale မှာ component တစ်ခုခုက အချိန်တိုင်းနီးပါး fail ဖြစ်နေတတ်ပါတယ် — system တွေကို failure ကို ရှောင်ရှားနိုင်လိမ့်မယ်လို့ မျှော်လင့်မနေဘဲ ဖြစ်တတ်တယ်လို့ယူဆပြီး ဒီဇိုင်းဆွဲရပါတယ်။
Redundancy ဆိုတာ single point of failure မရှိခြင်းကို ဆိုလိုပြီး failover က unhealthy instance တွေဆီကနေ traffic ကို အလိုအလျောက် ပြန်ညွှန်းပေးပါတယ်။
Circuit breaker က ပြဿနာရှိနေတဲ့ downstream service ကို ပြန်ကြိုးစား ခေါ်နေမည့်အစား ခေါ်ဆိုမှုကို ရပ်တန့်ပြီး မြန်မြန် fail ဖြစ်စေကာ ပြန်လည်ကောင်းမွန်ဖို့ အခွင့်အရေးပေးပါတယ်။

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

text

          failures exceed threshold
   +------------------------------------+
   |                                      v
+--------+                          +--------+
| CLOSED |                          |  OPEN  |
|--------|                          |--------|
| calls  |                          | calls  |
| pass   |                          | fail   |
| through|                          | instantly,
| to the |                          | no network
| service|                          | attempt  |
+--------+                          +--------+
   ^                                      |
   |                                      | cooldown timer expires
   |          trial call succeeds         v
   |    +--------------------------+  +-----------+
   +----|                          |<-|HALF-OPEN  |
        |  trial call fails -------|->| one trial |
        |  (back to OPEN,          |  | call sent |
        |   restart cooldown)      |  | to test   |
        +--------------------------+  +-----------+

You should see

State diagram က circuit breaker ဟာ ပုံမှန်အလုပ်လုပ်ခြင်း (closed) ကနေ failure threshold ကျော်သွားရင် call တိုင်းကို မြန်မြန် fail ဖြစ်စေခြင်း (open) ဆီ ပြောင်းသွားပြီး trial call တစ်ခုတည်းနဲ့ ပြန်လည်ကောင်းမွန်မှုကို သတိထားစမ်းသပ် (half-open) ပြီးမှ အပြည့်အဝ ပြန်ဖွင့်မလား ဒါမှမဟုတ် fail-fast ဆီ ပြန်ကျမလား ဆုံးဖြတ်တာကို ပြသထားပါတယ်။

၅ မိနစ် စမ်းကြည့်

Third-party payment gateway ခေါ်ဆိုမှုကို ကာကွယ်ဖို့ circuit breaker parameter တွေကို ဒီဇိုင်းဆွဲပါ - ဘယ်လောက် time window အတွင်း failure ဘယ်နှစ်ခုရှိရင် open ဖြစ်သင့်လဲ၊ half-open စမ်းသပ်ခင် cooldown ဘယ်လောက်ကြာသင့်လဲ၊ circuit open ဖြစ်နေချိန်မှာ caller က ဘာလုပ်သင့်လဲ (checkout ကို fail လုပ်မလား၊ retry အတွက် queue လုပ်မလား)။

သတိလေးတစ်ချက်

Server level မှာသာ redundancy ထည့်ပြီး အောက်ခြေက shared dependency ကို လွတ်ထားတာ — ဥပမာ redundant app server instance သုံးခုက redundant မဟုတ်တဲ့ database တစ်ခုတည်းကို ညွှန်းနေတာမျိုး — single point of failure က ရွှေ့သွားတာပါပဲ၊ ပျောက်သွားတာ မဟုတ်ပါဘူး။

Circuit breaker ရဲ့ cooldown ကို တိုတိုလွန်းအောင် configure လုပ်တာ — downstream service အမှန်တကယ် ပြန်ကောင်းမလာခင် half-open ကို ပြန်ပြောင်းပြီး ထပ်ခံရတော့ open/closed အကြိမ်ကြိမ် flap ဖြစ်နေမှာဖြစ်ပြီး တကယ့် recovery အချိန်ပေးခြင်း မဖြစ်တော့ပါဘူး။

Wikipedia — Fault tolerance — System Design