user
software engineering မှာ scaling ဆိုတာ ဘာကို ပြောတာလဲ။ မတူညီတဲ့ scaling လုပ်တဲ့ ပုံစံတွေကို နားလည်အောင် အကျယ်ချဲ့ ရှင်းပြပေးပါလား
assistant
Amazon website က စက္ကန့်တိုင်းမှာ စျေးဝယ်သူတွေဆီက traffic သောင်းနဲ့ချီ ရှိနေနိုင်တဲ့အတွက် Amazon Web System ဆော့ဝဲကို စက်တလုံးတည်းပေါ်မှာပဲ အလုပ်လုပ်စေပြီး ကျားကန်ထားဖို့ မဖြစ်နိုင်ပါဘူး။ ဒီပြဿနာကို ဖြေရှင်းဖို့ဆိုရင် လိုအပ်တဲ့ resource တွေကို ချဲ့ထုတ် ( scale out ) ရမှာပါ။ software engineering ရှုထောင့်ကကြည့်ရင် ဒါကို scaling လုပ်တယ်လို့ ခေါ်တာဖြစ်တယ်။

scaling အကြောင်းပြောရရင် ယေဘုယျအားဖြင့် ၂ မျိုး ရှိပါတယ်။ ဒီဆော့ဝဲကိုပဲ ပိုအားကောင်းတဲ့ စက်နဲ့ အလုပ်လုပ်စေမလား။ ဒါမှမဟုတ် ​ဒီဆော့ဝဲကိုပဲ အရေအတွက်ပွားပြီး အလုပ်လုပ်စေမလားဆိုတဲ့ နှစ်မျိုးပေါ့။

ပထမတခုကိုတော့ vertical scaling လို့ခေါ်တယ်။ 3D sketch ထုတ်ပေးတဲ့ program လို့ဆိုပါစို့။ ရလဒ်ထွက်ဖို့ အရမ်းစောင့်ရတယ်လို့ user တွေ ကွန်ပလိန်းတက်နေပြီ။ ဒီနေရာမှာ လွယ်တဲ့ အဖြေက program ကို CPU ပိုကြမ်းတဲ့ စက်တခုပေါ် ပြောင်းတင်လိုက်တာပါပဲ။ ဒါမှမဟုတ် ကိုယ့် program က file system ကိုမှီခိုနေရပြီး အဲဒီနေရာက အဓိက နှေးကွေးနေစေတာဆိုရင် IOPS များများရအောင် storage ခပ်ကြီးကြီးထည့်လိုက်ပြီး Scale Up လုပ်နိုင်ပါတယ်။
vertical scaling မှာ အရေးကြီးတဲ့အချက်က လက်ရှိ သုံးနေတဲ့ user တွေကို မထိခိုက်စေဖို့ပါ။ ဒါကြောင့် များသောအားဖြင့် ပြုပြင်ထိန်းသိမ်းရေးကာလတခု ထားပြီး vertical scaling လုပ်ကြပါတယ်။ ဒါပေမယ့် program ကိုပိတ်မချပဲ live migration လုပ်ဖို့ လိုအပ်လာတဲ့အခါ memory snapshot ယူဖို့၊ ဟန်ချက်ညီညီ cluster management coordination လုပ်ဖို့နဲ့ data မဆုံးရှုံးရအောင် storage replication လုပ်ဖို့ အရေးကြီးပါတယ်။
ဒါပေမယ့် ဒီခေတ်မှာ ကုမ္ပဏီတိုင်း cloud environment ကို မှီခိုလာပြီး လိုအပ်တဲ့ software တွေကလည်း အသင့်ရနိုင်တာဖြစ်လို့ အရင်လောက် ခေါင်းစားစရာ သိပ်မရှိတော့ပါဘူး။
vertical scaling က ရုတ်တရက်ကြည့်ရင် ရိုးရှင်းတယ်လို့ ထင်ရပေမယ့် သူ့မှာ ကန့်သတ်ချက်တွေ ရှိပါတယ်။ ပထမတချက်က ကိုယ်စိတ်ကြိုက် အဆုံးမရှိ scale up လုပ်လို့ မရပါဘူး။ ကိုယ့် program က Memory 300 TB နဲ့မှ user တွေ အဆင်ပြေမယ်လို့ ခန့်မှန်းရတယ်။ ဒါပေမယ့် လက်ရှိ hardware နည်းပညာက 250 TB ထိပဲရနိုင်ဦးမယ်ဆိုရင် vertical scaling နဲ့ Scale Up လုပ်ဖို့ မဖြစ်နိုင်တော့ပါဘူး။
နောက်တချက်က ပိုက်ဆံ ကုန်ပါတယ်။ CPU, Memory, Storage ပိုများလာလေလေ ပိုက်ဆံ ပိုပေးရလေလေပါပဲ။ နောက်ဆုံးတချက်ကတော့ ဒီစက်ကြီးပဲရှိတဲ့အတွက် ဒီစက်ကြီး ကျသွားရင် အကုန် ကုန်သွားပါပြီ။ ဒီအချက်ကို SPOF (single point of failure) လို့ခေါ်ပါတယ်။

