Sumber: ChatGPT

Reaksi yang Terlihat Wajar Tapi Berbahaya

Ketika sebuah pemanggilan ke layanan lain gagal, reaksi paling alami adalah mencobanya lagi. Pada kegagalan yang bersifat sementara, cara ini memang menyelesaikan masalah.

Persoalannya muncul ketika kegagalan itu terjadi karena layanan tujuan sedang kewalahan. Dalam kondisi itu, mengulang permintaan berarti menambah beban pada sistem yang sudah kesulitan. Bila semua pemanggil melakukan hal yang sama pada saat bersamaan, layanan yang tadinya hanya lambat akan benar-benar berhenti.

Karena itu penanganan kegagalan yang baik bukan sekadar mengulang, melainkan mengulang dengan cara yang tidak memperburuk keadaan. Inilah salah satu hal yang membedakan jasa outsourcing IT untuk pengembangan software custom yang berpengalaman menangani beban nyata.

Mengulang dengan Cara yang Benar

Ada beberapa hal yang membuat pengulangan menjadi aman alih-alih merusak.

Memberi jeda yang membesar. Percobaan kedua dilakukan setelah jeda singkat, percobaan ketiga setelah jeda yang lebih panjang, dan seterusnya. Ini memberi kesempatan layanan tujuan untuk pulih alih-alih terus dibanjiri.

Menambahkan variasi acak pada jeda. Tanpa ini, semua pemanggil yang gagal pada waktu yang sama akan mencoba lagi pada waktu yang sama pula, menghasilkan gelombang permintaan serentak yang justru menjatuhkan layanan tepat saat mulai pulih.

Membatasi jumlah percobaan. Pengulangan tanpa batas hanya memindahkan kegagalan menjadi keterlambatan yang lebih panjang, dan pada akhirnya tetap gagal setelah membuang banyak sumber daya.

Membedakan jenis kegagalan. Kegagalan karena permintaan tidak valid tidak akan berubah hasilnya berapa kali pun diulang, sehingga mengulangnya hanya pemborosan. Yang layak diulang hanya kegagalan yang memang berpeluang berbeda hasilnya.

Memastikan Pengulangan Tidak Menghasilkan Duplikasi

Ada satu risiko yang membuat pengulangan berbahaya pada sistem transaksional, dan risiko ini sering terlewat.

Ketika koneksi terputus setelah sebuah permintaan sebenarnya berhasil diproses tetapi sebelum jawabannya sampai, pemanggil tidak tahu apakah permintaannya berhasil atau tidak. Bila ia mengulang, prosesnya bisa dijalankan dua kali. Pada konteks pembayaran atau pemotongan saldo, konsekuensinya sangat serius.

Penyelesaiannya adalah memastikan bahwa permintaan yang sama, meski dikirim beberapa kali, hanya diproses satu kali. Ini dilakukan dengan menyertakan penanda unik pada setiap permintaan. Bila sistem menerima permintaan dengan penanda yang sudah pernah diproses, ia langsung mengembalikan hasil yang sama tanpa menjalankan ulang logikanya.

Perancangan seperti ini perlu dilakukan sejak awal, karena menambahkannya pada sistem yang sudah berjalan menuntut penelusuran ke seluruh proses yang berpotensi terdampak.

Membatasi Dampak Ketika Kegagalan Berlanjut

Selain menangani kegagalan individual, sistem juga perlu menangani kondisi ketika sebuah layanan memang sedang bermasalah dalam waktu lama.

Pemutusan sementara. Setelah sejumlah kegagalan berturut-turut, pemanggilan berikutnya langsung digagalkan tanpa menunggu, lalu dicoba kembali secara bertahap setelah jeda. Ini mencegah penumpukan permintaan yang tidak akan berhasil.

Pemisahan sumber daya antar tujuan. Bila kumpulan koneksi dan kapasitas pemrosesan dibagi berdasarkan layanan tujuan, maka satu layanan yang bermasalah tidak akan menghabiskan seluruh kapasitas dan mengganggu pemanggilan ke layanan lain yang sehat.

Perilaku cadangan. Ketika sebuah layanan tidak tersedia, sistem sebaiknya tetap memberikan sesuatu yang masuk akal, misalnya data terakhir yang tersimpan disertai keterangan bahwa informasinya mungkin belum terbaru.

Kapan Penanganan Kegagalan Anda Perlu Ditinjau

Kelemahan pada penanganan kegagalan biasanya baru terlihat saat terjadi gangguan berskala besar.


Sinyal bahwa penanganan kegagalan Anda perlu diperbaiki:

  • Pengulangan permintaan dilakukan langsung tanpa jeda yang membesar.

  • Semua jenis kegagalan diperlakukan sama tanpa dibedakan penyebabnya.

  • Pernah ditemukan transaksi ganda akibat pengulangan permintaan.

  • Tidak ada penanda unik yang mencegah proses dijalankan dua kali.

  • Satu layanan bermasalah menghabiskan kapasitas untuk memanggil layanan lain.

  • Tidak ada perilaku cadangan ketika layanan pendukung tidak tersedia.

  • Penelusuran penyebab kegagalan lintas layanan sulit dilakukan.

Langkah Memulai Bersama Sagara

Sagara memulai dari menelusuri jalur pemanggilan antar layanan dan memetakan apa yang terjadi bila masing-masing gagal.

Konsultasi discovery untuk memahami ketergantungan antar layanan dan tingkat kekritisannya. Audit arsitektur untuk menemukan proses yang berisiko menghasilkan duplikasi. Implementasi bertahap yang mendahulukan proses transaksional, disertai penelusuran terdistribusi agar kegagalan bisa dilacak lintas layanan.

Kesimpulan

Mengulang permintaan yang gagal adalah reaksi yang wajar, tetapi tanpa jeda yang tepat dan jaminan tidak berulang, reaksi itu justru memperburuk keadaan.

Sebagai jasa outsourcing IT untuk pengembangan software custom, Sagara merancang penanganan kegagalan sejak awal karena menambahkannya belakangan menuntut penelusuran ke seluruh proses.

Karena pada sistem terdistribusi, kegagalan adalah keadaan yang pasti terjadi, dan yang menentukan adalah bagaimana sistem berperilaku ketika itu terjadi