Ringkasan Load Balancer Aplikasi Internal

Dokumen ini memperkenalkan konsep yang perlu Anda pahami untuk mengonfigurasi Load Balancer Aplikasi internal.

Load Balancer Aplikasi internal Google Cloud adalah load balancer lapisan 7 berbasis proxy yang dapat digunakan untuk menjalankan dan menskalakan layanan Anda melalui satu alamat IP internal. Load Balancer Aplikasi internal mendistribusikan traffic HTTP dan HTTPS ke backend yang dihosting di berbagai platform Google Cloud, seperti Compute Engine, Google Kubernetes Engine (GKE), dan Cloud Run. Untuk mengetahui detailnya, lihat Kasus penggunaan.

Mode operasi

Anda dapat mengonfigurasi Load Balancer Aplikasi internal dalam mode berikut:

• Load Balancer Aplikasi internal lintas region. Ini adalah load balancer multi-region yang diterapkan sebagai layanan terkelola berdasarkan proxy Envoy open source. Mode lintas region memungkinkan Anda melakukan load balancing terhadap traffic ke layanan backend yang didistribusikan secara global, termasuk pengelolaan traffic yang memastikan traffic diarahkan ke backend terdekat. Load balancer ini juga memungkinkan ketersediaan tinggi. Menempatkan backend di beberapa region akan membantu menghindari kegagalan di satu region. Jika backend satu region tidak aktif, traffic dapat beralih ke region lain.

• Load Balancer Aplikasi internal Regional. Ini adalah load balancer regional yang diterapkan sebagai layanan terkelola berdasarkan proxy Envoy open source. Mode regional memastikan bahwa semua klien dan backend berasal dari region yang ditentukan, yang membantu saat Anda membutuhkan kepatuhan regional. Load balancer ini diaktifkan dengan kemampuan kontrol traffic yang beragam berdasarkan parameter HTTP(S). Setelah dikonfigurasi, load balancer akan otomatis mengalokasikan proxy Envoy untuk memenuhi kebutuhan traffic Anda.

  Tabel berikut menjelaskan perbedaan penting antara mode regional dan lintas region:

  Fitur	Load Balancer Aplikasi internal lintas region	Load Balancer Aplikasi internal regional
  Alamat IP virtual (VIP) untuk load balancer.	Dialokasikan dari subnet di region Google Cloud tertentu. Alamat VIP dari beberapa region dapat berbagi layanan backend global yang sama. Anda dapat mengonfigurasi load balancing global berbasis DNS menggunakan kebijakan perutean DNS untuk mengarahkan permintaan klien ke alamat VIP terdekat.	Dialokasikan dari subnet di region Google Cloud tertentu.
  Akses klien	Selalu dapat diakses secara global. Klien dari region Google Cloud mana pun di VPC dapat mengirim traffic ke load balancer.	Tidak dapat diakses secara global secara default. Secara opsional, Anda dapat mengaktifkan akses global.
  Backend yang di-load balanced	Backend global. Load balancer dapat mengirim traffic ke backend di region mana pun.	Backend regional. Load balancer hanya dapat mengirim traffic ke backend yang berada di region yang sama dengan proxy load balancer.
  Ketersediaan tinggi dan failover	Failover otomatis ke backend yang responsif di region yang sama atau berbeda.	Failover otomatis ke backend yang responsif di region yang sama.

Mengidentifikasi mode

Cloud Console

1. Di Konsol Google Cloud, buka halaman Load balancing.

   Buka Load balancing

2. Di tab Load Balancer, Anda dapat melihat jenis, protokol, dan region load balancer. Jika region kosong, load balancer berada dalam mode lintas region. Tabel berikut merangkum cara mengidentifikasi mode load balancer.

   Mode load balancer	Jenis load balancer	Jenis akses	Region
   Load Balancer Aplikasi internal regional	Aplikasi	Internal	Menentukan wilayah
   Load Balancer Aplikasi internal lintas region	Aplikasi	Internal

gcloud

1. Untuk menentukan mode load balancer, jalankan perintah berikut:

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

   Di output perintah, periksa skema load balancing, region, dan tingkat jaringan. Tabel berikut merangkum cara mengidentifikasi mode load balancer.

   Mode load balancer	Skema load balancing	Aturan penerusan
   Load Balancer Aplikasi internal lintas region	INTERNAL_MANAGED	Global
   Load Balancer Aplikasi internal regional	INTERNAL_MANAGED	Regional

Penting: Setelah membuat load balancer, Anda tidak dapat mengedit modenya. Sebagai gantinya, Anda harus menghapus load balancer dan membuat yang baru.

Arsitektur dan referensi

Diagram berikut menunjukkan resource Google Cloud yang diperlukan untuk Load Balancer Aplikasi internal di setiap mode:

Lintas region

Diagram ini menunjukkan komponen deployment Load Balancer Aplikasi internal lintas region di Paket Premium dalam jaringan VPC yang sama. Setiap aturan penerusan global menggunakan alamat IP regional yang digunakan klien untuk terhubung.

Komponen Load Balancer Aplikasi internal lintas region (klik untuk memperbesar).

Regional

Diagram ini menunjukkan komponen deployment Load Balancer Aplikasi internal regional di Paket Premium.

Komponen Load Balancer Aplikasi internal Regional (klik untuk memperbesar).

Setiap Load Balancer Aplikasi internal menggunakan resource konfigurasi Google Cloud berikut.

Subnet khusus proxy

Pada diagram sebelumnya, subnet khusus proxy memberikan sekumpulan alamat IP yang digunakan Google untuk menjalankan proxy Envoy atas nama Anda. Anda harus membuat subnet khusus proxy di setiap region jaringan VPC tempat Anda menggunakan Load Balancer Aplikasi internal.

Tabel berikut menjelaskan perbedaan antara subnet khusus proxy dalam mode regional dan lintas region:

