Praktik terbaik untuk penanganan kesalahan sementara

Semua aplikasi yang berkomunikasi dengan layanan dan sumber daya jarak jauh harus mendeteksi dan memulihkan dari kesalahan sementara. Persyaratan ini terutama berlaku untuk aplikasi yang berjalan di cloud. Karena sifat lingkungan cloud dan konektivitas melalui internet, aplikasi Anda cenderung mengalami kesalahan sementara lebih sering. Gangguan sementara mencakup hilangnya konektivitas jaringan ke komponen dan layanan untuk sesaat, ketidaktersediaan layanan untuk sementara, dan batas waktu habis yang terjadi ketika suatu layanan sedang sibuk. Kesalahan ini biasanya menyelesaikan sendiri tanpa intervensi, sehingga tindakan kemungkinan akan berhasil jika aplikasi mencobanya kembali setelah penundaan yang sesuai.

Penanganan kesalahan sementara adalah teknik ketahanan utama dalam pilar Keandalan Azure Well-Architected Framework. Jika Anda mendeteksi dan memulihkan dari kesalahan sementara di tingkat aplikasi, Anda membantu mencegah kegagalan bertingkat yang mungkin memicu respons insiden yang lebih luas atau prosedur pemulihan bencana (DR). Penanganan kesalahan sementara yang efektif membantu beban kerja Anda mentolerir gangguan rutin dan mempertahankan ketersediaan tanpa eskalasi ke prosedur pemulihan tingkat infrastruktur.

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, perangkat keras redundan biasanya mempertahankan performa dan ketersediaan aplikasi dan komponennya. Komponen dan sumber daya juga terletak dekat satu sama lain. Pendekatan ini membuat kegagalan kurang mungkin terjadi, tetapi kesalahan sementara masih dapat terjadi. Peristiwa tak terduga seperti catu daya eksternal atau masalah jaringan, atau skenario bencana lainnya, dapat menyebabkan pemadaman. Perangkat keras redundan juga bisa mahal dan sering kurang digunakan.

Lingkungan cloud dapat memberikan ketersediaan keseluruhan yang lebih tinggi karena mendistribusikan beban kerja di banyak server dan menggunakan redundansi, failover otomatis, dan alokasi sumber daya dinamis. Tetapi sifat lingkungan cloud membuat kesalahan sementara lebih mungkin karena beberapa alasan:

• 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 mencapai tingkat tertentu atau tingkat throughput maksimum. Pendekatan ini memungkinkan layanan memproses permintaan yang ada dan mempertahankan performa 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.

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

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

Tantangan

Kesalahan sementara dapat secara signifikan memengaruhi ketersediaan aplikasi yang dirasakan, bahkan jika Anda mengujinya secara menyeluruh dalam kondisi yang diharapkan. Untuk memastikan bahwa aplikasi yang dihosting cloud beroperasi dengan andal, mereka harus mengatasi tantangan berikut:

• Aplikasi harus dapat mendeteksi kesalahan ketika terjadi dan menentukan apakah kesalahan bersifat sementara, tahan lama, atau kegagalan terminal. Sumber daya yang berbeda biasanya mengembalikan respons yang berbeda ketika kesalahan terjadi. 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. Ketika informasi ini tidak tersedia, menjadi lebih sulit untuk menentukan 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 mengulangi operasi tersebut.

• Aplikasi harus menggunakan strategi coba lagi yang sesuai dengan persyaratannya. Strategi menentukan berapa kali aplikasi harus mencoba kembali, penundaan antara upaya, dan tindakan yang harus diambil setelah upaya yang gagal. Jumlah upaya dan penundaan antara masing-masing sering sulit ditentukan. Strategi ini 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.

Periksa 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 percobaan ulang diperlukan dan berapa lama menunggu sebelum upaya berikutnya.

Gunakan mekanisme coba lagi bawaan saat opsi bawaan tersedia, kecuali Anda memiliki persyaratan spesifik dan dipahami dengan baik yang membuat perilaku coba lagi yang berbeda lebih cocok untuk skenario Anda.

