HA & Fault Tolerance #

Dalam dunia rekayasa perangkat lunak dan infrastruktur modern, terdapat satu kebenaran mutlak yang harus kita terima sejak awal perancangan sistem: semua komponen infrastruktur pasti akan mengalami kegagalan pada suatu waktu. Harddisk server akan rusak, modul RAM akan mengalami kerusakan memori, jaringan serat optik akan terputus karena penggalian jalan, atau bencana alam akan melumpuhkan data center. Filosofi arsitektur cloud yang baik tidak berupaya mencegah kegagalan tersebut secara sia-sia, melainkan merancang sistem yang tetap mampu bertahan dan berfungsi dengan baik meskipun komponen di bawahnya sedang hancur. Dua pendekatan utama yang kita gunakan untuk mencapai ketahanan sistem ini adalah High Availability (HA) dan Fault Tolerance (FT). Meskipun memiliki tujuan akhir yang serupa, keduanya menerapkan strategi operasional yang berbeda dengan konsekuensi biaya dan kompleksitas arsitektur yang sangat berlawanan.

Anatomi Perbedaan: High Availability vs Fault Tolerance #

Untuk menghindari kesalahan penafsiran arsitektur yang berujung pada pemborosan anggaran, kita harus memahami batas-batas definisi yang jelas antara High Availability (HA) dan Fault Tolerance (FT).

High Availability (HA) adalah kemampuan suatu sistem untuk menjaga tingkat ketersediaan operasionalnya dalam waktu yang lama, dengan merancang proses pemulihan (recovery) yang sangat cepat ketika terjadi kegagalan komponen. Kata kunci dari HA adalah meminimalkan downtime. Sistem HA menerima kenyataan bahwa kegagalan akan menyebabkan gangguan sesaat (downtime singkat), namun sistem memiliki otomatisasi untuk mendeteksi kegagalan tersebut, mengisolasi komponen yang rusak, dan melakukan pengalihan (failover) ke komponen cadangan dalam hitungan detik atau menit.

Fault Tolerance (FT) adalah kemampuan suatu sistem untuk terus berjalan melayani pengguna tanpa ada degradasi performa atau interupsi layanan sedikit pun ketika terjadi kegagalan pada komponen perangkat keras atau perangkat lunak. Kata kunci dari FT adalah zero downtime dan zero data loss. Pada sistem yang toleran terhadap kesalahan, kegagalan komponen diserap sepenuhnya secara instan oleh infrastruktur cadangan yang berjalan secara paralel (lockstep), sehingga pengguna akhir sama sekali tidak merasakan adanya kendala atau proses failover yang sedang berlangsung di latar belakang.

Tabel perbandingan di bawah ini menyajikan detail perbedaan antara HA dan FT:

Diagram di bawah ini membandingkan siklus hidup respon sistem saat terjadi kegagalan pada arsitektur HA dan FT:

flowchart TD
    subgraph HALifecycle["High Availability (HA) Failover"]
        direction TB
        H1["Komponen A Aktif"] --> H2["Terjadi Kegagalan Komponen A"]
        H2 --> H3["Sistem Mendeteksi Kegagalan (Health Check delay, ~5-30s)"]
        H3 --> H4["Mengalihkan Trafik ke Komponen B Standby (Failover Window)"]
        H4 --> H5["Sistem Kembali Normal (Ada brief downtime)"]
    end
    
    subgraph FTLifecycle["Fault Tolerance (FT) Lockstep"]
        direction TB
        F1["Komponen A & B Bekerja Paralel (Lockstep)"] --> F2["Terjadi Kegagalan Komponen A"]
        F2 --> F3["Komponen B Melanjutkan Pemrosesan Instan"]
        F3 --> F4["Sistem Terus Berjalan (Downtime = 0ms)"]
    end

Mengukur Availability dengan SLA dan “Nines” #