Mode load balancer	Nilai tanda --purpose subnet khusus proxy
Load Balancer Aplikasi internal lintas region	GLOBAL_MANAGED_PROXY Load balancer regional dan lintas region tidak dapat berbagi subnet yang sama Load balancer berbasis Envoy lintas region harus memiliki subnet khusus proxy di setiap region yang dikonfigurasi load balancer. Proxy load balancer lintas region di region dan jaringan yang sama memiliki subnet khusus proxy yang sama.
Load Balancer Aplikasi internal regional	REGIONAL_MANAGED_PROXY Load balancer regional dan lintas region tidak dapat berbagi subnet yang sama Semua load balancer berbasis Envoy regional di satu region dan jaringan VPC memiliki subnet khusus proxy yang sama

Lebih lanjut:

• Subnet khusus proxy hanya digunakan untuk proxy Envoy, bukan backend Anda.
• VM backend atau endpoint dari semua Load Balancer Aplikasi internal di suatu region dan jaringan VPC menerima koneksi dari subnet khusus proxy.
• Alamat IP virtual dari Load Balancer Aplikasi internal tidak berada di subnet khusus proxy. Alamat IP load balancer ditentukan oleh aturan penerusan terkelola internalnya, yang dijelaskan di bawah ini.

Aturan penerusan dan alamat IP

Aturan penerusan merutekan traffic menurut alamat IP, port, dan protokol ke konfigurasi load balancing yang terdiri dari proxy target dan layanan backend.

Setiap aturan penerusan merujuk pada satu alamat IP regional yang dapat digunakan dalam data DNS untuk aplikasi Anda. Anda dapat mencadangkan alamat IP statis yang dapat digunakan atau membiarkan Cloud Load Balancing menetapkannya untuk Anda. Sebaiknya cadangkan alamat IP statis. Jika tidak, Anda harus memperbarui data DNS dengan alamat IP efemeral yang baru ditetapkan setiap kali Anda menghapus aturan penerusan dan membuat yang baru.

Klien menggunakan port dan alamat IP untuk terhubung ke proxy Envoy load balancer. Alamat IP aturan penerusan adalah alamat IP load balancer (terkadang disebut alamat IP virtual atau VIP). Klien yang terhubung ke load balancer harus menggunakan HTTP versi 1.1 atau yang lebih baru. Untuk mengetahui daftar lengkap protokol yang didukung, lihat Fitur load balancer.

Alamat IP internal yang terkait dengan aturan penerusan dapat berasal dari subnet di jaringan dan region yang sama dengan backend Anda.

Setiap aturan penerusan untuk Load Balancer Aplikasi dapat mereferensikan port tunggal dari 1-65535. Untuk mendukung beberapa port, Anda harus mengonfigurasi beberapa aturan penerusan. Anda dapat mengonfigurasi beberapa aturan penerusan untuk menggunakan alamat IP internal (VIP) yang sama dan untuk mereferensikan proxy HTTP(S) target yang sama, asalkan kombinasi alamat IP, port, dan protokol tersebut bersifat unik untuk setiap aturan penerusan. Dengan cara ini, Anda dapat menggunakan satu load balancer dengan peta URL bersama sebagai proxy untuk beberapa aplikasi.

Tabel berikut menunjukkan perbedaan antara aturan penerusan dalam mode regional dan lintas region:

Mode load balancer	Aturan penerusan, alamat IP, dan subnet khusus proxy --purpose	Memilih rute dari klien ke frontend load balancer
Load Balancer Aplikasi internal lintas region	Aturan penerusan global Alamat IP regional Skema load balancing: INTERNAL_MANAGED Subnet khusus proxy --purpose: GLOBAL_MANAGED_PROXY Alamat IP --purpose: SHARED_LOADBALANCER_VIP	Akses global diaktifkan secara default untuk mengizinkan klien dari region mana pun di VPC mengakses load balancer Anda. Backend dapat berada di beberapa region.
Load Balancer Aplikasi internal regional	Aturan penerusan regional Alamat IP regional Skema load balancing: INTERNAL_MANAGED Subnet khusus proxy --purpose: REGIONAL_MANAGED_PROXY Alamat IP --purpose: SHARED_LOADBALANCER_VIP	Anda dapat mengaktifkan akses global untuk mengizinkan klien dari region mana pun di VPC mengakses load balancer Anda. Backend juga harus berada di region yang sama dengan load balancer.

Proxy target

Proxy HTTP(S) target menghentikan koneksi HTTP(S) dari klien. Proxy HTTP(S) melihat peta URL untuk menentukan cara mengarahkan traffic ke backend. Proxy HTTPS target menggunakan sertifikat SSL untuk mengautentikasi dirinya sendiri ke klien.

Load balancer mempertahankan header Host permintaan klien asli. Load balancer juga menambahkan dua alamat IP ke header X-Forwarded-For:

• Alamat IP klien yang terhubung ke load balancer
• Alamat IP aturan penerusan load balancer

Jika tidak ada header X-Forwarded-For pada permintaan masuk, kedua alamat IP ini adalah seluruh nilai header. Jika permintaan memiliki header X-Forwarded-For, informasi lain, seperti alamat IP yang dicatat oleh proxy dalam proses ke load balancer, akan dipertahankan sebelum kedua alamat IP tersebut. Load balancer tidak memverifikasi alamat IP apa pun yang mendahului dua alamat IP terakhir di header ini.

Jika Anda menjalankan proxy sebagai server backend, proxy ini biasanya menambahkan informasi lebih lanjut ke header X-Forwarded-For, dan software Anda mungkin perlu mempertimbangkannya. Permintaan melalui proxy dari load balancer berasal dari alamat IP di subnet khusus proxy, dan proxy Anda di instance backend dapat mencatat alamat ini dan alamat IP instance backend itu sendiri.

