Cloud Service Mesh dan Traffic Director kini bergabung menjadi Cloud Service Mesh. Untuk mengetahui informasi selengkapnya, lihat ringkasan Cloud Service Mesh.

Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan load balancing lanjutan

Load balancing lanjutan terdiri dari fitur yang memungkinkan Anda menyesuaikan load balancing global dan distribusi traffic untuk memenuhi tujuan ketersediaan, performa, dan efisiensi biaya Anda dengan sebaik-baiknya. Dokumen ini ditujukan bagi pengguna yang setidaknya memiliki pemahaman tingkat menengah tentang konsep Cloud Service Mesh dan load balancing.

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

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

Waterfall menurut wilayah (algoritma default).
Semprotkan ke wilayah.
Semprot ke dunia.
Air terjun berdasarkan zona.

Opsi tambahan berikut tersedia:

Tentukan backend pilihan. Cloud Service Mesh mengirimkan traffic ke MIG atau NEG tersebut sebelum mengirimkan traffic ke backend lainnya.
Menyiapkan pengurasan kapasitas otomatis.
Menyesuaikan perilaku failover.

Sebelum mengonfigurasi opsi load balancing lanjutan, sebaiknya Anda meninjau 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 membuat keputusan load balancing (klik untuk memperbesar)

Pertama, Cloud Service Mesh memilih layanan backend, berdasarkan karakteristik permintaan dan berdasarkan 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 (NEG GCE_VM_IP_PORT)
Grup endpoint jaringan konektivitas hybrid (NEG NON_GCP_PRIVATE_IP_PORT)

Jenis backend berikut tidak didukung untuk load balancing lanjutan:

Grup instance terkelola regional
Grup endpoint jaringan internet (NEG INTERNET_FQDN_PORT)

Kasus penggunaan

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

Menyeimbangkan traffic di seluruh backend dalam satu region

Algoritma load balancing default, waterfall menurut 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 menurut region, backend menerima traffic sesuai dengan kapasitasnya, yang memberikan perlindungan terhadap kelebihan beban backend. Traffic dikirim melintasi batas zona jika diperlukan agar backend tetap dimuat secara merata dalam region. Meskipun zona yang lokal untuk klien memiliki kapasitas yang tersisa, ada traffic lintas zona. Permintaan setiap klien dapat disebarkan di beberapa MIG atau NEG zona di region, yang membantu menjaga beban pada MIG atau NEG tetap seragam saat beban traffic dari klien tidak seragam.

Meningkatkan ketahanan dengan menyebarkan traffic dari klien di seluruh zona

Algoritma waterfall menurut region default mencoba menyeimbangkan penggunaan kapasitas di beberapa MIG atau NEG zonal. Namun, dengan 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 di satu zona.

Gunakan algoritma spray ke region jika Anda ingin klien menyebarkan permintaannya ke semua MIG atau NEG di suatu region, yang mengurangi risiko kelebihan muatan pada MIG atau NEG di satu zona saat terjadi peningkatan volume traffic yang cepat dan terlokalisasi.

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

Perhatikan bahwa saat Anda menggunakan algoritma spray ke region, traffic untuk setiap klien akan selalu didistribusikan di antara zona backend dalam suatu region. Hal ini menghasilkan traffic lintas zona yang secara konsisten lebih tinggi meskipun masih ada kapasitas di zona lokal, dan dapat menghasilkan area yang lebih luas yang terpengaruh untuk traffic dari Cloud Service Mesh, jika dua klien Cloud Service Mesh mengirim traffic ke zona yang sama.

Mendistribusikan traffic dari klien Anda ke semua backend di beberapa region

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

Jika Anda lebih memilih radius penyebaran yang lebih besar, gunakan algoritma semprot ke dunia. Dengan algoritma ini, klien menyebarkan permintaannya ke semua MIG atau NEG di dunia di beberapa region.

