Penanganan kesalahan sementara

  • Artikel

Semua aplikasi yang berkomunikasi dengan layanan dan sumber daya jarak jauh harus peka terhadap kesalahan sementara. Ini terutama berlaku untuk aplikasi yang berjalan di cloud, di mana, karena sifat lingkungan dan konektivitas melalui internet, jenis kesalahan ini cenderung lebih sering ditemui. Kesalahan sementara termasuk hilangnya konektivitas jaringan sesaat ke komponen dan layanan, tidak tersedianya layanan sementara, dan batas waktu yang terjadi ketika layanan sibuk. Kesalahan ini sering mengoreksi diri, jadi, jika tindakan diulang setelah penundaan yang sesuai, kemungkinan akan berhasil.

Artikel ini menyediakan panduan umum untuk penanganan kesalahan sementara. Untuk informasi tentang menangani kesalahan sementara saat Anda menggunakan layanan Azure, lihat Panduan coba lagi untuk layanan Azure.

Mengapa kesalahan sementara terjadi di cloud?

Kesalahan sementara dapat terjadi di lingkungan apa pun, pada platform atau sistem operasi apa pun, dan dalam segala jenis aplikasi. Untuk solusi yang berjalan pada infrastruktur lokal lokal, performa dan ketersediaan aplikasi dan komponennya biasanya dipertahankan melalui redundansi perangkat keras yang mahal dan sering kali kurang digunakan, dan komponen dan sumber daya terletak dekat satu sama lain. Pendekatan ini membuat kegagalan lebih kecil kemungkinannya, tetapi kesalahan sementara masih dapat terjadi, karena dapat pemadaman yang disebabkan oleh peristiwa tak terduga seperti catu daya eksternal atau masalah jaringan, atau skenario bencana lainnya.

Penghostingan cloud, termasuk sistem cloud privat, dapat menawarkan ketersediaan keseluruhan yang lebih tinggi dengan menggunakan sumber daya bersama, redundansi, failover otomatis, dan alokasi sumber daya dinamis di banyak node komputasi komoditas. Namun, karena sifat lingkungan cloud, kesalahan sementara lebih mungkin terjadi. Ada beberapa alasan untuk ini:

  • Banyak sumber daya di lingkungan cloud dibagikan, dan akses ke sumber daya ini tunduk pada pembatasan untuk melindungi sumber daya. Beberapa layanan menolak koneksi ketika beban naik ke tingkat tertentu, atau ketika tingkat throughput maksimum tercapai, untuk memungkinkan pemrosesan permintaan yang ada dan untuk mempertahankan performa layanan untuk semua pengguna. Pembatasan membantu menjaga kualitas layanan untuk tetangga dan penyewa lain yang menggunakan sumber daya bersama.

  • Lingkungan cloud menggunakan sejumlah besar unit perangkat keras komoditas. Mereka memberikan performa dengan mendistribusikan beban secara dinamis di beberapa unit komputasi dan komponen infrastruktur. Mereka memberikan keandalan dengan mendaur ulang atau mengganti unit yang gagal secara otomatis. Karena sifat dinamis ini, kesalahan sementara dan kegagalan koneksi sementara mungkin kadang-kadang terjadi.

  • Seringkali ada lebih banyak komponen perangkat keras, termasuk infrastruktur jaringan seperti router dan load balancer, antara aplikasi dan sumber daya dan layanan yang digunakannya. Infrastruktur tambahan ini kadang-kadang dapat menyebabkan latensi koneksi tambahan dan kesalahan koneksi sementara.

  • Kondisi jaringan antara klien dan server mungkin bervariasi, terutama ketika komunikasi melintasi internet. Bahkan di lokasi lokal, beban lalu lintas yang berat dapat memperlambat komunikasi dan menyebabkan kegagalan koneksi terputus-terputus.

Tantangan

