Scalability — Vertical vs Horizontal

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

Server တစ်ခုတည်းက load ကို မကိုင်တွယ်နိုင်တော့တဲ့အခါ သွားလို့ရတဲ့ လမ်းကြောင်း နှစ်ခုပဲ ရှိပါတယ် — vertical scaling (CPU၊ RAM၊ disk ပိုကောင်းတဲ့ machine ကြီးတစ်ခု ဝယ်ခြင်း) ဒါမှမဟုတ် horizontal scaling (machine အများကြီး ထပ်ထည့်ပြီး load ကို ဝေမျှခြင်း)။ Vertical scaling ကတော့ ရိုးရှင်းပါတယ် — application code ပြောင်းစရာမလိုဘူး၊ machine တွေကြား coordination လိုအပ်ချက်မရှိဘူး၊ ချက်ချင်းအလုပ်လုပ်ပါတယ် — ဒါပေမယ့် ရုပ်ပိုင်းဆိုင်ရာ ceiling တစ်ခုရှိတယ် (ဝယ်လို့ရနိုင်ဆုံး machine အကြီးဆုံးဆိုတာ ရှိတယ်) ပြီးတော့ single point of failure ဖြစ်စေတတ်ပါတယ် — machine တစ်ခုတည်း down သွားရင် system တစ်ခုလုံး ပါသွားနိုင်ပါတယ်။ Horizontal scaling မှာတော့ ဒီလို ceiling မရှိဘူး — theoretically machine ဆက်တိုက်ထည့်နိုင်ပြီး machine တစ်ခုပျောက်သွားရင်တောင် capacity နည်းသွားရုံသာရှိပြီး outage လုံးဝမဖြစ်ပါဘူး။ ကုန်ကျတဲ့ costs ကတော့ complexity ပါ — application က stateless ဖြစ်ရမှာ (server ဘယ်ခုမဆို request ဘယ်ခုမဆို ကိုင်တွယ်နိုင်ရမယ်၊ user ရဲ့ session/data က specific machine တစ်ခုတည်းမှာ tied မဖြစ်ရဘူး) ပြီးတော့ traffic ကို fleet တစ်ခုလုံးအပေါ် ဖြန့်ဝေပေးမယ့် အရာတစ်ခု လိုအပ်ပါတယ်။ Vertical scaling ရဲ့ ceiling နဲ့ single point of failure ဟာ real production scale မှာ လက်ခံလို့မရတော့တဲ့အတွက် modern system အများစုက engineering ပိုလိုအပ်ပေမယ့် horizontal scaling ကို default အနေနဲ့ ရွေးချယ်ကြပါတယ်။

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

လက်ရှိ Tutorial Platform ဟာ upgrade လုပ်ထားတဲ့ server တစ်ခုတည်းနဲ့တောင် အလုပ်လုပ်နိုင်ပြီး၊ ခဏတာအတွက်ကတော့ ဒါက အသက်ဆုံး ရွေးချယ်မှုဖြစ်ပါတယ် — machine ကြီးတစ်ခု ဝယ်တာက app ကို rearchitect လုပ်တာထက် အလုပ်နည်းပါတယ်။ ဒါပေမယ့် ceiling ရှိပါတယ် — learner ပိုများများ တစ်ချိန်တည်း lesson ကြည့်နေတဲ့အခါ machine တစ်ခုတည်းက မလုံလောက်တော့ဘဲ crash တစ်ခု ဖြစ်ရင် platform တစ်ခုလုံး everyone အတွက် offline ဖြစ်သွားနိုင်ပါတယ်။ Platform ရဲ့ real growth path ကတော့ horizontal ဖြစ်ပါတယ် — Next.js app တစ်ခုတည်းကို load balancer (နောက်lesson) နောက်ကွယ်ကနေ server အများကြီးမှာ run ခြင်း — ဒါက app ကို stateless ဦးဆုံးလုပ်ဖို့ လိုအပ်ပြီး ဒီ constraint ကို ဒီ course ရဲ့ နောက်ပိုင်း lesson တိုင်းက assume လုပ်ထားပါတယ်။

Vertical scaling = machine ကြီးအောင်လုပ်ခြင်း; ရိုးရှင်းပြီး code ပြောင်းစရာမလိုပေမယ့် hard ceiling နှင့် single point of failure ရှိတယ်။
Horizontal scaling = machine အများကြီး ထပ်ထည့်ခြင်း; ပိုကျယ်ကျယ်ပြန့်ပြန့် scale လုပ်နိုင်ပြီး individual failure ခံနိုင်ပေမယ့် app stateless ဖြစ်ရမယ်၊ traffic distribution လိုအပ်တယ်။
Modern production system အများစုက vertical scaling ရဲ့ ceiling က real scale မှာ လက်မခံနိုင်တဲ့အတွက် complexity ပိုများပေမယ့် horizontal scaling ကို default ရွေးချယ်ကြတယ်။

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

text

VERTICAL SCALING                        HORIZONTAL SCALING
----------------------                  ----------------------------
      +--------+                          +----+  +----+  +----+
      | BIG    |                          | S1 |  | S2 |  | S3 |
      | SERVER |                          +----+  +----+  +----+
      | (CPU++ |                              \      |      /
      |  RAM++)|                               \     |     /
      +--------+                            +------------------+
                                             |  Load Balancer   |
+ Simple, no code changes                   +------------------+
+ Works immediately                         + No hard ceiling
- Hard ceiling (biggest box                 + One server dies,
  money can buy)                              others keep serving
- Single point of failure                   - Requires stateless app
  (it dies, everything dies)                 - Needs traffic distribution

You should see

Diagram က server တစ်ခုတည်းကို ချဲ့ခြင်းနှင့် server အများစုအား load balancer နောက်ကွယ်တွင် ဖြန့်ကျက်ခြင်း၏ trade-off များကို ယှဉ်ပြသပါတယ်။

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

သင့် app တစ်ခုကို စဉ်းစားပြီး user 10 ဆတိုးလာရင် vertical scaling နဲ့ ဖြေရှင်းလို့ရမလား၊ horizontal scaling လိုအပ်လား ဆုံးဖြတ်ကြည့်ပါ — ဘာကြောင့်လဲ ရှင်းပြပါ။

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

Vertical scaling ကိုပဲ strategy တစ်ခုတည်းအနေနဲ့ cloud provider ပေးနိုင်တဲ့ instance အကြီးဆုံးထိ ဆက်တိုးသုံးပြီး၊ ပြီးရင် production pressure အောက်မှာ ကုန်ကျစရိတ်များတဲ့ rearchitecture တစ်ခုပဲ next step အဖြစ် ကျန်ခဲ့တတ်ပါတယ်။

Server အများကြီး ထပ်ထည့်ပေမယ့် app က session data ကို local memory ထဲ ဆက်သိမ်းထားလို့ user ရဲ့ request တွေ ဟာ data မပါတဲ့ server ပေါ် random ကျရောက်ပြီး logout ဖြစ်တာ ဒါမှမဟုတ် cart ပျောက်တာလို ပြဿနာများ ဖြစ်စေတတ်ပါတယ်။

Wikipedia — Scalability — System Design