Scalability

Scalability ဆိုတာကေတာ့ လက္ရိွ ရိွေနသည့္ system ကို scale လုပ္လို႕ရေအာင္ လုပ္ထား တယ္လို႕ ဆိုႏိုင္ပါတယ္။ Scale လုပ္တယ္ဆိုတာက လက္ရိွ လူ ၁၀ ေယာက္ေလာက္ သံုးေနခ်ိန္မွာ server အေသးပဲ လိုေပမယ့္ လူ အေယာက္ ၁ သန္း သံုးသည့္ အခ်ိန္မွာေတာ့ လက္ရိွ server နဲ႕မရေတာ့ပါဘူး။

Horizontal Scale , Vertical Scale

Scaling လုပ္သည့္ အပိုင္းမွာ ၂ မ်ဳိး ရိွပါတယ္။ Horizontal လုပ္မလား Vertical လုပ္မလား ဆိုျပီး ရိွပါတယ္။ Vertical ကေတာ့ လက္ရိွ ရိွေနသည့္ server spec ကို တိုးလိုက္တာပါ။ အလြယ္ဆံုး နဲ႕ အျမန္ဆံုး ပါပဲ။ သို႕ေပမယ့္ အျမင့္ဆံုး အျမန္ဆံုး server နဲ႕ ေတာင္ မေလာက္ ရင္ ဘယ္လိုလုပ္မလဲ ? ေနာက္ပိုင္းမွာေတာ့ Vertical ထက္ Horizontal scale ကို ပိုျပီး အသံုးျပဳၾကပါတယ္။ Horizontal scal ဆိုတာကေတာ့ server အေသးေတြ အမ်ားၾကီးကို Load balancer တစ္ခု ခံျပီး အသံုးျပဳၾကပါတယ္။ Horizontal scaling ဟာ vertical scaling ထက္ ေငြကုန္ သက္သာပါတယ္။ ေနာက္ျပီးေတာ့ လိုသေလာက္ အတိုးအေလ်ာ့ လြယ္လင့္ တကူ လုပ္ႏိုင္တယ္။


Concurrency

Horizontal scaling ဟာ vertical scale ထက္ concurrency ပိုျပီး ခံႏုိင္ရည္ ရိွပါတယ္။ server တစ္ခု တည္းမွာ load မရိွပဲ server ေတြခဲြ ျပီးေတာ့ လုပ္ေဆာင္ပါတယ္။

Thread Pool,Connection, Workers

Vertical scaling လုပ္ရင္ Web server မွာ max connection ေတြ တိုးဖို႕ လိုပါတယ္။ တစ္ခါ scale လုပ္တိုင္း max connection , thread pool, workers စတာေတြကို ျပန္ျပီး ခ်ိန္ ညိွေပးဖို႕ လိုတယ္။ အဲလို မခ်ိန္ညိွထားရင္ vertical scale က သိပ္ျပီး အလုပ္ျဖစ္မွာ မဟုတ္ပါဘူး။ Horizontal scale ကေတာ့ လက္ရိွ server ကိုပဲ clone လုပ္ျပီး သံုးတာ ျဖစ္သည့္ အတြက္ေၾကာင့္ thread, connection စတာေတြ ျပန္ခ်ိန္ဖို႕ မလိုေတာ့ပါဘူး။

Cache Server

Scalability ျဖစ္ေအာင္ မျဖစ္မေန cache server လိုအပ္ပါတယ္။ Cache ကို memcache , redis စတာေတြကို အသံုးျပဳႏိုင္တယ္။ အဓိက memory base ျဖစ္ဖို႕ လိုတယ္။ File Cache ထက္စာရင္ memory base cache ေတြက ပိုျပီး ျမန္တယ္။ ဒါေၾကာင့္ code ေရးသည့္ အခါမွာလည္း cache ကို မျဖစ္မေန ထည့္သြင္းေရးရတယ္။

Caching ပိုင္းက လြယ္လြယ္ေလးလို႕ ဆိုေပမယ့္ ဘယ္အခ်ိန္မွာ cache ဖ်က္မယ္။ cache ထားမယ္။ ဘာေတြကေတာ့ cache ရိွဖို႕ လိုတယ္။ ဘာေတြကေတာ့ cache ထားလို႕ မျဖစ္ဘူးဆိုတာကို နားလည္ဖို႕ လိုတယ္။

Cache Server ကို သီးသန္႕ ခြဲထုတ္ထားမွသာ server အကုန္လံုးက cache တစ္ခု တည္း အေနနဲ႕ အလုပ္လုပ္ႏုိင္ပါလိမ့္မယ္။ Local file cache ဆုိရင္ server တစ္ခု ျခင္းဆီက cache ကို အလုပ္လုပ္ေနရပါမယ္။