Kesalahan sementara dapat memiliki efek besar pada ketersediaan aplikasi yang dirasakan, bahkan jika telah diuji secara menyeluruh dalam semua keadaan yang dapat diperkirakan. Untuk memastikan bahwa aplikasi yang dihosting cloud beroperasi dengan andal, Anda perlu memastikan bahwa aplikasi tersebut dapat merespons tantangan berikut:

  • Aplikasi harus dapat mendeteksi kesalahan ketika terjadi dan menentukan apakah kesalahan cenderung sementara, tahan lama, atau kegagalan terminal. Sumber daya yang berbeda kemungkinan akan mengembalikan respons yang berbeda ketika kesalahan terjadi, dan respons ini juga dapat bervariasi tergantung pada konteks operasi. Misalnya, respons untuk kesalahan ketika aplikasi membaca dari penyimpanan mungkin berbeda dari respons untuk kesalahan saat menulis ke penyimpanan. Banyak sumber daya dan layanan memiliki kontrak kegagalan sementara yang terdokumen dengan baik. Namun, ketika informasi tersebut tidak tersedia, mungkin sulit untuk menemukan sifat kesalahan dan apakah kemungkinan bersifat sementara.

  • Aplikasi harus dapat mencoba kembali operasi jika menentukan bahwa kesalahan kemungkinan bersifat sementara. Ini juga perlu melacak berapa kali operasi dicoba kembali.

  • Aplikasi harus menggunakan strategi yang sesuai untuk percobaan ulang. Strategi menentukan berapa kali aplikasi harus mencoba kembali, penundaan antara setiap upaya, dan tindakan yang harus diambil setelah upaya yang gagal. Jumlah upaya yang sesuai dan penundaan antara masing-masing sering sulit ditentukan. Strategi akan bervariasi tergantung pada jenis sumber daya dan pada kondisi operasi sumber daya dan aplikasi saat ini.

Panduan umum

Panduan berikut dapat membantu Anda merancang mekanisme penanganan kesalahan sementara yang sesuai untuk aplikasi Anda.

Menentukan apakah ada mekanisme coba lagi bawaan

  • Banyak layanan menyediakan SDK atau pustaka klien yang berisi mekanisme penanganan kesalahan sementara. Kebijakan percobaan ulang yang digunakannya biasanya disesuaikan dengan sifat dan persyaratan layanan target. Atau, antarmuka REST untuk layanan mungkin mengembalikan informasi yang dapat membantu Anda menentukan apakah coba lagi sesuai dan berapa lama menunggu sebelum upaya coba lagi berikutnya.

  • Anda harus menggunakan mekanisme coba lagi bawaan ketika tersedia, kecuali Anda memiliki persyaratan spesifik dan dipahami dengan baik yang membuat perilaku coba lagi yang berbeda lebih tepat.

Tentukan apakah operasi cocok untuk mencoba kembali

  • Lakukan operasi coba lagi hanya ketika kesalahan bersifat sementara (biasanya ditunjukkan oleh sifat kesalahan) dan ketika setidaknya ada beberapa kemungkinan bahwa operasi akan berhasil ketika dicoba kembali. Tidak ada gunanya mencoba kembali operasi yang mencoba operasi yang tidak valid, seperti pembaruan database ke item yang tidak ada atau permintaan ke layanan atau sumber daya yang mengalami kesalahan fatal.

  • Secara umum, terapkan percobaan ulang hanya ketika Anda dapat menentukan efek penuh dari melakukannya dan kapan kondisi dipahami dengan baik dan dapat divalidasi. Jika tidak, biarkan kode panggilan menerapkan percobaan ulang. Ingatlah bahwa kesalahan yang dikembalikan dari sumber daya dan layanan di luar kontrol Anda mungkin berevolusi dari waktu ke waktu, dan Anda mungkin perlu mengunjungi kembali logika deteksi kesalahan sementara Anda.

  • Saat Anda membuat layanan atau komponen, pertimbangkan untuk menerapkan kode kesalahan dan pesan yang membantu klien menentukan apakah mereka harus mencoba kembali operasi yang gagal. Secara khusus, tunjukkan apakah klien harus mencoba kembali operasi (mungkin dengan mengembalikan nilai isTransient ) dan menyarankan penundaan yang sesuai sebelum upaya coba lagi berikutnya. Jika Anda membangun layanan web, pertimbangkan untuk mengembalikan kesalahan kustom yang ditentukan dalam kontrak layanan Anda. Meskipun klien generik mungkin tidak dapat membaca kesalahan ini, mereka berguna dalam pembuatan klien kustom.