Layanan Azure masing-masing menangani kesalahan sementara secara berbeda. Beberapa layanan menyediakan kebijakan coba lagi tingkat SDK yang menyertakan algoritma back-off yang dapat dikonfigurasi. Layanan lainnya menyediakan fitur platform seperti pemeriksaan kesehatan dan batas waktu keterlihatan yang melengkapi logika pengulangan tingkat aplikasi. Periksa panduan keandalan untuk setiap layanan Azure yang Anda gunakan. Panduan ini mencakup bagian khusus yang menyediakan rekomendasi khusus layanan untuk konfigurasi coba lagi, penyetelan batas waktu, dan pemantauan kesehatan.

Periksa apakah pengulangan sesuai dengan operasi

Ulangi tugas hanya ketika kesalahan bersifat sementara, yang biasanya diperlihatkan oleh sifat kesalahan, dan ketika operasi mungkin berhasil jika diulang. Untuk layanan berbasis HTTP, kode status 429 (Terlalu Banyak Permintaan) dan kesalahan server 5xx adalah kandidat coba lagi yang khas. Sebagian besar kesalahan klien 4xx, seperti 400, 401, 403, dan 404, menunjukkan masalah yang tidak diselesaikan oleh percobaan ulang. Jangan coba lagi operasi yang tidak berhasil, seperti memperbarui item database yang tidak ada atau memanggil layanan yang mengembalikan kesalahan fatal.

Secara umum, terapkan percobaan ulang hanya ketika Anda dapat menentukan efek penuhnya dan kapan Anda memahami dan dapat memvalidasi kondisi. Jika tidak, biarkan kode panggilan menerapkan percobaan ulang. Kesalahan yang dikembalikan dari sumber daya dan layanan di luar kontrol Anda mungkin berevolusi dari waktu ke waktu, dan Anda mungkin perlu meninjau kembali logika deteksi kesalahan sementara Anda.

Saat Anda membuat layanan atau komponen, terapkan kode kesalahan dan pesan yang membantu klien menentukan apakah mereka harus mencoba kembali operasi yang gagal. Misalnya, kembalikan nilai isTransient untuk menunjukkan apakah klien harus mengulang operasi, dan menyarankan penundaan yang sesuai sebelum upaya ulang berikutnya. Jika Anda membangun layanan web, kembalikan kesalahan kustom yang ditentukan oleh kontrak layanan Anda. Klien generik mungkin tidak dapat membaca kesalahan ini, tetapi berguna saat Anda membuat klien kustom.

Menentukan jumlah dan interval coba lagi yang sesuai

Optimalkan jumlah coba lagi dan interval untuk jenis kasus penggunaan. Jika Anda tidak mencoba kembali cukup waktu, aplikasi tidak dapat menyelesaikan operasi dan gagal. Jika Anda mencoba kembali terlalu banyak atau tidak menunggu cukup lama di antara percobaan, aplikasi mungkin menyimpan sumber daya seperti utas, koneksi, dan memori untuk jangka waktu yang lama, yang berdampak buruk pada kesehatan aplikasi. Untuk informasi selengkapnya, lihat Pola coba lagi.

Sesuaikan nilai untuk interval waktu dan jumlah percobaan ulang berdasarkan jenis operasi. Misalnya, jika operasi adalah bagian dari interaksi pengguna, intervalnya harus singkat, dan Anda hanya boleh mencoba beberapa percobaan ulang. Gunakan pendekatan ini agar pengguna tidak perlu menunggu respons, yang mempertahankan 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 bisa mahal atau memakan waktu, Anda dapat memperpanjang waktu tunggu antara upaya dan mencoba lagi lebih sering.

Menentukan interval yang benar antara percobaan ulang adalah bagian yang paling sulit dalam merancang strategi yang sukses. Strategi umum menggunakan jenis interval coba lagi berikut:

• Back-off eksponensial: Aplikasi menunggu beberapa saat sebelum percobaan ulang pertama dan kemudian secara eksponensial memperpanjang waktu setiap percobaan ulang berikutnya. Misalnya, operasi mungkin menjalankan ulang setelah dua detik, empat detik, delapan detik, dan hingga jumlah percobaan yang ditentukan atau durasi total tertentu. Tambahkan jitter, yaitu penundaan acak kecil, pada setiap interval upaya ulang untuk mencegah sejumlah klien menyinkronkan upaya ulang mereka dan menyebabkan lonjakan beban pada layanan target.

• Interval inkremental: Aplikasi menunggu beberapa saat sebelum percobaan ulang pertama, lalu secara bertahap meningkatkan waktu antara setiap percobaan ulang berikutnya. Misalnya, operasi mungkin mencoba lagi setelah 3 detik, 7 detik, dan 11 detik.

