Pengoptimalan load balancing lanjutan

Halaman ini menjelaskan cara menggunakan kebijakan load balancing layanan untuk mendukung pengoptimalan biaya, latensi, dan ketahanan lanjutan untuk load balancer berikut:

• Load Balancer Aplikasi eksternal global
• Load Balancer Aplikasi internal lintas region
• Load Balancer Jaringan proxy eksternal global
• Load Balancer Jaringan proxy internal lintas region

Cloud Service Mesh juga mendukung pengoptimalan load balancing lanjutan. Untuk mengetahui detailnya, lihat Ringkasan load balancing lanjutan dalam dokumentasi Cloud Service Mesh.

Kebijakan load balancing layanan (serviceLbPolicy) adalah resource yang terkait dengan layanan backend load balancer. Kebijakan load balancing layanan memungkinkan Anda menyesuaikan parameter yang memengaruhi cara traffic didistribusikan dalam backend yang terkait dengan layanan backend:

• Menyesuaikan algoritma load balancing yang digunakan untuk menentukan cara traffic didistribusikan dalam region atau zona tertentu.
• Aktifkan pengosongan kapasitas otomatis sehingga load balancer dapat dengan cepat menghabiskan traffic dari backend yang tidak sehat.
• Tetapkan nilai minimum failover untuk menentukan kapan backend dianggap tidak responsif. Hal ini memungkinkan traffic gagal ke backend lain untuk menghindari backend yang tidak sehat.

Selain itu, Anda dapat menetapkan backend tertentu sebagai backend pilihan. Backend ini harus digunakan sesuai kapasitas sebelum permintaan dikirim ke backend yang tersisa.

Diagram berikut menunjukkan cara Cloud Load Balancing mengevaluasi pemilihan rute, load balancing, dan distribusi traffic.

Cara Cloud Load Balancing membuat keputusan pemilihan rute dan distribusi traffic.

Sebelum memulai

Sebelum meninjau konten halaman ini, tinjau dengan cermat Proses distribusi permintaan yang dijelaskan di halaman ringkasan Load Balancer Aplikasi Eksternal. Untuk load balancer yang selalu menggunakan Paket Premium, semua algoritma load balancing yang dijelaskan di halaman ini mendukung overflow antar-region jika region pilihan pertama sudah penuh.

Backend yang didukung

Kebijakan load balancing layanan dan backend pilihan hanya dapat dikonfigurasi di load balancer yang menggunakan backend yang didukung seperti yang ditunjukkan dalam tabel berikut.

Backend	Didukung?
Grup instance Tidak dikelola Dikelola menurut zona
MIG Regional
NEG Zona (endpoint GCE_VM_IP_PORT)
NEG Hybrid (endpoint NON_GCP_PRIVATE_IP_PORT)
NEG Serverless
NEG Internet
NEG Private Service Connect

Algoritma load balancing

Bagian ini menjelaskan algoritma load balancing yang dapat Anda konfigurasikan dalam kebijakan load balancing layanan. Jika Anda tidak mengonfigurasi algoritma, atau jika Anda tidak mengonfigurasi kebijakan load balancing layanan sama sekali, load balancer akan menggunakan WATERFALL_BY_REGION secara default.

Waterfall menurut wilayah

WATERFALL_BY_REGION adalah algoritma load balancing default. Dengan algoritma ini, secara agregat, semua Google Front End (GFE) di region terdekat dengan pengguna akan mencoba mengisi backend secara proporsional dengan kapasitas target yang dikonfigurasi (diubah oleh scaler kapasitasnya).

Setiap GFE lapisan kedua lebih memilih untuk memilih instance backend atau endpoint di zona yang sedekat mungkin (ditentukan oleh waktu perjalanan bolak-balik jaringan) ke GFE lapisan kedua. Karena WATERFALL_BY_REGION meminimalkan latensi antar-zona, pada kecepatan permintaan yang rendah, setiap GFE lapisan kedua mungkin secara eksklusif mengirim permintaan ke backend di zona pilihan GFE lapisan kedua.

Jika semua backend di region terdekat berjalan pada batas kapasitas yang dikonfigurasi, traffic akan mulai meluap ke region terdekat berikutnya sekaligus mengoptimalkan latensi jaringan.