Menentukan jumlah dan interval coba lagi yang sesuai

  • Optimalkan jumlah coba lagi dan interval ke jenis kasus penggunaan. Jika Anda tidak mencoba kembali cukup waktu, aplikasi tidak dapat menyelesaikan operasi dan mungkin akan gagal. Jika Anda mencoba kembali terlalu banyak kali, atau dengan interval yang terlalu pendek antara percobaan, aplikasi mungkin menyimpan sumber daya seperti utas, koneksi, dan memori untuk jangka waktu yang lama, yang berdampak buruk pada kesehatan aplikasi.

  • Sesuaikan nilai untuk interval waktu dan jumlah upaya coba lagi ke jenis operasi. Misalnya, jika operasi adalah bagian dari interaksi pengguna, interval harus singkat dan hanya beberapa percobaan ulang yang harus dicoba. Dengan menggunakan pendekatan ini, Anda dapat menghindari membuat pengguna menunggu respons, yang menyimpan koneksi terbuka dan dapat mengurangi ketersediaan untuk pengguna lain. Jika operasi adalah bagian dari alur kerja yang berjalan lama atau kritis, di mana membatalkan dan memulai ulang prosesnya mahal atau memakan waktu, sebaiknya tunggu lebih lama antara upaya dan coba lagi lebih lama.

  • Perlu diingat bahwa menentukan interval yang sesuai antara percobaan ulang adalah bagian yang paling sulit dalam merancang strategi yang sukses. Strategi yang umum digunakan menggunakan jenis interval percobaan ulang berikut:

    • Back-off eksponensial. Aplikasi menunggu beberapa saat sebelum percobaan ulang pertama dan kemudian secara eksponensial meningkatkan waktu antara setiap percobaan ulang berikutnya. Misalnya, operasi mungkin mencoba kembali operasi setelah 3 detik, 12 detik, 30 detik, dan sebagainya.

    • Interval bertambah bertahap. Aplikasi menunggu beberapa saat sebelum percobaan ulang pertama, lalu secara bertahap meningkatkan waktu antara setiap percobaan ulang berikutnya. Misalnya, operasi mungkin mencoba kembali operasi setelah 3 detik, 7 detik, 13 detik, dan sebagainya.

    • Interval reguler. Aplikasi menunggu periode waktu yang sama antara setiap upaya. Misalnya, operasi mungkin mencoba kembali operasi setiap 3 detik.

    • Coba lagi segera. Terkadang kesalahan sementara singkat, mungkin disebabkan oleh peristiwa seperti tabrakan paket jaringan atau lonjakan komponen perangkat keras. Dalam hal ini, mencoba kembali operasi segera tepat karena mungkin berhasil jika kesalahan dibersihkan pada saat aplikasi merakit dan mengirim permintaan berikutnya. Namun, tidak boleh ada lebih dari satu upaya coba lagi segera. Anda harus beralih ke strategi alternatif, seperti tindakan back-off atau fallback eksponensial, jika percobaan kembali segera gagal.

    • Pengacakan. Salah satu strategi coba lagi yang tercantum sebelumnya dapat menyertakan pengacakan untuk mencegah beberapa instans klien mengirim upaya coba lagi berikutnya secara bersamaan. Misalnya, satu instans mungkin mencoba kembali operasi setelah 3 detik, 11 detik, 28 detik, dan sebagainya, sementara instans lain mungkin mencoba kembali operasi setelah 4 detik, 12 detik, 26 detik, dan sebagainya. Pengacakan adalah teknik berguna yang dapat dikombinasikan dengan strategi lain.

  • Sebagai pedoman umum, gunakan strategi back-off eksponensial untuk operasi latar belakang, dan gunakan strategi coba lagi interval langsung atau reguler untuk operasi interaktif. Dalam kedua kasus, Anda harus memilih penundaan dan jumlah percobaan ulang sehingga latensi maksimum untuk semua upaya coba ulang berada dalam persyaratan latensi menyeluruh yang diperlukan.

  • Mempertimbangkan kombinasi semua faktor yang berkontribusi pada batas waktu maksimum keseluruhan untuk operasi yang dicoba kembali. Faktor-faktor ini termasuk waktu yang diperlukan koneksi yang gagal untuk menghasilkan respons (biasanya diatur oleh nilai batas waktu di klien), penundaan antara upaya coba lagi, dan jumlah maksimum percobaan ulang. Total semua waktu ini dapat mengakibatkan waktu operasi keseluruhan yang lama, terutama ketika Anda menggunakan strategi penundaan eksponensial di mana interval antara percobaan ulang tumbuh dengan cepat setelah setiap kegagalan. Jika suatu proses harus memenuhi perjanjian tingkat layanan tertentu (SLA), waktu operasi secara keseluruhan, termasuk semua batas waktu dan penundaan, harus berada dalam batas yang ditentukan dalam SLA.

  • Jangan menerapkan strategi coba lagi yang terlalu agresif. Ini adalah strategi yang memiliki interval yang terlalu pendek atau percobaan ulang yang terlalu sering. Mereka dapat memiliki efek buruk pada sumber daya atau layanan target. Strategi ini dapat mencegah sumber daya atau layanan pulih dari status kelebihan bebannya, dan akan terus memblokir atau menolak permintaan. Skenario ini menghasilkan lingkaran setan, di mana semakin banyak permintaan dikirim ke sumber daya atau layanan. Akibatnya, kemampuannya untuk pulih semakin berkurang.

  • Perhitungkan batas waktu operasi saat Anda memilih interval coba lagi untuk menghindari peluncuran upaya berikutnya segera (misalnya, jika periode waktu habis mirip dengan interval coba lagi). Selain itu, pertimbangkan apakah Anda perlu menyimpan total periode yang mungkin (batas waktu ditambah interval coba lagi) di bawah total waktu tertentu. Jika operasi memiliki batas waktu yang sangat singkat atau lama, batas waktu mungkin memengaruhi berapa lama untuk menunggu dan seberapa sering mencoba kembali operasi.

  • Gunakan jenis pengecualian dan data apa pun yang dikandungnya, atau kode kesalahan dan pesan yang dikembalikan dari layanan, untuk mengoptimalkan jumlah percobaan ulang dan interval di antaranya. Misalnya, beberapa pengecualian atau kode kesalahan (seperti kode HTTP 503, Layanan Tidak Tersedia, dengan header Coba Lagi-Setelah dalam respons) mungkin menunjukkan berapa lama kesalahan mungkin berlangsung, atau bahwa layanan gagal dan tidak akan merespons upaya berikutnya.

