Ringkasan load balancing lanjutan

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Untuk informasi tentang akses ke rilis ini, lihat halaman permintaan akses.

Load balancing lanjutan terdiri dari fitur-fitur yang dapat Anda gunakan untuk meningkatkan kualitas load balancing dan distribusi traffic global agar memenuhi sasaran ketersediaan, performa, dan efisiensi biaya Anda secara optimal. Dokumen ini ditujukan untuk pengguna yang setidaknya memiliki pemahaman menengah tentang konsep Cloud Service Mesh dan load balancing.

Catatan: Panduan ini hanya mendukung Cloud Service Mesh dengan Google Cloud API dan tidak mendukung Istio API. Untuk mengetahui informasi selengkapnya, lihat ringkasan Cloud Service Mesh.

Untuk menerapkan load balancing lanjutan, buat kebijakan load balancing layanan (resource serviceLbPolicies), yang berisi nilai yang memengaruhi pemilihan backend. Kemudian, Anda akan memasang kebijakan load balancing layanan ke layanan backend. Kebijakan load balancing layanan menentukan algoritma yang digunakan untuk menentukan cara traffic diseimbangkan ke backend.

Anda dapat memilih dari opsi algoritma berikut untuk load balancing lanjutan:

• Waterfall menurut wilayah (algoritma default).
• Semprot ke wilayah.
• Semprot ke seluruh dunia.
• Waterfall berdasarkan zona.

Tersedia opsi tambahan berikut:

• Menentukan backend yang diinginkan. Cloud Service Mesh mengirimkan traffic ke MIG atau NEG tersebut sebelum mengirimkan traffic ke backend lain.
• Siapkan pengosongan kapasitas otomatis.
• Sesuaikan perilaku failover.

Sebelum mengonfigurasi opsi load balancing lanjutan, sebaiknya tinjau dokumentasi untuk resource layanan backend.

Cara Cloud Service Mesh merutekan dan melakukan load balancing pada traffic

Diagram berikut menunjukkan cara Cloud Service Mesh memutuskan untuk merutekan traffic.

Cara Cloud Service Mesh mengambil keputusan load balancing (klik untuk memperbesar)

Pertama, Cloud Service Mesh memilih layanan backend, berdasarkan karakteristik permintaan dan aturan perutean di resource Route atau peta URL, bergantung pada API yang digunakan deployment Anda.

Kedua, Cloud Service Mesh memilih MIG atau NEG backend yang terkait dengan layanan backend, berdasarkan lokasi klien, lokasi, kondisi, dan kapasitas MIG atau NEG, serta informasi dalam kebijakan load balancing layanan yang terkait dengan layanan backend.

Terakhir, Cloud Service Mesh memilih instance atau endpoint dalam MIG atau NEG. Pilihan ini didasarkan pada informasi dalam kebijakan load balancing lokalitas di layanan backend.

Backend yang didukung dan tidak didukung

Jenis backend berikut didukung untuk load balancing lanjutan:

• Grup instance tidak terkelola
• Grup instance terkelola (MIG)
• Grup endpoint jaringan zona (GCE_VM_IP_PORT NEG)
• Grup endpoint jaringan konektivitas hybrid (NON_GCP_PRIVATE_IP_PORT NEG)

Jenis backend berikut tidak didukung untuk load balancing lanjutan:

• Grup instance terkelola regional
• Grup endpoint jaringan internet (INTERNET_FQDN_PORT NEGs)

Kasus penggunaan

Bagian berikut menjelaskan cara kerja setiap algoritma dan mana yang harus dipilih untuk kebutuhan bisnis Anda.

Menyeimbangkan traffic di berbagai backend dalam satu region

Algoritma load balancing default, yang menggunakan waterfall berdasarkan region, mendistribusikan traffic secara merata di semua MIG atau NEG di zona dalam suatu region. Sebaiknya gunakan algoritma default kecuali jika Anda memiliki persyaratan khusus.

Dengan waterfall berdasarkan region, backend menerima traffic secara proporsional dengan kapasitasnya, yang memberikan perlindungan overload backend. Traffic dikirim ke seluruh batas zona jika diperlukan untuk menjaga backend dimuat secara merata di dalam region. Meskipun zona lokal ke klien memiliki kapasitas yang tersisa, masih ada traffic lintas zona. Permintaan setiap klien dapat tersebar di beberapa MIG atau NEG zona di suatu region, yang membantu menjaga beban pada seragam MIG atau NEG saat beban traffic dari klien tidak seragam.

Meningkatkan ketahanan dengan menyebarkan traffic dari klien di seluruh zona

