နားလည်ထားရမယ့် အချက်
| Approach | ဘယ်လိုအလုပ်လုပ်လဲ |
|---|---|
| Vertical scaling | ရှိပြီးသား server ကို CPU/memory/disk ပိုပေးတာ။ ရိုးရှင်းပေမယ့် hard ceiling နဲ့ single point of failure ရှိတယ်။ |
| Horizontal scaling | Load 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။
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 ကို တိတ်တဆိတ် ချိုးဖျက်လိုက်မှာပါ။
အတူတူ စမ်းရေးကြည့်မယ်
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()}`);
}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 ပိုလွယ်လဲ
MDN — Load balancer — Cloud & Deployment