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 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. Sesuaikan algoritma load balancing yang digunakan untuk menentukan cara traffic didistribusikan dalam region atau zona tertentu.
  • Pengurasan kapasitas otomatis. Aktifkan pengurasan kapasitas otomatis sehingga load balancer dapat menguras traffic dengan cepat dari backend yang tidak sehat.
  • Nilai minimum failover. Tetapkan nilai minimum failover untuk menentukan kapan backend dianggap tidak responsif. Hal ini memungkinkan traffic melakukan failover ke backend lain untuk menghindari backend yang bermasalah.
  • Isolasi traffic. Mencegah kegagalan beruntun dengan membatasi atau melarang luapan traffic lintas region.

• Backend pilihan. Anda dapat menetapkan backend tertentu sebagai backend pilihan. Backend ini harus digunakan secara maksimal 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 pelimpahan 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 yang mendukung mode penyeimbangan. Backend yang didukung diringkas dalam tabel berikut:

Algoritma load balancing

Bagian ini menjelaskan algoritma load balancing yang dapat Anda konfigurasi 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 keseluruhan, semua Front End Google (GFE) di wilayah yang paling dekat dengan pengguna akan mencoba mengisi backend secara proporsional dengan kapasitas target yang dikonfigurasi (dimodifikasi oleh penskala kapasitasnya).

Setiap GFE lapisan kedua lebih memilih untuk memilih instance atau endpoint backend di zona yang sedekat mungkin (ditentukan oleh waktu perjalanan pulang pergi jaringan) dengan 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 diluapkan ke region terdekat berikutnya sambil mengoptimalkan latensi jaringan.

Semprotkan ke wilayah

Algoritma SPRAY_TO_REGION mengubah perilaku individu setiap GFE lapisan kedua sedemikian rupa sehingga setiap GFE lapisan kedua tidak memiliki preferensi untuk memilih instance atau endpoint backend yang berada di zona sedekat mungkin dengan GFE lapisan kedua. Dengan SPRAY_TO_REGION, setiap GFE lapisan kedua mengirim permintaan ke semua instance atau endpoint backend, di semua zona region, tanpa preferensi untuk waktu perjalanan pulang pergi yang lebih singkat antara GFE lapisan kedua dan instance atau endpoint backend.

Seperti WATERFALL_BY_REGION, secara keseluruhan, semua GFE lapisan kedua di region mengisi backend secara proporsional dengan kapasitas target yang dikonfigurasi (dimodifikasi oleh pengubah skala kapasitasnya).

Meskipun SPRAY_TO_REGION memberikan distribusi yang lebih seragam di antara backend di semua zona suatu region, terutama pada kecepatan permintaan yang rendah, distribusi seragam ini memiliki pertimbangan berikut:

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

Waterfall menurut zona

Algoritma WATERFALL_BY_ZONE mengubah perilaku individu setiap GFE lapisan kedua hingga setiap GFE lapisan kedua memiliki preferensi yang sangat kuat untuk memilih instance atau endpoint backend yang berada di zona sedekat mungkin dengan GFE lapisan kedua. Dengan WATERFALL_BY_ZONE, setiap GFE lapisan kedua hanya mengirim permintaan ke instance atau endpoint backend di zona lain dalam region saat GFE lapisan kedua telah mengisi (atau mengisi secara proporsional) instance atau endpoint backend di zona yang paling disukainya.

Seperti WATERFALL_BY_REGION, secara keseluruhan, semua GFE lapisan kedua di region mengisi backend secara proporsional dengan kapasitas target yang dikonfigurasi (dimodifikasi oleh pengubah skala kapasitasnya).

Algoritma WATERFALL_BY_ZONE meminimalkan latensi dengan pertimbangan berikut:

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

Membandingkan algoritma load balancing

Tabel berikut membandingkan berbagai algoritma load balancing.

Pengurasan dan pengurasan otomatis kapasitas

Pengurasan dan pengembalian kapasitas otomatis menggabungkan konsep health check dan kapasitas backend. Dengan pengosongan kapasitas otomatis, health check digunakan sebagai sinyal tambahan untuk menyetel kapasitas backend efektif ke nol. Dengan pengosongan otomatis kapasitas, pemeriksaan kondisi digunakan sebagai sinyal tambahan untuk memulihkan kapasitas backend yang efektif ke nilai sebelumnya.

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

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

Untuk mengaktifkan pengurasan dan pengurasan ulang kapasitas otomatis, lihat Mengonfigurasi kebijakan load balancing layanan.

Pengurasan kapasitas otomatis

Pengurasan kapasitas otomatis menetapkan kapasitas setiap grup instance atau NEG backend kandidat yang dapat dikuras menjadi nol selama rasio grup instance atau NEG backend kandidat yang dapat dikuras 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 penyebut.

Backend kandidat yang dapat dikuras adalah grup instance atau NEG backend yang memiliki kurang dari 25% instance atau endpoint anggotanya yang lulus pemeriksaan kondisi 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 atau NEG backend yang penskala kapasitasnya telah Anda tetapkan ke nol

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

Pengosongan otomatis kapasitas

Pengosongan otomatis kapasitas mengembalikan kapasitas backend ke nilai yang dikontrol oleh penskala kapasitas backend saat 35% atau lebih instance atau endpoint backend lulus pemeriksaan kondisi selama minimal 60 detik. Persyaratan 60 detik mengurangi kemungkinan pengurasan dan pengurasan ulang berurutan saat health check gagal dan berhasil secara berurutan.

Ambang batas failover