Menyemprot ke wilayah

Algoritma SPRAY_TO_REGION mengubah perilaku individual dari setiap GFE lapisan kedua sejauh setiap GFE lapisan kedua tidak memiliki preferensi untuk memilih instance backend atau endpoint yang berada di zona sedekat mungkin dengan GFE lapisan kedua. Dengan SPRAY_TO_REGION, setiap GFE lapisan kedua akan mengirim permintaan ke semua instance atau endpoint backend, di semua zona di region, tanpa preferensi untuk waktu perjalanan bolak-balik yang lebih singkat antara GFE lapisan kedua dan instance atau endpoint backend.

Seperti WATERFALL_BY_REGION, secara agregat, semua GFE lapisan kedua di region mengisi backend secara proporsional dengan kapasitas target yang dikonfigurasi (diubah oleh scaler kapasitas).

Meskipun SPRAY_TO_REGION memberikan distribusi yang lebih seragam di antara backend di semua zona region, terutama pada rasio permintaan yang rendah, distribusi seragam ini disertai dengan pertimbangan berikut:

• Saat backend mengalami error (tetapi terus lulus health check), lebih banyak GFE lapisan kedua yang terpengaruh, meskipun dampak individualnya kurang parah.
• Karena setiap GFE lapisan kedua tidak memiliki preferensi untuk satu zona dibandingkan zona lainnya, GFE lapisan kedua akan membuat lebih banyak traffic lintas zona. Bergantung pada jumlah permintaan yang sedang diproses, setiap GFE lapisan kedua juga dapat membuat lebih banyak koneksi TCP ke backend.

Waterfall menurut zona

Algoritma WATERFALL_BY_ZONE mengubah perilaku individual dari setiap GFE lapisan kedua sejauh setiap GFE lapisan kedua memiliki preferensi yang sangat kuat untuk memilih instance backend atau endpoint yang berada di zona yang paling dekat dengan GFE lapisan kedua. Dengan WATERFALL_BY_ZONE, setiap GFE lapisan kedua hanya mengirim permintaan ke instance atau endpoint backend di zona lain di region saat GFE lapisan kedua telah mengisi (atau melebihi kapasitas secara proporsional) instance atau endpoint backend di zona yang paling disukainya.

Seperti WATERFALL_BY_REGION, secara agregat, semua GFE lapisan kedua di region mengisi backend secara proporsional dengan kapasitas target yang dikonfigurasi (diubah oleh scaler kapasitas).

Algoritma WATERFALL_BY_ZONE meminimalkan latensi dengan pertimbangan berikut:

• WATERFALL_BY_ZONE secara inheren tidak meminimalkan koneksi lintas zona. Algoritma hanya diarahkan oleh latensi.
• WATERFALL_BY_ZONE tidak menjamin bahwa setiap GFE lapisan kedua selalu mengisi zona yang paling disukai sebelum mengisi zona lain. Peristiwa pemeliharaan dapat secara sementara menyebabkan semua traffic dari GFE lapisan kedua dikirim ke instance atau endpoint backend di zona lain.
• WATERFALL_BY_ZONE dapat menyebabkan distribusi permintaan yang kurang seragam di antara semua instance backend atau endpoint dalam region secara keseluruhan. Misalnya, instance atau endpoint backend di zona GFE lapisan kedua yang paling disukai mungkin terisi penuh, sedangkan backend di zona lain tidak terisi penuh.

Membandingkan algoritma load balancing

Tabel berikut membandingkan berbagai algoritma load balancing.

Perilaku	Waterfall menurut wilayah	Menyemprot ke wilayah	Waterfall menurut zona
Penggunaan kapasitas yang seragam dalam satu region	Ya	Ya	Tidak
Penggunaan kapasitas yang seragam di beberapa region	Tidak	Tidak	Tidak
Pemisahan traffic yang seragam dari load balancer	Tidak	Ya	Tidak
Distribusi traffic lintas zona	Ya. Traffic didistribusikan secara merata di seluruh zona dalam suatu region sekaligus mengoptimalkan latensi jaringan. Traffic mungkin dikirim ke seluruh zona jika diperlukan.	Ya	Ya. Traffic pertama-tama akan diarahkan ke zona terdekat hingga mencapai kapasitas. Kemudian, ia akan beralih ke zona terdekat berikutnya.
Sensitivitas terhadap lonjakan traffic di zona lokal	Rata-rata; bergantung pada jumlah traffic yang telah dialihkan untuk menyeimbangkan di seluruh zona.	Lebih rendah; lonjakan satu zona tersebar di semua zona dalam region.	Lebih tinggi; lonjakan zona tunggal kemungkinan akan ditayangkan sepenuhnya oleh zona yang sama hingga load balancer dapat bereaksi.