Penting untuk diperhatikan bahwa dengan algoritma ini, semua traffic disebarkan ke semua backend secara global. Kueri yang rusak dapat merusak semua backend dalam 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 secara keseluruhan dan mengurangi traffic lintas zona dengan menggunakan setelan waterfall menurut 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 mengirimkan traffic ke MIG atau NEG berikutnya di zona tersebut hingga semua kapasitas MIG atau NEG di zona tersebut digunakan. Baru setelah itu traffic diluapkan 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 diutamakan. Namun, hal ini juga dapat menyebabkan traffic yang tidak merata di seluruh MIG atau NEG dalam suatu region.

Perbandingan algoritma load balancing

Tabel berikut memberikan perbandingan mendetail tentang empat algoritma load balancing Cloud Service Mesh.

Perilaku	Waterfall menurut wilayah	Semprotkan ke wilayah	Spray to world	Waterfall menurut zona
Penggunaan kapasitas seragam dalam suatu region dalam kondisi stabil	Ya	Ya	Ya	Tidak
Penggunaan kapasitas seragam di beberapa region dalam kondisi stabil	Tidak	Tidak	Ya	Tidak
Pemisahan traffic seragam dalam suatu region dalam kondisi stabil	Tidak	Ya	Ya	Tidak
Traffic lintas zona	Ya. Algoritma ini akan mendistribusikan traffic secara merata di seluruh zona dalam suatu region sambil mengoptimalkan latensi jaringan. Traffic dapat dikirim ke seluruh zona jika diperlukan.	Ya	Ya	Ya, traffic akan mengisi zona terdekat hingga kapasitasnya penuh. Kemudian, mobil akan masuk ke zona berikutnya.
Sensitivitas terhadap lonjakan traffic zona lokal	Rata-rata; bergantung pada seberapa banyak traffic yang sudah dialihkan untuk menyeimbangkan di seluruh zona.	Lebih rendah; karena lonjakan zona tunggal akan didistribusikan ke semua zona di region.	Lebih rendah; karena lonjakan zona tunggal akan tersebar di semua region.	Lebih tinggi; karena lonjakan zona tunggal lebih mungkin ditayangkan 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 dari layanan backend ditetapkan sebagai pilihan. Backend ini digunakan sepenuhnya 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 yang dikonfigurasi dari backend pilihan akan dirutekan ke backend non-pilihan. Algoritma load balancing mendistribusikan traffic di antara backend yang tidak disukai.

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

Pengurasan kapasitas otomatis

Jika backend tidak berfungsi dengan baik, sebaiknya backend tersebut dikeluarkan secepat mungkin dari keputusan load balancing. Mengecualikan backend akan mencegah permintaan dikirim ke backend yang tidak responsif. Selain itu, traffic diseimbangkan di antara backend yang sehat untuk mencegah kelebihan beban backend dan mengoptimalkan latensi secara keseluruhan.

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

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

Salah satu kasus penggunaannya adalah Anda dapat menggunakan pengurasan kapasitas otomatis dengan backend pilihan. Jika MIG atau NEG backend lebih disukai dan banyak endpoint di dalamnya tidak sehat, setelan ini 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 kondisi stabil, Cloud Service Mesh mengirim traffic ke backend yang dipilih berdasarkan algoritma yang dibahas sebelumnya. Backend yang dipilih dianggap optimal dalam hal latensi dan pemanfaatan kapasitas. Backend ini 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. Biasanya backend terdekat yang memiliki sisa kapasitas.

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

Resource serviceLbPolicy mencakup 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 sehat, Cloud Service Mesh tidak serta-merta mengalihkan traffic dengan segera. Sebagai gantinya, Cloud Service Mesh dapat 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, ambang batas kegagalan digunakan untuk memutuskan apakah failover dipicu atau tidak. Cloud Service Mesh mentoleransi kondisi tidak sehat hingga mencapai nilai minimum, lalu mengalihkan sebagian traffic dari backend utama ke backend failover.

Ambang batas 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 umum untuk pemecahan masalah dan mitigasi.

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

Kemudian, traffic akan ditetapkan berdasarkan algoritma yang Anda gunakan. Misalnya, dengan algoritma WATERFALL_BY_ZONE, Cloud Service Mesh mencoba mempertahankan traffic ke zona terdekat. Jika Anda memeriksa metrik jaringan, Anda akan melihat bahwa 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.