• Interval reguler: Aplikasi menunggu periode waktu yang sama antara setiap upaya. Misalnya, operasi mungkin mengulangi setiap tiga detik.

• Coba lagi segera: Kesalahan sementara yang terjadi seperti tabrakan paket jaringan atau lonjakan komponen perangkat keras biasanya singkat. Dalam skenario ini, mencoba ulang operasi segera dapat membantu karena mungkin berhasil jika kesalahan teratasi selama aplikasi merakit dan mengirim permintaan berikutnya. Jangan mencoba lagi lebih dari satu kali. Jika percobaan ulang segera gagal, beralih ke strategi alternatif, seperti back-off eksponensial atau tindakan fallback.

• Pengacakan: Salah satu strategi coba ulang yang tercantum sebelumnya dapat mencakup pengacakan untuk mencegah berbagai instansi klien mengirim upaya coba ulang berikutnya secara bersamaan. Misalnya, satu instans mungkin mencoba kembali operasi setelah 3 detik, 11 detik, atau 28 detik, sementara instans lain mungkin mencoba kembali operasi setelah 4 detik, 12 detik, atau 26 detik. Pengacakan adalah teknik berguna yang dapat Anda gabungkan dengan strategi lain.

Gunakan strategi penundaan eksponensial dengan jitter untuk operasi latar belakang, dan gunakan strategi interval coba lagi langsung atau teratur untuk operasi interaktif. Dalam kedua kasus, pilih penundaan dan jumlah coba lagi sehingga latensi maksimum untuk semua upaya coba lagi memenuhi persyaratan latensi end-to-end.

Kombinasi faktor berkontribusi pada batas waktu maksimum keseluruhan untuk operasi yang dicoba kembali. Pertimbangkan faktor berikut:

• Waktu yang diperlukan koneksi yang gagal untuk menghasilkan respons. Nilai batas waktu pada klien biasanya diatur saat ini.

• Penundaan antara usaha pengulangan.

• Jumlah maksimum percobaan ulang.

Total 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 tujuan tingkat layanan (SLO) tertentu, waktu operasi keseluruhan, termasuk semua batas waktu dan penundaan, harus berada dalam batas yang ditentukan dalam SLO.

Pertimbangkan waktu habis dari operasi saat Anda memilih interval coba ulang untuk menghindari pelaksanaan upaya berikutnya secara langsung, seperti jika periode waktu habis mirip dengan interval coba ulang. Tentukan apakah Anda perlu menyimpan total periode yang mungkin, yaitu batas waktu ditambah interval coba lagi, di bawah ambang 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.

Atur batas waktu pada setiap panggilan keluar sebelum Anda menerapkan logika coba lagi. Penghentian sementara, percobaan ulang, dan pendekatan back-off berfungsi bersama. Strategi coba lagi hanya seefektif batas waktu yang mengendalikan setiap upaya individu. Timeout yang terlalu lama menyebabkan thread dan koneksi terakumulasi selama pemadaman. Batas waktu yang terlalu singkat menyebabkan kegagalan dini pada operasi yang sebaliknya akan berhasil.

Jangan menerapkan strategi coba lagi yang terlalu agresif. Strategi ini menggunakan interval yang terlalu pendek atau percobaan ulang yang terjadi terlalu sering. Mereka dapat berdampak buruk pada sumber daya atau layanan target. Mereka mungkin juga mencegah pemulihan sumber daya atau layanan, sehingga sumber daya atau layanan terus memblokir atau menolak permintaan. Skenario ini membuat siklus di mana aplikasi mengirim lebih banyak permintaan ke sumber daya atau layanan, yang semakin mengurangi kemampuannya untuk pulih.

Gunakan jenis pengecualian dan data apa pun yang dikandungnya, atau kode kesalahan dan pesan yang dikembalikan layanan, untuk mengoptimalkan jumlah percobaan ulang dan interval di antaranya. Beberapa pengecualian atau kode kesalahan, seperti HTTP 503 (Layanan Tidak Tersedia), mungkin menunjukkan bahwa layanan gagal dan tidak akan merespons upaya lebih lanjut. Saat respons menyertakan sebuah header Retry-After, ikuti dan tunggu setidaknya durasi yang ditentukan sebelum upaya berikutnya. Sinyal yang disediakan server ini mencerminkan garis waktu pemulihan layanan dan lebih diutamakan daripada perhitungan back-off sisi klien Anda.