Waterfall default berdasarkan algoritme region mencoba menyeimbangkan penggunaan kapasitas di berbagai MIG atau NEG zona. Namun, berdasarkan algoritma tersebut, permintaan yang berasal dari satu klien tidak dikirim secara konsisten ke semua zona, dan permintaan dari satu klien biasanya dirutekan ke MIG atau NEG dalam satu zona.

Gunakan algoritme spray to region jika Anda ingin klien menyebarkan permintaan mereka ke semua MIG atau NEG di suatu region, sehingga mengurangi risiko kelebihan beban MIG atau NEG di satu zona saat terjadi peningkatan volume traffic yang dilokalkan dan cepat.

Dengan algoritme semprot ke region, jika Anda memiliki dua zona, A dan B, dan ada lonjakan traffic di zona B, traffic akan dibagi di antara dua zona. Dengan algoritma default, lonjakan pada zona B dapat memicu kelebihan beban di zona sebelum Cloud Service Mesh dapat merespons perubahan tersebut.

Perhatikan bahwa saat Anda menggunakan algoritme semprot ke region, traffic untuk setiap klien selalu tersebar di antara zona backend dalam suatu region. Hal ini secara konsisten menghasilkan traffic lintas zona yang lebih tinggi bahkan saat ada kapasitas yang tersisa di zona lokal. Hal ini dapat mengakibatkan area yang terpengaruh lebih besar untuk traffic dari Cloud Service Mesh, jika dua klien Cloud Service Mesh mengirim traffic ke zona yang sama.

Menyebarkan traffic dari klien Anda di semua backend di beberapa region

Seperti yang telah dibahas di bagian sebelumnya, algoritma semprot ke region menyebarkan traffic dari setiap klien ke semua zona di suatu region. Untuk layanan yang memiliki MIG atau NEG di beberapa region, Cloud Service Mesh tetap mengoptimalkan latensi keseluruhan dengan mengirimkan traffic ke region terdekat.

Jika Anda menginginkan radius penyebaran yang lebih besar, gunakan algoritme semprot ke dunia. Dengan algoritma ini, klien menyebarkan permintaan mereka ke semua MIG atau NEG di seluruh dunia di berbagai region.

Penting untuk diperhatikan bahwa dengan algoritma ini, semua traffic akan disebarkan ke semua backend secara global. Kueri yang rusak dapat merusak semua backend di deployment Anda. Algoritma ini juga menghasilkan lebih banyak traffic lintas region, yang dapat meningkatkan latensi permintaan dan menimbulkan biaya tambahan.

Meminimalkan traffic lintas zona

Anda dapat mengoptimalkan latensi keseluruhan dan mengurangi traffic lintas zona menggunakan waterfall menurut setelan zona. Jika beberapa MIG atau NEG dikonfigurasi dalam satu zona, traffic klien akan dirutekan ke MIG atau NEG terdekat di zona tersebut, hingga kapasitasnya, sebelum mengirim traffic ke MIG atau NEG berikutnya di zona tersebut hingga semua kapasitas MIG atau NEG di zona tersebut habis digunakan. Setelah itu barulah lalu lintas data ditumpahkan ke zona terdekat berikutnya.

Dengan algoritma ini, Anda dapat meminimalkan traffic lintas zona yang tidak perlu. Latensi keseluruhan mungkin sedikit meningkat karena backend lokal terdekat lebih disukai. Namun, tindakan ini juga dapat menyebabkan traffic yang tidak merata di seluruh MIG atau NEG dalam suatu wilayah.

Perbandingan algoritma load balancing

Tabel berikut memberikan perbandingan terperinci dari empat algoritma load balancing Cloud Service Mesh.

Perilaku	Waterfall menurut wilayah	Semprot ke wilayah	Semprot ke dunia	Waterfall menurut zona
Penggunaan kapasitas yang seragam dalam suatu region dalam keadaan stabil	Ya	Ya	Ya	Tidak
Penggunaan kapasitas yang seragam di beberapa region dalam status stabil	Tidak	Tidak	Ya	Tidak
Pemisahan traffic yang seragam dalam suatu region dalam status stabil	Tidak	Ya	Ya	Tidak
Traffic lintas zona	Ya. Algoritma ini akan mendistribusikan traffic secara merata di seluruh zona dalam suatu region sekaligus mengoptimalkan latensi jaringan. Traffic dapat dikirim ke berbagai zona jika diperlukan.	Ya	Ya	Ya, traffic akan mengisi zona terdekat sesuai kapasitasnya. Kemudian akan menuju ke zona berikutnya.
Sensitivitas terhadap lonjakan traffic zona lokal	Rata-rata; bergantung pada seberapa banyak traffic yang telah dialihkan untuk menyeimbangkan lintas zona.	Lebih rendah; karena lonjakan zona tunggal akan tersebar di semua zona di region.	Lebih rendah; karena lonjakan zona tunggal akan tersebar di semua region.	Lebih tinggi; karena lonjakan zona tunggal cenderung akan disalurkan sepenuhnya oleh satu zona hingga Cloud Service Mesh dapat bereaksi.

