WebLogic Clustered Env:

WebLogic  Clustered Env:

Corporate ေတြရဲ႕ web application ေတာ္ေတာ္မ်ားမ်ားဟာ Clustered Environment မွာထားၾကတယ္။

Clustering အေၾကာင္းေျပာေနရင္ ရွည္လ်ားေထြျပားကုန္မယ္။ အၾကမ္းဖ်င္းကေတာ႔ Availability ျမင္႔ေအာင္ၾကပါတာပါ။ Weblogic မွာေတာ႔ Managed Server  အေနနဲ႕လုပ္ၾကပါတယ္။ App1 ကို အရင္စ။ cluster ထဲသြင္းထား။ ေနာက္ထပ္ App2 ကုိစ Cluster ထဲသြင္း။  cluster နဲ႕မွန္မွန္ကန္ကန္ေလးတက္လာတဲ႔ server ေတြမွာဆို
 
အဲဒီ BEA 000102 ေလးေတြ႕ရလိမ္႔မယ္။ အဲဒီ IP နဲ႕ Port ေနာက္မွာ Clusters 2 ခုရိွတယ္ေပါ႔။ App1 နဲ႕ App2 ကို Node ေတြလုိ႕လည္းေခၚတယ္။ ဒါက အလြယ္ဆံုး ဥပမာေျပာတာ။

မ်ားေသာအားျဖင္႔ေတာ႔ Load Balancer Hardware/software/Plug-in တစ္ခုခု ေရွ႕နားကေန ခံထားေလ႔ရိွတယ္။ အဲဒါမွမဟုတ္ရင္လည္း အလကားလုပ္ထားသလိုျဖစ္ကုန္မွာကိုး။

ၾကံဳေလ႔ၾကံဳထရိွတဲ႔ ျပႆနာသံုးေလးခုအေၾကာင္းေျပာၾကရေအာင္။ ပထမဆံုးက cluster လုပ္ထားရင္ session ကို share ရမယ္။ မဟုတ္ရင္ ပထမ request က App1 ေၾကာင္႔၊ ဒုတိယ request က App2 ေရာက္ေတြျဖစ္ကုန္ရင္ Session Timeout ေတြျဖစ္ေစႏုိင္တယ္။

Load Balancer က App ကို တုိက္ရုိက္လႊဲလိုက္တာေတာ႔မဟုတ္ဘူး။ App ေတြရဲ႕ အေပၚမွာ Web ရိွဦးမယ္။ Balancer က Web ရဲ႕ အေပၚမွာရိွရမယ္။ အဲဒီလုိထားၾကတယ္။

ဒုတိယတစ္ခု သတိထားရမွာက session ကို share ပါျပီတဲ႔။ session ထဲကို ထည္႕လုိက္တဲ႔ bean ေတြက serializable ျဖစ္ရမယ္။ အဲဒါမွမဟုတ္ရင္ အဆင္မေျပဘူး။ Clustered Env မွာ Serialized မလုပ္ထားတဲ႔ object ေတြ ဒြတ္ခေရာက္ကုန္မယ္။ Good Practice ကေတာ႔ Object မွန္သမွ် Base object တစ္ခုကို extends လုပ္ခိုင္းထားျပီး၊ အဲဒီ base Object ကို serializable interface implements လုပ္လုိက္ရင္ ေနာက္လာေနာက္သားေတြ စိတ္ေအးရတယ္။

ေနာက္တစ္ခုကေတာ႔ ဂြစာေတြ။ third party plug-in ေတြက တစ္ခ်က္တစ္ခ်က္ serialized လုပ္လုိ႕မရတာရိွတယ္။ အဲဒီ lib ေတြပါလာရင္ ေစာေစာစီးစီး ေျပာင္းသံုးလုိ႕ရတုန္း ေျပာင္းသံုးထားလုိက္။မဟုတ္ရင္ ေနာက္မွာ ဒုကၡေသခ်ာေပါက္ေပးလိမ္႔မယ္။

