Pola desain high availability di AWS menggunakan Multi-AZ, Load Balancer, Auto Scaling, RDS Multi-AZ, S3, Route 53, dan backup.
Di artikel sebelumnya, kita membahas konsep reliability dan high availability. Sekarang kita masuk ke pertanyaan yang lebih praktis:
Bagaimana cara mendesain aplikasi yang highly available di AWS?
High availability bukan satu fitur tunggal. High availability adalah hasil dari beberapa keputusan arsitektur:
Single point of failure adalah satu komponen yang jika gagal akan membuat seluruh sistem berhenti.
Contoh buruk:
User → 1 EC2 Instance → Database di instance yang samaMasalah:
Solusi awal:
User → Load Balancer → beberapa EC2 Instance → Database terpisahAvailability Zone atau AZ adalah lokasi data center yang terpisah dalam satu Region AWS.
Jika aplikasi hanya berjalan di satu AZ, gangguan di AZ tersebut bisa berdampak besar.
Pola yang lebih baik:
Region
├── AZ A: EC2 Instance A
└── AZ B: EC2 Instance BDengan Multi-AZ, aplikasi tetap bisa berjalan jika satu AZ mengalami masalah.
Load balancer membagi traffic ke beberapa target yang sehat.
Contoh alur:
Users → Application Load Balancer → EC2 Instance A/B/CManfaat:
Jenis load balancer umum:
| Jenis | Cocok untuk |
|---|---|
| Application Load Balancer | HTTP/HTTPS application traffic |
| Network Load Balancer | Traffic TCP/UDP dengan performa tinggi |
| Gateway Load Balancer | Integrasi appliance network/security |
Untuk pemula, biasanya Application Load Balancer paling sering dipakai untuk aplikasi web.
Auto Scaling membantu menambah atau mengurangi kapasitas secara otomatis.
Contoh:
Pola:
graph TD
User[Users] --> ALB[Application Load Balancer]
ALB --> ASG[Auto Scaling Group]
ASG --> EC2A[EC2 - AZ A]
ASG --> EC2B[EC2 - AZ B]Manfaat:
Database sering menjadi komponen paling kritis.
Untuk aplikasi relational, kamu bisa menggunakan Amazon RDS Multi-AZ.
Konsepnya:
Primary DB di AZ A → Standby DB di AZ BJika primary bermasalah, RDS dapat melakukan failover ke standby.
Manfaat:
Catatan: Multi-AZ bukan fitur untuk read scaling utama. Untuk read scaling, kamu bisa mempertimbangkan read replica sesuai kebutuhan.
Jangan menyimpan file penting hanya di disk lokal EC2.
Jika EC2 diganti atau mati, data lokal bisa hilang.
Gunakan Amazon S3 untuk menyimpan object seperti:
Manfaat S3:
High availability membantu sistem tetap berjalan, tetapi backup tetap penting.
Backup melindungi dari:
Contoh AWS:
Jangan hanya membuat backup. Lakukan juga restore test.
Sistem highly available tetap butuh monitoring.
Gunakan Amazon CloudWatch untuk memantau:
Tanpa monitoring, kamu mungkin baru tahu sistem bermasalah setelah user komplain.
graph TD
User[Users] --> R53[Amazon Route 53]
R53 --> CF[Amazon CloudFront]
CF --> ALB[Application Load Balancer]
ALB --> EC2A[EC2 Instance - AZ A]
ALB --> EC2B[EC2 Instance - AZ B]
EC2A --> RDS[(RDS Primary/Standby Multi-AZ)]
EC2B --> RDS
EC2A --> S3[Amazon S3]
EC2B --> S3
RDS --> Backup[AWS Backup / Automated Backups]
CW[Amazon CloudWatch] --> ALB
CW --> EC2A
CW --> EC2B
CW --> RDSKomponen:
| Komponen | Fungsi |
|---|---|
| Route 53 | DNS dan routing |
| CloudFront | Cache konten dekat user |
| Application Load Balancer | Membagi traffic ke instance sehat |
| Auto Scaling Group | Menambah/mengurangi instance otomatis |
| EC2 Multi-AZ | Mengurangi risiko single AZ failure |
| RDS Multi-AZ | Failover database |
| S3 | Object storage durable |
| AWS Backup | Backup terpusat |
| CloudWatch | Monitoring dan alarm |
High availability di AWS dibangun dari kombinasi beberapa pola:
Tujuannya bukan membuat sistem mustahil gagal. Tujuannya adalah membuat sistem tetap bisa melayani user walaupun sebagian komponennya bermasalah.