Hindari anti-pola

  • Dalam kebanyakan kasus, hindari implementasi yang mencakup lapisan duplikat kode coba lagi. Hindari desain yang mencakup mekanisme coba lagi bertahap atau yang menerapkan coba lagi di setiap tahap operasi yang melibatkan hierarki permintaan, kecuali Anda memiliki persyaratan khusus yang memerlukannya. Dalam keadaan luar biasa ini, gunakan kebijakan yang mencegah terlalu banyak percobaan ulang dan periode penundaan serta pastikan Anda memahami konsekuensinya. Misalnya, satu komponen membuat permintaan ke komponen lain, yang kemudian mengakses layanan target. Jika Anda menerapkan coba lagi dengan hitungan tiga pada kedua panggilan, ada sembilan upaya coba lagi secara total terhadap layanan. Banyak layanan dan sumber daya menerapkan mekanisme coba lagi bawaan. Anda harus menyelidiki bagaimana Anda dapat menonaktifkan atau memodifikasi mekanisme ini jika Anda perlu menerapkan percobaan ulang pada tingkat yang lebih tinggi.

  • Jangan pernah menerapkan mekanisme coba lagi tanpa akhir. Melakukannya kemungkinan akan mencegah sumber daya atau layanan pulih dari situasi kelebihan beban dan menyebabkan pembatasan dan menolak koneksi berlanjut untuk waktu yang lebih lama. Gunakan jumlah percobaan ulang yang terbatas, atau terapkan pola seperti Circuit Breaker untuk memungkinkan layanan pulih.

  • Jangan pernah melakukan percobaan ulang langsung lebih dari sekali.

  • Hindari menggunakan interval coba lagi reguler saat Anda mengakses layanan dan sumber daya di Azure, terutama ketika Anda memiliki jumlah upaya coba lagi yang tinggi. Pendekatan terbaik dalam skenario ini adalah strategi back-off eksponensial dengan kemampuan pemecah sirkuit.

  • Cegah beberapa instans klien yang sama, atau beberapa instans klien yang berbeda, agar tidak mengirim percobaan ulang secara bersamaan. Jika skenario ini kemungkinan akan terjadi, masukkan pengacakan ke dalam interval coba lagi.

