အခန်း ၁၃ :: Backend Infrastructure Design

Infra လို့ ပြောလိုက်တာနဲ့ ဦးစွာ ကျွန်တော် မေးနေကျ စကားက scalability ဖြစ်လား မဖြစ်ဘူးလား ဆိုသည့် မေးခွန်းပါပဲ။ Junior Developer တွေဟာ scalability ဆိုတာ ဘာမှန်း မသိတော့ ရေးထားသည့် code တွေဟာလည်း scal လုပ်လို့မရသည့် ပြဿနာတွေ ဖြစ်တတ်တယ်။ Senior တွေဟာလည်း ရှင်းပြဖို့ အချိန်မရှိသည့် အခါမှာ work done ဖြစ်သွားအောင် timleine မှီသွားအောင် junior တွေကို ရေးခိုင်းသည့် အခါမှာတော့ နောက်ပိုင်း scalability issue တက်လာပါတယ်။

Scalability

Scalability လို့ ဆိုလိုတာနဲ့ Horizontal လား Vertical လား ဆိုတာ ကို စပြီး မေးရတာပဲ။ Horizontal scaling သွားမှာလား vertical scaling သွားမှာလား ?

Vertical Scaling

Vertical Scaling ဆိုတာကတော့ မြင်အောင် ပြောရရင် ဒေါင်လိုက်တက်သွားတာပေါ့။ Memory 4GB ကနေ Memory 8GB ကို တိုးလိုက် သလိုမျိုးပေါ့။ Vertical Scaling က အမြန်ဆုံး performance ကို မြှင့်တင်သည့် အခါမှာ အသုံးဝင်ပါတယ်။ Memory မလောက်လို့ Memeory တိုးလိုက်တာ။ CPU usages များနေလို့ တိုးလိုက်တာ။

Vertical Scaling

Vertical Scaling က ကုန်ကျစရိတ် များပါတယ်။ တင်ပြီးသွားရင်လည်း ပြန်လျော့ဖို့ ခက်ပါတယ်။ promotion ကာလမှာ လူသုံးများလာလို့ ၁ လ $20 server ကနေ ၁ လ $80 server ကို ပြောင်းလိုက်တယ်။ promotion လည်းပြီးသွားကော လူသုံးနည်းသည့် အခါမှာတော့ ပြန်ပြီး $20 ကို ပြောင်းဖို့ သိပ်မလွယ်ပါဘူး။

Horizontal Scaling

Horizontal Scaling က တော့ လူသုံးများသည့် Scaling တစ်ခုပါပဲ။ Server အသေးတွေ အများကြီးကို Load Balancer ခံပြီး အသုံးပြုခြင်းပါ။ Horizontal Scaling က Vertical Scaling ထက် အတိုးအလျော့ လုပ်လို့ရပါတယ်။ ဥပမာ Server ရဲ့ Memory ကို 4GB ကနေ 8GB ပြောင်းဖို့ system ကို shutdown လုပ်ပြီးမှ လုပ်လို့ရပါလိမ့်မယ်။ Horizontal Scaling မှာတော့ Server တစ်လုံး ထပ်ဖြည့်လိုက်ရုံပါပဲ။ မလိုအပ်တော့ရင် ပြန်ဖြုတ်လိုက်လို့ရပါတယ်။

Horizontal Scaling

Horizontal Scaling မှာလည်း ပြဿနာတွေ ရှိပါတယ်။ Database ကို vertical မှာလို တနေရာတည်းမှာ ထား လို့ မရတော့ပဲ သီးသန့် ခွဲထုတ်ရပါတယ်။ File Storage ကိုလည်း ဆွဲထုတ်ဖို့ လိုအပ်ပါတယ်။ ခွဲမထုတ်ပဲ server တစ်ခုတည်းမှာထားလိုက်ရင် Server 1 က file ကို server 2 မှာ လာပြပေးမှာ မဟုတ်ပါဘူး။

