CAP Theorem in Practice

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

CAP theorem က node အများအပြားကြား shared data ပေးတဲ့ distributed system တစ်ခုဟာ Consistency (read တိုင်းက အနောက်ဆုံး write ကို ရရှိခြင်း)၊ Availability (request တိုင်းက error မဟုတ်တဲ့ response ရရှိခြင်း)၊ Partition tolerance (node တွေကြား message ပျောက်ဆုံး သို့မဟုတ် နှောင့်နှေးနေတာကြောင့် system ဆက်လက်အလုပ်လုပ်ခြင်း) ဆိုတဲ့ property သုံးခုထဲက အများဆုံး နှစ်ခုကိုသာ တစ်ပြိုင်နက် အာမခံနိုင်တယ်လို့ ဆိုထားပါတယ်။ ရိုးရိုးလွယ်လွယ် နားလည်မှားတတ်တာက engineer တွေဟာ architecture တစ်ခုလုံးအတွက် အမြဲတမ်း အာမခံရမယ့် သုံးခုထဲက နှစ်ခုကို အမြဲသေအေးအေး ရွေးရမယ်လို့ ထင်ကြတာပါ။ ဒါက မှားနေပါတယ် — partition တွေက ပုံမှန် operation နဲ့ယှဉ်ရင် ရှားပါတယ်၊ partition မရှိတဲ့အခါမှာဆိုရင် ကောင်းစွာတည်ဆောက်ထားတဲ့ system တစ်ခုက consistency နဲ့ availability နှစ်ခုစလုံးကို တစ်ပြိုင်နက် ပေးနိုင်ပါတယ် — အများစုအချိန်မှာ trade-off လုပ်ဖို့ မလိုပါဘူး။ တကယ့် ဆုံးဖြတ်ချက်က partition ဖြစ်နေချိန်မှာသာ အရေးပါလာပါတယ် — network partition တွေဟာ ဒီဇိုင်းနဲ့ ရှောင်လွှဲလို့မရတဲ့ ရုပ်ပိုင်းဆိုင်ရာ အမှန်တရားဖြစ်တာကြောင့် (cable ပြတ်တာ၊ router ပျက်တာ၊ region တစ်ခု connectivity ပျောက်တာ) partition ရဲ့ minority ဘက်က node တွေဟာ majority ဘက်နဲ့ sync ဖြစ်နေမှန်း အတည်ပြုမရတဲ့အခါ ဘာလုပ်မလဲဆုံးဖြတ်ရပါတယ်။ Confident မဖြစ်တဲ့ inconsistent request တွေကို ဖြေဆိုဖို့ ငြင်းဆန်မယ် (consistency ရွေးပြီး ခဏတာ unavailable ဖြစ်မယ်) သို့မဟုတ် လက်ရှိရှိသမျှ data နဲ့ ဖြေဆိုမယ် (availability ရွေးပြီး inconsistency အန္တရာယ်ခံမယ်)။ Production system အများစုက ဒီကျဉ်းမြောင်းတဲ့ partition-triggered window မှာသာ 'CP' ဒါမှမဟုတ် 'AP' ဖြစ်ကြပါတယ်။

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

Tutorial Platform ဟာ user-progress database ကို region သုံးခုမှာ run ထားပြီး ကမ္ဘာတစ်ဝှမ်း read မြန်ဆန်အောင် လုပ်ထားပါတယ်။ တစ်နေ့မှာ US နဲ့ Asia region ကြား network link တစ်ခု ပြတ်တောက်သွားပါတယ် — partition အစစ်ပါ။ Engineering team က ကြိုတင်ဆုံးဖြတ်ထားပြီးသားပါ - 'ဒီ quiz ကို student ဒီဟာအောင်ပြီးပြီလား' ဆိုတဲ့ data အတွက် availability (AP) ကို ရွေးထားပါတယ် — Asia မှာရှိတဲ့ student တစ်ဦးဟာ သူ့ progress က US replica ပြသနေတာနဲ့ ခဏတာ မကိုက်ညီပေမယ့် ဆက်သင်ယူနိုင်ပြီး link ပြန်ချိတ်ဆက်တဲ့အခါ reconcile ဖြစ်သွားပါလိမ့်မယ်။ ဒါပေမဲ့ 'ဒီ purchase ကို ငွေကောက်ပြီးပြီလား' ဆိုတဲ့ data အတွက်တော့ consistency (CP) ကို ရွေးထားပါတယ် — partition ဖြစ်နေချိန်မှာ isolated ဖြစ်နေတဲ့ region က double-charge ဒါမှမဟုတ် ငွေမပေးရသေးဘဲ access ပေးမိမှာကို စွန့်စားမည့်အစား purchase အသစ်တွေကို အတည်မပြုဘဲ ဒီ region မှာ checkout ခဏတာ unavailable ဖြစ်ခြင်းကို လက်ခံပါတယ်။