Bergantung pada jenis traffic yang perlu ditangani aplikasi, Anda dapat mengonfigurasi load balancer dengan proxy HTTP target atau proxy HTTPS target.

Tabel berikut menunjukkan API proxy target yang diperlukan oleh Load Balancer Aplikasi internal di setiap mode:

Proxy target	Load Balancer Aplikasi internal lintas region	Load Balancer Aplikasi internal regional
HTTP	targetHttpProxies global	regionTargetHttpProxies
HTTPS	targetHttpsProxies global	regionTargetHttpsProxies

Sertifikat SSL

Load Balancer Aplikasi Internal yang menggunakan proxy HTTPS target memerlukan kunci pribadi dan sertifikat SSL sebagai bagian dari konfigurasi load balancer.

Tabel berikut menentukan jenis sertifikat SSL yang diperlukan oleh Load Balancer Aplikasi internal di setiap mode:

Mode load balancer	Jenis sertifikat SSL
Load Balancer Aplikasi internal regional	Sertifikat SSL regional Compute Engine Sertifikat yang dikelola sendiri secara regional dan sertifikat yang dikelola Google oleh Certificate Manager. Jenis sertifikat yang dikelola Google berikut ini didukung dengan Certificate Manager: Sertifikat regional yang dikelola Google dengan otorisasi DNS per project. Untuk informasi selengkapnya, lihat Men-deploy sertifikat regional yang dikelola Google. Sertifikat regional yang dikelola Google dengan Certificate Authority Service pribadi. Untuk informasi selengkapnya, lihat Men-deploy sertifikat regional yang dikelola Google dengan CA Service. Sertifikat yang dikelola Google dengan otorisasi load balancer tidak didukung.
Load Balancer Aplikasi internal lintas region	Pengelola Sertifikat sertifikat yang dikelola sendiri dan sertifikat yang dikelola Google. Jenis sertifikat yang dikelola Google berikut ini didukung dengan Certificate Manager: Otorisasi DNS dengan DNS Publik. Untuk informasi selengkapnya, lihat Membuat sertifikat yang dikelola Google dengan otorisasi DNS. {i>Private Certificate Authority Service<i}. Untuk informasi selengkapnya, lihat Membuat sertifikat yang dikelola Google yang diterbitkan oleh instance CA Service Anda. Sertifikat yang dikelola Google dengan otorisasi load balancer tidak didukung. Sertifikat SSL Compute Engine tidak didukung.

Peta URL

Proxy HTTP(S) target menggunakan peta URL untuk membuat penentuan pemilihan rute berdasarkan atribut HTTP (seperti jalur permintaan, cookie, atau header). Berdasarkan keputusan pemilihan rute, proxy akan meneruskan permintaan klien ke layanan backend tertentu. Peta URL dapat menentukan tindakan tambahan yang akan diambil, seperti menulis ulang header, mengirim pengalihan ke klien, dan mengonfigurasi kebijakan waktu tunggu (antara lain).

Tabel berikut menentukan jenis peta URL yang diperlukan oleh Load Balancer Aplikasi internal di setiap mode:

Mode load balancer	Jenis peta URL
Load Balancer Aplikasi internal lintas region	Peta URL global
Load Balancer Aplikasi internal regional	Peta URL wilayah

Layanan backend

Layanan backend mendistribusikan permintaan ke backend yang responsif: grup instance yang berisi VM Compute Engine, Cloud Run, atau NEG yang berisi container GKE.

Layanan backend mendukung protokol HTTP, HTTPS, atau HTTP/2. HTTP/2 hanya didukung melalui TLS. Klien dan backend tidak perlu menggunakan protokol permintaan yang sama. Misalnya, klien dapat mengirim permintaan ke load balancer dengan menggunakan HTTP/2, dan load balancer dapat meneruskan permintaan ini ke backend menggunakan HTTP/1.1.

Tabel berikut menentukan jenis layanan backend yang diperlukan oleh Load Balancer Aplikasi internal di setiap mode:

Mode load balancer	Jenis layanan backend
Load Balancer Aplikasi internal lintas region	backendServices global
Load Balancer Aplikasi internal regional	Layanan backend regional

Tabel berikut menentukan fitur backend yang didukung oleh Load Balancer Aplikasi internal di setiap mode:

Mode load balancer	Backend yang didukung di layanan backend						Mendukung bucket backend	Mendukung Google Cloud Armor	Mendukung Cloud CDN	Mendukung IAP	Mendukung Ekstensi Layanan
	Grup instance	NEGARA ZONA	NEG Internet	NEG Tanpa Server	NEG Hybrid	NEG Private Service Connect
Load Balancer Aplikasi internal lintas region		^2		Cloud Run
Load Balancer Aplikasi internal regional		^1		Cloud Run

¹ Gunakan endpoint jenis GCE_VM_IP_PORT dengan GKE: Gunakan NEG zona mandiri atau gunakan Ingress

² Menggunakan endpoint jenis GCE_VM_IP_PORT dengan GKE: Menggunakan NEG zona mandiri

Catatan:

• Anda tidak dapat menggunakan grup instance dan NEG pada layanan backend yang sama.

• Jika Anda berbagi grup instance yang sama untuk layanan backend global dan regional, konfigurasikan kebijakan penskalaan otomatis grup instance agar menggunakan beberapa sinyal.

Untuk mengetahui informasi selengkapnya, lihat Ringkasan layanan backend.

Backend dan jaringan VPC

Semua backend harus berada di jaringan VPC yang sama. Menempatkan backend di jaringan VPC yang berbeda, bahkan yang terhubung menggunakan Peering Jaringan VPC, tidak didukung. Untuk mengetahui detail tentang bagaimana sistem klien di jaringan VPC yang di-peering dapat mengakses load balancer, lihat Load Balancer Aplikasi Internal dan jaringan yang terhubung.

Subsetelan backend

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.

