Ringkasan layanan backend

Layanan backend menentukan cara Cloud Load Balancing mendistribusikan traffic. Konfigurasi layanan backend berisi kumpulan nilai, seperti protokol yang digunakan untuk terhubung ke backend, berbagai setelan sesi dan distribusi, health check, serta waktu tunggu. Setelan ini memberikan kontrol terperinci terkait perilaku load balancer. Untuk memulai, sebagian besar setelan memiliki nilai default yang memungkinkan konfigurasi cepat. Layanan backend tercakup dalam cakupan global atau regional.

Load balancer, proxy Envoy, dan klien gRPC tanpa proxy menggunakan informasi konfigurasi di resource layanan backend untuk melakukan hal berikut:

• Mengarahkan traffic ke backend yang benar, yang merupakan grup instance atau grup endpoint jaringan (NEG).
• Distribusikan traffic sesuai dengan mode penyeimbangan, yang merupakan setelan untuk setiap backend.
• Menentukan health check mana yang memantau kondisi backend.
• Tentukan afinitas sesi.
• Menentukan apakah layanan lainnya diaktifkan atau tidak, termasuk layanan berikut yang hanya tersedia untuk load balancing tertentu:
  • Cloud CDN
  • Kebijakan keamanan Google Cloud Armor
  • Identity-Aware Proxy
• Tetapkan layanan backend regional sebagai layanan di Pusat Aplikasi, yang sedang dalam pratinjau.

Anda menetapkan nilai ini saat membuat layanan backend atau menambahkan backend ke layanan backend.

Catatan: Jika Anda menggunakan Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik, dan backend Anda menayangkan konten statis, sebaiknya gunakan bucket backend, bukan layanan backend.

Tabel berikut meringkas load balancer mana yang menggunakan layanan backend. Produk yang Anda gunakan juga menentukan jumlah maksimum layanan backend, cakupan layanan backend, jenis backend yang didukung, dan skema load balancing layanan backend. Skema load balancing adalah ID yang digunakan Google untuk mengklasifikasikan aturan penerusan dan layanan backend. Setiap produk load balancing menggunakan satu skema load balancing untuk aturan penerusan dan layanan backend-nya. Beberapa skema dibagikan di antara produk.

Tabel: Layanan backend dan jenis backend yang didukung

Produk	Jumlah maksimum layanan backend	Cakupan layanan backend	Jenis backend yang didukung	Skema load balancing
Load Balancer Aplikasi eksternal global	Beberapa	Global	Setiap layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance yang terkelola, tidak terkelola, atau kombinasi dari backend grup instance yang terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT ^2 Semua NEG serverless: Satu atau beberapa layanan App Engine, Cloud Run, atau Cloud Functions NEG Private Service Connect: Jika lebih dari satu NEG ditentukan, NEG harus berada di wilayah yang berbeda Satu NEG internet global untuk backend eksternal	EXTERNAL_MANAGED
Load Balancer Aplikasi Klasik	Beberapa	Global^1	Setiap layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance yang terkelola, tidak terkelola, atau kombinasi dari backend grup instance yang terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT ^2 Semua NEG serverless: Satu atau beberapa layanan App Engine, Cloud Run, atau Cloud Functions, atau Satu NEG internet global untuk backend eksternal	EKSTERNAL
Load Balancer Aplikasi eksternal regional	Beberapa	Regional	Setiap layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance yang terkelola, tidak terkelola, atau kombinasi dari backend grup instance yang terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT ^2 Satu NEG serverless (khusus Cloud Run) Satu NEG Private Service Connect Semua NEG internet regional untuk backend eksternal	EXTERNAL_MANAGED
Load Balancer Aplikasi internal lintas region	Beberapa	Global	Setiap layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance yang terkelola, tidak terkelola, atau kombinasi dari backend grup instance yang terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT ^2 Satu NEG serverless (khusus Cloud Run) Satu NEG Private Service Connect	INTERNAL_MANAGED
Load Balancer Aplikasi internal regional	Beberapa	Regional	Setiap layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance yang terkelola, tidak terkelola, atau kombinasi dari backend grup instance yang terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT ^2 Satu NEG serverless (khusus Cloud Run) Satu NEG Private Service Connect Semua NEG internet regional untuk backend eksternal	INTERNAL_MANAGED
Load Balancer Jaringan proxy eksternal global	1	Global	Layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance yang terkelola, tidak terkelola, atau kombinasi dari backend grup instance yang terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT ^2	EXTERNAL_MANAGED
Load Balancer Jaringan proxy klasik	1	Global^1	Layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance yang terkelola, tidak terkelola, atau kombinasi dari backend grup instance yang terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT ^2	EKSTERNAL
Load Balancer Jaringan proxy eksternal regional	1	Regional	Layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance yang terkelola, tidak terkelola, atau kombinasi dari backend grup instance yang terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan campuran: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT Semua NEG internet regional untuk backend eksternal	EXTERNAL_MANAGED
Load Balancer Jaringan proxy internal regional	1	Regional	Layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance yang terkelola, tidak terkelola, atau kombinasi dari backend grup instance yang terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan campuran: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT Semua NEG internet regional untuk backend eksternal	INTERNAL_MANAGED
Load Balancer Jaringan proxy internal lintas region	Beberapa	Global	Layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance yang terkelola, tidak terkelola, atau kombinasi dari backend grup instance yang terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan campuran: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT	INTERNAL_MANAGED
Load Balancer Jaringan passthrough eksternal	1	Regional	Layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance yang terkelola, tidak terkelola, atau kombinasi dari backend grup instance yang terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP	EKSTERNAL
Load Balancer Jaringan passthrough internal	1	Regional, tetapi dapat dikonfigurasi agar dapat diakses secara global	Layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance yang terkelola, tidak terkelola, atau kombinasi dari backend grup instance yang terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP	INTERNAL
Traffic Director	Beberapa	Global	Setiap layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance yang terkelola, tidak terkelola, atau kombinasi dari backend grup instance yang terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT atau NON_GCP_PRIVATE_IP_PORT Satu NEG internet jenis INTERNET_FQDN_PORT Satu atau beberapa binding layanan	INTERNAL_SELF_MANAGED

¹ Layanan backend yang digunakan oleh Load Balancer Aplikasi klasik dan Load Balancer Jaringan proxy klasik selalu memiliki cakupan global, baik dalam Paket Jaringan Standar maupun Premium. Namun, pada Paket Standar, pembatasan berikut berlaku:

• Aturan penerusan dan alamat IP eksternalnya bersifat regional.
• Semua backend yang terhubung ke layanan backend harus ditempatkan di region yang sama dengan aturan penerusan.

² Untuk deployment GKE, backend NEG campuran hanya didukung dengan NEG mandiri.

Backend

Backend adalah satu atau beberapa endpoint yang menerima traffic dari load balancer Google Cloud, proxy Envoy yang dikonfigurasi Traffic Director, atau klien gRPC tanpa proxy. Ada beberapa jenis backend:

• Grup instance yang berisi instance virtual machine (VM). Grup instance dapat berupa grup instance terkelola (MIG), dengan atau tanpa penskalaan otomatis, atau dapat berupa grup instance yang tidak dikelola. Lebih dari satu layanan backend dapat mereferensikan grup instance, tetapi semua layanan backend yang mereferensikan grup instance tersebut harus menggunakan mode penyeimbangan yang sama.
• NEGARA Zona
• NEG Tanpa Server
• NEG Internet
• NEG dengan konektivitas hybrid
• NEG Private Service Connect
• Binding layanan Direktori Layanan

Anda tidak dapat menghapus grup instance backend atau NEG yang terkait dengan layanan backend. Sebelum menghapus grup instance atau NEG, Anda harus terlebih dahulu menghapusnya sebagai backend dari semua layanan backend yang mereferensikannya.

Grup instance

Bagian ini membahas cara kerja grup instance dengan layanan backend.

VM backend dan alamat IP eksternal

VM backend di layanan backend tidak memerlukan alamat IP eksternal:

• Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Jaringan proxy eksternal: Klien berkomunikasi dengan Google Front End (GFE) yang menghosting alamat IP eksternal load balancer Anda. GFE berkomunikasi dengan VM backend atau endpoint dengan mengirimkan paket ke alamat internal yang dibuat dengan menggabungkan ID untuk jaringan VPC backend dengan alamat IPv4 internal backend. Komunikasi antara GFE dan VM backend atau endpoint difasilitasi melalui rute khusus.
  • Untuk backend grup instance, alamat IPv4 internal selalu merupakan alamat IPv4 internal utama yang sesuai dengan antarmuka nic0 VM.
  • Untuk endpoint GCE_VM_IP_PORT di NEG zona, Anda dapat menentukan alamat IP endpoint sebagai alamat IPv4 utama yang terkait dengan antarmuka jaringan VM apa pun, atau alamat IPv4 apa pun dari rentang alamat IP alias yang terkait dengan antarmuka jaringan VM apa pun.

• Untuk Load Balancer Aplikasi eksternal regional: Klien berkomunikasi dengan proxy Envoy yang menghosting alamat IP eksternal load balancer Anda. Proxy Envoy berkomunikasi dengan VM backend atau endpoint dengan mengirimkan paket ke alamat internal yang dibuat dengan menggabungkan ID untuk jaringan VPC backend dengan alamat IPv4 internal backend.

  • Untuk backend grup instance, alamat IPv4 internal selalu merupakan alamat IPv4 internal utama yang sesuai dengan antarmuka nic0 VM, dan nic0 harus berada di jaringan yang sama dengan load balancer.
  • Untuk endpoint GCE_VM_IP_PORT di NEG zona, Anda dapat menentukan alamat IP endpoint sebagai alamat IPv4 utama yang terkait dengan antarmuka jaringan VM apa pun, atau alamat IPv4 apa pun dari rentang alamat IP alias yang terkait dengan antarmuka jaringan VM apa pun, selama antarmuka jaringan berada dalam jaringan yang sama dengan load balancer.

