Serverless ဆိုတာ

Serverless ဆိုတဲ့ စကားလုံးက နည်းပညာလောကမှာ တဖြည်းဖြည်းနဲ့ လူပြောသူပြောများလာတဲ့ အကြောင်းအရာတစ်ခုပါ။ ပုံမှန်အားဖြင့် Website တစ်ခု သို့မဟုတ် API တစ်ခုအတွက် Server ဆိုတဲ့ အရာက မရှိမဖြစ်လိုအပ်တဲ့ အရာတစ်ခု။ သို့သော် နံမည်ကိုက Serverless လို့ ဆိုလာတဲ့အတွက် ရုတ်တရက် တွေးကြည့်လိုက်မယ်ဆိုရင် server မပါပဲနဲ့ ဘယ်လိုများ အလုပ်လုပ်သတုန်းပေါ့။ Cloud service provider တွေဖြစ်တဲ့ AWS တို့ Google Cloud တို့က အစ "NO SERVERS TO MANAGE" ဆိုပြီး ကြော်ငြာနေကြတာကိုး။ မရင်းနှီးသေးတဲ့ သူတွေအများစု အတွက်ကတော့ အနည်းငယ် ပုစ္ဆာဆန်နေနိုင်ပါတယ်။ ဒီတော့ Serverless ဆိုတာ ဘာများလဲ?

(အကယ်၍များ ဒီနေရာမှာ Website တစ်ခု ဖြစ်လာဖို့ အခြေခံအားဖြင့် ဘာတွေလိုအပ်လည်း ဆိုတာကို မသိသေးဘူးဆိုရင်တော့ "Website တစ်ခု ဖြစ်လာဖို့" ဆိုတဲ့ post ကို အရင်ဖတ်ကြည့်ဖို့ တိုက်တွန်းလိုပါတယ်။)

Serverless ဆိုတာ ဘာလဲ?

တကယ်တော့ Serverless ဆိုတာ ကိုယ့်ရဲ့ web application တစ်ခု အလုပ်လုပ်ဖို့ အတွက် server ကြီး တကယ်မရှိတာမျိုး မဟုတ်ပဲနဲ့ အဲဒီ server ကို ကိုယ်တိုင် setup လုပ်စရာမလို၊ manage လုပ်စရာမလိုပဲ ကိုယ့်အစား cloud service provider က တာဝန်ယူ ဆောင်ရွက်ပေးတဲ့ service တစ်ခုကို ခေါ်တာပါ။ Serverless ရဲ့ အဓိက component ကိုတော့ function လို့ ခေါ်ပါတယ်။

ဒီနေရာမှာ Serverless ကို AWS, Google Cloud, Azure အစရှိတဲ့ နံမည်ကြီး cloud service provider တွေအကုန်လုံးမှာ အသုံးပြုလို့ရပါတယ်။ ဒါပေမယ့် ဒီဆောင်းပါးမှာတော့ AWS ကိုပဲ ဥပမာပေးပြီး ပြောသွားမှာဖြစ်ပါတယ်။

အကြမ်းဖျင်း ဘယ်လို အလုပ်လုပ်လည်းဆိုရင် event တစ်ခု trigger ဖြစ်လာပြီဆိုရင် ဥပမာ - S3 bucket ထဲကို ပုံတစ်ပုံရောက်လာတယ် ဆိုကြပါစို့၊ အဲဒီအချိန်မှာ lambda function က အလုပ်လုပ်ရတော့မှာ ဖြစ်တဲ့အတွက် AWS က code ကို download ချ၊ ကိုယ်သတ်မှတ်ပေးထားတဲ့ setting တွေအတိုင်း container တစ်ခု တည်ဆောက်လိုက်ပြီး အဲဒီ container ထဲမှာ ကိုယ့်ရဲ့ lambda function ကို run ပေးပါတယ်။ process တစ်ခုပြီးသွားလို့ နောက်ထပ် 15 မိနစ် အထိ နောက် event တစ်ခု မရှိတော့ဘူးဆိုရင် အဲဒီ container ကို ဖျက်ပစ် လိုက်မှာပါ။ 20 မိနစ်ကြာမှ နောက် event တစ်ခုရောက်လာရင် ခုနက အဆင့်ကို အစက ပြန်စရတဲ့ သဘောမျိုးပေါ့။ အဲဒါကြောင့် stateless container လို့လည်း ခေါ်ကြပါတယ်။ ဒါဆို တစ်ပြိုင်တည်း event 2 ခု ရောက်လာရင်ကောလို့ တွေးစရာရှိပါတယ်။ အဲဒီအချိန်ကြရင် container 2 ခု တည်ဆောက်ပြီး တပြိုင်တည်း run ပါတယ်။ ကိုယ်ရွေးထားတဲ့ region ပေါ်မူတည်ပြီးတော့ တပြိုင်နက်ထဲ အများဆုံး container ဘယ်နှစ်ခုထိ handle လုပ်နိုင်လည်းဆိုတဲ့ Concurrency Burst Limits ကတော့ ကွဲပြားပါတယ်။ ဘယ်လိုပဲဖြစ်ဖြစ်  scalability အတွက်တော့ အရမ်းကြီး ခေါင်းမခြောက်ရဘူးပေါ့။

