AWS Regions සහ Availability Zones – Cloud එක Down නොවී තියාගන්නේ කොහොමද?
හිතන්න…
ඔයා මාස ගණනක් මහන්සි වෙලා Application එකක් build කළා.
Customers ලා use කරනවා.
Orders එනවා.
Payments process වෙනවා.
Business එක smoothly run වෙනවා.
එක දවසක…
Application එක run වෙන Data Center එකට problem එකක් එනවා.
Power failure එකක් වෙන්න පුළුවන්.
Network failure එකක් වෙන්න පුළුවන්.
Hardware issue එකක් වෙන්න පුළුවන්.
Natural disaster එකක් වෙන්නත් පුළුවන්.
එතකොට…
මුළු Application එකම down ද?
Cloud Architecture ගැන serious විදිහට හිතන්න පටන් ගන්නේ මෙතනින්.
AWS මේ problem එක handle කරන්න තමන්ගේ Global Infrastructure එක ප්‍රධාන concepts දෙකක් වටා organize කරනවා:
Regions
සහ
Availability Zones – AZs
මේ දෙක හරියට තේරුම්ගත්තොත් Cloud Architecture වල ලොකු කොටසක් suddenly clear වෙන්න පටන් ගන්නවා.
AWS Region කියන්නේ මොකක්ද?
සරලව කියනවා නම්,
AWS Region කියන්නේ AWS Infrastructure තියෙන වෙනම geographic area එකක්.
උදාහරණ විදිහට:
US East (N. Virginia)
Europe (Ireland)
Asia Pacific (Singapore)
Asia Pacific (Mumbai)
Asia Pacific (Sydney)
AWS official documentation අනුව, AWS Region එකක් අනෙක් Regions වලින් isolate වෙන්න design කරලා තියෙන geographic area එකක්.
Region එකකට unique code එකක් තියෙනවා.
උදාහරණ:
Singapore → **ap-southeast-1**
Mumbai → **ap-south-1**
Sydney → **ap-southeast-2**
N. Virginia → **us-east-1**
AWS Console එකේ resource එකක් create කරනකොට ඉහළ පැත්තේ Region selector එකක් දැකලා ඇති.
ඒක decoration එකක් නෙවෙයි.
ඔයා select කරන Region එක…
ඔයාගේ architecture එකට impact කරන්න පුළුවන්.
Region එකක් choose කරන එක වැදගත් ඇයි?
හිතන්න ඔයාගේ Application එකේ users ලා බහුතරයක් Asia වල කියලා.
Application එක ඔවුන්ගෙන් geographically ගොඩක් ඈත Region එකක run කළොත් network latency වැඩි වෙන්න පුළුවන්.
User request එක දිග distance එකක් travel කරන්න වෙනවා.
ඒ නිසා Region select කරනකොට AWS විසින් consider කරන්න කියන factors අතර users ලාට geographical proximity, required AWS services/features සහ legal/compliance requirements වගේ දේවල් තියෙනවා.
සරලව:
Region selection = “Server එක කොහෙද දාන්නේ?” කියන decision එක විතරක් නෙවෙයි.
ඒක:
Performance decision එකක්.
Compliance decision එකක්.
Cost decision එකක්.
Availability decision එකක්.
Architecture decision එකක්.
එහෙනම් Availability Zone කියන්නේ මොකක්ද?
දැන් තමයි මේ story එක interesting වෙන්නේ.
Region එකක් කියන්නේ එකම Data Center එකක් නෙවෙයි.
Region එක ඇතුළේ Availability Zones කියලා independently operated infrastructure locations තියෙනවා.
AWS අනුව Availability Zone එකක් කියන්නේ එකක් හෝ කිහිපයක් වූ discrete Data Centers වලින් සමන්විත location එකක්. ඒවා redundant power, networking සහ connectivity සමඟ design කරලා තියෙනවා.
සරලව හිතමු.
Region
↓
Availability Zone A
Availability Zone B
Availability Zone C
AWS documentation අනුව සෑම Region එකකම අවම වශයෙන් Availability Zones තුනක් තියෙනවා.
Example එකක්
හිතන්න Region එක:
us-east-2
ඒ Region එක ඇතුළේ Availability Zones මේ වගේ names වලින් පේන්න පුළුවන්:
us-east-2a
us-east-2b
us-east-2c
මෙතන:
us-east-2 → Region
අන්තිමට තියෙන:
a
b
c
→ Availability Zone labels
සරලයි.
හැබැයි මේ simple naming එක පිටිපස්සේ තියෙන Architecture idea එක ගොඩක් powerful.
Availability Zones වෙන වෙනම තියෙන්නේ ඇයි?
හිතන්න AWS එක Region එකක එකම massive Data Center එකක් විතරක් build කළා කියලා.
ඒ Data Center එකේ power issue එකක් වුණොත්?
Everything down.
Network problem එකක් වුණොත්?
Everything down.
Fire එකක් වුණොත්?
Everything down.
ඒක dangerous architecture එකක්.
ඒ නිසා AWS Availability Zones physically separated facilities ලෙස design කරන අතර, ඒවා independent power, cooling සහ physical security වලින් support කරනවා. ඒ අතර low-latency, high-bandwidth, redundant networking connections තියෙනවා.
මෙතන key word එක:
Isolation
එක Availability Zone එකේ problem එකක් වුණොත් අනෙක් Availability Zone එක automatically ඒ same physical failure එක share නොකරන විදිහට architecture එක design කරලා තියෙනවා.
මේ idea එක තමයි High Availability වල foundation එකක්.
එක AZ එකක Application එක දාමු
හිතන්න E-commerce Application එකක් තියෙනවා.
ඔයා EC2 Servers තුනක් create කරනවා.
හැබැයි Servers තුනම:
Availability Zone A
එකේ තියෙනවා.
Looks good.
Servers තුනක් තියෙනවා.
Redundancy තියෙනවා වගේ පේනවා.
හැබැයි…
AZ A එකට major failure එකක් වුණොත්?
Servers තුනම potentially unavailable වෙන්න පුළුවන්.
AWS documentation එකත් single Availability Zone එකක සියලු EC2 instances තියෙන architecture එකක් ඒ AZ එකට failure එකක් ආවොත් unavailable වෙන්න පුළුවන් කියලා පැහැදිලි කරනවා.
එතකොට අපි Servers තුනක් තිබුණත්…
Real resilience එකක් නැහැ.
Better Architecture එක
දැන් Application එක මේ විදිහට design කරමු.
Availability Zone A
Application Server 1
Application Server 2
Availability Zone B
Application Server 3
Application Server 4
ඉස්සරහට Load Balancer එකක් තියෙනවා.
Users ලගේ traffic healthy servers වලට distribute කරනවා.
දැන් AZ A එකට issue එකක් වුණොත්…
AZ B එකේ application instances තවම run වෙනවා.
Users ලාට service එක continue කරන්න architecture එක design කරන්න පුළුවන්.
මේකට අපි කියනවා:
Multi-AZ Architecture
AWS විසින් production applications Availability Zones කිහිපයක deploy කිරීම best practice එකක් ලෙස recommend කරනවා.
මේක තමයි High Availability
High Availability කියන්නේ:
“System එක කවදාවත් fail වෙන්නේ නැහැ”
කියන එක නෙවෙයි.
Technology world එකේ failures happen.
Hardware fail වෙනවා.
Networks fail වෙනවා.
Software fail වෙනවා.
People mistakes කරනවා.
Real Engineering mindset එක:
“Failure එකක් වුණාම system එක continue කරන්නේ කොහොමද?”
කියන එක.
ඒ නිසා good Cloud Architecture එක failure avoid කරන්න විතරක් try කරන්නේ නැහැ.
Failure expect කරනවා.
ඊට පස්සේ survive කරන්න design කරනවා.
Region සහ Availability Zone අතර වෙනස
මේක මතක තියාගන්න ලේසිම විදිහ:
Region
Large Geographic Area
උදාහරණයක්:
Singapore.
Sydney.
Mumbai.
Ireland.
Availability Zone
Region එකක් ඇතුළේ isolated infrastructure location එකක්.
Region එකක් ඇතුළේ AZ කිහිපයක් තියෙනවා.
ඒ AZs high-bandwidth, low-latency networking හරහා interconnected.
Simple hierarchy එක:
AWS Global Infrastructure
↓
Region
↓
Availability Zones
↓
Data Centers
↓
Physical Servers
↓
Virtual Machines / Cloud Services
මේ chain එක imagine කරන්න.
එතකොට Cloud එක suddenly abstract දෙයක් වගේ පේන්නේ නැහැ.
Region එකක්ම fail වුණොත්?
දැන් තවත් deeper question එකක්.
Multi-AZ architecture එකෙන් එක AZ failure එකකට protect වෙන්න පුළුවන්.
හැබැයි entire Region එකකට serious disruption එකක් ආවොත්?
එතකොට සමහර critical systems වල Multi-Region Architecture ගැන හිතන්න වෙනවා.
Example:
Primary Region → Singapore
Secondary Region → Sydney
Application හෝ data දෙවැනි Region එකකට replicate කරන්න පුළුවන්.
Primary Region unavailable වුණොත් recovery strategy එක අනුව secondary Region එක use කරන්න පුළුවන්.
මේක Multi-AZ වලට වඩා complicated.
Cost වැඩි.
Data replication complicated.
Networking complicated.
Consistency challenges තියෙනවා.
හැබැයි extremely critical systems වල මේ trade-offs consider කරනවා.
AWS Regions එකිනෙක isolate වෙන්න design කරලා තියෙන අතර resources automatically වෙනත් Region එකකට replicate නොවන services ගොඩක් තියෙන නිසා cross-Region architecture එක consciously design කරන්න වෙනවා.
Multi-AZ සහ Multi-Region එකම දේ නෙවෙයි
මේ දෙක confuse කරන්න එපා.
Multi-AZ
එක Region එකක්.
Availability Zones කිහිපයක්.
Goal:
High Availability
Multi-Region
Different geographic Regions.
Goal එක use case අනුව:
Disaster Recovery
Global Reach
Latency Reduction
Regulatory Requirements
වගේ දේවල් වෙන්න පුළුවන්.
Availability Zone එක Data Center එකක්මද?
Always one Data Center කියලා කියන්න බෑ.
AWS අනුව Availability Zone එකක් one or more discrete Data Centers වලින් සමන්විත වෙන්න පුළුවන්.
මේ distinction එක වැදගත්.
ඒ නිසා:
Region = Data Center
කියන එකත් වැරදියි.
AZ = always exactly one Data Center
කියන එකත් වැරදියි.
Correct mental model එක:
Region → Multiple Availability Zones → Each AZ may contain one or more Data Centers
Database එකකටත් මේ concept එක වැදගත්
Servers විතරක් Multi-AZ කරලා වැඩක් නැහැ.
හිතන්න:
Application Servers AZ A සහ AZ B වල.
හැබැයි Database එක AZ A එකේ විතරයි.
AZ A down.
Application Server AZ B එකේ still alive.
හැබැයි database unavailable.
Application එක practically වැඩ කරන්නේ නැහැ.
මේ නිසා resilient architecture එකක් design කරනකොට compute විතරක් නෙවෙයි:
Database
Storage
Networking
Load Balancing
Backups
Dependencies
හැම layer එකක් ගැනම හිතන්න වෙනවා.
System එක strong වෙන්නේ weakest dependency එක තරමට.
Cloud Engineer කෙනෙක්ට Region සහ AZ දැනගන්න ඕන ඇයි?
AWS Console එකේ Region select කරන්න ඕන කියලා දැනගෙන හිටියට enough නෑ.
Engineer කෙනෙක්ට අහන්න ඕන:
Users ලා කොහෙද?
Latency requirement එක මොකක්ද?
Data residency requirement තියෙනවද?
Required AWS service එක මේ Region එකේ available ද?
Application එක single AZ ද?
Multi-AZ ද?
AZ එකක් fail වුණොත් මොකද වෙන්නේ?
Region එකක් unavailable වුණොත් recovery plan එක මොකක්ද?
Backup එක කොහෙද?
Database failover එක කොහොමද?
මේ questions අහන්න පටන් ගන්න moment එකේ…
ඔයා resource create කරන කෙනෙක්ගෙන්,
Architecture ගැන හිතන Engineer කෙනෙක් වෙන්න පටන් ගන්නවා.
“Server එකක් run වෙනවා” කියන එක enough නෑ
Beginner stage එකේ අපි happy වෙනවා:
“EC2 instance එක running!”
Great.
හැබැයි production world එකේ next questions එනවා:
Tomorrow ඒ server එක fail වුණොත්?
AZ එක fail වුණොත්?
Database එක unavailable වුණොත්?
Traffic suddenly double වුණොත්?
Region issue එකක් වුණොත්?
Good architecture කියන්නේ happy path එක ගැන විතරක් හිතන එක නෙවෙයි.
Bad day එක ගැනත් කලින් හිතන එක.
ඒක තමයි reliability engineering.
Simple Architecture එකක් imagine කරන්න
Users
↓
Application Load Balancer
↓
↙ ↘
AZ A AZ B
App Server App Server
App Server App Server
↘ ↙
Multi-AZ Database
මෙතන එක AZ එකක් fail වුණත් application service එක continue කරන්න architecture එක design කරන්න පුළුවන්.
මේ simple diagram එක පිටිපස්සේ තියෙන idea එක:
Don’t put everything in one place.
අපේ ජීවිතේ example එකක්
ඔයාගේ වැදගත් documents හැම එකම එකම laptop එකේ තියෙනවා කියලා හිතන්න.
Backup නෑ.
Laptop එක damage වුණා.
Everything gone.
ඒත් copy එකක් external drive එකක තියෙනවා නම්?
තව safe.
Cloud Architecture එකත් ඒ වගේ.
එක server එකක්.
එක rack එකක්.
එක Data Center එකක්.
එක Availability Zone එකක්.
එක Region එකක්.
මේ හැම level එකකම question එක එකමයි:
“මේ එක thing එක නැති වුණොත් මොකද වෙන්නේ?”
මේ question එකට හොඳ answer එකක් තියෙන architecture එක තමයි resilient architecture එකක්.
මතක තියාගන්න ලේසිම විදිහ
Region
AWS Infrastructure තියෙන geographic area එක.
Availability Zone
Region එකක් ඇතුළේ isolated infrastructure location එකක්.
Multi-AZ
එක AZ එකක් fail වුණත් application එක continue කරන්න AZ කිහිපයක් use කරන architecture approach එකක්.
Multi-Region
Different Regions use කරලා disaster recovery, global reach හෝ වෙන business requirements support කරන architecture approach එකක්.
අවසානයේ...
Cloud එකේ ලස්සනම දේ Server එකක් seconds කිහිපයකින් create කරන්න පුළුවන් එක විතරක් නෙවෙයි.
ලස්සනම දේ තමයි…
Failure එකක් වෙනවා කියලා දැනගෙනත්, ඒ failure එකෙන් survive වෙන්න system එක design කරන්න පුළුවන් එක.
Availability Zone එකක් down වෙන්න පුළුවන්.
Server එකක් crash වෙන්න පුළුවන්.
Network එකකට issue එකක් එන්න පුළුවන්.
Database එක fail වෙන්න පුළුවන්.
Real Engineering කියන්නේ:
“Nothing will ever fail.”
කියලා hope කරන එක නෙවෙයි.
Real Engineering කියන්නේ:
“Something will eventually fail. When it does, are we ready?”
කියලා අහන එක.
AWS Regions සහ Availability Zones තේරුම්ගන්න එකෙන් අපි ඉගෙනගන්නේ Cloud terminology දෙකක් විතරක් නෙවෙයි.
අපි ඉගෙනගන්නේ Engineering mindset එකක්.
Design for Failure.
එක Server එකකට depend වෙන්න එපා.
එක Availability Zone එකකට depend වෙන්න එපා.
Critical system එකක් නම් එක Region එකකට depend වෙන risk එකත් understand කරන්න.
Infrastructure build කරන්න පුළුවන් ඕනම කෙනෙක්ට.
හැබැයි failure එකක් ආවත් users ලාට service එක continue වෙන infrastructure එකක් design කරන එක තමයි real Cloud Engineering.
ඊළඟ ලිපියෙන් අපි බලමු:
“High Availability සහ Fault Tolerance කියන්නේ එකම දේද?”
Application එකක් “highly available” කියනකොට ඇත්තටම ඒකෙන් අදහස් කරන්නේ මොකක්ද කියලා එතනින් ගැඹුරින් තේරුම් ගමු.
#AWS #AWSRegions #AvailabilityZones #CloudComputing #CloudArchitecture
