လွယ်လွယ်ပြောရရင် Auto Scaling ဆိုတာ လိုအပ်ချက်အလိုက် server အရေအတွက် အလိုလို တိုး/လျှော့ပေးတဲ့ cloud နည်းပညာပါ။ လူ များလာရင် server များလာတယ်၊ လူ နည်းသွားရင် ပြန်လျှော့တယ် — လူလုပ် ဝင်လုပ်စရာ မလိုဘူး။
မုန့်ဟင်းခါးဆိုင်နဲ့ ဥပမာ ပြောရအောင်။
ကျွန်တော်တို့ ရပ်ကွက်ထဲက မုန့်ဟင်းခါးဆိုင် တွေးကြည့်ပါ။ သာမန်နေ့တွေဆို ဝန်ထမ်း 2 ယောက်နဲ့ လုံလောက်တယ်။ ဒါပေမယ့် တနင်္လာနေ့ မနက် ရုံးသွားချိန် ဆိုရင် လူ 50 ရောက်လာတယ်။ ဆိုင်ရှင်က အဲဒီအချိန်ဆို အပို ဝန်ထမ်း 3 ယောက် ကြိုခေါ်ထားတယ်၊ လူကျသွားရင် ပြန်လွှတ်တယ်။ အဲဒါ Auto Scaling ပဲ — လုပ်ငန်းကို ကြည့်ပြီး လူ (server) အရေအတွက် ချိန်တာ။
အရင်ခေတ်က server ကို ကိုယ်တိုင် ဝယ်ရတယ်။ “နောက်နှစ် လူ များလာမယ် ထင်တယ်” ဆိုပြီး server အကြီးကြီး ဝယ်ထားရတာ — လူ မများတဲ့ လတွေမှာ ပိုက်ဆံ အလကား ကုန်တယ်။ Cloud ခေတ်မှာ ဒီပြဿနာ ပျောက်သွားပြီ။ AWS Auto Scaling, Google Cloud, Azure တို့မှာ စည်းကမ်း ချထားလိုက်ရုံပဲ —
CPU 70% ကျော်လာရင် server အသစ် တစ်လုံး အလိုလို ဖွင့်
CPU 30% အောက် ကျသွားရင် ပို server ကို အလိုလို ပိတ်
မနက် 8 နာရီ လူကျချိန်ဆို ကြိုပြီး server တိုးထား (scheduled scaling)
သတိထားရမှာက Auto Scaling က “ဆေးဖက်” မဟုတ်ဘူး၊ “ကုစားနည်း” ပဲ။ Code ကိုယ်တိုင်က နှေးနေရင် server 100 လုံး တိုးလည်း နှေးနေမှာပဲ — ပိုက်ဆံပဲ ပိုကုန်မယ်။ ဒါကြောင့် အရင် code ကို optimize လုပ်၊ ပြီးမှ scale လုပ်တာ အကောင်းဆုံး အစီအစဉ်။
ပြီးတော့ database လို “ပွားလို့ မရတဲ့” အစိတ်အပိုင်းတွေလည်း ရှိတယ်။ Web server တွေကို 10 လုံး ပွားလို့ ရပေမယ့် database တစ်လုံးတည်းကို 10 လုံး ပွားလို့ မရဘူး — အဲဒီမှာ read replica, caching (Redis) တို့လို တခြားနည်းတွေ လိုတယ်။
ကိုယ်က side project လေး လုပ်နေရင် Auto Scaling ကို အခုချက်ချင်း မလိုဘူး။ ဒါပေမယ့် “လူများလာရင် ဘာလုပ်မလဲ” ဆိုတဲ့ မေးခွန်းကို အဖြေရှိထားတာ ကောင်းတယ်။ Cloud ရဲ့ အကြီးမားဆုံး အားသာချက်က ဒါပဲ — ဆိုင်ရှင်လို တွေးစရာ မလိုဘူး၊ စနစ်က အလိုလို ချိန်ပေးတယ်။ 🙂