Gunakan pendekatan dead-letter queue agar informasi dari permintaan masuk tetap ada setelah semua upaya coba ulang habis. Teknik ini menuguhkan pekerjaan yang gagal untuk diproses nanti alih-alih membuangnya.

Hindari pola yang tidak efektif

Dalam kebanyakan kasus, hindari implementasi yang mencakup lapisan kode ulang yang duplikat. Hindari desain yang menggunakan mekanisme coba lagi bertahap atau yang menerapkan percobaan ulang di setiap tahap operasi yang melibatkan hierarki permintaan, kecuali Anda memiliki persyaratan khusus. Dalam kasus luar biasa ini, gunakan kebijakan yang membatasi jumlah percobaan ulang dan periode penundaan, dan pastikan Anda memahami konsekuensinya.

Misalnya, pertimbangkan satu komponen yang membuat permintaan ke komponen lain, yang kemudian mengakses layanan target. Percobaan ulang dengan tiga kali coba pada setiap panggilan akan menjadi sembilan percobaan ulang secara keseluruhan terhadap layanan.

Banyak layanan dan sumber daya menerapkan mekanisme coba lagi bawaan. Nonaktifkan atau ubah mekanisme ini jika Anda perlu menerapkan percobaan ulang pada tingkat yang lebih tinggi. Untuk informasi selengkapnya tentang risiko percobaan ulang yang tidak terkoordinasi, lihat Antipattern Retry Storm.

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

Terapkan anggaran coba lagi untuk membatasi jumlah total percobaan ulang di semua permintaan dalam proses atau layanan selain batas untuk setiap permintaan individu. Misalnya, Anda mungkin mengizinkan proses untuk melakukan tidak lebih dari 60 percobaan ulang per menit terhadap dependensi tertentu. Jika Anda menghabiskan anggaran, segera gagalkan permintaan alih-alih mencoba kembali.

Batas coba ulang per permintaan saja tidak dapat mencegah skenario di mana banyak permintaan bersamaan masing-masing mencoba ulang beberapa kali dan secara kolektif membebani layanan hilir yang sedang kesulitan. Anggaran percobaan ulang membatasi beban percobaan ulang secara keseluruhan dan dapat membuat perbedaan antara masalah kapasitas yang terbatas pada satu lokasi dan kegagalan yang beruntun.

Jangan pernah melakukan pengulangan kembali segera untuk kedua kalinya.

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 penundaan eksponensial yang menggunakan kemampuan pemutus sirkuit.

Cegah beberapa contoh klien yang sama, atau beberapa contoh klien berbeda, dari mengirim ulang secara bersamaan. Jika skenario ini mungkin, masukkan pengacakan ke dalam interval coba lagi.

Menguji strategi coba lagi dan implementasi Anda

Uji strategi coba lagi Anda di berbagai kondisi, terutama ketika aplikasi dan sumber daya atau layanan targetnya beroperasi di bawah beban ekstrem. Untuk memeriksa perilaku selama pengujian, Anda dapat mengambil tindakan berikut:

• Sertakan kesalahan sementara dalam rekayasa chaos dan praktik injeksi kesalahan Anda dengan sengaja memasukkannya ke lingkungan nonproduksi dan produksi Anda. Misalnya, kirim permintaan yang tidak didukung atau tambahkan kode yang mendeteksi permintaan pengujian dan merespons dengan berbagai jenis kesalahan.

• Buat versi tiruan sumber daya atau layanan yang mengembalikan berbagai kesalahan yang mungkin dikembalikan oleh layanan nyata. Pastikan bahwa semua jenis kesalahan yang terdeteksi oleh strategi pengulangan Anda tercakup.

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

• Pertimbangkan untuk menggunakan layanan injeksi kesalahan untuk menjalankan eksperimen terkontrol terhadap sumber daya Azure Anda. Misalnya, Azure Chaos Studio mendukung kesalahan langsung layanan, seperti menambahkan latensi jaringan atau me-reboot kluster cache, dan kesalahan berbasis agen, seperti menerapkan tekanan memori atau mengakhiri proses pada komputer virtual (VM). Anda dapat mengintegrasikan eksperimen injeksi kesalahan ke dalam alur integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) Anda untuk terus memvalidasi ketahanan sebagai bagian dari proses penyebaran Anda.

