Thuta Learning
Cloud & Deployment
AdvancedDevOps & Toolsbeginner

Scaling နဲ့ Load Balancing

ဒီခန်းပြီးရင် ဘာတတ်သွားမလဲ

  • Scaling နဲ့ Load Balancing concept ကို နားလည်ရှင်းပြနိုင်ရန်
  • Diagram ကို ဖတ်ပြီး architecture ထဲမှာ request/data ဘယ်လိုစီးဆင်းသလဲ ခြေရာခံနိုင်ရန်
  • ကိုယ့် project အတွက် ဘယ်လို ဆုံးဖြတ်သင့်သလဲ ရှင်းပြနိုင်ရန်

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

Approachဘယ်လိုအလုပ်လုပ်လဲ
Vertical scalingရှိပြီးသား server ကို CPU/memory/disk ပိုပေးတာ။ ရိုးရှင်းပေမယ့် hard ceiling နဲ့ single point of failure ရှိတယ်။
Horizontal scalingLoad balancer နောက်မှာ server ပိုထည့်တာ။ Practical ceiling မရှိသလောက်၊ instance တစ်ခု fail သွားလည်း survive တယ် — app က copy အများကြီးအဖြစ် တကယ် run နိုင်မှသာ။

App တိုင်း ဒီအတိုင်း horizontal scale လုပ်လို့ မရပါဘူး

Session data, upload file, ဒါမှမဟုတ် state ကို server တစ်ခုတည်းရဲ့ memory/disk မှာ ထားတဲ့ app ဟာ ပြောင်းလဲမှု မလုပ်ဘဲ horizontal scale မလုပ်နိုင်ပါဘူး — user ရဲ့ next request က ဒီ data ကို တစ်ခါမှ မမြင်ဖူးတဲ့ instance မှာ ကျရောက်နိုင်ပါတယ်။

App က instance ဘယ်ဟာမဆို request ဘယ်ဟာမဆို ကိုင်တွယ်နိုင်ရင် stateless ပါ၊ အရေးကြီးတဲ့ state အားလုံးက app process ရဲ့ အပြင်မှာ ရှိလို့ပါ — database, shared cache, object storage ထဲမှာပေါ့။ Stateless app တွေက အပို မစဉ်းစားရဘဲ scale လုပ်နိုင်ပါတယ်။

Auto-scaling က CPU ဒါမှမဟုတ် queue depth လို signal ကို စောင့်ကြည့်ပြီး instance အရေအတွက်ကို auto ချိန်ညှိပေးပါတယ်။ Hands-on depth အတွက် Kubernetes ရဲ့ scaling-and-hpa နဲ့ AWS Fundamentals ရဲ့ load-balancing-and-autoscaling lesson ကို ကြည့်ပါ။

Horizontal Scaling
Server instance ပိုထည့်ပြီး load balancer တစ်ခုနဲ့ traffic ကို ဖြန့်ဝေတာ။
Vertical Scaling
Server ပိုထည့်မယ့်အစား ရှိပြီးသား server တစ်ခုကို CPU, memory, disk ပိုပေးတာ။
Stateless
အရေးကြီးတဲ့ state က app process ရဲ့ အပြင်ဘက်မှာ ရှိနေလို့ instance ဘယ်ဟာမဆို request ဘယ်ဟာမဆို ကိုင်တွယ်နိုင်တဲ့ app design။
text
VERTICAL VS HORIZONTAL SCALING
------------------------------
VERTICAL VS HORIZONTAL SCALING
---------------------------------

VERTICAL (bigger server)         HORIZONTAL (more servers)
-------------------------        --------------------------
                                        [ LOAD BALANCER ]
    [ SMALL SERVER ]                    /      |       \
          |                            v       v        v
     resize up                    [ app-1 ] [ app-2 ] [ app-3 ]
          v
    [ BIG SERVER ]                 traffic spread across
    single point of failure        instances; one instance
    hard ceiling                   can fail without an outage

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

Round robin က instance တွေကို အစဉ်လိုက် cycle ပတ်ပြီး တစ်ခုစီကို request တန်းတူ ပေးပါတယ်။

Request ငါးခုကို mock instance သုံးခုကနေ run ကြည့်ရင် wraparound ရှင်းရှင်းလင်းလင်း မြင်ရပါတယ် — fourth request က first instance ကို ပြန်ကျရောက်ပါတယ်။