အခုလက္ရိွလုပ္ေနတဲ႔ project အေဟာင္းတစ္ခုမွာ user ကို active ျဖစ္ေနလား၊ မျဖစ္ေနလားကို log-in လုပ္ကတည္းက user ID နဲ႕ session ID ကို persist လုပ္ထားလုိက္ျပီး၊ ျပန္ျပန္စစ္တာမ်ိဳး။ ဆာဗာတစ္လံုးထဲဆိုရင္ ဘာမွမျဖစ္ဘူး။ Load Balancer ကို sticky session လုပ္ထားရင္လည္း အဆင္ေျပတယ္။(သို႕ေသာ္ မေကာင္းဘူး။ std: အရလည္း မလုပ္သင္႔တာေတြရိွတယ္။) session ID ကို ျပန္သံုးတဲ႔အခါမွာ session.getSessionID() method နဲ႕သံုးထားတာေတြ႕တယ္။ အဲဒီမွာ ျပႆနာအၾကီးၾကီးရိွတယ္။ cluster ေတြမွာ session ထဲမွာ သိမ္းထားတဲ႔ Java Object ေတြကို replicate လုပ္တာမွန္ေပမယ္႔၊ session ID ႏွစ္ခုဟာ somehow identical ျဖစ္မေနတာေတြ႕တယ္။ အဲဒီမွာ logical error ျဖစ္ကုန္ျပီး၊ users မွန္သမွ် session timeout ၾကေလသတည္းျဖစ္ကုန္တယ္။ အရင္က အလုပ္မလုပ္တဲ႔ load balancer က သူ႕ဟာသူ ၂ ႏွစ္ေလာက္ပ်က္ေနတုန္းက အေကာင္းပဲ။ သူအလုပ္စလုပ္တာနဲ႕ အဲဒီျပႆနာေပၚလာတယ္။ ေနာက္ေတာ႔ session ID ကို user Obj ထဲေပါင္းထည္႕ထားျပီး အဲဒီ user Obj ကို session ထဲျပန္ထည္႕ထားလုိက္မွေအးသြားတယ္။ Obj ေတြက cluster မွာ replicate-if-cluster ဆိုတဲ႔ parameter on ထားလုိက္ရင္ အဆင္ေျပတယ္။ weblogic.xml မွာျပင္ရတယ္။

အခုကိစၥေတြဟာ ဖတ္ထားရင္ လြယ္လြယ္သိတယ္။ ကုိယ္တုိင္ၾကံဳမွဆုိရင္ ရြာလည္တတ္တယ္။ အထူးသျဖင္႔ Production Environment လိုမ်ိဳး Clustered Env မရိွရင္သာေတာင္ခက္တယ္။ အဲဒီ Setup Local မွာလုပ္တာကိုေတာ႔ ေနာက္ထပ္ post တစ္ခုမွာ ေရးလုိက္ပါဦးမယ္။

Regards,
Zero

Ref:http://docs.oracle.com/cd/E13222_01/wls/docs103/webapp/weblogic_xml.html#wp1071982

Server Clustering ဆိုတာ . . . (2)

Clustering မွာ ဘယ္လိုအဆင့္ေတြရွိလည္း ?
ေခါင္းစဥ္က သိပ္မကြဲပါဘူး။ ျမန္မာစာ ပညာရွိမဟုတ္ေတာ့ စကားလုံးေရြးရတာ တခါတေလ မလြယ္ဘူး။ Clustering မွာ ဘယ္လို level အလိုက္ရွိလည္းလို႕ေျပာရင္ ပိုေကာင္းမယ္။
1. Network Level Clustering
2. Service Level Clustering
3. Application Level Clustering ဆိုျပီး ေယဘူရအားျဖင့္ သုံးခုရွိပါတယ္။ Failover ပံုစံအလုပ္လုပ္မလား၊ NLB အလုပ္လုပ္မလားဆိုတာက ဘယ္လို Setup လုပ္လည္းဆိုတာေပၚမွာ မူတည္ပါတယ္။ ဘယ္လို Level clustering မွာမဆို ႏွစ္မ်ိဳးလုံး ( တစ္မ်ိဳးမဟုတ္ တစ္မ်ိဳး) setup လုပ္ဖို႕ျဖစ္ႏိုင္ပါတယ္။