Subsetelan backend adalah fitur opsional yang didukung oleh Load Balancer Aplikasi internal regional yang meningkatkan performa dan skalabilitas dengan menetapkan subset backend ke setiap instance proxy.

Secara default, subsetelan backend dinonaktifkan. Untuk mengetahui informasi tentang cara mengaktifkan fitur ini, lihat Subsetelan backend untuk Load Balancer Aplikasi internal.

Health check

Setiap layanan backend menentukan health check yang secara berkala memantau kesiapan backend untuk menerima koneksi dari load balancer. Tindakan ini mengurangi risiko permintaan dikirim ke backend yang tidak dapat melayani permintaan tersebut. Health check tidak memeriksa apakah aplikasi itu sendiri berfungsi.

Agar pemeriksaan health check berhasil, Anda harus membuat aturan firewall izin Ingress yang memungkinkan pemeriksaan health check menjangkau instance backend Anda. Biasanya, pemeriksaan health check berasal dari mekanisme health check terpusat Google. Namun, untuk NEG hybrid, health check berasal dari subnet khusus proxy. Untuk mengetahui detailnya, lihat health check Envoy terdistribusi di ringkasan NEG Hybrid.

Protokol health check

Meskipun tidak diwajibkan dan tidak selalu memungkinkan, praktik terbaiknya adalah menggunakan health check yang protokolnya cocok dengan protokol layanan backend. Misalnya, health check HTTP/2 paling akurat menguji konektivitas HTTP/2 ke backend. Sebaliknya, Load Balancer Aplikasi internal yang menggunakan backend NEG hybrid tidak mendukung health check gRPC. Untuk mengetahui daftar protokol health check yang didukung, lihat Fitur load balancing.

Tabel berikut menentukan cakupan health check yang didukung oleh Load Balancer Aplikasi internal di setiap mode:

Mode load balancer	Jenis health check
Load Balancer Aplikasi internal lintas region	Global
Load Balancer Aplikasi internal regional	Regional

Untuk mengetahui informasi selengkapnya tentang health check, lihat berikut ini:

• Ringkasan health check
• Membuat health check

Aturan firewall

Load Balancer Aplikasi internal memerlukan aturan firewall berikut:

• Aturan izinkan masuk yang mengizinkan traffic dari rentang health check pusat Google.
  • 35.191.0.0/16
  • 130.211.0.0/22
• Aturan izinkan masuk yang mengizinkan traffic dari subnet khusus proxy.

Ada pengecualian tertentu pada persyaratan aturan firewall untuk rentang ini:

• Mengizinkan rentang pemeriksaan health check Google tidak diperlukan untuk NEG campuran. Namun, jika menggunakan kombinasi NEG campuran dan zona dalam satu layanan backend, Anda harus mengizinkan rentang pemeriksaan health check Google untuk NEG zona.
• Untuk NEG internet regional, health check bersifat opsional. Traffic dari load balancer yang menggunakan NEG internet regional berasal dari subnet khusus proxy dan kemudian diterjemahkan NAT (dengan menggunakan Cloud NAT) ke alamat IP NAT yang dialokasikan secara manual atau otomatis. Traffic ini mencakup pemeriksaan health check dan permintaan pengguna dari load balancer ke backend. Untuk mengetahui detailnya, lihat NEG Regional: Gunakan Cloud NAT untuk keluar.

Akses klien

Klien dapat berada di jaringan yang sama atau dalam jaringan VPC yang terhubung menggunakan Peering Jaringan VPC.

Untuk Load Balancer Aplikasi internal lintas region, akses global diaktifkan secara default. Klien dari region mana pun di VPC dapat mengakses load balancer Anda.

Untuk Load Balancer Aplikasi internal regional, klien harus berada di region yang sama dengan load balancer secara default. Anda dapat mengaktifkan akses global agar klien dari region mana pun di VPC dapat mengakses load balancer Anda.

Tabel berikut meringkas akses klien untuk Load Balancer Aplikasi internal regional:

Akses global dinonaktifkan	Akses global diaktifkan
Klien harus berada di region yang sama dengan load balancer. Komponen tersebut juga harus berada di jaringan VPC yang sama dengan load balancer atau di jaringan VPC yang terhubung ke jaringan VPC load balancer menggunakan Peering Jaringan VPC.	Klien dapat berada di region mana pun. Keduanya tetap harus berada di jaringan VPC yang sama dengan load balancer atau di jaringan VPC yang terhubung ke jaringan VPC load balancer menggunakan Peering Jaringan VPC.
Klien lokal dapat mengakses load balancer melalui tunnel Cloud VPN atau lampiran VLAN. Tunnel atau lampiran ini harus berada di region yang sama dengan load balancer.	Klien lokal dapat mengakses load balancer melalui tunnel Cloud VPN atau lampiran VLAN. Tunnel atau lampiran ini dapat berada di region mana saja.

Arsitektur VPC Bersama

Load Balancer Aplikasi Internal mendukung jaringan yang menggunakan VPC Bersama. Dengan VPC Bersama, organisasi dapat menghubungkan resource dari beberapa project ke jaringan VPC umum, sehingga mereka dapat berkomunikasi satu sama lain dengan aman dan efisien menggunakan IP internal dari jaringan tersebut. Jika Anda belum terbiasa dengan VPC Bersama, baca dokumentasi ringkasan VPC Bersama.

Ada banyak cara untuk mengonfigurasi Load Balancer Aplikasi internal dalam jaringan VPC Bersama. Apa pun jenis deployment, semua komponen load balancer harus berada dalam organisasi yang sama.

