HA vs Toleransi Kesalahan: Definisi dan Pertukaran

High Availability (HA) dan Fault Tolerance (FT) adalah dua sasaran keandalan berbeda yang sering disalahartikan oleh arsitek. Ketersediaan tinggi berarti sistem mengalami waktu henti minimal — sistem dapat menoleransi kegagalan, tetapi mungkin mengalami gangguan singkat selama pemulihan. Toleransi kesalahan berarti sistem terus beroperasi tanpa gangguan apa pun meskipun komponen mengalami kegagalan, karena memiliki jalur yang sepenuhnya redundan dan dapat mengambil alih secara seketika.

Ketersediaan diukur sebagai persentase waktu aktif selama setahun. Ketersediaan 99,9% (three nines) berarti sekitar 8,7 jam waktu henti per tahun, sedangkan 99,99% (four nines) hanya mengizinkan 52,6 menit. 99,999% (five nines) hanya mengizinkan 5,26 menit. Setiap tambahan angka sembilan biasanya memerlukan lebih banyak redundansi, otomatisasi, dan biaya. Ujian SAA-C03 sering meminta Anda mengidentifikasi arsitektur yang memenuhi target ketersediaan tertentu.

Arsitektur dengan ketersediaan tinggi menoleransi kegagalan satu komponen dengan mendeteksi kegagalan secara otomatis dan beralih ke pengganti yang sehat dalam hitungan detik atau menit. Contohnya termasuk RDS Multi-AZ (failover otomatis ke siaga di AZ berbeda), Auto Scaling Groups yang menggantikan instans yang dihentikan, dan Elastic Load Balancers yang mengarahkan lalu lintas menjauh dari target yang tidak sehat. Terjadi gangguan singkat, tetapi sistem pulih tanpa intervensi manual.

Arsitektur yang toleran terhadap kesalahan memiliki redundansi aktif — beberapa komponen identik melayani permintaan secara bersamaan sehingga ketika salah satunya gagal, komponen lain langsung menanggung bebannya tanpa waktu henti. Contohnya termasuk ELB active-active dengan beberapa instans EC2, DynamoDB Global Tables yang melayani pembacaan dan penulisan secara bersamaan di beberapa region, serta Aurora dengan beberapa read replica. Toleransi kesalahan memerlukan lebih banyak sumber daya yang terus berjalan.

Toleransi kesalahan jauh lebih mahal daripada ketersediaan tinggi karena memerlukan kapasitas redundan yang sepenuhnya tersedia setiap saat. Instans RDS Multi-AZ yang sangat tersedia menggandakan biaya basis data Anda untuk siaga yang hanya aktif saat terjadi kegagalan. Deployment Aurora active-active multi-region yang tahan terhadap kesalahan mungkin berbiaya empat kali lipat, tetapi menghilangkan semua waktu henti selama kegagalan region. Arsitek harus menyeimbangkan biaya redundansi dengan biaya bisnis akibat waktu henti.

Recovery Time Objective (RTO) adalah waktu maksimum yang dapat diterima ketika sistem tidak tersedia. Arsitektur dengan ketersediaan tinggi menargetkan RTO rendah — biasanya beberapa menit — melalui failover otomatis. Arsitektur yang toleran terhadap kesalahan menargetkan RTO mendekati nol. Saat merancang HA, Anda harus memilih layanan dan konfigurasi yang menjamin pemulihan dalam batas RTO Anda. Contohnya, RDS Multi-AZ menyediakan RTO sekitar 60–120 detik, yang sesuai untuk banyak persyaratan HA.

Single Point of Failure (SPOF) adalah komponen apa pun yang kegagalannya menyebabkan seluruh sistem gagal. SPOF umum meliputi satu instans EC2 tanpa ASG, basis data RDS pada satu AZ, satu gateway NAT, atau satu availability zone. Menghilangkan SPOF adalah langkah pertama menuju HA dan FT. Ujian SAA-C03 sering menguji kemampuan Anda untuk mengidentifikasi dan menghilangkan SPOF dalam diagram arsitektur yang diberikan.

Mencapai HA atau FT jauh lebih sederhana untuk layanan stateless (seperti server web atau fungsi Lambda) karena instans mana pun dapat menangani permintaan apa pun. Layanan stateful (basis data, cache, sistem berkas) lebih sulit — Anda harus menyinkronkan status di seluruh replika, menangani keterlambatan replikasi, dan memastikan konsistensi selama failover. Layanan AWS seperti EFS (sistem berkas bersama), ElastiCache dengan replication groups, dan Aurora (penyimpanan bersama) dirancang untuk mempermudah HA stateful.

Pola HA umum di AWS meliputi: 1) Multi-AZ Load Balancing — distribusikan instans EC2 di berbagai AZ di belakang ALB. 2) Read Replicas — alihkan lalu lintas pembacaan dan promosikan saat DR. 3) S3 untuk aset stateless — S3 secara inheren memiliki HA dengan ketahanan 11 angka sembilan. 4) Global Accelerator — IP Anycast statis yang mengarahkan lalu lintas ke titik akhir yang sehat di berbagai region. Setiap pola menukar biaya dengan tingkat ketersediaan tertentu.

Pola yang toleran terhadap kesalahan memerlukan redundansi aktif di semua bagian. Pola FT utama: DynamoDB secara inheren toleran terhadap kesalahan — layanan ini mereplikasi data di tiga AZ tanpa memerlukan failover. S3 memiliki FT bawaan. Aurora Multi-Master (sekarang Aurora Serverless v2 multi-writer) memungkinkan penulisan ke beberapa AZ secara bersamaan. Kinesis menyimpan data di beberapa AZ secara default. Memilih layanan terkelola dengan FT bawaan adalah cara paling hemat biaya untuk mencapai arsitektur tanpa waktu henti.

Perancangan HA atau FT hanya sebaik pengujian yang Anda lakukan. AWS merekomendasikan penggunaan AWS Fault Injection Simulator (FIS) untuk menjalankan eksperimen terkendali yang menghentikan instans, membatasi API, atau menyuntikkan kegagalan jaringan. Anda harus memverifikasi bahwa failover benar-benar selesai dalam RTO Anda, data tidak hilang melebihi RPO Anda, dan alarm terpicu dengan benar. Hari pengujian rutin dan latihan rekayasa kekacauan mengungkap celah dalam asumsi ketahanan Anda sebelum insiden produksi terjadi.

Uji pemahaman Anda tentang konsep AWS Solutions Architect (SAA-C03) dari pelajaran ini.

Dalam pelajaran ini Anda mempelajari bahwa: High Availability meminimalkan waktu henti melalui pemulihan otomatis (RTO dalam hitungan menit), Fault Tolerance menghilangkan waktu henti melalui redundansi aktif (RTO nol), dan biaya meningkat secara signifikan pada setiap tingkat ketahanan. Menghilangkan Single Points of Failure adalah dasar dari kedua pendekatan tersebut. Selanjutnya kita akan mempelajari pola multi-AZ untuk layanan stateful.