Network Level Clustering ( Vs Service Level Clustering)
သူကရွင္းပါတယ္။ တကယ္လို႕ Cluster ထဲမွာ Server 5 လုံးရွိတယ္ဆိုပါေတာ့။ ဒီ Server ငါးလုံးက အခ်င္းခ်င္း Network reachability ကို စစ္ေနပါတယ္။ Engineer က configure လုပ္ထားသလို 5 seconds ဆိုလည္း 5 seconds တိုင္းမွာ၊ 5 minutes ဆိုလည္း 5 minutes တိုင္းမွာ စစ္ေနပါတယ္။ Network reachability ဆိုတာကေတာ့ က်ေနာ္တို႕ ping ၾကည့္သလိုေပါ့။ ကိုယ္သုံးတယ့္ clustering technology ေပၚမွာမူတည္ျပီး ဘယ္လိုစစ္ေနလည္းဆိုတာေတာ့ ကြာပါလိမ့္မယ္။ တကယ္လို႕ unreachable ျဖစ္သြားျပီဆိုရင္ အဲ Server down သြားျပီလို႕ ယူဆျပီး Server ကို Cluster ထဲကေနဖယ္လိုက္ပါတယ္။ ဒီ Clustering ရဲ့ အားနည္းခ်က္ကေတာ့ Server ၾကီးက မ down ဘူး၊ Server ေပၚက Service ကပဲ down ေနရင္ သူမသိပါဘူး။ သူက Network အရ ping ၾကည့္လို႕ ဒီ Server alive ရွိမရွိ စစ္တာမ်ိဳးပဲစစ္ျပီး ဆုံးျဖတ္လို႕ Network Level Clustering လို႕ေျပာတာပါ။

ဥပမာ စဥ္းစားၾကည့္ရေအာင္။ Windows Server 2003 မွာ Windows NLB Manager ဆိုတာ ပါပါတယ္။ သူက Network Level Clustering ပါ။ NLB ပံုစံ Clustering ပါ။ Server သုံးလုံးကို IIS web server run ျပီး Cluster လုပ္လိုက္ၾကတယ္ဆိုပါေတာ့ ။ User က Access လုပ္ရင္ Server သုံးလုံး တစ္လွည့္စီ respond လုပ္ေနမွာေပါ့။ တကယ္လို႕ Svr 1 က hang သြားတယ္ ဆိုပါေတာ့ ၊ ဒါမွမဟုတ္လည္း network ၾကိဳးလြတ္သြားတာပဲျဖစ္ျဖစ္၊ ဒါမ်ိဳးဆိုရင္ Svr 1 down သြားတာကို က်န္တယ့္ Sever ႏွစ္လုံးက သိပါတယ္။ လာသမွ် user ကို Svr 2 နဲ႕ 3 ကပဲ မွ်ျပီး respond လုပ္ပါလိမ့္မယ္။

ဒါေပမယ့္ တကယ္လို႕ Server 1 ၾကီးက ဘာမွမျဖစ္ဖူး ၊ IIS ကပဲ crash ျဖစ္ျပီး stop ျဖစ္သြားတယ္။ ဒီလို scenario မွာ က်န္တယ့္ Server ႏွစ္လုံးက မသိပါဘူး။ Network aspect အားျဖင့္ Server 1 က alive ရွိေနပါတယ္။ IIS Service down သြားတာ ၊ ဒီ Network Level Cluster မွာ ဒါကို မသိပါဘူး။ ဒါဆို ဘာျဖစ္မလည္း ? Cluster က Svr1 down ေနတာကို မသိတယ့္အတြက္ request 3 ခါမွာ တစ္ခါကို ထုံးစံအတိုင္း Svr1 ဆီကို ပို႕ေနပါလိမ့္မယ္။ ဒါေပမယ့္ IIS ၾကီးက down ေနေတာ့ သုံးခါမွာ တစ္ခါ error ျပေနမွာေပါ့။ Reload လုပ္လိုက္ရင္ ျပန္ေကာင္းသြားျပန္ေရာ။

ဒါဆိုဘယ္လိုလုပ္မလည္း ? Service Level ကိုပါ monitor လုပ္ႏိုင္ဖို႕လိုပါတယ္။ Windows ရဲ့ built-in ေတြမွာေတာ့ မေတြ႕မိပါဘူး။ က်ေနာ္မသိတာလည္းျဖစ္ႏိုင္ပါတယ္။ Linux မွာေတာ့ heartbeat version 2 တို႕ LDirector တို႕ေတာ့ Opensource ေတြရွိပါတယ္။ သူတို႕က Service port ကိုပဲျဖစ္ျဖစ္ Service ကိုတစ္နည္းနည္းနဲ႕ စစ္ေပးျပီး Service down ရင္လည္း Server down တယ္လို႕ သတ္မွတ္ျပီး Cluster ထဲကေန isolate လုပ္ေပးလိုက္ပါတယ္။

