High Availibility

Pendahuluan

Ketika berbicara mengenai High Availibility didalam sebuah sistem, maka kita akan butuh 3 hal berikut :

• Tidak ada Single Point of Failure.
• Kemampuan untuk berganti-ganti sistem secara mudah.
• Kemampuan untuk mendeteksi kegagalan sistem secara cepat.

Karena inti dari High Availibility adalah Availibility nya, yaitu ketersediaan service yang dibutuhkan, sehingga pengguna bisa menggunakan sistem kita dengan lengkap dan sempurna.

High Availibility bukan berarti sistem/aplikasi kita tidak pernah mati/downtime sama sekali.

Akan tetapi High Availibility mengisyaratkan bahwa sistem kita harus tersedia sepanjang waktu., dengan meminimalkan downtime nya.

Downtime yang kita maksudkan disini juga termasuk ketidakmampuan sistem untuk menangani request yang banyak.

Misalkan di Ticket War atau Flash Sale yang menangani ribuan request permenit/perdetik, sehingga menyebabkan sistem nge hang, atau tidak bisa diakses.

Kasus awalnya

Sebenarnya sebuah sistem aplikasi bisa saja mati dalam beberapa saat, misalnya ketika :

• Pergantian komponen fisik, seperti disk, memori, VM, dll.
• Ketika deployment aplikasi yang membutuhkan downtime.
• Ketika ada kegagalan di salah satu komponennya, misalnya aplikasi pihak ketiga, atau salah satu microservice kita, sehingga sistem kita menjadi tidak sempurna pemrosesannya.
• Ketika mati lampu.
• dll.

Akibatnya sistem aplikasi kita tidak bisa diakses dalam waktu tersebut.

Dan tidak apa-apa juga sebenarnya kan ?

Paling cuma seperempat jam, satu jam, atau paling maksimal satu hari saja.

Itupun biasanya malam hari.

Eh, tapi bisa juga seminggu ding..

Untuk kasus yang terencana, seperti operasional task, deployment aplikasi, atau pergantiaan disk, memori, VM, dll, biasanya lebih mudah memperkirakan waktunya.

Kita memberikan informasi kepada customer atau client atau user mengenai Downtime nya itu melalui email, informasi di website atau di aplikasi kita.

Sementara untuk kasus yang tidak terencana, seperti mati lampu, ngehang, kegagalan di bagian dari sistem, maka kita melakukan mitigasi nya bermacam-macam, misalnya :

• melakukan restart sistem.
• mengganti disk, VM, atau RAM yang dibutuhkan.
• mengaktifkan genset listrik.
• dll.

Nah kasus ini lebih tinggi resikonya, karena tidak direncanakan.

Waktunya juga tidak bisa diperkirakan.

Bisa saja dalam hitungan detik, menit, hari, bahkan minggu.

Kegagalan di sebuah data center, bisa saja menyebabkan kehilangan data yang banyak, dan membutuhkan recovery dalam hitungan hari atau minggu.

Berakibat kepada penjualan, pemrosesan data, kehilangan uang, reputasi, dll.

Dan akhirnya kita merasa bahwa ada batas toleransi Downtime yang mesti kita definisikan agar masih tetap bisa diterima oleh kita sebagai user teknis maupun user bisnis.

Lalu ?

Kejadian Downtime yang terlalu lama diatas mestinya tidak boleh terjadi, karena :

• Kita tentu saja tidak ingin tergantung kepada sistem yang bisa mati tiba-tiba.
• Kita juga butuh sistem yang bisa diandalkan kapan pun dibutuhkan. Apalagi terkait dengan penjualan, keuangan, dan transaksi.
• Kita tidak ingin terburu-buru dalam kepanikan ketika service kita tidak available, karena kerusakan atau error di salah satu bagian aplikasi.
• Apalagi terjadi di aplikasi yang transaksinya sudah ribuan transaksi permenit, atau yang lebih banyak lagi.

Akibatnya muncul ide untuk High Availibility.

Yaitu memastikan bahwa semua keinginan kita diatas terpenuhi.

Secara otomatis dan secara lengkap juga tentunya.

Karena melakukan sesuatu secara manual, secara natural akan membutuhkan waktu yang lebih lama.

Bagaimana membuat service yang kita punya tetap bekerja walaupun ada kejadian downtime yang terencana maupun tidak terencana.

Misalnya :

• Ketika melakukan penggantian Disk, Memori, atau VM, maka sudah otomatis ada backup nya, sudah ready environment barunya, atau langsung switch ke environment yang baru tanpa butuh waktu lama.
• Ketika deployment aplikasi, maka otomatis akan switch ke versi yang baru, baik secara bertahap maupun secara keseluruhan, tanpa membutuhkan downtime yang lama.
• Ketika mati lampu, maka otomatis genset akan hidup dan sistem yang berada diatasnya bisa juga otomatis hidup tanpa intervensi manual.
• Ketika ada service yang mati, maka otomatis akan ada pengganti nya yang serupa atau service yang tadi otomatis akan restart sendiri.
• dll.

Jadi kalau dilihat High Availibility ini levelnya di abstraksi yang lebih tinggi.

Yaitu :

Kebutuhan agar sebuah sistem tersedia/available sepanjang waktu.

Available seberapa lama ?

Ok..ok.

Karena High Availibility ini levelnya di abstraksi yang lebih tinggi, maka hal ini nanti berkaitan dengan SLA (Service Level Agreement).

Yaitu seberapa lama Uptime yang dianggap pantas sebagai Available.

Dalam istilah teknis nya, kita mengenai berapa banyak angka 9 dalam persentase yang dijadikan patokan.

Kita nanti mengenal table SLA untuk High Availibilty sbb :

Persentase SLA diatas merupakan salah satu formula bagi tim SRE (Site Reliability Engineering) dalam mengukur kehandalan dari sistem yang ada.

Makin tinggi atau makin banyak angka 9 yang ada dalam SLA nya itu, maka makin tinggi/ketat tingkat High Availibility dari sistem tersebut.