Belajar Cloud Architect - Reliability & Resilience Design
Reliability tidak datang dari satu komponen yang sempurna, melainkan dari desain yang menahan kegagalan. Episode ini membahas fault tolerance, high availability, pola disaster recovery dengan RTO/RPO, dan error budget ala SRE untuk mengukur seberapa andal arsitektur seharusnya
#Pendahuluan
Di episode 7 kita mengamankan arsitektur; sekarang kita pastikan ia tetap berjalan. Reliability adalah pillar yang paling sering dijanjikan tapi paling jarang didefinisikan: apa artinya "andalkan"? 99%? 99.9%? Jawabannya harus dihitung dari kebutuhan bisnis, bukan dari marketing provider.
Prinsip paling penting di episode ini: kegagalan bukan pengecualian, melainkan fakta. Disks rusak, AZ down, network terputus, code punya bug. Arsitektur yang reliable adalah arsitektur yang mengasumsikan semua ini akan terjadi dan tetap bekerja. Itu alasan mengapa reliability adalah desain, bukan harapan.
#Fault Tolerance vs High Availability
Dua konsep yang sering tertukar:
| Konsep | Arti | Contoh |
|---|---|---|
| Fault tolerance | Sistem tetap berfungsi tanpa gangguan saat komponen gagal | Active-active, dua node memproses paralel |
| High availability | Sistem tersedia dengan downtime sangat kecil saat kegagalan | Active-passive, failover otomatis dalam detik |
Perbedaan praktisnya soal waktu pemulihan. Fault tolerance nyaris tanpa jeda; HA menerima jeda singkat. Keduanya dibangun di atas prinsip yang sama: redundansi + deteksi + failover.
#Redundansi: Menghilangkan Single Point of Failure
Setiap komponen yang jika gagal melumpuhkan sistem adalah single point of failure (SPOF). Arsitektur reliable memeriksanya lapis demi lapis:
- Compute: minimal 2 instance di 2 AZ di belakang load balancer.
- Data: database multi-AZ dengan standby, atau managed service dengan replika.
- Network: load balancer cross-AZ, DNS dengan multiple IP.
- Geographic: region kedua untuk DR (episode 15).
#Pola Disaster Recovery
Saat bencana skala besar terjadi (region down), HA di satu region tidak cukup. Disaster Recovery (DR) menjawab pertanyaan ini dengan dua angka:
- RTO (Recovery Time Objective) — berapa lama sistem harus pulih setelah bencana.
- RPO (Recovery Point Objective) — berapa banyak data yang boleh hilang.
| Pola DR | RTO | RPO | Biaya | Kompleksitas |
|---|---|---|---|---|
| Backup & restore | Jam–hari | 24 jam+ | Rendah | Rendah |
| Pilot light | Menit–jam | Menit | Sedang | Sedang |
| Warm standby | Menit | Detik | Sedang–tinggi | Sedang |
| Multi-site active-active | Detik | Nol | Tinggi | Tinggi |
#Backup & Restore
Paling murah: backup data ke region lain secara berkala. Saat bencana, rebuild dari backup. RTO bisa berjam-jam karena harus re-deploy + restore.
#Pilot Light
Region kedua hanya menjalankan inti minimal (database replika, networking siap). Saat bencana, "nyalakan" compute di region kedua. Lebih cepat dari backup karena fondasinya sudah ada.
#Warm Standby
Region kedua menjalankan full stack dalam skala kecil, siap diperbesar. Failover lebih cepat, tapi biaya terus berjalan.
#Multi-Site Active-Active
Kedua region melayani traffic nyata secara paralel. RTO/RPO mendekati nol, tetapi kompleksitas tinggi — topik penuh episode 15 (multi-region).
#Error Budget: Menghubungkan Reliability dan Bisnis
#Berapa "Cukup Andal"?
Menghabiskan uang untuk reliability 99.999% padahal bisnis hanya butuh 99.9% adalah pemborosan. Konsep error budget dari Google SRE menjawabnya: tentukan SLO (target reliability), hitung 100% - SLO = budget kegagalan yang boleh terjadi.
| SLO | Downtime yang Diizinkan/Tahun | Arti |
|---|---|---|
| 99.0% | ~3.65 hari | Bisnis toleran |
| 99.9% | ~8.76 jam | Standar production |
| 99.99% | ~52.6 menit | Kritis, mahal |
| 99.999% | ~5.26 menit | Sangat kritis, sangat mahal |
Error budget mengubah cara tim bekerja: selama budget belum habis, tim boleh rilis fitur; jika budget habis, prioritas berpindah ke reliability. Ini bukan sekadar angka — ini mekanisme pengambilan keputusan yang menghubungkan bisnis dan engineering.
Warning
Kesalahan umum: menargetkan SLO 99.99% tanpa menghitung biayanya. Setiap "9" tambahan menambah biaya infrastruktur, kompleksitas, dan beban operasional secara eksponensial. Hitung dulu nilai bisnis dari setiap 9 tambahan — sering kali 99.9% adalah titik optimal.
#Fail-Safe Design: Praktik Membangun yang Tidak Jatuh
Desain fail-safe berarti mengasumsikan kegagalan dan membatasi dampaknya:
- Timeouts dan retries dengan backoff — dependency yang lambat tidak boleh menggantung seluruh request.
- Circuit breaker — dependency yang rusak di-open circuit, aplikasi jatuh cepat alih-alih menunggu.
- Bulkhead (isolation) — satu service yang overload tidak boleh menghabiskan resource service lain.
- Degradation — fitur non-kritis bisa dimatikan saat beban ekstrem, yang kritis tetap jalan.
- Idempotency — operasi bisa diulang tanpa efek ganda (kunci untuk retry).
Pattern ini mengubah sistem dari "jatuh total saat ada masalah" menjadi "menurun anggun dan pulih cepat". Ini adalah ciri arsitektur yang dikerjakan dengan benar.
#Penutup
Inti yang harus dibawa pulang:
- Reliability adalah desain yang mengasumsikan kegagalan, bukan harapan.
- HA = downtime kecil; fault tolerance = tanpa gangguan; keduanya butuh redundansi.
- DR dibangun di atas RTO/RPO: pilih pola dari backup hingga active-active sesuai kebutuhan.
- Error budget menghubungkan reliability dengan keputusan bisnis.
- Fail-safe: timeouts, retries, circuit breaker, bulkhead, idempotency.
Di episode 9 selanjutnya kita akan membahas cost architecture & FinOps — cost modeling, tagging, savings plan, dan trade-off biaya dalam desain arsitektur. Sampai jumpa di episode 9!