Availability atau tingkat ketersediaan sistem biasanya diukur secara matematis dalam bentuk persentase waktu aktif (uptime) dalam kurun waktu satu tahun. Persentase ini tertuang di dalam dokumen komitmen hukum yang disebut SLA (Service Level Agreement) antara penyedia layanan cloud dengan pelanggan.

Tingkat ketersediaan ini sering disebut dengan istilah “Nines” (Jumlah Angka Sembilan). Tabel di bawah ini menunjukkan konversi persentase availability menjadi durasi toleransi downtime maksimum yang diizinkan:

Setiap kita ingin menaikkan tingkat ketersediaan aplikasi (misalnya dari 99.9% menjadi 99.99%), kompleksitas desain sistem dan biaya infrastruktur akan melonjak berkali-kali lipat. Kita dipaksa untuk menambahkan lebih banyak sistem otomatisasi failover, replikasi data real-time lintas benua, dan memangkas waktu deteksi kegagalan hingga sekecil mungkin.

Bahaya Salah Menghitung SLA Komposit (Composite SLA) #

Satu kesalahan klasik yang sering dilakukan oleh developer junior adalah berasumsi bahwa jika seluruh komponen cloud yang kita sewa memiliki SLA 99.9%, maka aplikasi kita otomatis akan memiliki SLA 99.9%. Ini adalah asumsi yang salah secara matematika probabilitas.

Jika aplikasi kita berjalan secara linier (bergantung pada komponen yang terhubung secara seri), ketersediaan total aplikasi kita adalah hasil perkalian dari SLA masing-masing komponen. Ini disebut SLA Komposit Seri.

$$\text{SLA Komposit Seri} = \text{SLA App Server} \times \text{SLA Database} \times \text{SLA Storage}$$

Misalkan kita menyewa VM dengan SLA 99.9% ($0.999$), Database managed dengan SLA 99.9% ($0.999$), dan Storage dengan SLA 99.9% ($0.999$). Maka SLA komposit aplikasi kita adalah:

$$\text{SLA Komposit} = 0.999 \times 0.999 \times 0.999 = 0.997 \text{ (atau } 99.7%)$$

Catatan: 99.7% berarti toleransi downtime aplikasi kita membengkak menjadi 26.28 jam per tahun, jauh lebih buruk dibanding 8.76 jam per tahun pada SLA 99.9%.

Solusi: Meningkatkan SLA dengan Redundansi Paralel #

Untuk menaikkan SLA komposit, kita harus mendesain komponen aplikasi secara paralel (redundant). Jika kita menaruh dua VM aplikasi secara paralel di bawah Load Balancer, probabilitas kegagalan gabungan dari kedua VM tersebut menurun drastis menjadi:

$$\text{Probabilitas Gagal Gabungan} = (1 - 0.999) \times (1 - 0.999) = 0.000001$$ $$\text{SLA Paralel Baru} = 1 - 0.000001 = 0.999999 \text{ (atau } 99.9999%)$$

Dengan mendesain server aplikasi secara paralel, kita berhasil mendongkrak keandalan layer komputasi dari 99.9% menjadi 99.9999%, yang pada akhirnya akan mendongkrak SLA komposit seluruh sistem secara keseluruhan.

Komponen Arsitektur Utama untuk High Availability #

Untuk membangun sistem yang memiliki ketersediaan tinggi di cloud, arsitektur kita wajib menerapkan tiga pilar fundamental berikut secara bersamaan:

1. Redundansi Multilapis (Multi-tiered Redundancy) #

Tidak boleh ada satu pun komponen di dalam sistem kita yang menjadi Single Point of Failure (SPOF). Setiap layer harus memiliki cadangan:

• Layer Jaringan: Gunakan Load Balancer yang secara otomatis tersebar di beberapa Availability Zone untuk menerima trafik masuk.
• Layer Komputasi: Jalankan minimal dua instans server aplikasi di Availability Zone yang berbeda.
• Layer Penyimpanan: Gunakan managed storage yang melakukan replikasi data secara otomatis di latar belakang.
• Layer Database: Konfigurasikan arsitektur Primary-Standby dengan sinkronisasi aktif di zone yang terpisah.