• Untuk Load Balancer Jaringan passthrough eksternal: Klien berkomunikasi langsung dengan backend melalui infrastruktur load balancing passthrough Maglev Google. Paket dirutekan dan dikirim ke backend dengan alamat IP sumber dan tujuan asli yang dipertahankan. Backend merespons klien menggunakan pengembalian server langsung. Metode yang digunakan untuk memilih backend dan melacak koneksi dapat dikonfigurasi.

  • Untuk backend grup instance, paket selalu dikirim ke antarmuka nic0 VM.
  • Untuk endpoint GCE_VM_IP di NEG zona, paket dikirimkan ke antarmuka jaringan VM yang ada di subnetwork yang terkait dengan NEG.

Port yang bernama

Atribut port bernama layanan backend hanya berlaku untuk load balancer proxy yang menggunakan backend grup instance. Port bernama menentukan port tujuan yang digunakan untuk koneksi TCP antara proxy (GFE atau Envoy) dan instance backend.

Port bernama dikonfigurasi sebagai berikut:

• Di setiap backend grup instance, Anda harus mengonfigurasi satu atau beberapa port bernama menggunakan key-value pair. Kunci ini mewakili nama port bermakna yang Anda pilih, dan nilainya mewakili nomor port yang Anda tetapkan pada nama tersebut. Pemetaan nama ke angka dilakukan satu per satu untuk setiap backend grup instance.

• Di layanan backend, Anda menentukan satu port bernama hanya menggunakan nama port (--port-name).

Pada backend grup per-instance, layanan backend menerjemahkan nama port menjadi nomor port. Jika port bernama grup instance cocok dengan --port-name layanan backend, layanan backend akan menggunakan nomor port ini untuk berkomunikasi dengan VM grup instance.

Misalnya, Anda dapat menetapkan port bernama pada grup instance dengan nama my-service-name dan port 8888:

gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
    --named-ports=my-service-name:8888

Kemudian, Anda merujuk ke port yang dinamai dalam konfigurasi layanan backend dengan --port-name pada layanan backend yang disetel ke my-service-name:

gcloud compute backend-services update my-backend-service \
    --port-name=my-service-name

Layanan backend dapat menggunakan nomor port yang berbeda saat berkomunikasi dengan VM dalam grup instance yang berbeda jika setiap grup instance menentukan nomor port yang berbeda untuk nama port yang sama.

Nomor port yang di-resolve dan digunakan oleh layanan backend load balancer proxy tidak harus cocok dengan nomor port yang digunakan oleh aturan penerusan load balancer. Load balancer proxy memproses koneksi TCP yang dikirim ke alamat IP dan port tujuan aturan penerusannya. Karena proxy membuka koneksi TCP kedua ke backend-nya, port tujuan koneksi TCP kedua dapat berbeda.

Port bernama hanya berlaku untuk backend grup instance. NEG Zona dengan endpoint GCE_VM_IP_PORT, NEG campuran dengan endpoint NON_GCP_PRIVATE_IP_PORT, dan NEG internet menentukan port menggunakan mekanisme yang berbeda, yaitu pada endpoint itu sendiri. NEG tanpa server merujuk ke layanan Google dan NEG PSC mereferensikan lampiran layanan menggunakan abstraksi yang tidak melibatkan penentuan port tujuan.

Load Balancer Jaringan passthrough internal dan Load Balancer Jaringan passthrough eksternal tidak menggunakan port yang bernama. Hal ini karena load balancer tersebut adalah load balancer penerusan yang merutekan koneksi langsung ke backend, bukan membuat koneksi baru. Paket dikirimkan ke backend dengan mempertahankan alamat IP tujuan dan port aturan penerusan load balancer.

Untuk mempelajari cara membuat port bernama, lihat petunjuk berikut:

• Grup instance yang tidak terkelola: Bekerja dengan port bernama
• Grup instance terkelola: Menetapkan port bernama ke grup instance terkelola

Batasan dan panduan untuk grup instance

Perhatikan batasan dan panduan berikut saat Anda membuat grup instance untuk load balancer:

• Jangan menempatkan VM di lebih dari satu grup instance dengan load balancing. Jika VM adalah anggota dari dua atau beberapa grup instance yang tidak dikelola, atau anggota dari satu grup instance terkelola dan satu atau beberapa grup instance yang tidak dikelola, Google Cloud akan membatasi Anda agar hanya menggunakan salah satu grup instance tersebut pada satu waktu sebagai backend untuk layanan backend tertentu.

  Jika memerlukan VM untuk berpartisipasi dalam beberapa load balancer, Anda harus menggunakan grup instance yang sama dengan backend di setiap layanan backend.

• Untuk load balancer proxy, jika Anda ingin menyeimbangkan traffic ke port yang berbeda, tentukan port bernama yang diperlukan di satu grup instance dan buat setiap layanan backend berlangganan port bernama unik .

• Anda dapat menggunakan grup instance yang sama sebagai backend untuk lebih dari satu layanan backend. Dalam situasi ini, backend harus menggunakan mode penyeimbangan yang kompatibel. Kompatibel berarti mode penyeimbangan harus sama, atau harus berupa kombinasi CONNECTION dan RATE.

  Kombinasi mode penyeimbangan yang tidak kompatibel adalah sebagai berikut:

  • CONNECTION dengan UTILIZATION
  • RATE dengan UTILIZATION

  Perhatikan contoh berikut:

  • Anda memiliki dua layanan backend: external-https-backend-service untuk Load Balancer Aplikasi eksternal dan internal-tcp-backend-service untuk Load Balancer Jaringan passthrough internal.
  • Anda menggunakan grup instance dengan nama instance-group-a di internal-tcp-backend-service.
  • Di internal-tcp-backend-service, Anda harus menerapkan mode penyeimbangan CONNECTION karena Load Balancer Jaringan passthrough internal hanya mendukung mode penyeimbangan CONNECTION.
  • Anda juga dapat menggunakan instance-group-a di external-https-backend-service jika menerapkan mode penyeimbangan RATE di external-https-backend-service.
  • Anda tidak dapat menggunakan instance-group-a dalam external-https-backend-service dengan mode penyeimbangan UTILIZATION.

• Untuk mengubah mode penyeimbangan grup instance yang berfungsi sebagai backend untuk beberapa layanan backend:

  • Hapus grup instance dari semua layanan backend, kecuali satu layanan.
  • Ubah mode penyeimbangan untuk backend di satu layanan backend yang tersisa.
  • Tambahkan kembali grup instance sebagai backend ke layanan backend yang tersisa, jika layanan tersebut mendukung mode penyeimbangan baru.

• Jika grup instance Anda dikaitkan dengan beberapa layanan backend, setiap layanan backend dapat mereferensikan port dengan nama yang sama atau port dengan nama yang berbeda di grup instance.

• Sebaiknya jangan menambahkan grup instance terkelola dengan penskalaan otomatis ke lebih dari satu layanan backend. Tindakan ini dapat menyebabkan penskalaan instance yang tidak dapat diprediksi dan tidak perlu dalam grup, terutama jika Anda menggunakan metrik penskalaan otomatis HTTP Load Balancing Utilization.

  • Meskipun tidak direkomendasikan, skenario ini dapat berfungsi jika metrik penskalaan otomatis adalah Pemakaian CPU atau Metrik Cloud Monitoring yang tidak terkait dengan kapasitas penayangan load balancer. Penggunaan salah satu metrik penskalaan otomatis ini dapat mencegah penskalaan yang tidak menentu.

Grup endpoint jaringan zona

Endpoint jaringan mewakili layanan berdasarkan alamat IP-nya atau kombinasi alamat IP dan port, bukan merujuk ke VM dalam grup instance. Grup endpoint jaringan (NEG) adalah pengelompokan logis endpoint jaringan.

Grup endpoint jaringan zona (NEG) adalah resource zona yang mewakili kumpulan alamat IP atau alamat IP dan kombinasi port untuk resource Google Cloud dalam satu subnet.

Layanan backend yang menggunakan NEG zona sebagai backend-nya mendistribusikan traffic di antara aplikasi atau container yang berjalan dalam VM.

Ada dua jenis endpoint jaringan yang tersedia untuk NEG zona:

• Endpoint GCE_VM_IP (hanya didukung dengan Load Balancer Jaringan passthrough internal dan Load Balancer Jaringan passthrough eksternal berbasis layanan backend).
• GCE_VM_IP_PORT endpoint.

Untuk melihat produk yang mendukung backend NEG zona, lihat Tabel: Layanan backend dan jenis backend yang didukung.

Untuk mengetahui detailnya, lihat ringkasan NEG Zona.

Grup endpoint jaringan internet

NEG internet adalah resource yang menentukan backend eksternal. Backend eksternal adalah backend yang dihosting di dalam infrastruktur lokal atau di infrastruktur yang disediakan oleh pihak ketiga.

NEG internet adalah kombinasi nama host atau alamat IP, serta port opsional. Ada dua jenis endpoint jaringan yang tersedia untuk NEG internet: INTERNET_FQDN_PORT dan INTERNET_IP_PORT.

NEG Internet tersedia dalam dua cakupan: global dan regional. Untuk melihat produk mana yang mendukung backend NEG internet di setiap cakupan, lihat Tabel: Layanan backend dan jenis backend yang didukung.