Pengosongan kapasitas otomatis

Jika backend tidak sehat, Anda biasanya ingin mengecualikannya dari keputusan load balancing sesegera mungkin. Mengecualikan backend yang tidak responsif akan mengoptimalkan latensi keseluruhan dengan hanya mengirim traffic ke backend yang responsif.

Saat Anda mengaktifkan fitur pengosongan kapasitas otomatis, load balancer akan otomatis menskalakan kapasitas backend menjadi nol jika kurang dari 25 persen instance atau endpoint backend lulus health check. Tindakan ini akan menghapus backend yang tidak responsif dari kumpulan load balancing global. Tindakan ini secara fungsional setara dengan menetapkan backendService.capacityScaler ke 0 untuk backend jika Anda ingin menghindari rute traffic ke backend tersebut.

Jika 35 persen (10 persen di atas nilai minimum) instance atau endpoint backend yang sebelumnya dikosongkan secara otomatis lulus health check selama 60 detik, backend akan otomatis dikosongkan dan ditambahkan kembali ke kumpulan load balancing. Hal ini memastikan bahwa backend benar-benar responsif dan tidak beralih antara status yang habis dan tidak habis.

Meskipun pengosongan kapasitas otomatis diaktifkan, load balancer tidak akan menghabiskan lebih dari 50 persen backend yang terpasang ke layanan backend, terlepas dari status responsivitas backend. Mempertahankan 50 persen backend yang terpasang akan mengurangi risiko kelebihan beban backend yang sehat.

Salah satu kasus penggunaan pengosongan kapasitas otomatis adalah menggunakannya untuk meminimalkan risiko melebihi kapasitas backend pilihan Anda. Misalnya, jika backend ditandai sebagai pilihan, tetapi sebagian besar instance atau endpoint-nya tidak sehat, pengosongan kapasitas otomatis akan menghapus backend dari kumpulan load balancing. Alih-alih membebani instance atau endpoint yang masih berfungsi di backend yang diinginkan, pengosongan kapasitas otomatis akan mengalihkan traffic ke backend lain.

Anda dapat mengaktifkan pengosongan kapasitas otomatis sebagai bagian dari kebijakan load balancing layanan. Untuk mengetahui detailnya, lihat Mengonfigurasi kebijakan load balancing layanan.

Kapasitas otomatis tidak didukung dengan backend yang tidak menggunakan mode penyeimbangan. Hal ini mencakup backend seperti NEG internet, NEG tanpa server, dan NEG PSC.

Nilai minimum failover

Load balancer menentukan distribusi traffic di antara backend dengan cara multi-level. Dalam status stabil, load balancer mengirim traffic ke backend yang dipilih berdasarkan salah satu algoritma load balancing yang dijelaskan sebelumnya. Backend ini, yang disebut backend utama, dianggap optimal dalam hal latensi dan kapasitas.

Load balancer juga melacak backend lain yang dapat digunakan jika backend utama tidak responsif dan tidak dapat menangani traffic. Backend ini disebut backend failover. Backend ini biasanya merupakan backend di sekitar dengan kapasitas yang tersisa.

Jika instance atau endpoint di backend utama menjadi tidak responsif, load balancer tidak akan langsung mengalihkan traffic ke backend lain. Sebagai gantinya, load balancer akan mengalihkan traffic terlebih dahulu ke instance atau endpoint lain yang responsif di backend yang sama untuk membantu menstabilkan beban traffic. Jika terlalu banyak endpoint di backend utama yang tidak responsif, dan endpoint yang tersisa di backend yang sama tidak dapat menangani traffic tambahan, load balancer akan menggunakan nilai minimum failover untuk menentukan kapan harus mulai mengirim traffic ke backend failover. Load balancer mentoleransi ketidakstabilan di backend utama hingga nilai minimum failover. Setelah itu, traffic akan dialihkan dari backend utama.