2. Deteksi Kegagalan Otomatis & Auto-Healing #

Redundansi tidak akan berguna jika sistem kita tidak tahu kapan salah satu komponen mengalami kerusakan. Kita membutuhkan:

• Liveness Probes: Memastikan bahwa server aplikasi masih hidup. Jika server mengalami deadlock memori, sistem auto-scaling akan mematikan server tersebut secara paksa dan menggantinya dengan instans baru.
• Readiness Probes: Memastikan bahwa server aplikasi sudah siap menerima request trafik baru (misalnya, koneksi ke database telah terjalin dan cache inisial sudah terisi). Load balancer hanya akan mengarahkan trafik ke server yang berstatus ready.

3. Degradasi Fungsional secara Anggun (Graceful Degradation) #

Ketika terjadi kegagalan pada layanan eksternal atau sub-sistem yang tidak kritis, aplikasi kita tidak boleh langsung menampilkan halaman error 500 total kepada pengguna. Kita harus menerapkan Circuit Breaker Pattern.

Jika layanan pemberi rekomendasi produk di e-commerce kita mati, halaman detail produk harus tetap tampil dengan menyembunyikan bagian rekomendasi, sehingga pengguna tetap bisa melakukan pembelian produk utama secara normal.

Berikut adalah ilustrasi kode implementasi Circuit Breaker sederhana di sisi aplikasi Node.js untuk menjaga ketersediaan fitur utama ketika service rekomendasi pihak ketiga mengalami gangguan:

// ✓ BENAR: Terapkan Circuit Breaker untuk Graceful Degradation
class RecommendationServiceClient {
  constructor() {
    this.failureCount = 0;
    this.failureThreshold = 3;
    this.state = 'CLOSED'; // CLOSED, OPEN, HALF-OPEN
    this.lastStateChange = Date.now();
    this.cooldownPeriod = 30000; // 30 detik untuk mencoba kembali
  }

  async getRecommendations(userId) {
    if (this.state === 'OPEN') {
      if (Date.now() - this.lastStateChange > this.cooldownPeriod) {
        this.state = 'HALF-OPEN'; // Masuk ke mode coba-coba
      } else {
        // Sistem dalam mode OPEN (Gagal) -> Kembalikan data fallback instant tanpa memanggil API yang rusak
        return this.getFallbackData();
      }
    }

    try {
      const response = await this.callExternalAPI(userId);
      // Jika sukses, reset kegagalan
      this.failureCount = 0;
      this.state = 'CLOSED';
      return response;
    } catch (error) {
      this.failureCount++;
      if (this.failureCount >= this.failureThreshold) {
        this.state = 'OPEN';
        this.lastStateChange = Date.now();
        console.warn("CRITICAL: Circuit breaker OPEN untuk service rekomendasi.");
      }
      return this.getFallbackData(); // Kembalikan data fallback agar user tidak melihat error 500
    }
  }

  async callExternalAPI(userId) {
    // Simulasi pemanggilan API eksternal
    // Jika lambat atau error, akan memicu throw error
    return fetch(`https://api.rekomendasi.internal/users/${userId}`);
  }

  getFallbackData() {
    // Kembalikan daftar produk populer default sebagai alternatif anggun
    return ["Produk Terpopuler A", "Produk Terpopuler B", "Produk Terpopuler C"];
  }
}

Pola Desain HA di Lingkungan Cloud #

Ada beberapa pola implementasi arsitektur HA di cloud yang bisa kita sesuaikan dengan karakteristik workload aplikasi kita:

Pola 1: Active-Active Multi-AZ (Compute Layer) #

Pada pola ini, semua instans aplikasi yang tersebar di beberapa Availability Zone berada dalam kondisi aktif dan menerima trafik secara bersamaan dari Load Balancer.