Untuk mengetahui detailnya, lihat Ringkasan grup endpoint jaringan internet.

Grup endpoint jaringan tanpa server

Grup endpoint jaringan (NEG) menentukan grup endpoint backend untuk load balancer. NEG serverless adalah backend yang mengarah ke layanan Cloud Run, App Engine, Cloud Functions, atau Gateway API.

NEG serverless dapat mewakili salah satu dari hal berikut:

• Layanan Cloud Run atau grup layanan.
• Fungsi Cloud Functions atau sekelompok fungsi.
• Aplikasi App Engine (Standard atau Flex), layanan tertentu dalam aplikasi, versi aplikasi tertentu, atau grup layanan.
• Gateway API yang menyediakan akses ke layanan Anda melalui REST API yang konsisten di semua layanan, apa pun implementasi layanannya. Kemampuan ini berada dalam Pratinjau.

Penting: Agar sekelompok layanan berada di NEG serverless yang sama, layanan tersebut harus memiliki pola URL yang sama.

Untuk menyiapkan NEG serverless bagi aplikasi serverless yang memiliki pola URL yang sama, gunakan mask URL. Masker URL adalah template skema URL Anda (misalnya, example.com/<service>). NEG serverless akan menggunakan template ini untuk mengekstrak nama <service> dari URL permintaan masuk dan merutekan permintaan ke layanan Cloud Run, Cloud Functions, atau App Engine yang cocok dengan nama yang sama.

Untuk melihat load balancer mana yang mendukung backend NEG serverless, lihat Tabel: Layanan backend dan jenis backend yang didukung.

Untuk mengetahui informasi selengkapnya tentang NEG serverless, baca Ringkasan grup endpoint jaringan Serverless.

Pengikatan layanan

Binding layanan adalah backend yang membuat koneksi antara layanan backend di Traffic Director dan layanan yang terdaftar di Service Directory. Layanan backend dapat mereferensikan beberapa binding layanan. Layanan backend dengan binding layanan tidak dapat mereferensikan jenis backend lainnya.

Backend campuran

Pertimbangan penggunaan berikut berlaku saat Anda menambahkan berbagai jenis backend ke layanan backend tunggal:

• Satu layanan backend tidak dapat menggunakan grup instance dan NEG zona secara bersamaan.
• Anda dapat menggunakan kombinasi jenis grup instance yang berbeda pada layanan backend yang sama. Misalnya, satu layanan backend dapat merujuk kombinasi grup instance terkelola dan tidak terkelola. Untuk mengetahui informasi lengkap tentang backend mana yang kompatibel dengan layanan backend, lihat tabel di bagian sebelumnya.
• Dengan load balancer proxy tertentu, Anda dapat menggunakan kombinasi NEG zona (dengan endpoint GCE_VM_IP_PORT) dan NEG konektivitas hybrid (dengan endpoint NON_GCP_PRIVATE_IP_PORT) untuk mengonfigurasi load balancing hybrid. Untuk melihat load balancer mana yang memiliki kemampuan ini, lihat Tabel: Layanan backend dan jenis backend yang didukung.

Protokol ke backend

Saat membuat layanan backend, Anda harus menentukan protokol yang digunakan untuk berkomunikasi dengan backend. Anda hanya dapat menentukan satu protokol per layanan backend — Anda tidak dapat menentukan protokol sekunder yang akan digunakan sebagai penggantian.

Protokol mana yang valid bergantung pada jenis load balancer atau apakah Anda menggunakan Traffic Director.

Tabel: Protokol ke backend

Produk	Opsi protokol layanan backend
Load Balancer Aplikasi	HTTP, HTTPS, HTTP/2
Load Balancer Jaringan Proxy	TCP atau SSL Load Balancer Jaringan proxy regional hanya mendukung TCP.
Load Balancer Jaringan Passthrough	TCP, UDP, atau UNSPECIFIED
Traffic Director	HTTP, HTTPS, HTTP/2, gRPC, TCP

Mengubah protokol layanan backend akan membuat backend tidak dapat diakses melalui load balancer selama beberapa menit.

Enkripsi antara load balancer dan backend

Untuk informasi tentang enkripsi antara load balancer dan backend, lihat Enkripsi ke backend.

Distribusi traffic

Nilai kolom berikut dalam resource layanan backend menentukan beberapa aspek perilaku backend:

• Mode balancing menentukan cara load balancer mengukur kesiapan backend untuk permintaan atau koneksi baru.
• Kapasitas target menentukan jumlah koneksi maksimum target, kecepatan maksimum target, atau target penggunaan CPU maksimum.
• Penskala kapasitas menyesuaikan keseluruhan kapasitas yang tersedia tanpa mengubah kapasitas target.

Balancing mode

Mode penyeimbangan menentukan apakah backend load balancer atau Traffic Director dapat menangani traffic tambahan atau dimuat sepenuhnya. Google Cloud memiliki tiga mode balancing:

• CONNECTION: Menentukan cara penyebaran beban berdasarkan jumlah total koneksi yang dapat ditangani backend.
• RATE: Jumlah maksimum permintaan (kueri) per detik (RPS, QPS) target. Target RPS/QPS maksimum dapat terlampaui jika semua backend berada pada atau di atas kapasitas.
• UTILIZATION: Menentukan cara penyebaran beban berdasarkan pemakaian instance dalam grup instance.

Mode balancing yang tersedia untuk setiap load balancer

Anda menetapkan mode penyeimbangan saat menambahkan backend ke layanan backend. Mode penyeimbangan yang tersedia untuk load balancer bergantung pada jenis load balancer dan jenis backend.

Load Balancer Jaringan passthrough memerlukan mode penyeimbangan CONNECTION, tetapi tidak mendukung penetapan kapasitas target apa pun.

Load Balancer Aplikasi mendukung mode penyeimbangan RATE atau UTILIZATION untuk backend grup instance, mode penyeimbangan RATE untuk NEG zona dengan endpoint GCE_VM_IP_PORT, dan mode penyeimbangan RATE untuk NEG hybrid (endpoint NON_GCP_PRIVATE_IP_PORT). Untuk jenis backend lain yang didukung, mode penyeimbangan harus dihilangkan.

• Untuk Load Balancer Aplikasi klasik, region dipilih berdasarkan lokasi klien dan apakah region tersebut memiliki kapasitas yang tersedia, berdasarkan kapasitas target mode load balancing. Kemudian, dalam sebuah region, kapasitas target mode penyeimbangan digunakan untuk menghitung proporsi jumlah permintaan yang harus dikirim ke setiap backend di region tersebut. Permintaan atau koneksi kemudian didistribusikan secara round robin di antara instance atau endpoint dalam backend.

• Untuk Load Balancer Aplikasi eksternal global, region dipilih berdasarkan lokasi klien dan apakah region tersebut memiliki kapasitas yang tersedia, berdasarkan kapasitas target mode load balancing. Dalam sebuah region, kapasitas target mode penyeimbangan digunakan untuk menghitung proporsi jumlah permintaan yang harus dikirimkan ke setiap backend (grup instance atau NEG) di region tersebut. Anda dapat menggunakan kebijakan load balancing layanan (serviceLbPolicy) dan setelan backend yang dipilih untuk memengaruhi pemilihan backend tertentu dalam suatu region. Selain itu, dalam setiap grup instance atau NEG, kebijakan load balancing (LocalityLbPolicy) menentukan cara traffic didistribusikan ke instance atau endpoint dalam grup.

• Untuk Load Balancer Aplikasi internal lintas region, Load Balancer Aplikasi eksternal regional,, dan Load Balancer Aplikasi internal regional, kapasitas target mode penyeimbangan digunakan untuk menghitung proporsi jumlah permintaan yang harus dikirimkan ke setiap backend (grup instance atau NEG) di region. Dalam setiap grup instance atau NEG, kebijakan load balancing (LocalityLbPolicy) menentukan cara traffic didistribusikan ke instance atau endpoint dalam grup. Hanya Load Balancer Aplikasi internal lintas region yang mendukung penggunaan kebijakan load balancing layanan (serviceLbPolicy) dan setelan backend yang dipilih untuk memengaruhi pemilihan backend tertentu dalam suatu region.

Load Balancer Jaringan Proxy mendukung mode CONNECTION atau UTILIZATION balancing untuk backend grup instance VM, mode penyeimbangan CONNECTION untuk NEG zona dengan endpoint GCE_VM_IP_PORT, dan mode penyeimbangan CONNECTION untuk NEG hybrid (endpoint NON_GCP_PRIVATE_IP_PORT). Untuk jenis backend lain yang didukung, mode penyeimbangan harus dihilangkan.

• Untuk Load Balancer Jaringan proxy eksternal global, region dipilih berdasarkan lokasi klien dan apakah region tersebut memiliki kapasitas yang tersedia, berdasarkan kapasitas target mode load balancing. Dalam sebuah region, kapasitas target mode penyeimbangan digunakan untuk menghitung proporsi jumlah permintaan yang harus dikirimkan ke setiap backend (grup instance atau NEG) di region tersebut. Anda dapat menggunakan kebijakan load balancing layanan (serviceLbPolicy) dan setelan backend yang dipilih untuk memengaruhi pemilihan backend tertentu dalam suatu region. Selain itu, dalam setiap grup instance atau NEG, kebijakan load balancing (LocalityLbPolicy) menentukan cara traffic didistribusikan ke instance atau endpoint dalam grup.