Ambang batas failover adalah nilai antara 1 dan 99, yang dinyatakan sebagai persentase endpoint di backend yang harus responsif. Jika persentase endpoint yang responsif berada di bawah batas failover, load balancer akan mencoba mengirim traffic ke backend failover. Secara default, nilai minimum failover adalah 70.

Jika batas failover ditetapkan terlalu tinggi, traffic yang tidak perlu dapat terjadi karena perubahan kesehatan sementara. Jika nilai minimum failover ditetapkan terlalu rendah, load balancer akan terus mengirim traffic ke backend utama meskipun ada banyak endpoint yang tidak responsif.

Keputusan failover dilokalkan. Setiap Google Front End (GFE) lokal berperilaku secara independen dari yang lain. Anda bertanggung jawab untuk memastikan bahwa backend failover dapat menangani traffic tambahan.

Traffic failover dapat menyebabkan backend kelebihan beban. Meskipun backend tidak responsif, load balancer mungkin masih mengirim traffic ke sana. Untuk mengecualikan backend yang tidak sehat dari kumpulan backend yang tersedia, aktifkan fitur pengosongan kapasitas otomatis.

Backend pilihan

Backend pilihan adalah backend yang kapasitasnya ingin Anda gunakan sepenuhnya sebelum mengalihkan traffic ke backend lain. Traffic apa pun yang melebihi kapasitas backend pilihan yang dikonfigurasi akan dirutekan ke backend non-pilihan yang tersisa. Algoritma load balancing kemudian mendistribusikan traffic di antara backend non-pilihan dari layanan backend.

Anda dapat mengonfigurasi load balancer untuk lebih memilih dan sepenuhnya menggunakan satu atau beberapa backend yang terpasang ke layanan backend sebelum merutekan permintaan berikutnya ke backend yang tersisa.

Pertimbangkan batasan berikut saat Anda menggunakan backend pilihan:

• Backend yang dikonfigurasi sebagai backend pilihan mungkin lebih jauh dari klien dan menghasilkan latensi rata-rata yang lebih tinggi untuk permintaan klien. Hal ini terjadi meskipun ada backend lain yang lebih dekat yang dapat menayangkan klien dengan latensi yang lebih rendah.
• Algoritma load balancing tertentu (WATERFALL_BY_REGION, SPRAY_TO_REGION, dan WATERFALL_BY_ZONE) tidak berlaku untuk backend yang dikonfigurasi sebagai backend pilihan.

Untuk mempelajari cara menetapkan backend pilihan, lihat Menetapkan backend pilihan.

Mengonfigurasi kebijakan load balancing layanan

Catatan: Bagian ini mengasumsikan Anda telah memiliki pengetahuan tingkat menengah hingga lanjutan tentang Cloud Load Balancing. Langkah-langkah ini tidak menjelaskan pembuatan layanan backend atau konfigurasi load balancer dasar lainnya. Untuk menyiapkan penyiapan dasar terlebih dahulu, lihat dokumentasi load balancer masing-masing.

Resource kebijakan load balancing layanan memungkinkan Anda mengonfigurasi kolom berikut:

• Algoritma load balancing
• Pengosongan kapasitas otomatis
• Nilai minimum failover

Untuk menetapkan backend pilihan, lihat Menetapkan backend pilihan.

Buat kebijakan

Untuk membuat dan mengonfigurasi kebijakan load balancing layanan, selesaikan langkah-langkah berikut:

1. Buat resource kebijakan load balancing layanan. Anda dapat melakukannya menggunakan file YAML atau secara langsung, menggunakan parameter gcloud.

   • Dengan file YAML. Anda menentukan kebijakan load balancing layanan dalam file YAML. Berikut adalah contoh file YAML yang menunjukkan cara mengonfigurasi algoritma load balancer, mengaktifkan pengosongan kapasitas otomatis, dan menetapkan nilai minimum failover kustom:

     name: projects/PROJECT_ID/locations/global/serviceLbPolicies/SERVICE_LB_POLICY_NAME
     autoCapacityDrain:
         enable: True
     failoverConfig:
         failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
     loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
     

     Ganti kode berikut:

     • PROJECT_ID: project ID.
     • SERVICE_LB_POLICY_NAME: nama kebijakan load balancing layanan.
     • FAILOVER_THRESHOLD_VALUE: nilai nilai minimum kegagalan. Nilai ini harus berupa angka antara 1 dan 99.
     • LOAD_BALANCING_ALGORITHM: algoritma load balancing yang akan digunakan. Ini dapat berupa SPRAY_TO_REGION, WATERFALL_BY_REGION, atau WATERFALL_BY_ZONE.

     Setelah Anda membuat file YAML, impor file ke kebijakan load balancing layanan baru.

     gcloud network-services service-lb-policies import SERVICE_LB_POLICY_NAME \
      --source=PATH_TO_POLICY_FILE \
      --location=global
     

   • Tanpa file YAML. Atau, Anda dapat mengonfigurasi fitur kebijakan load balancing layanan tanpa menggunakan file YAML.

     Untuk menetapkan algoritma load balancing dan mengaktifkan pengosongan otomatis, gunakan parameter berikut:

     gcloud network-services service-lb-policies create SERVICE_LB_POLICY_NAME \
      --load-balancing-algorithm=LOAD_BALANCING_ALGORITHM \
      --auto-capacity-drain \
      --failover-health-threshold=FAILOVER_THRESHOLD_VALUE \
      --location=global
     

     Ganti kode berikut:

     • SERVICE_LB_POLICY_NAME: nama kebijakan load balancing layanan.
     • LOAD_BALANCING_ALGORITHM: algoritma load balancing yang akan digunakan. Ini dapat berupa SPRAY_TO_REGION, WATERFALL_BY_REGION, atau WATERFALL_BY_ZONE.
     • FAILOVER_THRESHOLD_VALUE: nilai nilai minimum kegagalan. Nilai ini harus berupa angka antara 1 dan 99.

2. Update layanan backend sehingga kolom --service-lb-policy-nya mereferensikan resource kebijakan load balancing layanan yang baru dibuat. Layanan backend hanya dapat dikaitkan dengan satu resource kebijakan load balancing layanan.

   gcloud compute backend-services update BACKEND_SERVICE_NAME \
     --service-lb-policy=SERVICE_LB_POLICY_NAME \
     --global
   

   Anda dapat mengaitkan kebijakan load balancing layanan dengan layanan backend saat membuat layanan backend.

   gcloud compute backend-services create BACKEND_SERVICE_NAME \
       --protocol=PROTOCOL \
       --port-name=NAMED_PORT_NAME \
       --health-checks=HEALTH_CHECK_NAME \
       --load-balancing-scheme=LOAD_BALANCING_SCHEME \
       --service-lb-policy=SERVICE_LB_POLICY_NAME \
       --global
   

Menghapus kebijakan

Untuk menghapus kebijakan load balancing layanan dari layanan backend, gunakan perintah berikut:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-service-lb-policy \
    --global

Menetapkan backend pilihan

Anda dapat mengonfigurasi backend pilihan menggunakan Google Cloud CLI atau API.

gcloud

Menambahkan backend pilihan

Untuk menetapkan backend pilihan, gunakan perintah gcloud compute backend-services add-backend untuk menetapkan flag --preference saat Anda menambahkan backend ke layanan backend.

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

Ganti PREFERENCE dengan tingkat preferensi yang ingin Anda tentukan ke backend. Ini dapat berupa PREFERRED atau DEFAULT.

Perintah lainnya bergantung pada jenis backend yang Anda gunakan (grup instance atau NEG). Untuk semua parameter yang diperlukan, lihat perintah gcloud compute backend-services add-backend.

Memperbarui preferensi backend

Untuk memperbarui parameter --preference backend, gunakan perintah gcloud compute backend-services update-backend.

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

Perintah lainnya bergantung pada jenis backend yang Anda gunakan (grup instance atau NEG). Contoh perintah berikut memperbarui preferensi grup instance backend dan menetapkannya ke PREFERRED:

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    --instance-group=INSTANCE_GROUP_NAME \
    --instance-group-zone=INSTANCE_GROUP_ZONE \
    --preference=PREFERRED \
    --global

API