Opsi load balancing lanjutan tambahan

Bagian berikut membahas opsi untuk mengubah load balancing Cloud Service Mesh.

Backend pilihan

Anda dapat mengonfigurasi load balancing sehingga grup backend layanan backend ditetapkan sebagai lebih disarankan. Backend ini sepenuhnya digunakan sebelum permintaan berikutnya dirutekan ke backend yang tersisa. Cloud Service Mesh mendistribusikan traffic klien ke backend pilihan terlebih dahulu, sehingga meminimalkan latensi permintaan untuk klien Anda.

Traffic yang melebihi kapasitas backend pilihan yang dikonfigurasi akan dirutekan ke backend yang tidak diinginkan. Algoritma load balancing mendistribusikan traffic di antara backend yang tidak dipilih.

Salah satu kasus penggunaan adalah overflow ke Google Cloud, tempat Anda menentukan resource komputasi lokal, yang diwakili oleh NEG konektivitas hybrid, untuk digunakan sepenuhnya sebelum permintaan dirutekan ke MIG atau NEG backend Google Cloud yang diskalakan secara otomatis. Konfigurasi ini dapat meminimalkan konsumsi komputasi Google Cloud dan masih memiliki ketahanan untuk beralih atau failover secara bertahap ke Google Cloud jika diperlukan.

Pengurasan kapasitas otomatis

Jika backend tidak responsif, sebaiknya kecualikan secepat mungkin dari pengambilan keputusan load balancing. Mengecualikan backend akan mencegah permintaan dikirim ke backend yang tidak responsif. Selain itu, traffic diseimbangkan di antara backend yang responsif untuk mencegah overload backend dan mengoptimalkan latensi secara keseluruhan.

Opsi ini mirip dengan menetapkan capacityscalar ke nol. Proses ini meminta Cloud Service Mesh untuk menurunkan kapasitas backend ke nol secara otomatis saat backend memiliki kurang dari 25% setiap instance atau endpoint-nya yang lulus health check. Dengan opsi ini, backend yang tidak responsif akan dihapus dari load balancing global.

Jika backend yang dihabiskan secara otomatis kembali responsif, backend tersebut tidak akan digunakan lagi jika setidaknya 35% endpoint atau instance responsif selama 60 detik. Cloud Service Mesh tidak menghabiskan lebih dari 50% endpoint dalam layanan backend, terlepas dari status respons backend.

Salah satu kasus penggunaannya adalah Anda dapat menggunakan pengurangan kapasitas otomatis dengan backend pilihan. Jika MIG atau NEG backend lebih dipilih dan banyak endpoint di dalamnya tidak responsif, setelan ini akan melindungi endpoint yang tersisa di MIG atau NEG dengan mengalihkan traffic dari MIG atau NEG.

Menyesuaikan perilaku failover

Cloud Service Mesh biasanya mengirimkan traffic ke backend dengan mempertimbangkan beberapa faktor. Dalam keadaan stabil, Cloud Service Mesh akan mengirimkan traffic ke backend yang dipilih berdasarkan algoritma yang dibahas sebelumnya. Backend yang dipilih dianggap optimal dalam hal latensi dan penggunaan kapasitas. Mereka disebut backend utama.

Cloud Service Mesh juga melacak backend yang akan digunakan saat backend utama tidak responsif dan tidak dapat menerima traffic. Backend ini disebut backend failover. Server tersebut biasanya berada di backend terdekat yang memiliki sisa kapasitas yang dimilikinya.

Jika backend tidak responsif, Cloud Service Mesh akan mencoba menghindari pengiriman traffic ke backend tersebut, dan justru mengalihkan traffic ke backend yang responsif.

Resource serviceLbPolicy menyertakan kolom, failoverHealthThreshold, yang nilainya dapat disesuaikan untuk mengontrol perilaku failover. Nilai minimum yang Anda tetapkan menentukan kapan traffic dialihkan dari backend utama ke backend failover.