• Untuk Load Balancer Jaringan proxy internal lintas region, region yang dikonfigurasi akan dipilih terlebih dahulu. Dalam sebuah region, kapasitas target mode penyeimbangan digunakan untuk menghitung proporsi jumlah permintaan yang harus dikirimkan ke setiap backend (grup instance atau NEG) di region tersebut. Anda dapat menggunakan kebijakan load balancing layanan (serviceLbPolicy) dan setelan backend yang dipilih untuk memengaruhi pemilihan backend tertentu dalam suatu region. Selain itu, dalam setiap grup instance atau NEG, kebijakan load balancing (LocalityLbPolicy) menentukan cara traffic didistribusikan ke instance atau endpoint dalam grup.

• Untuk Load Balancer Jaringan proxy klasik, region dipilih berdasarkan lokasi klien dan apakah region tersebut memiliki kapasitas yang tersedia berdasarkan kapasitas target mode load balancing. Kemudian, dalam sebuah region, kapasitas target mode load balancing digunakan untuk menghitung proporsi jumlah permintaan atau koneksi yang harus diteruskan ke setiap backend (grup instance atau NEG) di region tersebut. Setelah load balancer memilih backend, permintaan atau koneksi kemudian didistribusikan secara round robin di antara instance VM atau endpoint jaringan dalam setiap backend individual.

• Untuk Load Balancer Jaringan proxy eksternal regional dan Load Balancer Jaringan proxy internal regional, kapasitas target mode load balancing digunakan untuk menghitung proporsi jumlah permintaan yang harus dikirimkan ke setiap backend (grup instance atau NEG). Dalam setiap grup instance atau NEG, kebijakan load balancing (localityLbPolicy) menentukan cara traffic didistribusikan ke instance atau endpoint dalam grup.

Tabel berikut meringkas mode load balancing yang tersedia untuk setiap kombinasi load balancer dan backend.

Tabel: Mode balancing yang tersedia untuk setiap load balancer

Load balancer	Backend	Mode balancing tersedia
Load Balancer Aplikasi	Grup instance	RATE atau UTILIZATION
	NEG Zona (GCE_VM_IP_PORT endpoint)	RATE
	NEG campuran (NON_GCP_PRIVATE_IP_PORT endpoint)	RATE
Load Balancer Jaringan proxy eksternal global Load Balancer Jaringan proxy klasik Load Balancer Jaringan proxy eksternal regional Load Balancer Jaringan proxy internal regional Load Balancer Jaringan proxy internal lintas region	Grup instance	CONNECTION atau UTILIZATION
	NEG Zona (GCE_VM_IP_PORT endpoint)	CONNECTION
	NEG campuran (NON_GCP_PRIVATE_IP_PORT endpoint)	CONNECTION
Load Balancer Jaringan Passthrough	Grup instance	CONNECTION
	NEG Zona (GCE_VM_IP endpoint)	CONNECTION

Catatan:

Jika Anda mengamati distribusi traffic yang buruk saat menggunakan mode penyeimbangan UTILIZATION, sebaiknya gunakan RATE.

Mode balancing UTILIZATION bergantung pada instance VM atau pemakaian CPU beserta faktor lainnya. Saat faktor-faktor tersebut berfluktuasi, load balancer menghitung kapasitas secara tidak efektif, yang sering kali menyebabkan distribusi traffic antargrup backend yang buruk. Sebaliknya, untuk mode penyeimbangan RATE, load balancer mengirimkan permintaan ke grup backend dengan latensi rata-rata terendah dibandingkan permintaan terbaru, atau untuk HTTP/2 dan HTTP/3, permintaan akan dikirim ke grup backend dengan permintaan yang belum diproses paling sedikit.

Jika rata-rata penggunaan semua VM yang terkait dengan layanan backend kurang dari 10%, Google Cloud mungkin memilih zona tertentu. Hal ini dapat terjadi jika Anda menggunakan grup instance terkelola regional, grup instance terkelola menurut zona di zona berbeda, dan grup instance yang tidak dikelola menurut zona. Ketidakseimbangan zona ini akan otomatis diselesaikan saat lebih banyak traffic dikirim ke load balancer.

Untuk mengetahui informasi selengkapnya, lihat gcloud compute backend-services add-backend.

Kapasitas target

Setiap mode penyeimbangan memiliki kapasitas target yang sesuai, yang menentukan salah satu jumlah maksimum target berikut:

• Jumlah koneksi
• Rate
• CPU utilization

Untuk setiap mode penyeimbangan, kapasitas target bukanlah pemutus arus listrik. Load balancer dapat melebihi batas maksimum dalam kondisi tertentu, misalnya, jika semua VM atau endpoint backend telah mencapai batas maksimum.

Mode connection balancing

Untuk mode penyeimbangan CONNECTION, kapasitas target menentukan jumlah maksimum koneksi terbuka target. Kecuali untuk Load Balancer Jaringan passthrough internal dan Load Balancer Jaringan passthrough eksternal, Anda harus menggunakan salah satu setelan berikut untuk menentukan jumlah maksimum koneksi target:

• max-connections-per-instance (per VM): Menargetkan jumlah koneksi rata-rata untuk satu VM.
• max-connections-per-endpoint (per endpoint di NEG zona): Menargetkan jumlah rata-rata koneksi untuk endpoint tunggal.
• max-connections (per NEG zona dan untuk grup instance zona): Menargetkan jumlah rata-rata koneksi untuk seluruh NEG atau grup instance. Untuk grup instance terkelola regional, gunakan max-connections-per-instance sebagai gantinya.

Tabel berikut menunjukkan cara parameter kapasitas target menentukan hal berikut:

• Kapasitas target untuk seluruh backend
• Kapasitas target yang diharapkan untuk setiap instance atau endpoint

Tabel: Target kapasitas untuk backend menggunakan mode CONNECTION balancing

Backend type	Kapasitas target
	Jika Anda menentukan	Kapasitas backend keseluruhan	Diharapkan per instance atau kapasitas per endpoint
Grup instance N instance, H responsif	max-connections-per-instance=X	X × N	(X × N)/H
NEG Zona N endpoint, H responsif	max-connections-per-endpoint=X	X × N	(X × N)/H
Grup instance (kecuali grup instance terkelola regional) H instance responsif	max-connections=Y	Y	Y/H

Seperti yang diilustrasikan, setelan max-connections-per-instance dan max-connections-per-endpoint adalah proxy untuk menghitung jumlah maksimum koneksi target untuk seluruh grup instance VM atau seluruh NEG zona:

• Dalam grup instance VM dengan instance N, menetapkan max-connections-per-instance=X memiliki arti yang sama dengan menetapkan max-connections=X × N.
• Di NEG zona dengan endpoint N, menetapkan max-connections-per-endpoint=X memiliki arti yang sama dengan menetapkan max-connections=X × N.

Mode penyeimbangan tarif

Untuk mode penyeimbangan RATE, Anda harus menentukan kapasitas target menggunakan salah satu parameter berikut:

• max-rate-per-instance (per VM): Memberikan rasio permintaan HTTP rata-rata target untuk satu VM.
• max-rate-per-endpoint (per endpoint di NEG zona): Memberikan rasio permintaan HTTP rata-rata target untuk satu endpoint.
• max-rate (per NEG zona dan untuk grup instance zona): Berikan rasio permintaan HTTP rata-rata target untuk seluruh NEG atau grup instance. Untuk grup instance terkelola regional, gunakan max-rate-per-instance sebagai gantinya.

Tabel berikut menunjukkan cara parameter kapasitas target menentukan hal berikut:

• Kapasitas target untuk seluruh backend
• Kapasitas target yang diharapkan untuk setiap instance atau endpoint

Tabel: Target kapasitas untuk backend menggunakan mode penyeimbangan RATE

Backend type	Kapasitas target
	Jika Anda menentukan	Kapasitas backend keseluruhan	Diharapkan per instance atau kapasitas per endpoint
Grup instance N instance, H responsif	max-rate-per-instance=X	X × N	(X × N)/H
NEG zona N endpoint, H responsif	max-rate-per-endpoint=X	X × N	(X × N)/H
Grup instance (kecuali grup instance terkelola regional) H instance responsif	max-rate=Y	Y	Y/H

Seperti yang diilustrasikan, setelan max-rate-per-instance dan max-rate-per-endpoint adalah proxy untuk menghitung tarif maksimum target permintaan HTTP untuk seluruh grup instance atau seluruh NEG zona:

• Dalam grup instance dengan instance N, menetapkan max-rate-per-instance=X memiliki arti yang sama dengan menetapkan max-rate=X × N.
• Di NEG zona dengan endpoint N, menetapkan max-rate-per-endpoint=X memiliki arti yang sama dengan menetapkan max-rate=X × N.

Mode balancing pemanfaatan

Mode penyeimbangan UTILIZATION tidak memiliki kapasitas target wajib. Anda memiliki sejumlah opsi yang bergantung pada jenis backend, seperti yang diringkas dalam tabel di bagian berikut.

Kapasitas target max-utilization hanya dapat ditentukan per grup instance dan tidak dapat diterapkan ke VM tertentu dalam grup.

Mode penyeimbangan UTILIZATION tidak memiliki kapasitas target wajib. Saat Anda menggunakan Konsol Google Cloud untuk menambahkan grup instance backend ke layanan backend, Konsol Google Cloud akan menetapkan nilai max-utilization ke 0,8 (80%) jika mode penyeimbangan UTILIZATION dipilih. Selain max-utilization, mode penyeimbangan UTILIZATION mendukung kapasitas target yang lebih kompleks, seperti yang dirangkum dalam tabel di bagian berikut.

Mengubah mode penyeimbangan load balancer