www.abc.xyz/file1.png လို့ ခေါ်လိုက်ရင် Load Balancer ကနေ server 1 ကို ရောက်လာခဲ့လို့ file ရှိသည့် အခါမှာ ပြပေးပေမယ့် server 2 ကို ရောက်သည့် အခါမှာ file မရှိသည့် အခါမှာ ဖော်ပြလို့ မရတော့ပါဘူး။

Load Balancer

Load Balancer ကတော့ Server တွေ တစ်ခုထက် မက ရှိသည့် အခါမှာ Public IP တစ်ခုတည်းကနေ ဘယ် server ကို သွားရမလဲ ဆိုတာကို handling လုပ်ပေးပါတယ်။ လူသုံးများတာကတော့ Round Robin Algorithm နဲ့ Least connections ပါ။

Round Robin ဆိုတာကတော့ အလှည့်ကျ သွားသည့် ပုံစံပါ။ request ကို server တစ်ခုပြီး တစ်ခု ပေါင်းပြီး ခေါ်ပေးသည့် ပုံစံပါ။

Round Robin

Least connections ကတော့ အနည်းဆုံး request ရှိသည့် server ကို ပို့ပေးတာပါ။ ဥပမာ

Least Connection 1

ပထမဆုံး server ၂ ခု မှာ load အပြည့် ရှိတာကနေ 1 နှင့် 3 connection ကို မရှိတော့ဘူး ဆိုပါဆို့။ အဲဒီ အခါမှာ 2 ရဲ့ request တွေက နောက် အခါမှာ server ပြောင်းသွားပါတယ်။

Least Connection 2

Request တွေက server ရဲ့ load ပေါ်မှာ မူတည်ပြီး ပြောင်းလဲ ပေးတာပါ။ ဒါကြောင့် load balancer ကို အသုံးပြုသည့် အခါမှာ request တွေ ပေါ်မှာ မူတည်ပြီး server အတိုး အချဲ့ လွယ်လင့် တကူ လုပ်လို့ရပါတယ်။

Storage

Horizontal Scaling လုပ်သည့် အခါမှာ နောက်ထပ် ပြဿနာ တစ်ခုကတော့ File သိမ်းသည့် ပြဿနာပါပဲ။ Upload လုပ်လိုက်သည့် file ကို ပြန်ပြဖို့ Server တစ်ခုထဲမှာ သိမ်းထားလို့ မရပဲ သီးသန့် ခွဲထုတ်ရပါတယ်။

Storage

ပုံမှန် အားဖြင့် Amazon S3 , Digital Ocean Space တို့ကို အသုံးပြုပါတယ်။ Cloud File Storage server တွေဟာ စျေးသက်သာသလို server အကုန်လုံးက file တွေကို API ကနေ တဆင့် သိမ်းဆည်းနိုင်ပါတယ်။

Database (Read/Write)

File Storage လိုပဲ database မှာ လည်း တစ်ခုခြင်းဆီမှာ ထားလို့ မရတော့ပါဘူး။ ဒါကြောင့် database ကိုလည်း သီးသန့် ခွဲထုတ်မှသာ အဆင်ပြေပါတယ်။

Database

Database ကို ခွဲထုတ်လိုက်ခြင်းအားဖြင့် server တစ်ခုခြင်းဆီမှာ web server ရဲ့ request တွေပဲ handling လုပ်စရာလိုပါတော့တယ်။ Database ကို load ပေါ်မှာ မူတည်ပြီး vertical scaling တည်ဆောက်လို့ရပါတယ်။

Database Read And Write

ဒီထက် ပိုကောင်းတာကတော့ Write Server နှင့် Read Server တွေ ခွဲထုတ်လိုက်ခြင်းအားဖြင့် performance ကို ပိုကောင်းစေပါတယ်။ ဥပမာ Admin Panel ကနေ file ထုတ်နေသည့် အချိန်မှာ အဓိက system ကတော့ performance မကျသွားအောင်ပါ။ Admin Panel အတွက် read server တစ်ခုကို သီးသန့် ခွဲထုတ်ပြီး အသုံးပြုကြပါတယ်။

