Mar 29, 2026
Immutable infrastructure ကို ဘယ်အချိန်မှာလိုအပ်လဲ။
အဲ့တာမပြောခင် mutable infrastructure အကြောင်းသိဖို့လိုတယ်။ mutable ဆိုတဲ့အတိုင်း server ပေါ်မှာ အပြောင်းအလဲ လုပ်လို့ ရတာကို ဆိုလိုတယ်။ ဥပမာ - Apache server ပေါ်မှာ PHP code ကိုတိုက်ရိုက်သွား ပြင်တာမျိုး ဒါမှမဟုတ် Git providers တွေကနေ pull လုပ်တာမျိုးတွေကိုဆိုလိုတယ်။ ဒါ့အပြင် VM (Virtual Machine) မှာ တိုက်ရိုက်လုပ်တဲ့ အပြောင်းအလဲတွေလည်းပါတယ်။ ဥပမာ - နဂိုရှိနေတဲ့ Apache server ကို Nginx ပြောင်းသုံးတာမျိုး၊ ကိုယ်သုံးနေတဲ့ software package ကို update လုပ်လိုက်တာမျိုး ( NodeJS v20 to v25) တွေကို ဆိုလိုတယ်။ အဲ့လိုအပြောင်းအလဲတွေဟာ ပြုပြင်ရတာ လွယ်ကူပြီး မြန်ဆန်တယ်။ cost အနေနဲ့ရော အခြားကုန်စရာမရှိဘူး။ ပြသနာက environment isolation လုပ်တဲ့အချိန်မှာ configuration drift တွေတွေ့ကြုံရတာပါ။ ဥပမာ - ကိုယ့် company မှာ production , test, dev environments ရှိတယ်ဆိုပါစို့။ horizontal scaling approach ကို သုံးတယ် ဆိုရင် environment တစ်ခုစီက VM တစ်ခုမှာရှိနေမှာပါ။ dev မှာရှိတဲ့ NodeJS ကို Hot fix အနေနဲ့ v26 အထိ upgrade လိုက်တယ်ဆိုပါစို့။ အဲ့အချိန်မှာ test server မှာ code pull လိုက်ပြီး deploy လုပ်တဲ့ချိန် fail တယ် ပြီးတော့ တဖန် manually upgrade လုပ်ရတယ်။ NodeJS မှ မဟုတ်ဘူး အခြား software packages တွေကိုလည်း အပြောင်းအလဲ လုပ်တာများလာတာနဲ့ configuration drift ဆိုတာဖြစ်လာတယ်။ Ansible, Chef Puppet တွေလို configuration tool တွေနဲ့တော့ထိန်းလို့ရပင်မဲ့ debug လုပ်ရတာခက်လာတယ်။ Immutable infrastructure က အဲ့ဒီပြသနာတွေအတွက် အဖြေတစ်ခုဖြစ်လာတယ်။ application တွေက immutable image ( Docker image) တစ်ခုအနေနဲ့ ဖြစ်သွားတယ်။ အဲ့ဒီ image နဲ့ ဘဲ deploy လုပ်ပြီး ပြောင်းစရာရှိရင် code ကို local မှာပြင်ပြီး image အသစ်တစ်ခုအနေတဲ့ deploy လုပ်တယ် (or CI/CD approach)။ VM ကို အပြောင်းအလဲ လုပ်ချင်တယ်ဆိုရင်လဲ Golden Image approach (immutable + mutable ) ကိုသုံးတယ်။ Packer နဲ့ temporary VM လုပ်ပြီး Ansible လို configuration tool နဲ့ setup လုပ်တယ်။ အဲ့ဒီ VM ကို Packer က snapshot အနေနဲ့ image လုပ်တယ်။ အဲ့ဒီ image ကိုမှ production, test, dev VM အနေနဲ့ခွဲလိုက်တယ်။ အပြောင်းအလဲလုပ်ဖို့ရှိရင် Ansible ကနေလုပ်ပြီး image အသစ်ထုတ်တယ်။ ပြီးမှ VM အသစ်ထုတ်တယ်။ configuration drift ကိုကာကွယ်ပေးနိုင်တယ်။ ဒါမဲ့ deploy လုပ်တဲ့ချိန် mutable infra ထက်အချိန်ကြာတယ်။ Note အနေနဲ့ storage နဲ့ database တွေက အမြဲတန်း mutable ပါဘဲ။ (မဟုတ်ရင် data တွေ ပျောက်သွားလိမ့်မယ် ;))
Apr 15, 2026
ကျွန်တော် တို့ project စလုပ်တဲ့ချိန်မှာ database server instance တစ်ခုတည်းနဲ့တင် လုံလောက်ပါတယ် (ဥပမာ - ကိုယ့် company အတွက် internal tools တွေ ၊ hobby project တွေပေါ့) ။ ကြာလာတာနဲ့ data size က ကြီးလာတော့ performance ကျလို့ cache layer (e.g Redis) ထည့်ပြီး fix လုပ်နိုင်တယ်။ ဒါပင်မဲ့ database server instance တစ်ခုကိုဘဲသုံးနေရင် (vertical scaling လုပ်မယ်ဆိုရင်) အရင် blog က ပြောတဲ့ အတိုင်း hardware limit ကိုထိလာတယ်။ ဥပမာအနေနဲ့ data intensive ဖြစ်တဲ့ application တွေပြောရရင် bus ticket application တွေ၊ ordering system တွေပါ။ ...
ထို့ကြောင့် data size ကြီးလာပြီး request တွေများလာတာနဲ့ အမြဲ horizontal scaling strategies တွေကို သုံးလာရတယ်။ ...
အသုံးများတဲ့ Database Horizontal scaling strategies နှစ်မျိုးရှိပါတယ်။ ...
၁။ Sharding ...
Write (data ကို အပြောင်းအလဲလုပ်တာ) နဲ့ read (data ဖတ်တာ) ကို servers တွေက တစ်ခုနဲ့တစ်ခုပေါ်မမှီခိုဘဲ request traffic တွေကို ဖြန့်ဝေတာ (distribute) ...
၂။ Read replicas ...
Write ကို primary server တစ်ခုကနေ handle လုပ်ပြီး read operation ကို replica လို့ခေါ်တဲ့primary database ရဲ့ copies အများကြီးတွေစီကို ဖြန့်ဝေပေးတာ။ ...
ဒီမှာတော့ database Sharding အကြောင်းရှင်းပြသွားပါမယ်။ ...
ခုနက scaling ပြသနာနဲ့ ကြည့်ရအောင်။ bus ticket application ကို သုံးလာတဲ့သူများလာတယ်ဆိုပါစို့။ data တွေက database တစ်ခုမှာဘဲ စုပြီးရှိလာရင်း traffic များလာတာနဲ့အမျှ query time တွေကြာလာတယ်။ data storage တွေပြည့်လာတယ်။ vertical scaling approach နဲ့ ဖြေရှင်းနိုင်ပင်မဲ့ အပေါ်ကပြောတဲ့ ပြသနာတွေရှိတယ်။ အဲ့ဒီကြီးမားနေတဲ့ database တစ်ခုလုံးကို ခွဲခြမ်းစိတ်ဖြာပြီး ထိန်းသိမ်းရလွယ်တဲ့ အစိတ်အပိုင်းတွေကို shard လို့ခေါ်တယ်။ shard တစ်ခုချင်းစီက database server instance အသီးသီးမှာရှိတယ်။ တစ်နေရာမှာဘဲ မစုနေလို့ workload တွေကို ကောင်းကောင်းဖြန့်ဝေနိုင်တယ်။ ...
ဘယ်လိုခွဲခြမ်းစိတ်ဖြာ (sharding) တာလဲ? ...
Data တွေဟာ shard key အလိုက် group လုပ်ပြီးခွဲတယ်။ shard key တွေက ခင်ဗျားရဲ့ database ထဲက column တစ်ခု ဒါမှ မဟုတ် တစ်ထက်ပိုပြီး ပေါ်မူတည်နေတယ်။ ဥပမာ - ticket id , user id , order number တွေ။ ဒါမှ မဟုတ် approach အရ ဘယ် column မှ မမူတည်ဘဲ unique generated key တွေနဲ့လည်း သုံးလို့ရတယ်။ အဲ့ဒီ shard key တွေကို database တစ်ခုထဲမှာ သိမ်းပြီး data request လာတဲ့ချိန် routing လုပ်တဲ့နေရာမှာသုံးတယ်။ routing ကို load balancer ဒါမှမဟုတ် proxy တစ်ခုကနေ shard key အရသက်ဆိုင်တဲ့ shard (database server) စီကို direct လုပ်ပေးတယ်။ ဒါမဲ့ မဟုတ် GCP documentation အရ multi-player game တို့ high performance real time application (e.g trading system) တွေမှာဆိုရင် application ရဲ့ code မှာတင် shard key ကိုဆုံးဖြတ်တယ်။ ...
လူသိများပြီး အသုံးများတဲ့ sharding နည်းလမ်းတစ်ခုစီကိုပုံနှင့်တကွဖတ်နိုင်ပါတယ်။ ...
Apr 5, 2026
အရင် blog အဆက် ...
Applications မှာ သုံးလာတဲ့သူများလာတာနဲ့အမြဲ scale လုပ်ဖို့ လိုအပ်လာတယ်။ Scaling လုပ်ရင်ဘာကောင်းမှုတွေရှိလဲ။ ၁။ system ရဲ့ reliability နဲ့ availability ကိုမြင့်စေတယ်။ ၂။ response လုပ်တဲ့ခါ performance ကောင်းစေတယ်။ ၃။ storage နဲ့ data များပြားလာမှုကို အထောက်အကူလုပ်ပေးတယ်။ ...