REL04-BP01 Mengidentifikasi jenis sistem terdistribusi yang Anda perlukan - AWS Well-Architected Framework
Panduan implementasi

REL04-BP01 Mengidentifikasi jenis sistem terdistribusi yang Anda perlukan

Sistem terdistribusi bisa bersifat sinkron, asinkron, atau batch. Sistem sinkron harus memproses permintaan secepat mungkin dan berkomunikasi satu sama lain dengan membuat panggilan permintaan dan respons sinkron menggunakan protokol HTTP/S, REST, atau panggilan prosedur jarak jauh (RPC). Sistem asinkron berkomunikasi satu sama lain dengan bertukar data secara asinkron melalui layanan perantara tanpa memasangkan sistem-sistem terpisah. Sistem batch menerima data input dalam jumlah besar, menjalankan proses data otomatis tanpa campur tangan manusia, dan menghasilkan data output.

Hasil yang diinginkan: Rancang beban kerja yang secara efektif berinteraksi dengan dependensi sinkron, asinkron, dan batch.

Antipola umum:

  • Beban kerja menunggu respons dari dependensinya tanpa batas waktu, yang dapat menyebabkan klien beban kerja mengalami waktu habis, tanpa mengetahui apakah permintaannya telah diterima.

  • Beban kerja menggunakan serangkaian sistem dependen yang memanggil satu sama lain secara sinkron. Hal ini mengharuskan setiap sistem untuk tersedia dan berhasil memproses sebuah permintaan sebelum seluruh rangkaian dapat berhasil, sehingga menyebabkan perilaku dan ketersediaan secara keseluruhan menjadi rapuh.

  • Beban kerja berkomunikasi dengan dependensinya secara asinkron dan mengandalkan konsep pengiriman pesan yang dijamin persis satu kali, padahal sering kali masih pesan duplikat masih memungkinkan untuk diterima.

  • Beban kerja tidak menggunakan alat penjadwalan batch yang sesuai dan memungkinkan pelaksanaan pekerjaan batch yang sama secara bersamaan.

Manfaat menjalankan praktik terbaik ini: Hal biasa bagi beban kerja tertentu untuk mengimplementasikan satu atau lebih gaya komunikasi antara sinkron, asinkron, dan batch. Praktik terbaik ini membantu Anda mengidentifikasi kompromi berbeda yang terkait dengan setiap gaya komunikasi untuk membuat beban kerja Anda dapat menoleransi gangguan pada dependensinya.

Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan: Tinggi

Panduan implementasi

Bagian berikutnya berisi panduan implementasi umum dan spesifik untuk setiap jenis dependensi.

Panduan umum

  • Pastikan tujuan tingkat layanan (SLO) kinerja dan keandalan yang ditawarkan oleh dependensi Anda memenuhi persyaratan performa dan keandalan beban kerja Anda.

  • Gunakan layanan observabilitas AWS untuk memantau waktu respons dan tingkat kesalahan untuk memastikan dependensi Anda menyediakan layanan pada tingkat yang dibutuhkan oleh beban kerja Anda.

  • Identifikasi potensi tantangan yang mungkin dihadapi beban kerja Anda saat berkomunikasi dengan dependensinya. Sistem terdistribusi memiliki berbagai tantangan yang dapat menambah kompleksitas arsitektur, beban operasional, dan biaya. Tantangan umumnya mencakup latensi, gangguan jaringan, kehilangan data, penskalaan, dan jeda replikasi data.

  • Implementasikan penanganan kesalahan dan pembuatan log yang kuat untuk membantu Anda memecahkan masalah saat dependensi Anda mengalami masalah.

Dependensi sinkron

Dalam komunikasi sinkron, beban kerja Anda mengirimkan permintaan ke dependensinya dan memblokir operasi yang menunggu respons. Ketika dependensinya menerima permintaan, dependensi tersebut mencoba menanganinya sesegera mungkin dan mengembalikan respons ke beban kerja Anda. Tantangan besar pada komunikasi sinkron adalah jenis komunikasi ini menyebabkan penggabungan temporal, yang mengharuskan beban kerja Anda dan dependensinya untuk tersedia pada saat yang bersamaan. Ketika beban kerja Anda perlu berkomunikasi secara sinkron dengan dependensinya, pertimbangkan panduan berikut:

  • Beban kerja Anda seharusnya tidak bergantung pada beberapa dependensi sinkron untuk melakukan satu fungsi. Rangkaian dependensi ini meningkatkan kerapuhan secara keseluruhan karena semua dependensi di jalurnya harus tersedia agar permintaan berhasil diselesaikan.

  • Ketika dependensi 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 detail lebih lanjut tentang perilaku bimodal, lihat REL11-BP05 Menggunakan stabilitas statis untuk mencegah perilaku bimodal.

  • Harap diingat bahwa gagal cepat (fail fast) lebih baik daripada membuat beban kerja Anda menunggu. Misalnya, Panduan Developer AWS Lambda 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 diskusi yang bermanfaat tentang masalah ini, lihat Menyetel pengaturan permintaan HTTP SDK Java AWS untuk aplikasi Amazon DynamoDB sadar latensi.

  • Minimalkan jumlah panggilan yang dilakukan dari beban kerja Anda ke dependensinya untuk memenuhi satu permintaan. Memiliki banyak panggilan (chatty) di antara keduanya dapat meningkatkan penggabungan dan latensi.

