Anthos 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 sasaran ketersediaan, performa, dan efisiensi biaya Anda dengan sebaik mungkin. Dokumen ini ditujukan untuk pengguna yang memiliki setidaknya pemahaman menengah tentang Cloud Service Mesh dan konsep 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 traffic diseimbangkan ke backend.

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

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

Opsi tambahan berikut tersedia:

Tentukan backend pilihan. Cloud Service Mesh mengirimkan traffic ke MIG atau NEG tersebut sebelum mengirimkan traffic ke backend lain.
Menyiapkan pengosongan 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 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 pemilihan rute 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, status, 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 campuran (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 suatu region

Algoritme 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 kapasitas mereka, yang memberikan perlindungan overload backend. Traffic dikirim melintasi batas zona jika diperlukan agar backend dimuat secara merata dalam region. Meskipun zona lokal untuk klien memiliki kapasitas yang tersisa, ada traffic lintas zona. Setiap permintaan klien dapat tersebar di beberapa MIG zona atau NEG 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 default menurut region mencoba menyeimbangkan penggunaan kapasitas di beberapa MIG atau NEG zonal. 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 di satu zona.

Gunakan algoritma semprot ke region jika Anda ingin klien menyebarkan permintaan mereka ke semua MIG atau NEG di region, yang mengurangi risiko melebihi beban MIG atau NEG di satu zona saat terjadi peningkatan volume traffic yang cepat dan terlokalisir.

Dengan algoritma semprot ke region, jika Anda memiliki dua zona, A dan B, dan ada lonjakan traffic di zona B, traffic akan dibagi di antara kedua zona tersebut. 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 semprot ke region, traffic untuk setiap klien selalu tersebar di antara zona backend dalam suatu region. Hal ini menghasilkan traffic lintas zona yang secara konsisten lebih tinggi meskipun ada kapasitas yang tersisa di zona lokal, dan dapat mengakibatkan area yang lebih besar terpengaruh untuk traffic dari Cloud Service Mesh, jika dua klien Cloud Service Mesh mengirim traffic ke zona yang sama.

Memperluas traffic dari klien Anda ke semua backend di beberapa region

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

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

Perlu diperhatikan bahwa dengan algoritma ini, semua traffic didistribusikan 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 menggunakan setelan urutan menurut zona. Jika beberapa MIG atau NEG dikonfigurasi dalam zona, traffic klien akan dirutekan ke MIG atau NEG terdekat di zona, hingga kapasitas, sebelum mengirim traffic ke MIG atau NEG berikutnya di zona hingga semua kapasitas MIG atau NEG di zona digunakan. Baru setelah itu traffic akan dialihkan 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, 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	Spray to region	Spray to world	Waterfall menurut zona
Penggunaan kapasitas yang seragam dalam region dalam status stabil	Ya	Ya	Ya	Tidak
Penggunaan kapasitas yang seragam di beberapa region dalam status stabil	Tidak	Tidak	Ya	Tidak
Pembagian traffic yang seragam dalam 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 di seluruh zona jika diperlukan.	Ya	Ya	Ya, traffic akan mengisi zona terdekat sesuai kapasitasnya. Kemudian, akan beralih ke zona berikutnya.
Sensitivitas terhadap lonjakan traffic zona lokal	Rata-rata; bergantung pada jumlah traffic yang telah dialihkan untuk menyeimbangkan di seluruh zona.	Lebih rendah; karena lonjakan satu zona akan tersebar di semua zona di region.	Lebih rendah; karena lonjakan satu zona akan tersebar di semua region.	Lebih tinggi; karena lonjakan zona tunggal cenderung 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 layanan backend ditetapkan sebagai pilihan. 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 apa pun yang melebihi kapasitas backend pilihan yang dikonfigurasi akan dirutekan ke backend yang tidak dipilih. Algoritma load balancing mendistribusikan traffic di antara backend yang tidak dipilih.

Salah satu kasus penggunaannya 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 penggunaan komputasi Google Cloud dan tetap memiliki ketahanan untuk secara bertahap melakukan spill atau failover ke Google Cloud jika diperlukan.

Pengosongan kapasitas otomatis

Jika backend tidak sehat, sebaiknya kecualikan 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 responsif untuk mencegah kelebihan beban backend dan mengoptimalkan latensi secara keseluruhan.

Opsi ini mirip dengan menetapkan capacityscalar ke nol. Fitur ini meminta Cloud Service Mesh untuk menskalakan kapasitas backend ke 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.

Saat backend yang dikosongkan otomatis sudah berfungsi kembali, backend tersebut tidak akan dikosongkan lagi jika setidaknya 35% endpoint atau instance berfungsi 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 pengosongan kapasitas otomatis dengan backend pilihan. Jika MIG atau NEG backend lebih disukai dan banyak endpoint di dalamnya tidak sehat, 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 status 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 ini adalah backend terdekat yang masih memiliki beberapa 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 menyertakan kolom, failoverHealthThreshold, yang nilainya dapat disesuaikan untuk mengontrol perilaku failover. Nilai nilai minimum yang Anda tetapkan menentukan kapan traffic dialihkan dari backend utama ke backend failover.

Jika beberapa endpoint di backend utama tidak berfungsi, Cloud Service Mesh tidak selalu langsung mengalihkan traffic. Sebagai gantinya, Cloud Service Mesh mungkin menggeser 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 memutuskan apakah failover dipicu atau tidak. Cloud Service Mesh menoleransi kondisi tidak sehat hingga 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 solusi umum dan saran 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 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 akan melihat Cloud Service Mesh memilih backend dengan latensi RTT terkecil saat mengirim permintaan untuk mengoptimalkan latensi RTT secara keseluruhan.

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

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

Ini adalah perilaku yang diinginkan 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 sehat

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

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

Ini adalah perilaku yang diinginkan 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 yang dipilih akan ditetapkan terlebih dahulu berdasarkan latensi RTT ke backend ini.

Jika Anda lebih suka mengirim traffic ke tempat lain, Anda dapat mengonfigurasi layanan backendnya tanpa backend pilihan atau dengan estimasi 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 lebih banyak pilihan klien. Dalam hal ini, pertimbangkan untuk menggunakan algoritma lain, seperti waterfall menurut wilayah.

Traffic dikirim ke cluster jarak jauh saat kondisi backend berubah

Jika failoverHealthThreshold ditetapkan ke nilai tinggi, ini adalah 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 sehat kelebihan beban saat beberapa endpoint tidak sehat

Jika failoverHealthThreshold ditetapkan ke nilai rendah, ini adalah perilaku yang diinginkan. Jika beberapa endpoint tidak responsif, traffic untuk endpoint tidak responsif ini mungkin tersebar 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 perhatikan saat mengonfigurasi load balancing lanjutan.

Waterfall per zona

Selama peristiwa pemeliharaan transparan, traffic mungkin akan di-load balance untuk sementara di luar zona lokal.
Perhatikan kasus saat beberapa MIG atau NEG sudah mencapai kapasitas, 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 traffic lintas zona yang berkurang.
Zona mungkin dipetakan ke cluster hardware fisik internal yang berbeda-beda dalam pusat data Google; misalnya, karena virtualisasi zona. Dalam hal ini, VM di zona yang sama mungkin tidak dimuat secara merata. Secara umum, latensi secara keseluruhan akan dioptimalkan.

Spray-to-region

Jika endpoint di satu MIG atau NEG mengalami gangguan, konsekuensinya biasanya tersebar di seluruh kumpulan klien yang lebih besar; dengan kata lain, lebih banyak klien mesh yang mungkin terpengaruh, tetapi tidak terlalu parah.
Karena 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 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 menurut region, spray-to-region, waterfall-by-zone) tidak berlaku untuk MIG atau NEG yang dikonfigurasi sebagai backend pilihan.

Pengosongan kapasitas otomatis

Jumlah minimum MIG yang tidak pernah habis 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 habis adalah 50%. Pada 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 tidak dikosongkan setelah pengosongan, setidaknya 35% instance atau endpoint harus dalam kondisi baik. Hal ini diperlukan untuk memastikan bahwa MIG atau NEG tidak berfluktuasi antara status drain dan undrained.
Pembatasan yang sama untuk penskala kapasitas untuk backend yang tidak menggunakan mode penyeimbangan juga berlaku di sini.

Langkah selanjutnya

Untuk petunjuk penyiapan, lihat Menyiapkan load balancing lanjutan.