Admin သီးသန့်ခွဲထုတ်ခြင်း

Queue Server

System တွေထဲက data တွေ များလာသည့် အခါမှာ ချက်ချင်း database ထဲကို write ဖို့ မလိုသည့် အခါတွေမှာ queue service တွေကို အသုံးပြုနိုင်ပါတယ်။ ဥပမာ Email ပို့ခြင်း ၊ push notification ပို့ ခြင်းတို့လိုပေါ့။ တစ်ခါတစ်လေ database ကနေ တိုက်ရိုက် export ထုတ်သည့် အခါမှာ လက်ရှိ page က အချိန်အကြာကြီး load ပြီးအောင် စောင့်နေရပါတယ်။ အဲလိုမျိုး ကိစ္စတွေမှာ နောက်ကွယ်ကနေ queue server ကနေ တဆင့် process လုပ်ပြီး email ပို့ပေးခြင်းအားဖြင့် system ကို ပိုပြီး တည်ငြိမ်စေပါတယ်။ Video Encoding တွေလုပ်သည့် အခါမှာ နာရီ နဲ့ ကြာအောင် စောင့်ရတာတွေ ရှိပါတယ်။ Queue Service မပါသည့် အခါမှာ video encoding ကို user တွေ အများကြီးက request လုပ်သည့် အခါမှာ usages တွေ တက်လာပြီး မနိုင်တော့တာတွေ ရှိပါတယ်။ ဒါကြောင့် system design ပေါ်မှာ မူတည်ပြီး queue server ထည့်သွင်း တည်ဆောက်သင့် မသင့် စဥ်းစားရပါတယ်။

Queue Server

Queue အတွက် Redis , Beanstalk အပြင် အခြား နှစ်သက်ရာ service ကို အသုံးပြုနိုင်ပါတယ်။ သတိထားရမှာက redis, beanstalk တို့က data ကို memory ပေါ်မှာ သိမ်းထားတာ ဖြစ်လို့ system restart ချလိုက်ရင် data တွေ ပျောက်သွားနိုင်ပါတယ်။

Cache Server

Developer တစ်ယောက် အနေနဲ့ Cache ကို မဖြစ်မနေ သိထားဖို့လိုတယ်။ Cache ဆိုတာကတော့ တူညီသည့် Process တစ်ခုကို နောက်ထပ် ထပ်လုပ်ဖို့ မလိုပဲ data ကို သိမ်းဆည်းထားပေးတာပါ။

ဥပမာ

SELECT * FROM users where id = 5;

ဆိုရင် user id 5 ရဲ့ data မပြောင်းမချင်း တူညီသည့် data ပဲ ထွက်လာမှာပါ။ ခဏခဏ မလိုအပ်ပဲ SQL database မှာ သွားပြီး query မလုပ်အောင် cache ခံထားဖို့ လိုပါတယ်။ cache အတွက် Memcached , Redis စသည့် server တွေ ရှိပါတယ်။ ကိုယ်ရေးမည့် programming နဲ့ အဆင်ပြေမယ့် Cache server ကို အသုံးပြုနိုင်ပါတယ်။

Laravel မှာ ဆိုရင်တော့

$value = Cache::remember('users_5', $seconds, function () {
    return User::where("id",5)->first();
});

users_5 ဆိုသည့် cache မရှိတော့မှ database ထဲက query ဆွဲပြီး တစ်ခါတည်း cache ထဲမှာ သိမ်းသွားပါတယ်။

CDN