ဘယ်နေရာတွေမှာ သုံးလို့ရသလဲ?

ဘယ်နေရာတွေမှာ သုံးလို့ရသလဲ ဆိုတာကို သိဖို့အတွက် lambda function တွေကို ဘယ်လို ပုံစံမျိုးတွေနဲ့ လှမ်းခေါ်လို့ ရသလဲဆိုတာကို သိဖို့လိုပါတယ်။ အဲဒါတွေကတော့ Synchronous (Push), Asynchronous (Event) နဲ့ Stream (Poll-based) တို့ ဖြစ်ပါတယ်။

Synchronous (Push)

ဒါကတော့ တည်ဆောက်ထားတဲ့ REST endpoint တစ်ခုခုကို request ရောက်လာတဲ့ အခါမှာ API Gateway ကနေ  lambda function ကို လှမ်းခေါ်တာပါ။ API endpoint တစ်ခုဖြစ်တဲ့အတွက် response တစ်ခုခုပြန်ရမှာမို့လို့ lambda function ရဲ့ process ပြီးတဲ့အထိ စောင့်ရပါတယ်။ အဲဒါကြောင့် ဒါက Synchronous ပုံစံဖြစ်ပါတယ်။

Asynchronous (Event)

ဒါကတော့ lambda function ရဲ့ process လုပ်တာကို စောင့်ဖို့မလိုပဲ လှမ်းခေါ်ရုံသက်သက်လောက်ပဲ လိုအပ်တဲ့အခြေအနေမျိုးပါ။ ဥပမာ .. အပေါ်မှာပြောခဲ့သလို S3 bucket ထဲကို ပုံတစ်ပုံရောက်လာမယ်။ ရောက်လာတဲ့ပုံကို thumbnail အဖြစ် resize လုပ်ဖို့အတွက် အဲဒီ bucket ကနေ lambda function ကိုလှမ်းခေါ်မယ်။ အဲဒီအတွက် resize လုပ်ပြီးတဲ့အချိန်အထိ စောင့်နေဖို့ မလိုအပ်ပါဘူး။ အဲဒီလို အခြေအနေမျိုးအတွက် Asynchronous ပုံစံနဲ့ အလုပ်လုပ်ပါတယ်။ Asynchronous အမျိုးအစားအတွက် process fail သွားခဲ့ရင် AWS က နှစ်ခါတိတိ ပြန်ပြီး retry လုပ်ပေးပါတယ်။ စုစုပေါင်း သုံးခါပေါ့။

Stream (Poll-based)

နောက်ဆုံးတစ်ခုကတော့ Stream ဖြစ်ပါတယ်။ ဥပမာ - Kinesis ရဲ့ data stream ကို lambda က polling လုပ်နေမှာ ဖြစ်ပြီးတော့ data အပြောင်းအလဲရှိတိုင်းမှာ function ကို အလိုအလျောက်ခေါ်ပေးမှာ ဖြစ်ပါတယ်။ Stream အမျိုးအစားမှာတော့ retry က data source ရဲ့ expiration date ပေါ်မှာ အခြေခံမှာ ဖြစ်ပါတယ်။