API ေတြနဲ႕ခ်ိတ္ဆက္ျပီး Application တစ္ခု Process တစ္ခုကို Server ေတြအမ်ားၾကီးေပၚမွာ ခြဲေဝျပီး အလုပ္လုပ္တယ့္ Application Level Clustering ကေတာ့ က်ေနာ္ ေသခ်ာမရွင္းႏိုင္တယ့္ အေၾကာင္းအရာမို႕ ေက်ာ္လိုက္ပါရေစ။

Divinity

Server Clustering ဆိုတာ . . . (1)

Clustering ဆိုတာ ဘာလည္း ?
ႏွစ္လုံး သို႕မဟုတ္ ႏွစ္လုံးထက္ပိုတယ့္ Server ေတြ၊ ဒါမွမဟုတ္လည္း Computer ေတြဟာ Application တစ္ခု ( တနည္းအားျဖင့္ အလုပ္တစ္ခု) ကို အတူတကြ အလုပ္လုပ္ၾက ၊ serve လုပ္ၾကတာျဖစ္ပါတယ္။ website ေတြ လူသုံးအလြန္မ်ားလာတာမ်ိဳး ၊ database ေတြ query access အလြန္မ်ားလာတာမ်ိဳးၾကရင္ Server တစ္လုံးထဲနဲ႕ ျပန္ျပီး respond လုပ္ဖို႕ မႏိုင္ေတာ့ပါဘူး။ Server ေတြခြဲျပီး Cluster လုပ္လိုက္ခ်င္းအားျဖင့္ ပိုေကာင္းတယ့္ respond time ကိုလည္းရႏိုင္သလို ၊ Server တစ္လုံးလုံးမွာ network error ပဲျဖစ္ျဖစ္ hardware failure ပဲျဖစ္ျဖစ္ ( HDD ပ်က္သြားတာမ်ိဳး) တစ္ခုခုျဖစ္ရင္ Site တစ္ခုလုံး ၊ Database တစ္ခုလုံး ရပ္သြားျခင္းမွလည္း ကာကြယ္ႏိုင္ပါတယ္။

Clustering လုပ္တဲ့ ပံုစံ အမ်ိဳးမ်ိဳးရွိပါတယ္။ Cluster တစ္ခုမတည္ေဆာက္ခင္မွာ ကိုယ့္ရဲ့ လိုအပ္ခ်က္ ေပၚမွာ မူတည္ျပီး ဘယ္လို Clustering မ်ိဳးလုပ္မလဲဆိုတာ ဆုံးျဖတ္ရပါတယ္။ ေယဘူရ အားျဖစ္ေတာ့ Clustering ပံုစံ ႏွစ္မ်ိဳးရွိပါတယ္။

Failover cluster
Server ႏွစ္လုံးရွိေနမယ္၊ တစ္လုံးက down သြားရင္ ေနာက္တစ္လုံးက ခ်က္ခ်င္း ပထမ server ေနရာကိုယူျပီး respond ဆက္လုပ္ေနတာမ်ိဳးပါ။ User ေတြဘက္ကၾကည့္ရင္ Server တစ္လုံး down သြားတာ သိလိုက္မွာမဟုတ္ပါဘူး။ Active - Passive setup လို႕လည္း ေခၚပါတယ္။

ဥပမာ WebSvr1 နဲ႕ WebSvr2 ဆိုၾကပါဆို႕။Server ႏွစ္လုံးစလုံးက www.example.org ဆိုတဲ့ Website ကို host လုပ္ထားတယ္ ဆိုပါေတာ့။ ပံုမွန္အားျဖင့္ WebSvr1 ကပဲ respond လုပ္ပါတယ္။ User 1 က www.example.org လို႕ surf လုပ္ရင္ WebSvr1 ကပဲ respond ျပန္သလို၊ User 2 က www.example.org လို႕ surf ရင္လည္း WebSvr1 ကပဲ respond လုပ္ပါတယ္။ WevSvr1 အေၾကာင္းတစ္ခုခုေၾကာင့္ down သြားရင္ေတာ့ WevSvr2 က အစားထိုးဝင္ေရာက္ျပီး User 1 နဲ႕ User 2 ကို respond လုပ္ပါတယ္။ User 1 နဲ႕ User 2 အေနနဲ႕ Svr1 down သြားေၾကာင္း သိလိုက္မွာ မဟုတ္ပါဘူး။ ဒါ Failover cluster ပါ။

