Bayangkan kamu sedang membuka sebuah aplikasi penting. Tiba-tiba muncul pesan “Server sedang mengalami gangguan”. Kamu mencoba beberapa kali, tetapi sistem tetap tidak bisa digunakan.

Bagi pengguna, kondisi seperti ini tentu mengganggu. Apalagi jika aplikasi tersebut digunakan untuk transaksi, pembayaran, komunikasi, layanan publik, atau aktivitas bisnis.

Dalam dunia pengembangan software, salah satu konsep yang digunakan untuk mengurangi risiko tersebut adalah High Availability.

High Availability atau HA merupakan konsep dalam System Design untuk merancang sistem agar tetap dapat menyediakan layanan ketika terjadi gangguan pada sebagian komponen.

Namun, apakah High Availability berarti sistem tidak boleh mengalami downtime sama sekali?

Tentu tidak sesederhana itu.

High Availability lebih berkaitan dengan bagaimana sebuah sistem tetap dapat melayani pengguna atau memulihkan layanan dengan cepat ketika terjadi kegagalan.

Pada artikel ini, kita akan membahas pengertian High Availability, cara kerjanya, komponen yang digunakan, contoh arsitektur, hingga tips menerapkannya untuk pemula.

Apa Itu High Availability?

High Availability adalah pendekatan dalam merancang sistem agar layanan tetap tersedia dan dapat digunakan meskipun terjadi kegagalan pada sebagian komponen sistem.

Sederhananya:

Jika satu komponen mengalami masalah, sistem masih memiliki cara untuk tetap melayani pengguna.

Misalnya sebuah aplikasi hanya menggunakan satu server:

User
  ↓
Server
  ↓
Database

Jika server tersebut mengalami masalah:

User
  ↓
Server ❌

Aplikasi tidak dapat digunakan.

Dalam desain High Availability, kita dapat menggunakan lebih dari satu instance:

                 ┌── Server 1
User → Load Balancer
                 └── Server 2

Jika Server 1 mengalami gangguan, request masih dapat diarahkan ke Server 2.

Konsep inilah yang menjadi salah satu dasar High Availability.

Mengapa High Availability Penting?

Aplikasi modern sering digunakan kapan saja.

Pengguna tidak selalu mengakses aplikasi hanya pada jam kerja. Karena itu, downtime dapat memberikan dampak yang berbeda-beda tergantung jenis sistemnya.

Contohnya:

• Aplikasi e-commerce
• Sistem pembayaran
• Sistem perbankan
• Aplikasi komunikasi
• Sistem rumah sakit
• Platform pembelajaran
• Sistem perusahaan
• Website dengan trafik tinggi

Jika sistem tidak tersedia, pengguna mungkin tidak dapat melakukan aktivitas yang mereka butuhkan.

Karena itu, ketika kebutuhan availability meningkat, arsitektur sistem juga perlu dirancang dengan mempertimbangkan kemungkinan kegagalan.

High Availability Bukan Berarti Tanpa Downtime

Ini merupakan hal penting yang perlu dipahami.

High Availability tidak sama dengan sistem yang dijamin tidak pernah mengalami downtime.

Setiap sistem tetap memiliki kemungkinan mengalami masalah.

Misalnya:

• Server rusak
• Database mengalami gangguan
• Network bermasalah
• Software mengalami bug
• Cloud region mengalami gangguan
• Kesalahan konfigurasi
• Listrik atau perangkat keras bermasalah

Tujuan High Availability adalah mengurangi dampak kegagalan tersebut dan membantu layanan tetap tersedia atau pulih dalam waktu yang sesuai dengan kebutuhan.

Konsep Dasar High Availability

Ada beberapa konsep penting yang sering digunakan dalam desain sistem High Availability.

1. Redundancy

Redundancy berarti menyediakan komponen cadangan.

Misalnya:

Server A
Server B

Jika Server A mengalami masalah, Server B dapat mengambil alih atau tetap melayani sebagian trafik.

Redundancy dapat diterapkan pada berbagai komponen:

• Server
• Database
• Network
• Storage
• Load balancer

2. Failover

Failover adalah proses mengalihkan layanan dari komponen yang mengalami masalah ke komponen lain yang masih tersedia.

Contohnya:

Server Utama
     ↓
   ERROR
     ↓
