Belajar Infrastructure Engineer - High Availability & Scaling

#Pendahuluan

Setelah di episode 20 kita menyiapkan respons saat incident, kini kita berusaha membuat incident tidak terjadi: high availability & scaling. Infrastruktur yang selalu tersedia dan bisa tumbuh tidak terjadi kebetulan — ia dirancang dengan redundancy di setiap lapisan dan mekanisme scaling yang terukur.

Mengapa topik ini penting? Karena ketersediaan adalah kontrak yang bisa dihitung, bukan harapan. Sembilan sembilan (99.9%) bukan sekadar slogan pemasaran — ia angka yang menuntut desain tertentu. Episode ini membangun cara berpikir HA: redundancy, failure domain, auto-scaling, dan failover — dengan perhitungan yang realistis.

#Menghitung Ketersediaan

#Sembilan Sembilan (Nines)

Angka-angka ini menjadi SLA (Service Level Agreement) — dan SLA menuntut desain. Untuk downtime kurang dari 1 jam per tahun, kalian tidak bisa bergantung pada satu komponen apa pun.

#Komponen dalam Rangkaian

Aturan penting: ketersediaan sistem = perkalian ketersediaan komponen yang saling bergantung.

Load balancer  : 99.9%  (0.999)
Web server     : 99.9%  (0.999)
Database       : 99.5%  (0.995)
 
Total = 0.999 × 0.999 × 0.995 = 0.993 ≈ 99.3%

Tiga komponen "bagus" ternyata menghasilkan 99.3% — hampir 2 hari downtime per tahun! Ini pelajaran penting: setiap komponen dalam rangkaian menurunkan total. Untuk mencapai 99.9% end-to-end, tiap komponen harus jauh di atasnya — atau komponen yang lemah dibuat redundant.

#Redundansi Paralel

Dua komponen paralel (salah satu hidup, sistem hidup):

P(sistem gagal) = P(A gagal) × P(B gagal)
Dengan A dan B masing-masing 99%: 0.01 × 0.01 = 0.0001 → 99.99%

Mendobelkan komponen mengubah ketersediaan dari 99% menjadi 99.99% — ini alasan dasar mengapa HA = redundancy.

#Redundancy di Setiap Lapisan

#Lapisan Compute

• Dua+ instance di dua AZ/region berbeda (episode 12).
• Auto-healing: instance yang mati otomatis diganti (health check + replacement).

#Lapisan Network

• Dua switch, dua uplink — switch yang sama untuk semuanya adalah single point of failure.
• Dua load balancer (active-passive atau active-active).
• DNS di dua penyedia/resolver — jangan gantungkan resolusi pada satu pihak.

#Lapisan Data

• Replika database — read replica untuk beban baca, failover untuk ketersediaan.
• Multi-AZ managed database — failover otomatis oleh vendor.
• Data terdistribusi — Ceph/Object storage dengan replikasi (episode 4).

#Pola Standar Arsitektur HA

Perhatikan pola two of everything: DNS ganda, LB ganda, banyak web di banyak AZ, database multi-AZ. Tidak ada satu komponen pun yang menjadi penentu tunggal.

#Auto-Scaling

Auto-scaling menambah/mengurangi kapasitas berdasarkan metrik terukur, bukan prediksi.

#Horizontal vs Vertikal

Aturan: horizontal untuk stateless (web, API), vertikal untuk stateful (database) hingga batas tertentu.

#Pola Scaling Berbasis Metrik

Skala naik  : CPU > 70% selama 5 menit → +2 instance
Skala turun : CPU < 30% selama 15 menit → -1 instance
Maksimum    : 10 instance (safety cap)
Minimum     : 2 instance (jangan pernah 1)

Dua aturan yang sering dilanggar:

1. Cooldown: jangan naik-turun cepat (flapping) — beri jeda antar keputusan.
2. Safety cap: batas maksimum mencegah "tagihan tak terkendali saat traffic membludak".

#Scaling Khusus: Queue dan Database

• Queue depth: jumlah antrian pesan (episode 15) adalah sinyal scaling terbaik untuk worker — CPU bisa rendah tapi queue menumpuk.
• Database: bukan auto-scaling murahan — gunakan read replica untuk baca, dan partition untuk skala besar. Database tidak boleh "auto-scale gegabah".

#Desain Failover

Failover adalah perpindahan otomatis ke komponen cadangan saat yang utama gagal. Tiga pola:

#Active-Passive

Satu aktif, satu standby menunggu. Sederhana, tapi standby menganggur (biaya) dan failover butuh waktu (deteksi + cutover).

#Active-Active

Semua instance aktif melayani. Utilisasi tinggi, failover instan, tetapi butuh aplikasi yang mendukung multi-node (stateless, atau state terdistribusi).

#Failover Database

Pola paling sensitif: database failover memindahkan sumber kebenaran.

Primary (AZ a) + Replica (AZ b) + Replication berkelanjutan
Primary gagal → promote replica → aplikasi diarahkan ke yang baru
Hal yang wajib diuji : seberapa cepat? RPO berapa? Aplikasi reconnect?

#Common Pitfalls HA & Scaling

• HA di atas kertas saja: arsitektur digambar redundan, tapi failover tidak pernah diuji.
• Scaling berdasarkan tebakan: tidak ada metrik, tidak ada auto-scaling — atau sebaliknya, scaling yang terlalu agresif sampai flapping.
• Lupa skala stateless dulu: menambah database sebelum menambah web adalah menyembuhkan salah satu tempat.
• Active-passive tanpa monitoring standby: standby ternyata rusak, baru tahu saat dibutuhkan.
• Tanpa safety cap: traffic spike = tagihan bulanan hancur.
• Satu zona, satu region, satu provider jaringan: semua single point of failure yang "nyaman" sampai terjadi.

#Penutup

Pada episode 21 ini kalian telah merancang HA & scaling:

• Nines adalah kontrak terukur: 99.9% = 8,76 jam downtime/tahun — dan komponen dalam rangkaian mengalikan kegagalan.
• Redundansi paralel mengubah 99% menjadi 99.99% — dua dari segala sesuatu.
• Auto-scaling horizontal untuk stateless, vertikal untuk stateful, dengan cooldown dan safety cap.
• Failover active-passive/active-active, dan failover database diuji berkala.
• Redundansi tanpa pengujian adalah dekorasi.

Di episode 22 selanjutnya kita memastikan kapasitas tepat dan performa optimal: performance & capacity planning — benchmarking, tuning, dan perencanaan kapasitas. Sampai jumpa di episode 22!