flowchart TD
    LB["Load Balancer"] -->|"33% trafik"| A["AZ-1a: Instance A"]
    LB -->|"33% trafik"| B["AZ-1b: Instance B"]
    LB -->|"33% trafik"| C["AZ-1c: Instance C"]

• Keunggulan: Pemanfaatan resource sangat efisien karena semua server bekerja melayani request. Tidak ada downtime saat salah satu server mati karena server lain langsung menyerap sisa trafik.
• Kelemahan: Aplikasi harus dirancang stateless agar request pengguna bisa diarahkan ke instans mana saja tanpa merusak sesi.

Pola 2: Active-Passive (Primary-Standby) (Database Layer) #

Pola ini umumnya digunakan untuk sistem database relasional di mana penulisan data harus terpusat pada satu server utama untuk menjaga konsistensi transaksi data.

flowchart TD
    LB["Load Balancer"] -->|"100% trafik"| A["AZ-1a: Instance A (ACTIVE)"]
    LB -. "no trafik" .-> B["AZ-1b: Instance B (STANDBY)"]

• Keunggulan: Menjamin integritas data yang sangat konsisten karena seluruh penulisan dilakukan pada satu tempat utama.
• Kelemahan: Ada waktu jeda pemulihan (downtime singkat) selama proses promosi database Standby menjadi Primary baru. Server Standby juga tidak digunakan untuk memproses komputasi harian sehingga efisiensi biaya kurang optimal.

Metrik Bisnis untuk Recovery: RTO dan RPO #

Dalam merancang Disaster Recovery (DR) dan High Availability, kita harus menyelaraskan target teknis dengan kebutuhan bisnis organisasi. Dua metrik paling mendasar yang wajib disepakati bersama pihak manajemen adalah RTO dan RPO.

  RTO (Recovery Time Objective)
      "Berapa lama waktu maksimal sistem kita boleh mati sebelum bisnis menderita kerugian fatal?"
      
      RTO = 0       -> Sistem tidak boleh mati sama sekali (Fault Tolerance).
      RTO = 5 menit -> Sistem harus pulih secara otomatis dalam 5 menit setelah kegagalan.
      RTO = 4 jam   -> Tim IT memiliki waktu 4 jam untuk memulihkan sistem secara manual.

  RPO (Recovery Point Objective)
      "Berapa banyak jumlah data transaksi yang boleh hilang saat bencana terjadi?"
      
      RPO = 0       -> Tidak boleh ada kehilangan data sama sekali (Replikasi Sinkron).
      RPO = 1 jam   -> Kita boleh kehilangan data transaksi maksimal 1 jam terakhir.
      RPO = 24 jam  -> Kita cukup mengandalkan restore data dari backup harian semalam.

Berikut adalah tabel pemetaan strategi arsitektur di cloud berdasarkan target metrik RTO dan RPO:

Ringkasan #

• HA fokus pada minimalisasi downtime, sedangkan FT fokus pada peniadaan downtime dan pencegahan gangguan sekecil apa pun dengan biaya infrastruktur yang jauh lebih tinggi.
• SLA komposit seri bersifat multiplikatif, yang berarti menggabungkan beberapa komponen tanpa redundansi akan memperburuk ketersediaan total aplikasi kita.
• Terapkan redundansi paralel pada layer komputasi aplikasi untuk meningkatkan keandalan sistem gabungan hingga mencapai standard “Five Nines” (99.999%).
• Circuit breaker pattern sangat krusial untuk menerapkan graceful degradation, mencegah aplikasi mati total ketika layanan eksternal mengalami gangguan.
• Gunakan kombinasi Liveness dan Readiness Probes pada Load Balancer agar trafik hanya dialirkan ke instans server yang benar-benar siap memproses data.
• RTO dan RPO adalah kompas bisnis arsitektur HA/DR, yang mengukur batas toleransi waktu pemulihan sistem dan batas toleransi kehilangan data saat bencana terjadi.

← Sebelumnya: Global Infrastructure   Berikutnya: Control Plane vs Data Plane →