# Arsitektur beban kerja
**Topics**
+ [REL 3 Bagaimana cara mendesain arsitektur layanan beban kerja Anda?](w2aac19b9b7b5.md)
+ [REL 4 Bagaimana cara mendesain interaksi di sistem terdistribusi untuk mencegah kegagalan?](w2aac19b9b7b7.md)
+ [REL 5 Bagaimana cara mendesain interaksi di sistem terdistribusi untuk memitigasi atau bertahan dari kegagalan?](w2aac19b9b7b9.md)
# REL 3 Bagaimana cara mendesain arsitektur layanan beban kerja Anda?
Bangun beban kerja yang mudah diskalakan dan andal menggunakan arsitektur berorientasi layanan (SOA) atau arsitektur layanan mikro. Arsitektur berorientasi layanan (SOA) adalah praktik untuk membuat komponen perangkat lunak dapat digunakan ulang lewat antarmuka layanan. Arsitektur layanan mikro melangkah lebih jauh untuk membuat komponen menjadi lebih kecil dan lebih sederhana.
**Topics**
+ [REL03-BP01 Memilih cara untuk menyegmentasi beban kerja](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Bangun layanan yang berfokus pada domain dan fungsionalitas bisnis khusus](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Berikan kontrak layanan per API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Memilih cara untuk menyegmentasi beban kerja
Segmentasi beban kerja penting saat menentukan persyaratan ketahanan aplikasi Anda. Arsitektur monolitik harus dihindari jika memungkinkan. Sebagai gantinya, pertimbangkan dengan cermat komponen aplikasi mana yang dapat dipecah menjadi layanan mikro. Bergantung pada persyaratan aplikasi Anda, solusinya mungkin merupakan kombinasi arsitektur berorientasi layanan (SOA) dengan layanan mikro jika memungkinkan. Beban kerja yang mampu berada dalam kondisi stateless akan lebih mampu di-deploy sebagai layanan mikro.
**Hasil yang diinginkan:** Beban kerja harus dapat didukung, dapat diskalakan, dan di-coupling selonggar mungkin.
Saat membuat pilihan tentang cara menyegmentasikan beban kerja Anda, seimbangkan manfaat dengan kerumitannya. Hal yang tepat untuk produk baru yang mengejar jadwal peluncuran pertama akan berbeda dengan hal yang dibutuhkan oleh beban kerja yang dibangun untuk diskalakan dari awal. Saat memfaktor ulang monolit yang ada, Anda perlu mempertimbangkan seberapa baik aplikasi akan mendukung dekomposisi menuju kondisi stateless. Dengan memecah layanan menjadi bagian-bagian yang lebih kecil, tim kecil yang diberi tanggung jawab khusus akan dapat mengembangkan dan mengelolanya. Namun, layanan yang lebih kecil dapat menimbulkan kompleksitas yang mencakup kemungkinan peningkatan latensi, debugging yang lebih kompleks, dan peningkatan beban operasional.
**Antipola umum:**
+ Dalam [layanan mikro, *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) adalah situasi saat komponen atomik menjadi sangat saling bergantung sehingga kegagalan salah satu komponen akan menghasilkan kegagalan yang jauh lebih besar, sehingga komponen ini pun menjadi kaku dan rapuh seperti monolit.
**Manfaat menjalankan praktik ini:**
+ Segmen yang lebih spesifik akan menghasilkan ketangkasan, fleksibilitas organisasi, dan skalabilitas yang lebih besar.
+ Dampak gangguan layanan yang berkurang.
+ Komponen-komponen aplikasi mungkin memiliki persyaratan ketersediaan yang berbeda-beda, yang dapat didukung oleh segmentasi yang lebih atomik.
+ Tanggung jawab yang ditentukan khusus untuk tim yang mendukung beban kerja.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Pilih jenis arsitektur berdasarkan cara beban kerja disegmentasikan. Pilih arsitektur SOA atau layanan mikro (atau dalam beberapa kasus yang jarang terjadi, arsitektur monolitik). Bahkan jika Anda memilih untuk memulai arsitektur monolit, Anda harus memastikan bahwa arsitektur tersebut modular dan pada akhirnya dapat berkembang menjadi SOA atau layanan mikro seiring dengan skala produk Anda dengan adopsi pengguna. SOA dan layanan mikro masing-masing menawarkan segmentasi yang lebih kecil, yang lebih disarankan sebagai arsitektur modern yang dapat diskalakan dan andal, tetapi ada tarik ulur yang perlu dipertimbangkan, terutama saat melakukan deployment arsitektur layanan mikro.
Salah satu tarik ulur utama adalah Anda sekarang memiliki arsitektur komputasi terdistribusi yang dapat mempersulit dalam memenuhi persyaratan latensi pengguna dan ada kerumitan tambahan dalam proses debugging dan penelusuran interaksi pengguna. Anda dapat menggunakan AWS X-Ray untuk membantu Anda memecahkan masalah ini. Efek lain yang perlu dipertimbangkan adalah peningkatan kompleksitas operasional seiring Anda meningkatkan jumlah aplikasi yang Anda kelola, yang memerlukan deployment banyak komponen independen.
![\[Diagram yang menunjukkan perbandingan antara arsitektur monolitik, berorientasi layanan, dan layanan mikro\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Langkah implementasi
+ Tentukan arsitektur yang sesuai untuk memfaktor ulang atau membangun aplikasi Anda. SOA dan layanan mikro masing-masing menawarkan segmentasi yang lebih kecil, serta diutamakan sebagai arsitektur modern yang dapat diskalakan dan diandalkan. SOA dapat menjadi kompensasi yang baik untuk mencapai segmentasi yang lebih kecil sembari menghindari beberapa kompleksitas dari layanan mikro. Untuk detail selengkapnya, lihat [Tarik Ulur Layanan Mikro](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Jika dapat diterima beban kerja dan didukung organisasi, Anda harus menggunakan arsitektur layanan mikro untuk mencapai ketangkasan dan keandalan terbaik. Untuk detail selengkapnya, lihat [Menerapkan Layanan Mikro di AWS.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Pertimbangkan untuk mengikuti karakteristik pohon [*Strangler Fig* , yaitu pola](https://martinfowler.com/bliki/StranglerFigApplication.html) untuk memfaktor ulang monolit menjadi komponen yang lebih kecil. Hal ini memerlukan penggantian komponen aplikasi tertentu secara bertahap dengan aplikasi dan layanan baru. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) bertindak sebagai titik awal untuk pemfaktoran ulang secara bertahap. Untuk detail selengkapnya, lihat [Memigrasikan beban kerja lama di on-premise dengan lancar menggunakan pola strangler](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ Implementasi layanan mikro mungkin memerlukan mekanisme penemuan layanan untuk memungkinkan layanan terdistribusi ini berkomunikasi satu sama lain. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) dapat digunakan dengan arsitektur berorientasi layanan untuk menyediakan penemuan dan akses layanan yang andal. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) juga dapat digunakan untuk penemuan layanan berbasis DNS yang dinamis.
+ Jika Anda bermigrasi dari monolit ke SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) dapat membantu menjembatani kesenjangan sebagai bus layanan saat mendesain ulang aplikasi lama di cloud.
+ Untuk monolit yang ada dengan satu basis data bersama, pilih cara mengatur ulang data menjadi segmen yang lebih kecil. Segmentasi ini dapat didasarkan pada unit bisnis, pola akses, atau struktur data. Pada titik ini dalam proses pemfaktoran ulang, Anda harus memilih untuk melanjutkan dengan jenis basis data relasional atau nonrelasional (NoSQL). Untuk detail selengkapnya, lihat [Dari SQL ke NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Tingkat upaya untuk rencana implementasi:** Tinggi
## Sumber daya
**Praktik terbaik terkait:**
+ [REL03-BP02 Bangun layanan yang berfokus pada domain dan fungsionalitas bisnis khusus](rel_service_architecture_business_domains.md)
**Dokumen terkait:**
+ [Amazon API Gateway: Mengonfigurasi API REST Menggunakan OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Apa itu Arsitektur Berorientasi Layanan?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Konteks Terikat (pola sentral di Desain yang Didorong Domain)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Mengimplementasikan Layanan Mikro di AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompensasi Layanan Mikro](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Layanan mikro - definisi istilah arsitektur baru ini](https://www.martinfowler.com/articles/microservices.html)
+ [Layanan mikro di AWS](https://aws.amazon.com/microservices/)
+ [Apa itu AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Contoh terkait:**
+ [Lokakarya Modernisasi Aplikasi Iteratif](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Video terkait:**
+ [Memberikan Keunggulan dengan Layanan Mikro di AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Bangun layanan yang berfokus pada domain dan fungsionalitas bisnis khusus
Arsitektur berorientasi layanan (SOA) membangun layanan dengan fungsi yang digambarkan dengan baik berdasarkan kebutuhan bisnis. Layanan mikro menggunakan model domain dan konteks terbatas untuk membatasinya lebih lanjut sehingga tiap-tiap layanan hanya melakukan satu hal. Dengan berfokus pada fungsionalitas tertentu, Anda dapat memilah-milah persyaratan keandalan berbagai layanan, dan menargetkan investasi dengan lebih spesifik. Masalah bisnis yang ringkas dan adanya tim kecil terkait tiap-tiap layanan juga memungkinkan penskalaan organisasi yang lebih mudah.
Dalam merancang arsitektur layanan mikro, penggunaan Desain yang Didorong Domain (DDD) bermanfaat untuk memodelkan masalah bisnis menggunakan entitas. Misalnya, untuk situs web Amazon.com, entitas dapat meliputi paket, pengantaran, jadwal, harga, diskon, dan mata uang. Model ini kemudian dibagi lebih lanjut ke dalam model-model yang lebih kecil menggunakan [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html), di mana entitas dengan fitur dan atribut yang serupa dikelompokkan masing-masing. Jadi, menggunakan untuk kasus Amazon.com, paket, pengantaran, dan jadwal adalah bagian dari konteks pengiriman, sedangkan harga, diskon, dan mata uang adalah bagian dari konteks harga. Dengan model yang dibagi ke dalam konteks, muncul templat untuk membatasi layanan mikro.
![\[Memodelkan templat untuk cara membatasi layanan mikro\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/building-services.png)
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Rancang beban kerja Anda berdasarkan domain bisnis Anda serta fungsionalitasnya masing-masing. Dengan berfokus pada fungsionalitas tertentu, Anda dapat memilah-milah persyaratan keandalan berbagai layanan, dan menargetkan investasi dengan lebih spesifik. Masalah bisnis yang ringkas dan adanya tim kecil terkait tiap-tiap layanan juga memungkinkan penskalaan organisasi yang lebih mudah.
+ Lakukan Analisis Domain untuk memetakan desain yang didorong domain (DDD) untuk beban kerja Anda. Lalu, Anda dapat memilih tipe arsitektur untuk memenuhi kebutuhan beban kerja Anda.
+ [Cara memecah Monolit menjadi Layanan-Layanan Mikro](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Mulai Menggunakan DDD di Tengah-Tengah Sistem Warisan](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software”](https://www.amazon.com/gp/product/0321125215)
+ [Implementasi Layanan Mikro di AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Urai layanan Anda menjadi komponen-komponen sekecil mungkin. Dengan arsitektur layanan mikro, Anda dapat memisahkan beban kerja Anda menjadi komponen-komponen dengan fungsionalitas minimal guna memungkinkan skalabilitas dan ketangkasan organisasi.
+ Tetapkan API untuk beban kerja serta tujuan desainnya, batas, dan pertimbangan lainnya untuk penggunaan.
+ Tetapkan API.
+ Penetapan API harus memungkinkan pertumbuhan dan parameter tambahan.
+ Tetapkan ketersediaan yang dirancang.
+ API Anda mungkin memiliki beberapa tujuan desain untuk berbagai fitur.
+ Buat batasan
+ Gunakan pengujian untuk menetapkan batasan kemampuan beban kerja Anda.
## Sumber daya
**Dokumen terkait:**
+ [Amazon API Gateway: Mengonfigurasi API REST Menggunakan OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Konteks Terbatas (pola sentral dalam Desain yang Didorong Domain)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software”](https://www.amazon.com/gp/product/0321125215)
+ [Mulai Menggunakan DDD di Tengah-Tengah Sistem Warisan](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Cara memecah Monolit menjadi Layanan-Layanan Mikro](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implementasi Layanan Mikro di AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompromi Layanan Mikro](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Layanan mikro - definisi istilah arsitektur baru ini](https://www.martinfowler.com/articles/microservices.html)
+ [Layanan mikro di AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Berikan kontrak layanan per API
Kontrak layanan merupakan perjanjian yang didokumentasikan antara tim terkait integrasi layanan dan ini meliputi definisi API yang dapat dibaca mesin, batas tingkat, dan harapan akan performa. Strategi versioning memungkinkan klien Anda untuk terus menggunakan API yang ada dan memigrasikan aplikasi mereka ke API yang lebih baru ketika mereka siap. Deployment dapat terjadi kapan saja, selama kontrak tidak dilanggar. Tim penyedia layanan dapat menggunakan tumpukan teknologi pilihan mereka untuk memenuhi kontrak API. Demikian juga, konsumen layanan dapat menggunakan teknologi mereka sendiri.
Layanan mikro mengambil konsep arsitektur yang berorientasi pada layanan (SOA) sampai pada titik membuat layanan yang memiliki serangkaian fungsionalitas minimal. Setiap layanan mempublikasikan sasaran dan batas desain dan API, serta pertimbangan lainnya untuk menggunakan layanan. Ini menetapkan *kontrak* dengan aplikasi yang memanggil. Hal ini akan mencapai tiga manfaat utama:
+ Layanan memiliki masalah bisnis yang ringkas untuk dilayani dan tim kecil yang memiliki masalah bisnis tersebut. Ini memungkinkan penskalaan organisasi yang lebih baik.
+ Tim dapat melakukan deploy kapan saja selama mereka memenuhi persyaratan API mereka dan persyaratan kontrak lainnya.
+ Tim dapat menggunakan tumpulkan teknologi apa pun yang mereka inginkan selama mereka memenuhi persyaratan API mereka dan persyaratan kontrak lainnya.
Amazon API Gateway adalah layanan terkelola penuh yang memudahkan developer membuat, mempublikasikan, memelihara, memantau, dan mengamankan API dalam skala apa pun. Amazon API Gateway menangani semua tugas yang terlibat dalam menerima dan memproses hingga ratusan ribu panggilan API bersamaan, termasuk manajemen lalu lintas, otorisasi dan kontrol akses, pemantauan, dan manajemen versi API. Menggunakan OpenAPI Specification (OAS), yang sebelumnya disebut sebagai Swagger Specification, Anda dapat menetapkan kontrak API Anda dan mengimpornya ke API Gateway. Dengan API Gateway, kemudian Anda dapat memversikan dan melakukan deploy API.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Rendah
## Panduan implementasi
+ Berikan kontrak layanan per API Kontrak layanan merupakan perjanjian yang didokumentasikan antara tim terkait integrasi layanan dan ini meliputi definisi API yang dapat dibaca mesin, batas tingkat, dan harapan akan performa.
+ [Amazon API Gateway: Mengonfigurasi API REST Menggunakan OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Strategi versioning memungkinkan klien untuk terus menggunakan API yang ada dan memigrasikan aplikasi mereka ke API yang lebih baru ketika mereka siap.
+ Amazon API Gateway adalah layanan terkelola penuh yang memudahkan developer membuat API dalam skala apa pun. Menggunakan OpenAPI Specification (OAS), yang sebelumnya disebut sebagai Swagger Specification, Anda dapat menetapkan kontrak API Anda dan mengimpornya ke API Gateway. Dengan API Gateway, kemudian Anda dapat memversikan dan melakukan deploy API.
## Sumber daya
**Dokumen terkait:**
+ [Amazon API Gateway: Mengonfigurasi API REST Menggunakan OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Konteks Terikat (pola sentral di Desain yang Didorong Domain)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementasi Layanan Mikro di AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompromi Layanan Mikro](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Layanan mikro - definisi istilah arsitektur baru ini](https://www.martinfowler.com/articles/microservices.html)
+ [Layanan mikro di AWS](https://aws.amazon.com/microservices/)
# REL 4 Bagaimana cara mendesain interaksi di sistem terdistribusi untuk mencegah 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 mencegah kegagalan dan meningkatkan waktu rata-rata antara kegagalan (MTBF).
**Topics**
+ [REL04-BP01 Mengidentifikasi jenis sistem terdistribusi yang diperlukan](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Mengimplementasikan dependensi yang digabungkan secara longgar](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Melakukan tugas konstan](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Menjadikan semua respons idempoten](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Mengidentifikasi jenis sistem terdistribusi yang diperlukan
Sistem terdistribusi hard real-time memerlukan respons yang diberikan secara sinkron dan cepat, sedangkan sistem soft real-time memiliki jendela waktu yang lebih fleksibel untuk respons, dalam hitungan menit atau lebih. Sistem offline menangani respons melalui batch atau pemrosesan asinkron. Sistem terdistribusi hard real-time memiliki persyaratan keandalan yang paling ketat.
Tantangan yang paling sulit [dengan sistem terdistribusi](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) adalah sistem terdistribusi hard real-time, yang dikenal juga sebagai layanan permintaan/balasan. Hal yang membuatnya sulit adalah permintaan yang masuk tidak dapat diprediksikan dan respons yang diberikan harus cepat (misalnya, pelanggan menunggu respons dengan aktif). Contohnya mencakup server web front-end, urutan pipeline, transaksi kartu kredit, setiap API AWS, dan telefoni.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Identifikasikan jenis sistem terdistribusi yang diperlukan. Tantangan dengan sistem terdistribusi meliputi latensi, penskalaan, pemahaman atas API jaringan, mengonversi dan membatalkan konversi data, serta kompleksitas algoritme seperti Paxos. Ketika sistem tumbuh lebih besar dan lebih terdistribusi, apa yang tadinya merupakan kasus edge teoretis berubah menjadi kejadian biasa.
+ [Amazon Builders' Library: Tantangan dengan sistem terdistribusi](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ Sistem terdistribusi hard real-time memerlukan respons yang diberikan secara sinkron dan cepat.
+ Sistem soft real-time memiliki jendela waktu yang lebih fleksibel untuk respons, dalam hitungan menit atau lebih.
+ Sistem offline menangani respons melalui batch atau pemrosesan asinkron.
+ Sistem terdistribusi hard real-time memiliki persyaratan keandalan yang paling ketat.
## Sumber daya
**Dokumen terkait:**
+ [Amazon EC2: Memastikan Idempotensi](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: Tantangan dengan sistem terdistribusi](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: Keandalan, kerja konstan, dan pilihan yang tepat](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Apa Itu Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Apa Itu Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Video terkait:**
+ [AWS New York Summit 2019: Pengantar Arsitektur Berbasis Peristiwa dan Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: Cara Mengontrol Sistem, ARC337 Besar dan Kecil (mencakup penggabungan longgar, kerja konstan, stabilitas statis)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Beralih ke arsitektur berbasis peristiwa (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP02 Mengimplementasikan dependensi yang digabungkan secara longgar
Dependensi seperti sistem pengantrean, sistem streaming, alur kerja, dan penyeimbang beban digabungkan secara longgar. Penggabungan longgar membantu memisahkan perilaku suatu komponen dari komponen lainnya yang bergantung pada komponen tersebut, sehingga meningkatkan ketahanan dan ketangkasan.
Jika perubahan pada satu komponen memaksa komponen lain yang bergantung padanya untuk turut berubah, berarti komponen-komponen tersebut *digabungkan* secara ketat. *Penggabungan* longgar memecah dependensi ini sehingga komponen-komponen yang bergantung hanya perlu mengetahui antarmuka versi terbaru dan yang dipublikasikan. Implementasi penggabungan longgar antar dependensi memisahkan kegagalan pada salah satu dependensi agar tidak memengaruhi dependensi lain.
Penggabungan longgar memungkinkan Anda untuk menambahkan kode atau fitur tambahan ke sebuah komponen sambil meminimalkan risiko pada komponen-komponen yang bergantung pada komponen tersebut. Selain itu, skalabilitas juga meningkat karena Anda dapat melakukan penskalaan ke luar atau bahkan menubah implementasi dasar dari dependensi.
Agar makin meningkatkan ketahanan melalui penggabungan longgar, jadikan interaksi komponen asinkron apabila memungkinkan. Model ini cocok untuk interaksi apa pun yang tidak memerlukan respons cepat dan ketika terdaftarnya suatu permintaan cukup perlu diketahui. Ini melibatkan satu komponen yang menghasilkan peristiwa dan komponen lain yang menggunakannya. Kedua komponen tersebut tidak terintegrasi melalui interaksi titik ke titik langsung, tetapi biasanya melalui lapisan penyimpanan tahan lama perantara, seperti antrean SQS atau platform data streaming seperti Amazon Kinesis, atau AWS Step Functions.
![\[Diagram yang menunjukkan dependensi seperti sistem pengantrean dan penyeimbang beban digabungkan secara longgar\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png)
Antrean Amazon SQS dan Penyeimbang Beban Elastis hanyalah dua cara untuk menambahkan lapisan perantara untuk penggabungan longgar. Arsitektur yang didorong peristiwa juga dapat dibangun di AWS Cloud menggunakan Amazon EventBridge, yang dapat mengabstraksi klien (penghasil peristiwa) dari layanan yang mereka andalkan (pemakai peristiwa). Amazon Simple Notification Service (Amazon SNS) adalah solusi efektif ketika Anda memerlukan olah pesan dari banyak ke banyak dengan throughput tinggi dan berbasis push. Menggunakan topik Amazon SNS, sistem penerbit Anda dapat menyebarkan pesan ke titik akhir pelanggan dalam jumlah besar untuk pemrosesan paralel.
Meskipun antrean menawarkan sejumlah manfaat, di sebagian besar sistem waktu nyata yang keras, permintaan yang lebih lama dari waktu ambang batas (sering kali dalam hitungan detik) harus dianggap basi (klien telah menyerah dan sudah tidak menunggu respons), dan tidak diproses. Dengan begitu, permintaan yang lebih baru (dan kemungkinan masih valid) dapat diproses sebagai gantinya.
**Antipola umum:**
+ Men-deploy satu komponen tunggal sebagai bagian dari beban kerja.
+ Memanggil API secara langsung antar tingkatan beban kerja tanpa kemampuan failover atau pemrosesan permintaan secara asinkron.
**Manfaat menjalankan praktik terbaik ini:** Penggabungan longgar membantu memisahkan perilaku suatu komponen dari komponen lainnya yang bergantung pada komponen tersebut, sehingga meningkatkan ketahanan dan ketangkasan. Kegagalan di salah satu komponen dipisahkan dari komponen lain.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Implementasikan dependensi yang digabungkan secara longgar. Dependensi seperti sistem pengantrean, sistem streaming, alur kerja, dan penyeimbang beban digabungkan secara longgar. Penggabungan longgar membantu memisahkan perilaku suatu komponen dari komponen lainnya yang bergantung pada komponen tersebut, sehingga meningkatkan ketahanan dan ketangkasan.
+ [AWS re:Invent 2019: Beralih ke arsitektur berbasis peristiwa (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Apa itu Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Apa itu Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ Amazon EventBridge memungkinkan Anda membangun arsitektur yang didorong peristiwa, yang digabungkan dan didistribusikan secara longgar.
+ [AWS New York Summit 2019: Pengantar Arsitektur Berbasis Peristiwa dan Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ Jika perubahan pada satu komponen memaksa komponen lain yang bergantung padanya untuk turut berubah, berarti komponen-komponen tersebut digabungkan secara ketat. Penggabungan longgar memecah dependensi ini sehingga komponen-komponen dependensi hanya perlu mengetahui antarmuka versi terbaru dan yang dipublikasikan.
+ Jadikan interaksi komponen asinkron apabila memungkinkan. Model ini cocok untuk interaksi apa pun yang tidak memerlukan respons cepat dan ketika terdaftarnya suatu permintaan cukup perlu diketahui.
+ [AWS re:Invent 2019: Aplikasi berbasis peristiwa nirserver yang dapat diskalakan menggunakan Amazon SQS dan Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
## Sumber daya
**Dokumen terkait:**
+ [AWS re:Invent 2019: Beralih ke arsitektur berbasis peristiwa (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon EC2: Memastikan Idempotensi](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: Tantangan dengan sistem terdistribusi](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: Keandalan, kerja konstan, dan secangkir kopi yang enak](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Apa itu Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Apa itu Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Video terkait:**
+ [AWS New York Summit 2019: Pengantar Arsitektur Berbasis Peristiwa dan Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: Cara Mengontrol Sistem, ARC337 Besar dan Kecil (mencakup penggabungan longgar, kerja konstan, stabilitas statis)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Beralih ke arsitektur berbasis peristiwa (SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Aplikasi berbasis peristiwa nirserver yang dapat diskalakan menggunakan Amazon SQS dan Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
# REL04-BP03 Melakukan tugas konstan
Sistem dapat gagal mengalami kegagalan saat ada perubahan besar dan cepat pada beban. Misalnya, jika beban kerja Anda sedang melakukan pemeriksaan kondisi yang memantau kondisi dari ribuan server, beban kerja Anda harus mengirimkan payload berukuran sama (snapshot penuh berisi status saat ini) setiap saat. Saat tidak ada server yang gagal, atau semuanya gagal, sistem pemeriksaan kondisi melakukan tugas konstan tanpa perubahan besar dan cepat.
Misalnya, jika sistem pemeriksaan kondisi sedang memantau 100.000 server, beban di dalamnya kecil, dengan tingkat kegagalan server normal yang ringan. Namun, jika sebuah peristiwa besar menjadikan separuh server tidak sehat, sistem pemeriksaan kondisi akan kewalahan untuk memperbarui sistem notifikasi dan menyampaikan status ke kliennya. Jadi sebagai gantinya, sistem pemeriksaan kondisi harus mengirimkan snapshot penuh berisi status saat ini setiap saat. 100.000 status sehat server, masing-masing diwakili satu bit, hanyalah satu payload berukuran 12,5 KB. Saat tidak ada server yang gagal, atau semuanya gagal, sistem pemeriksaan kondisi melakukan tugas konstan, dan perubahan yang besar dan cepat bukanlah ancaman untuk stabilitas sistem. Seperti inilah Amazon Route 53 menangani pemeriksaan kondisi untuk titik akhir (seperti alamat IP) untuk menentukan bagaimana pengguna akhir dirutekan ke sana.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Rendah
## Panduan implementasi
+ Lakukan tugas konstan sehingga sistem tidak gagal saat terdapat perubahan beban yang besar dan cepat.
+ Implementasikan dependensi yang digabungkan secara longgar. Dependensi seperti sistem pengantrean, sistem streaming, alur kerja, dan penyeimbang beban digabungkan secara longgar. Penggabungan longgar membantu memisahkan perilaku suatu komponen dari komponen lainnya yang bergantung pada komponen tersebut, sehingga meningkatkan ketahanan dan ketangkasan.
+ [Amazon Builders' Library: Keandalan, kerja konstan, dan secangkir kopi yang enak](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (mencakup tugas konstan)](https://youtu.be/O8xLxNje30M?t=2482)
+ Untuk contoh sistem pemeriksaan kondisi yang memantau 100.000 server, rekayasa beban kerja sehingga ukuran payload tetap sama berapa pun jumlah keberhasilan atau kegagalan.
## Sumber daya
**Dokumen terkait:**
+ [Amazon EC2: Memastikan Idempotensi](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: Tantangan dengan sistem terdistribusi](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: Keandalan, kerja konstan, dan secangkir kopi yang enak](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Video terkait:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (mencakup tugas konstan)](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (mencakup penggabungan longgar, kerja konstan, stabilitas statis)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Menjadikan semua respons idempoten
Layanan idempoten menjanjikan setiap permintaan diselesaikan tepat satu kali, sehingga pembuatan beberapa permintaan yang sama memiliki efek yang sama seperti membuat satu permintaan. Layanan idempoten memudahkan klien untuk mengimplementasikan percobaan ulang tanpa takut permintaan akan salah diproses beberapa kali. Untuk melakukan ini, klien dapat mengeluarkan permintaan API dengan token idempotensi—token yang sama digunakan setiap permintaan diulang. API layanan idempoten menggunakan token untuk mengembalikan respons yang identik dengan respons yang dikembalikan saat pertama kali permintaan diselesaikan.
Dalam sistem terdistribusi, mudah untuk melakukan tindakan paling banyak satu kali (klien hanya membuat satu permintaan), atau setidaknya satu kali (tetap meminta sampai klien mendapat konfirmasi berhasil). Namun, sulit untuk menjamin suatu tindakan bersifat idempoten, yang berarti tindakan dilakukan *tepat* satu kali, sehingga pembuatan beberapa permintaan identik memiliki efek yang sama seperti membuat satu permintaan. Menggunakan token idempotensi di API, layanan dapat menerima permintaan yang bermutasi satu kali atau lebih tanpa membuat rekaman ganda atau efek samping.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Menjadikan semua respons idempoten. Layanan idempoten menjanjikan setiap permintaan diselesaikan tepat satu kali, sehingga pembuatan beberapa permintaan yang sama memiliki efek yang sama seperti membuat satu permintaan.
+ Klien dapat mengeluarkan permintaan API dengan token idempotensi—token yang sama digunakan setiap permintaan diulang. API layanan idempoten menggunakan token untuk mengembalikan respons yang identik dengan respons yang dikembalikan saat pertama kali permintaan diselesaikan.
+ [Amazon EC2: Memastikan Idempotensi](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
## Sumber daya
**Dokumen terkait:**
+ [Amazon EC2: Memastikan Idempotensi](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: Tantangan dengan sistem terdistribusi](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: Keandalan, kerja konstan, dan secangkir kopi yang enak](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Video terkait:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (mencakup penggabungan longgar, kerja konstan, stabilitas statis)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# 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