Horizontal နဲ့ Vertical scaling

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

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

ပထမတခုကိုတော့ vertical scaling လို့ခေါ်တယ်။ 3D sketch ထုတ်ပေးတဲ့ program လို့ဆိုပါစို့။ ရလဒ်ထွက်ဖို့ အရမ်းစောင့်ရတယ်လို့ user တွေ ကွန်ပလိန်းတက်နေပြီ။ ဒီနေရာမှာ လွယ်တဲ့အဖြေက program ကို CPU ပိုကြမ်းတဲ့ စက်တခုပေါ် ပြောင်းတင်လိုက်တာပါပဲ။ ဒါမှမဟုတ် ကိုယ့် program က file system ကိုမှီခိုနေရပြီး အဲဒီနေရာက အဓိက နှေးကွေးနေစေတဲ့ bottleneck ဖြစ်နေတာဆိုရင် IOPS များများရအောင် storage ခပ်ကြီးကြီး ထည့်လိုက်နိုင်ပါတယ်။

vertical scaling မှာတခုသတိထားဖို့ရှိတာက လက်ရှိသုံးနေတဲ့ user တွေကို မထိခိုက်စေဖို့ပါ။ ဒါကြောင့် များသောအားဖြင့် ပြုပြင်ထိန်းသိမ်းရေးကာလတခု ထားပြီး vertical scaling လုပ်ကြပါတယ်။ ဒါကြောင့် program ကိုပိတ်မချပဲ live migration လုပ်ဖို့လိုအပ်လာတဲ့အခါ memory snapshot ယူဖို့၊ cluster management coordination လုပ်ဖို့နဲ့ data မဆုံးရှုံးရအောင် storage replication လုပ်ဖို့အရေးကြီးပါတယ်။ ဒါပေမယ့် ဒီခေတ်မှာ ကုမ္ပဏီတိုင်း cloud environment ကိုမှီခိုလာပြီး လိုအပ်တဲ့ scaling software တွေကလည်း အသင့်ရနိုင်တာဖြစ်လို့ အရင်လောက် ခေါင်းစားစရာ သိပ်မရှိတော့ပါဘူး။

vertical scaling ကရုတ်တရက်ကြည့်ရင် ရိုးရှင်းတယ် ထင်ရပေမယ့် သူ့မှာ ကန့်သတ်ချက်တွေ ရှိပါတယ်။ ပထမတချက်က ကိုယ်စိတ်ကြိုက် အဆုံးမရှိ scale up လုပ်လို့ မရပါဘူး။ ကိုယ့် program က Memory 300 TB နဲ့မှ user တွေ အဆင်ပြေမယ်လို့ ယူဆရတယ် ဆိုပါတော့။ ဒါပေမယ့် လက်ရှိ hardware နည်းပညာက 250 TB ထိပဲရနိုင်ဦးမယ်ဆိုရင် vertical scaling နဲ့မဖြစ်နိုင်တော့ပါဘူး။ နောက်တချက်က ပိုက်ဆံကုန်ပါတယ်။ CPU, Memory, Storage ပိုများလာလေလေ ပိုက်ဆံ ပိုပေးရလေလေပါပဲ။ နောက်ဆုံးတချက်ကတော့ ဒီစက်ကြီးပဲရှိတဲ့အတွက် ဒီစက်ကြီး ကျသွားရင် အကုန်ကုန်သွားပါပြီ။ ဒါကို SPOF (single point of failure) လို့ခေါ်ပါတယ်။

ဒါတွေကို ဖြေရှင်းဖို့ horizontal scaling ကိုသုံးကြတယ်။ ဒီပုံစံမှာ Amazon ရဲ့ Web program ကို ခုနကလို ပိုကောင်းတဲ့စက်ပေါ် မရွှေ့တော့ပါဘူး။ အဲဒီအစား စက်တွေ အများကြီးပေါ်မှာ Amazon Web program အပွားတွေ အများကြီး တင်ပြီး အလုပ်လုပ်စေပါတယ်။ အစကတည်းက stateless mindset နဲ့တည်ဆောက်ခဲ့တဲ့ program တွေက uptime ကိုလုံးဝမထိခိုက်စေပဲ traffic အပေါ်မူတည်ပြီး နောက်ထပ်စက်တွေ ထည့်လိုက် လျှော့လိုက် လုပ်နေလို့ရပါတယ်။

ဒါပေမယ့် horizontal scaling ကလည်း ပြီးပြည့်စုံနေတာ မဟုတ်ပါဘူး။ စက်တွေ ဆော့ဝဲတွေက တခုတည်း မဟုတ်တော့ပဲ cluster တခု fleet တခုဖြစ်လာတဲ့အခါ အချင်းချင်းကြားမှာ အဆက်အသွယ် မပြတ်ဖို့၊ state ဟန်ချက်ညီနေဖို့၊ လုပ်ရမယ့် တာဝန်တွေကို ခွဲဝေနိုင်ဖို့၊ တယောက်တည်း မနိုင်ဝန်ထမ်းမနေရဖို့ စသဖြင့် စီမံထားဖို့ လိုအပ်လာပါတယ်။ ဒါ့အပြင် ကိုယ့် software အလုပ်လုပ်နေရဲ့လားလို့ စောင့်ကြည့်တဲ့အခါ အရင်လို တခုတည်း တနေရာတည်းကို အာရုံစိုက်လိုက်ရုံနဲ့ မပြီးတော့ပါဘူး။ software version အတင်အချ လုပ်ချင်တဲ့အခါမှာလည်း စက်တိုင်းကို ကိုင်တွယ်ဖို့ လိုအပ်လာတယ်။ နောက်တချက်ကတော့ software တခုအလုပ်လုပ်ဖို့အတွက် သီးသန့်စက်တခု ဆောက်တာက မလိုအပ်တဲ့ overhead တွေရှိတဲ့အတွက် horizontal scaling မှာ resource အပိုဖြုန်းတီးမှု ဖြစ်နိုင်တယ်။ ဒီပြဿနာတွေကိုတော့ containerization နဲ့ container orchestration နည်းပညာတွေက ထိုက်သင့်သလောက် ဖြေရှင်းပေးနိုင်တယ်။