Load balance cluster
Active - Active setup လို႕လည္း သုံးေလ့ရွိပါတယ္။ Server ႏွစ္လုံး သို႕မဟုတ္ ႏွစ္လုံးထက္ပိုတယ့္ server ေတြက အလုပ္တစ္ခုကို မွ်ေဝလုပ္ၾကတာမ်ိဳးပါ။ ( Grid computing ၊ Server System Image တို႕ကို hardware level clustering အျဖစ္ေျပာၾကေလ့ရွိပါတယ္။ Server clustering technology တစ္ခုခ်င္းကို ေနာက္မွ အခြင့္သင့္ရင္ အေသးစိတ္ေရးပါအုန္းမယ္။ )

အခုေတာ့ ျမင္သာေအာင္ Network Load Balancing Cluster ကို ဥပမာေပးပါရေစ။၊ အေပၚက ဥပမာအတိုင္း Website တစ္ခုကို web server ႏွစ္လုံးက round-robin network load balanced ပံုစံနဲ႕ ဥပမာ ေျပာရရင္၊ Web Server ႏွစ္လုံးရွိမယ္ WebSvr1 နဲ႕ WebSvr2။ Server ႏွစ္လုံးစလုံးက www.example.org ဆိုတဲ့ Website ကို host လုပ္ထားတယ္ ဆိုပါေတာ့။ User 1 က www.example.org လို႕ surf လုပ္လိုက္ရင္ WebSvr1 က respond လုပ္ပါမယ္။ User 2 က surf လုပ္ရင္ WebSvr2 က respond လုပ္ပါမယ္။ တကယ္လို႕ User 3 ထပ္ေရာက္လာရင္ WebSvr1 က respond လုပ္ပါလိမ့္မယ္။ Server loading ကို balance လုပ္ယူလိုက္တာပါ။ User 4 ထပ္ေရာက္လာရင္ Svr2 က respond လုပ္ပါလိမ့္မယ္။ တကယ္လို႕ Svr1 ကသာ down သြားရင္ User ေလးေယာက္လုံးကို Svr2 က ဆက္ျပီး respond လုပ္ပါလိမ့္မယ္။ Load balanced လုပ္ထားရာကေန ၊ တစ္လုံးျပဳတ္သြားေတာ့ ပိုေတာ့ ေႏွးသြားေကာင္း ေႏွးသြားႏိုင္ပါတယ္။

Failover နဲ႕ NLB ဘာကြာလဲ
Srv 1 down သြားရင္ Srv 2 က အလုပ္လုပ္ေပးတာ၊ ဒါဆို သိပ္မကြာဘူးလို႕ ထင္ႏိုင္ပါတယ္။ ေရာေနႏိုင္လို႕ ျပန္ရွင္းပါမယ္။ Failover မွာတုန္းက Server ႏွစ္လုံးက Active-Passive ပါ။ Active အလုံးက ေကာင္းေကာင္းအလုပ္လုပ္ေန ေသးသမွ် Passive အလုံးက standby အေနအထားမွာပဲေနပါတယ္။ အလုပ္ဝင္မလုပ္ပါဘူး။ သူ႕ဟာသူ မႏိုင္မနင္းျဖစ္လည္း ဂ႐ုမစိုက္ပါဘူး။ သူ down မွ ငါ role တက္မွာဆိုတာမ်ိဳးစိတ္ထားနဲ႕ကို လစ္လွ်ဴ႐ႉထားပါတယ္။ NLB မွာကေတာ့ Active-Active ပါ။ ရွိသမွ် Server အားလုံးက load ကို ခြဲယူထားတာပါ။ အေပၚက Scenario မွာ server ႏွစ္လုံးဆိုေပမယ့္ Server သုံးလုံး အေနနဲ႕ စဥ္းစားရင္ ပိုရွင္းမယ္ထင္ပါတယ္။ User ေျခာက္ေယာက္ကို Server သုံးလုံးက ႏွစ္ေယာက္စီခြဲျပီး respond လုပ္ေနရာကေန၊ Srv 1 down သြားရင္ Srv 2 ေန႕ Srv 3 က သုံးေယာက္ဆီ ခြဲယူျပီး respond လုပ္ေပးပါလိမ့္မယ္။ Srv 1 မ down ခင္ကလည္း သူတို႕ အလုပ္လုပ္ေနပါတယ္။ Srv 1 down သြားေတာ့ သူတို႕ပိုအလုပ္ရွုပ္သြားတယ္။