Storage

Multi-server ျဖစ္သြားသည့္ အခါမွာ static file ေတြကို တစ္ေနရတည္းမွာ အသံုးျပဳ ႏိုင္ရင္ ပိုေကာင္းပါတယ္။ Amazon S3, Digital Ocean Space လိုမ်ဳိး file storage ေတြမွာ သိမ္းျပီးေတာ့ CDN နဲ႕ ေခၚသံုးတာ ပိုအဆင္ေျပပါလိမ့္မယ္။ Multi server ျဖစ္သည့္ အတြက္ေၾကာင့္ တစ္ေနရာမွာ javascript , css ကို ျပင္လိုက္ရင္ အကုန္လံုးမွာ လိုက္ေျပာင္းဖုိ႕ အတြက္ မလြယ္လွပါဘူး။ Static အတြက္ Storage တစ္ခုခု ကိုသံုးထားျပီးေတာ့ အဲဒီ file ကို access လုပ္တာ အဆင္ေျပဆံုးပါပဲ။ အဲဒီလို မဟုတ္ရင္ေတာ့ Server ၅ လံုးရိွရင္ ၅ လံုး စလံုး ျပန္ျပီး update လုပ္ေနရပါလိမ့္မယ္။

အကယ္၍ user profile ေတြပါလာခဲ့ရင္ profile picture ကို upload လိုက္တာနဲ႕ အျခား server ေတြကေနလည္း access ရေနဖို႕လိုတယ္။ ပံုမွန္ local ထဲမွာ သိမ္းမယ့္ အစား S3 လိုမ်ဳိး file storage မွာ သိမ္းသည့္ အခါမွာ အျခား server ေတြက လြယ္လင့္ တကူ ျပန္ျပီး ရယူႏိုင္ပါတယ္။

Backend ကေန ပံုတစ္ပံုတင္လိုက္တယ္ဆုိရင္ သမာရိုးက် ကေတာ့ file အေနနဲ႕ လက္ရိွ server မွာ သိမ္းသြားတယ္။ /var/www/domains/blabla.com/storage/pic1.jpg ဆိုျပီးေတာ့ေပါ့။ အဲဒါဆုိရင္ အဲဒီ server ကေနပဲ access လုပ္လို႕ရမယ္။ အျခား server မွာ file မရိွသည့္အတြက္ ေၾကာင့္ အဆင္မေျပဘူး။ ဒါေၾကာင့္ မျဖစ္မေန s3 လိုမ်ဳိး storage တစ္ခုခုကို အသံုးျပဳရပါတယ္။


Git

မျဖစ္မေန Git သို႕မဟုတ္ version control system တစ္ခုခု ကို သံုးဖုိ႕လိုအပ္တယ္။ File တစ္ခုခု ျပင္တာႏွင့္ production မွာ တစ္ခုျခင္းဆီ လိုက္ျပင္ေနမယ့္ အစား pull ဆြဲခ်တာ ပိုအဆင္ေျပတယ္။ Server 5 လံုးမွာ file 10 ခု ေလာက္ကို တစ္ခုျခင္းစီ လိုက္ျပင္ေန ဖို႕ မလြယ္ဘူး။ ဒါေၾကာင့္ Git ကို အသံုးျပဳျပီးေတာ့ server မွာလည္း file ေတြကို git ကေန ပဲအသံုးျပဳတာ ပိုအဆင္ေျပပါလိမ့္မယ္။

ပံုမွန္အားျဖင့္ developer ေတြဟာ production server ေပၚမွာ အေရးေပၚ fix လုပ္တာေတြ ရိွတတ္တယ္။ Mutli Server ျဖစ္သြားသည့္ အခါမွာ အဲလို လုပ္လို႕ မရေတာ့ဘူး။ Server တစ္ခု ျခင္းစီကို fix code ေတြ လိုက္ျဖည့္တာ အခ်ိန္ၾကာသလို က်န္ခဲ့တာေတြလည္း ရိွႏိုင္တယ္။ ဒါေၾကာင့္ မျဖစ္မေန git ကို အသံုးျပဳေစခ်င္တယ္။


Database

Code က ေရးထားတာ ေကာင္းေပမယ့္ database ပိုင္းကို ေသခ်ာမလုပ္ထားရင္လည္း အဆင္မေျပပါဘူး။ အခု ေဆာင္းပါးက Scalability ျဖစ္ေနတာေၾကာင့္ high performance အေၾကာင္းကို ေနာက္မွ ေျပာပါမယ္။