Subnet dan alamat IP	Komponen {i>frontend<i}	Komponen backend
Buat jaringan dan subnet yang diperlukan (termasuk subnet khusus proxy), di project host VPC Bersama. Alamat IP internal load balancer dapat ditentukan dalam project host atau project layanan, tetapi harus menggunakan subnet di jaringan VPC Bersama yang diinginkan dalam project host. Alamat itu sendiri berasal dari rentang IP utama dari subnet yang dirujuk.	Alamat IP internal regional, aturan penerusan, proxy HTTP(S) target, dan peta URL terkait harus ditetapkan dalam project yang sama. Project ini dapat berupa project host atau project layanan.	Anda dapat melakukan salah satu tindakan berikut: Buat layanan backend dan backend (grup instance, NEG serverless, atau jenis backend lain yang didukung) dalam project layanan yang sama dengan komponen frontend. Buat layanan backend dan backend (grup instance, NEG serverless, atau jenis backend lain yang didukung) di sebanyak mungkin project layanan yang diperlukan. Satu peta URL dapat mereferensikan layanan backend di berbagai project. Jenis deployment ini dikenal sebagai referensi layanan lintas-project. Setiap layanan backend harus ditentukan dalam project yang sama dengan backend yang direferensikannya. Health check yang terkait dengan layanan backend harus ditentukan dalam project yang sama dengan layanan backend juga.

Meskipun Anda dapat membuat semua komponen dan backend load balancing di project host VPC Bersama, jenis deployment ini tidak memisahkan tanggung jawab administrasi jaringan dan pengembangan layanan.

Semua komponen dan backend load balancer dalam sebuah project layanan

Diagram arsitektur berikut menunjukkan deployment VPC Bersama standar tempat semua komponen dan backend load balancer berada dalam sebuah project layanan. Jenis deployment ini didukung oleh semua Load Balancer Aplikasi.

Load balancer menggunakan alamat IP dan subnet dari project host. Klien dapat mengakses Load Balancer Aplikasi internal jika berada di jaringan dan region VPC Bersama yang sama dengan load balancer. Klien dapat berada di project host, atau dalam project layanan yang terpasang, atau jaringan yang terhubung.

Load Balancer Aplikasi Internal di jaringan VPC Bersama

Backend serverless di lingkungan VPC Bersama**

Untuk Load Balancer Aplikasi internal yang menggunakan backend NEG serverless, layanan Cloud Run pendukung harus berada dalam project layanan yang sama dengan layanan backend dan NEG serverless. Komponen frontend load balancer (aturan penerusan, proxy target, peta URL) dapat dibuat di project host, project layanan yang sama dengan komponen backend, atau project layanan lainnya di lingkungan VPC Bersama yang sama.

Rujukan layanan lintas project

Dalam model ini, peta URL dan frontend load balancer berada dalam project layanan atau host. Layanan backend dan backend load balancer dapat didistribusikan ke seluruh project di lingkungan VPC Bersama. Layanan backend lintas project dapat direferensikan di satu peta URL. Hal ini disebut sebagai referensi layanan lintas-project.

Dengan referensi layanan lintas project, organisasi dapat mengonfigurasi satu load balancer pusat dan merutekan traffic ke ratusan layanan yang didistribusikan di berbagai project. Anda dapat mengelola semua aturan dan kebijakan rute lalu lintas secara terpusat dalam satu peta URL. Anda juga dapat mengaitkan load balancer dengan satu set nama host dan sertifikat SSL. Oleh karena itu, Anda dapat mengoptimalkan jumlah load balancer yang diperlukan untuk men-deploy aplikasi, serta mengelola pengelolaan, biaya operasional, dan persyaratan kuota yang lebih rendah.

Dengan memiliki project yang berbeda untuk setiap tim fungsional, Anda juga dapat mencapai pemisahan peran dalam organisasi Anda. Pemilik layanan dapat berfokus pada pembuatan layanan di project layanan, sementara tim jaringan dapat menyediakan dan mempertahankan load balancer di project lain, dan keduanya dapat dihubungkan dengan menggunakan referensi layanan lintas project.

Pemilik layanan dapat mempertahankan otonomi atas eksposur layanan mereka dan mengontrol pengguna mana yang dapat mengakses layanan mereka menggunakan load balancer. Hal ini dicapai oleh peran IAM khusus yang disebut peran Pengguna Layanan Load Balancer Compute (roles/compute.loadBalancerServiceUser).

Untuk mempelajari cara mengonfigurasi VPC Bersama untuk Load Balancer Aplikasi internal—dengan dan tanpa rujukan layanan lintas-project, baca artikel Menyiapkan Load Balancer Aplikasi internal dengan VPC Bersama.

Batasan umum pada referensi layanan lintas-project

• Anda tidak dapat mereferensikan layanan backend lintas project jika layanan backend memiliki backend NEG internet regional. Semua jenis backend lainnya didukung.
• Google Cloud tidak membedakan beberapa resource (misalnya, layanan backend) yang menggunakan nama yang sama di beberapa project. Oleh karena itu, saat Anda menggunakan referensi layanan lintas-project, sebaiknya gunakan nama layanan backend yang unik di seluruh project dalam organisasi Anda.

Contoh 1: Frontend dan backend load balancer di berbagai project layanan

Berikut adalah contoh deployment dengan frontend dan peta URL load balancer yang dibuat di project layanan A dan peta URL mereferensikan layanan backend di project layanan B.

Dalam hal ini, Admin Jaringan atau Admin Load Balancer di project layanan A akan memerlukan akses ke layanan backend di project layanan B. Admin project layanan B memberikan peran IAM compute.loadBalancerServiceUser kepada Admin Load Balancer di project layanan A yang ingin mereferensikan layanan backend di project layanan B.

Frontend dan backend load balancer di berbagai project layanan

Contoh 2: Frontend load balancer di project host dan backend di project layanan

Pada jenis deployment ini, peta URL dan frontend load balancer dibuat di project host, sedangkan layanan backend (serta backend) dibuat dalam project layanan.

Dalam hal ini, Admin Jaringan atau Admin Load Balancer di project host akan memerlukan akses ke layanan backend dalam project layanan. Admin project layanan memberikan peran IAM compute.loadBalancerServiceUser kepada Admin Load Balancer di project host A yang ingin mereferensikan layanan backend di project layanan.