အခုေနာက္ပိုင္းမွာ failover စစ္စစ္ကို သုံးတာ ရွားပါတယ္။ NLB server ငါးလုံးအတြက္ Srv တစ္လုံးကို standby အေနနဲ႕ ထားေပးထားတာမ်ိဳးပဲရွိပါေတာ့တယ္။ Server တစ္လုံးအတြက္ ေနာက္တစ္လုံး standby ထားေပးထားတာမ်ိဳး မလုပ္ၾကေတာ့ပါဘူး။ ကုန္က်စရိတ္အရေရာ ၊ မီတာအလကား ကုန္ေနတာမ်ိဳးလည္း မျဖစ္ေအာင္ပါ။


Server ေတြကို cluster လုပ္ျပီး သုံးရင္ ဘာေတြပိုေကာင္းမလည္း ?
1 . High Availability
ႏွစ္လုံးထက္ပိုတယ့္ Server ေတြကို အတူတကြ အလုပ္လုပ္ေစတာမို႕လို႕ Failover မွာပဲျဖစ္ျဖစ္ NLB မွာပဲျဖစ္ျဖစ္ Server တစ္လုံး down သြားရုံနဲ႕ operational state ရပ္မသြားပါဘူး။ ဆက္ျပီး အလုပ္လုပ္ေနႏိုင္ေသးတယ့္ အတြက္ Availability အသုံးျပဳႏိုင္စြမ္း ပိုျမင့္ေစပါတယ္။ ဒါဟာ User ေတြရဲ့ စိတ္ေၾကနပ္မႈအတြက္ အေရးပါပါတယ္။
2. Better Performance
Failover cluster မွာေတာ့ ဒီအခ်က္ဟာ သိပ္အၾကဳံးမဝင္ပါဘူး။ NLB cluster မွာေတာ့ Request 200 ကို Server တစ္လုံးထဲက reply လုပ္တာထက္၊ Server ႏွစ္လုံးက reply လုပ္တာမို႕ ပိုျမန္ျမန္ဆန္ဆန္ respond လုပ္ႏိုင္တာ ေတြ႕ရပါလိမ့္မယ္။
( Note: CPU 3.0 MHz နဲ႕ Memory 4GB server ႏွစ္လုံးကို cluster လုပ္တာနဲ႕ CPU 3.0 MHz Dual Processor နဲ႕ Memory 8GB server တစ္လုံး performance ခ်င္းယွဥ္ရင္ Cluster ကသာပါလိမ့္မယ္။ ကိန္း ဂဏန္းအရ အတူတူေလာက္ရွိေပမယ့္ motherboard က bus speed တို႕၊ Network traffic တို႕ ထဲ့တြက္ရပါလိမ့္မယ္။ Critical application ဆိုရင္ High-Availablity(HA) ကိုလည္း အေရးပါတယ့္ factor အေနနဲ႕ ထဲ့တြက္ရပါတယ္။ )
3. Better Scalability
User ေတြအရမ္းမ်ားလာမွ တစ္လုံးထဲကေန ပိုျပီး powerful ျဖစ္တယ့္ Server ကိုေရႊ႕ရရင္ မလြယ္ပါဘူး။ Clustered environment မွာေတာ့ cluster ကို တိုးခ်ဲ႕ရတာ ပိုလြယ္ပါတယ္။ Cluster ထဲကို Server ေတြတိုးျပီး ၊ load ကိုျပန္ထိန္းဖို႕က ပိုျပီး အဆင္ေျပ လြယ္ကူပါတယ္။

Clustering မွာ ဒီႏွစ္ခုကိုပဲေျပာေနတယ္ ထင္အုန္းမယ္။ ဒီ concept ႏွစ္ခုအတြက္ technology အမ်ိဳးမ်ိဳး ကြဲျပီးျဖစ္လာတာမို႕၊ ဒီႏွစ္ခုကို အရင္ေျပာခ်င္လို႕ပါ။ ဒါေပမယ့္ ဆက္ေျပာခ်င္တယ့္ အေၾကာင္းအရာေတြက စာၾကီးပဲဖတ္ဖို႕ထက္ ပံုေလးေတြနဲ႕မွပိုအဆင္ေျပမယ္ထင္တယ္။ ပံုေလးေတြဆြဲျပီးမွ ေနာက္ post တစ္ခုဆက္ေရးေတာ့မယ္ဗ်ာ။

Divinity