MySQL ကို scale လုပ္ဖို႕ လြယ္ေတာ့ မလြယ္ပါဘူး။ ပံုမွန္ အားျဖင့္ Read/Write Database ခြဲျပီးေတာ့ master slave replication လုပ္ၾကတယ္။ Read ပဲရိွျပီး write မရိွသည့္ database နဲ႕ write ပဲ အဓိက လုပ္သည့္ database ကို ခြဲၾကပါတယ္။

သို႕ေပမယ့္ master slave replication က ေနရာတိုင္း အတြက္ အဆင္မေျပပါဘူး။ Database ပိုင္းမွာလည္း scale လုပ္သည့္ အခါမွာ performance အတြက္လား data safety အတြက္ လား ဆိုျပီး စဥ္းစားႏိုင္တယ္။ Data safety အတြက္ ဆုိရင္ Multi Master replication ကို အသံုးျပဳႏိုင္တယ္။ သို႕ေပမယ့္ performance က data မ်ားလာေလေလ က်လာေလေလ ျဖစ္ႏိုင္တယ္။

အမ်ားအားျဖင့္ Master Slave ကို အသံုးျပဳၾကတယ္။ Master ကို Delete/Update/Insert အတြက္ သံုးျပီး Read ကိုေတာ့ Slave Replica ေတြကေန ဖတ္ၾကတာ မ်ားတယ္။ Master နဲ႕ ပံုမွန္ sync လုပ္ေနဖို႕ လိုပါတယ္။ အဲလိုမ်ဳိး ကိစၥေတြ အတြက္ HAProxy နဲ႕ တြဲျပီး အသံုးျပဳၾကတာ မ်ားပါတယ္။ Port တစ္ခုကို read query အတြက္ အသံုးျပဳျပီးေတာ့ write အတြက္ကို အျခား port တစ္ခု နဲ႕ အသံုးျပဳႏိုင္တယ္။ Code အေနနဲ႕ database တစ္ခု ထက္ပိုျပီး handling လုပ္ႏိုင္ေအာင္ ဖန္တီးထားဖို႕ လိုတယ္။

အခုေနာက္ပိုင္း Maria DB မွာ MaxScale ဆုိတာ ထြက္လာပါတယ္။ Read-write splitting အလိုလို ေဆာင္ရြက္ေပးႏိုင္တယ္။ Query Caching ေတြပါတယ္လို႕ ဆုိပါတယ္။ Sharding ပါ support လုပ္တယ္လို႕ ဆိုပါတယ္။

MySQL မွာေတာ့ MySQL Router ဆိုျပီး ထုတ္ထားပါတယ္။ MySQL Community Edition မွာ support လုပ္တယ္လို႕ ဆိုပါတယ္။

အျခား database ေတြ လည္း scaling လုပ္ဖို႕ သူ႕နည္းသူ႕ဟန္ နဲ႕ ရိွၾကပါတယ္။ အမ်ားအားျဖင့္ Master/Slave (Read/Write) replication သို႕မဟုတ္ Sharding ကို အသံုးျပဳၾကပါတယ္။


Scalable ?

လက္ရိွ ေရးထားသည့္ code ေတြက scalable ျဖစ္ရဲ႕ လား ဆုိတာ ျပန္စစ္ေဆးၾကည့္သင့္ပါတယ္။

လက္ရိွ project မွာ
1. Git အသံုးျပဳျပီး deploy လုပ္ေနသလား ?
2. Cache Server သံုးမယ္ ဆုိရင္ေကာ အဆင္ေျပလား ? လြယ္လင့္ တကူ ထည့္သံုးႏိုင္လား ?
3. File Upload ေတြကို သီးသန္႕ class ခြဲထားလား။ static file ေတြကို config နဲ႕ url လုပ္ထားလား ? အခု အခ်ိန္မွာ s3 ေျပာင္းသံုးမယ္ဆုိရင္ ခ်က္ျခင္း ေျပာင္းေပးႏိုင္လား ?
4. Database ကို တစ္ခုထက္ ပိုျပီး ေရးႏိုင္ဖတ္ႏိုင္လား ? DB connection က တစ္ခုပဲ အသံုးျပဳလို႕ ရေနတာလား ?

Scalable လုပ္ႏိုင္ေပမယ့္ code quality နဲ႕ database design/setup က high performance မဟုတ္ရင္ေတာ့ သိပ္ျပီး မထူးလွပါဘူး။ High Performance ျဖစ္ေအာင္ Coding Skills အျပင္ database knowledge ပိုင္းလည္း ေကာင္းမြန္စြာ နားလည္ဖို႕လိုအပ္ ပါတယ္။ Database အပိုင္းနဲ႕ ပတ္သက္ျပီး ေနာက္မွ post တစ္ခု ထပ္ေရးပါအံုးမယ္။


 

51
Kudos
Don't
move!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.