Peta URL dan frontend load balancer di project host

Waktu tunggu dan percobaan ulang

Load Balancer Aplikasi Internal mendukung jenis waktu tunggu berikut:

Jenis dan deskripsi waktu tunggu	Nilai default	Mendukung nilai kustom
		Waktu tunggu layanan backend Waktu tunggu permintaan dan respons. Menyatakan jumlah waktu maksimum yang dapat berlalu dari saat load balancer mengirimkan byte pertama permintaan HTTP ke backend Anda hingga saat backend menampilkan byte terakhir dari respons HTTP. Jika seluruh respons HTTP belum ditampilkan ke load balancer selama waktu tunggu permintaan atau respons habis, data respons yang tersisa akan dihapus.	Untuk NEG serverless di layanan backend: 60 menit Untuk semua jenis backend lainnya di layanan backend: 30 detik
Waktu tunggu keepalive HTTP Klien Jumlah waktu maksimum saat koneksi TCP antara klien dan proxy Envoy yang dikelola load balancer dapat menjadi tidak ada aktivitas. (Koneksi TCP yang sama dapat digunakan untuk beberapa permintaan HTTP.)	10 menit (600 detik)
Waktu tunggu keepalive HTTP backend Jumlah waktu maksimum saat koneksi TCP antara proxy Envoy terkelola load balancer dan backend boleh tidak ada aktivitas. (Koneksi TCP yang sama dapat digunakan untuk beberapa permintaan HTTP.)	10 menit (600 detik)

Waktu tunggu layanan backend

Waktu tunggu layanan backend yang dapat dikonfigurasi menunjukkan jumlah waktu maksimum yang dihabiskan load balancer untuk menunggu backend Anda memproses permintaan HTTP dan menampilkan respons HTTP yang sesuai. Kecuali untuk NEG serverless, nilai default waktu tunggu layanan backend adalah 30 detik.

Misalnya, jika Anda ingin mendownload file berukuran 500 MB dan nilai waktu tunggu layanan backend adalah 90 detik, load balancer mengharapkan backend mengirimkan seluruh file berukuran 500 MB dalam waktu 90 detik. Anda dapat mengonfigurasi waktu tunggu layanan backend agar tidak cukup bagi backend untuk mengirim respons HTTP secara lengkap. Dalam situasi ini, jika load balancer setidaknya telah menerima header respons HTTP dari backend, load balancer akan menampilkan header respons lengkap dan isi respons sebanyak mungkin yang dapat diperoleh selama waktu tunggu layanan backend habis.

Anda harus menetapkan waktu tunggu layanan backend ke jangka waktu terlama yang Anda harapkan akan diperlukan backend untuk memproses respons HTTP. Anda harus meningkatkan waktu tunggu layanan backend jika software yang berjalan di backend memerlukan lebih banyak waktu untuk memproses permintaan HTTP dan menampilkan seluruh responsnya.

Waktu tunggu layanan backend menerima nilai antara 1 dan 2,147,483,647 detik; namun, nilai yang lebih besar bukanlah opsi konfigurasi yang praktis. Google Cloud tidak menjamin bahwa koneksi TCP dasar dapat tetap terbuka selama keseluruhan nilai waktu tunggu layanan backend. Sistem klien harus mengimplementasikan logika mencoba ulang, bukan mengandalkan koneksi TCP agar terbuka dalam jangka waktu yang lama.

Untuk koneksi WebSocket yang digunakan dengan Load Balancer Aplikasi internal, koneksi WebSocket aktif tidak mengikuti waktu tunggu layanan backend. Koneksi WebSocket tidak ada aktivitas ditutup setelah waktu tunggu layanan backend habis.

Google Cloud memulai ulang atau mengubah jumlah tugas software Envoy secara berkala. Makin lama nilai waktu tunggu layanan backend, makin besar kemungkinan tugas Envoy dimulai ulang atau penggantian akan menghentikan koneksi TCP.

Untuk mengonfigurasi waktu tunggu layanan backend, gunakan salah satu metode berikut:

• Konsol Google Cloud: Ubah kolom Timeout di layanan backend load balancer.
• Google Cloud CLI: Gunakan perintah gcloud compute backend-services update untuk mengubah parameter --timeout dari resource layanan backend.
• API: Ubah parameter timeoutSec untuk resource regionBackendServices.

Waktu tunggu keepalive HTTP klien

Waktu tunggu HTTP klien habis menunjukkan jumlah waktu maksimum saat koneksi TCP dapat tidak ada aktivitas antara klien (downstream) dan proxy Envoy. Nilai waktu tunggu keepalive HTTP klien tetap pada 600 detik.

Waktu tunggu keepalive HTTP juga disebut Waktu tunggu tidak ada aktivitas TCP.

Waktu tunggu keepalive HTTP klien load balancer harus lebih besar daripada waktu tunggu HTTP keepalive (TCP tidak ada aktivitas) yang digunakan oleh klien atau proxy downstream. Jika klien downstream memiliki waktu tunggu keepalive HTTP (TCP tidak ada aktivitas) yang lebih besar daripada waktu tunggu keepalive HTTP klien load balancer, kondisi race dapat terjadi. Dari perspektif klien downstream, koneksi TCP yang dibuat diizinkan untuk tidak ada aktivitas selama lebih lama dari yang diizinkan oleh load balancer. Ini berarti bahwa klien downstream dapat mengirim paket setelah load balancer menganggap koneksi TCP ditutup. Jika hal itu terjadi, load balancer merespons dengan paket reset TCP (RST).

Waktu tunggu keepalive HTTP backend

Load Balancer Aplikasi Internal adalah proxy yang menggunakan koneksi TCP pertama antara klien (downstream) dan proxy Envoy, serta koneksi TCP kedua antara proxy Envoy dan backend Anda.