Menguji strategi dan implementasi coba lagi Anda

  • Uji sepenuhnya strategi coba lagi Anda di bawah sekumpulan keadaan selebar mungkin, terutama ketika aplikasi dan sumber daya target atau layanan yang digunakannya berada di bawah beban ekstrem. Untuk memeriksa perilaku selama pengujian, Anda dapat:

    • Menyuntikkan kesalahan sementara dan nontransien ke dalam layanan. Misalnya, mengirim permintaan yang tidak valid atau menambahkan kode yang mendeteksi permintaan pengujian dan merespons dengan berbagai jenis kesalahan. Untuk contoh yang menggunakan TestApi, lihat Pengujian Injeksi Kesalahan dengan TestApi dan Pengantar TestApi – Bagian 5: API Injeksi Kesalahan Kode Terkelola.

    • Buat mockup sumber daya atau layanan yang mengembalikan berbagai kesalahan yang mungkin dikembalikan oleh layanan nyata. Mencakup semua jenis kesalahan yang dirancang untuk dideteksi oleh strategi percobaan ulang Anda.

    • Untuk layanan kustom yang Anda buat dan sebarkan, paksa kesalahan sementara terjadi dengan menonaktifkan atau membebani layanan untuk sementara waktu. (Jangan mencoba membebani sumber daya bersama atau layanan bersama apa pun di Azure.)

    • Untuk API berbasis HTTP, pertimbangkan untuk menggunakan pustaka dalam pengujian otomatis Anda untuk mengubah hasil permintaan HTTP, baik dengan menambahkan waktu pulang pergi tambahan atau dengan mengubah respons (seperti kode status HTTP, header, isi, atau faktor lainnya). Melakukannya memungkinkan pengujian deterministik dari subset kondisi kegagalan, untuk kesalahan sementara dan jenis kegagalan lainnya.

    • Lakukan faktor beban tinggi dan pengujian bersamaan untuk memastikan bahwa mekanisme dan strategi coba lagi berfungsi dengan benar dalam kondisi ini. Pengujian ini juga akan membantu memastikan bahwa percobaan kembali tidak memiliki efek buruk pada pengoperasian klien atau menyebabkan kontaminasi silang antar permintaan.

Mengelola konfigurasi kebijakan coba lagi

  • Kebijakan coba lagi adalah kombinasi dari semua elemen strategi coba lagi Anda. Ini mendefinisikan mekanisme deteksi yang menentukan apakah kesalahan kemungkinan bersifat sementara, jenis interval yang akan digunakan (seperti back-off reguler, eksponensial, dan pengacakan), nilai interval aktual, dan berapa kali untuk mencoba kembali.

  • Terapkan percobaan ulang di banyak tempat, bahkan dalam aplikasi paling sederhana, dan di setiap lapisan aplikasi yang lebih kompleks. Daripada melakukan hard-coding elemen dari setiap kebijakan di beberapa lokasi, pertimbangkan untuk menggunakan titik pusat untuk menyimpan semua kebijakan. Misalnya, simpan nilai seperti interval dan jumlah coba lagi dalam file konfigurasi aplikasi, baca saat runtime, dan buat kebijakan coba lagi secara terprogram. Melakukannya memudahkan untuk mengelola pengaturan dan untuk memodifikasi dan menyempurnakan nilai untuk merespons perubahan persyaratan dan skenario. Namun, rancang sistem untuk menyimpan nilai daripada dibaca ulang file konfigurasi setiap kali, dan gunakan default yang sesuai jika nilai tidak dapat diperoleh dari konfigurasi.

  • Dalam aplikasi Azure Cloud Services, pertimbangkan untuk menyimpan nilai yang digunakan untuk membangun kebijakan coba lagi pada runtime dalam file konfigurasi layanan sehingga Anda dapat mengubahnya tanpa perlu menghidupkan ulang aplikasi.

  • Manfaatkan strategi coba lagi bawaan atau default yang tersedia di API klien yang Anda gunakan, tetapi hanya jika sesuai untuk skenario Anda. Strategi ini biasanya umum. Dalam beberapa skenario, mereka mungkin semua yang Anda butuhkan, tetapi dalam skenario lain mereka tidak menawarkan berbagai opsi yang sesuai dengan persyaratan spesifik Anda. Untuk menentukan nilai yang paling tepat, Anda perlu melakukan pengujian untuk memahami bagaimana pengaturan memengaruhi aplikasi Anda.

