Download Teknologi App
.png)
Sumber: ChatGPT
Sistem Jatuh karena Berusaha Melayani Semuanya
Ketika permintaan yang masuk melampaui kapasitas sistem, ada dua kemungkinan perilaku. Sistem bisa berusaha menerima semuanya, atau sistem bisa menolak sebagian secara tertib.
Pilihan pertama terdengar lebih ramah, tetapi hasilnya justru paling merugikan. Permintaan menumpuk di antrean, memori terpakai untuk menahan koneksi yang belum terlayani, dan pada akhirnya seluruh sistem berhenti melayani siapa pun. Semua pengguna gagal, termasuk yang sebenarnya masih bisa dilayani.
Pilihan kedua terlihat lebih keras, tetapi jauh lebih baik. Sebagian permintaan ditolak dengan jawaban yang jelas, sementara sisanya tetap dilayani dengan baik. Inilah yang membedakan sistem yang dirancang untuk beban nyata dari sistem yang hanya dirancang untuk kondisi normal.
Efek Berantai yang Membuat Satu Masalah Menjadi Menyeluruh
Pada sistem yang layanannya saling bergantung, kegagalan jarang berhenti di satu tempat. Satu layanan yang melambat membuat layanan pemanggilnya ikut menunggu. Selama menunggu, layanan itu tetap memakai sumber daya, sehingga kapasitasnya untuk melayani permintaan lain berkurang.
Dalam hitungan menit, layanan yang sebenarnya sehat ikut kehabisan kapasitas hanya karena menunggu layanan lain yang bermasalah. Pengguna melihatnya sebagai kegagalan menyeluruh, padahal penyebab awalnya hanya satu komponen.
Dua mekanisme berikut bekerja bersama untuk memutus rantai ini, satu di sisi masuk dan satu di sisi keluar.
Mengatur Aliran Masuk
Pembatasan laju permintaan sering disalahpahami sekadar sebagai pembatasan akses. Fungsinya sebenarnya lebih penting, yaitu memastikan kapasitas yang ada dialokasikan pada permintaan yang paling perlu dilayani.
Beberapa pendekatan dipakai sesuai karakteristik trafiknya. Pendekatan berbasis kuota yang terisi ulang secara berkala mampu menoleransi lonjakan singkat tanpa mengorbankan rata-rata jangka panjang, sehingga cocok untuk kampanye atau periode ramai yang terjadwal.
Untuk penggunaan oleh pihak ketiga, pendekatan berbasis jendela bergeser memberi perhitungan yang lebih akurat dibanding jendela tetap, karena mencegah penumpukan permintaan tepat di batas pergantian periode.
Pada sistem yang berjalan di banyak instance, pembatasan pada satu instance saja tidak cukup. Perhitungan kuota perlu disimpan terpusat agar batasnya konsisten di seluruh sistem, dan ini biasanya memakai penyimpanan dalam memori yang cepat diakses.
Yang sama pentingnya, permintaan yang ditolak harus mendapat jawaban yang jelas beserta informasi kapan bisa mencoba lagi, agar sistem pemanggil bisa menyesuaikan diri alih-alih terus mencoba.
Membatasi Ketergantungan Keluar
Mekanisme kedua bekerja pada arah sebaliknya, yaitu ketika sistem Anda memanggil layanan lain yang sedang bermasalah.
Prinsipnya menyerupai sekring listrik. Setelah sejumlah kegagalan berturut-turut terhadap satu layanan, pemanggilan berikutnya langsung digagalkan tanpa perlu menunggu waktu habis. Ini mencegah penumpukan permintaan yang tidak akan berhasil.
Setelah jeda tertentu, sistem mencoba beberapa permintaan untuk menguji apakah layanan tujuan sudah pulih. Bila berhasil, aliran dibuka kembali secara bertahap. Bila masih gagal, jeda diperpanjang.
Selama pemutusan berlangsung, sistem sebaiknya menyediakan perilaku cadangan. Menampilkan data terakhir yang tersimpan atau memberi pesan yang jelas jauh lebih baik daripada membiarkan pengguna menunggu tanpa kepastian.
Menempatkan Pertahanan di Lapisan yang Tepat
Pertahanan yang efektif ditempatkan berlapis, bukan hanya di satu titik.
Di lapisan gerbang, pembatasan dasar menyaring permintaan berlebihan sebelum menyentuh aplikasi inti. Ini paling murah karena permintaan ditolak sebelum menghabiskan sumber daya pemrosesan.
Di lapisan aplikasi, pembatasan yang lebih memahami konteks bisnis bisa diterapkan, misalnya membedakan antara permintaan yang menghasilkan transaksi dan permintaan yang hanya membaca data.
Di lapisan pemantauan, jumlah permintaan yang ditolak perlu dipantau sebagai indikator. Kenaikan mendadak bisa menandakan lonjakan wajar, tetapi bisa juga menandakan penyalahgunaan yang perlu ditangani secara berbeda.
Kapan Sistem Anda Membutuhkan Pertahanan Ini
Kebutuhan ini biasanya baru disadari setelah terjadi satu kejadian yang membuat layanan tidak dapat diakses.
Langkah Memulai Bersama Sagara Sagara memulai dari pengukuran terhadap pola beban yang sebenarnya, bukan dari penerapan konfigurasi standar. Konsultasi discovery untuk memahami pola trafik dan titik yang paling rentan. Audit arsitektur untuk menilai perilaku sistem pada kondisi beban tinggi. Implementasi bertahap dengan pemantauan disiapkan lebih dulu, agar setiap batas yang ditetapkan bisa disesuaikan berdasarkan data. Kesimpulan Sistem yang berusaha melayani semua permintaan pada saat kapasitasnya terlampaui akan berakhir tidak melayani siapa pun. Sebagai vendor outsourcing IT berbasis cloud di Indonesia, Sagara merancang sistem yang tahu kapan harus menolak dengan tertib dan kapan harus memutus ketergantungan yang bermasalah. Karena ketahanan sebuah layanan tidak diukur dari kondisi normal, melainkan dari perilakunya ketika beban melampaui perkiraan.
Tinggalkan Komentar