Traffic dikirim ke MIG atau NEG yang lebih jauh sebelum yang lebih dekat

Inilah 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 tidak sehat

Ini adalah perilaku yang dimaksudkan saat MIG atau NEG dikuras karena autoCapacityDrain dikonfigurasi. Dengan setelan ini, MIG atau NEG dengan banyak endpoint yang tidak sehat akan dihapus dari keputusan load balancing dan dengan demikian akan dihindari. Jika perilaku ini tidak diinginkan, Anda dapat menonaktifkan setelan autoCapacityDrain. Namun, perhatikan bahwa hal ini berarti traffic dapat dikirim ke MIG atau NEG dengan banyak endpoint yang tidak sehat dan dengan demikian permintaan dapat gagal dengan error.

Traffic tidak dikirim ke beberapa MIG atau NEG saat beberapa MIG atau NEG lebih disukai

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 tanpa backend pilihan atau dengan perkiraan kapasitas yang lebih konservatif untuk MIG atau NEG pilihan.

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

Ini adalah perilaku yang dimaksudkan jika spray-to-region atau spray-to-world digunakan. Namun, Anda mungkin mengalami masalah dengan distribusi traffic yang lebih luas. Misalnya, rasio hit cache mungkin berkurang karena backend melihat traffic dari pilihan klien yang lebih luas. Dalam hal ini, pertimbangkan untuk menggunakan algoritma lain, seperti waterfall menurut wilayah.

Traffic dikirim ke cluster jarak jauh saat status respons backend berubah

Jika failoverHealthThreshold ditetapkan ke nilai yang tinggi, inilah perilaku yang diinginkan. Jika Anda ingin traffic tetap berada di backend utama saat ada perubahan respons sementara, tetapkan failoverHealthThreshold ke nilai yang lebih rendah.

Endpoint yang responsif kelebihan beban saat beberapa endpoint tidak responsif

Jika failoverHealthThreshold ditetapkan ke nilai yang rendah, ini adalah perilaku yang diinginkan. Jika beberapa endpoint tidak responsif, traffic untuk endpoint yang tidak responsif ini mungkin disebarkan di antara endpoint yang tersisa dalam 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 transparan, traffic mungkin akan di-load balance sementara di luar zona lokal.
Mungkin ada kasus saat beberapa MIG atau NEG mencapai kapasitasnya, sementara MIG atau NEG lain di region 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 dapat dipetakan ke cluster hardware fisik internal yang berbeda 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.

Sebar ke wilayah

Jika endpoint di satu MIG atau NEG tidak berfungsi, konsekuensinya biasanya tersebar di sejumlah besar klien; dengan kata lain, sejumlah besar klien mesh 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 (berurutan menurut region, kirim ke region, berurutan menurut zona) tidak berlaku untuk MIG atau NEG yang dikonfigurasi sebagai backend pilihan.

Baterai cepat habis secara otomatis

Jumlah minimum MIG yang tidak pernah dikuras berbeda dengan nilai yang ditetapkan saat dikonfigurasi menggunakan serviceLbPolicies.
Secara default, jumlah minimum MIG yang tidak pernah dikuras adalah 1.
Jika serviceLbPolicies disetel, persentase minimum MIG atau NEG yang tidak pernah dikuras adalah 50%. Dalam kedua konfigurasi tersebut, MIG atau NEG ditandai sebagai tidak sehat jika kurang dari 25% instance atau endpoint di MIG atau NEG dalam kondisi sehat.
Agar MIG atau NEG dapat menghentikan pengurasan setelah pengurasan, setidaknya 35% instance atau endpoint harus dalam kondisi baik. Hal ini diperlukan untuk memastikan bahwa MIG atau NEG tidak berayun antara status terkuras dan tidak terkuras.
Pembatasan yang sama untuk penskala kapasitas untuk backend yang tidak menggunakan mode penyeimbangan juga berlaku di sini.

Langkah berikutnya

Untuk mengetahui petunjuk penyiapan, lihat Menyiapkan load balancing lanjutan.