Perlindungan sistem menyediakan perlindungan traffic tingkat node untuk berbagai situasi tak terduga. Misalnya, ketika antarmuka yang tidak memiliki aturan perlindungan traffic mengalami lonjakan lalu lintas (traffic spike), perlindungan sistem bertindak sebagai jaring pengaman yang menjamin stabilitas aplikasi Anda.
Untuk memahami hubungan antara perlindungan sistem dan perlindungan traffic, lihat Perlindungan sistem vs. perlindungan traffic.
Fitur perlindungan
Microservices Governance menyediakan fitur perlindungan sistem berikut untuk traffic sisi server dan traffic sisi klien. Gunakan metrik pemicu (trigger metric) dan karakteristik beban aplikasi Anda untuk menentukan fitur mana yang perlu dikonfigurasi.
| Feature | Trigger metric | Applies to | Minimum agent version |
| Adaptive overload protection | CPU utilization | Semua antarmuka sisi server | 3.1.4 atau lebih baru |
| Total QPS throttling | Total QPS dari sebuah node | Semua antarmuka sisi server | 4.2.0 atau lebih baru |
| Total concurrency throttling | Total concurrency dari sebuah node | Semua antarmuka sisi server | 4.2.0 atau lebih baru |
| Abnormal call circuit breaking | Error ratio dari sebuah antarmuka | Semua antarmuka sisi klien, kecuali antarmuka yang telah dikonfigurasi dengan aturan circuit breaking tingkat antarmuka | 4.2.0 atau lebih baru |
| Slow call circuit breaking | Slow call ratio dari sebuah antarmuka | Semua antarmuka sisi klien, kecuali antarmuka yang telah dikonfigurasi dengan aturan circuit breaking tingkat antarmuka | 4.2.0 atau lebih baru |
Batasan
Sebelum mengonfigurasi perlindungan sistem, perhatikan batasan berikut:
Precedence — Adaptive overload protection, total QPS throttling, dan total concurrency throttling memiliki prioritas lebih rendah dibandingkan aturan perlindungan traffic.
Kode status respons — Saat throttling dipicu, perlindungan sistem mengembalikan kode status 429. Kode status kustom tidak didukung.
Prasyarat
Hubungkan aplikasi Anda ke Microservices Governance. Untuk informasi selengkapnya, lihat Hubungkan aplikasi microservice ACK ke pusat governance MSE dan Hubungkan aplikasi microservice ECS ke pusat governance MSE.
Agen aplikasi Anda menjalankan versi yang mendukung fitur-fitur yang ingin Anda konfigurasi.
Prosedur
-
Masuk ke Konsol MSE, lalu pilih wilayah di bilah navigasi atas.
-
Di panel navigasi kiri, pilih Microservices Governance > Application Governance.
-
Pada halaman Application list, klik kartu resource aplikasi yang diinginkan. Di panel navigasi kiri, klik Traffic management.
Klik tab System protection. Untuk setiap fitur yang ingin digunakan, atur Mode dan konfigurasikan ambang batas (threshold) yang dijelaskan pada bagian terkait dalam topik ini.
Untuk memastikan suatu fitur melindungi traffic sesuai harapan, periksa daftar event di sisi kiri tab System protection dan grafik tren di sisi kanan. Untuk menghentikan fitur agar tidak melakukan throttling terhadap traffic, atur Mode-nya ke opsi nonaktif.
Adaptive overload protection
Cara kerja
Adaptive overload protection menggunakan CPU utilization untuk mengukur beban sistem dan secara adaptif menyesuaikan rasio throttling untuk traffic sisi server. Bahkan saat terjadi lonjakan traffic tak terduga, fitur ini menjaga CPU utilization tetap relatif stabil dalam ambang batas yang dikonfigurasi.
Skenario
Adaptive overload protection menyediakan perlindungan fallback berbasis CPU untuk antarmuka sisi server. Gunakan fitur ini untuk aplikasi yang terikat pada CPU (CPU-bound applications), di mana lonjakan pada antarmuka tak terduga meningkatkan beban CPU sistem dan memengaruhi waktu respons (RT) antarmuka inti.
Konsol
Tab System protection mencantumkan event adaptive overload protection di sisi kiri. Sisi kanan menampilkan tren rata-rata CPU utilization node aplikasi selama 5 menit terakhir.
Bagian atas halaman berisi pengaturan Mode untuk adaptive overload protection. Pada grafik garis CPU utilization di sisi kanan, garis putus-putus biru menandai protection threshold, yaitu ambang batas watermark perlindungan.
Event dilaporkan tingkat node berdasarkan perubahan status algoritma. Event tersebut mencakup mulainya throttling, throttling sedang berlangsung, dan berakhirnya throttling.
Klik tautan View di kolom Actions suatu event untuk mengkueri data CPU utilization dari alamat IP node terkait. Timeline akan mundur ke waktu pelaporan event sehingga Anda dapat mengamati CPU utilization dan probabilitas throttling node saat event dipicu.
| Parameter | Description |
| Mode |
|
| CPU utilization | Ambang batas CPU utilization yang diharapkan. Adaptive overload protection menggabungkan CPU utilization sistem aktual dengan ambang batas CPU utilization yang dikonfigurasi, lalu menggunakan algoritma untuk secara adaptif menyesuaikan probabilitas throttling antarmuka. Dalam kondisi beban berat, sistem menolak sebagian permintaan agar CPU utilization tetap berfluktuasi dalam rentang kecil di sekitar ambang batas yang dikonfigurasi. CPU utilization kondisi stabil bervariasi tergantung bisnis masing-masing aplikasi. Tentukan CPU utilization stabil maksimum melalui uji stres atau dari data historis, lalu tambahkan margin pada nilai tersebut. |
| Exceptions | Untuk informasi selengkapnya, lihat Konfigurasi pengecualian. |
Total QPS throttling
Cara kerja
Total QPS throttling melacak total QPS tingkat node—yaitu jumlah QPS dari semua antarmuka sisi server pada satu node—dan melakukan throttling terhadap permintaan yang melebihi ambang batas.
Skenario
Tidak semua sistem sangat terikat pada CPU. Beberapa aplikasi mengalami penurunan performa meski pada beban CPU rendah karena keterbatasan memori, jaringan, atau faktor lainnya. Total QPS throttling melakukan throttling berdasarkan total QPS sebuah node, sehingga menyediakan metode perlindungan berbasis traffic.
Gunakan total QPS throttling saat lonjakan pada antarmuka tak terduga menyebabkan kontensi terhadap sumber daya langka yang berdampak pada antarmuka inti.
Konsol
Tab System protection mencantumkan event total QPS throttling di sisi kiri. Sisi kanan menampilkan tren rata-rata data permintaan total QPS node aplikasi selama 5 menit terakhir.
Grafik garis di sisi kanan menampilkan kurva tren Total QPS, Passed QPS, dan Blocked QPS bersama garis referensi ambang batas, sehingga membantu Anda mengamati efek throttling.
Event dilaporkan tingkat node dan antarmuka berdasarkan node dan antarmuka tempat total QPS throttling benar-benar terjadi. Event dilaporkan setiap 5 menit dan mencakup throttling yang terjadi dalam 5 menit sebelumnya.
Klik tautan View di kolom Actions suatu event untuk mengkueri total QPS dari alamat IP node terkait. Timeline akan mundur ke waktu dekat pelaporan event sehingga Anda dapat memeriksa apakah total QPS node dan perilaku throttling sesuai ekspektasi. Halaman detail antarmuka dan halaman detail node menyediakan informasi lebih rinci, seperti data tingkat antarmuka dan node.
| Parameter | Description |
| Mode |
|
| Total QPS threshold | Ambang batas total QPS tingkat node. Tentukan total QPS stabil sebuah node melalui uji stres atau dari data historis, lalu tambahkan margin pada nilai tersebut. |
| Exceptions | Untuk informasi selengkapnya, lihat Konfigurasikan exceptions. |
Total concurrency throttling
Cara kerja
Total concurrency throttling melacak total concurrency tingkat node—yaitu jumlah permintaan konkuren dari semua antarmuka sisi server pada satu node—dan melakukan throttling terhadap permintaan yang melebihi ambang batas.
Skenario
Pada skenario dengan RT panggilan tinggi—umumnya lebih dari 1 detik—throttling berbasis QPS menunjukkan masalah yang jelas. Saat sumber daya sistem yang diperebutkan seperti kolam thread, memori, dan kolam koneksi terisi, permintaan mengantre dan RT antarmuka semakin meningkat. Jika hanya mengandalkan throttling berbasis QPS, sejumlah kecil permintaan tetap masuk ke sistem setiap detik, tetapi permintaan yang mengantre tidak dapat diproses dalam hitungan detik. Antrean membesar, RT semakin naik, dan RT baik permintaan baru maupun yang sudah ada meningkat signifikan.
Dengan throttling berbasis concurrency, permintaan baru langsung ditolak selama sejumlah permintaan belum selesai diproses. Permintaan diberi throttling, tetapi setelah sistem menyelesaikan permintaan saat ini, permintaan baru dapat lolos dengan waktu antrean lebih singkat. Secara keseluruhan, baik tingkat keberhasilan maupun RT rata-rata permintaan meningkat signifikan.
Gunakan total concurrency throttling saat lonjakan pada antarmuka tak terduga menyebabkan kontensi terhadap sumber daya langka, penumpukan antrean, dan RT lebih tinggi untuk semua permintaan.
Konsol
Tab System protection mencantumkan event total concurrency throttling di sisi kiri. Sisi kanan menampilkan tren rata-rata data permintaan konkuren total node aplikasi selama 5 menit terakhir.
Event dilaporkan tingkat node dan antarmuka berdasarkan node dan antarmuka tempat total concurrency throttling benar-benar terjadi. Event dilaporkan setiap 5 menit dan mencakup throttling yang terjadi dalam 5 menit sebelumnya.
Klik tautan View di kolom Actions suatu event untuk mengkueri total concurrency dari alamat IP node terkait. Timeline akan mundur ke waktu dekat pelaporan event sehingga Anda dapat memeriksa apakah total concurrency node dan perilaku throttling sesuai ekspektasi. Halaman detail antarmuka dan halaman detail node menyediakan informasi lebih rinci, seperti data tingkat antarmuka dan node.
| Parameter | Description |
| Mode |
|
| Total concurrency threshold | Ambang batas total concurrency tingkat node. Tentukan total concurrency stabil sebuah node melalui uji stres atau dari data historis, lalu tambahkan margin pada nilai tersebut. |
| Exceptions | Untuk informasi selengkapnya, lihat Konfigurasikan exceptions. |
Abnormal call circuit breaking
Cara kerja
Abnormal call circuit breaking melacak error ratio setiap antarmuka sisi klien. Saat error ratio melebihi ambang batas yang dikonfigurasi, pemutus sirkuit (circuit breaker) aktif untuk antarmuka tersebut. Selama circuit breaking, permintaan ke antarmuka tersebut gagal secara cepat (fail fast). Secara berkala, sistem mengizinkan satu permintaan probe. Saat permintaan probe berhasil, circuit breaking berakhir.
Skenario
Abnormal call circuit breaking terutama mencakup dua skenario:
Timeout errors — Error timeout tinggi pada antarmuka sisi klien biasanya menunjukkan penyedia layanan mengalami masalah. Hal ini menyebabkan permintaan menumpuk di pemanggil (aplikasi Anda) dan memengaruhi antarmuka lainnya. Circuit breaking membuat permintaan tersebut gagal secara cepat selama penyedia bermasalah, sehingga mencegah penumpukan.
Non-timeout errors — Saat error non-timeout pada antarmuka sisi klien terlalu tinggi, abnormal call circuit breaking melemparkan exception throttling yang dapat Anda tangani. Hal ini memberikan efek degradasi dan meningkatkan pengalaman pengguna dalam situasi abnormal.
Konsol
Tab System protection mencantumkan event abnormal call circuit breaking di sisi kiri. Sisi kanan menampilkan 10 antarmuka teratas berdasarkan error ratio aplikasi selama 5 menit terakhir.
Event dilaporkan tingkat node dan antarmuka berdasarkan node dan antarmuka tempat abnormal call circuit breaking benar-benar terjadi. Event dilaporkan setiap 5 menit dan mencakup throttling yang terjadi dalam 5 menit sebelumnya.
| Parameter | Description |
| Mode |
|
| Circuit breaking ratio threshold (%) | Ambang batas rasio circuit breaking tingkat antarmuka. |
| Exceptions | Untuk informasi selengkapnya, lihat Konfigurasikan exceptions. |
Advanced settings
| Parameter | Description |
| Statistical window duration (seconds) | Durasi jendela waktu statistik. Nilai valid: 1 detik hingga 120 menit. |
| Circuit breaking duration (s) | Periode berlangsungnya circuit breaking setelah dipicu. Setelah resource memasuki status circuit breaking, semua permintaan gagal secara cepat selama durasi circuit breaking yang dikonfigurasi. |
| Minimum number of requests | Jumlah minimum permintaan yang diperlukan untuk memicu circuit breaking. Jika jumlah permintaan dalam jendela statistik saat ini kurang dari nilai ini, aturan tidak dipicu meskipun kondisi circuit breaking terpenuhi. |
| Circuit breaking recovery strategy | Strategi pemulihan yang digunakan pemutus sirkuit saat memasuki fase pemulihan (status half-open).
|
Slow call circuit breaking
Cara kerja
Slow call circuit breaking melacak slow call ratio setiap antarmuka sisi klien. Saat slow call ratio melebihi ambang batas yang dikonfigurasi, pemutus sirkuit aktif untuk antarmuka tersebut. Selama circuit breaking, permintaan ke antarmuka tersebut gagal secara cepat. Secara berkala, sistem mengizinkan satu permintaan probe. Saat permintaan probe berhasil, circuit breaking berakhir.
Skenario
Slow call circuit breaking pada dasarnya mencakup skenario yang sama dengan skenario timeout pada abnormal call circuit breaking. Perbedaannya, Anda dapat menyesuaikan kriteria RT untuk mendefinisikan slow call secara dinamis tanpa bergantung pada konfigurasi timeout.
Konsol
Tab System protection mencantumkan event slow call circuit breaking di sisi kiri. Sisi kanan menampilkan 10 antarmuka teratas berdasarkan RT rata-rata aplikasi selama 5 menit terakhir.
Event dilaporkan tingkat node dan antarmuka berdasarkan node dan antarmuka tempat slow call circuit breaking benar-benar terjadi. Event dilaporkan setiap 5 menit dan mencakup throttling yang terjadi dalam 5 menit sebelumnya.
| Parameter | Description |
| Mode |
|
| Slow call RT (ms) | Permintaan dengan waktu respons lebih lama dari nilai ini dianggap sebagai slow call. |
| Degradation threshold (%) | Saat persentase permintaan dengan RT lebih lama dari slow call RT yang dikonfigurasi melebihi ambang batas ini, circuit breaking dipicu. |
| Exceptions | Untuk informasi selengkapnya, lihat Konfigurasikan exceptions. |
Advanced settings
| Parameter | Description |
| Statistical window duration (seconds) | Durasi jendela waktu statistik. Nilai valid: 1 detik hingga 120 menit. |
| Circuit breaking duration (s) | Periode berlangsungnya circuit breaking setelah dipicu. Setelah resource memasuki status circuit breaking, semua permintaan gagal secara cepat selama durasi circuit breaking yang dikonfigurasi. |
| Minimum number of requests | Jumlah minimum permintaan yang diperlukan untuk memicu circuit breaking. Jika jumlah permintaan dalam jendela statistik saat ini kurang dari nilai ini, aturan tidak dipicu meskipun kondisi circuit breaking terpenuhi. |
| Circuit breaking recovery strategy | Strategi pemulihan yang digunakan pemutus sirkuit saat memasuki fase pemulihan (status half-open).
|
Exceptions
Cara kerja
Anda dapat mengonfigurasi exceptions untuk semua fitur perlindungan sistem. Perlindungan sistem selalu mengizinkan antarmuka dalam daftar exceptions tanpa memeriksa aturan.
Exceptions memerlukan versi agen 4.2.0 atau lebih baru.
Skenario
Pada sebagian besar kasus, Anda hanya perlu mengonfigurasi exceptions untuk endpoint pemeriksaan kesehatan (health check) dan antarmuka sistem kritis. Exceptions untuk endpoint health check mencegah status kesehatan node terpengaruh. Antarmuka sistem kritis memiliki batas throttling tingkat antarmuka sendiri dan diharapkan tetap tidak terpengaruh oleh throttling tingkat sistem.
Konsol
Tab System protection mencantumkan antarmuka yang dapat Anda pilih langsung di sisi kiri. Antarmuka tersebut adalah antarmuka yang baru-baru ini dipanggil. Untuk antarmuka yang tidak tercantum di sisi kiri, masukkan namanya di kotak input lalu tekan Enter untuk menambahkannya ke antarmuka terpilih.
Anda dapat menghapus antarmuka terpilih satu per satu dengan mengklik × atau menghapus semuanya sekaligus dengan mengklik Remove all. Perlindungan sistem tidak menerapkan aturan yang dikonfigurasi pada antarmuka terpilih.
Perlindungan sistem vs. perlindungan traffic
Baik perlindungan sistem maupun perlindungan traffic menjaga aplikasi dalam kondisi stabil, tetapi keduanya mencakup skenario berbeda dan menyebabkan tingkat kehilangan traffic berbeda.
Perlindungan sistem menyediakan perlindungan traffic berdasarkan metrik tingkat node. Fitur ini menjaga aplikasi itu sendiri dalam kondisi stabil dan mencakup sebagian besar skenario. Namun, perlindungan sistem bekerja dari perspektif aplikasi dan memperlakukan semua antarmuka secara setara, padahal antarmuka dalam aplikasi yang sama berbeda dalam hal tingkat kepentingan dan dampaknya terhadap beban sistem. Perlindungan traffic memungkinkan Anda mengonfigurasi ambang batas berbeda untuk setiap antarmuka, sehingga mencakup lebih banyak skenario dan melakukan throttling terhadap traffic seminimal mungkin sambil tetap memberikan perlindungan yang sama.
Secara keseluruhan, baik perlindungan sistem maupun perlindungan traffic sama-sama efektif. Perlindungan traffic lebih unggul dalam cakupan skenario dan minimnya kehilangan traffic, sedangkan perlindungan sistem lebih mudah dikonfigurasi. Oleh karena itu, praktik terbaik adalah menggabungkan keduanya: gunakan perlindungan sistem untuk menjamin stabilitas aplikasi, dan gunakan perlindungan traffic untuk mengurangi kehilangan traffic (yaitu traffic yang diberi throttling) melalui konfigurasi detail halus tanpa mengurangi efek perlindungan.
Referensi
Untuk informasi selengkapnya tentang kebijakan perlindungan traffic, lihat Perlindungan traffic.