Jika beberapa endpoint di backend utama tidak responsif, Cloud Service Mesh tidak selalu mengalihkan traffic dengan segera. Sebagai gantinya, Cloud Service Mesh mungkin mengalihkan traffic ke endpoint yang responsif di backend utama, untuk mencoba menstabilkan traffic.

Jika terlalu banyak endpoint di backend yang tidak responsif, endpoint yang tersisa tidak dapat menangani traffic tambahan. Dalam hal ini, nilai minimum kegagalan digunakan untuk menentukan apakah failover dipicu atau tidak. Cloud Service Mesh menoleransi kondisi tidak responsif hingga batas tertentu, lalu mengalihkan sebagian traffic dari backend utama ke backend failover.

Nilai minimum kondisi failover adalah nilai persentase. Nilai yang Anda tetapkan menentukan kapan Cloud Service Mesh mengarahkan traffic ke backend failover. Anda dapat menetapkan nilai ke bilangan bulat antara 1 dan 99. Nilai default untuk Cloud Service Mesh adalah 70 dengan Envoy dan 50 untuk gRPC tanpa proxy. Nilai yang lebih besar akan memulai failover traffic lebih cepat daripada nilai yang lebih kecil.

Pemecahan masalah

Pola distribusi traffic dapat berubah berdasarkan cara Anda menyiapkan serviceLbPolicy baru dengan layanan backend.

Untuk men-debug masalah traffic, gunakan sistem pemantauan yang ada untuk memeriksa cara traffic mengalir ke backend Anda. Metrik jaringan dan Cloud Service Mesh tambahan dapat membantu Anda memahami cara pengambilan keputusan load balancing. Bagian ini menawarkan saran mitigasi dan pemecahan masalah umum.

Secara keseluruhan, Cloud Service Mesh mencoba menetapkan traffic agar backend tetap berjalan di bawah kapasitas yang dikonfigurasi. Perlu diingat bahwa hal ini tidak dijamin. Anda dapat meninjau dokumentasi untuk layanan backend untuk mengetahui detail selengkapnya.

Kemudian traffic ditetapkan berdasarkan algoritma yang Anda gunakan. Misalnya, dengan algoritma WATERFALL_BY_ZONE, Cloud Service Mesh mencoba mempertahankan traffic ke zona terdekat. Jika memeriksa metrik jaringan, Anda melihat Cloud Service Mesh lebih memilih backend dengan latensi RTT terkecil saat mengirim permintaan untuk mengoptimalkan latensi RTT secara keseluruhan.

Bagian berikut menjelaskan masalah yang mungkin Anda lihat terkait kebijakan load balancing layanan dan setelan backend pilihan.

Lalu lintas dikirim ke MIG atau NEG yang lebih jauh sebelum yang lebih dekat

Ini adalah perilaku yang dimaksudkan saat backend pilihan dikonfigurasi dengan MIG atau NEG yang lebih jauh. Jika Anda tidak menginginkan perilaku ini, ubah nilai di kolom backend pilihan.

Traffic tidak dikirim ke MIG atau NEG yang memiliki banyak endpoint yang tidak responsif

Ini adalah perilaku yang dimaksudkan saat MIG atau NEG dihabiskan karena autoCapacityDrain dikonfigurasi. Dengan setelan ini, MIG atau NEG dengan banyak endpoint yang tidak responsif akan dihapus dari keputusan load balancing sehingga dapat dihindari. Jika perilaku ini tidak diinginkan, Anda dapat menonaktifkan setelan autoCapacityDrain. Namun, perlu diperhatikan bahwa ini berarti traffic dapat dikirim ke MIG atau NEG yang memiliki banyak endpoint tidak responsif, sehingga permintaan mungkin gagal dengan error.

Traffic tidak dikirim ke beberapa MIG atau NEG jika lebih memilih beberapa MIG atau NEG

Ini adalah perilaku yang dimaksudkan jika MIG atau NEG yang dikonfigurasi sebagai pilihan belum mencapai kapasitas.

Jika backend pilihan dikonfigurasi dan belum mencapai batas kapasitasnya, traffic tidak akan dikirim ke MIG atau NEG lain. MIG atau NEG pilihan akan ditetapkan terlebih dahulu berdasarkan latensi RTT ke backend ini.

Jika ingin traffic dikirim ke tempat lain, Anda dapat mengonfigurasi layanan backend mereka tanpa backend pilihan atau dengan estimasi kapasitas yang lebih konservatif untuk MIG atau NEG yang diinginkan.

Traffic dikirim ke terlalu banyak MIG atau NEG yang berbeda dari satu sumber