Untuk beberapa konfigurasi load balancer atau load balancer, Anda tidak dapat mengubah mode penyeimbangan karena layanan backend hanya memiliki satu kemungkinan mode penyeimbangan. Untuk sistem lainnya, bergantung pada backend yang digunakan, Anda dapat mengubah mode penyeimbangan karena lebih dari satu mode tersedia untuk layanan backend tersebut.

Untuk melihat mode balancing yang didukung untuk setiap load balancer, lihat Tabel: Mode balancing yang tersedia untuk setiap load balancer

Menyeimbangkan mode dan setelan kapasitas target

Tabel ini meringkas semua mode penyeimbangan yang mungkin untuk load balancer tertentu dan jenis backend. Ini juga menunjukkan setelan kapasitas yang tersedia atau diperlukan, yang harus Anda tentukan dengan mode balancing.

Tabel: Spesifikasi kapasitas target untuk mode penyeimbangan

Load balancer	Jenis backend	Balancing mode	Kapasitas target
Load Balancer Aplikasi Traffic Director	Instance group	RATE	Anda harus menentukan salah satu hal berikut: max-rate per grup instance zona max-rate-per-instance (grup instance zona atau regional)
		UTILIZATION	Anda dapat menentukan salah satu hal berikut secara opsional: (1) max-utilization (2) max-rate per grup instance zona (3) max-rate-per-instance (grup instance zona atau regional) (1) dan (2) bersama-sama (1) dan (3) bersama-sama
	NEG Zona (GCP_VM_IP_PORT)	RATE	Anda harus menentukan salah satu hal berikut: max-rate per NEG zona max-rate-per-endpoint
	NEG Hibrida (NON_GCP_PRIVATE_IP_PORT)	RATE	Anda harus menentukan salah satu hal berikut: max-rate per NEG campuran max-rate-per-endpoint
Load Balancer Jaringan proxy eksternal global Load Balancer Jaringan proxy klasik Load Balancer Jaringan proxy eksternal regional Load Balancer Jaringan proxy internal regional Load Balancer Jaringan proxy internal lintas region	Instance group	CONNECTION	Anda harus menentukan salah satu hal berikut: max-connections per grup instance zona max-connections-per-instance (grup instance zona atau regional)
		UTILIZATION	Anda dapat menentukan salah satu hal berikut secara opsional: (1) max-utilization (2) max-connections per grup instance zona (3) max-connections-per-instance (grup instance zona atau regional) (1) dan (2) bersama-sama (1) dan (3) bersama-sama
	NEG Zona (GCP_VM_IP_PORT)	CONNECTION	Anda harus menentukan salah satu hal berikut: max-connections per NEG zona max-connections-per-endpoint
	NEG Hibrida (NON_GCP_PRIVATE_IP_PORT)	CONNECTION	Anda harus menentukan salah satu hal berikut: max-connections per NEG campuran max-connections-per-endpoint
Load Balancer Jaringan Passthrough	Instance group	CONNECTION	Anda tidak dapat menentukan jumlah maksimum koneksi target.
	NEG Zona (GCP_VM_IP)	CONNECTION	Anda tidak dapat menentukan jumlah maksimum koneksi target.

Catatan: Untuk mode penyeimbangan RATE atau UTILIZATION—saat kapasitas target maksimum tercapai di semua backend, load balancer akan mendistribusikan traffic secara proporsional dengan kapasitas tersebut. Load balancer tidak menghentikan permintaan.

Penskalaan kapasitas

Gunakan scaler kapasitas untuk menskalakan kapasitas target (penggunaan maksimum, kapasitas maksimum, atau koneksi maksimum) tanpa mengubah kapasitas target.

Untuk dokumentasi referensi Google Cloud, lihat artikel berikut:

• Google Cloud CLI: capacity-scaler
• API:
  • Regional
  • Global

Anda dapat menyesuaikan penskalaan kapasitas untuk menskalakan kapasitas target yang efektif tanpa mengubah salah satu parameter --max-* secara eksplisit.

Anda dapat menetapkan penskala kapasitas ke salah satu nilai berikut:

• Nilai defaultnya adalah 1, yang berarti grup menyalurkan hingga 100% kapasitas yang dikonfigurasi (bergantung pada balancingMode).
• Nilai 0 berarti grup benar-benar dikosongkan, menawarkan 0% dari kapasitas yang tersedia. Anda tidak dapat mengonfigurasi setelan 0 jika hanya ada satu backend yang terpasang ke layanan backend.
• Nilai dari 0.1 (10%) hingga 1.0 (100%).

Contoh berikut menunjukkan cara kerja penskala kapasitas bersama setelan kapasitas target:

• Jika mode balancing adalah RATE, max-rate disetel ke 80 RPS, dan scaler kapasitas adalah 1.0, kapasitas yang tersedia juga 80 RPS.

• Jika mode penyeimbangan adalah RATE, max-rate disetel ke 80 RPS, dan scaler kapasitas adalah 0.5, kapasitas yang tersedia adalah 40 RPS (0.5 times 80).

• Jika mode penyeimbangan adalah RATE, max-rate disetel ke 80 RPS, dan scaler kapasitas adalah 0.0, kapasitas yang tersedia adalah nol (0).

Catatan: Penskala kapasitas tidak didukung untuk backend yang tidak mendukung mode penyeimbangan. Ini mencakup backend seperti NEG internet, NEG serverless, dan NEG PSC.

Kebijakan load balancing layanan

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.

Kebijakan load balancing layanan (serviceLbPolicy) adalah resource yang terkait dengan layanan backend load balancer. Dengan API ini, Anda dapat menyesuaikan parameter yang memengaruhi cara traffic didistribusikan dalam backend yang terkait dengan layanan backend:

• Sesuaikan algoritma load balancing yang digunakan untuk menentukan cara traffic didistribusikan di antara region atau zona.
• Aktifkan pengosongan kapasitas otomatis sehingga load balancer dapat dengan cepat menghabiskan traffic dari backend yang tidak responsif.

Selain itu, Anda dapat menentukan backend tertentu sebagai backend pilihan. Backend ini harus digunakan untuk menentukan kapasitas (yaitu, kapasitas target yang ditentukan oleh mode penyeimbangan backend) sebelum permintaan dikirim ke backend yang tersisa.

Untuk mempelajari lebih lanjut, lihat Pengoptimalan load balancing lanjutan dengan kebijakan load balancing layanan.

Traffic Director dan distribusi traffic

Traffic Director juga menggunakan resource layanan backend. Secara khusus, Traffic Director menggunakan layanan backend yang skema load balancingnya adalah INTERNAL_SELF_MANAGED. Untuk layanan backend yang dikelola sendiri secara internal, distribusi traffic didasarkan pada kombinasi mode load balancing dan kebijakan load balancing. Layanan backend mengarahkan traffic ke backend sesuai dengan mode penyeimbangan backend. Kemudian, Traffic Director mendistribusikan traffic sesuai dengan kebijakan load balancing.

Layanan backend yang dikelola sendiri secara internal mendukung mode penyeimbangan berikut:

• UTILIZATION, jika semua backend adalah grup instance
• RATE, jika semua backend adalah grup instance atau NEG zona

Jika memilih mode penyeimbangan RATE, Anda harus menentukan tarif maksimum, tarif maksimum per instance, atau tarif maksimum per endpoint.

Untuk informasi selengkapnya tentang Traffic Director, lihat konsep Traffic Director.

Subsetelan backend

Subsetelan backend adalah fitur opsional yang meningkatkan performa dan skalabilitas dengan menetapkan subset backend ke setiap instance proxy.

Subsetelan backend didukung untuk hal berikut:

• Load Balancer Aplikasi internal regional
• Load Balancer Jaringan passthrough internal

Subsetelan backend untuk Load Balancer Aplikasi internal regional

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.

Load Balancer Aplikasi internal lintas region tidak mendukung subsetelan backend.

Untuk Load Balancer Aplikasi internal regional, subsetelan backend hanya otomatis menetapkan sebagian backend dalam layanan backend regional ke setiap instance proxy. Secara default, setiap instance proxy membuka koneksi ke semua backend dalam layanan backend. Jika jumlah instance proxy dan backend besar, membuka koneksi ke semua backend dapat menyebabkan masalah performa.

Dengan mengaktifkan subsetelan, setiap proxy hanya akan membuka koneksi ke subset backend, sehingga mengurangi jumlah koneksi yang tetap terbuka untuk setiap backend. Mengurangi jumlah koneksi yang terbuka secara bersamaan ke setiap backend dapat meningkatkan performa backend dan proxy.

Diagram berikut menunjukkan load balancer dengan dua proxy. Tanpa subset backend, traffic dari kedua proxy akan didistribusikan ke semua backend di layanan backend 1. Dengan mengaktifkan subsetelan backend, traffic dari setiap proxy akan didistribusikan ke subkumpulan backend. Traffic dari proxy 1 didistribusikan ke backend 1 dan 2, dan traffic dari proxy 2 didistribusikan ke backend 3 dan 4.

Membandingkan Load Balancer Aplikasi internal tanpa dan dengan subsetelan backend (klik untuk memperbesar).

Anda juga dapat meningkatkan traffic load balancing ke backend dengan menetapkan kebijakan localityLbPolicy. Untuk informasi selengkapnya, lihat Kebijakan traffic.

Untuk membaca cara menyiapkan subsetelan backend untuk Load Balancer Aplikasi internal, lihat Mengonfigurasi subsetelan backend.

Peringatan yang terkait dengan subsetelan backend untuk Load Balancer Aplikasi internal

