Bagikan melalui

Penanganan kesalahan sementara

Semua aplikasi yang berkomunikasi dengan layanan dan sumber daya jarak jauh harus sensitif 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.

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.

Hosting 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 simpul 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 kecepatan membantu menjaga kualitas layanan untuk pengguna 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 memperkenalkan latensi koneksi tambahan dan kesalahan koneksi sementara.

  • Kondisi jaringan antara klien dan server mungkin bervariasi, terutama ketika komunikasi melintasi internet. Bahkan di lokasi on-premises, beban lalu lintas yang berat dapat memperlambat komunikasi dan menyebabkan koneksi 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.

Pedoman 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 coba lagi yang digunakan 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 kendali Anda mungkin berkembang seiring waktu, dan Anda mungkin perlu meninjau kembali logika deteksi kesalahan transien 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 untuk tipe 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 percobaan ulang berdasarkan 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 membiarkan koneksi tetap 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 umum menggunakan jenis interval coba lagi berikut:

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

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

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

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

    • Randomisasi. Salah satu dari strategi percobaan ulang yang disebutkan sebelumnya dapat menyertakan pengacakan untuk mencegah beberapa instans klien dari mengirim upaya coba lagi 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. Teknik pengacakan adalah teknik yang berguna dan bisa dikombinasikan dengan strategi lain.

  • Sebagai pedoman umum, gunakan strategi back-off eksponensial untuk operasi latar belakang, dan gunakan strategi pengulangan segera atau dengan interval teratur untuk operasi interaktif. Dalam kedua kasus, Anda harus memilih penundaan dan jumlah coba lagi sehingga latensi maksimum pada semua percobaan coba lagi sesuai dengan persyaratan latensi end-to-end yang diperlukan.

  • Perhatikan kombinasi semua faktor yang berkontribusi pada batas waktu maksimum keseluruhan untuk operasi yang diulang 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 proses harus memenuhi perjanjian tingkat layanan (SLA) tertentu, waktu operasi 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.

  • Pertimbangkan batas waktu operasi saat Anda memilih interval coba lagi untuk menghindari melakukan upaya berikutnya langsung setelahnya (misalnya, jika periode batas waktu mirip dengan interval coba lagi). Selain itu, pertimbangkan apakah Anda perlu mempertahankan total periode yang mungkin (waktu jeda ditambah interval coba ulang) di bawah jangka 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 Retry-After dalam respons) mungkin menunjukkan berapa lama kesalahan mungkin berlangsung, atau bahwa layanan gagal dan tidak akan merespons upaya berikutnya.

Hindari pola yang tidak efektif

  • Dalam kebanyakan kasus, hindari implementasi yang mencakup lapisan kode ulang yang duplikat. 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 jumlah percobaan ulang dan periode penundaan yang berlebihan, dan pastikan Anda memahami konsekuensinya. Misalnya, satu komponen membuat permintaan ke komponen lain, yang kemudian mengakses layanan target. Jika Anda menerapkan upaya mengulang dengan hitungan tiga pada kedua panggilan, ada sembilan upaya mengulang 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 langsung mengulangi 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 mundur eksponensial dengan kemampuan pemisah sirkuit.

  • Cegah beberapa contoh klien yang sama, atau beberapa contoh klien berbeda, dari mengirim ulang secara bersamaan. Jika skenario ini kemungkinan akan terjadi, masukkan jeda acak ke dalam coba lagi.

Menguji strategi coba lagi dan implementasi Anda

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

    • Menyuntikkan kesalahan sementara dan tidak sementara ke dalam layanan. Misalnya, kirim permintaan yang tidak valid atau tambahkan kode yang mendeteksi permintaan pengujian dan merespons dengan berbagai jenis kesalahan. Untuk contoh yang menggunakan TestApi, lihat Pengujian Injeksi Kesalahan dengan TestApi dan Pengenalan 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 pengujian faktor beban tinggi dan bersamaan untuk memastikan bahwa mekanisme dan strategi pencoba ulang berfungsi dengan tepat di bawah 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 pengulangan

  • 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 pengunduran reguler, eksponensial, dan pengacakan), nilai interval aktual, dan berapa kali percobaan ulang.

  • Terapkan percobaan ulang di banyak tempat, bahkan dalam aplikasi paling sederhana, dan di setiap lapisan aplikasi yang lebih kompleks. Daripada mengkode secara statis elemen dari setiap kebijakan di beberapa lokasi, pertimbangkanlah untuk menggunakan 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 kesalahan tidak sementara

  • Sebagai bagian dari strategi coba lagi, sertakan penanganan pengecualian dan instrumentasi lain yang mencatat upaya coba lagi. Kegagalan sementara yang sesekali terjadi dan upaya pengulangan diharapkan dan tidak menunjukkan adanya 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 kinerja sering kali menjadi indikator adanya kekurangan 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 dapat secara berkala menguji layanan, secara terputus-putus dan dengan interval panjang antar permintaan, untuk mendeteksi kapan layanan tersedia. Interval yang sesuai tergantung pada faktor-faktor seperti kekritisan operasi dan sifat layanan. Mungkin memerlukan waktu 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 percobaan ulang untuk kebijakan, pertimbangkan apakah operasi pada layanan atau sumber daya merupakan bagian dari operasi yang berjalan lama atau operasi multi-langkah. 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 langkah dari proses bertahap diulang dan operasinya 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 lebih lanjut, lihat pola idempoten .

  • 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, Anda harus mempertimbangkan latensi total dari semuanya saat Anda menentukan interval coba lagi, saat Anda memantau waktu yang berlalu dari operasi, dan sebelum Anda memicu 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 coba lagi yang agresif dapat menyebabkan meningkatnya jumlah kesalahan sementara untuk pengguna lain ini 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 sumber daya serta layanan ini, yang pada gilirannya dapat membantu membenarkan biaya tambahan.