# 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)