CAP theorem က Consistency နဲ့ Availability အကြား ရွေးချယ်ခိုင်းတာကို network partition အစစ်အမှန်ဖြစ်နေတဲ့အချိန်မှာသာ လုပ်ပါတယ်၊ အမြဲတမ်းမဟုတ်ပါဘူး။
Partition tolerance ဆိုတာ ရွေးချယ်စရာမဟုတ်ပါဘူး — network တွေက အမှန်တကယ် ပျက်စီးတတ်တာမို့ node တွေ isolated ဖြစ်နေချိန်မှာ ဘာလုပ်မလဲဆိုတာက အဓိပ္ပာယ်ရှိတဲ့ ရွေးချယ်မှုဖြစ်ပါတယ် — ငြင်းဆိုမယ် (CP) ဒါမှမဟုတ် ဘာဖြစ်ဖြစ် ဝန်ဆောင်မယ် (AP)။
Platform တစ်ခုတည်းအတွင်းမှာပဲ data အမျိုးအစားတစ်ခုအတွက် CP ဖြစ်ပြီး နောက်တစ်ခုအတွက် AP ဖြစ်နိုင်ပါတယ်။

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

text

NORMAL OPERATION (no partition):
  [Node A] <----sync----> [Node B] <----sync----> [Node C]
  Both Consistency AND Availability hold. No trade-off needed.

NETWORK PARTITION occurs:
  [Node A] <----sync----> [Node B]   X   [Node C]
                                     ^
                          link down, A/B cannot reach C

  Minority side (Node C) must now choose:

  CP CHOICE (Consistency over Availability):
    Client -> Node C: write/read request
    Node C: "I can't confirm I'm in sync with A/B. REJECTING."
    Result: Node C returns an error. Correctness preserved, but C is unavailable.

  AP CHOICE (Availability over Consistency):
    Client -> Node C: write/read request
    Node C: "I'll answer with what I have."
    Result: Node C serves the request. Available, but may diverge from A/B
            until the partition heals and state is reconciled.

You should see

Diagram က CAP trade-off ဟာ ပုံမှန် operation အချိန်မှာ မမြင်ရဘဲ network split အစစ်တစ်ခုရဲ့ minority ဘက်မှာသာ ငြင်းဆိုပြီး correctness ကို ထိန်းမယ် (CP) ဒါမှမဟုတ် ဖြေဆိုပြီး availability ကို ထိန်းမယ် (AP) ဆိုတဲ့ ရွေးချယ်မှုအစစ်ကို ဖြစ်ပေါ်စေတာကို ပြသထားပါတယ်။

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

Data center နှစ်ခုကြားမှာ ခွဲထားတဲ့ e-commerce checkout system တစ်ခုအတွက် partition scenario တစ်ခု စဉ်းစားပါ။ checkout လုပ်နေစဉ် inventory-count စစ်ဆေးမှုကို partition ဖြစ်နေချိန်မှာ CP လား AP လား ဖြစ်သင့်လဲ ဆုံးဖြတ်ပြီး မှားယွင်းစွာ ရွေးချယ်မိရင် ဖြစ်လာနိုင်တဲ့ အန္တရာယ်ကို တိကျစွာ ရှင်းပြပါ။

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

CAP ကို data အားလုံးအတွက် တညီတညွတ်တည်း သက်ဆိုင်တဲ့ architecture label အမြဲတမ်း ('ကျွန်တော်တို့က AP system') အဖြစ် ယူဆတာ — system အစစ်တွေက CP/AP ရွေးချယ်မှုကို operation တစ်ခုချင်း ဒါမှမဟုတ် data အမျိုးအစားတစ်ခုချင်းစီအလိုက် ဆုံးဖြတ်ကြပါတယ်၊ global rule တစ်ခုတည်းအနေနဲ့ မဟုတ်ပါဘူး။

'သတိထားခြင်း' သို့မဟုတ် database ကောင်းကောင်းသုံးခြင်းနဲ့ trade-off ကို ရှောင်လွှဲနိုင်တယ်လို့ ထင်ယူတာ — distributed system အစစ်တစ်ခုမှာ partition tolerance ဟာ ရွေးချယ်စရာမဟုတ်ပါဘူး၊ ဒါကြောင့် partition အတွင်း C-vs-A ရွေးချယ်မှုကို ရှောင်လို့မရပါဘူး၊ ဘယ်အချိန်ဆုံးဖြတ်မလဲဆိုတာသာ သင့်လက်ထဲမှာ ရှိပါတယ်။

Wikipedia — CAP theorem — System Design