• Meskipun subset backend dirancang untuk memastikan bahwa semua instance backend tetap digunakan dengan baik, hal ini dapat menimbulkan beberapa bias dalam jumlah traffic yang diterima setiap backend. Menyetel localityLbPolicy ke LEAST_REQUEST direkomendasikan untuk layanan backend yang sensitif terhadap keseimbangan beban backend.
• Mengaktifkan dan menonaktifkan subset akan memutuskan koneksi yang ada.
• Subsetelan backend memerlukan afinitas sesi adalah NONE (hash 5 tuple). Opsi afinitas sesi lainnya hanya dapat digunakan jika subsetelan backend dinonaktifkan. Nilai default dari tanda --subsetting-policy dan --session-affinity adalah NONE, dan hanya salah satunya dalam satu waktu yang dapat ditetapkan ke nilai yang berbeda.

Subsetelan backend untuk Load Balancer Jaringan passthrough internal

Subsetelan backend untuk Load Balancer Jaringan passthrough internal memungkinkan Anda menskalakan Load Balancer Jaringan passthrough internal untuk mendukung jumlah instance VM backend yang lebih besar per layanan backend internal.

Untuk mengetahui informasi tentang pengaruh subset terhadap batas ini, lihat bagian"Layanan backend" dalam kuota dan batas resource load balancing.

Secara default, subsetelan dinonaktifkan, yang membatasi layanan backend untuk mendistribusikan hingga 250 instance atau endpoint backend. Jika layanan backend Anda perlu mendukung lebih dari 250 backend, Anda dapat mengaktifkan subsetelan. Saat subset diaktifkan, subset instance backend akan dipilih untuk setiap koneksi klien.

Diagram berikut menunjukkan model yang diperkecil untuk perbedaan antara kedua mode operasi ini.

Membandingkan Load Balancer Jaringan passthrough internal tanpa dan dengan subsetelan (klik untuk memperbesar).

Tanpa subset, kumpulan lengkap backend yang sehat akan dimanfaatkan dengan lebih baik, dan koneksi klien baru didistribusikan ke semua backend yang responsif sesuai dengan distribusi traffic. Subsetelan akan menerapkan pembatasan load balancing, tetapi memungkinkan load balancer mendukung lebih dari 250 backend.

Untuk petunjuk konfigurasi, lihat Subsetelan.

Peringatan yang terkait dengan subsetelan backend untuk Load Balancer Jaringan passthrough internal

• Jika subsetelan diaktifkan, tidak semua backend akan menerima traffic dari pengirim tertentu meskipun jumlah backend-nya sedikit.
• Untuk mengetahui jumlah maksimum backend instance saat subsetelan diaktifkan, lihat halaman kuota .
• Hanya afinitas sesi 5-tuple yang didukung dengan subsetelan.
• Duplikasi Paket tidak didukung dengan subset.
• Mengaktifkan dan menonaktifkan subset akan memutuskan koneksi yang ada.
• Jika klien lokal perlu mengakses Load Balancer Jaringan passthrough internal, subset dapat secara signifikan mengurangi jumlah backend yang menerima koneksi dari klien lokal Anda. Hal ini karena region tunnel Cloud VPN atau lampiran VLAN Cloud Interconnect menentukan subset backend load balancer. Semua endpoint Cloud VPN dan Cloud Interconnect di region tertentu menggunakan subset yang sama. Subset yang berbeda digunakan di wilayah yang berbeda.
• Anda tidak dapat menggunakan protokol layanan backend UNSPECIFIED.

Penetapan harga subsetelan backend

Penggunaan subsetelan backend tidak dikenai biaya. Untuk mengetahui informasi selengkapnya, lihat Semua harga jaringan.

Afinitas sesi

Afinitas sesi memungkinkan Anda mengontrol cara load balancer memilih backend untuk koneksi baru dengan cara yang dapat diprediksi selama jumlah backend yang responsif tetap konstan. Cara ini berguna untuk aplikasi yang memerlukan beberapa permintaan dari pengguna tertentu agar dialihkan ke backend atau endpoint yang sama. Aplikasi tersebut biasanya mencakup server stateful yang digunakan oleh penayangan iklan, game, atau layanan dengan caching internal yang berat.

Load balancer Google Cloud memberikan afinitas sesi dengan upaya terbaik. Faktor-faktor seperti mengubah status health check backend, menambahkan atau menghapus backend, atau perubahan pada kelengkapan backend, seperti yang diukur oleh mode penyeimbangan, dapat merusak afinitas sesi.

Load balancing dengan afinitas sesi akan berfungsi dengan baik jika ada distribusi koneksi unik yang cukup besar. Cukup besar berarti setidaknya beberapa kali jumlah backend. Menguji load balancer dengan sejumlah kecil koneksi tidak akan menghasilkan representasi yang akurat dari distribusi koneksi klien di antara backend.

Secara default, semua load balancer Google Cloud memilih backend menggunakan hash lima tuple (--session-affinity=NONE), sebagai berikut:

• Alamat IP sumber paket
• Port sumber paket (jika ada di header paket)
• Alamat IP tujuan paket
• Port tujuan paket (jika ada di header paket)
• Protokol paket

Untuk load balancer pass-through, koneksi baru akan didistribusikan ke instance atau endpoint backend yang responsif (di kumpulan yang aktif, jika kebijakan failover dikonfigurasi). Anda dapat mengontrol hal berikut:

• Apakah koneksi yang dibuat tetap ada di backend yang tidak responsif. Untuk mengetahui detailnya, baca Persistensi koneksi pada backend yang tidak responsif dalam dokumentasi Load Balancer Jaringan passthrough internal dan Persistensi koneksi pada backend yang tidak responsif di dokumentasi Load Balancer Jaringan passthrough eksternal berbasis layanan backend.
• Apakah koneksi yang tersambung akan tetap ada selama failover dan failover, jika kebijakan failover dikonfigurasi. Untuk mengetahui detailnya, baca Pengosongan koneksi pada failover dan failback dalam dokumentasi Load Balancer Jaringan passthrough internal dan Pengosongan koneksi pada failover dan failover di dokumentasi Load Balancer Jaringan passthrough eksternal eksternal berbasis layanan backend.
• Berapa lama koneksi yang terhubung dapat bertahan saat menghapus backend dari load balancer. Untuk mengetahui detailnya, lihat Mengaktifkan pengurasan koneksi.

Untuk load balancer berbasis proxy, selama jumlah instance backend atau endpoint yang sehat tetap konstan, dan selama instance backend atau endpoint yang dipilih sebelumnya tidak mencapai kapasitas, permintaan atau koneksi berikutnya akan diarahkan ke VM atau endpoint backend yang sama. Kapasitas target mode penyeimbangan menentukan kapan backend mencapai kapasitasnya.

Tabel berikut menunjukkan opsi afinitas sesi yang didukung untuk setiap produk:

Tabel: Setelan afinitas sesi yang didukung

Produk	Opsi minat sesi
Load Balancer Aplikasi eksternal global Load Balancer Aplikasi eksternal regional	Tidak ada (NONE) IP Klien (CLIENT_IP) Cookie yang dihasilkan (GENERATED_COOKIE) Kolom header (HEADER_FIELD) Cookie HTTP (HTTP_COOKIE) Perhatikan juga: Nilai default yang efektif dari kebijakan lokalitas load balancing (localityLbPolicy) akan berubah sesuai dengan setelan afinitas sesi Anda. Jika afinitas sesi tidak dikonfigurasi—yaitu, jika afinitas sesi tetap pada nilai default NONE—nilai default untuk localityLbPolicy adalah ROUND_ROBIN. Jika afinitas sesi ditetapkan ke nilai selain NONE, maka nilai default untuk localityLbPolicy adalah MAGLEV. Untuk Load Balancer Aplikasi eksternal global, jangan mengonfigurasi afinitas sesi jika Anda menggunakan pemisahan traffic berbobot. Jika Anda melakukannya, konfigurasi pemisahan traffic berbobot akan diprioritaskan.
Load Balancer Aplikasi Klasik	Tidak ada (NONE) IP Klien (CLIENT_IP) Cookie yang dihasilkan (GENERATED_COOKIE)
Load Balancer Aplikasi internal lintas region Load Balancer Aplikasi internal regional	Tidak ada (NONE) IP Klien (CLIENT_IP) Cookie yang dihasilkan (GENERATED_COOKIE) Kolom header (HEADER_FIELD) Cookie HTTP (HTTP_COOKIE) Perhatikan juga: Nilai default yang efektif dari kebijakan lokalitas load balancing (localityLbPolicy) akan berubah sesuai dengan setelan afinitas sesi Anda. Jika afinitas sesi tidak dikonfigurasi—yaitu, jika afinitas sesi tetap pada nilai default NONE—nilai default untuk localityLbPolicy adalah ROUND_ROBIN. Jika afinitas sesi ditetapkan ke nilai selain NONE, maka nilai default untuk localityLbPolicy adalah MAGLEV. Untuk Load Balancer Aplikasi internal, jangan mengonfigurasi afinitas sesi jika Anda menggunakan pemisahan traffic berbobot. Jika Anda melakukannya, konfigurasi pemisahan traffic berbobot akan diprioritaskan.
Load Balancer Jaringan passthrough internal	Tidak ada (NONE) IP CLIENT, tidak ada tujuan (CLIENT_IP_NO_DESTINATION) IP Klien, IP Tujuan (CLIENT_IP) IP Klien, IP Tujuan, Protokol (CLIENT_IP_PROTO) IP Klien, Port Klien, IP Tujuan, Port Tujuan, Protokol (CLIENT_IP_PORT_PROTO) Untuk mengetahui informasi spesifik tentang Load Balancer Jaringan passthrough internal dan afinitas sesi, baca Ringkasan Load Balancer Jaringan passthrough internal.
Load Balancer Jaringan passthrough eksternal^1	Tidak ada (NONE) IP Klien, IP Tujuan (CLIENT_IP) IP Klien, IP Tujuan, Protokol (CLIENT_IP_PROTO) IP Klien, Port Klien, IP Tujuan, Port Tujuan, Protokol (CLIENT_IP_PORT_PROTO) Untuk mengetahui informasi spesifik tentang Load Balancer Jaringan passthrough eksternal dan afinitas sesi, lihat Ringkasan Load Balancer Jaringan Passthrough Eksternal TCP/UDP Eksternal.
Load Balancer Jaringan proxy eksternal global Load Balancer Jaringan proxy klasik Load Balancer Jaringan proxy eksternal regional Load Balancer Jaringan proxy internal regional Load Balancer Jaringan proxy internal lintas region	Tidak ada (NONE) IP Klien (CLIENT_IP)
Traffic Director	Tidak ada (NONE) IP Klien (CLIENT_IP) Cookie yang dihasilkan (GENERATED_COOKIE) (khusus protokol HTTP) Kolom header (HEADER_FIELD) (khusus protokol HTTP) Cookie HTTP (HTTP_COOKIE) (khusus protokol HTTP)