• 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. Pendekatan ini membantu Anda secara deterministik menguji subset kondisi kegagalan untuk kesalahan sementara dan jenis kegagalan lainnya.

• Jalankan uji faktor beban tinggi dan bersamaan untuk memastikan bahwa mekanisme percobaan ulang dan strategi bekerja dengan benar dalam kondisi ini. Pengujian ini juga membantu mengonfirmasi bahwa upaya coba lagi tidak memengaruhi operasi 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 faktor-faktor berikut:

• Apakah kesalahan kemungkinan bersifat sementara
• Jenis interval yang digunakan, seperti regular, penundaan eksponensial, atau pengacakan
• Nilai interval aktual
• Berapa kali mencoba lagi

Terapkan percobaan ulang di banyak tempat, termasuk dalam aplikasi dasar dan di setiap lapisan aplikasi yang lebih kompleks. Alih-alih membakukan (hard-coding) komponen kebijakan di beberapa lokasi, gunakan pusat terpusat 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. Pendekatan ini menyederhanakan manajemen pengaturan dan modifikasi dan penyempurnaan nilai untuk merespons perubahan persyaratan dan skenario. Rancang sistem untuk menyimpan nilai daripada dibaca ulang file konfigurasi untuk setiap permintaan, dan gunakan default yang sesuai jika konfigurasi tidak menyediakan nilai.

Simpan nilai yang digunakan untuk membangun kebijakan coba lagi pada runtime dalam sistem konfigurasi aplikasi 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 dengan skenario Anda. Strategi ini biasanya umum. Mereka mungkin memadai dalam beberapa skenario, tetapi dalam skenario lain mereka tidak menyediakan berbagai opsi untuk memenuhi persyaratan spesifik Anda. Untuk menentukan nilai yang paling cocok, uji untuk memahami bagaimana pengaturan memengaruhi aplikasi Anda. Untuk opsi default dan konfigurasi coba lagi khusus layanan, periksa panduan keandalan untuk setiap layanan Azure dalam arsitektur Anda.

Mencatat dan melacak kesalahan sementara dan kesalahan tidak sementara

Strategi coba lagi Anda harus mencakup penanganan pengecualian dan instrumentasi lain yang mencatat upaya coba lagi. Kegagalan sementara yang sesekali terjadi dan upaya pengulangan diharapkan dan tidak menunjukkan adanya masalah. Tetapi jumlah percobaan ulang yang teratur atau meningkat biasanya menunjukkan masalah yang dapat menyebabkan kegagalan atau mengurangi 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.

Simpan nilai dalam entri log Anda yang menunjukkan apakah pembatasan dalam layanan atau jenis kesalahan lainnya, seperti kegagalan koneksi, menyebabkan percobaan ulang. Pendekatan ini membantu Anda membedakan penyebab selama analisis data. Peningkatan kesalahan pembatasan performa biasanya menunjukkan adanya kelemahan desain dalam aplikasi dan kebutuhan untuk bermigrasi ke layanan premium yang menyediakan perangkat keras khusus.

Mengukur dan mencatat waktu yang berlalu secara keseluruhan untuk operasi yang menyertakan mekanisme coba lagi. Metrik ini secara akurat menunjukkan efek keseluruhan yang dimiliki kesalahan sementara pada waktu respons pengguna, latensi proses, dan efisiensi kasus penggunaan aplikasi. Catat jumlah percobaan ulang yang terjadi sehingga Anda dapat memahami faktor-faktor yang berkontribusi pada waktu respons.

Terapkan sistem telemetri dan pemantauan yang meningkatkan pemberitahuan saat metrik berikut meningkat:

• Jumlah dan tingkat kegagalan
• Jumlah rata-rata percobaan ulang
• Waktu keseluruhan yang berlalu sebelum operasi berhasil

Mengelola operasi yang terus gagal

Buat rencana untuk menangani operasi yang terus gagal di setiap upaya. Situasi ini tidak dapat dihindari.

