High Availability සහ Fault Tolerance කියන්නේ එකම දේද?
හිතන්න…
ඔයා build කරපු Application එකක් අද thousands of users use කරනවා.
Orders එනවා.
Payments process වෙනවා.
Customers login වෙනවා.
Business එක smoothly run වෙනවා.
එක මොහොතක…
Server එකක් crash වෙනවා.
දැන් තියෙන වැදගත්ම question එක:
“Server එක fail වුණාද?”
කියන එක නෙවෙයි.
වැදගත් question එක:
“User කෙනාට ඒ failure එක දැනුණාද?”
මෙතනින් තමයි Cloud සහ System Architecture වල ඉතාම වැදගත් concepts දෙකක් අපිට හම්බවෙන්නේ.
High Availability
සහ
Fault Tolerance
මේ terms දෙක ගොඩක් වෙලාවට එකම meaning එකක් වගේ use කරනවා.
හැබැයි ඒවා exactly එකම දෙයක් නෙවෙයි.
Difference එක පොඩි වගේ පේන්න පුළුවන්.
හැබැයි Production System එකක් design කරන Engineer කෙනෙක්ට මේ difference එක ගොඩක් වැදගත්.
මුලින්ම Failure කියන එක accept කරමු
Engineering වල අපි කැමති වුණත් නැතත් එක truth එකක් තියෙනවා.
Everything can fail.
Hard Disk fail වෙන්න පුළුවන්.
Server fail වෙන්න පුළුවන්.
Network connection fail වෙන්න පුළුවන්.
Database fail වෙන්න පුළුවන්.
Power fail වෙන්න පුළුවන්.
Availability Zone එකකට issue එකක් එන්න පුළුවන්.
Software bug එකක් production එකට යන්න පුළුවන්.
Human error එකක් වෙන්න පුළුවන්.
ඒ නිසා good architecture එකක්:
“Failure එකක් වෙන්නේ නැහැ.”
කියලා design කරන්නේ නැහැ.
Good architecture එක අහන්නේ:
“Failure එකක් වුණාම අපි මොකද කරන්නේ?”
කියලා.
මෙතනින් High Availability සහ Fault Tolerance දෙකේ story එක පටන් ගන්නවා.
High Availability කියන්නේ මොකක්ද?
සරලව කියනවා නම්,
High Availability කියන්නේ system එක හැකි තරම් දිගට available තියාගන්න, failure එකක් වුණොත් ඉක්මනින් recover හෝ fail over කරන්න design කරන approach එකක්.
මෙතන goal එක:
Downtime අඩු කරන එක.
Zero downtime හැම වෙලාවෙම guarantee කරන එක නෙවෙයි.
Failure එකක් වුණාම system එකට තත්පර කිහිපයක් හෝ කෙටි කාලයක් impact වෙන්න පුළුවන්.
හැබැයි architecture එක වෙනත් healthy resource එකකට shift වෙලා service එක නැවත ලබාදෙනවා.
Simple High Availability Example එකක්
හිතන්න Website එකක් තියෙනවා.
එක Server එකක් විතරයි.
Users
↓
Server A
Server A crash වුණොත්?
Website down.
Simple.
දැන් Server දෙකක් දාමු.
Users
↓
Load Balancer
↓
Server A Server B
Server A fail වුණොත් Load Balancer එක Server B එකට traffic යවනවා.
මේකෙන් Application එකේ availability වැඩි වෙනවා.
හැබැයි Server A fail වුණු exact moment එකේ requests කිහිපයක් fail වෙන්නත් පුළුවන්.
Health check එක Server A unhealthy කියලා detect කරන්න තත්පර කිහිපයක් යන්න පුළුවන්.
Traffic redirect වෙන්නත් පොඩි කාලයක් ගන්න පුළුවන්.
ඒත් system එක quickly recover වෙනවා.
මේ thinking එක තමයි High Availability.
High Availability වල main idea එක
High Availability කියන්නේ:
“Never fail.”
කියන එක නෙවෙයි.
ඒක:
“Fail වුණත් quickly recover.”
කියන එක.
මේ difference එක මතක තියාගන්න.
Availability කියන්නේ කොහොමද measure කරන්නේ?
Availability percentage වලින් කතා කරන එක common.
උදාහරණයක්:
99% Availability
99.9% Availability
99.99% Availability
Numbers ටික small difference එකක් වගේ පේනවා.
හැබැයි year එකක් ගත්තම difference එක ලොකු වෙන්න පුළුවන්.
Approximate විදිහට:
99% Availability
වසරකට පැය 87ක් වගේ downtime.
99.9% Availability
වසරකට පැය 9කට ආසන්න downtime.
99.99% Availability
වසරකට පැයකට අඩු downtime.
එක extra 9 එකක් add කරන එක paper එකේ පොඩි දෙයක්.
හැබැයි architecture එකේ?
Huge difference.
More redundancy.
More monitoring.
Better failover.
More engineering.
More cost.
Fault Tolerance කියන්නේ මොකක්ද?
දැන් story එක තවත් strict level එකකට යමු.
Fault Tolerance කියන්නේ component එකක් fail වුණත් service එක interruption එකක් නැතුව හෝ practically noticeable interruption එකක් නැතුව continue කරන්න design කරන approach එක.
මෙතන goal එක:
Failure එක absorb කරන එක.
High Availability වලදී:
Failure → Detect → Failover → Continue
Fault Tolerance වලදී ideal concept එක:
Failure → System continues
User කෙනාට almost කිසිම difference එකක් දැනෙන්නේ නැහැ.
Example එකක්
හිතන්න critical financial system එකක් තියෙනවා.
Transaction එකක් process වෙන අතරතුර Server A fail වෙනවා.
High Availability architecture එකක system එක Server B එකට fail over වෙන්න පුළුවන්.
ඒ process එකට short interruption එකක් ඇති වෙන්න පුළුවන්.
හැබැයි Fault-Tolerant architecture එකක් design කරලා තියෙනවා නම් redundant components already active වෙලා තියෙන්න පුළුවන්.
එක component එක fail වුණත් අනෙක් component එක processing එක continue කරනවා.
User කෙනාට:
“Server එකක් just died.”
කියලා දැනෙන්නෙවත් නැහැ.
ඒක තමයි Fault Tolerance වල goal එක.
High Availability vs Fault Tolerance
මතක තියාගන්න ලේසිම විදිහ:
High Availability
Failure එකක් වුණොත් quickly recover වෙනවා.
Small downtime හෝ interruption එකක් accept කරන්න පුළුවන්.
Fault Tolerance
Failure එකක් වුණත් system එක continue වෙනවා.
Service interruption එක minimize කරනවා, ideally userට noticeable නොවෙන තරමට.
එහෙම කියනකොට Fault Tolerance එක තවත් aggressive resilience level එකක්.
Car Example එකක්
මේක real-world example එකකින් බලමු.
හිතන්න long trip එකකට car එකක යනවා.
Tyre එක puncture වෙනවා.
High Availability approach
Car එක නවත්තනවා.
Spare tyre එක දානවා.
විනාඩි 15කින් නැවත ගමන continue කරනවා.
Failure එකක් වුණා.
Downtime එකක් තිබුණා.
හැබැයි quickly recover වුණා.
Fault Tolerance approach
Imagine කරන්න system එකට එක tyre එකක් fail වුණත් vehicle එක stop නොවී continue කරන්න redundant mechanism එකක් තියෙනවා කියලා.
Failure එක absorb වෙනවා.
Journey එක practically interrupt වෙන්නේ නැහැ.
මේක තමයි conceptual difference එක.
High Availability වල common techniques
High Availability build කරන්න Engineers ලා approaches කිහිපයක් use කරනවා.
Multiple Servers
එක server එකක් වෙනුවට instances කිහිපයක්.
Load Balancing
Traffic healthy servers අතර distribute කරනවා.
Multi-AZ Deployment
Infrastructure එක Availability Zones කිහිපයක spread කරනවා.
Database Replication
Primary database එක unavailable වුණොත් replica එකකට failover කරන්න පුළුවන් architecture එකක්.
Health Checks
Resource එක healthy ද unhealthy ද කියලා monitor කරනවා.
Auto Recovery
Failed resource එක replace හෝ restart කරන්න automation use කරනවා.
මේ හැම දෙයකම goal එක එකයි:
Downtime එක හැකි තරම් අඩු කරන්න.
Fault Tolerance වල redundancy තවත් deeper
Fault Tolerance achieve කරන්න redundancy තව strict level එකකට යන්න පුළුවන්.
Multiple active components.
Duplicate power systems.
Duplicate network paths.
Replicated processing.
Synchronous replication.
Hot standby systems.
Real-time state synchronization.
එක component එක නැති වුණත් system එකට immediately continue කරන්න enough redundancy තියෙනවා.
හැබැයි මෙතන problem එකක් තියෙනවා.
Cost.
Fault Tolerance free නෙවෙයි.
Fault Tolerance expensive ඇයි?
Imagine කරන්න Server එකක් එකක් ඕන workload එකකට Servers දෙකක් හෝ ඊට වැඩි ගණනක් continuously run කරනවා.
Database copies කිහිපයක් maintain කරනවා.
Network paths duplicate කරනවා.
Data real-time replicate කරනවා.
Monitoring systems තියෙනවා.
Automatic failover systems තියෙනවා.
Engineers මේ whole architecture එක manage කරනවා.
Cost එක suddenly increase වෙනවා.
ඒ නිසා every application එක Fault-Tolerant කරන්න practical නෑ.
හැම system එකකටම Fault Tolerance ඕනද?
නැහැ.
මේක architecture වල වැදගත්ම lesson එකක්.
හිතන්න personal blog එකක්.
විනාඩි 2ක් down වුණා කියලා millions lose වෙන්නේ නැහැ.
Fault-Tolerant architecture එකකට huge money spend කරන එක unnecessary වෙන්න පුළුවන්.
හැබැයි:
Emergency healthcare system එකක්.
Critical payment infrastructure එකක්.
Air traffic system එකක්.
Mission-critical industrial system එකක්.
වගේ environment එකක් නම් short downtime එකක්වත් serious impact එකක් ඇති කරන්න පුළුවන්.
එතන Fault Tolerance justify වෙන්න පුළුවන්.
Good Architecture කියන්නේ maximum technology use කරන එක නෙවෙයි.
Business impact එකට suitable reliability level එක choose කරන එක.
“More resilient” කියන්නේ “better” ද?
Technically resilience වැඩි වෙනවා.
හැබැයි architecture decision එකක් purely technical නෙවෙයි.
Always trade-offs තියෙනවා.
More Availability
වැඩි cost.
More Redundancy
වැඩි complexity.
More Replication
වැඩි infrastructure.
More Fault Tolerance
වැඩි engineering effort.
ඒ නිසා Engineer කෙනෙක් අහන්න ඕන:
“Business එකට මේ level එකේ reliability අවශ්‍යද?”
Architecture කියන්නේ unlimited budget එකක dream system එකක් draw කරන එක නෙවෙයි.
Architecture කියන්නේ constraints ඇතුළේ හරි balance එක හොයන එක.
High Availability example එකක් AWS context එකෙන්
හිතන්න Application එක AWS Region එකක run කරනවා.
Architecture එක:
Availability Zone A
App Server A
Availability Zone B
App Server B
ඉස්සරහට Load Balancer එකක්.
Database එකත් availability strategy එකක් එක්ක configure කරලා තියෙනවා.
AZ A එකට issue එකක් වුණොත් traffic AZ B එකේ resources වලට shift කරන්න architecture එකට පුළුවන්.
මේක High Availability වල classic idea එකක්.
One failure domain එකකට depend නොවීම.
Single Point of Failure
High Availability ගැන කතා කරනකොට අනිවාර්යයෙන් දැනගන්න ඕන term එකක්:
Single Point of Failure – SPOF
හිතන්න Servers දෙකක් තියෙනවා.
Excellent.
හැබැයි Servers දෙකටම traffic යන්නේ එකම Load Balancer server එකක් හරහා.
ඒ Load Balancer එක fail වුණොත්?
Everything down.
එතකොට Load Balancer එක Single Point of Failure.
Application servers redundant වුණත් whole architecture එක highly available නෑ.
තවත් example එකක්:
App Servers multi-AZ.
හැබැයි Database එක එක machine එකක්.
Database fail.
Application down.
ඒ නිසා resilience design කරනකොට question එක:
“මේ architecture එකේ එක component එකක් නැති වුණොත් whole system එක stop වෙන තැනක් තියෙනවද?”
ඒ තැන තමයි Single Point of Failure.
Redundancy ≠ High Availability automatically
Servers දෙකක් දාපු ගමන් High Availability ලැබෙන්නේ නැහැ.
Failover mechanism එකක් ඕන.
Health checking ඕන.
Network design එක හරි වෙන්න ඕන.
Database layer resilient වෙන්න ඕන.
DNS strategy හරි වෙන්න ඕන.
Application state manage කරන්න ඕන.
Testing කරන්න ඕන.
Redundant components තියෙන එක first step එකක් විතරයි.
Architecture එක failure එක handle කරන්න actually capable වෙන්න ඕන.
High Availability vs Disaster Recovery
මේ දෙකත් confuse කරන්න එපා.
High Availability:
Service එක running තියාගන්න.
Disaster Recovery:
Major disaster එකකින් පස්සේ service එක recover කරන්න.
Example:
Server එකක් fail → High Availability architecture එක handle කරනවා.
Entire Region unavailable → Disaster Recovery strategy එක involve වෙන්න පුළුවන්.
Backup වලින් restore කරනවා.
Secondary Region එකකට switch කරනවා.
Systems rebuild කරනවා.
මේවා DR story එකේ කොටස්.
RTO සහ RPO
Disaster Recovery ගැන ඉස්සරහට deeper ගියොත් terms දෙකක් හම්බවෙනවා.
RTO – Recovery Time Objective
System එක down වුණාට පස්සේ කොච්චර ඉක්මනින් recover වෙන්න ඕනද?
RPO – Recovery Point Objective
කොච්චර data loss එකක් tolerate කරන්න පුළුවන්ද?
උදාහරණයක්:
RPO = 5 minutes.
එහෙනම් disaster එකක් වුණොත් maximum approximately last minutes කිහිපයක data loss එක tolerate කරන්න architecture එක design කරනවා.
මේ requirements business එකෙන් එනවා.
Engineers ඒ requirements architecture එකට translate කරනවා.
Cloud Engineer කෙනෙක් අහන්න ඕන questions
Application එක production යන්න කලින් Engineer කෙනෙක් අහන්න ඕන:
Server එකක් fail වුණොත්?
AZ එකක් fail වුණොත්?
Database එක fail වුණොත්?
Load Balancer fail වුණොත්?
Network path එකක් fail වුණොත්?
Dependency service එක unavailable වුණොත්?
Backup restore කරන්න පුළුවන්ද?
Failover test කරලා තියෙනවද?
Users ලා කොච්චර downtime tolerate කරනවද?
Business එකට minute එකක downtime එකේ cost එක කොච්චරද?
මේ questions තමයි architecture එකේ real quality එක determine කරන්නේ.
Failure Testing කරන්න ඕන
Architecture diagram එකේ arrows දෙකක් draw කරලා:
“Failover works.”
කියන එක enough නෑ.
Actually test කරන්න ඕන.
Server එක intentionally stop කරලා බලන්න.
Instance එකක් remove කරලා බලන්න.
Dependency එක fail simulate කරන්න.
Network problem එකක් simulate කරන්න.
Database failover test කරන්න.
මොකද production incident එකක් අතරතුර first time failover test කරන එක හොඳ idea එකක් නෙවෙයි.
Hope is not a recovery strategy.
Test කරපු architecture එකක් තමයි trust කරන්න පුළුවන්.
Emotional part එක මෙතන
Users ලාට architecture diagram පේන්නේ නැහැ.
ඔවුන්ට Availability Zones ගැන care නැහැ.
Load Balancer ගැන care නැහැ.
Replica ගැන care නැහැ.
ඔවුන්ට එකම දෙයක් වැදගත්.
“මට මේ service එක දැන් use කරන්න පුළුවන්ද?”
Banking App එක open කරන customer කෙනාට backend එකේ Server A fail වුණාද කියලා අදාල නැහැ.
ඔහුට payment එක complete වෙන්න ඕන.
Hospital System එක use කරන doctor කෙනාට Database failover එකේ details දැනගන්න ඕන නැහැ.
System එක available වෙන්න ඕන.
Engineering වල beauty එක මෙතන.
Users ලා කිසිම දෙයක් notice නොකරන එක sometimes Engineer කෙනෙක් කරපු best work එකේ result එක.
මතක තියාගන්න ලේසිම විදිහ
High Availability
“Fall, recover quickly.”
Failure වෙන්න පුළුවන්.
Short interruption එකක් වෙන්න පුළුවන්.
හැබැයි quickly service එක restore වෙනවා.
Fault Tolerance
“Something falls, but the service keeps going.”
Component failure එකක් system එක absorb කරනවා.
Userට interruption එක ideally දැනෙන්නේ නැහැ.
Disaster Recovery
“Big disaster එකකින් පස්සේ කොහොමද නැවත නැගිටින්නේ?”
මේ තුන එකිනෙකට related.
හැබැයි same නෙවෙයි.
අවසානයේ...
Beginner කෙනෙක් Server එකක් create කරලා:
“Running”
කියලා green status එක දැක්කම happy වෙනවා.
ඒක great first step එකක්.
හැබැයි Engineer කෙනෙක් ටිකක් deeper ගියාම අහනවා:
“එක fail වුණොත්?”
තවත් deeper ගියාම:
“AZ එක fail වුණොත්?”
තවත් deeper ගියාම:
“Whole system එකේ weakest point එක මොකක්ද?”
තවත් deeper ගියාම:
“Business එකට කොච්චර downtime tolerate කරන්න පුළුවන්ද?”
එතනින් තමයි infrastructure create කරන කෙනෙක් සහ reliable systems design කරන Engineer කෙනෙක් අතර difference එක පටන් ගන්නේ.
High Availability අපිට කියලා දෙන්නේ failure එකෙන් ඉක්මනින් recover වෙන්න.
Fault Tolerance අපිට කියලා දෙන්නේ failure එක absorb කරගෙන continue වෙන්න.
හැබැයි දෙකම අපිට උගන්වන ලොකු lesson එක එකයි:
Failures are normal.
Great systems කියන්නේ fail නොවන systems නෙවෙයි.
Failure එකක් ආවත් users ලාට service එක continue කරන්න පුළුවන් විදිහට design කරපු systems.
ඒක තමයි Reliability Engineering වල හදවත.
#HighAvailability #FaultTolerance #CloudComputing #SystemReliability #ResilientSystems