သာမန် API Server နဲ့ ဘာကွာလဲ?

API တစ်ခုကို deploy လုပ်ချင်ပြီ ဆိုကြပါစို့။ ပုံမှန် လုပ်ရိုးလုပ်စဥ်နည်းနဲ့ ပြောရမယ်ဆိုရင် ပထမဆုံး အဲဒီ API application အတွက် instance တစ်ခုဝယ်။ ပြီးရင် SSH နဲ့ ဝင်ပြီး setup လုပ်။ လိုတာတွေ install လုပ်။ နောက်ပြီး လိုအပ်ရင် လိုအပ်သလို configuration တွေလည်း ပြင်ရမယ်။ ဥပမာ - မလိုအပ်တဲ့ port တွေ ပိတ်တာမျိုး၊ SSL enable လုပ်တာမျိုး၊ file permission တွေပြင်တာမျိုးတို့ စသည်ဖြင့်ပေါ့။ နောက်ပြီး ကိုယ်ဝယ်ထားတဲ့ instance ရဲ့ specification ကို အပြည့်အဝ အသုံးချနိုင်ဖို့အတွက် ကိုယ့် application မှာ သုံးထားတဲ့ programming language ပေါ်မူတည်ပြီး tuning လုပ်ရတဲ့ အပိုင်းတွေလည်း ရှိပါသေးတယ်။ ဒါတွေကို လုပ်ဆောင်နိုင်ဖို့အတွက် infrastructure နဲ့ ပတ်သတ်ပြီး knowledge အတော်အသင့်ရှိတဲ့ backend developer တစ်ယောက် မရှိမဖြစ်လိုအပ်ပါတယ်။ ဒါဆို Serverless နဲ့ဆိုရင်ကော?

AWS Serverless နဲ့ဆိုရင်တော့ အရင်ဆုံး lamda function တစ်ခု create လုပ်ဖို့အတွက် runtime ကိုရွေး၊ runtime ဆိုတာက ကိုယ့် application က node.js နဲ့ဆိုရင် node.js runtime၊ python နဲ့ဆိုလည်း python runtime ပေါ့၊ ပြီးရင် trigger point ကိုရွေး၊ ဒီနေရာမှာ API ကို တစ်ခု deploy လုပ်ချင်တာဖြစ်တဲ့အတွက် trigger point ကို API Gateway ကိုရွေးရမှာဖြစ်ပါတယ်။ API Gateway မှာလည်း လိုအပ်တဲ့ အဆင့်လေးတွေကိုတော့ လုပ်ဆောင်ရမှာပေါ့။ ဥပမာ resource တစ်ခု create လုပ်၊ create လုပ်ထားတဲ့ resource ကို request ရောက်လာရင် လှမ်းခေါ်ရမယ့် lambda function ကိုရွေးပေး။ publish လုပ်။ ဒီလောက်ပါပဲ။  ပြီးရင် lambda function ဘက်မှာ code ကို upload တင်၊ setting လေးတွေကို လိုအပ်သလို update လုပ်။ memory limit တို့ timeout တို့ပေါ့။ အားလုံးပြီးရင် publish လုပ်။ ဒါဆိုရင် serverless ပေါ်မှာ အလုပ်လုပ်တဲ့ API endpoint တစ်ခု အဆင်သင့်ဖြစ်သွားပါပြီ။

အားသာချက် ..

ပထမဆုံးကတော့ အကုန်အကျ ပိုပြီးသက်သာတဲ့ အချက်ပဲ။ Server ကို maintain လုပ်စရာမလိုတဲ့အတွက် infra အပိုင်းမှာလည်း လူအင်အားလျော့လို့ရတယ်။ Command line နဲ့မဟုတ်ပဲ သူ့ရဲ့ dashboard ကနေ ဘယ်သူမဆို လွယ်လွယ်ကူကူနဲ့ မြန်မြန်ဆန်ဆန် deploy လုပ်လို့ရတယ်။ Startup တွေအတွက် MVP တစ်ခုကို အမြန်တည်ဆောက်ဖို့ဆိုရင် အတော်လေး အဆင်ပြေတယ်။ ဥပမာ .. javascript framework တွေဖြစ်တဲ့ react သို့မဟုတ် vue နဲ့ ရေးထားတဲ့ frontend app ကို S3 မှာ host ထားမယ်။ S3 မှာ static file hosting support ရှိပါတယ်။

