Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memahami ketersediaan
Ketersediaan adalah salah satu cara utama kita dapat mengukur ketahanan secara kuantitatif. Kami mendefinisikan ketersediaan, *A*, sebagai persentase waktu beban kerja tersedia untuk digunakan. Ini adalah rasio dari “uptime” yang diharapkan (tersedia) dengan total waktu yang diukur (“uptime” yang diharapkan ditambah “downtime” yang diharapkan).
![\[Gambar persamaan. A = uptime/(uptime + downtime)\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability.png)
Untuk lebih memahami rumus ini, kita akan melihat bagaimana mengukur uptime dan downtime. Pertama, kami ingin tahu berapa lama beban kerja akan berjalan tanpa kegagalan. Kami menyebutnya *waktu rata-rata antara kegagalan* (MTBF), waktu rata-rata antara ketika beban kerja memulai operasi normal dan kegagalan berikutnya. Kemudian, kami ingin tahu berapa lama waktu yang dibutuhkan untuk pulih setelah gagal.
Kami menyebutnya *mean time to repair (atau recovery)* (MTTR), periode waktu ketika beban kerja tidak tersedia saat subsistem yang gagal diperbaiki atau dikembalikan ke layanan. Periode waktu penting dalam MTTR adalah *waktu rata-rata untuk deteksi* (MTTD), jumlah waktu antara kegagalan yang terjadi dan ketika operasi perbaikan dimulai. Diagram berikut menunjukkan bagaimana semua metrik ini terkait.
![\[Diagram yang menunjukkan hubungan antara MTTD, MTTR, dan MTBF\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability-metrics.png)
Dengan demikian kita dapat menyatakan ketersediaan, *A*, menggunakan MTBF, waktu beban kerja naik, dan MTTR, waktu beban kerja turun.
![\[Gambar persamaan. A = MTBF/(MTBF+MTTR)\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation2.png)
Dan probabilitas beban kerja “turun” (yaitu, tidak tersedia) adalah probabilitas kegagalan, *F*.
![\[Gambar persamaan. F = 1 - A\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation3.png)
[Keandalan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/reliability.html) adalah kemampuan beban kerja untuk melakukan hal yang benar, ketika diminta, dalam waktu respons yang ditentukan. Inilah ukuran ketersediaan. Memiliki beban kerja gagal lebih jarang (MTBF lebih lama) atau memiliki waktu perbaikan yang lebih pendek (MTTR yang lebih pendek) meningkatkan ketersediaannya.
**Aturan 1**
Kegagalan yang lebih jarang (MTBF lebih lama), waktu deteksi kegagalan yang lebih pendek (MTTD lebih pendek), dan waktu perbaikan yang lebih pendek (MTTR lebih pendek) adalah tiga faktor yang digunakan untuk meningkatkan ketersediaan dalam sistem terdistribusi.
**Topics**
+ [Ketersediaan sistem terdistribusi](distributed-system-availability.md)
+ [Ketersediaan dengan dependensi](availability-with-dependencies.md)
+ [Ketersediaan dengan redundansi](availability-with-redundancy.md)
+ [Teorema CAP](cap-theorem.md)
+ [Toleransi kesalahan dan isolasi kesalahan](fault-tolerance-and-fault-isolation.md)
# Ketersediaan sistem terdistribusi
Sistem terdistribusi terdiri dari komponen perangkat lunak dan komponen perangkat keras. Beberapa komponen perangkat lunak itu sendiri mungkin merupakan sistem terdistribusi lain. Ketersediaan komponen perangkat keras dan perangkat lunak yang mendasarinya memengaruhi ketersediaan beban kerja Anda yang dihasilkan.
Perhitungan ketersediaan menggunakan MTBF dan MTTR berakar pada sistem perangkat keras. Namun, sistem terdistribusi gagal karena alasan yang sangat berbeda dari perangkat keras. Di mana produsen dapat secara konsisten menghitung waktu rata-rata sebelum komponen perangkat keras habis, pengujian yang sama tidak dapat diterapkan pada komponen perangkat lunak dari sistem terdistribusi. Perangkat keras biasanya mengikuti kurva “bak mandi” tingkat kegagalan, sementara perangkat lunak mengikuti kurva terhuyung-huyung yang dihasilkan oleh cacat tambahan yang diperkenalkan dengan setiap rilis baru (lihat Keandalan [Perangkat Lunak](https://users.ece.cmu.edu/~koopman/des_s99/sw_reliability).)
![\[Diagram yang menunjukkan tingkat kegagalan perangkat keras dan perangkat lunak\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/availability-and-beyond-improving-resilience/images/failure-rates.png)
Selain itu, perangkat lunak dalam sistem terdistribusi biasanya berubah pada tingkat yang secara eksponensial lebih tinggi daripada perangkat keras. [Misalnya, hard drive magnetik standar mungkin memiliki tingkat kegagalan tahunan rata-rata (AFR) 0,93% yang, dalam praktiknya untuk HDD, dapat berarti umur setidaknya 3-5 tahun sebelum mencapai periode keausan, berpotensi lebih lama (lihat Data dan Statistik Hard Drive Backblaze, 2020.)](https://www.backblaze.com/b2/hard-drive-test-data.html) Hard drive tidak berubah secara material selama masa hidup itu, di mana, dalam 3-5 tahun, sebagai contoh, Amazon mungkin menyebarkan lebih dari 450 hingga 750 juta perubahan pada sistem perangkat lunaknya. (Lihat [Amazon Builders' Library — Mengotomatiskan penerapan yang aman](https://aws.amazon.com/about-aws/whats-new/2020/06/new-abl-article-automating-safe-hands-off-deployments/) dan lepas tangan.)
Perangkat keras juga tunduk pada konsep usang yang direncanakan, yaitu memiliki masa pakai bawaan, dan perlu diganti setelah jangka waktu tertentu. (Lihat [Konspirasi Bola Lampu Hebat](https://spectrum.ieee.org/tech-history/dawn-of-electronics/the-great-lightbulb-conspiracy).) Perangkat lunak, secara teoritis, tidak tunduk pada kendala ini, tidak memiliki periode aus dan dapat dioperasikan tanpa batas waktu.
Semua ini berarti bahwa model pengujian dan prediksi yang sama yang digunakan untuk perangkat keras untuk menghasilkan nomor MTBF dan MTTR tidak berlaku untuk perangkat lunak. Ada ratusan upaya untuk membangun model untuk memecahkan masalah ini sejak tahun 1970-an, tetapi semuanya umumnya terbagi dalam dua kategori, pemodelan prediksi dan pemodelan estimasi. (Lihat [Daftar model keandalan perangkat lunak](https://en.wikipedia.org/wiki/List_of_software_reliability_models).)
Dengan demikian, menghitung MTBF dan MTTR berwawasan ke depan untuk sistem terdistribusi, dan dengan demikian ketersediaan berwawasan ke depan, akan selalu diturunkan dari beberapa jenis prediksi atau perkiraan. Mereka dapat dihasilkan melalui pemodelan prediktif, simulasi stokastik, analisis historis, atau pengujian yang ketat, tetapi perhitungan tersebut bukan jaminan uptime atau downtime.
Alasan mengapa sistem terdistribusi gagal di masa lalu mungkin tidak pernah terulang kembali. Alasan kegagalan di masa depan cenderung berbeda dan mungkin tidak dapat diketahui. Mekanisme pemulihan yang diperlukan mungkin juga berbeda untuk kegagalan masa depan daripada yang digunakan di masa lalu dan membutuhkan waktu yang sangat berbeda.
Selain itu, MTBF dan MTTR adalah rata-rata. Akan ada beberapa varians dari nilai rata-rata ke nilai aktual yang terlihat (standar deviasi, σ, mengukur variasi ini). Dengan demikian, beban kerja mungkin mengalami waktu yang lebih pendek atau lebih lama antara kegagalan dan waktu pemulihan dalam penggunaan produksi aktual.
Karena itu, ketersediaan komponen perangkat lunak yang membentuk sistem terdistribusi masih penting. Perangkat lunak dapat gagal karena berbagai alasan (dibahas lebih lanjut di bagian berikutnya) dan berdampak pada ketersediaan beban kerja. Dengan demikian, untuk sistem terdistribusi yang sangat tersedia, fokus yang sama untuk menghitung, mengukur, dan meningkatkan ketersediaan komponen perangkat lunak harus diberikan untuk perangkat keras dan subsistem perangkat lunak eksternal.
**Aturan 2**
Ketersediaan perangkat lunak dalam beban kerja Anda merupakan faktor penting dari ketersediaan keseluruhan beban kerja Anda dan harus menerima fokus yang sama dengan komponen lainnya.
Penting untuk dicatat bahwa meskipun MTBF dan MTTR sulit diprediksi untuk sistem terdistribusi, mereka masih memberikan wawasan kunci tentang cara meningkatkan ketersediaan. Mengurangi frekuensi kegagalan (MTBF yang lebih tinggi) dan mengurangi waktu untuk pulih setelah kegagalan terjadi (MTTR yang lebih rendah) keduanya akan mengarah pada ketersediaan empiris yang lebih tinggi.
## Jenis kegagalan dalam sistem terdistribusi
Umumnya ada dua kelas bug dalam sistem terdistribusi yang memengaruhi ketersediaan, dinamai *Bohrbug dan *Heisenbug** (lihat [“A Conversation with Bruce Lindsay”, ACM Queue vol. 2, no](http://queue.acm.org/detail.cfm?id=1036486). 8 — November 2004.)
Bohrbug adalah masalah perangkat lunak fungsional berulang. Dengan input yang sama, bug akan secara konsisten menghasilkan output yang salah yang sama (seperti model atom Bohr deterministik, yang padat dan mudah dideteksi). Jenis bug ini jarang terjadi pada saat beban kerja sampai ke produksi.
Heisenbug adalah bug yang bersifat sementara, artinya hanya terjadi dalam kondisi tertentu dan tidak biasa. Kondisi ini biasanya terkait dengan hal-hal seperti perangkat keras (misalnya, kesalahan perangkat sementara atau spesifik implementasi perangkat keras seperti ukuran register), pengoptimalan kompiler dan implementasi bahasa, kondisi batas (misalnya, sementara di luar penyimpanan), atau kondisi balapan (misalnya, tidak menggunakan semaphore untuk operasi multi-threaded).
Heisenbug merupakan sebagian besar bug dalam produksi dan sulit ditemukan karena sulit dipahami dan tampaknya mengubah perilaku atau menghilang ketika Anda mencoba mengamati atau men-debugnya. Namun, jika Anda me-restart program, operasi yang gagal kemungkinan akan berhasil karena lingkungan operasi sedikit berbeda, menghilangkan kondisi yang memperkenalkan Heisenbug.
Dengan demikian, sebagian besar kegagalan dalam produksi bersifat sementara dan ketika operasi dicoba lagi, tidak mungkin gagal lagi. Agar tangguh, sistem terdistribusi harus toleran terhadap kesalahan terhadap Heisenbugs. Kami akan mengeksplorasi bagaimana hal ini dapat dicapai di bagian [Meningkatkan sistem terdistribusi MTBF](increasing-mtbf.md#increasing-mtbf.title).
# Ketersediaan dengan dependensi
Di bagian sebelumnya, kami menyebutkan bahwa perangkat keras, perangkat lunak, dan kemungkinan sistem terdistribusi lainnya adalah semua komponen beban kerja Anda. Kami menyebut *dependensi* komponen ini, hal-hal yang bergantung pada beban kerja Anda untuk menyediakan fungsinya. Ada dependensi *keras*, yang merupakan hal-hal yang beban kerja Anda tidak dapat berfungsi tanpanya, dan dependensi *lunak* yang ketidaktersediaannya dapat luput dari perhatian atau ditoleransi selama beberapa periode waktu. Dependensi keras berdampak langsung pada ketersediaan beban kerja Anda.
Kami mungkin ingin mencoba dan menghitung ketersediaan maksimum teoritis dari beban kerja. Ini adalah produk dari ketersediaan semua dependensi, termasuk perangkat lunak itu sendiri, (*α* *n* adalah ketersediaan subsistem tunggal) karena masing-masing harus operasional.
![\[Gambar persamaan. A = α 1 X α 2 X... X α n langganan>\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation4.png)
Nomor ketersediaan yang digunakan dalam perhitungan ini biasanya dikaitkan dengan hal-hal seperti SLA atau Tujuan Tingkat Layanan (SLO). SLA menentukan tingkat layanan yang diharapkan akan diterima pelanggan, metrik yang digunakan untuk mengukur layanan, dan remediasi atau penalti (biasanya moneter) jika tingkat layanan tidak tercapai.
Dengan menggunakan rumus di atas, kita dapat menyimpulkan bahwa, murni secara matematis, beban kerja tidak dapat lebih tersedia daripada dependensinya. Namun pada kenyataannya, apa yang biasanya kita lihat adalah bahwa ini tidak terjadi. Beban kerja yang dibangun menggunakan dua atau tiga dependensi dengan ketersediaan 99,99% SLA masih dapat mencapai ketersediaan 99,99% itu sendiri, atau lebih tinggi.
Ini karena seperti yang kami uraikan di bagian sebelumnya, angka ketersediaan ini adalah perkiraan. Mereka memperkirakan atau memprediksi seberapa sering kegagalan terjadi dan seberapa cepat itu dapat diperbaiki. Mereka bukan jaminan downtime. Dependensi sering melebihi ketersediaan yang dinyatakan SLA atau SLO.
Dependensi mungkin juga memiliki tujuan ketersediaan internal yang lebih tinggi yang mereka targetkan kinerja dibandingkan dengan angka yang disediakan di SLA publik. Ini memberikan tingkat mitigasi risiko dalam memenuhi SLA ketika hal yang tidak diketahui atau tidak diketahui terjadi.
Akhirnya, beban kerja Anda mungkin memiliki dependensi yang SLA tidak dapat diketahui atau tidak menawarkan SLA atau SLO. Misalnya, perutean internet di seluruh dunia adalah ketergantungan umum untuk banyak beban kerja, tetapi sulit untuk mengetahui penyedia layanan internet mana yang digunakan lalu lintas global Anda, apakah mereka memiliki SLA, dan seberapa konsisten mereka di seluruh penyedia.
Apa yang semua ini katakan kepada kita adalah bahwa menghitung ketersediaan teoretis maksimum hanya mungkin menghasilkan urutan perhitungan besarnya yang kasar, tetapi dengan sendirinya kemungkinan tidak akurat atau memberikan wawasan yang berarti. Apa yang dikatakan matematika kepada kami adalah bahwa semakin sedikit hal yang bergantung pada beban kerja Anda mengurangi kemungkinan kegagalan secara keseluruhan. Semakin sedikit angka kurang dari satu dikalikan bersama, semakin besar hasilnya.
**Aturan 3**
Mengurangi dependensi dapat berdampak positif pada ketersediaan.
Matematika juga membantu menginformasikan proses pemilihan ketergantungan. Proses seleksi memengaruhi cara Anda mendesain beban kerja Anda, bagaimana Anda memanfaatkan redundansi dalam dependensi untuk meningkatkan ketersediaannya, dan apakah Anda menganggap dependensi tersebut lunak atau keras. Dependensi yang dapat berdampak pada beban kerja Anda harus dipilih dengan cermat. Aturan berikutnya memberikan panduan tentang cara melakukannya.
**Aturan 4**
Secara umum, pilih dependensi yang tujuan ketersediaannya sama dengan atau lebih besar dari sasaran beban kerja Anda.
# Ketersediaan dengan redundansi
Ketika beban kerja menggunakan beberapa subsistem, independen, dan redundan, ia dapat mencapai tingkat ketersediaan teoritis yang lebih tinggi daripada dengan menggunakan subsistem tunggal. Misalnya, pertimbangkan beban kerja yang terdiri dari dua subsistem yang identik. Ini dapat sepenuhnya operasional jika subsistem satu atau subsistem dua beroperasi. Agar seluruh sistem turun, kedua subsistem harus turun pada saat yang bersamaan.
*Jika probabilitas kegagalan satu subsistem adalah 1 *α*, maka probabilitas bahwa dua subsistem redundan turun pada saat yang sama adalah produk dari probabilitas kegagalan masing-masing subsistem, *F* = (1− *α1) × (1− α*).* 2 Untuk beban kerja dengan dua subsistem redundan, menggunakan Persamaan *(3)*, ini memberikan ketersediaan yang didefinisikan sebagai:
![\[Gambar tiga persamaan\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation5.png)
Jadi, untuk dua subsistem yang ketersediaannya 99%, probabilitas bahwa satu gagal adalah 1% dan probabilitas bahwa keduanya gagal adalah (1− 99%) × (1− 99%) = 0,01%. Ini membuat ketersediaan menggunakan dua subsistem redundan 99,99%.
*Ini dapat digeneralisasi untuk memasukkan suku cadang tambahan yang berlebihan, *s*, juga.* Dalam Persamaan *(5)* kami hanya mengasumsikan satu cadangan, tetapi beban kerja mungkin memiliki dua, tiga, atau lebih suku cadang sehingga dapat bertahan dari hilangnya beberapa subsistem secara simultan tanpa memengaruhi ketersediaan. *Jika beban kerja memiliki tiga subsistem dan dua adalah suku cadang, probabilitas bahwa ketiga subsistem gagal pada saat yang sama adalah (1− *α) × (1− α*) × (1− *α*) atau (1− *α*) 3.* Secara umum, beban kerja dengan suku cadang *s* hanya akan gagal jika subsistem *s* \$1 1 gagal.
*Untuk beban kerja dengan *n* subsistem dan suku cadang *s*, *f* adalah jumlah mode kegagalan atau cara subsistem *s* \$1 1 gagal dari n.*
****Ini secara efektif adalah teorema binomial, matematika kombinatorial memilih *k* elemen dari himpunan *n, atau *“*n* pilih k”.**** Dalam hal ini, *k* adalah *s* \$1 1.
![\[Gambar empat persamaan\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation6.png)
Kami kemudian dapat menghasilkan perkiraan ketersediaan umum yang menggabungkan jumlah mode kegagalan dan hemat. (Untuk memahami mengapa ini dalam perkiraan, lihat Lampiran 2 dari Highleyman, dkk. [Melanggar Penghalang Ketersediaan](https://www.amazon.com/Breaking-Availability-Barrier-Survivable-Enterprise/dp/1410792331).)
![\[Gambar empat persamaan\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation7.png)
Hemat dapat diterapkan pada ketergantungan apa pun yang menyediakan sumber daya yang gagal secara independen. Instans Amazon EC2 di AZ yang berbeda atau bucket Amazon S3 berbeda adalah contohnya. Wilayah AWS Menggunakan suku cadang membantu ketergantungan mencapai ketersediaan total yang lebih tinggi untuk mendukung tujuan ketersediaan beban kerja.
**Aturan 5**
Gunakan hemat untuk meningkatkan ketersediaan dependensi dalam beban kerja.
Namun, hemat datang dengan biaya. Setiap biaya cadangan tambahan sama dengan modul asli, biaya mengemudi setidaknya secara linier. Membangun beban kerja yang dapat menggunakan suku cadang juga meningkatkan kompleksitasnya. Itu harus tahu bagaimana mengidentifikasi kegagalan ketergantungan, pekerjaan berat dari itu ke sumber daya yang sehat, dan mengelola kapasitas keseluruhan beban kerja.
Redundansi adalah masalah optimasi. Terlalu sedikit suku cadang, dan beban kerja bisa gagal lebih sering dari yang diinginkan, terlalu banyak suku cadang dan biaya beban kerja terlalu banyak untuk dijalankan. Ada ambang batas di mana menambahkan lebih banyak suku cadang akan lebih mahal daripada ketersediaan tambahan yang mereka capai waran.
***Menggunakan ketersediaan umum kami dengan rumus suku cadang, Persamaan *(7)*, untuk subsistem yang memiliki ketersediaan 99,5%, dengan dua suku cadang ketersediaan beban kerja adalah *A* ≈ 1 − (1) (1) (1−.995) 3 = 99,9999875% (sekitar 3,94 detik waktu henti setahun), dan dengan 10 suku cadang kita mendapatkan A ≈ 1 − (1) (1−.995) 11 = 25.995 5 9 ′ s (perkiraan waktu henti *adalah* 1,26252 × 10 15 m s per tahun, efektif 0).*** Dalam membandingkan dua beban kerja ini, kami telah mengalami peningkatan 5X dalam biaya hemat untuk mencapai waktu henti empat detik lebih sedikit dalam setahun. Untuk sebagian besar beban kerja, kenaikan biaya tidak beralasan untuk peningkatan ketersediaan ini. Gambar berikut menunjukkan hubungan ini.
![\[Diagram yang menunjukkan hasil yang semakin berkurang dari peningkatan hemat\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/availability-and-beyond-improving-resilience/images/effect-of-sparing.png)
Pada tiga suku cadang dan seterusnya, hasilnya adalah sepersekian detik dari waktu henti yang diharapkan dalam setahun, yang berarti bahwa setelah titik ini Anda mencapai area pengembalian yang semakin berkurang. Mungkin ada dorongan untuk “hanya menambahkan lebih banyak” untuk mencapai tingkat ketersediaan yang lebih tinggi, tetapi pada kenyataannya, manfaat biaya menghilang dengan sangat cepat. Menggunakan lebih dari tiga suku cadang tidak memberikan material, keuntungan nyata untuk hampir semua beban kerja ketika subsistem itu sendiri memiliki setidaknya ketersediaan 99%.
**Aturan 6**
Ada batas atas efisiensi biaya hemat. Memanfaatkan suku cadang paling sedikit yang diperlukan untuk mencapai ketersediaan yang dibutuhkan.
Anda harus mempertimbangkan unit kegagalan saat memilih jumlah suku cadang yang benar. Sebagai contoh, mari kita periksa beban kerja yang memerlukan 10 instans EC2 untuk menangani kapasitas puncak dan mereka digunakan dalam satu AZ.
Karena AZ dirancang untuk menjadi batas isolasi kesalahan, unit kegagalan bukan hanya satu instans EC2, karena seluruh instans EC2 senilai AZ dapat gagal bersama. Dalam hal ini, Anda ingin [menambahkan redundansi dengan AZ lain](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html), menerapkan 10 instans EC2 tambahan untuk menangani beban jika terjadi kegagalan AZ, dengan total 20 instans EC2 (mengikuti pola stabilitas statis).
Meskipun ini tampaknya 10 instans EC2 cadangan, ini benar-benar hanya satu AZ cadangan, jadi kami belum melampaui titik pengembalian yang berkurang. Namun, Anda dapat menjadi lebih hemat biaya sekaligus meningkatkan ketersediaan Anda dengan memanfaatkan tiga AZ dan menerapkan lima instans EC2 per AZ.
Ini menyediakan satu AZ cadangan dengan total 15 instans EC2 (dibandingkan dua AZ dengan 20 instans), masih menyediakan 10 instans total yang diperlukan untuk melayani kapasitas puncak selama peristiwa yang memengaruhi satu AZ. Dengan demikian, Anda harus membangun hemat agar toleran terhadap kesalahan di semua batas isolasi kesalahan yang digunakan oleh beban kerja (instance, sel, AZ, dan Wilayah).
# Teorema CAP
Cara lain yang mungkin kita pikirkan tentang ketersediaan adalah dalam kaitannya dengan teorema CAP. Teorema menyatakan bahwa sistem terdistribusi, yang terdiri dari beberapa node yang menyimpan data, tidak dapat secara bersamaan memberikan lebih dari dua dari tiga jaminan berikut:
+ **C** onsistency: Setiap permintaan baca menerima penulisan terbaru atau kesalahan ketika konsistensi tidak dapat dijamin.
+ **Vailability: Setiap permintaan menerima respons non-error, bahkan ketika node sedang down atau tidak tersedia.**
+ Toleransi seni **P**: Sistem terus beroperasi meskipun kehilangan sejumlah pesan yang sewenang-wenang antar node.
(Untuk detail lebih lanjut, lihat Seth Gilbert dan Nancy Lynch, [http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970](http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970) (2002), hal. 51—59.)
Sebagian besar sistem terdistribusi harus mentolerir kegagalan jaringan, dan dengan demikian, partisi jaringan harus diizinkan. Ini berarti bahwa beban kerja ini harus membuat pilihan antara konsistensi dan ketersediaan ketika partisi jaringan terjadi. Jika beban kerja memilih ketersediaan, maka itu selalu mengembalikan respons, tetapi dengan data yang berpotensi tidak konsisten. Jika memilih konsistensi, maka selama partisi jaringan itu akan mengembalikan kesalahan karena beban kerja tidak dapat memastikan konsistensi data.
Untuk beban kerja yang tujuannya adalah untuk menyediakan tingkat ketersediaan yang lebih tinggi, mereka mungkin memilih Availability and Partition tolerance (AP) untuk mencegah pengembalian kesalahan (tidak tersedia) selama partisi jaringan. Ini menghasilkan membutuhkan [model konsistensi yang lebih santai, seperti konsistensi](https://en.wikipedia.org/wiki/Consistency_model) akhirnya atau konsistensi monotonik.
# Toleransi kesalahan dan isolasi kesalahan
Ini adalah dua konsep penting ketika kita berpikir tentang ketersediaan. Toleransi kesalahan adalah kemampuan untuk [menahan kegagalan subsistem](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html) dan mempertahankan ketersediaan (melakukan hal yang benar dalam SLA yang sudah mapan). Untuk menerapkan toleransi kesalahan, beban kerja menggunakan subsistem cadangan (atau redundan). Ketika salah satu subsistem dalam set redundan gagal, yang lain mengambil pekerjaannya, biasanya hampir mulus. Dalam hal ini, suku cadang benar-benar kapasitas cadangan, mereka tersedia untuk mengasumsikan 100% pekerjaan dari subsistem yang gagal. Dengan suku cadang sejati, beberapa kegagalan subsistem diperlukan untuk menghasilkan dampak buruk pada beban kerja.
Isolasi kesalahan meminimalkan ruang lingkup dampak ketika kegagalan memang terjadi. Ini biasanya diimplementasikan dengan modularisasi. Beban kerja dipecah menjadi subsistem kecil yang gagal secara independen dan dapat diperbaiki secara terpisah. Kegagalan modul [tidak menyebar di luar modul](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html). Ide ini mencakup baik secara vertikal, di seluruh fungsionalitas yang berbeda dalam beban kerja, dan horizontal, di beberapa subsistem yang menyediakan fungsionalitas yang sama. Modul-modul ini bertindak sebagai wadah kesalahan yang membatasi ruang lingkup dampak selama suatu peristiwa.
Pola arsitektur bidang kontrol, bidang data, dan stabilitas statis secara langsung mendukung penerapan toleransi kesalahan dan isolasi kesalahan. Artikel Perpustakaan Pembangun Amazon [Stabilitas statis menggunakan Availability Zones](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) memberikan definisi yang baik untuk istilah-istilah ini dan bagaimana penerapannya untuk membangun beban kerja yang tangguh dan sangat tersedia. Whitepaper ini menggunakan pola-pola ini di bagian [Merancang sistem terdistribusi yang sangat tersediaAWS, dan kami juga merangkum definisinya di](designing-highly-available-distributed-systems-on-aws.md#designing-highly-available-distributed-systems-on-aws.title) sini.
+ **Control plane** — Bagian dari beban kerja yang terlibat dalam membuat perubahan: menambahkan sumber daya, menghapus sumber daya, memodifikasi sumber daya, dan menyebarkan perubahan tersebut ke tempat yang dibutuhkan. Pesawat kontrol biasanya lebih kompleks dan memiliki bagian yang lebih bergerak daripada pesawat data, dan dengan demikian secara statistik lebih mungkin gagal dan memiliki ketersediaan yang lebih rendah.
+ **Bidang data** — Bagian dari beban kerja yang menyediakan fungsionalitas day-to-day bisnis. Pesawat data cenderung lebih sederhana dan beroperasi pada volume yang lebih tinggi daripada pesawat kontrol, yang mengarah ke ketersediaan yang lebih tinggi.
+ **Stabilitas statis** — Kemampuan beban kerja untuk melanjutkan operasi yang benar meskipun ada gangguan ketergantungan. Salah satu metode implementasi adalah menghapus dependensi bidang kontrol dari pesawat data. Metode lain adalah menggabungkan dependensi beban kerja secara longgar. Mungkin beban kerja tidak melihat informasi yang diperbarui (seperti hal-hal baru, hal-hal yang dihapus, atau hal-hal yang dimodifikasi) yang seharusnya disampaikan oleh ketergantungannya. Namun, semua yang dilakukannya sebelum ketergantungan menjadi terganggu terus bekerja.
Ketika kita berpikir tentang penurunan beban kerja, ada dua pendekatan tingkat tinggi yang dapat kita pertimbangkan untuk pemulihan. Metode pertama adalah menanggapi gangguan itu setelah itu terjadi, mungkin menggunakan AWS Auto Scaling untuk menambah kapasitas baru. Metode kedua adalah mempersiapkan gangguan tersebut sebelum terjadi, mungkin dengan menyediakan infrastruktur beban kerja secara berlebihan sehingga dapat terus beroperasi dengan benar tanpa memerlukan sumber daya tambahan.
Sistem yang stabil secara statis menggunakan pendekatan yang terakhir. Ini menyediakan kapasitas cadangan untuk tersedia selama kegagalan. Metode ini menghindari pembuatan ketergantungan pada bidang kontrol di jalur pemulihan beban kerja untuk menyediakan kapasitas baru untuk pulih dari kegagalan. Selain itu, penyediaan kapasitas baru untuk berbagai sumber daya membutuhkan waktu. Sambil menunggu kapasitas baru, beban kerja Anda dapat kelebihan beban oleh permintaan yang ada dan mengalami degradasi lebih lanjut, yang menyebabkan “kecoklatan” atau kehilangan ketersediaan total. Namun, Anda juga harus mempertimbangkan implikasi biaya dari penggunaan kapasitas yang telah disediakan sebelumnya terhadap tujuan ketersediaan Anda.
Stabilitas statis menyediakan dua aturan berikutnya untuk beban kerja ketersediaan tinggi.
**Aturan 7**
Jangan mengambil dependensi pada pesawat kontrol di bidang data Anda, terutama selama pemulihan.
**Aturan 8**
Gabungkan dependensi secara longgar sehingga beban kerja Anda dapat beroperasi dengan benar meskipun ada gangguan ketergantungan, jika memungkinkan.