Koneksi TCP sekunder load balancer mungkin tidak ditutup setelah setiap permintaan. Koneksi TCP sekunder load balancer mungkin tidak ditutup setelah setiap permintaan. Koneksi TCP sekunder load balancer dapat tetap terbuka untuk menangani beberapa permintaan dan respons HTTP. Waktu tunggu keepalive HTTP backend menentukan waktu tunggu tidak ada aktivitas TCP antara load balancer dan backend Anda. Waktu tunggu keepalive HTTP backend tidak berlaku untuk WebSockets.

Waktu tunggu keepalive backend ditetapkan tetap 10 menit (600 detik) dan tidak dapat diubah. Waktu tunggu keepalive backend load balancer harus kurang dari waktu tunggu keepalive yang digunakan oleh software yang berjalan di backend Anda. Hal ini akan menghindari kondisi race saat sistem operasi backend Anda mungkin menutup koneksi TCP dengan reset TCP (RST). Karena waktu tunggu keepalive backend untuk load balancer tidak dapat dikonfigurasi, Anda harus mengonfigurasi software backend agar nilai waktu tunggu HTTP keepalive (TCP tidak ada aktivitas) lebih besar dari 600 detik.

Tabel berikut mencantumkan perubahan yang diperlukan untuk mengubah nilai waktu tunggu keepalive untuk software server web umum.

Software server web	Parameter	Setelan default	Setelan yang direkomendasikan
Apache	KeepAliveTimeout	KeepAliveTimeout 5	KeepAliveTimeout 620
nginx	keepalive_timeout	keepalive_timeout 75s;	keepalive_timeout 620s;

Upaya coba lagi

Untuk mengonfigurasi percobaan ulang, Anda dapat menggunakan kebijakan coba lagi di peta URL. Jumlah default percobaan ulang (numRetries) adalah 1. Waktu tunggu default untuk setiap percobaan (perTryTimeout) adalah 30 detik dengan perTryTimeout maksimum yang dapat dikonfigurasi selama 24 jam.

Tanpa kebijakan percobaan ulang, permintaan yang gagal dan tidak memiliki isi HTTP (misalnya, permintaan GET) yang menghasilkan respons 502, 503, atau 504 HTTP akan dicoba ulang sekali.

Permintaan POST HTTP tidak dicoba lagi.

Permintaan yang dicoba lagi hanya akan menghasilkan satu entri log untuk respons akhir.

Untuk mengetahui informasi selengkapnya, baca Logging dan pemantauan Load Balancer Aplikasi Internal.

Mengakses jaringan yang terhubung

Anda dapat mengakses Load Balancer Aplikasi internal di jaringan VPC Anda dari jaringan yang terhubung dengan cara berikut:

• Peering Jaringan VPC
• Cloud VPN dan Cloud Interconnect

Untuk contoh mendetail, lihat Load Balancer Aplikasi Internal dan jaringan yang terhubung.

Failover

Jika backend tidak responsif, traffic akan otomatis dialihkan ke backend yang responsif.

Tabel berikut menjelaskan perilaku failover dalam setiap mode:

Mode load balancer	Perilaku failover	Perilaku saat semua backend tidak responsif
Load Balancer Aplikasi internal lintas region	Failover otomatis ke backend yang responsif di region yang sama atau region lain. Traffic didistribusikan di antara backend yang responsif yang mencakup beberapa region berdasarkan distribusi traffic yang dikonfigurasi.	Menampilkan HTTP 503
Load Balancer Aplikasi internal regional	Failover otomatis ke backend yang responsif di region yang sama. Proxy Envoy mengirimkan traffic ke backend yang responsif di suatu region berdasarkan distribusi traffic yang dikonfigurasi.	Menampilkan HTTP 503

Ketersediaan tinggi dan failover lintas region

Anda dapat menyiapkan Load Balancer Aplikasi internal lintas region di beberapa region untuk mendapatkan manfaat berikut:

1. Jika Load Balancer Aplikasi internal lintas region di suatu region gagal, kebijakan perutean DNS akan merutekan traffic ke Load Balancer Aplikasi internal lintas region di region lain.

   Contoh deployment ketersediaan tinggi menampilkan hal berikut:

   • Load Balancer Aplikasi internal lintas region dengan alamat IP virtual (VIP) frontend di region RegionA dan RegionB di jaringan VPC Anda. Klien Anda berada di region RegionA.
   • Anda dapat membuat load balancer dapat diakses dengan menggunakan VIP frontend dari dua region, dan menggunakan kebijakan perutean DNS untuk menampilkan VIP yang optimal kepada klien Anda. Gunakan kebijakan pemilihan rute Geolokasi jika Anda ingin klien menggunakan VIP yang paling dekat secara geografis.
   • Kebijakan perutean DNS dapat mendeteksi apakah VIP tidak merespons selama pemadaman layanan regional, dan menampilkan VIP paling optimal berikutnya kepada klien Anda, sehingga memastikan aplikasi Anda tetap aktif bahkan selama pemadaman layanan regional.

   

   Load Balancer Aplikasi internal lintas region dengan deployment ketersediaan tinggi (klik untuk memperbesar).

2. Jika backend di region tertentu tidak berfungsi, traffic Load Balancer Aplikasi internal lintas region akan gagal berpindah ke backend di region lain dengan baik.

   Contoh deployment failover lintas region menunjukkan hal berikut:

   • Load Balancer Aplikasi internal lintas region dengan alamat VIP frontend di region RegionA pada jaringan VPC Anda. Klien Anda juga berada di region RegionA.
   • Layanan backend global yang mereferensikan backend di region Google Cloud RegionA dan RegionB.
   • Saat backend di region RegionA tidak aktif, traffic akan gagal ke region RegionB.

   

   Load Balancer Aplikasi internal lintas region dengan deployment failover lintas region (klik untuk memperbesar).