ဒီ simulation က stateless ကို assume လုပ်ထားတယ်

Instance တစ်ခုက user တစ်ယောက်ရဲ့ session ကို memory ထဲမှာ ထားတာ ကပဲ ဖြစ်ခဲ့ရင်၊ next request က တခြား instance ကို ကျရောက်တဲ့အခါ round robin က ဒီ user ရဲ့ experience ကို တိတ်တဆိတ် ချိုးဖျက်လိုက်မှာပါ။

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

javascript
function createRoundRobinBalancer(instances) {
  let next = 0;
  return function pickInstance() {
    const instance = instances[next];
    next = (next + 1) % instances.length;
    return instance;
  };
}

const instances = ["app-1", "app-2", "app-3"];
const pick = createRoundRobinBalancer(instances);

const requests = ["req-A", "req-B", "req-C", "req-D", "req-E"];
for (const req of requests) {
  console.log(`${req} -> ${pick()}`);
}
You should see
req-A -> app-1
req-B -> app-2
req-C -> app-3
req-D -> app-1
req-E -> app-2
(output က locale နှစ်ခုစလုံးအတွက် တူညီပါတယ်)

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

createRoundRobinBalancer ကို weights array လက်ခံအောင် ပြင်ပါ (ဥပမာ app-1 က app-2 နဲ့ app-3 ထက် traffic နှစ်ဆ ရသင့်တယ်)။ Request ငါးခုတည်းကို run ပြီး distribution က weights နဲ့ ကိုက်ညီလား စစ်ပါ။

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

App က session state ကို local memory ထဲမှာ ဆက်ထားပြီး load balancer နောက်မှာ instance ပိုထည့်ခြင်း — login/cart ပျောက်တဲ့ random bug တွေ ဖြစ်စေတယ်။

Vertical scaling ကို permanent fix အဖြစ် ယူဆထားခြင်း၊ stopgap အဖြစ်ပဲ မှတ်သင့်ပါတယ် — ceiling ကို အမြဲရောက်ပြီး၊ များသောအားဖြင့် အဆိုးဆုံးအချိန်မှာ ဖြစ်ပါတယ်။

ဘယ် app က horizontal scale ပိုလွယ်လဲ

App A က user တစ်ယောက်စီရဲ့ session data ကို server memory ထဲမှာ သိမ်းထားတယ်။ App B က session data ကို instance အားလုံး ဖတ်နိုင်တဲ့ shared database/cache ထဲမှာ သိမ်းထားတယ်။ ဘယ် app က horizontal scale ပိုလွယ်လဲ။

MDN — Load balancerCloud & Deployment

ဒီနေရာမှာ လူအများမှားတတ်တယ်

  • App က session state ကို local memory ထဲမှာ ဆက်ထားပြီး load balancer နောက်မှာ instance ပိုထည့်ခြင်း — login/cart ပျောက်တဲ့ random bug တွေ ဖြစ်စေတယ်။
  • Vertical scaling ကို permanent fix အဖြစ် ယူဆထားခြင်း၊ stopgap အဖြစ်ပဲ မှတ်သင့်ပါတယ် — ceiling ကို အမြဲရောက်ပြီး၊ များသောအားဖြင့် အဆိုးဆုံးအချိန်မှာ ဖြစ်ပါတယ်။
  • Localhost မှာ အလုပ်လုပ်တာနဲ့ Production မှာ အလိုအလျောက်အလုပ်လုပ်မယ်လို့ မယူဆပါနှင့် — environment, network, database, security ကွာခြားချက်တွေ ရှိနိုင်ပါတယ်။

လေ့ကျင့်ခန်း

createRoundRobinBalancer ကို weights array လက်ခံအောင် ပြင်ပါ (ဥပမာ app-1 က app-2 နဲ့ app-3 ထက် traffic နှစ်ဆ ရသင့်တယ်)။ Request ငါးခုတည်းကို run ပြီး distribution က weights နဲ့ ကိုက်ညီလား စစ်ပါ။

You'll know it worked when: req-A -> app-1 req-B -> app-2 req-C -> app-3 req-D -> app-1 req-E -> app-2 (output က locale နှစ်ခုစလုံးအတွက် တူညီပါတယ်)

Scaling နဲ့ Load Balancing | Thuta Learning