Failover
     ↓
Server Cadangan

Pengguna tetap dapat mengakses layanan apabila mekanisme failover berjalan sesuai rancangan.

Failover dapat dilakukan secara otomatis atau manual, tergantung arsitektur sistem.

3. Load Balancer

Load balancer berfungsi mendistribusikan request ke beberapa server.

Contohnya:

                 ┌── Server 1
                 |
User → Load Balancer
                 |
                 ├── Server 2
                 |
                 └── Server 3

Tanpa load balancer:

User
 ↓
Server 1

Dengan beberapa server:

User
 ↓
Load Balancer
 ↓
Server 1
Server 2
Server 3

Load balancer dapat membantu meningkatkan kapasitas sistem sekaligus mendukung availability.

4. Health Check

Bagaimana load balancer mengetahui bahwa sebuah server sedang bermasalah?

Salah satunya melalui health check.

Misalnya load balancer secara berkala memeriksa endpoint:

GET /health

Jika server memberikan respons yang sesuai:

Server 1 → Healthy

Jika tidak merespons:

Server 1 → Unhealthy

Load balancer kemudian dapat berhenti mengirim trafik ke server tersebut sesuai konfigurasi.

Health check juga perlu dirancang dengan baik agar tidak menganggap server sehat hanya karena proses utama masih hidup, padahal dependency penting seperti database tidak dapat diakses.

5. Replication

Replication adalah proses membuat salinan data atau sistem pada beberapa lokasi atau instance.

Contohnya pada database:

Primary Database
       |
       ↓
Replica Database
       |
       ↓
Replica Database

Jika primary mengalami masalah, replica dapat menjadi bagian dari mekanisme pemulihan atau failover, tergantung teknologi dan konfigurasi yang digunakan.

Arsitektur High Availability Sederhana

Untuk memahami konsepnya, kita dapat membuat arsitektur seperti berikut:

                    USERS
                      |
                      ↓
                LOAD BALANCER
                 /          \
                /            \
               ↓              ↓
          APP SERVER 1    APP SERVER 2
               |              |
               +------+-------+
                      |
                      ↓
                  DATABASE

Jika App Server 1 mengalami masalah:

                    USERS
                      |
                      ↓
                LOAD BALANCER
                      |
                      ↓
                APP SERVER 2
                      |
                      ↓
                  DATABASE

Layanan masih dapat berjalan selama komponen lain yang dibutuhkan tetap tersedia.

Single Point of Failure

Salah satu konsep penting dalam High Availability adalah Single Point of Failure atau SPOF.

SPOF adalah komponen yang jika mengalami kegagalan dapat menyebabkan seluruh sistem atau bagian penting sistem berhenti.

Contohnya:

             Users
                |
                ↓
          Load Balancer
                |
                ↓
           Server Tunggal
                |
                ↓
         Database Tunggal

Dalam desain tersebut, server tunggal dan database tunggal dapat menjadi titik kegagalan.

Jika server tersebut mati:

Users
  ↓
Server ❌
  ↓
Layanan terganggu

Karena itu, dalam desain High Availability, developer perlu mengidentifikasi SPOF dan menentukan apakah komponen tersebut perlu dibuat redundant.

Contoh Menghilangkan Single Point of Failure

Misalnya awalnya:

User
 ↓
Server
 ↓
Database

Kemudian dikembangkan menjadi:

                 ┌── App Server 1 ──┐
User → Load Balancer                ├→ Database
                 └── App Server 2 ──┘

Sekarang aplikasi memiliki lebih dari satu server aplikasi.

Tetapi masih ada pertanyaan:

Bagaimana dengan database?

Jika database hanya satu:

App 1 ──┐
        ├── Database ❌
App 2 ──┘

Database masih menjadi Single Point of Failure.

Karena itu, desain High Availability perlu melihat sistem secara keseluruhan, bukan hanya menambah server aplikasi.

High Availability pada Database

Database sering menjadi bagian yang cukup penting karena menyimpan data utama aplikasi.

Salah satu pendekatan adalah menggunakan database replication.

Contohnya:

             Application
                  |
                  ↓
              Primary
             Database
                  |
          +-------+-------+
          ↓               ↓
      Replica 1       Replica 2

Replica dapat digunakan untuk berbagai kebutuhan tergantung arsitektur, misalnya membaca data atau menjadi bagian dari strategi failover.

