Penanganan kesalahan sementara
Semua aplikasi yang berkomunikasi dengan layanan jarak jauh dan sumber daya harus peka terhadap kesalahan sementara. Hal ini terutama berlaku untuk aplikasi yang berjalan di cloud, saat sifat lingkungan dan konektivitas melalui Internet dapat berarti jenis kesalahan ini cenderung lebih sering ditemui. Kesalahan sementara termasuk hilangnya konektivitas jaringan untuk sesaat ke komponen dan layanan, ketidaktersediaan layanan untuk sementara, atau batas waktu yang muncul saat layanan sibuk. Kesalahan-kesalahan ini seringkali dapat terselesaikan dengan sendirinya, dan jika tindakan diulang setelah penundaan yang sesuai, kemungkinan akan berhasil.
Dokumen ini mencakup panduan umum untuk penanganan kesalahan sementara. Untuk informasi tentang penanganan kesalahan sementara saat menggunakan layanan Microsoft Azure, lihat Pedoman percobaan ulang khusus 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. Dalam solusi yang berjalan pada infrastruktur lokal, performa dan ketersediaan aplikasi dan komponennya biasanya dipertahankan melalui redundansi perangkat keras yang mahal dan sering kurang dimanfaatkan, dan komponen dan sumber daya terletak dekat satu sama lain. Meskipun pendekatan ini membuat kegagalan memiliki kemungkinan yang lebih kecil, pendekatan ini masih dapat mengakibatkan kesalahan sementara - dan bahkan pemadaman melalui peristiwa tak terduga seperti catu daya eksternal atau masalah jaringan, atau situasi 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, sifat lingkungan ini dapat berarti bahwa kesalahan sementara lebih mungkin terjadi. Ada beberapa alasan untuk ini:
Banyak sumber daya dibagikan di lingkungan cloud, dan akses ke sumber daya ini dapat mengalami pembatasan untuk melindungi sumber daya. Beberapa layanan akan menolak koneksi saat beban naik ke tingkat tertentu, atau tingkat throughput maksimum tercapai, untuk memungkinkan pemrosesan permintaan yang ada dan untuk mempertahankan performa layanan untuk semua pengguna. Pembatasan membantu menjaga kualitas layanan untuk orang lain dan penyewa lain menggunakan sumber daya bersama.
Lingkungan cloud dibangun menggunakan sejumlah besar unit perangkat keras komoditas. Hal ini berarti memberikan performa dengan mendistribusikan beban secara dinamis di beberapa unit komputasi dan komponen infrastruktur, dan memberikan keandalan dengan mendaur ulang atau mengganti unit yang gagal secara otomatis. Sifat dinamis ini berarti bahwa kesalahan sementara dan kegagalan koneksi sementara kadang-kadang dapat terjadi.
Seringkali ada lebih banyak komponen perangkat keras, termasuk infrastruktur jaringan seperti router dan penyeimbang beban, 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 saat komunikasi melewati jaringan Internet. Bahkan di lokasi lokal, beban lalu lintas yang padat dapat memperlambat komunikasi dan menyebabkan kegagalan koneksi yang terputus-putus.
Tantangan
Kesalahan sementara dapat memiliki efek besar pada ketersediaan aplikasi yang diterima, bahkan setelah diuji secara menyeluruh dalam semua keadaan yang dapat diperkirakan. Untuk memastikan bahwa aplikasi yang dihosting cloud beroperasi dengan andal, mereka harus dapat menanggapi tantangan berikut:
Aplikasi harus dapat mendeteksi kesalahan saat terjadi, dan menentukan apakah kesalahan ini cenderung bersifat sementara, lebih tahan lama, atau kegagalan terminal. Sumber daya yang berbeda cenderung mengembalikan respons yang berbeda saat kesalahan terjadi, dan tanggapan ini juga dapat bervariasi bergantung pada konteks operasi; misalnya, respons untuk kesalahan saat membaca dari penyimpanan mungkin berbeda dari respons untuk kesalahan saat menulis ke penyimpanan. Banyak sumber daya dan layanan memiliki kontrak kegagalan sementara yang terdokumentasi dengan baik. Namun, jika informasi tersebut tidak tersedia, mungkin sulit untuk menemukan sifat kesalahan dan apakah kesalahan tersebut bersifat sementara.
Aplikasi harus dapat mencoba kembali operasi jika menentukan bahwa kesalahan cenderung bersifat sementara dan melacak berapa kali melakukan percobaan ulang.
Aplikasi harus menggunakan strategi yang tepat untuk percobaan ulang. Strategi ini menentukan berapa kali harus melakukan percobaan ulang, penundaan antara setiap upaya, dan tindakan yang harus diambil setelah upaya gagal. Jumlah upaya yang sesuai dan penundaan antara masing-masing seringkali sulit untuk ditentukan, dan bervariasi berdasarkan jenis sumber daya serta kondisi operasi sumber daya saat ini dan aplikasi itu sendiri.
Panduan umum
Panduan berikut akan membantu Anda merancang mekanisme penanganan kesalahan sementara yang sesuai untuk aplikasi Anda:
Tentukan apakah ada mekanisme percobaan ulang 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. Jika tidak, antarmuka REST untuk layanan dapat mengembalikan informasi yang berguna dalam menentukan apakah percobaan ulang telah sesuai, dan berapa lama waktu tunggu sebelum upaya coba ulang berikutnya.
Gunakan mekanisme percobaan ulang bawaan jika tersedia, kecuali jika Anda memiliki persyaratan yang spesifik dan dapat dipahami dengan baik, yang membuat perilaku percobaan ulang yang berbeda lebih tepat.
Tentukan apakah operasi cocok untuk melakukan percobaan ulang:
Anda hanya harus mencoba kembali operasi saat kesalahan bersifat sementara (biasanya ditunjukkan oleh sifat kesalahan), dan jika setidaknya ada kemungkinan bahwa operasi akan berhasil ketika dicoba kembali. Tidak ada gunanya melakukan percobaan ulang pada operasi yang menunjukkan operasi yang tidak valid seperti pembaruan database ke item yang tidak ada, atau permintaan ke layanan atau sumber daya yang telah mengalami kesalahan fatal.
Secara umum, Anda harus menerapkan percobaan ulang hanya saat dampak penuh dari proses ini dapat ditentukan, dan kondisinya dipahami dengan baik dan dapat divalidasi. Jika tidak, serahkan pada kode panggilan untuk menerapkan percobaan ulang. Ingatlah bahwa kesalahan yang dikembalikan dari sumber daya dan layanan di luar kendali Anda dapat berkembang seiring waktu, dan Anda mungkin perlu meninjau kembali logika deteksi kesalahan sementara.
Saat Anda membuat layanan atau komponen, pertimbangkan untuk menerapkan kode kesalahan dan pesan yang akan 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 sarankan penundaan yang sesuai sebelum upaya coba ulang berikutnya. Jika Anda membangun layanan web, pertimbangkan untuk mengembalikan kesalahan kustom yang ditentukan dalam kontrak layanan Anda. Meskipun klien umum mungkin tidak dapat membacanya, ini akan berguna saat membangun klien kustom.
Menentukan jumlah dan interval percobaan ulang yang sesuai:
Sangat penting untuk mengoptimalkan jumlah percobaan ulang dan interval ke jenis kasus penggunaan. Jika Anda tidak mencoba kembali beberapa kali, aplikasi tidak akan dapat menyelesaikan operasi dan kemungkinan akan mengalami kegagalan. Jika Anda melakukan percobaan ulang dengan jumlah yang terlalu banyak, atau dengan interval yang terlalu singkat antar percobaan, aplikasi berpotensi menyimpan sumber daya seperti utas, koneksi, dan memori untuk waktu yang lama, yang akan berdampak buruk pada kesehatan aplikasi.
Nilai yang sesuai untuk interval waktu dan jumlah upaya percobaan ulang bergantung pada jenis operasi yang dicoba. Misalnya, jika operasi adalah bagian dari interaksi pengguna, interval harus singkat dan hanya mengupayakan beberapa percobaan ulang untuk menghindari pengguna menunggu respons (yang menahan koneksi terbuka dan dapat mengurangi ketersediaan untuk pengguna lain). Jika operasi adalah bagian dari alur kerja yang berjalan lama atau kritis, di mana operasi pembatalan dan percobaan ulang proses akan memerlukan biaya tinggi atau memakan waktu, lebih tepat jika Anda menunggu lebih lama antar upaya dan melakukan percobaa ulang dengan jumlah yang lebih banyak.
Menentukan interval yang tepat antara percobaan ulang adalah bagian tersulit 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, aplikasi mungkin mencoba kembali operasi setelah 3 detik, 12 detik, 30 detik, dan seterusnya.
Interval bertambah bertahap. Aplikasi menunggu beberapa saat sebelum percobaan ulang pertama, dan kemudian secara bertahap meningkatkan waktu antara setiap percobaan ulang berikutnya. Misalnya, aplikasi dapat mencoba ulang operasi setelah 3 detik, 7 detik, 13 detik, dan seterusnya.
Interval reguler. Aplikasi menunggu periode waktu yang sama antara setiap upaya. Misalnya, mungkin mencoba lagi operasi setiap 3 detik.
Coba lagi segera. Terkadang kesalahan sementara berlangsung singkat, mungkin karena kejadian seperti tabrakan paket jaringan atau lonjakan komponen perangkat keras. Dalam hal ini, mencoba kembali operasi segera adalah tepat karena mungkin berhasil jika kesalahan telah dibersihkan dalam waktu yang dibutuhkan aplikasi untuk merakit dan mengirim permintaan berikutnya. Namun, tidak boleh ada lebih dari satu upaya percobaan ulang langsung, dan Anda harus beralih ke strategi alternatif, seperti tindakan back-off atau fallback eksponensial, jika percobaan ulang langsung gagal.
Pengacakan. Salah satu strategi percobaan ulang yang tercantum di atas mungkin termasuk pengacakan untuk mencegah beberapa contoh klien mengirim upaya percobaan ulang berikutnya pada saat yang sama. Misalnya, satu instans dapat mencoba kembali operasi setelah 3 detik, 11 detik, 28 detik, dan seterusnya, sementara instans lain dapat mencoba kembali operasi setelah 4 detik, 12 detik, 26 detik, dan seterusnya. Pengacakan adalah teknik yang berguna dan dapat dikombinasikan dengan strategi lain.
Sebagai pedoman umum, gunakan strategi back-off eksponensial untuk operasi latar belakang, dan strategi percobaan ulang 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.
Pertimbangkan kombinasi semua faktor yang berkontribusi pada batas waktu maksimum secara keseluruhan untuk operasi yang dicoba ulang. Faktor-faktor ini termasuk waktu yang dibutuhkan untuk koneksi yang gagal untuk menghasilkan respons (biasanya ditetapkan oleh nilai batas waktu pada klien) serta penundaan antara upaya percobaan ulang dan jumlah percobaan ulang maksimum. Total semua waktu ini dapat menghasilkan waktu operasi keseluruhan yang panjang, terutama saat menggunakan strategi penundaan eksponensial saat interval antar 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.
Strategi percobaan ulang yang terlalu agresif, yang memiliki interval yang terlalu pendek atau percobaan ulang yang terlalu sering, dapat memiliki efek buruk pada sumber daya atau layanan target. Ini dapat mencegah sumber daya atau layanan pulih dari keadaan kelebihan beban, dan akan terus memblokir atau menolak permintaan. Hal ini akan mengakibatkan lingkaran setan saat semakin banyak permintaan dikirim ke sumber daya atau layanan, dan akibatnya kemampuannya untuk pulih semakin berkurang.
Pertimbangkan batas waktu operasi saat memilih interval percobaan ulang untuk menghindari meluncurkan upaya berikutnya dengan segera (misalnya, jika periode batas waktu mirip dengan interval percobaan ulang). Pertimbangkan juga jika Anda perlu menjaga total periode yang mungkin dilakukan (batas waktu ditambah interval percobaan ulang) hingga di bawah total waktu tertentu. Operasi yang memiliki batas waktu yang luar biasa singkat atau sangat lama dapat memengaruhi lama waktu tunggu dan seberapa sering operasi percobaan ulang dilakukan.
Gunakan jenis pengecualian dan data apa pun yang dikandungnya, atau kode kesalahan dan pesan yang dikembalikan dari layanan, untuk mengoptimalkan interval dan jumlah percobaan ulang. Misalnya, beberapa pengecualian atau kode kesalahan (seperti kode HTTP 503 Layanan Tidak tersedia dengan header Coba Ulang Setelah dalam respons) dapat menunjukkan berapa lama kesalahan mungkin berlangsung, atau bahwa layanan telah gagal dan tidak akan menanggapi upaya selanjutnya.
Hindari anti-pola:
Dalam sebagian besar kasus, Anda harus menghindari penerapan yang mencakup lapisan duplikat kode percobaan ulang. Hindari desain yang mencakup mekanisme percobaan ulang kaskade, atau yang menerapkan coba ulang pada setiap tahap operasi yang melibatkan hierarki permintaan, kecuali Jika Anda memiliki persyaratan khusus yang memerlukan hal ini. Dalam keadaan luar biasa ini, gunakan kebijakan yang mencegah terlalu banyak percobaan ulang dan periode penundaan serta pastikan Anda memahami konsekuensinya. Misalnya, jika satu komponen membuat permintaan ke yang lain, yang kemudian mengakses layanan target, dan Anda menerapkan percobaan ulang dengan hitungan tiga pada kedua panggilan, akan ada total sembilan upaya percobaan ulang terhadap layanan. Banyak layanan dan sumber daya menerapkan mekanisme percobaan ulang bawaan dan Anda harus menyelidiki bagaimana Anda dapat menonaktifkan atau memodifikasinya jika Anda perlu menerapkan percobaan ulang pada tingkat yang lebih tinggi.
Jangan pernah menerapkan mekanisme percobaan ulang yang tak ada habisnya. Hal ini dapat mencegah sumber daya atau layanan pulih dari situasi yang berlebihan, dan menyebabkan pembatasan dan menolak koneksi untuk melanjutkan untuk jangka waktu yang lebih lama. Gunakan jumlah atau percobaan ulang terbatas, atau terapkan pola seperti Circuit Breaker guna memungkinkan layanan pulih.
Jangan pernah melakukan percobaan ulang langsung lebih dari sekali.
Hindari menggunakan interval percobaan ulang secara teratur, terutama saat Anda memiliki sejumlah besar upaya coba ulang saat mengakses layanan dan sumber daya di Azure. Pendekatan optimal dalam skenario ini adalah strategi back-off eksponensial dengan kemampuan pemutusan sirkuit.
Cegah beberapa instans dari klien yang sama, atau beberapa contoh klien yang berbeda, dari mengirim percobaan ulang pada saat yang sama. Jika hal ini mungkin terjadi, gunakan pengacakan pada interval percobaan ulang.
Menguji strategi dan penerapan percobaan ulang Anda:
Pastikan Anda sepenuhnya menguji penerapan strategi percobaan ulang di bawah serangkaian keadaan seluas mungkin, terutama saat 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. Misalnya, menggunakan TestApi, lihat Pengujian Injeksi Kesalahan dengan TestApi dan Pengantar TestApi – Bagian 5: API Injeksi Kesalahan Kode Aman.
Buat tiruan sumber daya atau layanan yang mengembalikan berbagai kesalahan yang dapat dikembalikan oleh layanan nyata. Pastikan Anda mencakup semua jenis kesalahan yang dirancang untuk dideteksi oleh strategi percobaan ulang Anda.
Paksa kesalahan sementara terjadi dengan menonaktifkan sementara atau membebani layanan jika layanan adalah layanan khusus yang Anda buat dan terapkan (tentu saja, Anda tidak boleh mencoba membebani sumber daya bersama atau layanan bersama dalam Azure).
Untuk API berbasis HTTP, pertimbangkan untuk menggunakan pustaka FiddlerCore dalam pengujian otomatis Anda guna mengubah hasil permintaan HTTP, baik dengan menambahkan waktu pulang pergi tambahan atau dengan mengubah respons (seperti kode status HTTP, header, badan, atau faktor lainnya). Hal ini memungkinkan pengujian deterministik subset dari kondisi kegagalan, baik kesalahan sementara atau jenis kegagalan lainnya. Untuk informasi selengkapnya, lihat FiddlerCore. Untuk contoh cara menggunakan pustaka, terutama kelas HttpMangler, periksa kode sumber untuk SDK Azure Storage.
Lakukan faktor pemuatan tinggi dan pengujian bersamaan untuk memastikan bahwa mekanisme dan strategi percobaan ulang berfungsi dengan benar dalam kondisi ini, dan tidak memiliki efek buruk pada pengoperasian klien atau menyebabkan kontaminasi silang antara permintaan.
Mengelola konfigurasi kebijakan coba ulang:
Kebijakan percobaan ulang adalah kombinasi dari semua elemen strategi percobaan ulang Anda. Kebijakan ini mendefinisikan mekanisme deteksi yang menentukan jika suatu kesalahan cenderung bersifat sementara, jenis interval yang akan digunakan (seperti back-off reguler, eksponensial, dan pengacakan), nilai interval aktual, dan jumlah percobaan ulang.
Percobaan ulang harus diterapkan di banyak tempat, bahkan dalam aplikasi yang paling sederhana, dan di setiap lapisan aplikasi yang lebih kompleks. Alih-alih melakukan hard-coding elemen dari setiap kebijakan di beberapa lokasi, pertimbangkan untuk menggunakan titik pusat untuk menyimpan semua kebijakan. Misalnya, simpan nilai-nilai seperti interval dan coba kembali jumlah dalam file konfigurasi aplikasi, baca saat runtime, dan buat kebijakan percobaan ulang secara terprogram. Hal ini membuatnya lebih mudah untuk mengelola pengaturan, dan untuk memodifikasi dan menyempurnakan nilai-nilai untuk menanggapi perubahan persyaratan dan skenario. Namun, desain sistem untuk menyimpan nilai alih-alih membaca ulang file konfigurasi setiap saat, dan pastikan default yang sesuai digunakan jika nilai tidak dapat diperoleh dari konfigurasi.
Dalam aplikasi Azure Cloud Services, pertimbangkan untuk menyimpan nilai yang digunakan untuk membangun kebijakan coba ulang saat runtime dalam file konfigurasi layanan sehingga dapat diubah tanpa perlu menghidupkan ulang aplikasi.
Manfaatkan strategi percobaan ulang bawaan atau default yang tersedia di API klien yang Anda gunakan, tetapi hanya jika sesuai untuk skenario Anda. Strategi ini biasanya merupakan tujuan umum. Dalam beberapa situasi, strategi ini dapat mencakup semua yang diperlukan, tetapi dalam situasi lain, strategi ini mungkin tidak menawarkan berbagai pilihan yang sesuai dengan kebutuhan spesifik Anda. Anda harus memahami cara pengaturan akan memengaruhi aplikasi melalui pengujian untuk menentukan nilai yang paling tepat.
Melakukan log dan pelacakan kesalahan sementara dan nontransien:
Sebagai bagian dari strategi percobaan ulang, sertakan penanganan pengecualian dan instrumentasi lain yang mencatat saat upaya percobaan ulang dilakukan. Meskipun beberapa kegagalan sementara dan cobaan ulang diharapkan untuk terjadi dan tidak menunjukkan masalah, jumlah percobaan ulang yang teratur dan meningkat sering menjadi indikator masalah yang dapat menyebabkan kegagalan, atau saat ini menurunkan performa dan ketersediaan aplikasi.
Catat kesalahan sementara sebagai entri Peringatan dan bukan entri Kesalahan sehingga sistem pemantauan tidak mendeteksinya sebagai kesalahan aplikasi yang dapat memicu peringatan palsu.
Pertimbangkan untuk menyimpan nilai dalam entri log Anda yang menunjukkan jika percobaan ulang disebabkan oleh pembatasan dalam layanan, atau oleh jenis kesalahan lain 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 keseluruhan waktu yang dibutuhkan untuk operasi yang mencakup mekanisme percobaan ulang. 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 untuk memahami faktor yang berkontribusi pada waktu respons.
Pertimbangkan untuk menerapkan sistem telemetri dan pemantauan yang dapat meningkatkan peringatan saat terjadi peningkatan jumlah dan tingkat kegagalan, jumlah rata-rata percobaan ulang, atau waktu keseluruhan yang dibutuhkan agar operasi berhasil.
Mengelola operasi yang terus gagal:
Akan ada keadaan saat operasi terus gagal dalam setiap upaya, dan penting untuk mempertimbangkan cara Anda menangani situasi ini:
Meskipun strategi percobaan ulang akan menentukan berapa kali operasi harus dicoba ulang, strategi ini tidak mencegah aplikasi mengulangi operasi lagi, dengan jumlah percobaan ulang yang sama. Misalnya, jika layanan pemrosesan pemesanan gagal dengan kesalahan fatal yang membuatnya tidak berfungsi secara permanen, strategi coba ulang dapat mendeteksi batas waktu koneksi dan menganggapnya sebagai kesalahan sementara. Kode akan mencoba kembali operasi beberapa kali dan kemudian menyerah. Namun, saat pelanggan lain melakukan pemesanan, operasi akan dicoba lagi - meskipun pasti akan gagal setiap saat.
Guna mencegah percobaan ulang terus-menerus untuk operasi yang terus gagal, pertimbangkan untuk menerapkan pola Circuit Breaker. Dalam pola ini, jika jumlah kegagalan dalam kurun waktu tertentu melebihi ambang batas, permintaan dikembalikan ke pemanggil dengan segera sebagai kesalahan, tanpa mencoba 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 tepat akan bergantung pada skenario, seperti kekritisan operasi dan sifat layanan, dan mungkin memiliki durasi antara beberapa menit dan beberapa jam. Pada titik saat pengujian berhasil, aplikasi dapat melanjutkan operasi normal dan meneruskan permintaan ke layanan yang baru dipulihkan.
Sementara itu, mungkin Anda dapat kembali ke instans lain dari layanan (mungkin di pusat data atau aplikasi yang berbeda), menggunakan layanan serupa yang menawarkan fungsionalitas yang kompatibel (mungkin lebih sederhana), atau melakukan beberapa operasi alternatif dengan harapan bahwa layanan akan segera tersedia. Misalnya, mungkin tepat untuk menyimpan permintaan untuk layanan dalam antrean atau penyimpanan data dan memutar ulang nanti. Jika tidak, Anda mungkin dapat mengarahkan pengguna ke instans alternatif aplikasi, menurunkan performa aplikasi tetapi masih menawarkan fungsionalitas yang dapat diterima, atau hanya mengembalikan pesan kepada pengguna yang menunjukkan bahwa aplikasi tidak tersedia saat ini.
Pertimbangan lain
Saat memutuskan nilai untuk jumlah percobaan ulang dan interval percobaan ulang untuk suatu kebijakan, pertimbangkan jika operasi pada layanan atau sumber daya adalah bagian dari operasi jangka panjang atau multistep. Mungkin sulit atau mahal untuk memberikan kompensasi semua langkah operasional lainnya yang telah berhasil saat satu telah gagal. Dalam situasi ini, interval yang sangat panjang dan sejumlah besar percobaan ulang dapat diterima selama tidak memblokir operasi lain dengan memegang atau mengunci sumber daya yang langka.
Pertimbangkan jika mencoba ulang operasi yang sama dapat menyebabkan inkonsistensi dalam data. Jika beberapa bagian dari proses multistep diulang, dan operasi tidak idempotent, proses dapat mengakibatkan inkonsistensi. Misalnya, operasi yang meningkatkan nilai, jika diulang, akan menghasilkan hasil yang tidak valid. Mengulangi operasi yang mengirim pesan ke antrean dapat menyebabkan inkonsistensi dalam pesan konsumen jika tidak dapat mendeteksi pesan duplikat. Untuk mencegah hal ini, pastikan Anda merancang setiap langkah sebagai operasi idempotent. Untuk informasi selengkapnya tentang idempotent, lihat Pola Idempotent.
Pertimbangkan cakupan operasi yang akan dicoba ulang. Misalnya, mungkin lebih mudah untuk menerapkan kode percobaan ulang pada tingkat yang mencakup beberapa operasi, dan lakukan ulang semuanya jika salah satu gagal. Namun, melakukan hal ini dapat mengakibatkan masalah idempotent atau operasi putar kembali yang tidak perlu.
Jika Anda memilih cakupan percobaan ulang yang mencakup beberapa operasi, pertimbangkan latensi total semuanya saat menentukan interval coba ulang, saat memantau waktu yang dibutuhkan, dan sebelum memberikan peringatan untuk kegagalan.
Pertimbangkan cara strategi percobaan ulang dapat memengaruhi orang lain dan penyewa lain dalam aplikasi bersama, atau saat 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 percobaan ulang yang diterapkan oleh pengguna lain dari sumber daya dan layanan. Untuk aplikasi yang penting untuk misi, Anda dapat memutuskan untuk menggunakan layanan premium yang tidak dibagikan dengan orang lain. Ini memberi Anda lebih banyak kontrol atas beban dan pengurangan pembatasan sumber daya dan layanan, yang dapat membantu menjelaskan adanya biaya tambahan.