Dependensi asinkron

Untuk memisahkan beban kerja Anda dari dependensinya secara sementara, keduanya harus berkomunikasi secara asinkron. Jika menggunakan pendekatan asinkron, beban kerja Anda dapat melanjutkan pemrosesan lain tanpa harus menunggu dependensinya, atau rangkaian dependensinya, untuk mengirimkan respons.

Ketika beban kerja Anda perlu berkomunikasi secara asinkron dengan dependensinya, pertimbangkan panduan berikut:

  • Tentukan apakah perpesanan atau streaming peristiwa perlu digunakan berdasarkan kasus penggunaan dan kebutuhan Anda. Perpesanan memungkinkan beban kerja Anda untuk berkomunikasi dengan dependensinya dengan mengirimkan dan menerima pesan melalui broker pesan. Streaming peristiwa memungkinkan beban kerja Anda dan dependensinya untuk menggunakan layanan streaming untuk memublikasikan dan berlangganan peristiwa, yang disampaikan dalam bentuk aliran data berkelanjutan, yang perlu diproses sesegera mungkin.

  • Perpesanan dan streaming peristiwa menangani pesan secara berbeda sehingga Anda perlu mengambil keputusan kompromi berdasarkan:

    • Prioritas pesan: broker pesan dapat memproses pesan prioritas tinggi sebelum pesan normal. Dalam streaming peristiwa, semua pesan memiliki prioritas yang sama.

    • Pemakaian pesan: broker pesan memastikan bahwa pemakai menerima pesan. Pemakai streaming peristiwa harus terus melacak pesan terakhir yang telah mereka baca.

    • Pengurutan pesan: dengan perpesanan, pesan tidak dijamin diterima dengan urutan sesuai pengirimannya kecuali Anda menggunakan pendekatan first-in-first-out (FIFO). Streaming peristiwa selalu mempertahankan urutan sesuai urutan data dibuat.

    • Penghapusan pesan: dengan perpesanan, konsumen harus menghapus pesan setelah memprosesnya. Layanan streaming peristiwa menambahkan pesan ke 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. Misalnya, ketika beban kerja Anda menginvokasi fungsi Lambda secara asinkron, Lambda menempatkan peristiwa di dalam antrean dan mengembalikan respons yang berhasil tanpa informasi tambahan. Setelah pemrosesan selesai, fungsi Lambda dapat mengirimkan hasil ke tujuan, yang 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 ditekankan bahwa layanan perpesanan atau streaming akan mengirimkan kembali sebuah pesan jika terjadi kegagalan jaringan atau jika konfirmasi belum diterima.

  • Jika beban kerja Anda tidak mendapatkan respons dari dependensinya, permintaan perlu dikirimkan kembali. Pertimbangkan untuk membatasi jumlah percobaan ulang untuk menghemat sumber daya CPU, memori, dan jaringan beban kerja Anda untuk menangani permintaan lainnya. Dokumentasi AWS Lambda menunjukkan cara menangani kesalahan untuk panggilan asinkron.

  • Manfaatkan alat-alat observabilitas, debugging, dan pelacakan yang sesuai untuk mengelola dan mengoperasikan komunikasi asinkron beban kerja Anda dengan dependensinya. Anda dapat menggunakan Amazon CloudWatch untuk memantau layanan perpesanan dan streaming peristiwa. Anda juga dapat menginstrumentasi beban kerja Anda dengan AWS X-Ray untukmendapatkan wawasan secara cepat untuk memecahkan masalah.

Dependensi batch

Sistem batch mengambil data input, memulai serangkaian pekerjaan untuk memprosesnya, dan 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 panduan berikut:

  • Tentukan rentang periode ketika beban kerja Anda harus menjalankan tugas batch. Beban kerja Anda dapat mengatur pola pengulangan untuk menginvokasi sistem batch, misalnya, setiap jam atau pada akhir setiap bulan.

  • Tentukan lokasi input data dan output data yang diproses. Pilih layanan penyimpanan, seperti Amazon Simple Storage Service (Amazon S3), Amazon Elastic File System (Amazon EFS), dan Amazon FSx for Lustre, yang memungkinkan beban kerja Anda membaca dan menulis file dalam skala besar.

  • Jika beban kerja Anda perlu menginvokasi beberapa pekerjaan batch, Anda dapat memanfaatkan AWS Step Functions untuk menyederhanakan orkestrasi pekerjaan batch yang berjalan di AWS atau on-premise. Proyek sampel ini menunjukkan orkestrasi pekerjaan batch menggunakan Step Functions, AWS Batch, dan Lambda.

  • Pantau pekerjaan batch untuk mencari kelainan, seperti pekerjaan yang membutuhkan waktu lebih lama dari yang seharusnya. Anda dapat menggunakan alat seperti Wawasan Kontainer CloudWatch untuk memantau lingkungan dan pekerjaan AWS Batch. Dalam hal ini, beban kerja Anda akan menghentikan pekerjaan berikutnya dari awal dan memberitahukan pengecualian kepada staf yang relevan.