Namun, replication bukan berarti semua masalah database otomatis selesai.

Developer tetap perlu mempertimbangkan:

• Konsistensi data
• Replication lag
• Proses failover
• Recovery
• Backup
• Monitoring

Apa Itu Failover Database?

Misalnya database utama mengalami masalah.

Application
     |
     ↓
Primary Database ❌

Sistem dapat memiliki mekanisme untuk mengalihkan peran ke database lain:

Application
     |
     ↓
Replica Database

Tetapi proses failover database perlu dirancang dengan hati-hati.

Jangan hanya berpikir:

“Kalau database mati, tinggal pindahkan ke replica.”

Perlu dipastikan bahwa replica memiliki data yang cukup terbaru dan sistem dapat menangani perubahan koneksi serta kemungkinan konflik data.

Availability dan Scalability Itu Berbeda

High Availability sering dibicarakan bersama Scalability, tetapi keduanya bukan hal yang sama.

Scalability

Scalability berkaitan dengan kemampuan sistem menangani pertumbuhan beban.

Contohnya:

10.000 pengguna
      ↓
Tambah kapasitas
      ↓
100.000 pengguna

High Availability

High Availability berkaitan dengan kemampuan sistem tetap menyediakan layanan ketika terjadi kegagalan.

Contohnya:

Server 1 ❌
     ↓
Server 2 tetap melayani

Keduanya dapat diterapkan bersama.

Sistem dapat dirancang agar:

• mampu menangani trafik tinggi
• tetap tersedia ketika sebagian komponen gagal

Availability dan Fault Tolerance

High Availability juga memiliki hubungan erat dengan Fault Tolerance.

Fault tolerance berfokus pada kemampuan sistem untuk tetap beroperasi ketika terjadi kegagalan tertentu.

Sedangkan High Availability lebih menekankan pada menjaga layanan tetap tersedia dan meminimalkan downtime.

Keduanya dapat saling melengkapi dalam System Design.

Contohnya:

Redundancy
   +
Failover
   +
Health Check
   +
Monitoring
   ↓
High Availability

Apa Itu Uptime?

Uptime adalah waktu ketika sebuah sistem tersedia atau beroperasi.

Biasanya availability dinyatakan dalam persentase.

Misalnya:

99%
99,9%
99,99%
99,999%

Semakin tinggi target availability, semakin ketat pula kebutuhan desain, operasi, monitoring, dan pemulihan sistem.

Mengenal “Nines” dalam Availability

Availability sering dibicarakan menggunakan istilah nines.

Contohnya:

Availability	Perkiraan downtime per tahun
99%	sekitar 3,65 hari
99,9%	sekitar 8,76 jam
99,99%	sekitar 52,6 menit
99,999%	sekitar 5,26 menit

Angka tersebut merupakan gambaran matematis jika target availability diterapkan selama satu tahun penuh dan downtime dihitung secara sederhana.

Semakin tinggi target availability, semakin kecil waktu downtime yang dapat diterima.

Apa Itu SLA?

SLA atau Service Level Agreement adalah kesepakatan mengenai tingkat layanan yang harus diberikan.

Misalnya sebuah layanan menetapkan target availability tertentu.

Target tersebut kemudian menjadi salah satu dasar dalam menentukan arsitektur dan operasional sistem.

Namun, penting untuk membedakan:

• Availability target: target yang ingin dicapai.
• SLA: kesepakatan layanan dengan ketentuan tertentu.
• SLO: tujuan tingkat layanan yang digunakan sebagai target operasional.
• SLI: metrik yang digunakan untuk mengukur kondisi layanan.

Konsep-konsep ini sering digunakan bersama dalam praktik reliability engineering.

Contoh System Design High Availability

Misalnya kita membuat aplikasi toko online.

Arsitektur sederhananya:

                         USERS
                           |
                           ↓
                      LOAD BALANCER
                      /           \
                     ↓             ↓
               APP SERVER 1   APP SERVER 2
                     \             /
                      \           /
                       ↓         ↓
                         DATABASE
                            |
                            ↓
                         STORAGE

Jika ingin meningkatkan availability, setiap bagian perlu dianalisis.

Misalnya:

Load Balancer
      ↓
Apakah ada redundancy?