ပြီးတော့ API အတွက် lambda ကို သုံးမယ်။ ဒါဆိုရင် ဘာ server မှ maintain လုပ်စရာမလိုတဲ့ web application တစ်ခု တည်ဆောက်လို့ရနေပါပြီ။ Auto scaling ကလည်း default မို့လို့ Scalability အတွက်လည်း ခေါင်းမစားရတော့ပါဘူး။ Database, Authentication, Monitoring အတွက်လည်း DynamoDB, Cognito, CloudWatch အစရှိတဲ့ service တွေကလည်း AWS မှာ ရှိပြီးသားမို့လို့ လိုရင်လိုသလို integrate လုပ်ပြီး သုံးလိုက်ရုံပါပဲ။

အားနည်းချက်..

အားနည်းချက်တွေ အနေနဲ့ ဆိုရင်တော့ cloud service provider တွေက fully managed လုပ်တာဖြစ်လို့ ကိုယ့်ဘက်က ဘာမှ control လုပ်လို့မရတော့ပါဘူး။ ဒါဟာ အလုပ်ရှုပ်သက်သာတာမှန်ပေမယ့် တခါတလေကျတော့ လုပ်ရကိုင်ရတာ လက်ပေါက်ကပ်တဲ့ အခြေအနေမျိုးတွေလည်း ဖြစ်လာနိုင်ပါတယ်။ ပြီးတော့ limitation တွေ အခြားပြဿနာတွေလည်း ရှိပါသေးတယ်။ Lambda function တစ်ခုကို deploy မလုပ်ခင် local မှာ test လုပ်ဖို့ဆိုတာ သာမန်ရေးထားတဲ့ function ကို test လုပ်သလို မလွယ်ကူပါဘူး။ နောက်ပြီး deploy လုပ်တဲ့အခါမှာလည်း code ကို zip file နဲ့ upload လုပ်ရပါတယ်။ Dashboard မှာ Built-in editor ပါတယ်ဆိုပေမယ့်လည်း လိုအပ်တဲ့ အခြား third-party package တွေ install လုပ်လိုက်တဲ့အခါမှာ file တွေ တအားများသွားတဲ့ အတွက် အဲဒီ Built-in editor က အလုပ်မလုပ်တော့ပါဘူး။ ဒါကို ဖြေရှင်းဖို့အတွက် serverless framework လိုဟာမျိုးကို ထပ်သုံးရပါတယ်။ ဒီအကြောင်းကိုတော့ နောက်ကြုံမှ ထပ်ရေးပါဦးမယ်။

နောက်ထပ် အားနည်းချက်တစ်ခုကတော့ အကုန်အကျသက်သာတယ် ဆိုသော်ငြားလည်း ဘယ်လောက်ကုန်ကျမလဲဆိုတာကို ပုံသေတွက်လို့မရပါဘူး။ ဘာကြောင့်လည်းဆိုတော့ သူ့ရဲ့ pricing model က လစဥ်ကြေးနဲ့ မဟုတ်ပဲ ကိုယ်ယူထားတဲ့ memory ပမာဏရယ် lambda function က processing time နဲ့ process လုပ်ရတဲ့ အကြိမ်အရေအတွက်ပေါ်ကို မူတည်ပြီးတော့ တွက်တာဖြစ်တဲ့အတွက် စုစုပေါင်းကုန်ကျငွေက ကိန်းရှင်ဖြစ်နေပါတယ်။ အရမ်းကြီး traffic များလွန်းတဲ့ application ဆိုရင်တော့ သာမန် web server တစ်ခုထက်တောင် ပိုပြီး ကုန်ကျနိုင်ခြေရှိပါတယ်။ အကြမ်းဖျင်း တွက်ကြည့်ဖို့ကိုတော့ AWS မှာ calculator ရှိပါတယ်။ မိမိရဲ့လိုအပ်ချက်အပေါ်မှာ မူတည်ပြီးတော့ ချင့်ချိန်ရွေးချယ်သင့်ပါတယ်။ ဆိုလိုတာကတော့ serverless သုံးရင် အကုန်အကျ သက်သာတယ်ဆိုတိုင်း မျက်စိမှိတ်ပြီး မသုံးပဲနဲ့ ကိုယ့် usecase နဲ့ သင့်တော်သလား မသင့်တော်သလား အရင်ဆန်းစစ်ဖို့ပါပဲ။ ဘယ်နည်းပညာကမှ ဘက်စုံထောင့်စုံမှာ အဆင်ပြေဆုံး အကောင်းဆုံးဆိုတာ မရှိပါဘူး။ သူနေရာနဲ့ သူ လိုသလို အသုံးချတတ်ဖို့ပဲ အရေးကြီးပါတယ်။