Dukungan WebSocket

Load balancer berbasis HTTP(S) Google Cloud memiliki dukungan bawaan untuk protokol WebSocket saat Anda menggunakan HTTP atau HTTPS sebagai protokol ke backend. Load balancer tidak memerlukan konfigurasi apa pun untuk melakukan proxy koneksi WebSocket.

Protokol WebSocket menyediakan saluran komunikasi full-duplex antara klien dan server. Permintaan HTTP(S) akan memulai saluran. Untuk mengetahui informasi selengkapnya tentang protokol, lihat RFC 6455.

Jika load balancer mengenali permintaan Upgrade WebSocket dari klien HTTP(S) diikuti dengan respons Upgrade yang berhasil dari instance backend, load balancer akan melakukan proxy traffic dua arah selama durasi koneksi saat ini. Jika backend instance tidak menampilkan respons Upgrade yang berhasil, load balancer akan menutup koneksi.

Afinitas sesi untuk WebSockets berfungsi sama seperti permintaan lainnya. Untuk mengetahui informasinya, lihat Afinitas sesi.

Dukungan gRPC

gRPC adalah framework open source untuk panggilan prosedur jarak jauh. Ini didasarkan pada standar HTTP/2. Kasus penggunaan untuk gRPC mencakup hal berikut:

• Sistem berlatensi rendah, sangat skalabel, dan terdistribusi
• Mengembangkan klien seluler yang berkomunikasi dengan server {i>cloud<i}
• Merancang protokol baru yang harus akurat, efisien, dan tidak bergantung pada bahasa
• Desain berlapis untuk mengaktifkan ekstensi, autentikasi, dan logging

Untuk menggunakan gRPC dengan aplikasi Google Cloud, Anda harus membuat proxy permintaan secara menyeluruh melalui HTTP/2. Untuk melakukan ini:

1. Mengonfigurasi load balancer HTTPS.
2. Mengaktifkan HTTP/2 sebagai protokol dari load balancer ke backend.

Load balancer menegosiasikan HTTP/2 dengan klien sebagai bagian dari handshake SSL dengan menggunakan ekstensi TLS ALPN.

Load balancer mungkin masih menegosiasikan HTTPS dengan beberapa klien, atau menerima permintaan HTTP yang tidak aman pada load balancer yang dikonfigurasi untuk menggunakan HTTP/2 antara load balancer dan backend instance. Permintaan HTTP atau HTTPS tersebut diubah oleh load balancer untuk mem-proxy permintaan melalui HTTP/2 ke backend instance.

Anda harus mengaktifkan TLS di backend. Untuk mengetahui informasi selengkapnya, lihat Enkripsi dari load balancer ke backend.

Dukungan TLS

Secara default, proxy target HTTPS hanya menerima TLS 1.0, 1.1, 1.2, dan 1.3 saat menghentikan permintaan SSL klien.

Jika Load Balancer Aplikasi internal menggunakan HTTPS sebagai protokol layanan backend, Load Balancer Aplikasi dapat menegosiasikan TLS 1.0, 1.1, 1.2, atau 1.3 ke backend.

Batasan

• Tidak ada jaminan bahwa permintaan dari klien di satu zona region dikirim ke backend yang berada di zona yang sama dengan klien. Afinitas sesi tidak mengurangi komunikasi antar-zona.

• Load Balancer Aplikasi Internal tidak kompatibel dengan fitur berikut:

  • Cloud CDN
  • Google Cloud Armor
  • Bucket Cloud Storage
  • Sertifikat SSL yang dikelola Google

• Load Balancer Aplikasi internal hanya mendukung HTTP/2 melalui TLS.

• Klien yang terhubung ke Load Balancer Aplikasi internal harus menggunakan HTTP versi 1.1 atau yang lebih baru. HTTP 1.0 tidak didukung.

• Google Cloud tidak memperingatkan Anda jika subnet khusus proxy kehabisan alamat IP.

• Aturan penerusan internal yang digunakan Load Balancer Aplikasi internal Anda harus memiliki tepat satu port.

• Load Balancer Aplikasi Internal tidak mendukung Cloud Trace.

• Saat menggunakan Load Balancer Aplikasi internal dengan Cloud Run di lingkungan VPC Bersama, jaringan VPC yang berdiri sendiri dalam project layanan dapat mengirim traffic ke layanan Cloud Run lain yang di-deploy di project layanan lain dalam lingkungan VPC Bersama yang sama. Ini adalah masalah umum dan bentuk akses ini akan diblokir di masa mendatang.

• Google Cloud tidak menjamin bahwa koneksi TCP dasar dapat tetap terbuka selama keseluruhan nilai waktu tunggu layanan backend. Sistem klien harus menerapkan logika mencoba ulang, bukan mengandalkan koneksi TCP agar terbuka dalam waktu yang lama.

Langkah selanjutnya

• Untuk mengonfigurasi load balancing pada penyiapan VPC Bersama, baca artikel Menyiapkan Load Balancer Aplikasi internal untuk VPC Bersama.
• Untuk mengonfigurasi load balancing bagi layanan Anda yang berjalan di pod GKE, lihat Men-deploy Gateway GKE, load balancing berbasis container dengan NEG mandiri, dan bagian Melampirkan Load Balancer Aplikasi internal ke NEG mandiri.
• Untuk mengonfigurasi Load Balancer Aplikasi internal regional dengan Private Service Connect, lihat Mengonfigurasi Private Service Connect dengan kontrol layanan HTTP(S) konsumen.
• Untuk mengelola resource subnet khusus proxy, lihat Subnet khusus proxy.
• Untuk mengonfigurasi subset backend di Load Balancer Aplikasi internal regional, lihat Subsetelan backend.
• Untuk memasukkan logika kustom ke jalur data load balancing, konfigurasikan info Ekstensi Layanan.