Application
      ↓
Apakah ada lebih dari satu instance?

Database
      ↓
Bagaimana mekanisme replication dan failover?

Storage
      ↓
Bagaimana backup dan recovery?

Dengan pendekatan ini, System Design tidak hanya fokus pada satu server.

Contoh High Availability pada Aplikasi Perpustakaan

Misalnya kita memiliki aplikasi perpustakaan berbasis web.

Arsitektur awal:

User
 ↓
Server
 ↓
MySQL

Jika server mati, aplikasi tidak dapat digunakan.

Kemudian dikembangkan:

                   ┌── App Server 1
User → Load Balancer
                   └── App Server 2
                          |
                          ↓
                     Database

Jika App Server 1 mengalami gangguan, request dapat diarahkan ke App Server 2.

Untuk database, desain dapat dikembangkan sesuai kebutuhan availability dan konsistensi data.

Monitoring dalam High Availability

Memiliki server cadangan saja belum cukup.

Kita juga perlu mengetahui apakah sistem sedang sehat.

Monitoring dapat digunakan untuk memantau:

• CPU
• Memory
• Disk
• Network
• Response time
• Error rate
• Database
• Status server

Contohnya:

Server 1
   ↓
Monitoring
   ↓
CPU tinggi
   ↓
Alert
   ↓
Developer / DevOps

Dengan monitoring, masalah dapat diketahui lebih cepat.

Logging dan Alerting

Selain monitoring, sistem juga membutuhkan logging.

Contohnya:

Application
    ↓
Log
    ↓
Error ditemukan
    ↓
Monitoring
    ↓
Alert

Log dapat membantu developer mengetahui:

• Kapan masalah terjadi
• Endpoint yang mengalami error
• Jenis error
• Request yang terlibat
• Komponen yang terdampak

Alert kemudian dapat digunakan untuk memberi tahu tim ketika kondisi tertentu terjadi.

Backup Tetap Penting

High Availability tidak menggantikan backup.

Misalnya database memiliki replication:

Primary
  ↓
Replica

Jika data terhapus secara tidak sengaja:

Data Terhapus
      ↓
Replication
      ↓
Replica ikut berubah

Dalam situasi tertentu, replica bukan pengganti backup karena perubahan atau penghapusan dapat ikut direplikasi.

Karena itu, sistem tetap membutuhkan strategi backup dan recovery yang sesuai.

Disaster Recovery

Untuk gangguan yang lebih besar, kita membutuhkan Disaster Recovery (DR).

Contohnya:

Data Center / Region A
        ↓
     Gangguan
        ↓
Data Center / Region B

Disaster Recovery berfokus pada kemampuan memulihkan layanan dan data setelah gangguan besar.

Strateginya dapat melibatkan:

• Backup
• Replication
• Infrastruktur cadangan
• Prosedur recovery
• Pengujian recovery

RTO dan RPO

Dalam Disaster Recovery, dua istilah yang penting dipahami adalah RTO dan RPO.

RTO — Recovery Time Objective

RTO adalah target waktu yang dibutuhkan untuk memulihkan layanan setelah terjadi gangguan.

Contohnya:

Gangguan terjadi
      ↓
Target pemulihan: 1 jam

RPO — Recovery Point Objective

RPO berkaitan dengan seberapa banyak kehilangan data yang masih dapat diterima berdasarkan titik pemulihan yang tersedia.

Misalnya:

RPO = 15 menit

Artinya strategi recovery dirancang agar kehilangan data yang diterima berada dalam batas target tersebut.

RTO dan RPO membantu menentukan desain backup dan disaster recovery.

Apakah Semua Aplikasi Membutuhkan High Availability?

Tidak semua aplikasi membutuhkan tingkat availability yang sama.

Misalnya website portofolio sederhana mungkin memiliki kebutuhan berbeda dengan sistem pembayaran.

Karena itu, sebelum membuat arsitektur yang kompleks, tanyakan:

1. Seberapa penting aplikasi harus selalu tersedia?
2. Berapa lama downtime yang masih dapat diterima?
3. Berapa biaya jika sistem berhenti?
4. Berapa banyak pengguna yang dilayani?
5. Apa dampaknya jika data tidak tersedia?
6. Berapa cepat sistem harus dipulihkan?

