HA & Fault Tolerance #
Sistem yang baik bukan sistem yang tidak pernah gagal — sistem yang baik adalah sistem yang tetap berfungsi ketika komponen-komponennya gagal. High Availability (HA) dan Fault Tolerance (FT) adalah dua pendekatan berbeda untuk mencapai tujuan yang sama: sistem yang dapat diandalkan. Memahami perbedaannya membantu kamu memilih pendekatan yang tepat sesuai kebutuhan dan anggaran.
Apa itu High Availability #
High Availability adalah kemampuan sistem untuk tetap beroperasi dalam persentase waktu yang tinggi — biasanya dinyatakan dalam “nines”. Sistem HA dirancang untuk meminimalkan downtime, bukan menghilangkannya sepenuhnya.
Tabel "Nines" Availability:
Availability Downtime per Tahun Downtime per Bulan
─────────────────────────────────────────────────────
99% 3.65 hari 7.2 jam
99.9% 8.7 jam 43.8 menit
99.99% 52.6 menit 4.4 menit
99.999% 5.26 menit 26.3 detik
99.9999% 31.5 detik 2.6 detik
Catatan:
→ 99% terdengar tinggi tapi artinya 3+ hari downtime per tahun
→ Dari 99.9% ke 99.99% butuh arsitektur yang jauh lebih kompleks
→ 99.999% (five nines) adalah standar untuk sistem kritis seperti
telekomunikasi dan perbankan
Sistem HA umumnya dirancang dengan asumsi bahwa kegagalan akan terjadi — dan ketika terjadi, ada mekanisme untuk mendeteksi, merespons, dan memulihkan diri dengan cepat.
Apa itu Fault Tolerance #
Fault Tolerance adalah kemampuan sistem untuk terus beroperasi tanpa gangguan yang terdeteksi oleh pengguna meskipun ada komponen yang gagal. Perbedaan kuncinya dari HA: sistem FT tidak mengalami downtime sama sekali saat terjadi kegagalan komponen.
Perbedaan HA vs FT:
High Availability:
─────────────────
Kegagalan terjadi → Deteksi kegagalan (beberapa detik/menit)
→ Failover ke komponen cadangan
→ Recovery (mungkin ada brief downtime)
Pengguna mungkin merasakan: error singkat, timeout, atau
koneksi terputus selama failover berlangsung
Fault Tolerance:
────────────────
Kegagalan terjadi → Komponen cadangan langsung mengambil alih
(sudah aktif bersamaan, bukan standby)
Pengguna tidak merasakan: tidak ada interruption sama sekali
Contoh FT: RAID-1 (disk mirroring) — jika satu disk rusak,
sistem terus berjalan dari disk kedua tanpa gangguan apapun
Komponen Utama Arsitektur HA #
Membangun sistem HA membutuhkan beberapa komponen yang bekerja bersama. Tidak ada satu komponen tunggal yang bisa menjamin high availability sendiri.
Redundansi #
Setiap komponen kritis harus memiliki setidaknya satu cadangan yang siap mengambil alih.
Redundansi di Berbagai Layer:
Compute:
✓ Minimal 2 instance di minimal 2 AZ berbeda
✓ Auto-scaling group dengan minimum capacity > 1
Database:
✓ Primary + standby replica (Multi-AZ)
✓ Read replica untuk mendistribusikan beban baca
Jaringan:
✓ Load balancer (secara otomatis redundant di managed LB)
✓ Multiple internet connection / ISP
Storage:
✓ Replikasi data ke AZ lain (otomatis di managed storage)
Health Check dan Auto-Healing #
Redundansi saja tidak cukup — sistem harus bisa mendeteksi kegagalan dan merespons secara otomatis.
Alur Health Check:
Load Balancer melakukan health check ke setiap instance
│
├── Instance sehat → trafik diteruskan
│
└── Instance tidak sehat (3 kali gagal health check)
│
├── Load balancer hentikan trafik ke instance ini
│
└── Auto Scaling Group deteksi instance tidak sehat
│
└── Terminate instance → Launch instance baru
Graceful Degradation #
Ketika sebagian sistem gagal, sistem yang dirancang dengan baik tidak mati sepenuhnya — ia beroperasi dengan kapasitas atau fungsi yang berkurang.
// ANTI-PATTERN: Semua fitur atau tidak sama sekali
Jika layanan rekomendasi produk tidak tersedia:
→ Seluruh halaman produk error
→ Pengguna tidak bisa berbelanja sama sekali
// BENAR: Graceful degradation
Jika layanan rekomendasi produk tidak tersedia:
→ Halaman produk tetap tampil
→ Seksi "Rekomendasi untuk Kamu" disembunyikan
→ Pengguna tetap bisa berbelanja, hanya tanpa rekomendasi
Pola Arsitektur HA di Cloud #
Ada beberapa pola yang umum digunakan untuk mencapai high availability di cloud.
Pola 1: Active-Active Multi-AZ
Semua instance aktif menerima trafik secara bersamaan
[Load Balancer]
├── AZ-1a: [Instance A] ← 33% trafik
├── AZ-1b: [Instance B] ← 33% trafik
└── AZ-1c: [Instance C] ← 33% trafik
Kegagalan satu AZ: 2 instance masih melayani 100% trafik
✓ Tidak ada downtime saat failover
✓ Memanfaatkan semua resource yang tersedia
Pola 2: Active-Passive (Primary-Standby)
Satu instance aktif, satu standby menunggu
[Load Balancer]
├── AZ-1a: [Instance A] ← 100% trafik (ACTIVE)
└── AZ-1b: [Instance B] ← tidak menerima trafik (STANDBY)
Kegagalan Instance A: failover ke Instance B
✓ Instance B selalu fresh (tidak terdegradasi karena beban)
✗ Resource standby tidak dimanfaatkan
✗ Ada waktu failover yang diperlukan
Pola 3: Multi-AZ Database dengan Automatic Failover
[Primary DB] ──── sync replikasi ──── [Standby DB]
AZ-1a AZ-1b
Kegagalan Primary DB:
→ Standby otomatis dipromosikan jadi Primary
→ DNS endpoint diupdate (beberapa menit)
→ Aplikasi reconnect ke endpoint baru
Mengukur Kesiapan HA #
Dua metrik utama untuk mengukur efektivitas arsitektur HA adalah RPO dan RTO.
RPO — Recovery Point Objective
"Berapa banyak data yang boleh hilang?"
RPO = 0 → Tidak boleh ada data yang hilang sama sekali
(membutuhkan synchronous replication)
RPO = 1 jam → Boleh kehilangan maksimal data 1 jam terakhir
(backup setiap jam sudah cukup)
RPO = 24 jam → Boleh kehilangan data hingga 1 hari
(backup harian sudah cukup)
RTO — Recovery Time Objective
"Berapa lama waktu recovery yang bisa ditoleransi?"
RTO = 0 → Tidak boleh ada downtime sama sekali
(membutuhkan Fault Tolerance, bukan hanya HA)
RTO = 5 menit → Sistem harus pulih dalam 5 menit
RTO = 4 jam → Sistem boleh mati hingga 4 jam
Hubungan RPO/RTO dengan Biaya:
Makin kecil RPO dan RTO → Makin mahal dan kompleks arsitekturnya
SLA dari cloud provider (misalnya 99.99% uptime untuk suatu layanan) adalah jaminan availability layanan itu sendiri, bukan jaminan availability aplikasi kamu. Aplikasi yang tidak dirancang dengan HA bisa tetap mengalami downtime meski semua layanan cloud yang digunakan memenuhi SLA mereka.
Fault Tolerance vs High Availability — Kapan Memilih #
Pilih High Availability jika:
✓ Downtime singkat (detik hingga beberapa menit) masih bisa
diterima dalam skenario terburuk
✓ Anggaran adalah pertimbangan penting
✓ Aplikasi bisnis umum, e-commerce, SaaS
Pilih Fault Tolerance jika:
✓ Tidak ada toleransi terhadap downtime sama sekali
✓ Setiap detik downtime berarti kerugian signifikan
✓ Sistem kritis: transaksi keuangan real-time, sistem medis,
avionik, infrastruktur kritis
Realita biaya:
HA: 2x resource (redundancy aktif-pasif) atau ~1.5x (aktif-aktif)
FT: Bisa mencapai 2-3x resource dengan overhead sinkronisasi penuh
Ringkasan #
- HA meminimalkan downtime, FT menghilangkannya — HA punya brief downtime saat failover, FT tidak ada interupsi sama sekali.
- “Nines” adalah cara mengukur availability — dari 99% (3.6 hari downtime/tahun) hingga 99.999% (5 menit downtime/tahun). Setiap nine tambahan membutuhkan kompleksitas dan biaya yang jauh lebih besar.
- Redundansi + health check + auto-healing adalah fondasi HA — ketiga komponen ini harus ada bersamaan.
- Graceful degradation membuat sistem lebih resilient — sistem yang bisa beroperasi dengan fungsi terbatas saat sebagian gagal lebih baik dari sistem yang mati total.
- RPO dan RTO adalah bahasa bisnis untuk availability — gunakan keduanya untuk menentukan kebutuhan arsitektur yang tepat.
- SLA provider ≠ availability aplikasimu — arsitektur aplikasi yang buruk bisa membuat downtime meski layanan cloud berjalan normal.
← Sebelumnya: Global Infrastructure Berikutnya: Control Plane vs Data Plane →