Ini adalah perilaku yang dimaksudkan jika semprot ke wilayah atau semprot ke dunia digunakan. Namun, Anda mungkin mengalami masalah dengan distribusi traffic yang lebih luas. Misalnya, rasio cache ditemukan dapat berkurang karena backend melihat traffic dari pilihan klien yang lebih luas. Dalam hal ini, pertimbangkan untuk menggunakan algoritma lain, seperti waterfall berdasarkan region.

Traffic dikirim ke cluster jarak jauh saat kondisi backend berubah

Jika failoverHealthThreshold disetel ke nilai tinggi, ini adalah perilaku yang diinginkan. Jika Anda ingin traffic tetap berada di backend utama saat ada perubahan kondisi sementara, tetapkan failoverHealthThreshold ke nilai yang lebih rendah.

Endpoint yang responsif kelebihan beban saat beberapa endpoint tidak responsif

Jika failoverHealthThreshold disetel ke nilai rendah, ini adalah perilaku yang diinginkan. Jika beberapa endpoint tidak responsif, traffic untuk endpoint yang tidak responsif ini mungkin menyebar di antara endpoint yang tersisa di MIG atau NEG yang sama. Jika Anda ingin perilaku failover dipicu lebih awal, tetapkan failoverHealthThreshold ke nilai yang lebih tinggi.

Batasan dan pertimbangan

Berikut adalah batasan dan pertimbangan yang harus Anda ketahui saat mengonfigurasi load balancing lanjutan.

Waterfall menurut zona

• Selama peristiwa pemeliharaan yang transparan, traffic akan diseimbangkan untuk sementara di luar zona lokal.

• Kemungkinan terjadi kasus saat beberapa MIG atau NEG mencapai kapasitasnya, sementara MIG atau NEG lain di wilayah yang sama kurang dimanfaatkan.

• Jika sumber traffic ke layanan Anda berada di zona yang sama dengan endpoint-nya, Anda akan melihat penurunan traffic lintas zona.

• Zona mungkin dipetakan ke berbagai cluster hardware fisik internal dalam pusat data Google; misalnya, karena virtualisasi zona. Dalam hal ini, VM di zona yang sama mungkin tidak dimuat secara merata. Secara umum, latensi keseluruhan akan dioptimalkan.

Semprot ke region

• Jika endpoint dalam satu MIG atau NEG tidak aktif, konsekuensinya biasanya menyebar ke seluruh kumpulan klien yang lebih besar. Dengan kata lain, jumlah klien mesh yang lebih besar mungkin terpengaruh, tetapi tidak terlalu parah.

• Saat klien mengirim permintaan ke semua MIG atau NEG di region, dalam beberapa kasus, hal ini dapat meningkatkan jumlah traffic lintas zona.

• Jumlah koneksi yang dibuka ke endpoint dapat meningkat, sehingga menyebabkan peningkatan penggunaan resource.

Backend pilihan

• MIG atau NEG yang dikonfigurasi sebagai backend pilihan mungkin berada jauh dari klien dan dapat menyebabkan latensi rata-rata yang lebih tinggi untuk klien. Hal ini dapat terjadi meskipun ada MIG atau NEG lain yang dapat melayani klien dengan latensi yang lebih rendah.

• Algoritma load balancing global (waterfall berdasarkan region, spray-to-region, waterfall-by-zone) tidak berlaku untuk MIG atau NEG yang dikonfigurasi sebagai backend pilihan.

Pengurasan kapasitas otomatis

• Jumlah minimum MIG yang tidak pernah dihabiskan berbeda dengan nilai yang ditetapkan saat dikonfigurasi menggunakan serviceLbPolicies.

• Secara default, jumlah minimum MIG yang tidak pernah habis adalah 1.

• Jika serviceLbPolicies ditetapkan, persentase minimum MIG atau NEG yang tidak pernah terkuras adalah 50%. Berdasarkan kedua konfigurasi tersebut, MIG atau NEG ditandai sebagai tidak sehat jika kurang dari 25% instance atau endpoint dalam MIG atau NEG sehat.

• Agar MIG atau NEG tidak dapat habis setelah pengosongan, setidaknya 35% instance atau endpoint harus responsif. Hal ini diperlukan untuk memastikan MIG atau NEG tidak bingung antara kondisi terkuras dan tidak terproses.

• Pembatasan yang sama untuk penskalaan kapasitas bagi backend yang tidak menggunakan mode penyeimbangan juga berlaku di sini.

Langkah selanjutnya

• Untuk mengetahui petunjuk penyiapan, lihat Menyiapkan load balancing lanjutan.