Pengoptimalan load balancing lanjutan

Halaman ini menjelaskan cara mengonfigurasi pengoptimalan biaya, latensi, dan ketahanan lanjutan untuk Load Balancer Aplikasi dan Load Balancer Jaringan Proxy.

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

Cloud Load Balancing menawarkan fitur lanjutan berikut:

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

  • Algoritma load balancing. Menyesuaikan algoritma load balancing yang digunakan untuk menentukan cara traffic didistribusikan dalam region atau zona tertentu.
  • Pengosongan kapasitas otomatis. Aktifkan pengosongan kapasitas otomatis sehingga load balancer dapat dengan cepat menghabiskan traffic dari backend yang tidak sehat.
  • Batas failover. Tetapkan nilai minimum failover untuk menentukan kapan backend dianggap tidak responsif. Hal ini memungkinkan traffic dialihkan ke backend lain untuk menghindari backend yang bermasalah.
  • Isolasi traffic. Cegah kegagalan beruntun dengan membatasi atau melarang luapan traffic lintas region.

• Backend pilihan. 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.

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.

Load balancer dan backend yang didukung

Load balancer berikut mendukung kebijakan load balancing layanan dan backend pilihan:

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

Fitur yang dijelaskan di halaman ini memerlukan backend yang kompatibel dan mendukung mode penyeimbangan. Backend yang didukung diringkas dalam tabel berikut:

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 gangguan (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 penskala 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.

Pengosongan dan pengisian kapasitas otomatis

Pengosongan dan pengisian kapasitas otomatis menggabungkan konsep health check dan kapasitas backend. Dengan pengosongan kapasitas otomatis, health check digunakan sebagai sinyal tambahan untuk menetapkan kapasitas backend yang efektif ke nol. Dengan pengosongan kapasitas otomatis, pemeriksaan kesehatan digunakan sebagai sinyal tambahan untuk memulihkan kapasitas backend yang efektif ke nilai sebelumnya.

Tanpa pengosongan dan pengisian kapasitas otomatis, jika Anda ingin mengalihkan permintaan dari semua backend di region tertentu, Anda harus menetapkan kapasitas efektif setiap backend di region tersebut ke nol secara manual. Misalnya, Anda dapat menggunakan scaler kapasitas untuk melakukannya.

Dengan pengosongan dan pengisian kapasitas otomatis, health check dapat digunakan sebagai sinyal untuk menyesuaikan kapasitas backend, baik dengan mengosongkan maupun mengisi kapasitas.

Untuk mengaktifkan pengosongan dan pengisian kapasitas otomatis, lihat Mengonfigurasi kebijakan load balancing layanan.

Pengosongan kapasitas otomatis

Pengosongan kapasitas otomatis menetapkan kapasitas setiap grup instance atau NEG backend kandidat yang dapat dikosongkan menjadi nol selama rasio grup instance atau NEG backend kandidat yang dapat dikosongkan dibandingkan dengan semua grup instance atau NEG backend kurang dari 50%. Saat menghitung rasio 50%, backend dengan kapasitas nol tidak disertakan dalam pembilang. Namun, semua backend disertakan dalam denominator.

Backend kandidat yang dapat dikosongkan adalah grup instance backend atau NEG yang memiliki kurang dari 25% instance atau endpoint anggotanya yang lulus pemeriksaan status load balancer.

Backend dengan kapasitas nol adalah sebagai berikut:

• Grup instance backend tanpa instance anggota, dengan kapasitas grup instance ditentukan per instance
• NEG backend tanpa endpoint anggota, dengan kapasitas NEG ditentukan berdasarkan per endpoint
• Grup instance backend atau NEG yang scaler kapasitasnya telah Anda tetapkan ke nol

Kapasitas backend yang otomatis dikosongkan secara fungsional setara dengan menetapkan backendService.backends[].capacityScaler backend ke 0 secara manual, tetapi tanpa menetapkan nilai penskala kapasitas.

Pengosongan kapasitas otomatis

Pengosongan kapasitas otomatis menampilkan kapasitas backend ke nilai yang dikontrol oleh penskala kapasitas backend saat 35% atau lebih instance atau endpoint backend lulus health check selama minimal 60 detik. Persyaratan 60 detik akan mengurangi kemungkinan pengosongan dan pengisian ulang secara berurutan saat health check gagal dan lulus secara berurutan.

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 memindahkan 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 batas 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.

Isolasi traffic

Secara default, Cloud Load Balancing menggunakan algoritma WATERFALL_BY_REGION untuk menentukan tujuan traffic pengguna Anda. Dengan WATERFALL_BY_REGION, traffic akan diluapkan ke region lain jika backend di region terdekat dengan pengguna penuh atau tidak responsif. Mengaktifkan isolasi traffic memungkinkan load balancer merutekan traffic hanya ke region yang paling dekat dengan pengguna, meskipun semua backend di region tersebut berjalan pada batas kapasitas yang dikonfigurasi. Mengaktifkan isolasi traffic dapat membantu Anda mencegah kegagalan regional beruntun dan membatasi potensi pemadaman layanan ke satu region.

Isolasi traffic dikonfigurasi sebagai bagian dari kebijakan load balancing layanan. Ada dua mode isolasi yang tersedia:

• NEAREST (default), dengan load balancer (yaitu, GFE lapisan kedua atau proxy Envoy yang menangani koneksi) mengirimkan traffic ke backend di region terdekat dengan pengguna. Jika tidak ada backend yang dikonfigurasi di region terdekat, atau jika backend di region terdekat tidak responsif, traffic akan dirutekan ke region terdekat berikutnya sekaligus mengoptimalkan latensi jaringan. Hal ini berlanjut saat setiap wilayah kehabisan kapasitas penayangan.

  Mode isolasi NEAREST tersedia untuk semua load balencer yang didukung.

• STRICT, dengan load balancer (yaitu, proxy Envoy yang menangani koneksi) hanya mengirimkan traffic ke backend di region yang paling dekat dengan pengguna. Jika tidak ada backend yang dikonfigurasi di region terdekat, atau jika backend di region terdekat tidak responsif dan tidak dapat menyalurkan permintaan, traffic akan dihapus dan permintaan mulai gagal.

  Mode isolasi STRICT hanya tersedia untuk Load Balancer Aplikasi internal lintas region dan Load Balancer Jaringan proxy internal lintas region.

Tanpa isolasi

Diagram berikut menunjukkan perilaku load balancer lintas region saat isolasi traffic tidak diaktifkan.

Terdekat

Diagram berikut menunjukkan perilaku load balancer lintas region saat isolasi traffic diaktifkan dengan mode NEAREST.

Ketat

Diagram berikut menunjukkan perilaku load balancer lintas region saat isolasi traffic diaktifkan dengan mode STRICT.

Perhatikan pertimbangan berikut sebelum Anda mengaktifkan fitur ini:

• Jika backend Anda di suatu region kelebihan beban, load balancer mungkin masih mengirim traffic tambahan ke backend tersebut meskipun backend di region lain dapat menangani traffic. Artinya, backend di setiap region lebih cenderung mengalami kelebihan beban karena traffic tambahan dan Anda perlu merencanakannya dengan tepat.

• Meskipun isolasi diaktifkan, traffic Anda masih dirutekan oleh panel kontrol global. Artinya, masih ada kemungkinan kegagalan global di beberapa region. Untuk isolasi tingkat infrastruktur yang lebih baik, pilih load balancer regional.

Saat mengonfigurasi mode isolasi traffic, Anda juga harus menetapkan tingkat granularitas isolasi ke REGION, yang mencegah overflow traffic lintas region. Jika granularitas tidak dikonfigurasi, isolasi traffic tidak akan diterapkan. Untuk mengetahui detail tentang cara mengaktifkan isolasi traffic, lihat Mengonfigurasi kebijakan load balancing layanan.

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

Resource kebijakan load balancing layanan memungkinkan Anda mengonfigurasi kolom berikut:

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

Untuk menetapkan backend pilihan, lihat Menetapkan backend pilihan.

Buat kebijakan

Gunakan langkah-langkah berikut untuk membuat dan mengonfigurasi kebijakan load balancing layanan.

Menonaktifkan fitur yang dikonfigurasi pada kebijakan

Bagian ini menunjukkan cara mereset atau menonaktifkan fitur yang dikonfigurasi pada kebijakan load balancing layanan.

Mereset algoritma load balancing

Untuk mereset algoritma load balancing, Anda menggunakan perintah berikut untuk menetapkan algoritma load balancing kembali ke WATERFALL_BY_REGION default:

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --load-balancing-algorithm=WATERFALL_BY_REGION \
    --location=global

Mereset nilai minimum failover

Untuk mereset nilai minimum failover, Anda menggunakan perintah berikut untuk menetapkan nilai minimum failover kembali ke 70 detik default:

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --failover-health-threshold=70 \
    --location=global

Menonaktifkan pengosongan kapasitas otomatis

Untuk menonaktifkan pengosongan kapasitas otomatis, Anda dapat menggunakan perintah berikut:

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --no-auto-capacity-drain \
    --location=global

Menonaktifkan isolasi traffic

Untuk menonaktifkan isolasi traffic (Pratinjau), Anda menetapkan kedua parameter konfigurasi isolasi ke UNSPECIFIED seperti yang ditunjukkan dalam perintah berikut:

gcloud beta network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --isolation-config-granularity=UNSPECIFIED \
    --isolation-config-mode=UNSPECIFIED \
    --location=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 compute backend-services add-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

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

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

  name: projects/PROJECT_ID/locations/global/backendServices/BACKEND_SERVICE_NAME
  ...
  - backends
      name: BACKEND_1_NAME
      preference: PREFERRED
      ...
  - backends
      name: BACKEND_2_NAME
      preference: 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 saat mengaktifkan setiap fitur ini.

Algoritma load balancing

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.

Pengosongan kapasitas otomatis

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 bermasalah dan permintaan dapat gagal.

Nilai minimum failover

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.

Backend pilihan

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. 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.

Isolasi traffic

Permintaan yang dikirim ke load balancer internal lintas region Anda gagal

Jika mode isolasi STRICT diaktifkan dan tidak ada backend yang dikonfigurasi di region yang sama dengan load balancer, traffic diperkirakan akan gagal. Jika ini bukan perilaku yang Anda inginkan, pastikan Anda memiliki backend di wilayah tempat Anda ingin traffic dikirim. Atau, tetapkan mode isolasi ke NEAREST agar traffic dapat dirutekan ke region terdekat berikutnya.

Traffic dirutekan dari region terpencil ke region yang lebih dekat

Isolasi permintaan mencegah traffic luapan berbasis kapasitas. Jadi, jika backend Anda sudah kelebihan beban sebelum mengaktifkan fitur ini, traffic mungkin sudah dikirim ke region jarak jauh. Dalam hal ini, mengaktifkan fitur ini dapat menyebabkan traffic ini dirutekan kembali ke region terdekat.

Traffic tidak dialihkan setelah mengaktifkan isolasi traffic

Isolasi permintaan mencegah traffic luapan berbasis kapasitas. Jadi, jika backend Anda di region terdekat tidak kelebihan beban sebelum mengaktifkan fitur ini, kemungkinan region terdekat mampu menangani semua traffic. Dalam hal tersebut, Anda tidak akan melihat perubahan pada rute traffic dalam jangka pendek. Hal ini dapat berubah seiring perubahan volume traffic.

Traffic berpindah saat backend ditambahkan ke atau dihapus dari region

Ini adalah perilaku yang diharapkan karena load balancer mencoba merutekan traffic untuk mengoptimalkan latensi jaringan secara keseluruhan. Oleh karena itu, saat backend baru di-deploy di region yang lebih dekat, load balancer mungkin akan mengirim lebih banyak traffic ke region tersebut. Demikian pula, saat backend dihapus, bergantung pada setelan pengasingan permintaan Anda, load balancer akan mulai mengirim traffic yang meluap ke region yang lebih jauh.

Batasan

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