ဒါတွေကို ဖြေရှင်းဖို့ horizontal scaling ကိုကျင့်သုံးကြတယ်။ ဒီပုံစံမှာ Amazon ရဲ့ Web program ကို ခုနကလို ပိုကောင်းတဲ့စက်ပေါ် မရွှေ့တော့ပါဘူး။ အဲဒီအစား စက်တွေ အများကြီးပေါ်မှာ Amazon Web program အပွားတွေ အများကြီး တင်ပြီး အလုပ်လုပ်စေပါတယ်။ အစကတည်းက ဒီ mindset နဲ့တည်ဆောက်ခဲ့တဲ့ program တွေက UX ကို လုံးဝမထိခိုက်စေပဲ နောက်ထပ်စက်တွေ ထည့်လိုက် လျှော့လိုက် လုပ်နေလို့ရပါတယ်။
ဒါပေမယ့် horizontal scaling ကလည်း ပြီးပြည့်စုံနေတာ မဟုတ်ပါဘူး။ စက်တွေ ဆော့ဝဲတွေက တခုတည်း မဟုတ်တော့ပဲ cluster တခု fleet တခုဖြစ်လာတဲ့အခါ အချင်းချင်း အဆက်အသွယ် မပြတ်ဖို့၊ ဟန်ချက်ညီနေဖို့၊ လုပ်ရမယ့် တာဝန်တွေကို ခွဲဝေပေးနိုင်ဖို့၊ တယောက်တည်း မနိုင်ဝန် မထမ်းနေရဖို့ စသဖြင့် စီမံထားဖို့ လိုအပ်လာပါတယ်။
ကိုယ့် software အလုပ်လုပ်နေရဲ့လားလို့ စောင့်ကြည့်တဲ့အခါ အရင်လို တခုတည်း တနေရာတည်းကို အာရုံစိုက်လိုက်ရုံနဲ့ မပြီးတော့ပါဘူး။ software version အတင်အချ လုပ်ချင်တဲ့အခါမှာလည်း စက်တိုင်းကို ကိုင်တွယ်ဖို့ လိုအပ်လာတယ်။ နောက်တချက်ကတော့ software တခုအလုပ်လုပ်ဖို့အတွက် သီးသန့်စက်တခု လိုချင်မှ လိုပါလိမ့်မယ်။ ဒါကြောင့် horizontal scaling မှာမလိုအပ်ပဲ အပိုဖြုန်းတီးမှု ဖြစ်နိုင်တယ်။ နောက်တခေါက်မှာ ဒီပြဿနာတွေကို containerization နဲ့ container orchestration နည်းပညာတွေက ဘယ်လိုဖြေရှင်းပေးသလဲလို့ ဆက်ပြောကြပါမယ်။
vertical scaling နဲ့ horizontal scaling မှာ တကယ်တမ်း ဘယ်ဟာက အမှန်ရယ်လို့ မရှိပဲ ကိုယ့်လိုအပ်ချက်အပေါ် မူတည်ပါတယ်။ Amazon နဲ့ Netflix တို့က ထောင်ချီတဲ့ program အပွားတွေနဲ့ အလုပ်လုပ်နေပေမယ့် ကျွန်တော်တို့ ချစ်တဲ့ Stack overflow က ပင်မစက်ကြီးတခုထားပြီး အရံတွေနဲ့ အလုပ်လုပ်နေတာဖြစ်တယ်။ ဒါကြောင့် မူတည်တယ်လို့ ပြောတာပါ။ ဒါကတော့ software engineering ရဲ့ scaling ဖြစ်ပါတယ်။