CDN ဆိုတာ content delivery network ပါ။ ကျွန်တော်တို့တွေ Youtube ကြည့်သည့် အခါမှာ မြန်ပေမယ့် အချို့ video website တွေမှာက နှေးနေတယ် လို့ ခံစားရပါလိမ့်မယ်။ ကိုယ်ပိုင် server နဲ့ video host လုပ်ထားသည့် အခါမှာ တက်လာဖို့က 10 seconds လောက် ကြာပေမယ့် Youtube မှာ 3 seconds လောက်နဲ့ တက်လာတယ်။ ဘာဖြစ်လို့လည်း ဆိုတော့ ကိုယ်ပိုင် server တွေမှာ CDN မသုံးထားကြပါဘူး။ နောက်ပြီး server host ကို ကိုယ်သုံးသည့် နိုင်ငံနဲ့ ဝေးသည့် နေရာမှာထားတတ်လို့ပါ။

ဥပမာ US မှာ server စျေးသက်သာသည့် အတွက် server location ကို US ရွေးထားတယ်။ ပြည်တွင်း မြန်မာ နိုင်ငံက သူတွေက US server ကနေ data တွေ ပို့သည့် အခါမှာ အတော်လေး ကို စောင့်ရပါလိမ့်မယ်။ US server အစား စင်္ကာပူ server ဆို ပိုမြန်တာပေါ့။ ဒါပေမယ့် US က သုံးသည့် သူတွေ အတွက် နှေးသွားပြန်ကော။

Cloudflare မှာ ပုံ အသုံးပြုထားပါသည်

CDN ဟာ static content တွေကို ကမ္ဘာပေါ်က နိုင်ငံ အလိုက် server တွေ မှာ ခွဲထားလိုက်ခြင်းပါပဲ။ ဥပမာ US server က file ကို Bangkok , London , Tokyo စသည့် မြို့တွေ ထဲမှာ clone လုပ်ပြီး သိမ်းထားလိုက်ပါတယ်။ မြန်မာ နိုင်ငံက ဆို ရင် အနီး ဆုံး Bangkok ကို ရောက်သွားပါမယ်။ Korea က သုံးရင် အနီးဆုံး Tokyo server ဆီကနေ data တွေ ရပါလိမ့်မယ်။ Server location နဲ့ အသုံးပြုသူ location နီး စမ်းသွားသည့် အတွက်ကြောင့် load တက်လာတာ မြန်လာပါလိမ့်မယ်။

Microservices

System တွေကြီးလာသည့် အခါမှာ database က record တွေလည်း များလာပါတယ်။ Monolith system မှာ services တွေ အကုန်လုံးက တစုတစည်းထဲ ဖြစ်နေတတ်သလို database ဟာလည်း တစ်ခုတည်းမှာ ရှိနေတတ်ပါတယ်။ Transac†ions ၅ သန်းလောက် ရှိလာသည့် အခါမှာ transaction ထဲမှာ row တစ်ကြောင်းထည့်လိုက်သည့် အခါမှာ အခြား system တွေ ပါ လေး သွားတာ မျိုး ဖြစ်တတ်ပါတယ်။ User က အချို့ အပိုင်း သေးသေးလေး ပြင်သည့် အခါမှာ System တစ်ခုလုံးပြန်ပြီး deploy လုပ်ရပါတယ်။ Monolith ဟာ ကောင်းတာတွေလည်း ရှိသလို အဆင်မပြေတာတွေလည်း ရှိတတ်ပါတယ်။

တချို့ system တွေဟာ ကြီးလာသည့် အခါ team ကလည်း ကြီးလာသည့် အခါမှာတော့ Microservices ကို ပြောင်းကြပါတယ်။ Microservices ကို အကြမ်းအား ဖြင့် အောက်မှာ ဖော်ပြပါ ပုံအတိုင်းပါပဲ။

Example Blog System with Microservices

Microservices မှာ ကိုယ်ပိုင် services တွေ အတွက် ကိုယ်ပိုင် database ကို အသုံးပြုပြီး အသေးလေးတွေ ခွဲထုတ်ထားပါတယ်။ Users system ပြင်ဆင်ထားတာတွေကို deploy လုပ်သည့်အခါမှာ အခြား services တွေ သွားမထိတော့ပါဘူး။ User service ကို java နဲ့ ရေးပြီး post service ကို node.js ၊ comment service ကို PHP နဲ့ ရေးလည်း ရပါတယ်။

