Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Merancang sistem terdistribusi yang sangat tersedia di AWS
Bagian sebelumnya sebagian besar tentang ketersediaan teoritis beban kerja dan apa yang dapat mereka capai. Mereka adalah seperangkat konsep penting yang perlu diingat saat Anda membangun sistem terdistribusi. Mereka akan membantu menginformasikan proses pemilihan ketergantungan Anda dan bagaimana Anda menerapkan redundansi.
Kami juga melihat hubunganMTTD,MTTR, dan MTBF ketersediaan. Bagian ini akan memperkenalkan panduan praktis berdasarkan teori sebelumnya. Singkatnya, beban kerja teknik untuk ketersediaan tinggi bertujuan untuk meningkatkan MTBF dan mengurangi MTTR serta. MTTD
Meskipun menghilangkan semua kegagalan akan ideal, itu tidak realistis. Dalam sistem terdistribusi besar dengan dependensi yang ditumpuk dalam, kegagalan akan terjadi. “Semuanya gagal sepanjang waktu” (lihat Werner Vogels,, Amazon.comCTO, [10 Pelajaran dari 10 Tahun Amazon Web Services](https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html).) dan “Anda tidak dapat membuat undang-undang terhadap kegagalan [jadi] fokus pada deteksi dan respons cepat.” (lihat Chris Pinkham, anggota pendiri, EC2 tim Amazon, [ARC335Merancang untuk kegagalan: Merancang sistem tangguh aktif) AWS](https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Designing_for_failure_Architecting_resilient_systems_on_AWS_ARC335-R1.pdf)
Apa artinya ini adalah bahwa seringkali Anda tidak memiliki kendali atas apakah kegagalan terjadi. Apa yang dapat Anda kontrol adalah seberapa cepat Anda mendeteksi kegagalan dan melakukan sesuatu tentang hal itu. Jadi, sementara peningkatan masih MTBF merupakan komponen penting dari ketersediaan tinggi, perubahan paling signifikan yang dimiliki pelanggan dalam kendali mereka adalah mengurangi MTTD danMTTR.
**Topics**
+ [Mengurangi MTTD](reducing-mttd.md)
+ [Mengurangi MTTR](reducing-mttr.md)
+ [Meningkat MTBF](increasing-mtbf.md)
# Mengurangi MTTD
MTTDMengurangi kegagalan berarti menemukan kegagalan secepat mungkin. Memperpendek MTTD didasarkan pada observabilitas, atau bagaimana Anda telah menginstrumentasi beban kerja Anda untuk memahami statusnya. Pelanggan harus memantau metrik *Pengalaman Pelanggan* mereka di subsistem kritis beban kerja mereka sebagai cara untuk secara proaktif mengidentifikasi kapan masalah terjadi (lihat [Lampiran 1 — MTTD dan metrik MTTR penting untuk informasi lebih lanjut tentang metrik](appendix-1-mttd-and-mttr-critical-metrics.md) ini. ). Pelanggan dapat menggunakan [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) untuk membuat *kenari* yang memantau Anda APIs dan konsol untuk mengukur pengalaman pengguna secara proaktif. Ada sejumlah mekanisme pemeriksaan kesehatan lain yang dapat digunakan untuk meminimalkanMTTD, seperti pemeriksaan kesehatan [Elastic Load Balancing (ELB), pemeriksaan kesehatan](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-elb-healthcheck.html) [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-types.html), dan banyak lagi. (Lihat [Amazon Builders' Library — Menerapkan](https://aws.amazon.com/builders-library/implementing-health-checks/) pemeriksaan kesehatan.)
Pemantauan Anda juga harus dapat mendeteksi kegagalan sebagian dari sistem secara keseluruhan dan dalam subsistem individu Anda. [Metrik ketersediaan, kegagalan, dan latensi Anda harus menggunakan dimensi batas isolasi kesalahan Anda sebagai dimensi metrik. CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension) Misalnya, pertimbangkan satu EC2 instance yang merupakan bagian dari arsitektur berbasis sel, di use1-az1 AZ, di Wilayah us-east-1, yang merupakan bagian dari pembaruan beban kerja yang merupakan bagian dari subsistem bidang kontrolnya. API Ketika server mendorong metriknya, ia dapat menggunakan id instans, AZ, Wilayah, API nama, dan nama subsistem sebagai dimensi. Ini memungkinkan Anda untuk memiliki observabilitas dan mengatur alarm di masing-masing dimensi ini untuk mendeteksi kegagalan.
# Mengurangi MTTR
Setelah kegagalan ditemukan, sisa MTTR waktu adalah perbaikan atau mitigasi dampak yang sebenarnya. Untuk memperbaiki atau mengurangi kegagalan, Anda harus tahu apa yang salah. Ada dua kelompok kunci metrik yang memberikan wawasan selama fase ini: 1/ metrik *Penilaian Dampak* dan 2/ metrik Kesehatan *Operasional*. Kelompok pertama memberi tahu Anda ruang lingkup dampak selama kegagalan, mengukur jumlah atau persentase pelanggan, sumber daya, atau beban kerja yang terkena dampak. Kelompok kedua membantu mengidentifikasi *mengapa* ada dampak. Setelah mengapa ditemukan, operator dan otomatisasi dapat merespons dan menyelesaikan kegagalan. Lihat [Lampiran 1 — MTTD dan metrik MTTR penting untuk informasi lebih lanjut tentang metrik](appendix-1-mttd-and-mttr-critical-metrics.md) ini.
**Aturan 9**
Observabilitas dan instrumentasi sangat penting untuk mengurangi MTTD dan. MTTR
## Rute di sekitar kegagalan
Pendekatan tercepat untuk mengurangi dampak adalah melalui subsistem cepat gagal yang mengelilingi kegagalan. Pendekatan ini menggunakan redundansi untuk mengurangi MTTR dengan cepat menggeser pekerjaan subsistem yang gagal ke cadangan. Redundansi dapat berkisar dari proses perangkat lunak, EC2 instance, hingga beberapa, hingga beberapa AZs Wilayah.
Subsistem cadangan dapat mengurangi MTTR turun menjadi hampir nol. Waktu pemulihan hanya apa yang diperlukan untuk mengalihkan pekerjaan ke cadangan siaga. Ini sering terjadi dengan latensi minimal dan memungkinkan pekerjaan selesai dalam yang ditentukanSLA, menjaga ketersediaan sistem. Ini menghasilkan MTTRs yang dialami sebagai penundaan ringan, bahkan mungkin tidak terlihat, daripada periode tidak tersedianya yang berkepanjangan.
Misalnya, jika layanan Anda menggunakan EC2 instans di belakang Application Load Balancer ALB (), Anda dapat mengonfigurasi pemeriksaan kesehatan pada interval sekecil lima detik dan hanya memerlukan dua pemeriksaan kesehatan yang gagal sebelum target ditandai sebagai tidak sehat. Ini berarti bahwa dalam 10 detik, Anda dapat mendeteksi kegagalan dan berhenti mengirim lalu lintas ke host yang tidak sehat. Dalam hal ini, MTTR secara efektif sama dengan MTTD karena segera setelah kegagalan terdeteksi, itu juga dikurangi.
Inilah yang coba *dicapai oleh beban kerja ketersediaan tinggi* atau *ketersediaan berkelanjutan*. Kami ingin dengan cepat merutekan kegagalan dalam beban kerja dengan cepat mendeteksi subsistem yang gagal, menandainya sebagai gagal, berhenti mengirim lalu lintas ke mereka, dan sebagai gantinya mengirim lalu lintas ke subsistem yang berlebihan.
Perhatikan bahwa menggunakan mekanisme fail-fast semacam ini membuat beban kerja Anda sangat sensitif terhadap kesalahan sementara. Dalam contoh yang diberikan, pastikan bahwa pemeriksaan kesehatan penyeimbang beban Anda melakukan pemeriksaan kesehatan *dangkal* atau [https://aws.amazon.com/builders-library/implementing-health-checks/](https://aws.amazon.com/builders-library/implementing-health-checks/) hanya pada instance, bukan menguji dependensi atau alur kerja (sering disebut sebagai pemeriksaan kesehatan *mendalam*). Ini akan membantu mencegah penggantian instance yang tidak perlu selama kesalahan sementara yang memengaruhi beban kerja.
Observabilitas dan kemampuan untuk mendeteksi kegagalan dalam subsistem sangat penting untuk perutean di sekitar kegagalan untuk berhasil. Anda harus mengetahui ruang lingkup dampaknya sehingga sumber daya yang terkena dampak dapat ditandai sebagai tidak sehat atau gagal dan dikeluarkan dari layanan sehingga dapat dialihkan. Misalnya, jika satu AZ mengalami gangguan sebagian layanan, instrumentasi Anda harus dapat mengidentifikasi bahwa ada masalah yang dilokalkan AZ untuk merutekan semua sumber daya di AZ tersebut hingga pulih.
Mampu merutekan kegagalan mungkin juga memerlukan perkakas tambahan tergantung pada lingkungan. Menggunakan contoh sebelumnya dengan EC2 contoh di belakangALB, bayangkan bahwa instance dalam satu AZ mungkin melewati pemeriksaan kesehatan lokal, tetapi gangguan AZ yang terisolasi menyebabkan mereka gagal terhubung ke database mereka di AZ yang berbeda. Dalam hal ini, pemeriksaan kesehatan load balancing tidak akan menghilangkan instans tersebut dari layanan. Mekanisme otomatis yang berbeda akan diperlukan untuk [menghapus AZ dari penyeimbang beban](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) atau memaksa instans untuk gagal dalam pemeriksaan kesehatan mereka, yang bergantung pada identifikasi bahwa ruang lingkup dampaknya adalah AZ. Untuk beban kerja yang tidak menggunakan penyeimbang beban, metode serupa akan diperlukan untuk mencegah sumber daya di AZ tertentu menerima unit kerja atau menghapus kapasitas dari AZ sama sekali.
Dalam beberapa kasus, pergeseran kerja ke subsistem yang berlebihan tidak dapat diotomatisasi, seperti failover database primer ke sekunder di mana teknologi tidak menyediakan pemilihan pemimpinnya sendiri. Ini adalah skenario umum untuk [arsitektur AWS Multi-region](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/). Karena jenis kegagalan ini memerlukan sejumlah waktu henti untuk diselesaikan, tidak dapat segera dibalik, dan membiarkan beban kerja tanpa redundansi untuk jangka waktu tertentu, penting untuk memiliki manusia dalam proses pengambilan keputusan.
Beban kerja yang dapat mencakup model konsistensi yang kurang ketat dapat mencapai yang lebih pendek MTTRs dengan menggunakan otomatisasi failover multi-wilayah untuk mengatasi kegagalan. Fitur seperti [replikasi lintas wilayah Amazon S3 atau tabel global Amazon](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) [DynamoDB memberikan kemampuan Multi-wilayah melalui](https://aws.amazon.com/dynamodb/global-tables/) replikasi yang konsisten. Selanjutnya, menggunakan model konsistensi santai bermanfaat ketika kita mempertimbangkan CAP teorema. Selama kegagalan jaringan yang memengaruhi konektivitas ke subsistem stateful, jika beban kerja memilih ketersediaan daripada konsistensi, itu masih dapat memberikan respons non-kesalahan, cara lain untuk merutekan kegagalan.
Routing seputar kegagalan dapat diimplementasikan dengan dua strategi yang berbeda. Strategi pertama adalah dengan menerapkan stabilitas statis dengan melakukan pra-penyediaan sumber daya yang cukup untuk menangani beban lengkap subsistem yang gagal. Ini bisa berupa satu EC2 contoh atau mungkin kapasitas seluruh AZ. Mencoba menyediakan sumber daya baru selama kegagalan meningkatkan MTTR dan menambahkan ketergantungan ke bidang kontrol di jalur pemulihan Anda. Namun, itu datang dengan biaya tambahan.
Strategi kedua adalah merutekan sebagian lalu lintas dari subsistem yang gagal ke yang lain dan [beban menumpahkan kelebihan lalu lintas](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload) yang tidak dapat ditangani oleh kapasitas yang tersisa. Selama periode degradasi ini, Anda dapat meningkatkan sumber daya baru untuk menggantikan kapasitas yang gagal. Pendekatan ini memiliki lebih lama MTTR dan menciptakan ketergantungan pada bidang kontrol, tetapi biaya lebih sedikit dalam siaga, kapasitas cadangan.
## Kembali ke keadaan baik yang dikenal
Pendekatan umum lainnya untuk mitigasi selama perbaikan adalah mengembalikan beban kerja ke keadaan baik yang diketahui sebelumnya. Jika perubahan baru-baru ini mungkin menyebabkan kegagalan, memutar kembali perubahan itu adalah salah satu cara untuk kembali ke keadaan sebelumnya.
Dalam kasus lain, kondisi sementara mungkin telah menyebabkan kegagalan, dalam hal ini, memulai kembali beban kerja dapat mengurangi dampaknya. Mari kita periksa kedua skenario ini.
Selama penyebaran, meminimalkan MTTD dan MTTR bergantung pada observabilitas dan otomatisasi. Proses penerapan Anda harus terus memperhatikan beban kerja untuk pengenalan tingkat kesalahan yang meningkat, peningkatan latensi, atau anomali. Setelah ini dikenali, itu harus menghentikan proses penerapan.
Ada berbagai [strategi penyebaran, seperti penerapan](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/deployment-strategies.html) di tempat, penerapan biru/hijau, dan penerapan bergulir. Masing-masing dari ini mungkin menggunakan mekanisme yang berbeda untuk kembali ke keadaan yang diketahui baik. Ini dapat secara otomatis memutar kembali ke keadaan sebelumnya, mengalihkan lalu lintas kembali ke lingkungan biru, atau memerlukan intervensi manual.
CloudFormation [menawarkan kemampuan untuk secara otomatis melakukan rollback](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-rollback-triggers.html) sebagai bagian dari membuat dan memperbarui operasi tumpukan, seperti halnya. [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html#deployments-rollback-and-redeploy-automatic-rollbacks) CodeDeploy juga mendukung penerapan biru/hijau dan bergulir.
Untuk memanfaatkan kemampuan ini dan meminimalkan kemampuan AndaMTTR, pertimbangkan untuk mengotomatiskan semua infrastruktur dan penyebaran kode Anda melalui layanan ini. Dalam skenario di mana Anda tidak dapat menggunakan layanan ini, pertimbangkan untuk menerapkan [pola saga](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-the-serverless-saga-pattern-by-using-aws-step-functions.html) dengan AWS Step Functions untuk mengembalikan penerapan yang gagal.
Saat mempertimbangkan *restart*, ada beberapa pendekatan berbeda. Mulai dari me-reboot server, tugas terpanjang, hingga memulai ulang utas, tugas terpendek. Berikut adalah tabel yang menguraikan beberapa pendekatan restart dan perkiraan waktu untuk menyelesaikan (mewakili urutan perbedaan besarnya, ini tidak tepat).
| Mekanisme pemulihan kesalahan | Diperkirakan MTTR |
| --- | --- |
| Luncurkan dan konfigurasikan server virtual baru | 15 menit |
| Menerapkan ulang perangkat lunak | 10 menit |
| Reboot server | 5 menit |
| Mulai ulang atau luncurkan wadah | 2 detik |
| Memanggil fungsi tanpa server baru | 100 ms |
| Mulai ulang proses | 10 ms |
| Mulai ulang utas | 10 μs |
Meninjau tabel, ada beberapa manfaat yang jelas untuk MTTR dalam menggunakan wadah dan fungsi tanpa server (seperti). [AWS Lambda](https://aws.amazon.com/lambda/) Mereka MTTR adalah urutan besarnya lebih cepat daripada memulai ulang mesin virtual atau meluncurkan yang baru. Namun, menggunakan isolasi kesalahan melalui modularitas perangkat lunak juga bermanfaat. Jika Anda dapat menahan kegagalan pada satu proses atau utas, memulihkan dari kegagalan itu jauh lebih cepat daripada memulai ulang wadah atau server.
Sebagai pendekatan umum untuk pemulihan, Anda dapat berpindah dari bawah ke atas: 1/Restart, 2/Reboot, 3/Re-image/Redeploy, 4/Replace. Namun, setelah Anda mencapai langkah reboot, merutekan kegagalan biasanya merupakan pendekatan yang lebih cepat (biasanya memakan waktu paling lama 3-4 menit). Jadi, untuk paling cepat mengurangi dampak setelah percobaan restart, rute di sekitar kegagalan, dan kemudian, di latar belakang, lanjutkan proses pemulihan untuk mengembalikan kapasitas ke beban kerja Anda.
**Aturan 10**
Fokus pada mitigasi dampak, bukan resolusi masalah. Ambil jalur tercepat kembali ke operasi normal.
## Diagnosis kegagalan
Bagian dari proses perbaikan setelah deteksi adalah periode diagnosis. Ini adalah periode waktu di mana operator mencoba menentukan apa yang salah. Proses ini mungkin melibatkan kueri log, meninjau metrik Kesehatan Operasional, atau masuk ke host untuk memecahkan masalah. Semua tindakan ini membutuhkan waktu, jadi membuat alat dan runbook untuk mempercepat tindakan ini dapat membantu mengurangi MTTR juga.
## Runbook dan otomatisasi
Demikian pula, setelah Anda menentukan apa yang salah dan tindakan apa yang akan memperbaiki beban kerja, operator biasanya perlu melakukan beberapa set langkah untuk melakukannya. Misalnya, setelah kegagalan, cara tercepat untuk memperbaiki beban kerja mungkin dengan memulai ulang, yang dapat melibatkan beberapa langkah yang dipesan. Memanfaatkan runbook yang mengotomatiskan langkah-langkah ini atau memberikan arahan khusus kepada operator akan mempercepat proses dan membantu mengurangi risiko tindakan yang tidak disengaja.
# Meningkat MTBF
Komponen terakhir untuk meningkatkan ketersediaan adalah meningkatkanMTBF. Ini dapat berlaku untuk perangkat lunak serta AWS layanan yang digunakan untuk menjalankannya.
## Meningkatkan sistem terdistribusi MTBF
Salah satu cara untuk meningkatkan MTBF adalah dengan mengurangi cacat pada perangkat lunak. Ada beberapa cara untuk melakukan ini. Pelanggan dapat menggunakan alat seperti [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) untuk menemukan dan memperbaiki kesalahan umum. Anda juga harus melakukan tinjauan kode sejawat yang komprehensif, pengujian unit, tes integrasi, uji regresi, dan uji beban pada perangkat lunak sebelum digunakan untuk produksi. Meningkatkan jumlah cakupan kode dalam pengujian akan membantu memastikan bahwa jalur eksekusi kode yang tidak biasa pun diuji.
Menyebarkan perubahan yang lebih kecil juga dapat membantu mencegah hasil yang tidak terduga dengan mengurangi kompleksitas perubahan. Setiap kegiatan memberikan kesempatan untuk mengidentifikasi dan memperbaiki cacat sebelum mereka dapat dipanggil.
Pendekatan lain untuk mencegah kegagalan adalah [pengujian rutin](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html). Menerapkan program rekayasa kekacauan dapat membantu menguji bagaimana beban kerja Anda gagal, memvalidasi prosedur pemulihan, dan membantu menemukan dan memperbaiki mode kegagalan sebelum terjadi dalam produksi. Pelanggan dapat menggunakan [AWS Fault Injection Simulator](https://aws.amazon.com/fis/) sebagai bagian dari perangkat eksperimen rekayasa kekacauan mereka.
Toleransi kesalahan adalah cara lain untuk mencegah kegagalan dalam sistem terdistribusi. Modul cepat gagal, percobaan ulang dengan backoff dan jitter eksponensial, transaksi, dan idempotensi adalah semua teknik untuk membantu membuat beban kerja toleran terhadap kesalahan.
Transaksi adalah sekelompok operasi yang mematuhi ACID properti. Mereka adalah sebagai berikut:
+ **Atomisitas** — Entah semua tindakan terjadi atau tidak satupun dari mereka akan terjadi.
+ **Konsistensi** — Setiap transaksi meninggalkan beban kerja dalam keadaan valid.
+ **Isolasi** — Transaksi yang dilakukan secara bersamaan meninggalkan beban kerja dalam keadaan yang sama seolah-olah telah dilakukan secara berurutan.
+ **Daya Tahan** — Setelah transaksi dilakukan, semua efeknya dipertahankan bahkan dalam kasus kegagalan beban kerja.
Mencoba lagi dengan [backoff eksponensial dan jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) memungkinkan Anda mengatasi kegagalan sementara yang disebabkan oleh Heisenbug, kelebihan beban, atau kondisi lainnya. Ketika transaksi idempoten, mereka dapat dicoba ulang beberapa kali tanpa efek samping.
Jika kita mempertimbangkan efek Heisenbug pada konfigurasi perangkat keras yang toleran terhadap kesalahan, kita akan cukup tidak peduli karena kemungkinan Heisenbug muncul pada subsistem primer dan redundan sangat kecil. (Lihat Jim Gray, "[Mengapa Komputer Berhenti dan Apa Yang Dapat Dilakukan Tentang Itu](https://pages.cs.wisc.edu/~remzi/Classes/739/Fall2018/Papers/gray85-easy.pdf)? “, Juni 1985, Laporan Teknis Tandem 85.7.) Dalam sistem terdistribusi, kami ingin mencapai hasil yang sama dengan perangkat lunak kami.
Ketika Heisenbug dipanggil, sangat penting bahwa perangkat lunak dengan cepat mendeteksi operasi yang salah dan gagal sehingga dapat dicoba lagi. Ini dicapai melalui pemrograman defensif, dan memvalidasi input, hasil antara, dan output. Selain itu, proses diisolasi dan tidak berbagi keadaan dengan proses lain.
Pendekatan modular ini memastikan bahwa ruang lingkup dampak selama kegagalan terbatas. Proses gagal secara independen. Ketika suatu proses gagal, perangkat lunak harus menggunakan “pasangan proses” untuk mencoba kembali pekerjaan, yang berarti proses baru dapat mengasumsikan pekerjaan yang gagal. Untuk menjaga keandalan dan integritas beban kerja, setiap operasi harus diperlakukan sebagai ACID transaksi.
Hal ini memungkinkan proses gagal tanpa merusak keadaan beban kerja dengan membatalkan transaksi dan mengembalikan setiap perubahan yang dibuat. Ini memungkinkan proses pemulihan untuk mencoba kembali transaksi dari keadaan yang diketahui baik dan memulai kembali dengan anggun. Ini adalah bagaimana perangkat lunak dapat toleran terhadap kesalahan terhadap Heisenbugs.
Namun, Anda tidak boleh bertujuan untuk membuat perangkat lunak toleran terhadap kesalahan Bohrbugs. Cacat ini harus ditemukan dan dihilangkan sebelum beban kerja memasuki produksi karena tidak ada tingkat redundansi yang akan mencapai hasil yang benar. (Lihat Jim Gray, "[Mengapa Komputer Berhenti dan Apa Yang Dapat Dilakukan Tentang Itu](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf)? “, Juni 1985, Laporan Teknis Tandem 85.7.)
Cara terakhir untuk meningkatkan MTBF adalah dengan mengurangi ruang lingkup dampak dari kegagalan. Menggunakan [isolasi kesalahan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) melalui modularisasi untuk membuat wadah kesalahan adalah cara utama untuk melakukannya seperti yang diuraikan sebelumnya dalam *Toleransi kesalahan dan isolasi kesalahan*. Mengurangi tingkat kegagalan meningkatkan ketersediaan. AWS menggunakan teknik seperti membagi layanan menjadi pesawat kontrol dan pesawat data, [Availability Zone Independence](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) (AZI), [isolasi Regional](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/), [arsitektur berbasis sel](https://www.youtube.com/watch?v=swQbA4zub20), dan [shuffle-sharding](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding) untuk memberikan isolasi kesalahan. Ini juga pola yang dapat digunakan oleh AWS pelanggan juga.
Sebagai contoh, mari kita tinjau skenario di mana beban kerja menempatkan pelanggan ke dalam wadah kesalahan yang berbeda dari infrastrukturnya yang melayani paling banyak 5% dari total pelanggan. Salah satu wadah kesalahan ini mengalami peristiwa yang meningkatkan latensi di luar batas waktu klien untuk 10% permintaan. Selama acara ini, untuk 95% pelanggan, layanan ini 100% tersedia. Untuk 5% lainnya, layanan tampaknya 90% tersedia. Hal ini menghasilkan ketersediaan 1 − (5% *o* *f* *c* *u* *s* *t* *o* *m* *e* *r* *s* × 10% *o* *f* *t* *h* *e* *i* *r* *r* *e* *q* *u* *e* *s* *t* *s s*) = 99,5% bukannya 10% permintaan gagal untuk 100% pelanggan (menghasilkan ketersediaan 90%).
**Aturan 11**
Isolasi kesalahan mengurangi cakupan dampak dan meningkatkan beban kerja dengan mengurangi tingkat kegagalan keseluruhan. MTBF
## Meningkatkan Ketergantungan MTBF
Metode pertama untuk meningkatkan AWS ketergantungan Anda MTBF adalah dengan menggunakan [isolasi kesalahan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html). Banyak AWS layanan menawarkan tingkat isolasi di AZ, yang berarti kegagalan dalam satu AZ tidak mempengaruhi layanan di AZ yang berbeda.
Menggunakan EC2 instance redundan dalam beberapa AZs meningkatkan ketersediaan subsistem. AZImenyediakan kemampuan hemat dalam satu Wilayah, memungkinkan Anda untuk meningkatkan ketersediaan Anda untuk AZI layanan.
Namun, tidak semua AWS layanan beroperasi di tingkat AZ. Banyak yang menawarkan isolasi regional. Dalam hal ini, di mana ketersediaan layanan regional yang dirancang untuk tidak mendukung ketersediaan keseluruhan yang diperlukan untuk beban kerja Anda, Anda dapat mempertimbangkan pendekatan Multi-wilayah. Setiap Wilayah menawarkan instantiasi layanan yang terisolasi, setara dengan hemat.
Ada berbagai layanan yang membantu membuat membangun layanan Multi-region lebih mudah. Sebagai contoh:
+ [Basis Data Global Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/)
+ [Tabel global Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/)
+ [Amazon ElastiCache (RedisOSS) - Datastore Global](https://aws.amazon.com/elasticache/redis/global-datastore/)
+ [AWS Akselerator Global](https://aws.amazon.com/global-accelerator/)
+ [Replikasi Lintas Wilayah Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Pengontrol Pemulihan Aplikasi Amazon Route 53](https://aws.amazon.com/route53/application-recovery-controller/)
Dokumen ini tidak mempelajari strategi membangun beban kerja Multi-wilayah, tetapi Anda harus mempertimbangkan manfaat ketersediaan arsitektur Multi-wilayah dengan biaya tambahan, kompleksitas, dan praktik operasional yang diperlukan untuk memenuhi tujuan ketersediaan yang Anda inginkan.
Metode selanjutnya untuk meningkatkan ketergantungan MTBF adalah dengan merancang beban kerja Anda agar stabil secara statis. Misalnya, Anda memiliki beban kerja yang menyajikan informasi produk. Ketika pelanggan Anda membuat permintaan untuk suatu produk, layanan Anda membuat permintaan ke layanan metadata eksternal untuk mengambil detail produk. Kemudian beban kerja Anda mengembalikan semua info itu ke pengguna.
Namun, jika layanan metadata tidak tersedia, permintaan yang dibuat oleh pelanggan Anda gagal. Sebagai gantinya, Anda dapat secara asinkron menarik atau mendorong metadata secara lokal ke layanan Anda untuk digunakan untuk menjawab permintaan. Ini menghilangkan panggilan sinkron ke layanan metadata dari jalur kritis Anda.
Selain itu, karena layanan Anda masih tersedia bahkan ketika layanan metadata tidak, Anda dapat menghapusnya sebagai ketergantungan dalam perhitungan ketersediaan Anda. Contoh ini bergantung pada asumsi bahwa metadata tidak sering berubah dan bahwa menyajikan metadata basi lebih baik daripada permintaan yang gagal. Contoh serupa lainnya adalah [serve-stale](https://www.rfc-editor.org/rfc/rfc8767) untuk DNS yang memungkinkan data disimpan dalam cache setelah TTL kedaluwarsa dan digunakan untuk tanggapan ketika jawaban yang diperbarui tidak tersedia.
Metode terakhir untuk meningkatkan ketergantungan MTBF adalah dengan mengurangi ruang lingkup dampak dari kegagalan. Seperti dibahas sebelumnya, kegagalan bukanlah peristiwa biner, ada derajat kegagalan. Ini adalah efek modularisasi; kegagalan terkandung hanya pada permintaan atau pengguna yang dilayani oleh wadah itu.
Hal ini mengakibatkan lebih sedikit kegagalan selama suatu peristiwa yang pada akhirnya meningkatkan ketersediaan beban kerja secara keseluruhan dengan membatasi ruang lingkup dampak.
## Mengurangi sumber dampak umum
Pada tahun 1985, Jim Gray menemukan, selama studi di Tandem Computers, bahwa kegagalan terutama didorong oleh dua hal: perangkat lunak dan operasi. (Lihat Jim Gray, "[Mengapa Komputer Berhenti dan Apa Yang Dapat Dilakukan Tentang Itu](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf)? “, Juni 1985, Laporan Teknis Tandem 85.7.) Bahkan setelah 36 tahun kemudian, ini terus menjadi kenyataan. Terlepas dari kemajuan teknologi, tidak ada solusi mudah untuk masalah ini, dan sumber utama kegagalan belum berubah. Mengatasi kegagalan dalam perangkat lunak dibahas di awal bagian ini, jadi fokusnya di sini adalah operasi dan mengurangi frekuensi kegagalan.
### Stabilitas dibandingkan dengan fitur
Jika kita merujuk kembali ke tingkat kegagalan untuk grafik perangkat lunak dan perangkat keras di bagian ini[Ketersediaan sistem terdistribusi](distributed-system-availability.md), kita dapat melihat bahwa cacat ditambahkan di setiap rilis perangkat lunak. Ini berarti bahwa setiap perubahan pada beban kerja menimbulkan peningkatan risiko kegagalan. Perubahan ini biasanya hal-hal seperti fitur baru, yang memberikan akibat wajar. Beban kerja ketersediaan yang lebih tinggi akan mendukung stabilitas dibandingkan fitur baru. Dengan demikian, salah satu cara paling sederhana untuk meningkatkan ketersediaan adalah dengan menggunakan lebih jarang atau memberikan lebih sedikit fitur. Beban kerja yang diterapkan lebih sering secara inheren akan memiliki ketersediaan yang lebih rendah daripada yang tidak. Namun, beban kerja yang gagal menambahkan fitur tidak sesuai dengan permintaan pelanggan dan dapat menjadi kurang berguna dari waktu ke waktu.
Jadi, bagaimana kita terus berinovasi dan merilis fitur dengan aman? Jawabannya adalah standardisasi. Apa cara yang benar untuk menyebarkan? Bagaimana Anda memesan penerapan? Apa standar untuk pengujian? Berapa lama Anda menunggu di antara tahapan? Apakah pengujian unit Anda cukup mencakup kode perangkat lunak? Ini adalah pertanyaan yang akan dijawab oleh standardisasi dan mencegah masalah yang disebabkan oleh hal-hal seperti tidak memuat pengujian, melewatkan tahapan penerapan, atau menyebarkan terlalu cepat ke terlalu banyak host.
Cara Anda menerapkan standardisasi adalah melalui otomatisasi. Ini mengurangi kemungkinan kesalahan manusia dan memungkinkan komputer melakukan hal yang mereka kuasai, yang melakukan hal yang sama berulang kali dengan cara yang sama setiap saat. Cara Anda menyatukan standardisasi dan otomatisasi adalah dengan menetapkan tujuan. Sasaran seperti tidak ada perubahan manual, akses host hanya melalui sistem otorisasi kontingen, menulis tes beban untuk setiapAPI, dan sebagainya. Keunggulan operasional adalah norma budaya yang membutuhkan perubahan besar. Membangun dan melacak kinerja terhadap suatu tujuan membantu mendorong perubahan budaya yang akan berdampak luas pada ketersediaan beban kerja. Pilar [AWS Well-Architected Operational Excellence](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html) memberikan praktik terbaik yang komprehensif untuk keunggulan operasional.
### Keamanan operator
Kontributor utama lainnya untuk peristiwa operasional yang menyebabkan kegagalan adalah orang-orang. Manusia membuat kesalahan. Mereka mungkin menggunakan kredensil yang salah, memasukkan perintah yang salah, menekan Enter terlalu cepat, atau melewatkan langkah kritis. Mengambil tindakan manual secara konsisten menghasilkan kesalahan, yang mengakibatkan kegagalan.
Salah satu penyebab utama kesalahan operator adalah antarmuka pengguna yang membingungkan, tidak intuitif, atau tidak konsisten. Jim Gray juga mencatat dalam studinya tahun 1985 bahwa “antarmuka yang meminta informasi kepada operator atau memintanya untuk melakukan beberapa fungsi harus sederhana, konsisten, dan toleran terhadap kesalahan operator.” (Lihat Jim Gray, "[Mengapa Komputer Berhenti dan Apa Yang Dapat Dilakukan Tentang Itu](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf)? “, Juni 1985, Laporan Teknis Tandem 85.7.) Wawasan ini terus menjadi kenyataan hari ini. Ada banyak contoh selama tiga dekade terakhir di seluruh industri di mana antarmuka pengguna yang membingungkan atau kompleks, kurangnya konfirmasi atau instruksi, atau bahkan hanya bahasa manusia yang tidak ramah menyebabkan operator melakukan hal yang salah.
**Aturan 12**
Memudahkan operator untuk melakukan hal yang benar.
### Mencegah kelebihan beban
Kontributor dampak umum terakhir adalah pelanggan Anda, pengguna sebenarnya dari beban kerja Anda. Beban kerja yang berhasil cenderung digunakan, banyak, tetapi terkadang penggunaan itu melebihi kemampuan beban kerja untuk skala. Ada banyak hal yang bisa terjadi, disk bisa menjadi penuh, kumpulan thread mungkin habis, bandwidth jaringan mungkin jenuh, atau batas koneksi database dapat dicapai.
Tidak ada metode gagal untuk menghilangkan ini, tetapi pemantauan proaktif kapasitas dan pemanfaatan melalui metrik Kesehatan Operasional akan memberikan peringatan dini ketika kegagalan ini mungkin terjadi. Teknik seperti [pelepasan beban](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload), [pemutus sirkuit](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html), dan [coba lagi dengan backoff eksponensial dan jitter dapat membantu meminimalkan dampak dan meningkatkan tingkat keberhasilan](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/), tetapi situasi ini masih merupakan kegagalan. Penskalaan otomatis berdasarkan metrik Kesehatan Operasional dapat membantu mengurangi frekuensi kegagalan karena kelebihan beban, tetapi mungkin tidak dapat merespons dengan cukup cepat terhadap perubahan pemanfaatan.
Jika Anda perlu memastikan kapasitas yang tersedia secara terus menerus untuk pelanggan, Anda harus melakukan pengorbanan pada ketersediaan dan biaya. Salah satu cara untuk memastikan kurangnya kapasitas tidak menyebabkan tidak tersedianya adalah dengan menyediakan setiap pelanggan dengan kuota dan memastikan kapasitas beban kerja Anda diskalakan untuk memberikan 100% dari kuota yang dialokasikan. Ketika pelanggan melebihi kuota mereka, mereka terhambat, yang bukan merupakan kegagalan dan tidak dihitung terhadap ketersediaan. Anda juga perlu melacak basis pelanggan Anda dengan cermat dan memperkirakan pemanfaatan masa depan untuk menjaga kapasitas yang cukup disediakan. Ini memastikan beban kerja Anda tidak didorong ke skenario kegagalan melalui konsumsi berlebihan oleh pelanggan Anda.
+ [Amazon Builders' Library — Menggunakan load shedding untuk menghindari kelebihan beban](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/)
+ [Amazon Builders' Library — Keadilan dalam sistem multi-penyewa](https://aws.amazon.com/builders-library/fairness-in-multi-tenant-systems)
Misalnya, mari kita periksa beban kerja yang menyediakan layanan penyimpanan. Setiap server dalam beban kerja dapat mendukung 100 unduhan per detik, pelanggan diberikan kuota atau 200 unduhan per detik, dan ada 500 pelanggan. Untuk dapat mendukung volume pelanggan ini, layanan perlu menyediakan kapasitas 100.000 unduhan per detik, yang membutuhkan 1.000 server. Jika ada pelanggan yang melebihi kuota mereka, mereka terhambat, yang memastikan kapasitas yang cukup untuk setiap pelanggan lainnya. Ini adalah contoh sederhana dari salah satu cara untuk menghindari kelebihan beban tanpa menolak unit kerja.