¹ Tabel ini mendokumentasikan minat sesi yang didukung oleh Load Balancer Jaringan passthrough Jaringan passthrough berbasis layanan backend. Load Balancer Jaringan passthrough eksternal berbasis kumpulan target tidak menggunakan layanan backend. Sebagai gantinya, Anda menetapkan afinitas sesi untuk Load Balancer Jaringan passthrough eksternal melalui parameter sessionAffinity di Kumpulan Target.

Perhatikan hal-hal berikut saat mengonfigurasi afinitas sesi:

• Jangan mengandalkan afinitas sesi untuk tujuan autentikasi atau keamanan. Afinitas sesi dirancang untuk berhenti berfungsi setiap kali jumlah penayangan dan backend responsif berubah. Aktivitas yang menyebabkan gangguan afinitas sesi meliputi:

  • Menambahkan grup instance backend atau NEG ke layanan backend
  • Menghapus grup instance backend atau NEG dari layanan backend
  • Menambahkan instance ke grup instance backend yang ada (yang terjadi secara otomatis saat Anda mengaktifkan penskalaan otomatis dengan grup instance terkelola)
  • Menghapus instance dari grup instance backend yang ada (yang terjadi secara otomatis saat Anda mengaktifkan penskalaan otomatis dengan grup instance terkelola)
  • Menambahkan endpoint ke NEG backend yang ada
  • Menghapus endpoint dari NEG backend yang ada
  • Saat backend yang responsif gagal health check-nya dan menjadi tidak responsif
  • Saat backend yang tidak responsif lulus health check dan menjadi responsif
  • Untuk load balancer pass-through: selama failover dan failover, jika kebijakan failover dikonfigurasi
  • Untuk load balancer proxy: saat backend berada pada atau di atas kapasitas

• Sebaiknya jangan menggunakan afinitas sesi selain None dengan mode penyeimbangan UTILIZATION. Hal ini karena perubahan penggunaan instance dapat menyebabkan layanan load balancing mengarahkan permintaan atau koneksi baru ke VM backend yang kurang penuh. Hal ini merusak afinitas sesi. Sebagai gantinya, gunakan mode penyeimbangan RATE atau CONNECTION untuk mengurangi kemungkinan merusak afinitas sesi. Untuk detail selengkapnya, lihat Kehilangan afinitas sesi.

• Untuk load balancer HTTP(S) eksternal dan internal, afinitas sesi dapat rusak ketika endpoint atau instance yang dimaksudkan melebihi target maksimum mode balancingnya. Perhatikan contoh berikut:

  • Load balancer memiliki satu NEG dan tiga endpoint.
  • Setiap endpoint memiliki kapasitas target 1 RPS.
  • Mode penyeimbangan adalah RATE.
  • Saat ini, setiap endpoint sedang memproses 1.1, 0.8, dan 1.6 RPS.
  • Ketika permintaan HTTP dengan afinitas untuk endpoint terakhir tiba di load balancer, afinitas sesi mengklaim endpoint yang sedang diproses pada RPS 1,6.
  • Permintaan baru mungkin dikirim ke endpoint tengah dengan RPS 0,8.

• Nilai default tanda --session-affinity dan --subsetting-policy adalah NONE dan hanya salah satunya dalam satu waktu yang dapat ditetapkan ke nilai yang berbeda.

Bagian berikut membahas berbagai jenis afinitas sesi.

IP klien, tidak ada afinitas tujuan

IP klien, tidak ada afinitas tujuan (CLIENT_IP_NO_DESTINATION) yang mengarahkan permintaan dari alamat IP sumber klien yang sama ke instance backend yang sama.

Saat Anda menggunakan IP klien, tidak ada minat tujuan, perhatikan hal berikut:

• IP klien, tanpa afinitas tujuan adalah hash satu-tuple yang terdiri dari alamat IP sumber klien.

• Jika klien berpindah dari satu jaringan ke jaringan lainnya, alamat IP-nya berubah, yang mengakibatkan afinitas yang terputus.

IP Klien, tidak ada afinitas tujuan, hanya opsi untuk Load Balancer Jaringan passthrough internal.

Afinitas IP klien

Afinitas IP klien (CLIENT_IP) mengarahkan permintaan dari alamat IP klien yang sama ke backend instance yang sama. Afinitas IP klien adalah opsi untuk setiap load balancer Google Cloud yang menggunakan layanan backend.

Saat Anda menggunakan afinitas IP klien, perhatikan hal berikut:

• Afinitas IP klien adalah hash dua tuple yang terdiri dari alamat IP klien dan alamat IP dari aturan penerusan load balancer yang dihubungi klien.

• Alamat IP klien seperti yang terlihat oleh load balancer mungkin bukan klien asal jika berada di belakang NAT atau membuat permintaan melalui proxy. Permintaan yang dibuat melalui NAT atau proxy menggunakan alamat IP router atau proxy NAT sebagai alamat IP klien. Hal ini bisa menyebabkan traffic masuk terkumpul secara tidak perlu ke backend instance yang sama.

• Jika klien berpindah dari satu jaringan ke jaringan lainnya, alamat IP-nya berubah, yang mengakibatkan afinitas yang terputus.

Untuk mempelajari produk yang mendukung afinitas IP klien, lihat Tabel: Setelan afinitas sesi yang didukung.

Afinitas berbasis cookie

Saat Anda menetapkan afinitas cookie yang dihasilkan, load balancer akan mengeluarkan cookie pada permintaan pertama. Untuk setiap permintaan berikutnya dengan cookie yang sama, load balancer akan mengarahkan permintaan tersebut ke VM backend atau endpoint yang sama.

• Untuk Load Balancer Aplikasi eksternal global, cookie diberi nama GCLB.

• Untuk Traffic Director, Load Balancer Aplikasi eksternal regional, dan Load Balancer Aplikasi internal, cookie akan diberi nama GCILB.

Afinitas berbasis cookie dapat mengidentifikasi klien ke load balancer secara lebih akurat dibandingkan dengan afinitas berbasis IP klien. Contoh:

1. Dengan afinitas berbasis cookie, load balancer dapat secara unik mengidentifikasi dua atau beberapa sistem klien yang menggunakan alamat IP sumber yang sama. Dengan menggunakan afinitas berbasis IP klien, load balancer memperlakukan semua koneksi dari alamat IP sumber yang sama seolah-olah berasal dari sistem klien yang sama.

2. Jika klien mengubah alamat IP-nya, afinitas berbasis cookie memungkinkan load balancer mengenali koneksi berikutnya dari klien tersebut, bukan memperlakukan koneksi sebagai baru. Contoh saat klien mengubah alamat IP-nya adalah ketika perangkat seluler berpindah dari satu jaringan lainnya.

Saat membuat cookie untuk afinitas berbasis cookie yang dihasilkan, load balancer menetapkan atribut path cookie ke /. Jika pencocok jalur peta URL memiliki beberapa layanan backend untuk nama host, semua layanan backend berbagi cookie sesi yang sama.

Masa aktif cookie HTTP yang dihasilkan oleh load balancer dapat dikonfigurasi. Anda dapat menetapkannya ke 0 (default), yang berarti cookie hanya berupa cookie sesi. Atau, Anda dapat menetapkan masa aktif cookie ke nilai dari 1 hingga 86400 detik (24 jam) inklusif.

Untuk mempelajari produk yang mendukung afinitas cookie yang dihasilkan, lihat Tabel: Setelan afinitas sesi yang didukung.

Afinitas kolom header

Traffic Director dan Load Balancer Aplikasi internal dapat menggunakan afinitas kolom header jika kedua hal berikut berlaku:

• Kebijakan lokalitas load balancing adalah RING_HASH atau MAGLEV.
• consistentHash layanan backend menentukan nama header HTTP (httpHeaderName).

Untuk mempelajari produk yang mendukung afinitas kolom header, lihat Tabel: Setelan afinitas sesi yang didukung.

Afinitas cookie HTTP

Traffic Director, Load Balancer Aplikasi eksternal global, Load Balancer Aplikasi eksternal regional, Load Balancer Jaringan proxy eksternal global, Load Balancer Jaringan proxy eksternal regional, Load Balancer Aplikasi internal lintas region, dan Load Balancer Aplikasi internal regional dapat menggunakan afinitas cookie HTTP jika kedua hal berikut berlaku:

• Kebijakan lokalitas load balancing adalah RING_HASH atau MAGLEV.
• Hash konsisten layanan backend menentukan nama cookie HTTP.

