High Availability Architecture Patterns on AWS

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:

• tidak bergantung pada satu server,
• menyebarkan workload ke lebih dari satu Availability Zone,
• menggunakan load balancer,
• menyiapkan backup,
• menggunakan database yang punya failover,
• dan melakukan monitoring.

Pattern 1: Hindari single point of failure

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 sama

Masalah:

• kalau EC2 mati, website mati,
• database juga ikut mati,
• tidak ada failover,
• maintenance sulit dilakukan tanpa downtime.

Solusi awal:

User → Load Balancer → beberapa EC2 Instance → Database terpisah

Pattern 2: Gunakan lebih dari satu Availability Zone

Availability 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 B

Dengan Multi-AZ, aplikasi tetap bisa berjalan jika satu AZ mengalami masalah.

Pattern 3: Gunakan Elastic Load Balancing

Load balancer membagi traffic ke beberapa target yang sehat.

Contoh alur:

Users → Application Load Balancer → EC2 Instance A/B/C

Manfaat:

• traffic tidak menumpuk di satu server,
• instance yang unhealthy tidak lagi menerima traffic,
• scaling lebih mudah,
• cocok untuk arsitektur Multi-AZ.

Jenis load balancer umum:

Untuk pemula, biasanya Application Load Balancer paling sering dipakai untuk aplikasi web.

Pattern 4: Gunakan Auto Scaling

Auto Scaling membantu menambah atau mengurangi kapasitas secara otomatis.

Contoh:

• saat traffic naik, EC2 instance bertambah,
• saat traffic turun, EC2 instance berkurang,
• jika instance unhealthy, Auto Scaling bisa menggantinya.

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:

• mengurangi downtime,
• mengurangi biaya saat traffic rendah,
• membantu sistem beradaptasi dengan demand.

Pattern 5: Gunakan database yang mendukung failover

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 B

Jika primary bermasalah, RDS dapat melakukan failover ke standby.

Manfaat:

• database lebih tahan gangguan,
• maintenance lebih aman,
• recovery lebih cepat.

Catatan: Multi-AZ bukan fitur untuk read scaling utama. Untuk read scaling, kamu bisa mempertimbangkan read replica sesuai kebutuhan.

Pattern 6: Gunakan Amazon S3 untuk object storage

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:

• gambar produk,
• file upload user,
• backup export,
• static assets,
• log tertentu.

Manfaat S3:

• durable,
• scalable,
• cocok untuk object storage,
• bisa dikombinasikan dengan versioning dan lifecycle policy.

Pattern 7: Backup dan snapshot

High availability membantu sistem tetap berjalan, tetapi backup tetap penting.

Backup melindungi dari:

• accidental deletion,
• data corruption,
• kesalahan deployment,
• ransomware,
• kebutuhan restore point-in-time.

Contoh AWS:

• EBS Snapshot untuk volume EBS.
• Automated backup di Amazon RDS.
• AWS Backup untuk pengelolaan backup terpusat.
• S3 Versioning untuk object.

Jangan hanya membuat backup. Lakukan juga restore test.

Pattern 8: Monitoring dan alerting

Sistem highly available tetap butuh monitoring.

Gunakan Amazon CloudWatch untuk memantau:

• CPU usage,
• memory usage jika custom metric dikirim,
• request count,
• latency,
• error rate,
• database connection,
• disk usage,
• alarm status.

Tanpa monitoring, kamu mungkin baru tahu sistem bermasalah setelah user komplain.

Contoh arsitektur final

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 --> RDS

Komponen:

Kesimpulan

High availability di AWS dibangun dari kombinasi beberapa pola:

• hindari single point of failure,
• gunakan Multi-AZ,
• gunakan load balancer,
• gunakan Auto Scaling,
• gunakan database dengan failover,
• simpan file penting di storage durable,
• buat backup dan uji restore,
• monitor sistem secara aktif.

Tujuannya bukan membuat sistem mustahil gagal. Tujuannya adalah membuat sistem tetap bisa melayani user walaupun sebagian komponennya bermasalah.