Cloud Server

Cloud Server ဟာ လက်ရှိ သမာရိုးကျ server တွေလို မဟုတ်ပဲ scaling ကို လိုသလို ချက်ခြင်းဆောင်ရွက်နိုင်တယ်။ Vertical scaling ပဲ ဖြစ်ဖြစ် horizontal scaling ပဲ ဖြစ်ဖြစ် မြန်မြန်ဆန်ဆန် ဆောင်ရွက်နိုင်တယ်။ Database ကိုလည်း performance ကောင်းအောင် ချက်ချင်းပြင်ဆင် ပြောင်းလဲနိုင်တယ်။ အခုခေတ်မှာ လူတိုင်းနီးပါး cloud server တွေ အသုံးပြုနေကြပါပြီ။ AWS ကို မတတ်နိုင်ရင်တောင် Digital Ocean ပေါ်မှာ စမ်းကြည့်လို့ရပါတယ်။

Amazon Web Service လို့ လူသိများသည့် AWS ဟာ အခုခေတ် နေရာတော်တော်များများမှာ အသုံးပြုနေပါပြီ။ AWS အတွက် certificate ကို web developer တွေ အနေနဲ့ ဖြေထားသင့်တယ်။ အလွတ်ကျက်သည့် အစား တကယ့်ကို lab နဲ့ လေ့လာပြီး ဖြေထားဖို့ လိုအပ်တယ်။ AWS က အရေးပါသည့် နေရာကို ရောက်နေပါပြီ။ System တော်တော်များများက AWS ပေါ်မှာ run နေကြပါတယ်။ AWS ကို မသိပဲ ကိုယ့်လက်ထဲရောက်လာလို့ manage လုပ်မယ် ဆိုရင် အန္တာရယ် အလွန်များပါတယ်။ မှတ်မှတ်ရရ AWS ကို ကျွန်တော် ပထမဆုံး သုံးသင့် အချိန်က EBS ကို ခွဲပြီး မသုံးတတ်သလို configuration လည်း မလုပ်တတ်ပါဘူး။ ရုံးမှာ AWS သုံးကြမယ် AWS ပေါ်တင်ဆိုပြီး ဒီအတိုင်း တင်လိုက်ကြတာ။ Services တွေ down ပြီး internet က မထွက်သည့် အချိန်မှာ instant ကို terminate လုပ်မိလိုက်တယ်။ AWS အကြောင်းမသိတော့ terminate က ecovery လုပ်လို့ မရတာ မသိလိုက်ဘူး။ Production server ဖြစ်လို့ နောက်ဆုံး data တွေ အကုန်ပျက်သွားတာ ဖြစ်ခဲ့ဖူးတယ်။ AWS ပေါ်ကာစ မို့ အချို့ စာတွေကို မလေ့လာပဲ ပုံမှန် linux server လိုပဲ ထင်ပြီး လုပ်ခဲ့မိတာ ကြောင့် အတော်ကို နောင်တရ မိတယ်။ နောက်ပြီး database server ကို ခွဲပြီး သုံးရမယ်ဆိုတာကို မသိခဲ့တာကြောင့်လည်း ပါတယ်။

AWS မှာ အခြား platform တွေမှာ မရှိသည့် feature တွေ အများကြီး ရှိသလို အမြဲလို update ဖြစ်နေတယ်။ အခုအချိန်မှာ AWS အပြင် Google Cloud , Microsoft Azure တို့ဟာလည်း နေရာတစ်ခု ရလာပါပြီ။ AWS ကို အသုံးပြုမယ်ဆိုရင် certificate ရှိထားရင်တော့ အများကြီး ပိုပြီးသင့်တော်ပါလိမ့်မယ်။ ဒါကြောင့် AWS certificate တွေ အချိန်ရရင် လေ့လာပြီး ဖြေထားသင့်ပါတယ်။

Developer Intern