Afinitas cookie HTTP merutekan permintaan ke VM backend atau endpoint di NEG berdasarkan cookie HTTP yang disebutkan dalam flag HTTP_COOKIE. Jika klien tidak menyediakan cookie, proxy akan membuat cookie dan menampilkannya ke klien di header Set-Cookie.

Untuk mempelajari produk yang mendukung afinitas IP cookie HTTP, lihat Tabel: Setelan afinitas sesi yang didukung.

Kehilangan minat sesi

Terlepas dari jenis afinitas yang dipilih, klien dapat kehilangan afinitas dengan backend dalam situasi berikut:

• Jika grup instance backend atau NEG zona kehabisan kapasitas, seperti yang ditentukan oleh kapasitas target mode balancing. Dalam situasi ini, Google Cloud mengarahkan traffic ke grup instance backend atau NEG zona yang berbeda, yang mungkin berada di zona berbeda. Anda dapat memitigasi hal ini dengan memastikan untuk menentukan kapasitas target yang benar untuk setiap backend berdasarkan pengujian Anda sendiri.
• Penskalaan otomatis akan menambahkan instance ke, atau menghapus instance dari, grup instance terkelola. Jika ini terjadi, jumlah instance dalam grup instance berubah, sehingga layanan backend menghitung ulang hash untuk afinitas sesi. Anda dapat mengurangi hal ini dengan memastikan bahwa ukuran minimum grup instance terkelola dapat menangani pemuatan standar. Penskalaan otomatis hanya dilakukan selama peningkatan beban yang tidak terduga.
• Jika sebuah VM backend atau endpoint dalam NEG gagal dalam health check, load balancer akan mengarahkan traffic ke backend responsif lainnya. Baca dokumentasi untuk setiap load balancer Google Cloud untuk mengetahui detail tentang perilaku load balancer saat semua backend-nya gagal dalam health check.
• Saat mode penyeimbangan UTILIZATION diterapkan untuk grup instance backend, afinitas sesi akan terputus karena perubahan pada penggunaan backend. Anda dapat mengurangi hal ini menggunakan mode penyeimbangan RATE atau CONNECTION, mana saja yang didukung oleh jenis load balancer.

Saat Anda menggunakan Load Balancer Aplikasi eksternal atau Load Balancer Jaringan proxy eksternal, perhatikan beberapa poin tambahan berikut:

• Jika jalur pemilihan rute dari klien di internet ke Google berubah antara permintaan atau koneksi, Google Front End (GFE) yang berbeda mungkin dipilih sebagai proxy. Hal ini dapat merusak afinitas sesi.
• Saat Anda menggunakan mode penyeimbangan UTILIZATION, terutama tanpa target kapasitas target maksimum yang ditentukan, afinitas sesi cenderung akan rusak ketika traffic ke load balancer rendah. Beralihlah untuk menggunakan mode penyeimbangan RATE atau CONNECTION, seperti yang didukung oleh load balancer yang Anda pilih.

Waktu tunggu layanan backend

Sebagian besar load balancer Google Cloud memiliki waktu tunggu layanan backend. Nilai defaultnya adalah 30 detik. Rentang penuh nilai waktu tunggu yang diizinkan adalah 1 - 2.147.483.647 detik.

• Untuk Load Balancer Aplikasi eksternal dan Load Balancer Aplikasi internal menggunakan protokol HTTP, HTTPS, atau HTTP/2, waktu tunggu layanan backend adalah waktu tunggu permintaan dan respons untuk traffic HTTP(S).

  Untuk mengetahui detail selengkapnya tentang waktu tunggu layanan backend untuk setiap load balancer, lihat hal berikut:

  • Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi eksternal regional, lihat Waktu tunggu dan percobaan ulang.
  • Untuk Load Balancer Aplikasi internal, lihat Waktu tunggu dan percobaan ulang.

• Untuk Load Balancer Jaringan proxy eksternal, waktu tunggunya adalah waktu tunggu tidak ada aktivitas. Untuk memberikan waktu yang lebih banyak atau lebih sedikit sebelum koneksi dihapus, ubah nilai waktu tunggu. Waktu tunggu tidak ada aktivitas ini juga digunakan untuk koneksi WebSocket.

• Untuk Load Balancer Jaringan passthrough internal dan Load Balancer Jaringan passthrough eksternal, Anda dapat menetapkan nilai waktu tunggu layanan backend menggunakan gcloud atau API, tetapi nilainya diabaikan. Waktu tunggu layanan backend tidak berarti untuk load balancer pass-through ini.

• Untuk Traffic Director, kolom waktu tunggu layanan backend (ditentukan menggunakan timeoutSec) tidak didukung dengan layanan gRPC tanpa proxy. Untuk layanan tersebut, konfigurasikan waktu tunggu layanan backend menggunakan kolom maxStreamDuration. Hal ini karena gRPC tidak mendukung semantik timeoutSec yang menentukan jumlah waktu untuk menunggu backend menampilkan respons penuh setelah permintaan dikirim. Waktu tunggu gRPC menentukan jumlah waktu untuk menunggu dari awal streaming hingga respons selesai diproses, termasuk semua percobaan ulang.

Health check

Setiap layanan backend yang backend-nya adalah grup instance atau NEG zona harus memiliki health check terkait. Layanan backend yang menggunakan NEG serverless atau NEG internet global sebagai backend tidak boleh mereferensikan health check.

Saat membuat load balancer menggunakan Konsol Google Cloud, Anda dapat membuat health check, jika diperlukan, saat membuat load balancer, atau Anda dapat mereferensikan health check yang sudah ada.

Saat Anda membuat layanan backend menggunakan grup instance atau backend NEG zona menggunakan Google Cloud CLI atau API, Anda harus mereferensikan health check yang ada. Lihat panduan load balancer di Ringkasan Health Check untuk mengetahui detail tentang jenis dan cakupan health check yang diperlukan.

Untuk mengetahui informasi selengkapnya, baca dokumen berikut:

• Ringkasan health check
• Membuat health check
• Halaman health check gcloud
• Halaman health check REST API

Fitur tambahan yang diaktifkan di resource layanan backend

Fitur opsional berikut didukung oleh beberapa layanan backend.

Cloud CDN

Cloud CDN menggunakan jaringan edge global Google untuk menayangkan konten lebih dekat ke pengguna, sehingga mempercepat situs dan aplikasi Anda. Cloud CDN diaktifkan di layanan backend yang digunakan oleh Load Balancer Aplikasi eksternal global. Load balancer menyediakan port dan alamat IP frontend yang menerima permintaan, serta backend yang merespons permintaan tersebut.

Untuk detail selengkapnya, lihat dokumentasi Cloud CDN.

Cloud CDN tidak kompatibel dengan IAP. Keduanya tidak dapat diaktifkan di layanan backend yang sama.

Google Cloud Armor

Jika menggunakan salah satu load balancer berikut, Anda dapat menambahkan perlindungan tambahan ke aplikasi dengan mengaktifkan Google Cloud Armor di layanan backend selama pembuatan load balancer:

• Load Balancer Aplikasi eksternal global
• Load Balancer Aplikasi Klasik
• Load Balancer Jaringan proxy eksternal global
• Load Balancer Jaringan proxy klasik

Jika menggunakan konsol Google Cloud, Anda dapat melakukan salah satu hal berikut:

• Pilih kebijakan keamanan Google Cloud Armor yang ada.
• Terima konfigurasi kebijakan keamanan pembatasan kapasitas Google Cloud Armor default dengan nama yang dapat disesuaikan, jumlah permintaan, interval, kunci, dan parameter pembatasan kapasitas. Jika Anda menggunakan Google Cloud Armor dengan layanan proxy upstream, seperti penyedia CDN, Enforce_on_key harus ditetapkan sebagai alamat IP XFF.
• Pilih untuk menonaktifkan perlindungan Google Cloud Armor dengan memilih Tidak ada.

IAP

IAP memungkinkan Anda membuat lapisan otorisasi pusat untuk aplikasi yang diakses melalui HTTPS, sehingga Anda dapat menggunakan model kontrol akses tingkat aplikasi, bukan mengandalkan firewall tingkat jaringan. IAP didukung oleh Load Balancer Aplikasi tertentu.

IAP tidak kompatibel dengan Cloud CDN. Keduanya tidak dapat diaktifkan di layanan backend yang sama.

Fitur pengelolaan traffic

Fitur berikut hanya didukung untuk beberapa produk:

• Kebijakan load balancing (localityLbPolicy) kecuali untuk ROUND_ROBIN
• Sirkuit rusak kecuali untuk kolom maxRequests
• Deteksi outlier

Fitur-fitur ini didukung oleh load balancer berikut:

• Load Balancer Aplikasi eksternal global (pemutusan arus listrik tidak didukung)

• Load Balancer Aplikasi eksternal regional

• Load Balancer Aplikasi internal lintas region

• Load Balancer Aplikasi internal regional

• Traffic Director (tetapi tidak didukung dengan layanan gRPC tanpa proxy)

Referensi API dan gcloud

Untuk mengetahui informasi selengkapnya tentang properti resource layanan backend, lihat referensi berikut:

* Resource API layanan backend global

* Resource API layanan backend regional

• Halaman gcloud compute backend-services, untuk layanan backend global dan regional

Langkah selanjutnya

Untuk dokumentasi dan informasi terkait tentang cara layanan backend digunakan dalam load balancing, tinjau artikel berikut:

• Membuat header kustom
• Membuat Load Balancer Aplikasi eksternal
• Ringkasan Load Balancer Aplikasi Eksternal
• Mengaktifkan pengosongan koneksi
• Enkripsi data dalam pengiriman di Google Cloud

Untuk video terkait:

• Cara mengonfigurasi layanan backend untuk Load Balancer Aplikasi eksternal global