# Merancang interaksi di dalam 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 yang terjadi 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 Anda perlukan](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Menerapkan dependensi yang digabungkan secara longgar](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Lakukan pekerjaan konstan](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Buat operasi yang bermutasi menjadi idempoten](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Mengidentifikasi jenis sistem terdistribusi yang Anda perlukan
Sistem terdistribusi bisa bersifat sinkron, asinkron, atau batch. Sistem selaras harus memproses permintaan secepat mungkin dan berkomunikasi satu sama lain dengan membuat panggilan permintaan dan respons yang selaras dengan menggunakan protokol HTTP/S, REST, atau protokol panggilan prosedur jarak jauh (RPC). Sistem tidak selaras berkomunikasi satu sama lain dengan bertukar data secara asinkron melalui sebuah layanan perantara tanpa melakukan penggabungan (coupling) terhadap masing-masing sistem. Sistem batch menerima data input dalam jumlah besar, menjalankan proses-proses data otomatis tanpa campur tangan manusia, dan menghasilkan data output.
**Hasil yang diinginkan**: Merancang desain sebuah beban kerja yang berinteraksi secara efektif dengan dependensi selaras, tidak selaras, dan batch.
**Anti-pola umum:**
+ Beban kerja menunggu respons dari dependensinya tanpa batas waktu, yang dapat menyebabkan klien beban kerja mengalami habis waktu, tanpa mengetahui apakah permintaannya telah diterima atau tidak.
+ Beban kerja menggunakan sebuah rantai sistem dependen yang memanggil satu sama lain dengan selaras. Hal ini mengharuskan setiap sistem untuk tersedia dan berhasil memproses sebuah permintaan sebelum seluruh rantai sistem dapat berhasil, sehingga menyebabkan perilaku dan ketersediaan secara keseluruhan menjadi rapuh.
+ Beban kerja berkomunikasi dengan dependensinya secara tak selaras dan mengandalkan konsep pengiriman pesan yang dijamin persis satu kali, padahal sering kali pesan duplikat masih memungkinkan untuk diterima.
+ Beban kerja tidak menggunakan alat-alat penjadwalan batch yang sesuai dan memungkinkan pelaksanaan pekerjaan batch yang sama secara bersamaan.
**Manfaat menerapkan praktik terbaik ini**: Sudah menjadi hal yang umum untuk beban kerja tertentu untuk menerapkan satu atau beberapa gaya komunikasi antara selaras, tak selaras, dan batch. Praktik terbaik ini akan membantu Anda untuk mengidentifikasi kompromi-kompromi berbeda yang terkait dengan setiap gaya komunikasi untuk membuat beban kerja Anda dapat memberikan toleransi terhadap gangguan pada dependensinya.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan**: Tinggi
## Panduan implementasi
Bagian-bagian berikutnya berisi panduan implementasi umum dan spesifik untuk masing-masing jenis dependensi.
**Panduan umum**
+ Pastikan bahwa tujuan tingkat layanan (SLO) kinerja dan keandalan yang ditawarkan oleh dependensi Anda memenuhi persyaratan performa dan keandalan beban kerja Anda.
+ Gunakan [layanan observabilitas AWS](https://aws.amazon.com/cloudops/monitoring-and-observability) untuk [memantau waktu respons dan tingkat kesalahan](https://www.youtube.com/watch?v=or7uFFyHIX0) untuk memastikan bahwa dependensi Anda sedang menyediakan layanan pada tingkat yang dibutuhkan oleh beban kerja Anda.
+ Identifikasi potensi-potensi tantangan yang mungkin dihadapi beban kerja Anda saat berkomunikasi dengan dependensinya. Sistem terdistribusi [datang dengan berbagai tantangan yang](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) dapat meningkatkan kompleksitas arsitektur, beban operasional, dan biaya. Tantangan-tantangan yang biasanya dihadapi mencakup latensi, gangguan jaringan, kehilangan data, penskalaan, dan jeda replikasi data.
+ Terapkan penanganan dan [pencatatan log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) kesalahan yang kuat untuk membantu Anda memecahkan masalah saat dependensi Anda mengalami masalah.
**Dependensi sinkron**
Dalam komunikasi yang selaras, beban kerja Anda mengirimkan permintaan ke dependensinya dan memblokir operasi yang menunggu sebuah respons. Ketika dependensinya menerima permintaan, dependensi tersebut akan mencoba menanganinya sesegera mungkin dan mengembalikan respons ke beban kerja Anda. Tantangan besar pada komunikasi selaras adalah jenis komunikasi ini menyebabkan terjadinya penggabungan temporal, yang mengharuskan beban kerja Anda dan dependensinya untuk tersedia pada saat yang bersamaan. Ketika beban kerja Anda perlu berkomunikasi secara selaras dengan dependensinya, pertimbangkan panduan berikut:
+ Beban kerja Anda seharusnya tidak bergantung pada beberapa dependensi selaras untuk melakukan satu fungsi tunggal. Rangkaian dependensi ini akan meningkatkan kerapuhan secara keseluruhan karena semua dependensi di jalurnya harus tersedia agar permintaan berhasil diselesaikan.
+ Ketika sebuah dependensi berada dalam kondisi tidak sehat atau tidak tersedia, tentukan penanganan kesalahan dan strategi coba lagi. Hindari penggunaan perilaku bimodal. Perilaku bimodal adalah ketika beban kerja Anda menunjukkan perilaku yang berbeda dalam mode normal dan mode kegagalan. Untuk mendapatkan detail selengkapnya tentang perilaku bimodal, silakan lihat [REL11-BP05 Menggunakan stabilitas statis untuk mencegah perilaku bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html).
+ Harap diingat bahwa gagal cepat (fail fast) lebih baik daripada membuat beban kerja Anda menunggu. Misalnya, [Panduan Pengembang AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html) menjelaskan cara menangani percobaan ulang dan kegagalan saat Anda menginvokasi fungsi Lambda.
+ Tetapkan batas waktu saat beban kerja Anda memanggil dependensinya. Teknik ini menghindari waktu tunggu yang terlalu lama atau waktu tunggu respons tanpa batas. Untuk melihat pembahasan yang bermanfaat mengenai topik ini, silakan lihat [Menyetel pengaturan permintaan AWS Java SDK HTTP untuk aplikasi Amazon DynamoDB yang sadar latensi](https://aws.amazon.com/blogs/database/tuning-aws-java-sdk-http-request-settings-for-latency-aware-amazon-dynamodb-applications/).
+ Minimalkan jumlah panggilan yang dilakukan dari beban kerja Anda ke dependensinya untuk memenuhi satu permintaan tunggal. Memiliki banyak panggilan (chatty) di antara keduanya dapat meningkatkan penggabungan dan latensi.
**Dependensi tidak selaras**
Untuk memisahkan beban kerja Anda dari dependensinya secara sementara, keduanya harus berkomunikasi secara tidak selaras. Jika menggunakan pendekatan tidak selaras, beban kerja Anda dapat melanjutkan pemrosesan lain tanpa harus menunggu dependensinya, atau rangkaian dependensinya, untuk mengirimkan sebuah respons.
Ketika beban kerja Anda perlu berkomunikasi secara tidak selaras dengan dependensinya, pertimbangkan panduan berikut:
+ Tentukan apakah akan menggunakan perpesanan atau streaming peristiwa berdasarkan kasus penggunaan dan kebutuhan Anda. [Layanan perpesanan](https://aws.amazon.com/messaging/) akan memungkinkan beban kerja Anda untuk berkomunikasi dengan dependensinya dengan mengirim dan menerima pesan melalui broker pesan. [Streaming acara](https://aws.amazon.com/streaming-data/) akan memungkinkan beban kerja Anda dan dependensinya untuk menggunakan layanan streaming untuk mempublikasikan dan berlangganan acara, disampaikan sebagai aliran data berkelanjutan, yang perlu diproses sesegera mungkin.
+ Perpesanan dan streaming peristiwa menangani pesan secara berbeda sehingga Anda perlu mengambil keputusan-keputusan kompromi berdasarkan:
+ **Prioritas pesan:** broker pesan dapat memproses pesan prioritas tinggi lebih dahulu dari pesan normal. Dalam streaming peristiwa, semua pesan memiliki prioritas yang sama.
+ **Konsumsi pesan**: broker pesan memastikan bahwa konsumen menerima pesan. Pemakai streaming peristiwa harus terus melacak pesan terakhir yang telah mereka baca.
+ **Pengurutan pesan**: dengan pesan, Anda akan menerima pesan dalam urutan yang tepat yang dikirim dan tidak dijamin kecuali Anda menggunakan pendekatan first-in-first-out (FIFO). Streaming peristiwa selalu akan mempertahankan urutan sesuai urutan data ketika dibuat.
+ **Penghapusan pesan**: dengan layanan pengiriman pesan, konsumen harus menghapus pesan setelah memprosesnya. Layanan streaming peristiwa menambahkan pesan tersebut ke sebuah aliran dan tetap berada di sana sampai periode penyimpanan pesan berakhir. Kebijakan penghapusan ini menjadikan streaming peristiwa cocok untuk pemutaran ulang pesan.
+ Tentukan bagaimana beban kerja Anda mengetahui kapan dependensinya menyelesaikan pekerjaan. Sebagai contoh, saat beban kerja Anda menginvokasi [fungsi Lambda asinkron](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html), Lambda akan menempatkan peristiwa dalam antrean dan mengembalikan respons sukses tanpa menyertakan informasi tambahan. Setelah pemrosesan selesai, fungsi Lambda dapat [mengirim hasilnya ke sebuah tujuan](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-destinations), dapat dikonfigurasi berdasarkan keberhasilan atau kegagalan.
+ Bangun beban kerja Anda untuk menangani pesan duplikat dengan memanfaatkan idempotensi. Idempotensi adalah ketika hasil beban kerja Anda tidak berubah bahkan jika beban kerja Anda dihasilkan lebih dari sekali untuk pesan yang sama. Penting untuk menunjukkan bahwa layanan [pengiriman pesan](https://aws.amazon.com/sqs/faqs/#FIFO_queues) atau [streaming](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html) akan mengirim ulang pesan jika terjadi kegagalan jaringan atau jika ada pengakuan bahwa pesan belum diterima.
+ Jika beban kerja Anda tidak mendapatkan respons dari dependensinya, maka permintaan perlu dikirimkan kembali. Pertimbangkan untuk membatasi jumlah percobaan ulang untuk menghemat sumber daya CPU, memori, dan jaringan beban kerja Anda untuk menangani premintaan-permintaan lainnya. [Dokumentasi AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-errors) menunjukkan cara menangani kesalahan untuk panggilan asinkron.
+ Manfaatkan alat-alat observabilitas, debugging, dan pelacakan yang sesuai untuk mengelola dan mengoperasikan komunikasi tidak selaras dari beban kerja Anda dengan dependensinya. Anda dapat menggunakan [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) untuk memantau layanan [perpesanan](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) dan [streaming acara](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html). Anda juga dapat menginstrumentasikan beban kerja Anda dengan [AWS X-Ray](https://aws.amazon.com/xray/) untuk dengan cepat [mendapatkan wawasan](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html) untuk pemecahan masalah.
**Dependensi Batch**
Sistem batch mengambil data input, memulai serangkaian pekerjaan untuk memprosesnya, dan kemudian menghasilkan beberapa data output, tanpa intervensi manual. Tergantung ukuran data, pekerjaan dapat berjalan dari hitungan menit hingga, dalam beberapa kasus, beberapa hari. Ketika beban kerja Anda berkomunikasi dengan dependensinya, pertimbangkan untuk menggunakan panduan berikut:
+ Tentukan rentang periode ketika beban kerja Anda harus menjalankan tugas batch. Beban kerja Anda dapat mengatur pola pengulangan untuk menginvokasi sebuah sistem batch, misalnya, setiap jam atau pada akhir setiap bulan.
+ Tentukan lokasi input data dan output data yang diproses. Pilih sebuah layanan penyimpanan, seperti [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/), [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html), dan [Amazon FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html), yang memungkinkan beban kerja Anda untuk membaca dan menulis file dalam skala besar.
+ Jika beban kerja Anda perlu menginvokasi beberapa pekerjaan batch, Anda dapat memanfaatkan [AWS Step Functions](https://aws.amazon.com/step-functions/?step-functions.sort-by=item.additionalFields.postDateTime&step-functions.sort-order=desc) untuk menyederhanakan orkestrasi pekerjaan batch yang berjalan di AWS atau on-premise. [Proyek sampel](https://github.com/aws-samples/aws-stepfunction-complex-orchestrator-app) ini mendemonstrasikan orkestrasi pekerjaan batch dengan menggunakan Step Functions, [AWS Batch](https://aws.amazon.com/batch/), dan Lambda.
+ Lakukan pemantauan terhadap pekerjaan batch untuk mencari kelainan, seperti pekerjaan yang membutuhkan waktu lebih lama dari yang seharusnya. Anda dapat menggunakan alat-alat seperti [Wawasan Kontainer CloudWatch](https://docs.aws.amazon.com/batch/latest/userguide/cloudwatch-container-insights.html) untuk memantau lingkungan dan pekerjaan AWS Batch. Dalam keadaan ini, beban kerja Anda akan menghentikan pekerjaan berikutnya dari awal dan memberitahukan pengecualian kepada staf yang relevan.
## Sumber daya
**Dokumen terkait**:
+ [Operasi AWS Cloud: Pemantauan dan Observabilitas](https://aws.amazon.com/cloudops/monitoring-and-observability)
+ [Amazon Builders' Library: Tantangan dengan sistem terdistribusi](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [REL11-BP05 Menggunakan stabilitas statis untuk mencegah perilaku bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ [Panduan Pengembang AWS Lambda: Penanganan kesalahan dan percobaan ulang otomatis di AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html)
+ [Menyetel pengaturan permintaan AWS Java SDK HTTP untuk aplikasi Amazon DynamoDB yang sadar latensi](https://aws.amazon.com/blogs/database/tuning-aws-java-sdk-http-request-settings-for-latency-aware-amazon-dynamodb-applications/)
+ [Perpesanan AWS](https://aws.amazon.com/messaging/)
+ [Apa itu data streaming?](https://aws.amazon.com/streaming-data/)
+ [Panduan Pengembang AWS Lambda: Panggilan asinkron](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html)
+ [Pertanyaan Umum tentang Amazon Simple Queue Service: Antrean FIFO](https://aws.amazon.com/sqs/faqs/#FIFO_queues)
+ [Panduan Pengembang Amazon Kinesis Data Streams: Menangani Rekaman Duplikat](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html)
+ [Panduan Pengembang Amazon Simple Queue Service: Metrik CloudWatch yang Tersedia untuk Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html)
+ [Panduan Pengembang Amazon Kinesis Data Streams: Memantau Layanan Amazon Kinesis Data Streams dengan Amazon CloudWatch](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html)
+ [Panduan Pengembang AWS X-Ray: Konsep AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html)
+ [Sampel AWS di GitHub: AWS Step menggunakan Aplikasi Orkestrator Kompleks](https://github.com/aws-samples/aws-stepfunction-complex-orchestrator-app)
+ [Panduan Pengguna AWS Batch: Wawasan Kontainer CloudWatch AWS Batch](https://docs.aws.amazon.com/batch/latest/userguide/cloudwatch-container-insights.html)
**Video terkait**:
+ [AWS Summit SF 2022 - Observabilitas tumpukan penuh (full-stack) dan pemantauan aplikasi dengan AWS (COP310)](https://www.youtube.com/watch?v=or7uFFyHIX0)
**Alat terkait:**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [Log Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)
+ [Amazon FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/?step-functions.sort-by=item.additionalFields.postDateTime&step-functions.sort-order=desc)
+ [AWS Batch](https://aws.amazon.com/batch/)
# REL04-BP02 Menerapkan 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.
Memisahkan dependensi, seperti sistem antrean, sistem streaming, dan alur kerja, membantu meminimalkan dampak perubahan atau kegagalan pada suatu sistem. Pemisahan ini akan mengisolasi perilaku komponen dari mempengaruhi orang lain yang bergantung padanya, meningkatkan ketahanan dan kelincahan.
Dalam sistem penggabungan erat (tightly coupled), perubahan pada satu komponen dapat menyebabkan perubahan pada komponen lain yang bergantung padanya, yang mengakibatkan penurunan performa di semua komponen. Penggabungan *longgar* menghilangkan dependensi ini, sehingga komponen-komponen yang bergantung hanya perlu mengetahui antarmuka versi terbaru dan yang dipublikasikan. Mengimplementasikan penggabungan longgar antar dependensi akan memisahkan kegagalan pada salah satu dependensi agar tidak memengaruhi dependensi yang lain.
Penggabungan longgar akan memungkinkan Anda untuk mengubah kode atau menambahkan fitur ke sebuah komponen sekaligus meminimalkan risiko pada komponen lain yang bergantung pada komponen tersebut. Hal ini juga memungkinkan ketahanan hingga tingkatan terkecil (granular) pada tingkat komponen sehingga Anda dapat menambahkan skala (scale-out) atau bahkan mengubah implementasi yang mendasari dependensi.
Agar makin meningkatkan ketahanan melalui penggabungan longgar, buatlah interaksi-interaksi komponen tak selaras, jika memungkinkan. Model ini cocok untuk interaksi apa pun yang tidak memerlukan respons langsung dan di mana pengakuan bahwa permintaan telah terdaftar sudah dianggap cukup. Ini melibatkan satu komponen yang menghasilkan peristiwa dan komponen-komponen lain yang menggunakannya. Kedua komponen tidak terintegrasi melalui point-to-point interaksi langsung tetapi biasanya melalui lapisan penyimpanan tahan lama menengah, seperti SQS antrian Amazon, platform data streaming seperti Amazon Kinesis, atau. AWS Step Functions
![\[Diagram yang menunjukkan dependensi seperti sistem pengantrean dan penyeimbang beban digabungkan dengan longgar\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/dependency-diagram.png)
Amazon SQS mengantri dan hanya AWS Step Functions dua cara untuk menambahkan lapisan perantara untuk kopling longgar. Arsitektur berbasis peristiwa juga dapat dibangun menggunakan AWS Cloud Amazon EventBridge, yang dapat mengabstraksi klien (produsen acara) dari layanan yang mereka andalkan (konsumen acara). Amazon Simple Notification Service (AmazonSNS) adalah solusi efektif ketika Anda membutuhkan throughput tinggi, berbasis push, perpesanan. many-to-many Menggunakan SNS topik Amazon, sistem penerbit Anda dapat menyebarkan pesan ke sejumlah besar titik akhir pelanggan 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 lagi), dan tidak diproses. Dengan begitu, permintaan yang lebih baru (dan kemungkinan masih valid) dapat diproses sebagai gantinya.
**Hasil yang diinginkan:** Menerapkan dependensi yang digabungkan dengan longgar akan memungkinkan Anda untuk meminimalkan peluang kegagalan ke tingkat komponen, dan akan membantu Anda untuk mendiagnosis dan menyelesaikan masalah. Cara ini juga dapat menyederhanakan siklus pengembangan, sehingga memungkinkan tim untuk menerapkan perubahan-perubahan pada tingkat modular tanpa memengaruhi performa komponen-komponen lain yang bergantung padanya. Pendekatan ini memberikan kemampuan untuk menambahkan skala (scale-out) pada tingkat komponen berdasarkan kebutuhan sumber daya, serta pemanfaatan komponen yang berkontribusi terhadap efektivitas biaya.
**Anti-pola umum:**
+ Melakukan deployment beban kerja monolitik.
+ Langsung memanggil APIs antara tingkatan beban kerja tanpa kemampuan failover atau pemrosesan permintaan asinkron.
+ Penggabungan erat dengan menggunakan data bersama. Sistem-sistem yang digabungkan dengan longgar sebaiknya tidak berbagi data melalui basis data bersama atau bentuk penyimpanan data yang digabungkan secara erat, yang dapat menimbulkan kembali penggabungan erat dan akan menghambat skalabilitas.
+ Mengabaikan tekanan balik. Beban kerja Anda harus memiliki kemampuan untuk memperlambat atau menghentikan data yang masuk ketika sebuah komponen tidak dapat memprosesnya dengan kecepatan yang sama.
**Manfaat menerapkan praktik terbaik ini:** Penggabungan longgar akan membantu Anda untuk memisahkan perilaku suatu komponen dari komponen lainnya yang bergantung pada komponen tersebut, sehingga akan meningkatkan ketahanan dan ketangkasan. Kegagalan di salah satu komponen dipisahkan dari komponen lain.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Implementasikan dependensi yang digabungkan dengan longgar. Ada berbagai solusi yang memungkinkan Anda untuk membangun aplikasi yang digabungkan dengan longgar. Ini termasuk layanan untuk menerapkan antrian yang dikelola sepenuhnya, alur kerja otomatis, bereaksi terhadap peristiwa, dan APIs antara lain yang dapat membantu mengisolasi perilaku komponen dari komponen lain, dan dengan demikian meningkatkan ketahanan dan kelincahan.
+ **Bangun arsitektur berbasis peristiwa: [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) membantu Anda membangun arsitektur berbasis peristiwa** yang digabungkan dan didistribusikan secara longgar.
+ **Menerapkan antrian dalam sistem terdistribusi:** Anda dapat menggunakan [Amazon Simple Queue Service (AmazonSQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) untuk mengintegrasikan dan memisahkan sistem terdistribusi.
+ **Kontainerisasi komponen sebagai layanan mikro: Layanan mikro** [memungkinkan tim untuk membangun aplikasi yang terdiri dari komponen independen kecil yang berkomunikasi melalui definisi yang terdefinisi dengan baik.](https://aws.amazon.com/microservices/) APIs [Amazon Elastic Container Service (AmazonECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html), dan [Amazon Elastic Kubernetes Service (EKSAmazon](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)) dapat membantu Anda memulai lebih cepat dengan kontainer.
+ **Kelola alur kerja dengan Step Functions:** [Step Functions](https://aws.amazon.com/step-functions/getting-started/) membantu Anda mengoordinasikan beberapa AWS layanan ke dalam alur kerja yang fleksibel.
+ **Manfaatkan arsitektur perpesanan berlangganan publikasi (pub/sub): Amazon Simple** [Notification Service (AmazonSNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) menyediakan pengiriman pesan dari penerbit ke pelanggan (juga dikenal sebagai produsen dan konsumen).
### Langkah-langkah implementasi
+ Komponen dalam sebuah arsitektur yang didorong peristiwa dimulai oleh peristiwa. Peristiwa adalah tindakan-tindakan yang terjadi dalam sebuah sistem, seperti pengguna menambahkan item ke keranjang. Ketika suatu tindakan berhasil, sebuah peristiwa dihasilkan, yang akan menggerakkan komponen berikutnya dalam sistem tersebut.
+ [Membangun Aplikasi Event Driven dengan Amazon EventBridge](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
+ [AWS re:invent 2022 - Merancang Integrasi Berbasis Acara menggunakan Amazon EventBridge](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ Sistem olah pesan terdistribusi memiliki tiga bagian utama yang perlu diimplementasikan untuk sebuah arsitektur berbasis antrean. Mereka termasuk komponen sistem terdistribusi, antrian yang digunakan untuk decoupling (didistribusikan di SQS server Amazon), dan pesan dalam antrian. Sistem seperti ini biasanya memiliki produsen yang memulai pesan ke dalam antrean, dan konsumen yang menerima pesan dari antrean tersebut. Antrian menyimpan pesan di beberapa SQS server Amazon untuk redundansi.
+ [SQSArsitektur Amazon dasar](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [ Kirim Pesan Antara Aplikasi Terdistribusi dengan Amazon Simple Queue Service ](https://aws.amazon.com/getting-started/hands-on/send-messages-distributed-applications/)
+ Layanan mikro, jika dimanfaatkan dengan baik, akan meningkatkan pemeliharaan dan mendongkrak skalabilitas, karena komponen-komponen yang digabungkan dengan longgar dikelola oleh tim independen. Hal ini juga akan memungkinkan isolasi perilaku ke satu komponen jika terjadi perubahan.
+ [Menerapkan Layanan Mikro pada AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Mari Merancang\$1 Merancang arsitektur layanan mikro dengan kontainer ](https://aws.amazon.com/blogs/architecture/lets-architect-architecting-microservices-with-containers/)
+ Dengan AWS Step Functions Anda dapat membangun aplikasi terdistribusi, mengotomatiskan proses, mengatur layanan mikro, antara lain. Melakukan orkestrasi beberapa komponen ke dalam sebuah alur kerja otomatis akan memungkinkan Anda untuk memisahkan dependensi dalam aplikasi Anda.
+ [Buat Alur Kerja Tanpa Server dengan dan AWS Step FunctionsAWS Lambda](https://aws.amazon.com/tutorials/create-a-serverless-workflow-step-functions-lambda/)
+ [Memulai dengan AWS Step Functions](https://aws.amazon.com/step-functions/getting-started/)
## Sumber daya
**Dokumen terkait:**
+ [AmazonEC2: 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)
+ [ Putus dengan monolit Anda ](https://pages.awscloud.com/break-up-your-monolith.html)
+ [Mengatur Layanan Mikro Berbasis Antrian dengan dan Amazon AWS Step Functions SQS](https://aws.amazon.com/tutorials/orchestrate-microservices-with-message-queues-on-step-functions/)
+ [SQSArsitektur Amazon dasar](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [ Arsitektur Berbasis Antrian ](https://docs.aws.amazon.com/wellarchitected/latest/high-performance-computing-lens/queue-based-architecture.html)
**Video terkait:**
+ [AWS KTT New York 2019: Pengantar Arsitektur Berbasis Acara dan Amazon EventBridge (05) MAD2](https://youtu.be/tvELVa9D9qU)
+ [AWS RE: Invent 2018: Tutup Loop dan Membuka Pikiran: Cara Mengendalikan Sistem, Besar dan Kecil ARC337 (termasuk kopling longgar, kerja konstan, stabilitas statis)](https://youtu.be/O8xLxNje30M)
+ [AWS re:invent 2019: Pindah ke arsitektur berbasis acara (08) SVS3](https://youtu.be/h46IquqjF3E)
+ [AWS re:invent 2019: Aplikasi berbasis peristiwa tanpa server yang dapat diskalakan menggunakan Amazon dan Lambda SQS](https://www.youtube.com/watch?v=2rikdPIFc_Q)
+ [AWS re:invent 2022 - Merancang integrasi berbasis acara menggunakan Amazon EventBridge](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ [AWS RE: Invent 2017: Elastic Load Balancing Deep Dive dan Praktik Terbaik](https://www.youtube.com/watch?v=9TwkMMogojY)
# REL04-BP03 Lakukan pekerjaan 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, dengan tingkat kegagalan server normal yang ringan, maka beban yang ditanggung kecil. Namun demikian, jika ada sebuah peristiwa besar yang membuat separuh server menjadi tidak sehat, maka sistem pemeriksaan kondisi akan kewalahan untuk memperbarui sistem notifikasi dan menyampaikan status ke kliennya. Jadi alih-alih sistem pemeriksaan kondisi harus mengirim snapshot lengkap dari keadaan saat ini setiap kali. 100.000 status kesehatan server, masing-masing diwakili oleh satu bit, dan itu hanya akan menjadi muatan sebesar 12,5 KB. Saat tidak ada server yang gagal, atau semuanya gagal, sistem pemeriksaan kondisi akan 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 dengan 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 pilihan yang tepat](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS Re: Invent 2018: Tutup Loop dan Membuka Pikiran: Cara Mengendalikan Sistem, Besar dan Kecil ARC337 (termasuk pekerjaan konstan)](https://youtu.be/O8xLxNje30M?t=2482)
+ Untuk contoh sistem pemeriksaan kondisi yang memantau 100.000 server, lakukan rekayasa beban kerja sehingga ukuran payload tetap sama berapa pun jumlah keberhasilan atau kegagalan yang terjadi.
## Sumber daya
**Dokumen terkait:**
+ [AmazonEC2: 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/)
**Video terkait:**
+ [AWS KTT New York 2019: Pengantar Arsitektur yang Digerakkan oleh Acara dan Amazon EventBridge (05) MAD2](https://youtu.be/tvELVa9D9qU)
+ [AWS Re: Invent 2018: Tutup Loop dan Membuka Pikiran: Cara Mengendalikan Sistem, Besar dan Kecil ARC337 (termasuk pekerjaan konstan)](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS RE: Invent 2018: Tutup Loop dan Membuka Pikiran: Cara Mengendalikan Sistem, Besar dan Kecil ARC337 (termasuk kopling longgar, kerja konstan, stabilitas statis)](https://youtu.be/O8xLxNje30M)
+ [AWS re:invent 2019: Pindah ke arsitektur berbasis acara (08) SVS3](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Buat operasi yang bermutasi menjadi idempoten
Layanan idempoten menjamin setiap permintaan diproses tepat satu kali, sehingga pembuatan beberapa permintaan yang identik memiliki efek yang sama seperti membuat satu permintaan. Hal ini memudahkan klien untuk mengimplementasikan percobaan ulang permintaan tanpa khawatir permintaan tersebut akan diproses lebih dari sekali dan menyebabkan kesalahan. Untuk melakukan ini, klien dapat mengeluarkan permintaan API dengan token idempotensi, yang digunakan setiap kali permintaan diulang. API layanan idempoten menggunakan token untuk mengembalikan respons yang identik dengan respons yang dikembalikan saat pertama kali permintaan diselesaikan, bahkan jika status dasar sistem telah berubah.
Dalam sebuah sistem terdistribusi, cukup simpel untuk melakukan tindakan paling banyak satu kali (klien hanya membuat satu permintaan), atau setidaknya satu kali (tetap mengirimkan permintaan sampai klien mendapatkan konfirmasi berhasil). Lebih sulit untuk menjamin suatu tindakan dilakukan *tepat satu kali*, sehingga membuat beberapa permintaan yang identik memiliki efek yang sama seperti membuat satu permintaan. Menggunakan token idempotensi di API, layanan dapat menerima sebuah permintaan yang bermutasi satu kali atau lebih tanpa perlu membuat data ganda atau efek samping.
**Hasil yang diinginkan:** Anda memiliki pendekatan yang konsisten, terdokumentasi dengan baik, dan diadopsi secara luas untuk memastikan idempotensi di semua komponen dan layanan.
**Anti-pola umum:**
+ Anda menerapkan idempotensi secara sembarangan, bahkan ketika tidak diperlukan.
+ Anda memperkenalkan logika yang terlalu kompleks untuk menerapkan idempotensi.
+ Anda menggunakan stempel waktu sebagai kunci untuk idempotensi. Hal ini dapat menyebabkan ketidakakuratan karena perbedaan waktu atau karena banyak klien yang menggunakan stempel waktu yang sama untuk menerapkan perubahan.
+ Anda menyimpan seluruh payload untuk idempotensi. Dalam pendekatan ini, Anda menyimpan payload data lengkap untuk setiap permintaan dan menimpanya pada setiap permintaan baru. Hal ini dapat menurunkan kinerja dan memengaruhi skalabilitas.
+ Anda menghasilkan kunci secara tidak konsisten di seluruh layanan. Tanpa kunci yang konsisten, layanan mungkin gagal mengenali permintaan duplikat, yang mengakibatkan hasil yang tidak diinginkan.
**Manfaat menjalankan praktik terbaik ini:**
+ Skalabilitas yang lebih besar: Sistem dapat menangani percobaan ulang permintaan dan permintaan duplikat tanpa harus menjalankan logika tambahan atau manajemen status yang kompleks.
+ Keandalan yang meningkat: Idempotensi membantu layanan menangani beberapa permintaan identik secara konsisten, yang mengurangi risiko efek samping yang tidak diinginkan atau data duplikat. Hal ini terutama penting dalam sistem terdistribusi, yang sering mengalami kegagalan jaringan dan memerlukan percobaan ulang.
+ Konsistensi data yang lebih baik: Karena permintaan yang sama menghasilkan respons yang sama, idempotensi membantu menjaga konsistensi data di seluruh sistem terdistribusi. Hal ini penting untuk menjaga integritas transaksi dan operasi.
+ Penanganan kesalahan: Token idempotensi membuat penanganan kesalahan lebih mudah. Jika klien tidak menerima respons karena masalah, klien dapat secara aman mengirim ulang permintaan dengan token idempotensi yang sama.
+ Transparansi operasional: Idempotensi memungkinkan pemantauan dan pencatatan log yang lebih baik. Layanan dapat membuat log permintaan dengan token idempotensi mereka, sehingga memudahkan proses pelacakan dan debug masalah.
+ Kontrak API yang disederhanakan: Hal ini dapat menyederhanakan kontrak antara klien dan sistem sisi server dan mengurangi kekhawatiran akan kesalahan dalam pemrosesan data.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Dalam sebuah sistem terdistribusi, melakukan tindakan maksimal satu kali (klien hanya membuat satu permintaan) atau minimal satu kali (klien terus mengirimkan permintaan sampai klien mendapatkan konfirmasi berhasil) cukup mudah. Namun, sulit untuk menerapkan perilaku *tepat satu kali*. Untuk mencapai hal ini, klien Anda harus membuat dan memberikan token idempotensi untuk setiap permintaan.
Dengan menggunakan token idempotensi, layanan dapat membedakan antara permintaan baru dan permintaan berulang. Ketika layanan menerima permintaan dengan token idempotensi, layanan tersebut memeriksa apakah token sudah pernah digunakan. Jika token sudah pernah digunakan, layanan mengambil dan mengembalikan respons yang disimpan. Jika token masih baru, layanan memproses permintaan tersebut, menyimpan respons beserta token, lalu mengembalikan respons. Mekanisme ini membuat semua respons idempoten, yang meningkatkan keandalan dan konsistensi sistem terdistribusi.
Idempotensi juga merupakan perilaku penting dari arsitektur berbasis peristiwa. Arsitektur ini biasanya didukung oleh antrean pesan seperti Amazon SQS, Amazon MQ, Amazon Kinesis Streams, atau Amazon Managed Streaming for Apache Kafka (MSK). Dalam beberapa situasi, pesan yang diterbitkan hanya sekali dapat dikirim lebih dari sekali secara tidak sengaja. Ketika penerbit membuat dan menyertakan token idempotensi dalam pesan, penerbit tersebut meminta agar pemrosesan pesan duplikat yang diterima tidak menghasilkan tindakan berulang untuk pesan yang sama. Konsumen harus melacak setiap token yang diterima dan mengabaikan pesan yang berisi token duplikat.
Layanan dan konsumen juga harus meneruskan token idempotensi yang diterima ke layanan hilir apa pun yang dipanggil. Setiap layanan hilir dalam rantai pemrosesan juga harus memastikan bahwa idempotensi diimplementasikan untuk menghindari efek samping berupa pemrosesan pesan lebih dari sekali.
### Langkah-langkah implementasi
1. **Identifikasi operasi idempoten**
Tentukan operasi mana yang membutuhkan idempotensi. Hal ini biasanya termasuk metode HTTP POST, PUT, dan DELETE dan operasi basis data insert, update, atau delete. Operasi yang tidak mengubah status, seperti kueri hanya-baca, biasanya tidak memerlukan idempotensi kecuali jika memiliki efek samping.
1. **Gunakan pengidentifikasi unik**
Sertakan token unik di setiap permintaan operasi idempoten yang dikirim oleh pengirim, baik secara langsung dalam permintaan maupun sebagai bagian dari metadatanya (misalnya, header HTTP). Hal ini memungkinkan penerima mengenali dan menangani permintaan atau operasi duplikat. Pengidentifikasi yang biasa digunakan untuk token termasuk [Universally Unique Identifiers (UUID)](https://datatracker.ietf.org/doc/html/rfc9562) dan [K-Sortable Unique Identifiers (KSUID)](https://github.com/segmentio/ksuid).
1. **Lacak dan kelola status**
Pertahankan status setiap operasi atau permintaan dalam beban kerja Anda. Hal ini dapat dicapai dengan menyimpan token idempotensi dan status yang sesuai (seperti tertunda, selesai, atau gagal) dalam basis data, cache, atau penyimpanan persisten lainnya. Informasi status ini memungkinkan beban kerja mengidentifikasi dan menangani permintaan atau operasi duplikat.
Pertahankan konsistensi dan atomisitas dengan mekanisme kontrol konkurensi yang sesuai jika diperlukan, seperti kunci, transaksi, atau kontrol konkurensi optimis. Hal ini termasuk proses merekam token idempoten dan menjalankan semua operasi bermutasi yang terkait dengan pemrosesan permintaan. Hal ini membantu mencegah "race condition" dan memverifikasi bahwa operasi idempoten berjalan dengan benar.
Hapus token idempotensi lama secara teratur dari penyimpanan data untuk mengelola penyimpanan dan kinerja. Jika sistem penyimpanan Anda mendukungnya, pertimbangkan untuk menggunakan stempel waktu kedaluwarsa untuk data (sering dikenal sebagai nilai time to live atau TTL). Kemungkinan penggunaan ulang token idempotensi berkurang seiring waktu.
Opsi penyimpanan AWS umum yang biasanya digunakan untuk menyimpan token idempotensi dan status terkait mencakup:
+ **Amazon DynamoDB**: DynamoDB adalah layanan basis data NoSQL yang menyediakan kinerja latensi rendah dan ketersediaan tinggi, yang membuatnya sangat cocok untuk penyimpanan data terkait idempotensi. Model data nilai-kunci dan dokumen DynamoDB memungkinkan penyimpanan dan pengambilan token idempotensi dan informasi status terkait secara efisien. DynamoDB juga dapat menghapus token idempotensi secara otomatis jika aplikasi Anda menetapkan nilai TTL saat menyisipkannya.
+ **Amazon ElastiCache**: ElastiCache dapat menyimpan token idempotensi dengan throughput tinggi, latensi rendah, dan hemat biaya. ElastiCache (Redis) dan ElastiCache (Memcached) juga dapat menghapus token idempotensi secara otomatis jika aplikasi Anda menetapkan nilai TTL saat menyisipkannya.
+ **Amazon Relational Database Service (RDS):** Anda dapat menggunakan Amazon RDS untuk menyimpan token idempotensi dan informasi status terkait, terutama jika aplikasi Anda sudah menggunakan basis data relasional untuk tujuan lain.
+ **Amazon Simple Storage Service (S3):** Amazon S3 adalah layanan penyimpanan objek yang sangat mudah diskalakan dan tahan lama yang dapat digunakan untuk menyimpan token idempotensi dan metadata terkait. Kemampuan penentuan versi S3 dapat berguna terutama untuk pemeliharaan status operasi idempoten. Pilihan layanan penyimpanan biasanya tergantung pada faktor-faktor seperti volume data terkait idempotensi, karakteristik kinerja yang diperlukan, kebutuhan akan daya tahan dan ketersediaan, dan bagaimana mekanisme idempotensi terintegrasi dengan arsitektur beban kerja secara keseluruhan.
1. **Implementasikan operasi idempoten**
Rancang komponen API dan beban kerja Anda agar idempoten. Gabungkan pemeriksaan idempotensi ke dalam komponen beban kerja Anda. Sebelum Anda memproses permintaan atau melakukan suatu operasi, periksa apakah pengidentifikasi uniknya sudah diproses. Jika sudah, kembalikan hasil sebelumnya, bukan menjalankan operasi kembali. Misalnya, jika klien mengirim permintaan untuk membuat pengguna, periksa apakah sudah ada pengguna dengan pengidentifikasi unik yang sama. Jika pengguna sudah ada, sistem seharusnya mengembalikan informasi pengguna yang sudah ada tersebut, bukan membuat yang baru. Demikian pula, jika konsumen antrean menerima pesan dengan token idempotensi duplikat, konsumen ini harus mengabaikan pesan tersebut.
Buat rangkaian pengujian komprehensif yang memvalidasi idempotensi permintaan. Pengujian tersebut harus mencakup berbagai skenario, seperti permintaan berhasil, permintaan gagal, dan permintaan duplikat.
Jika beban kerja Anda memanfaatkan fungsi AWS Lambda, pertimbangkan Powertools for AWS Lambda. Powertools for AWS Lambda adalah toolkit developer yang membantu mengimplementasikan praktik terbaik nirserver dan meningkatkan kecepatan developer saat Anda bekerja dengan fungsi AWS Lambda. Secara khusus, alat ini menyediakan utilitas untuk mengubah fungsi Lambda Anda menjadi operasi idempoten yang aman untuk dicoba ulang.
1. **Komunikasikan idempotensi dengan jelas**
Dokumentasikan komponen API dan beban kerja Anda untuk mengomunikasikan dengan jelas sifat operasi yang idempoten. Hal ini membantu klien memahami perilaku yang diharapkan dan cara berinteraksi dengan beban kerja Anda secara andal.
1. **Pantau dan audit**
Implementasikan mekanisme pemantauan dan audit untuk mendeteksi masalah apa pun yang terkait dengan idempotensi respons, seperti variasi respons yang tidak terduga atau penanganan permintaan duplikat yang berlebihan. Hal ini dapat membantu Anda mendeteksi dan menyelidiki masalah atau perilaku yang tidak terduga dalam beban kerja Anda.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [REL05-BP03 Mengontrol dan membatasi panggilan percobaan ulang](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_limit_retries.html)
+ [REL06-BP01 Memantau semua komponen untuk beban kerja (Pembuatan)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP03 Mengirimkan notifikasi (Pemrosesan dan pembuatan alarm waktu nyata)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html)
+ [REL08-BP02 Integrasikan pengujian fungsional sebagai bagian dari deployment Anda](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_functional_testing.html)
**Dokumen terkait:**
+ [Amazon Builders' Library: Membuat pengulangan aman dengan API idempoten](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
+ [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 nikmat](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Amazon Elastic Container Service: Memastikan idempotensi](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/ECS_Idempotency.html)
+ [Bagaimana cara membuat fungsi Lambda saya idempoten?](https://repost.aws/knowledge-center/lambda-function-idempotent)
+ [Memastikan idempotensi dalam permintaan API Amazon EC2](https://docs.aws.amazon.com/ec2/latest/devguide/ec2-api-idempotency.html)
**Video terkait:**
+ [Membangun Aplikasi Terdistribusi dengan Arsitektur yang Didorong Peristiwa - AWS Online Tech Talks](https://www.youtube.com/watch?v=gA2-eqDVSng&t=1668s)
+ [AWS re:invent 2023 - Membangun aplikasi generasi berikutnya dengan arsitektur yang didorong peristiwa](https://www.youtube.com/watch?v=KXR17uwLEC8)
+ [AWS re:Invent 2023 - Pola integrasi tingkat lanjut & kompromi untuk sistem yang digabungkan dengan metode penggabungan longgar ](https://www.youtube.com/watch?v=FGKGdUiZKto)
+ [AWS re:Invent 2023 - Pola yang didorong peristiwa tingkat lanjut dengan Amazon EventBridge](https://www.youtube.com/watch?v=6X4lSPkn4ps)
+ [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)
**Alat terkait:**
+ [Idempotensi dengan AWS Lambda Powertools (Java)](https://docs.powertools.aws.dev/lambda/java/utilities/idempotency/)
+ [Idempotensi dengan AWS Lambda Powertools (Python)](https://docs.powertools.aws.dev/lambda/python/latest/utilities/idempotency/)
+ [Halaman GitHub AWS Lambda Powertools](https://github.com/aws-powertools/)