Mencatat dan melacak kesalahan sementara dan nontransient

  • Sebagai bagian dari strategi coba lagi, sertakan penanganan pengecualian dan instrumentasi lain yang mencatat upaya coba lagi. Kegagalan sementara sesekali dan coba lagi diharapkan dan tidak menunjukkan masalah. Namun, jumlah percobaan ulang yang teratur dan meningkat sering menjadi indikator masalah yang dapat menyebabkan kegagalan atau yang menurunkan performa dan ketersediaan aplikasi.

  • Mencatat kesalahan sementara sebagai entri peringatan daripada sebagai entri kesalahan sehingga sistem pemantauan tidak mendeteksinya sebagai kesalahan aplikasi yang mungkin memicu pemberitahuan palsu.

  • Pertimbangkan untuk menyimpan nilai dalam entri log Anda yang menunjukkan apakah percobaan ulang disebabkan oleh pembatasan dalam layanan atau oleh jenis kesalahan lainnya, seperti kegagalan koneksi, sehingga Anda dapat membedakannya selama analisis data. Peningkatan jumlah kesalahan pembatasan sering menjadi indikator cacat desain dalam aplikasi atau kebutuhan untuk beralih ke layanan premium yang menawarkan perangkat keras khusus.

  • Pertimbangkan untuk mengukur dan mencatat waktu yang berlalu secara keseluruhan untuk operasi yang menyertakan mekanisme coba lagi. Metrik ini adalah indikator yang baik dari efek keseluruhan kesalahan sementara pada waktu respons pengguna, latensi proses, dan efisiensi kasus penggunaan aplikasi. Catat juga jumlah percobaan ulang yang terjadi sehingga Anda dapat memahami faktor-faktor yang berkontribusi pada waktu respons.

  • Pertimbangkan untuk menerapkan sistem telemetri dan pemantauan yang dapat menaikkan pemberitahuan ketika jumlah dan tingkat kegagalan, jumlah rata-rata percobaan ulang, atau waktu keseluruhan yang berlalu sebelum operasi berhasil meningkat.

Mengelola operasi yang terus gagal

  • Pertimbangkan bagaimana Anda akan menangani operasi yang terus gagal di setiap upaya. Situasi seperti ini tidak dapat dihindari.

    • Meskipun strategi coba lagi menentukan berapa kali operasi harus dicoba kembali, itu tidak mencegah aplikasi mengulangi operasi lagi dengan jumlah percobaan ulang yang sama. Misalnya, jika layanan pemrosesan pesanan gagal dengan kesalahan fatal yang mengeluarkannya dari tindakan secara permanen, strategi coba lagi mungkin mendeteksi batas waktu koneksi dan menganggapnya sebagai kesalahan sementara. Kode mencoba kembali operasi beberapa kali tertentu dan kemudian menyerah. Namun, ketika pelanggan lain melakukan pemesanan, operasi dicoba lagi, meskipun akan gagal setiap saat.

    • Untuk mencegah percobaan ulang berkelanjutan untuk operasi yang terus gagal, Anda harus mempertimbangkan untuk menerapkan pola Circuit Breaker. Saat Anda menggunakan pola ini, jika jumlah kegagalan dalam jendela waktu yang ditentukan melebihi ambang batas, permintaan segera kembali ke pemanggil sebagai kesalahan, dan tidak ada upaya untuk mengakses sumber daya atau layanan yang gagal.

    • Aplikasi ini dapat secara berkala menguji layanan, secara intermiten dan dengan interval panjang antara permintaan, untuk mendeteksi kapan tersedia. Interval yang sesuai tergantung pada faktor-faktor seperti kekritisan operasi dan sifat layanan. Mungkin ada apa saja antara beberapa menit dan beberapa jam. Ketika pengujian berhasil, aplikasi dapat melanjutkan operasi normal dan meneruskan permintaan ke layanan yang baru dipulihkan.

    • Sementara itu, Anda mungkin dapat kembali ke instans layanan lain (mungkin di pusat data atau aplikasi yang berbeda), gunakan layanan serupa yang menawarkan fungsionalitas yang kompatibel (mungkin lebih sederhana), atau melakukan beberapa operasi alternatif berdasarkan harapan bahwa layanan akan segera tersedia. Misalnya, mungkin sesuai untuk menyimpan permintaan layanan dalam antrean atau penyimpanan data dan mencobanya kembali nanti. Atau Anda mungkin dapat mengalihkan pengguna ke instans alternatif aplikasi, menurunkan performa aplikasi tetapi masih menawarkan fungsionalitas yang dapat diterima, atau hanya mengembalikan pesan kepada pengguna untuk menunjukkan bahwa aplikasi saat ini tidak tersedia.

