# REL 5 Bagaimana cara mendesain interaksi di sistem terdistribusi untuk memitigasi atau bertahan dari kegagalan?
Sistem terdistribusi mengandalkan jaringan komunikasi untuk membuat interkoneksi komponen (seperti server atau layanan). Beban kerja Anda harus beroperasi secara andal terlepas latensi atau hilangnya data di jaringan-jaringan ini. Komponen dari sistem terdistribusi harus beroperasi dengan cara yang tidak secara negatif memengaruhi beban kerja atau komponen-komponen lain. Berbagai praktik terbaik ini memungkinkan beban kerja bertahan dari stres atau kegagalan, lebih cepat pulih darinya, dan memitigasi dampak gangguan tersebut. Hasilnya yakni peningkatan dalam waktu rata-rata untuk pemulihan (MTTR).
**Topics**
+ [REL05-BP01 Mengimplementasikan degradasi yang tepat (graceful degradation) untuk mengubah dependensi keras yang berlaku menjadi dependensi lunak](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Membatasi (throttling) permintaan](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Mengontrol dan membatasi panggilan percobaan ulang](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Melakukan gagal cepat (fail fast) dan membatasi antrean](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Mengatur waktu habis klien](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Menjadikan layanan stateless jika memungkinkan](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Mengimplementasikan tuas darurat](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Mengimplementasikan degradasi yang tepat (graceful degradation) untuk mengubah dependensi keras yang berlaku menjadi dependensi lunak
Saat dependensi komponen tidak optimum, komponen tersebut masih dapat berfungsi, meskipun terbatas atau terdegradasi. Misalnya, saat panggilan dependensi gagal, lakukan failover ke respons statis yang telah ditentukan sebelumnya.
Misalkan layanan B dipanggil oleh layanan A dan kemudian memanggil layanan C.
![\[Diagram menampilkan Layanan C gagal saat dipanggil dari layanan B. Layanan B mengembalikan respons terdegradasi ke layanan A\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
Saat layanan B memanggil layanan C, yang diterima adalah pesan kesalahan atau waktu habis. Karena tidak mendapatkan respons yang mencukupi dari layanan C (dan data di dalamnya), layanan B mengembalikan respons seadanya. Respons ini dapat berupa nilai baik ter-cache paling akhir, atau layanan B dapat menggantikan respons yang seharusnya diterima dari layanan C dengan respons statis yang ditentukan sebelumnya. Layanan tersebut kemudian mengembalikan respons terbatas ke layanan A sebagai pemanggilnya. Tanpa respons statis, kegagalan di layanan C akan mengalir melalui layanan B ke layanan A, yang mengakibatkan hilangnya ketersediaan.
Sebagai faktor multiplikatif dalam persamaan ketersediaan untuk dependensi keras (lihat [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)), penurunan apa pun dalam ketersediaan layanan C dapat berdampak signifikan terhadap ketersediaan efektif layanan B. Dengan mengembalikan respons statis, layanan B memitigasi kegagalan layanan C, meskipun terbatas, sehingga ketersediaan layanan C tampak seperti 100% (dengan asumsi layanan C mengembalikan respons statis karena kesalahan). Perhatikan bahwa respons statis adalah alternatif sederhana untuk mengembalikan kesalahan, dan bukan upaya untuk mengkomputasi ulang respons menggunakan cara yang berbeda. Upaya semacam itu, dalam mekanisme yang benar-benar berbeda untuk mencoba meraih hasil yang sama, disebut perilaku fallback, dan merupakan antipola yang harus dihindari.
Contoh lain degradasi yang tepat (graceful degradation) adalah *pola pemutus sirkuit*. Strategi percobaan ulang harus digunakan saat kegagalan bersifat sementara. Saat hal tersebut tidak terjadi, dan operasi berpotensi gagal, pola pemutus sirkuit mencegah klien menjalankan permintaan yang berpotensi gagal. Saat permintaan diproses secara normal, pemutus sirkuit ditutup dan permintaan mengalir masuk. Saat sistem jarak jauh mengembalikan kesalahan atau menunjukkan latensi tinggi, pemutus sirkuit terbuka dan dependensi diabaikan atau hasilnya digantikan dengan respons yang lebih mudah didapatkan meskipun kurang komprehensif (atau disebut juga cache respons). Secara berkala, sistem mencoba memanggil dependensi untuk menentukan apakah dependensi sudah dipulihkan. Saat hal tersebut terjadi, pemutus sirkuit ditutup.
![\[Diagram menampilkan status pemutus sirkuit terbuka dan tertutup.\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
Selain status terbuka dan tertutup yang ditampilkan dalam diagram, pemutus sirkuit dapat beralih ke status setengah terbuka setelah berada dalam status terbuka selama periode waktu yang dapat dikonfigurasikan. Dalam status ini, pemutus sirkuit secara berkala mencoba memanggil layanan dengan tingkat yang lebih rendah daripada keadaan normal. Pengujian ini digunakan untuk memeriksa kondisi layanan. Setelah beberapa kali berhasil dalam status setengah terbuka, pemutus sirkuit beralih ke tertutup, dan permintaan normal dilanjutkan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Implementasikan degradasi yang tepat (graceful degradation) untuk mengubah dependensi keras yang berlaku menjadi dependensi lunak. Saat dependensi komponen tidak optimum, komponen tersebut masih dapat berfungsi, meskipun terbatas atau terdegradasi. Misalnya, saat panggilan dependensi gagal, lakukan failover ke respons statis yang telah ditentukan sebelumnya.
+ Dengan mengembalikan respons statis, beban kerja memitigasi kegagalan yang terjadi di dependensinya.
+ [Lab Well-Architected: Level 300: Mengimplementasikan Pemeriksaan Kondisi dan Mengelola Dependensi untuk Meningkatkan Keandalan](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
+ Deteksi saat operasi coba ulang berpotensi gagal, dan cegah klien membuat panggilan gagal dengan pola pemutus sirkuit.
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html)
## Sumber daya
**Dokumen terkait:**
+ [Amazon API Gateway: Permintaan API Throttle untuk Peningkatan Throughput ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (rangkuman Pemutus Sirkuit dari buku “Release It\$1”)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Kesalahan Percobaan Ulang dan Mundur Eksponensial di AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard “Release It\$1 Design and Deploy Production-Ready Software” (Rancang dan Lakukan Deployment Perangkat Lunak yang Siap Diproduksi)](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [Amazon Builders' Library: Menghindari fallback dalam sistem terdistribusi](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: Menghindari backlog antrean yang tidak dapat diatasi](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: Tantangan dan strategi caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders' Library: Waktu habis, percobaan ulang, dan mundur (backoff) dengan gangguan](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video terkait:**
+ [Percobaan ulang, mundur, dan gangguan: AWS re:Invent 2019: Memperkenalkan Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**Contoh terkait:**
+ [Lab Well-Architected: Level 300: Mengimplementasikan Pemeriksaan Kondisi dan Mengelola Dependensi untuk Meningkatkan Keandalan](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL05-BP02 Membatasi (throttling) permintaan
Pembatasan permintaan adalah pola mitigasi untuk menanggapi peningkatan permintaan yang tidak terduga. Beberapa permintaan diutamakan tetapi permintaan yang melebihi batas yang ditetapkan akan ditolak dan akan muncul pesan yang menunjukkan adanya pembatasan. Yang kemungkinan akan terjadi adalah klien mundur dan mengabaikan permintaan atau mencoba lagi dengan kecepatan lebih rendah.
Layanan Anda harus dirancang untuk menangani kapasitas permintaan yang diketahui yang dapat diproses oleh setiap simpul atau sel. Kapasitas dapat ditetapkan melalui pengujian beban. Anda kemudian perlu melacak tingkat kedatangan permintaan dan jika tingkat kedatangan sementara melebihi batas ini, respons yang tepat adalah memberi sinyal bahwa permintaan telah dibatasi. Ini memungkinkan pengguna untuk mencoba lagi, kemungkinan ke simpul atau sel berbeda yang mungkin memiliki kapasitas yang tersedia. Amazon API Gateway menyediakan metode untuk membatasi permintaan. Amazon SQS dan Amazon Kinesis dapat menahan permintaan, memperlancar tingkat permintaan, dan mengurangi kebutuhan untuk membatasi permintaan yang dapat ditangani secara asinkron.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Membatasi (throttling) permintaan Ini adalah pola mitigasi untuk merespons peningkatan permintaan yang tidak terduga. Beberapa permintaan diutamakan tetapi permintaan yang melebihi batas yang ditetapkan akan ditolak dan akan muncul pesan yang menunjukkan adanya pembatasan. Yang kemungkinan akan terjadi adalah klien mundur dan mengabaikan permintaan atau mencoba lagi dengan kecepatan lebih rendah.
+ Menggunakan Amazon API Gateway
+ [Membatasi Permintaan API untuk Peningkatan Throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## Sumber daya
**Dokumen terkait:**
+ [Amazon API Gateway: Membatasi Permintaan API untuk Peningkatan Throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Percobaan Ulang Kesalahan dan Mundur Eksponensial di AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library: Menghindari fallback dalam sistem terdistribusi](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: Menghindari backlog antrean yang tidak dapat diatasi](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: Waktu habis, percobaan ulang, dan mundur dengan jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [Membatasi Permintaan API untuk Peningkatan Throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**Video terkait:**
+ [Percobaan ulang, mundur, dan jitter: AWS re:Invent 2019: Memperkenalkan Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 Mengontrol dan membatasi panggilan percobaan ulang
Gunakan mundur eksponensial untuk percobaan ulang setelah interval yang makin lama. Masukkan jitter untuk mengacak interval percobaan ulang dan batasi jumlah percobaan ulang maksimum.
Komponen khas di sistem perangkat lunak terdistribusi mencakup server, penyeimbang beban, basis data, dan server DNS. Dalam operasi, dan dapat mengalami kegagalan, semua ini dapat mulai menghasilkan kesalahan. Teknik default untuk menangani kesalahan adalah dengan menerapkan percobaan ulang di sisi klien. Teknik ini meningkatkan keandalan dan ketersediaan aplikasi. Namun, pada skala besar—dan jika klien berupaya untuk mencoba ulang operasi yang gagal langsung setelah terjadi kesalahan—jaringan dengan cepat menjadi penuh dengan permintaan baru dan percobaan ulang, masing-masing memperebutkan bandwidth jaringan. Ini dapat mengakibatkan *badai percobaan ulang,* yang akan mengurangi ketersediaan layanan. Pola ini mungkin berlanjut sampai terjadi kegagalan sistem penuh.
Untuk menghindari skenario seperti itu, algoritme mundur (backoff) seperti *mundur eksponensial* umum harus digunakan. Algoritme mundur eksponensial secara bertahap mengurangi tingkat di mana percobaan ulang dilakukan, sehingga menghindari kemacetan jaringan.
Banyak SDK dan pustaka perangkat lunak, termasuk dari AWS, menerapkan versi dari algoritme ini. Namun, **jangan pernah berasumsi bahwa algoritme mundur ada—selalu uji dan verifikasi bahwa ini adalah masalahnya.**
Mundur sederhana saja tidak cukup karena pada sistem terdistribusi semua klien dapat mundur bersamaan, dan memunculkan klaster-klaster panggilan percobaan ulang. Marc Brooker dalam postingan blognya [Mundur Eksponensial dan Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/), menjelaskan cara mengubah fungsi wait() di mundur eksponensial untuk mencegah klaster-klaster panggilan percobaan ulang. Solusinya adalah menambahkan *jitter* di fungsi wait(). Untuk menghindari percobaan ulang terlalu lama, implementasi harus membatasi mundur ke nilai maksimum.
Terakhir, penting untuk mengonfigurasi *jumlah maksimum percobaan ulang* atau waktu yang telah berlalu, dan setelahnya percobaan ulang akan gagal. SDK AWS mengimplementasikannya secara default, dan dapat dikonfigurasi. Untuk layanan yang lebih rendah di tumpukan, batas percobaan ulang maksimum nol atau satu dapat membatasi risiko namun masih efektif karena percobaan ulang dilimpahkan ke layanan yang lebih tinggi di tumpukan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Mengontrol dan membatasi panggilan percobaan ulang. Gunakan mundur eksponensial untuk percobaan ulang setelah interval yang makin lama. Masukkan jitter untuk mengacak interval percobaan ulang dan batasi jumlah percobaan ulang maksimum.
+ [Percobaan Ulang Kesalahan dan Mundur Eksponensial di AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ SDK Amazon mengimplementasikan percobaan ulang dan mundur eksponensial secara default. Implementasikan logika yang sama di lapisan dependensi Anda saat memanggil layanan dependen Anda sendiri. Tentukan berapa batas waktu dan kapan harus berhenti mencoba ulang berdasarkan kasus penggunaan Anda.
## Sumber daya
**Dokumen terkait:**
+ [Amazon API Gateway: Membatasi Permintaan API untuk Peningkatan Throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Percobaan Ulang Kesalahan dan Mundur Eksponensial di AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library: Menghindari fallback dalam sistem terdistribusi](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: Menghindari backlog antrean yang tidak dapat diatasi](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: Tantangan dan strategi caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders' Library: Waktu habis, percobaan ulang, dan mundur dengan jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video terkait:**
+ [Percobaan ulang, mundur, dan jitter: AWS re:Invent 2019: Memperkenalkan Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 Melakukan gagal cepat (fail fast) dan membatasi antrean
Jika beban kerja tidak berhasil merespons permintaan, maka lakukan gagal cepat (fail fast). Ini memungkinkan pelepasan sumber daya yang terkait dengan permintaan, dan mengizinkan layanan untuk melakukan pemulihan jika kehabisan sumber daya. Jika beban kerja berhasil merespons tetapi tingkat permintaan terlalu tinggi, maka gunakan antrean untuk menahan permintaan. Namun, jangan izinkan antrean panjang yang dapat mengakibatkan pelayanan permintaan basi yang telah ditinggalkan klien.
Praktik terbaik ini berlaku untuk sisi server, atau penerima permintaan.
Ketahuilah bahwa antrean dapat dibuat di berbagai tingkat sistem, dan dapat sangat menghambat kemampuan untuk melakukan pemulihan dengan cepat saat permintaan lama dan basi (yang tidak lagi memerlukan respons) diproses sebelum permintaan baru. Waspadai tempat-tempat di mana terdapat antrean. Antrean sering bersembunyi di alur kerja atau di dalam pekerjaan yang direkam di basis data.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Lakukan gagal cepat (fail fast) dan batasi antrean Jika beban kerja tidak berhasil merespons permintaan, maka lakukan gagal cepat (fail fast). Ini memungkinkan pelepasan sumber daya yang terkait dengan permintaan, dan mengizinkan layanan untuk melakukan pemulihan jika kehabisan sumber daya. Jika beban kerja berhasil merespons tetapi tingkat permintaan terlalu tinggi, maka gunakan antrean untuk menahan permintaan. Namun, jangan izinkan antrean panjang yang dapat mengakibatkan pelayanan permintaan basi yang telah ditinggalkan klien.
+ Implementasikan gagal cepat (fail fast) saat layanan berada di bawah tekanan.
+ [Gagal Cepat (fail Fast)](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ Batasi antrean dalam sistem berbasis antrean, saat pemrosesan berhenti tetapi pesan tetap datang, utang pesan dapat terakumulasi menjadi backlog yang besar, sehingga meningkatkan waktu pemrosesan. Pekerjaan dapat diselesaikan lebih lama supaya hasilnya berguna, yang pada dasarnya menyebabkan ketersediaan hit yang seharusnya dijaga antreannya.
+ [Amazon Builders' Library: Menghindari backlog antrean yang tidak dapat diatasi](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## Sumber daya
**Dokumen terkait:**
+ [Percobaan Ulang Kesalahan dan Mundur Eksponensial di AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Gagal Cepat (fail Fast)](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [Amazon Builders' Library: Menghindari fallback dalam sistem terdistribusi](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: Menghindari backlog antrean yang tidak dapat diatasi](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: Tantangan dan strategi caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders' Library: Waktu habis, percobaan ulang, dan mundur dengan jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video terkait:**
+ [Percobaan ulang, mundur, dan jitter: AWS re:Invent 2019: Memperkenalkan Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 Mengatur waktu habis klien
Atur waktu habis dengan sesuai, verifikasikan waktu tersebut dengan sistematis, dan jangan selalu bergantung pada nilai default karena biasanya nilai tersebut ditetapkan terlalu tinggi.
Praktik terbaik ini berlaku untuk sisi klien, atau pengirim, permintaan.
Atur waktu habis koneksi dan waktu habis permintaan untuk panggilan jarak jauh apa pun, serta umumnya untuk panggilan apa pun di seluruh proses. Banyak kerangka kerja yang menawarkan kemampuan waktu habis bawaan, tetapi Anda harus tetap memperhatikan bahwa nilai default bawaan bisa saja terlalu tinggi atau tak terbatas. Nilai yang terlalu tinggi mengurangi kegunaan waktu habis karena sumber daya terus terpakai saat klien menunggu terjadinya waktu habis. Nilai yang terlalu rendah akan menyebabkan lalu lintas yang tinggi di backend serta meningkatkan latensi karena terlalu banyak permintaan yang dicoba ulang. Dalam beberapa kasus, hal ini dapat menyebabkan penghentian total karena semua permintaan dicoba ulang.
Untuk mempelajari lebih lanjut tentang bagaimana Amazon menggunakan waktu habis, percobaan ulang, dan mundur dengan jitter, lihat [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Atur waktu habis koneksi dan waktu habis permintaan untuk panggilan jarak jauh apa pun, serta umumnya untuk panggilan apa pun di seluruh proses. Banyak kerangka kerja yang menawarkan kemampuan waktu habis bawaan, tetapi Anda harus tetap memperhatikan bahwa nilai default bawaan bisa saja terlalu tinggi atau tak terbatas. Nilai yang terlalu tinggi mengurangi kegunaan waktu habis karena sumber daya terus terpakai saat klien menunggu terjadinya waktu habis. Nilai yang terlalu rendah akan menyebabkan lalu lintas yang tinggi di backend serta meningkatkan latensi karena terlalu banyak permintaan yang dicoba ulang. Dalam beberapa kasus, hal ini dapat menyebabkan penghentian total karena semua permintaan dicoba ulang.
+ [SDK AWS: Percobaan Ulang dan Waktu Habis](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## Sumber daya
**Dokumen terkait:**
+ [SDK AWS: Percobaan Ulang dan Waktu Habis](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway: Permintaan API Throttle untuk Peningkatan Throughput ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Kesalahan Percobaan Ulang dan Mundur Eksponensial di AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library: Waktu habis, percobaan ulang, dan mundur (backoff) dengan gangguan](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video terkait:**
+ [Percobaan ulang, mundur, dan gangguan: AWS re:Invent 2019: Memperkenalkan Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP06 Menjadikan layanan stateless jika memungkinkan
Layanan seharusnya tidak memerlukan state, atau seharusnya mengalihkan state sedemikian rupa sehingga di antara permintaan klien yang berbeda, tidak ada dependensi di penyimpanan data lokal di disk dan memori. Ini memungkinkan server diganti sesuka hati tanpa menyebabkan dampak ketersediaan. Amazon ElastiCache atau Amazon DynamoDB merupakan tujuan yang baik untuk state yang dialihkan.
![\[Pada aplikasi web stateless ini, state sesi dialihkan ke Amazon ElastiCache.\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
Ketika pengguna atau layanan berinteraksi dengan aplikasi, mereka sering melakukan serangkaian interaksi yang membentuk sesi. Sesi adalah data unik bagi pengguna yang lama berada di antara permintaan ketika mereka menggunakan aplikasi. Aplikasi stateless adalah aplikasi yang tidak memerlukan pengetahuan tentang interaksi sebelumnya dan tidak menyimpan informasi sesi.
Setelah dirancang menjadi stateless, Anda dapat menggunakan layanan komputasi nirserver, seperti AWS Lambda atau AWS Fargate.
Selain penggantian server, manfaat lain aplikasi stateless adalah kemampuannya untuk menyesuaikan skala secara horizontal karena sumber daya komputasi yang tersedia (seperti instans EC2 dan fungsi AWS Lambda) dapat melayani permintaan apa pun.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
+ Menjadikan aplikasi Anda stateless. Aplikasi stateless memungkinkan penskalaan horizontal dan toleran terhadap kegagalan simpul individual.
+ Hapus state yang sebenarnya dapat disimpan di parameter permintaan.
+ Setelah memeriksa apakah state diperlukan, pindahkan pelacakan state apa pun ke cache multi-zona yang tangguh atau penyimpanan data seperti Amazon ElastiCache, Amazon RDS, Amazon DynamoDB atau solusi data terdistribusi pihak ketiga. Simpan state yang tidak dapat dipindah ke penyimpanan data tangguh.
+ Beberapa data (seperti cookie) dapat diteruskan di header atau parameter kueri.
+ Lakukan pemfaktoran ulang untuk menghapus state yang dapat dengan cepat diteruskan di permintaan.
+ Beberapa data mungkin tidak terlalu diperlukan per permintaan dan dapat diambil sesuai permintaan.
+ Hapus data yang dapat diambil secara asinkron.
+ Tentukan penyimpanan data yang memenuhi kebutuhan state yang diperlukan.
+ Pertimbangkan basis data NoSQL untuk data non-rasional.
## Sumber daya
**Dokumen terkait:**
+ [Amazon Builders' Library: Menghindari fallback dalam sistem terdistribusi](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: Menghindari backlog antrean yang tidak dapat diatasi](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: Tantangan dan strategi caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 Mengimplementasikan tuas darurat
Tuas darurat adalah proses cepat yang dapat memitigasi dampak ketersediaan pada beban kerja.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Implementasikan tuas darurat. Ini adalah proses cepat yang dapat memitigasi dampak ketersediaan pada beban kerja. Tuas dapat dioperasikan tanpa adanya akar masalah. Tuas darurat idealnya mengurangi beban kognitif pada pemberi solusi (resolver) hingga nol dengan menyediakan kriteria aktivasi dan deaktivasi yang sepenuhnya deterministik. Tuas biasanya bersifat manual, tetapi dapat juga diotomatiskan.
+ Contoh tuas termasuk
+ Blok semua lalu lintas robot
+ Menyediakan halaman statis, bukan dinamis
+ Mengurangi frekuensi panggilan ke dependensi
+ Membatasi panggilan dari dependensi
+ Tips untuk mengimplementasikan dan menggunakan tuas darurat
+ Saat tuas diaktifkan, lakukan LEBIH SEDIKIT, tidak lebih banyak
+ Tetap sederhana, hindari perilaku bimodal
+ Uji tuas secara berkala
+ Ini adalah contoh yang BUKAN untuk tuas darurat
+ Menambah kapasitas
+ Memanggil pemilik layanan dari klien yang bergantung pada layanan Anda dan meminta mereka untuk mengurangi panggilan
+ Membuat perubahan pada kode dan merilisnya