Jawaban dari pertanyaan tersebut membantu menentukan tingkat High Availability yang sesuai.

Kesalahan yang Sering Terjadi

Ada beberapa kesalahan yang perlu dihindari ketika merancang sistem High Availability.

1. Hanya Menambah Server

Menambah beberapa server aplikasi tidak otomatis membuat seluruh sistem highly available.

Database, storage, network, dan komponen lainnya juga perlu dianalisis.

2. Tidak Mengidentifikasi SPOF

Jika masih ada satu komponen yang menjadi titik kegagalan utama, sistem tetap memiliki risiko gangguan besar.

3. Tidak Melakukan Testing Failover

Failover yang belum pernah diuji belum tentu bekerja ketika benar-benar dibutuhkan.

4. Mengabaikan Backup

Replication bukan pengganti backup.

5. Tidak Memiliki Monitoring

Tanpa monitoring, tim dapat terlambat mengetahui adanya masalah.

Tips Mendesain Sistem High Availability untuk Pemula

Kalau kamu baru belajar System Design, tidak perlu langsung membuat arsitektur yang sangat kompleks.

Mulailah dari langkah berikut:

1. Identifikasi Komponen

Tentukan:

• Frontend
• Backend
• Database
• Storage
• Network

2. Cari Single Point of Failure

Tanyakan:

“Kalau komponen ini mati, apakah seluruh sistem ikut mati?”

3. Tambahkan Redundancy Jika Dibutuhkan

Gunakan beberapa instance untuk komponen yang memang membutuhkan availability lebih tinggi.

4. Gunakan Health Check

Pastikan sistem dapat mengetahui komponen yang bermasalah.

5. Siapkan Failover

Tentukan apa yang terjadi ketika komponen utama gagal.

6. Tambahkan Monitoring

Pantau kondisi sistem secara berkala.

7. Siapkan Backup dan Recovery

Jangan hanya fokus pada server yang aktif.

8. Uji Sistem

Simulasikan kegagalan untuk mengetahui apakah mekanisme recovery benar-benar berjalan.

Contoh Arsitektur High Availability yang Lebih Lengkap

Jika kebutuhan sistem semakin besar, gambaran arsitekturnya dapat menjadi seperti berikut:

                         USERS
                           |
                           ↓
                    LOAD BALANCER
                     /           \
                    ↓             ↓
               APP SERVER 1   APP SERVER 2
                    \             /
                     \           /
                      ↓         ↓
                       DATABASE
                       /      \
                      ↓        ↓
                 PRIMARY      REPLICA
                    |
                    ↓
                  BACKUP

        MONITORING + LOGGING + ALERTING
                     |
                     ↓
                  OPERATIONS

Arsitektur tersebut menunjukkan bahwa High Availability bukan hanya tentang menambahkan server.

Ada beberapa lapisan yang perlu dipikirkan:

Redundancy
Failover
Health Check
Monitoring
Backup
Recovery

Semua komponen tersebut dapat disesuaikan dengan kebutuhan sistem.

Kesimpulan

High Availability adalah pendekatan dalam System Design untuk menjaga layanan tetap tersedia atau dapat dipulihkan dengan cepat ketika terjadi kegagalan pada sebagian komponen.

Beberapa konsep penting yang perlu dipahami antara lain:

• Redundancy untuk menyediakan komponen alternatif
• Failover untuk mengalihkan layanan ketika terjadi kegagalan
• Load Balancer untuk mendistribusikan trafik
• Health Check untuk mengetahui kondisi komponen
• Replication untuk menyediakan salinan data atau sistem
• Monitoring untuk mengawasi kondisi layanan
• Backup untuk perlindungan data
• Disaster Recovery untuk menghadapi gangguan besar

Hal yang tidak kalah penting, High Availability harus disesuaikan dengan kebutuhan aplikasi. Tidak semua aplikasi membutuhkan arsitektur yang sangat kompleks.

Bagi pemula, mulailah dengan memahami Single Point of Failure, kemudian pelajari redundancy, failover, load balancing, database replication, monitoring, dan disaster recovery.

Semakin kamu memahami konsep-konsep tersebut, semakin mudah untuk merancang sistem yang tidak hanya bisa berjalan ketika kondisi normal, tetapi juga memiliki strategi ketika sesuatu mengalami kegagalan.