Pertimbangan lain

  • Saat Anda memutuskan nilai untuk jumlah percobaan ulang dan interval coba lagi untuk kebijakan, pertimbangkan apakah operasi pada layanan atau sumber daya adalah bagian dari operasi yang berjalan lama atau multistep. Mungkin sulit atau mahal untuk mengkompensasi semua langkah operasional lainnya yang telah berhasil ketika satu gagal. Dalam hal ini, interval yang sangat panjang dan sejumlah besar percobaan ulang mungkin dapat diterima selama strategi tersebut tidak memblokir operasi lain dengan menahan atau mengunci sumber daya yang langka.

  • Pertimbangkan apakah mencoba kembali operasi yang sama dapat menyebabkan inkonsistensi dalam data. Jika beberapa bagian dari proses multistep diulang dan operasi tidak idempoten, inkonsistensi mungkin terjadi. Misalnya, jika operasi yang menaikkan nilai diulang, itu menghasilkan hasil yang tidak valid. Mengulangi operasi yang mengirim pesan ke antrean dapat menyebabkan ketidakkonsistensian pada konsumen pesan jika konsumen tidak dapat mendeteksi pesan duplikat. Untuk mencegah skenario ini, rancang setiap langkah sebagai operasi idempotensi. Untuk informasi selengkapnya, lihat Pola idempotensi.

  • Pertimbangkan cakupan operasi yang dicoba kembali. Misalnya, mungkin lebih mudah untuk menerapkan kode coba lagi pada tingkat yang mencakup beberapa operasi dan mencoba kembali semuanya jika satu gagal. Namun, melakukannya dapat mengakibatkan masalah idempotensi atau operasi putar kembali yang tidak perlu.

  • Jika Anda memilih cakupan coba lagi yang mencakup beberapa operasi, mempertimbangkan latensi total semuanya saat Anda menentukan interval coba lagi, saat Anda memantau waktu operasi yang berlalu, dan sebelum Anda menaikkan pemberitahuan untuk kegagalan.

  • Pertimbangkan bagaimana strategi coba lagi Anda dapat memengaruhi tetangga dan penyewa lain dalam aplikasi bersama dan saat Anda menggunakan sumber daya dan layanan bersama. Kebijakan percobaan ulang yang agresif dapat menyebabkan peningkatan jumlah kesalahan sementara terjadi untuk pengguna lain dan untuk aplikasi yang berbagi sumber daya dan layanan. Demikian juga, aplikasi Anda mungkin terpengaruh oleh kebijakan coba lagi yang diterapkan oleh pengguna lain dari sumber daya dan layanan. Untuk aplikasi penting bisnis, Anda mungkin ingin menggunakan layanan premium yang tidak dibagikan. Melakukannya memberi Anda kontrol lebih atas beban dan pembatasan konsekuensi dari sumber daya dan layanan ini, yang dapat membantu membenarkan biaya tambahan.