• Strategi coba lagi menentukan berapa kali aplikasi harus mencoba kembali operasi. Ini tidak mencegah aplikasi mengulangi operasi untuk memulai dengan jumlah percobaan ulang yang sama. Misalnya, jika layanan pemrosesan pesanan gagal dengan kesalahan fatal yang mengeluarkannya dari layanan secara permanen, strategi coba lagi mungkin mendeteksi batas waktu koneksi dan memperlakukannya sebagai kesalahan sementara. Kode mencoba kembali operasi berapa kali yang ditentukan lalu berhenti. Ketika pelanggan lain melakukan pemesanan, aplikasi mencoba operasi lagi, mencoba kembali, dan gagal.

• Untuk mencegah percobaan ulang berkelanjutan untuk operasi yang terus gagal, terapkan pola Circuit Breaker. Saat Anda menggunakan pola ini, jika jumlah kegagalan dalam jendela waktu tertentu melebihi ambang batas, permintaan segera kembali ke pemanggil sebagai kesalahan, dan aplikasi tidak mencoba 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 tergantung pada faktor-faktor seperti kekritisan operasi dan sifat layanan. Mungkin berkisar dari beberapa menit hingga 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 di pusat data atau aplikasi yang berbeda. Anda mungkin juga menggunakan layanan serupa yang menyediakan layanan yang kompatibel, tetapi lebih sederhana, fungsionalitas, atau melakukan beberapa operasi alternatif berdasarkan harapan bahwa layanan tersedia segera. Misalnya, Anda dapat menyimpan permintaan untuk 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 menyediakan fungsionalitas yang dapat diterima, atau hanya mengembalikan pesan kepada pengguna untuk menunjukkan bahwa aplikasi saat ini tidak tersedia.

Pertimbangan lain

Saat Anda menentukan nilai untuk jumlah percobaan ulang dan interval coba ulang untuk kebijakan, pertimbangkan apakah operasi pada layanan atau sumber daya adalah bagian dari operasi yang berlangsung lama atau melibatkan beberapa langkah. Mungkin sulit atau mahal untuk mengimbangi semua langkah operasional yang telah berhasil ketika salah satunya gagal. Dalam hal ini, interval panjang dan sejumlah besar percobaan ulang mungkin dapat diterima selama strategi tidak memblokir operasi lain dengan menahan atau mengunci sumber daya yang langka.

Pertimbangkan apakah mencoba kembali operasi yang sama dapat menyebabkan inkonsistensi data. Jika aplikasi mengulangi bagian dari proses multistep dan operasi tidak idempoten, inkonsistensi dapat terjadi. Misalnya, jika operasi yang menaikkan nilai berulang, itu menghasilkan hasil yang salah. Operasi berulang yang mengirim pesan ke antrean juga dapat menyebabkan masalah bagi konsumen yang tidak dapat mendeteksi pesan duplikat. Untuk mencegah skenario ini, rancang setiap langkah sebagai operasi idempotensi. Untuk informasi selengkapnya, lihat Pola Konsumen Idempotoen.

Bersikaplah sengaja tentang ruang lingkup operasi yang diulang oleh aplikasi. Misalnya, mungkin lebih mudah untuk menerapkan logika coba lagi pada tingkat yang mencakup beberapa operasi dan mencoba kembali semuanya jika satu gagal. Tetapi pendekatan ini mungkin menyebabkan masalah idempotensi atau operasi putar kembali yang tidak perlu.

Jika Anda memilih cakupan pengulangan yang mencakup beberapa operasi, pertimbangkan total latensi dari semuanya saat Anda menentukan interval pengulangan, saat Anda memantau waktu operasi yang telah berlalu, dan sebelum Anda mengeluarkan peringatan untuk kegagalan.

Perhitungkan bagaimana strategi coba lagi Anda memengaruhi tetangga dan penyewa lain dalam aplikasi bersama dan saat Anda menggunakan sumber daya dan layanan bersama. Kebijakan coba lagi yang agresif dapat meningkatkan jumlah kesalahan sementara yang terjadi untuk pengguna lain dan untuk aplikasi yang berbagi sumber daya dan layanan. Kebijakan coba lagi yang diterapkan pengguna lain mungkin juga memengaruhi aplikasi Anda. Untuk aplikasi penting bagi bisnis, gunakan layanan premium yang tidak dibagikan. Pendekatan ini memungkinkan Anda mengontrol beban dan pembatasan sumber daya dan layanan yang konsekuen, yang dapat membenarkan biaya tambahan.

Langkah selanjutnya

Desain beban kerja untuk menangani kesalahan sementara