Load balancer menentukan distribusi traffic di antara backend secara multi-level. Dalam kondisi stabil, traffic dikirim 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 menjadi tidak responsif dan tidak dapat menangani traffic. Backend ini disebut backend failover. Backend ini biasanya merupakan backend terdekat 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 terlebih dahulu mengalihkan traffic 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 batas failover untuk menentukan kapan harus mulai mengirim traffic ke backend failover. Load balancer mentoleransi kondisi tidak responsif di backend utama hingga batas failover. Setelah itu, traffic 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 disetel terlalu tinggi, tumpahan 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 pengalihan lokal. Setiap Google Front End (GFE) lokal berperilaku secara independen dari yang lain. Anda bertanggung jawab untuk memastikan bahwa backend pengalihan Anda dapat menangani traffic tambahan.

Traffic failover dapat menyebabkan backend kelebihan beban. Meskipun backend tidak berfungsi dengan baik, load balancer mungkin masih mengirimkan traffic ke sana. Untuk mengecualikan backend yang tidak sehat dari kumpulan backend yang tersedia, aktifkan fitur pengurasan kapasitas otomatis.

Isolasi traffic

Secara default, Cloud Load Balancing menggunakan algoritma WATERFALL_BY_REGION untuk memutuskan ke mana traffic pengguna Anda harus dirutekan. Dengan WATERFALL_BY_REGION, traffic akan diluapkan ke region lain jika backend di region terdekat dengan pengguna sudah penuh atau tidak responsif. Dengan mengaktifkan isolasi traffic, load balancer dapat merutekan traffic hanya ke region terdekat 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 kemungkinan pemadaman layanan ke satu region.

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

• TERDEKAT (default), saat load balancer (yaitu, GFE lapisan kedua atau proxy Envoy yang menangani koneksi) 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, maka traffic akan dirutekan ke region terdekat berikutnya sambil mengoptimalkan latensi jaringan. Hal ini akan berlanjut saat setiap wilayah kehabisan kapasitas penayangan.

  Mode isolasi NEAREST tersedia untuk semua load balancer yang didukung .

• STRICT, saat load balancer (yaitu, proxy Envoy yang menangani koneksi) mengirimkan traffic hanya 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 melayani permintaan, traffic akan dihentikan dan permintaan mulai gagal.

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

Tidak ada 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 mengirimkan traffic tambahan ke backend tersebut meskipun backend di region lain dapat menangani traffic. Artinya, backend di setiap region cenderung mengalami kelebihan beban karena traffic tambahan dan Anda harus merencanakan dengan tepat.

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

Saat mengonfigurasi mode isolasi traffic, Anda juga harus menyetel perincian isolasi ke REGION, yang mencegah overflow traffic lintas region. Jika perincian 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 melimpahkan traffic ke backend lain. Traffic apa pun yang melebihi kapasitas yang dikonfigurasi dari backend pilihan akan diarahkan ke backend non-pilihan yang tersisa. Algoritma load balancing kemudian mendistribusikan traffic di antara backend yang tidak disukai 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 menyetel backend pilihan, lihat Menyetel backend pilihan.

Mengonfigurasi kebijakan load balancing layanan

Resource kebijakan load balancing layanan memungkinkan Anda mengonfigurasi kolom berikut:

• Algoritma load balancing
• Pengurasan kapasitas otomatis
• Ambang batas 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 menyetel 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 menyetel 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 pengurasan kapasitas otomatis

Untuk menonaktifkan pengurasan kapasitas otomatis, Anda 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 Anda 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 lebih banyak pilihan klien. Dalam hal ini, pertimbangkan untuk menggunakan algoritma lain seperti WATERFALL_BY_REGION.

Pengurasan 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 pengurasan kapasitas otomatis. Namun, hal ini berarti traffic dapat dikirim ke backend dengan banyak endpoint yang bermasalah dan permintaan dapat gagal.

Ambang batas failover

Traffic dikirim ke backend jarak jauh selama perubahan responsif sementara

Ini adalah perilaku yang dimaksudkan saat nilai minimum failover ditetapkan ke nilai yang tinggi. Jika Anda ingin traffic terus menuju 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

Inilah perilaku yang dimaksudkan saat nilai minimum failover ditetapkan ke nilai yang rendah. Jika endpoint tidak sehat, traffic yang ditujukan untuk endpoint yang tidak sehat ini akan disebarkan ke 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 ke backend yang lebih dekat

Ini adalah perilaku yang dimaksudkan jika backend pilihan Anda lebih jauh daripada backend default Anda. Jika Anda tidak menginginkan perilaku ini, perbarui setelan preferensi untuk setiap backend dengan tepat.

Traffic tidak dikirim ke beberapa backend saat menggunakan backend pilihan

Ini adalah perilaku yang dimaksudkan 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 region tempat Anda ingin traffic dikirim. Atau, setel mode isolasi ke NEAREST sehingga traffic dapat dirutekan ke region terdekat berikutnya.

Traffic dirutekan dari region terpencil ke region yang lebih dekat

Isolasi permintaan mencegah luapan traffic 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 luapan traffic berbasis kapasitas. Jadi, jika backend Anda di region terdekat tidak kelebihan beban sebelum mengaktifkan fitur ini, kemungkinan besar region terdekat dapat menangani semua traffic. Dalam hal ini, 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 suatu region

Hal 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 dapat mengirimkan lebih banyak traffic ke region tersebut. Demikian pula, saat backend dihapus, bergantung pada setelan isolasi permintaan Anda, load balancer akan mulai mengirimkan traffic berlebih ke region yang lebih jauh.

Batasan

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