# Definisi
Laporan resmi ini membahas tentang keandalan di cloud, yang menjelaskan praktik terbaik untuk keempat area ini:
+ Fondasi
+ Arsitektur Beban Kerja
+ Manajemen Perubahan
+ Manajemen Kegagalan
Untuk mencapai keandalan, Anda harus mengawalinya dengan fondasi—sebuah lingkungan tempat kuota layanan (service quotas) dan topologi jaringan mengakomodasi beban kerja. Arsitektur beban kerja sistem terdistribusi harus didesain untuk dapat mencegah dan memitigasi kegagalan. Beban kerja harus menangani perubahan-perubahan yang terjadi dalam permintaan dan persyaratan, serta harus didesain untuk dapat mendeteksi kegagalan dan melakukan pemulihan mandiri secara otomatis.
**Topics**
+ [Ketahanan, dan komponen keandalan](resiliency-and-the-components-of-reliability.md)
+ [Ketersediaan](availability.md)
+ [Tujuan Pemulihan Bencana (DR)](disaster-recovery-dr-objectives.md)
# Ketahanan, dan komponen keandalan
Keandalan beban kerja di cloud bergantung pada sejumlah faktor, dan faktor utamanya adalah *Ketahanan*:
+ **Ketahanan** adalah kemampuan beban kerja untuk pulih dari gangguan infrastruktur atau layanan, secara dinamis memperoleh sumber daya komputasi untuk memenuhi permintaan, dan memitigasi gangguan, seperti kesalahan konfigurasi atau masalah jaringan sementara.
Faktor-faktor lain yang memengaruhi keandalan beban kerja adalah sebagai berikut:
+ Keunggulan Operasional, yang mencakup otomatisasi perubahan, penggunaan playbook untuk merespons kegagalan, dan Peninjauan Kesiapan Operasional (ORR) untuk mengonfirmasi bahwa aplikasi sudah siap untuk operasi produksi.
+ Keamanan, yang mencakup pencegahan bahaya terhadap data atau infrastruktur yang mungkin disebabkan oleh pelaku kejahatan, yang dapat mengganggu ketersediaan. Misalnya, enskripsi cadangan untuk memastikan keamanan data.
+ Efisiensi Kinerja, yang mencakup pembuatan desain untuk tingkat permintaan maksimum dan meminimalkan latensi untuk beban kerja Anda.
+ Optimasi Biaya, yang mencakup kompromi-kompromi seperti pilihan untuk mengeluarkan lebih banyak biaya untuk instans EC2 guna mencapai stabilitas statis, atau untuk mengandalkan penskalaan otomatis saat kapasitas yang lebih besar diperlukan.
Ketahanan adalah fokus utama laporan resmi ini.
Empat aspek lainnya juga penting dan tercakup ke dalam masing-masing pilar [Kerangka Kerja AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/). Banyak praktik terbaik yang diuraikan di sini juga menangani aspek-aspek keandalan tersebut, namun yang difokuskan di sini adalah ketahanan.
# Ketersediaan
*Ketersediaan* (juga dikenal dengan *ketersediaan layanan*) adalah metrik yang umum digunakan untuk mengukur ketahanan secara kuantitatif, serta merupakan target tujuan ketahanan.
+ **Ketersediaan** adalah persentase waktu ketika beban kerja tersedia untuk digunakan.
*Tersedia untuk digunakan* artinya beban kerja berhasil memberikan kinerja sesuai fungsinya yang disepakati ketika diperlukan.
Persentase ini dihitung dengan jangka waktu tertentu, seperti bulan, tahun, atau tiga tahun ke belakang. Dengan memberlakukan interpretasi seketat mungkin, maka ketersediaan akan berkurang setiap kali aplikasi tidak beroperasi secara normal, termasuk gangguan terjadwal dan di luar jadwal. Kami mendefinisikan *ketersediaan* seperti berikut:
![\[\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/availability-formula.png)
+ Ketersediaan adalah persentase waktu aktif (seperti 99,9%) selama jangka waktu tertentu (umumnya satu bulan atau tahun)
+ Penulisan singkat yang umum digunakan adalah “jumlah angka sembilan”; misalnya, “lima angka sembilan” artinya tingkat ketersediaannya adalah 99,999%
+ Beberapa pelanggan memilih untuk mengecualikan waktu henti layanan terjadwal (misalnya pemeliharaan terencana) dari *Total Waktu* dalam formula. Namun demikian, ini tidak disarankan, karena pengguna Anda kemungkinan ingin menggunakan layanan Anda selama waktu-waktu tersebut.
Berikut ini adalah tabel tujuan desain ketersediaan aplikasi umum dan durasi maksimum gangguan yang dapat terjadi dalam satu tahun namun tetap memenuhi tujuan-tujuan yang sudah ditetapkan. Tabel ini berisi contoh-contoh tipe aplikasi yang umum kita lihat pada tiap-tiap tingkatan ketersediaan. Di sepanjang dokumen ini, kita mengacu pada nilai-nilai ini.
| Ketersediaan | Ketidaktersediaan Maksimum (per tahun) | Kategori Aplikasi |
| --- | --- | --- |
| 99% | 3 hari 15 jam | Pemrosesan batch, ekstraksi data, transfer, dan tugas-tugas pemuatan |
| 99,9% | 8 jam 45 menit | Alat internal seperti manajemen pengetahuan, pelacakan proyek |
| 99,95% | 4 jam 22 menit | Niaga online, titik penjualan |
| 99,99% | 52 menit | Pengiriman video, beban kerja siaran |
| 99,999% | 5 menit | Transaksi ATM, beban kerja telekomunikasi |
**Mengukur ketersediaan berdasarkan permintaan.** Untuk layanan Anda, mungkin akan lebih mudah untuk menghitung permintaan yang berhasil dan gagal daripada “waktu yang tersedia untuk digunakan”. Dalam kasus ini, dapat digunakan hitungan berikut:
![\[Mathematical formula for calculating availability using successful responses divided by valid requests.\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/availability-formula-requests.png)
Ini sering kali dihitung untuk periode satu menit atau lima menit. Lalu, persentase waktu aktif bulanan (pengukuran ketersediaan berbasis waktu) dapat dihitung dari rata-rata semua periode ini. Jika tidak ada permintaan yang diterima dalam jangka waktu tertentu, maka aplikasi terhitung 100% tersedia untuk waktu tersebut.
**Menghitung ketersediaan dengan dependensi keras.** Banyak sekali sistem yang memiliki dependensi keras (hard dependency) pada sistem lain, di mana gangguan pada sebuah sistem dependen secara langsung diartikan sebagai gangguan pada sistem yang menginvokasi. Ini adalah kebalikan dari dependensi lembut (soft dependency), di mana sebuah kegagalan yang terjadi pada sistem dependen diimbangi di dalam aplikasi. Ketika dependensi keras terjadi, ketersediaan sistem yang menginvokasi adalah produk dari ketersediaan sistem dependen tersebut. Misalnya, jika Anda memiliki sistem yang dirancang untuk ketersediaan 99,99% yang memiliki dependensi keras pada dua sistem independen lain yang masing-masing dirancang untuk ketersediaan 99,99%, maka secara teori beban kerja tersebut dapat meraih ketersediaan 99,97%:
Availinvok × Avail*dep1* × Avail*dep2* = Availworkload
99,99% × 99,99% × 99,99% = 99,97%
Oleh karena itu, penting untuk memahami dependensi Anda serta tujuan-tujuan desain ketersediaannya saat Anda menghitung ketersediaan Anda sendiri.
**Menghitung ketersediaan dengan komponen redundan.** Ketika suatu sistem melibatkan penggunaan komponen redundan dan independen (misalnya sumber daya redundan di beberapa Zona Ketersediaan yang berbeda), maka secara teori, ketersediaan sistem tersebut dihitung 100% dikurangi hasil tingkat kegagalan komponen. Misalnya, jika suatu sistem memanfaatkan dua komponen independen, masing-masing memiliki ketersediaan 99,9%, maka ketersediaan efektif dependensi ini adalah 99,9999%:
![\[Diagram showing calculation of availability with redundant components in a system.\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/image2.png)
Availeffective = *Avail*MAX − ((100%−Availdependency)×(100%−Availdependency))
99,9999% = 100% − (0,1%×0,1%)
*Perhitungan pintasan*: Jika ketersediaan semua komponen di dalam hitungan Anda hanya terdiri dari angka sembilan, maka Anda dapat menjumlah hitungan jumlah angka sembilan untuk mendapatkan jawaban. Pada contoh di atas, dua komponen independen dan redundan dengan ketersediaan tiga angka sembilan menghasilkan enam angka sembilan.
**Menghitung ketersediaan dependensi.** Beberapa dependensi menyediakan panduan tentang ketersediaannya, termasuk tujuan desain ketersediaan untuk banyak layanan AWS. Tetapi pada kasus-kasus di mana ini tidak tersedia (misalnya, komponen yang produsennya tidak mempublikasikan informasi ketersediaan), satu cara untuk menghitung adalah dengan menentukan **Waktu Rata-rata Antara Kegagalan (MTBF)** dan **Waktu Rata-rata Pemulihan (MTTR)**. Hitungan ketersediaan dapat dilakukan dengan:
![\[\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/avail-est-formula.png)
Misalnya, jika MTBF 150 hari dan MTTR 1 jam, maka hitungan ketersediaannya adalah 99,97%.
Untuk detail tambahan, silakan lihat [Availability and Beyond: Memahami dan meningkatkan ketahanan sistem terdistribusi AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-and-beyond-improving-resilience.html), yang dapat membantu Anda menghitung ketersediaan Anda.
**Biaya ketersediaan.** Merancang desain aplikasi untuk tingkat ketersediaan yang lebih tinggi umumnya akan menyebabkan terjadinya peningkatan biaya, sehingga sebaiknya Anda mengidentifikasi kebutuhan ketersediaan yang sebenarnya sebelum mulai merancang desain aplikasi Anda. Tingkat ketersediaan yang tinggi menghadirkan persyaratan pengujian dan validasi yang lebih ketat berdasarkan skenario kegagalan yang lengkap. Tingkat ketersediaan ini memerlukan otomatisasi untuk pemulihan dari semua bentuk kegagalan, dan mengharuskan semua aspek yang ada dalam operasi sistem tersebut dibangun serupa dan diuji dengan standar yang sama. Misalnya, penambahan atau penghapusan kapasitas, deployment atau pembatalan (roll back) pembaruan perangkat lunak atau perubahan konfigurasi, atau migrasi data sistem harus dilakukan sesuai tujuan-tujuan ketersediaan yang dikehendaki. Selain biaya untuk pengembangan perangkat lunak, pada tingkat ketersediaan yang sangat tinggi, inovasi juga terkena dampak dikarenakan adanya kebutuhan untuk bergerak lebih lambat dalam melakukan deployment sistem. Oleh karena itu, panduan harus dibuat menyeluruh dalam menerapkan standar dan mempertimbangkan target-target ketersediaan yang tepat untuk seluruh siklus hidup pengoperasian sistem.
Faktor lain yang menyebabkan peningkatan biaya dalam sistem yang beroperasi dengan tujuan desain ketersediaan yang lebih tinggi adalah pemilihan dependensi. Pada tujuan-tujuan yang lebih tinggi ini, serangkaian perangkat lunak atau layanan yang dapat dipilih sebagai dependensi berkurang berdasarkan layanan mana yang telah memiliki investasi mendalam yang telah kami jelaskan sebelumnya untuk Anda. Seiring dengan meningkatnya tujuan-tujuan desain ketersediaan, merupakan hal umum untuk menemukan lebih sedikit layanan multi-tujuan (seperti basis data relasional) dan lebih banyak layanan yang dibuat khusus. Alasannya adalah bahwa jenis-jenis layanan yang dibuat khusus lebih mudah untuk dievaluasi, diuji, dan diotomatisasi, serta memiliki lebih sedikit potensi interaksi kejutan dengan fungsionalitas yang disertakan namun tidak digunakan.
# Tujuan Pemulihan Bencana (DR)
Selain tujuan ketersediaan, strategi ketahanan Anda juga harus menyertakan tujuan-tujuan Pemulihan Bencana (DR) berdasarkan strategi yang digunakan untuk memulihkan beban kerja Anda apabila terjadi peristiwa bencana. Pemulihan Bencana berfokus pada tujuan-tujuan pemulihan satu kali untuk merespons terjadinya bencana alam, kegagalan teknis skala besar, atau ancaman manusia seperti serangan atau kesalahan. Ini berbeda dengan ketersediaan yang mengukur rata-rata ketahanan selama kurun waktu tertentu ketika merespons terjadinya kegagalan komponen, lonjakan beban, atau bug perangkat lunak.
**sasaran waktu pemulihan (RTO)** Didefinisikan oleh organisasi. RTO adalah jeda waktu maksimum yang dapat diterima antara gangguan layanan dan pemulihan layanan. Ini menentukan apa yang dianggap sebagai jendela waktu yang dapat diterima ketika layanan tidak tersedia.
**Sasaran Titik Pemulihan (RPO)** Didefinisikan oleh organisasi. RPO adalah jumlah waktu maksimum yang dapat diterima sejak titik pemulihan data terakhir. Ini menentukan apa yang dianggap sebagai kehilangan data yang dapat diterima antara titik pemulihan terakhir dan gangguan layanan.
![\[Business continuity timeline showing RPO, disaster event, and RTO with data loss and downtime periods.\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/business-continuity.png)
*Hubungan antara RPO (Sasaran Titik Pemulihan), RTO (Sasaran Waktu Pemulihan), dan peristiwa bencana.*
RTO serupa dengan MTTR (Rata-Rata Waktu hingga Pemulihan) yakni keduanya sama-sama mengukur waktu antara sejak dari dimulainya penghentian (outage) hingga pemulihan beban kerja. Namun, MTTR adalah nilai rata-rata yang diambil selama beberapa peristiwa yang berdampak pada ketersediaan dalam kurun waktu tertentu, sedangkan RTO adalah target, atau nilai maksimum yang diizinkan, untuk *satu* peristiwa yang berdampak terhadap ketersediaan.