နောက်ဆုံး ပြဿနာတစ်ခုကတော့ latency ပါ။ အစောပိုင်းကပြောခဲ့သလို lambda function ကို ခေါ်လိုက်တဲ့အခါမှာ container တစ်ခုကို တည်ဆောက်ရတာ ဖြစ်တဲ့အတွက် အချိန်အနည်းငယ် ယူရပါတယ်။ ဒါကို cold start လို့ခေါ်ပါတယ်။ 15 မိနစ်အတွင်းမှာ နောက်တစ်ကြိမ်ခေါ်တဲ့ အခါမှာတော့ ရှိပြီးသား container ကို ပြန်သုံးတာဖြစ်တဲ့အတွက် ပိုမြန်ပါတယ်။ ဒါကို warm start လို့ခေါ်ပါတယ်။

အဲဒီတော့ ဒီပြဿနာကို ဖြေရှင်းဖို့အတွက် အချို့က function ကို အမြဲတမ်း warm ဖြစ်နေအောင် လုပ်ကြတာလည်း ရှိပါတယ်။ အကြမ်းဖျင်းအားဖြင်းကတော့ 15 မိနစ်မတိုင်ခင် lambda function ကို ပြန်ပြန်ခေါ်ပေးနေတဲ့ သဘောမျိုးပါ။

အကယ်၍များ lambda function က VPC ထဲမှာဆိုရင် latency ပြဿနာက ပိုဆိုးပါတယ်။ Container တစ်ခု တည်ဆောက်ရုံတင် မဟုတ်တော့ပဲ subnet assign လုပ်ခြင်းစတဲ့ network setup လုပ်တဲ့ အဆင့်တစ်ဆင့် ပိုတိုးလာတဲ့အတွက် ပိုကြာပါတယ်။ ဒါပေမယ့် AWS ကတော့ September လတုန်းက ဒီပြဿနာကို ဖြေရှင်းထားပါတယ်လို့တော့ ပြောထားပါပြီ။

ဒီလောက်ဆိုရင်တော့ Serverless ဆိုတာ ဘာလဲ၊ ဘယ်လို အလုပ်လုပ်သလဲ၊ ဘယ်လိုနေရာတွေမှာ သုံးလို့ရသလဲ၊ အားသာချက် အားနည်းချက်တွေက ဘာတွေလဲ ဆိုတာ အခြေခံအားဖြင့် နားလည်သွား လိမ့်မယ်လို့တော့ မျှော်လင့်ပါတယ်။ Serverless က ခုမှ အရှိန်ယူကောင်းနေဆဲ နည်းပညာအသစ်တစ်ခု ဖြစ်တဲ့အတွက် လိုအပ်တွေ အားနည်းချက်တွေ ရှိနေသးပေမယ့် အချိန်ကြာလာတာနဲ့ အမျှ တိုးတက်မှုတွေ အားသာချက်တွေ တဖြည်းဖြည်းနဲ့ ရှိလာဦးမှာပါ။ ပြီးတော့ Cloud computing လောကမှာ ဘယ်လောက်ထိ နေရာရလာနိုင်မလဲ ဆိုတာကတော့ စိတ်ဝင်စားဖို့ကောင်းပြီး စောင့်ကြည့်ရမယ့် အနေအထားမှာ ရှိပါတယ်။

Credit
Cover Photo by Taylor Vick on Unsplash