Untuk menetapkan backend pilihan, tetapkan flag preference di setiap backend menggunakan resource backendServices global.

Berikut adalah contoh yang menunjukkan cara mengonfigurasi preferensi backend:

  name: projects/PROJECT_ID/locations/global/backendServices/BACKEND_SERVICE_NAME
  ...
  - backends
      name: BACKEND_1_NAME
      preference: PREFERRED
      ...
  - backends
      name: BACKEND_2_NAME
      preference: DEFAULT
      ...

Ganti kode berikut:

• PROJECT_ID: the project ID
• BACKEND_SERVICE_NAME: nama layanan backend
• BACKEND_1_NAME: nama backend yang dipilih
• BACKEND_2_NAME: nama backend default

Pemecahan masalah

Pola distribusi traffic dapat berubah saat Anda melampirkan kebijakan load balancing layanan baru ke layanan backend.

Untuk men-debug masalah traffic, gunakan Cloud Monitoring untuk melihat cara traffic mengalir antara load balancer dan backend. Log dan metrik Cloud Load Balancing juga dapat membantu Anda memahami perilaku load balancing.

Bagian ini merangkum beberapa skenario umum yang mungkin Anda lihat dalam konfigurasi yang baru ditampilkan.

Traffic dari satu sumber dikirim ke terlalu banyak backend yang berbeda

Ini adalah perilaku yang dimaksudkan dari algoritma SPRAY_TO_REGION. Namun, Anda mungkin mengalami masalah yang disebabkan oleh distribusi traffic yang lebih luas. Misalnya, rasio hit cache mungkin menurun karena backend melihat traffic dari pilihan klien yang lebih luas. Dalam hal ini, pertimbangkan untuk menggunakan algoritma lain seperti WATERFALL_BY_REGION.

Traffic tidak dikirim ke backend dengan banyak endpoint yang tidak sehat

Ini adalah perilaku yang dimaksudkan saat autoCapacityDrain diaktifkan. Backend dengan banyak endpoint yang tidak responsif akan dikosongkan dan dihapus dari kumpulan load balancing. Jika tidak menginginkan perilaku ini, Anda dapat menonaktifkan pengosongan kapasitas otomatis. Namun, hal ini berarti traffic dapat dikirim ke backend dengan banyak endpoint yang tidak sehat dan permintaan dapat gagal.

Traffic dikirim ke backend yang lebih jauh sebelum backend yang lebih dekat

Ini adalah perilaku yang diinginkan jika backend pilihan Anda lebih jauh dari backend default Anda. Jika Anda tidak menginginkan perilaku ini, perbarui setelan preferensi untuk setiap backend.

Traffic tidak dikirim ke beberapa backend saat menggunakan backend pilihan

Ini adalah perilaku yang diinginkan saat backend pilihan Anda belum mencapai kapasitas. Backend pilihan ditetapkan terlebih dahulu berdasarkan latensi waktu pulang-pergi ke backend ini.

Jika ingin traffic dikirim ke backend lain, Anda dapat melakukan salah satu hal berikut:

• Perbarui setelan preferensi untuk backend lainnya.
• Tetapkan setelan kapasitas target yang lebih rendah untuk backend pilihan Anda. Kapasitas target dikonfigurasi menggunakan kolom max-rate atau max-utilization, bergantung pada mode penyeimbangan layanan backend.

Traffic dikirim ke backend jarak jauh selama perubahan status sementara

Ini adalah perilaku yang diinginkan saat nilai minimum failover ditetapkan ke nilai tinggi. Jika Anda ingin traffic terus diarahkan ke backend utama saat ada perubahan respons sementara, tetapkan kolom ini ke nilai yang lebih rendah.

Endpoint yang responsif kelebihan beban saat endpoint lain tidak responsif

Ini adalah perilaku yang diinginkan saat nilai minimum failover ditetapkan ke nilai yang rendah. Jika endpoint tidak sehat, traffic yang ditujukan untuk endpoint yang tidak sehat ini akan tersebar di antara endpoint yang tersisa di backend yang sama. Jika Anda ingin perilaku failover dipicu lebih cepat, tetapkan kolom ini ke nilai yang lebih tinggi.

Batasan

• Setiap layanan backend hanya dapat dikaitkan dengan satu resource kebijakan load balancing layanan.