Ringkasan Load Balancer Aplikasi Eksternal

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

Load Balancer Aplikasi eksternal adalah load balancer Lapisan 7 berbasis proxy yang memungkinkan Anda menjalankan dan menskalakan layanan di balik satu alamat IP eksternal. Load Balancer Aplikasi eksternal mendistribusikan traffic HTTP dan HTTPS ke backend yang dihosting di berbagai platform Google Cloud (seperti Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage, dan sebagainya), serta backend eksternal yang terhubung melalui internet atau melalui konektivitas campuran. Untuk mengetahui detailnya, lihat Ringkasan Load Balancer Aplikasi: Kasus penggunaan.

Mode operasi

Anda dapat mengonfigurasi Load Balancer Aplikasi eksternal dalam mode berikut:

• Load Balancer Aplikasi eksternal global. Ini adalah load balancer global yang diimplementasikan sebagai layanan terkelola di Google Front End (GFE). Layanan ini menggunakan proxy Envoy open source untuk mendukung kemampuan pengelolaan traffic lanjutan seperti pencerminan traffic, pemisahan traffic berbasis bobot, transformasi header berbasis permintaan/respons, dan lainnya.
• Load Balancer Aplikasi Klasik. Ini adalah Load Balancer Aplikasi eksternal klasik yang bersifat global di Paket Premium, tetapi dapat dikonfigurasi menjadi regional di Paket Standar. Load balancer ini diterapkan di Google Front End (GFE). GFE didistribusikan secara global dan beroperasi bersama menggunakan jaringan global dan bidang kontrol Google.
• Load Balancer Aplikasi eksternal regional. Ini adalah load balancer regional yang diterapkan sebagai layanan terkelola di proxy Envoy open source. Fitur ini mencakup kemampuan pengelolaan traffic lanjutan seperti pencerminan traffic, pemisahan traffic berbasis bobot, transformasi header berbasis permintaan/respons, dan lainnya.

Mode load balancer	Kasus penggunaan yang direkomendasikan	Kemampuan
Load Balancer Aplikasi eksternal global	Gunakan load balancer ini untuk beban kerja HTTP(S) eksternal dengan pengguna atau layanan backend yang tersebar secara global di beberapa region.	Kompatibel dengan GKE menggunakan Gateway (diorkestrasi sepenuhnya) atau NEG mandiri (orkestrasi manual) Mendukung pengelolaan traffic lanjutan Alamat IP eksternal Anycast global melalui Paket Premium Dapat mengakses backend di beberapa region Mendukung Cloud CDN Mendukung Google Cloud Armor
Load Balancer Aplikasi Klasik	Load balancer ini bersifat global di Paket Premium. Di Tingkat Layanan Jaringan Premium, load balancer ini menawarkan load balancing multi-region, mencoba mengarahkan traffic ke backend responsif terdekat yang memiliki kapasitas, dan menghentikan traffic HTTP(S) sedekat mungkin dengan pengguna Anda. Untuk mengetahui detail tentang proses distribusi permintaan, lihat Distribusi traffic. Di Paket Layanan Jaringan Standar, load balancer ini dapat mendistribusikan traffic ke backend hanya di satu region.	Kompatibel dengan GKE menggunakan Gateway (diorkestrasi sepenuhnya), Ingress (diorkestrasi sepenuhnya), atau NEG mandiri (orkestrasi manual) Mendukung Google Cloud Armor Lebih sedikit fitur pemilihan rute traffic Lihat halaman Fitur load balancing untuk mengetahui daftar lengkap kemampuan.
Load Balancer Aplikasi eksternal regional	Load balancer ini berisi banyak fitur dari Application Load Balancer klasik yang ada, beserta kemampuan pengelolaan traffic lanjutan. Gunakan load balancer ini jika Anda hanya ingin menayangkan konten dari satu geolokasi (misalnya, untuk memenuhi peraturan kepatuhan). Load balancer ini dapat dikonfigurasi di Paket Premium atau Standar.	Kompatibel dengan GKE menggunakan NEG mandiri (orkestrasi manual) Mendukung kemampuan pengelolaan traffic lanjutan VIP Regional yang menggunakan Tingkat Jaringan Standar Menghentikan TLS di satu region yang Anda konfigurasikan Hanya menayangkan konten dari region yang dikonfigurasi Untuk mengetahui daftar lengkapnya, lihat Fitur load balancing.

Mengidentifikasi mode

Cloud Console

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

   Buka Load balancing

2. Di tab Load Balancers, jenis, protokol, dan wilayah load balancer akan ditampilkan. Jika region kosong, load balancer bersifat global. Tabel berikut meringkas cara mengidentifikasi mode load balancer.

Mode load balancer	>Jenis load balancer	Jenis akses	Wilayah
Load Balancer Aplikasi eksternal global	Aplikasi	Eksternal
Load Balancer Aplikasi Klasik	Aplikasi(Klasik)	Eksternal
Load Balancer Aplikasi eksternal regional	Aplikasi	Eksternal	Menentukan region

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 meringkas cara mengidentifikasi mode load balancer.

Mode load balancer	Skema load balancing	Aturan penerusan	Tingkat jaringan
Load Balancer Aplikasi eksternal global	EXTERNAL_MANAGED	Global	Premium
Load Balancer Aplikasi Klasik	EKSTERNAL	Global	Standar atau Premium
Load Balancer Aplikasi eksternal regional	EXTERNAL_MANAGED	Menentukan region	Standar atau Premium

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

Arsitektur

Resource berikut diperlukan untuk deployment Load Balancer Aplikasi eksternal:

• Khusus untuk Load Balancer Aplikasi eksternal regional, subnet khusus proxy digunakan untuk mengirim koneksi dari load balancer ke backend.

• Aturan penerusan eksternal menentukan alamat IP, port, dan proxy HTTP(S) target eksternal. Klien menggunakan alamat IP dan port untuk terhubung ke load balancer.

• Proxy HTTP(S) target menerima permintaan dari klien. Proxy HTTP(S) mengevaluasi permintaan menggunakan peta URL untuk membuat keputusan pemilihan rute traffic. Proxy juga dapat mengautentikasi komunikasi dengan menggunakan sertifikat SSL.

  • Untuk load balancing HTTPS, proxy HTTPS target menggunakan sertifikat SSL untuk membuktikan identitasnya kepada klien. Proxy HTTPS target mendukung hingga jumlah yang didokumentasikan sertifikat SSL.

• Proxy HTTP(S) menggunakan peta URL untuk membuat penentuan rute berdasarkan atribut HTTP (seperti jalur permintaan, cookie, atau header). Berdasarkan keputusan pemilihan rute, proxy meneruskan permintaan klien ke layanan backend atau bucket backend tertentu. Peta URL dapat menentukan tindakan tambahan, seperti mengirim pengalihan ke klien.

• Layanan backend mendistribusikan permintaan ke backend yang sehat. Load Balancer Aplikasi eksternal global juga mendukung bucket backend. Satu atau beberapa backend harus terhubung ke layanan backend atau bucket backend.

• Health check secara berkala memantau kesiapan backend Anda. Hal ini mengurangi risiko permintaan yang mungkin dikirim ke backend yang tidak dapat melayani permintaan.

• Aturan firewall agar backend Anda dapat menerima pemeriksaan health check. Load Balancer Aplikasi eksternal regional memerlukan aturan firewall tambahan untuk mengizinkan traffic dari subnet khusus proxy menjangkau backend.

Global

Diagram ini menunjukkan komponen deployment Load Balancer Aplikasi eksternal global. Arsitektur ini berlaku untuk Load Balancer Aplikasi eksternal global, dan Load Balancer Aplikasi klasik di Paket Premium.

Komponen Load Balancer Aplikasi eksternal global (klik untuk memperbesar).

Regional

Diagram ini menunjukkan komponen deployment Load Balancer Aplikasi eksternal regional.

Komponen Load Balancer Aplikasi eksternal regional (klik untuk memperbesar).

Subnet khusus proxy

Subnet khusus proxy hanya diperlukan untuk Load Balancer Aplikasi eksternal regional.

Subnet khusus proxy menyediakan kumpulan alamat IP yang digunakan Google untuk menjalankan proxy Envoy atas nama Anda. Anda harus membuat satu subnet khusus proxy di setiap region jaringan VPC tempat Anda menggunakan Load Balancer Aplikasi eksternal regional. Flag --purpose untuk subnet khusus proxy ini ditetapkan ke REGIONAL_MANAGED_PROXY. Semua load balancer berbasis Envoy regional di region dan jaringan VPC yang sama berbagi kumpulan proxy Envoy dari 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 eksternal regional di region dan jaringan VPC menerima koneksi dari subnet khusus proxy.
• Alamat IP Load Balancer Aplikasi eksternal regional tidak berada di subnet khusus proxy. Alamat IP load balancer ditentukan oleh aturan penerusan yang dikelola secara eksternal, yang dijelaskan di bawah.

Jika sebelumnya Anda membuat subnet khusus proxy dengan --purpose=INTERNAL_HTTPS_LOAD_BALANCER, Anda perlu memigrasikan tujuan subnet ke REGIONAL_MANAGED_PROXY sebelum dapat membuat load balancer berbasis Envoy lainnya di region yang sama pada jaringan VPC.

Aturan penerusan dan alamat IP

Aturan penerusan merutekan traffic berdasarkan alamat IP, port, dan protokol ke konfigurasi load balancing yang terdiri dari proxy target, peta URL, dan satu atau beberapa layanan backend.

Spesifikasi alamat IP. Setiap aturan penerusan menyediakan satu alamat IP yang dapat digunakan dalam data DNS untuk aplikasi Anda. Tidak diperlukan load balancing berbasis DNS. Anda dapat menentukan alamat IP yang akan digunakan atau membiarkan Cloud Load Balancing menetapkannya untuk Anda.

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

Jenis aturan penerusan, alamat IP, dan skema load balancing yang digunakan oleh Load Balancer Aplikasi eksternal bergantung pada mode load balancer dan Paket Layanan Jaringan tempat load balancer berada.

Mode load balancer	Network Service Tier	Aturan penerusan, alamat IP, dan skema load balancing	Pemilihan rute dari internet ke frontend load balancer
Load Balancer Aplikasi eksternal global	Paket Premium	Aturan penerusan eksternal global Alamat IP eksternal global Skema load balancing: EXTERNAL_MANAGED	Permintaan yang dirutekan ke GFE yang terdekat dengan klien di internet.
Load Balancer Aplikasi Klasik	Paket Premium	Aturan penerusan eksternal global Alamat IP eksternal global Skema load balancing: EXTERNAL ^†	Permintaan yang dirutekan ke GFE yang terdekat dengan klien di internet.
	Paket Standar	Aturan penerusan eksternal regional Alamat IP eksternal regional Skema load balancing: EXTERNAL^*	Permintaan yang dirutekan ke GFE di region load balancer.
Load Balancer Aplikasi eksternal regional	Paket Premium atau Paket Standar	Aturan penerusan eksternal regional Alamat IP eksternal regional Skema load balancing: EXTERNAL_MANAGED	Permintaan mencapai Google Cloud di PoP yang terdekat dengan klien. Permintaan kemudian dirutekan melalui backbone premium Google Cloud hingga mencapai proxy Envoy di region yang sama dengan load balancer.

^* Anda dapat melampirkan layanan backend EXTERNAL_MANAGED ke aturan penerusan EXTERNAL. Namun, layanan backend EXTERNAL tidak dapat dilampirkan ke aturan penerusan EXTERNAL_MANAGED. Untuk memanfaatkan fitur baru yang hanya tersedia dengan Load Balancer Aplikasi eksternal global, sebaiknya migrasikan resource EXTERNAL yang ada ke EXTERNAL_MANAGED menggunakan proses migrasi yang dijelaskan di Memigrasikan resource dari Load Balancer Aplikasi klasik ke Load Balancer Aplikasi eksternal global.

Untuk mengetahui daftar lengkap protokol yang didukung oleh aturan penerusan Load Balancer Aplikasi eksternal di setiap mode, lihat Fitur load balancer.

Aturan penerusan dan jaringan VPC

Bagian ini menjelaskan cara aturan penerusan yang digunakan oleh Load Balancer Aplikasi eksternal dikaitkan dengan jaringan VPC.

Mode load balancer	Penautan jaringan VPC
Load Balancer Aplikasi eksternal global Load Balancer Aplikasi klasik	Tidak ada jaringan VPC terkait. Aturan penerusan selalu menggunakan alamat IP yang berada di luar jaringan VPC. Oleh karena itu, aturan penerusan tidak memiliki jaringan VPC terkait.
Load Balancer Aplikasi eksternal regional	Jaringan VPC aturan penerusan adalah jaringan tempat subnet khusus proxy telah dibuat. Anda menentukan jaringan saat membuat aturan penerusan. Bergantung pada apakah Anda menggunakan alamat IPv4 atau rentang alamat IPv6, selalu ada jaringan VPC eksplisit atau implisit yang terkait dengan aturan penerusan. Alamat IPv4 eksternal regional selalu ada di luar jaringan VPC. Namun, saat membuat aturan penerusan, Anda harus menentukan jaringan VPC tempat subnet khusus proxy telah dibuat. Oleh karena itu, aturan penerusan memiliki pengaitan jaringan eksplisit. Rentang alamat IPv6 eksternal regional selalu ada di dalam jaringan VPC. Saat membuat aturan penerusan, Anda harus menentukan subnet tempat rentang alamat IP diambil. Subnet ini harus berada di region dan jaringan VPC yang sama tempat subnet khusus proxy telah dibuat. Dengan demikian, ada pengaitan jaringan yang tersirat.

Proxy target

Proxy target menghentikan koneksi HTTP(S) dari klien. Satu atau beberapa aturan penerusan mengarahkan traffic ke proxy target, dan proxy target akan melihat peta URL untuk menentukan cara me-rutekan traffic ke backend.

Jangan mengandalkan proxy untuk mempertahankan kasus nama header permintaan atau respons. Misalnya, header respons Server: Apache/1.0 mungkin muncul di klien sebagai server: Apache/1.0.

Catatan: Untuk Grup Endpoint Jaringan (NEG) internet, permintaan dari load balancer berasal dari rentang IP yang berbeda, bergantung pada jenis NEG (global atau regional). Untuk mengetahui informasi selengkapnya, lihat Mengautentikasi permintaan.

Tabel berikut menentukan jenis proxy target yang diperlukan oleh Load Balancer Aplikasi eksternal.

Mode load balancer	Jenis proxy target	Header yang ditambahkan proxy	Header kustom yang didukung
Load Balancer Aplikasi eksternal global	HTTP Global, HTTPS Global	Proxy menetapkan header permintaan/respons HTTP sebagai berikut: Via: 1.1 google (permintaan dan respons) X-Forwarded-Proto: [http | https] (khusus permintaan) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (lihat header X-Forwarded-For) (khusus permintaan) Proksi juga menetapkan header X-Cloud-Trace-Context jika belum ada.	Dikonfigurasi di layanan backend atau bucket backend Tidak didukung dengan Cloud CDN
Load Balancer Aplikasi Klasik	HTTP Global, HTTPS Global	Proxy menetapkan header permintaan/respons HTTP sebagai berikut: Via: 1.1 google (permintaan dan respons) X-Forwarded-Proto: [http | https] (khusus permintaan) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (lihat header X-Forwarded-For) (khusus permintaan) Proksi juga menetapkan header X-Cloud-Trace-Context jika belum ada.	Dikonfigurasi di layanan backend atau bucket backend
Load Balancer Aplikasi eksternal regional	HTTP Regional, HTTPS Regional	X-Forwarded-Proto: [http | https] (khusus permintaan) Via: 1.1 google (permintaan dan respons) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (lihat header X-Forwarded-For) (khusus permintaan)	Dikonfigurasi di peta URL

Catatan: Sesuai dengan RFC 2616, header hop-by-hop berikut tidak disebarkan oleh proxy target: Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailers, Transfer-Encoding, dan Upgrade.

Selain header yang ditambahkan oleh proxy target, load balancer akan menyesuaikan header HTTP lainnya dengan cara berikut:

• Untuk Load Balancer Aplikasi eksternal global, header permintaan dan respons dapat dikonversi ke huruf kecil.

  Satu-satunya pengecualian untuk hal ini adalah saat Anda menggunakan backend NEG internet global dengan HTTP/1.1. Untuk mengetahui detail tentang cara header HTTP/1.1 diproses dengan NEG internet global, lihat Ringkasan NEG internet.

• Untuk Load Balancer Aplikasi klasik, header permintaan dan respons akan dikonversi ke huruf kecil kecuali jika Anda menggunakan HTTP/1.1. Dengan HTTP/1.1, header akan menggunakan huruf besar dan kecil yang tepat. Huruf pertama kunci header dan setiap huruf setelah tanda hubung (-) diawali dengan huruf besar untuk mempertahankan kompatibilitas dengan klien HTTP/1.1. Misalnya, user-agent diubah menjadi User-Agent, dan content-encoding diubah menjadi Content-Encoding.

• Beberapa header digabungkan. Jika ada beberapa instance kunci header yang sama (misalnya, Via), load balancer akan menggabungkan nilainya menjadi satu daftar yang dipisahkan koma untuk satu kunci header. Hanya header yang nilainya dapat direpresentasikan sebagai daftar yang dipisahkan koma yang digabungkan. Header lain, seperti Set-Cookie, tidak pernah digabungkan.

Header host

Saat load balancer membuat permintaan HTTP, load balancer akan mempertahankan header Host dari permintaan asli.

Header X-Forwarded-For

Load balancer menambahkan dua alamat IP yang dipisahkan oleh satu koma ke header X-Forwarded-For dalam urutan berikut:

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

Jika tidak ada header X-Forwarded-For pada permintaan masuk, dua alamat IP ini adalah seluruh nilai header:

X-Forwarded-For: <client-ip>,<load-balancer-ip>

Jika permintaan menyertakan header X-Forwarded-For, load balancer akan mempertahankan nilai yang diberikan sebelum <client-ip>,<load-balancer-ip>:

X-Forwarded-For: <supplied-value>,<client-ip>,<load-balancer-ip>

Perhatian: Load balancer tidak memverifikasi alamat IP apa pun yang mendahului <client-ip>,<load-balancer-ip> di header ini. Alamat IP sebelumnya mungkin berisi karakter lain, termasuk spasi.

Saat menjalankan software reverse proxy HTTP di backend load balancer, software tersebut dapat menambahkan satu atau kedua alamat IP berikut ke akhir header X-Forwarded-For:

• Alamat IP Google Front End (GFE) yang terhubung ke backend. Alamat IP ini berada dalam rentang 130.211.0.0/22 dan 35.191.0.0/16.

• Alamat IP sistem backend itu sendiri.

Dengan demikian, proses upstream setelah backend load balancer Anda mungkin menerima header X-Forwarded-For dalam bentuk:

<existing-values>,<client-ip>,<load-balancer-ip>,<GFE-IP>,<backend-IP>

Dukungan Cloud Trace

Pelacakan tidak didukung dengan Load Balancer Aplikasi. Load Balancer Aplikasi klasik dan global menambahkan header X-Cloud-Trace-Context jika tidak ada. Load Balancer Aplikasi eksternal regional tidak menambahkan header ini. Jika header X-Cloud-Trace-Context sudah ada, header tersebut akan melewati load balancer tanpa diubah. Namun, tidak ada rekaman aktivitas atau span yang diekspor oleh load balancer.

Peta URL

Peta URL menentukan pola yang cocok untuk perutean permintaan berbasis URL ke layanan backend yang sesuai. Peta URL memungkinkan Anda membagi traffic dengan memeriksa komponen URL untuk mengirim permintaan ke berbagai kumpulan backend. Layanan default ditentukan untuk menangani permintaan apa pun yang tidak cocok dengan aturan host atau aturan pencocokan jalur yang ditentukan.

Dalam beberapa situasi, seperti contoh load balancing multi-region, Anda mungkin tidak menentukan aturan URL apa pun dan hanya mengandalkan layanan default.

Peta URL mendukung beberapa fitur pengelolaan traffic lanjutan seperti pengarahan traffic berbasis header, pemisahan traffic berbasis bobot, dan pencerminan permintaan. Untuk informasi selengkapnya, lihat referensi berikut:

• Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global

• Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal regional

Tabel berikut menentukan jenis peta URL yang diperlukan oleh Load Balancer Aplikasi eksternal dalam setiap mode.

Mode load balancer	Jenis peta URL
Load Balancer Aplikasi eksternal global	Global
Load Balancer Aplikasi Klasik	Global (hanya dengan subset fitur yang didukung)
Load Balancer Aplikasi eksternal regional	Regional

Sertifikat SSL

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

• Google Cloud menyediakan dua metode konfigurasi untuk menetapkan kunci pribadi dan sertifikat SSL ke proxy HTTPS target: sertifikat SSL Compute Engine dan Certificate Manager. Untuk mengetahui deskripsi setiap konfigurasi, lihat Metode konfigurasi sertifikat di ringkasan sertifikat SSL.

• Google Cloud menyediakan dua jenis sertifikat: Dikelola sendiri dan dikelola Google. Untuk mengetahui deskripsi setiap jenis, lihat Jenis sertifikat di ringkasan sertifikat SSL.

Jenis Load Balancer Aplikasi eksternal (global, regional, atau klasik) menentukan metode konfigurasi dan jenis sertifikat yang didukung. Untuk mengetahui detailnya, lihat Sertifikat dan load balancer Google Cloud di ringkasan sertifikat SSL.

Kebijakan SSL

Kebijakan SSL menentukan kumpulan fitur SSL yang digunakan load balancer Google Cloud saat menegosiasikan SSL dengan klien.

Secara default, Load Balancing HTTPS menggunakan serangkaian fitur SSL yang memberikan keamanan yang baik dan kompatibilitas yang luas. Beberapa aplikasi memerlukan kontrol lebih besar atas versi dan cipher SSL yang digunakan untuk koneksi HTTPS atau SSL. Anda dapat menentukan kebijakan SSL untuk menentukan kumpulan fitur SSL yang digunakan load balancer saat menegosiasikan SSL dengan klien. Selain itu, Anda dapat menerapkan kebijakan SSL tersebut ke proxy HTTPS target.

Tabel berikut menentukan dukungan kebijakan SSL untuk load balancer dalam setiap mode.

Mode load balancer	Kebijakan SSL yang didukung
Load Balancer Aplikasi eksternal global
Load Balancer Aplikasi Klasik
Load Balancer Aplikasi eksternal regional

Layanan backend

Layanan backend memberikan informasi konfigurasi ke load balancer agar dapat mengarahkan permintaan ke backend-nya—misalnya, grup instance Compute Engine atau grup endpoint jaringan (NEG). Untuk mengetahui informasi selengkapnya tentang layanan backend, lihat Ringkasan layanan backend.

Untuk contoh yang menunjukkan cara menyiapkan load balancer dengan layanan backend dan backend Compute Engine, lihat Menyiapkan Load Balancer Aplikasi eksternal dengan backend Compute Engine.

Cakupan layanan backend

Tabel berikut menunjukkan resource dan cakupan layanan backend yang digunakan oleh Load Balancer Aplikasi eksternal:

Mode load balancer	Resource layanan backend
Load Balancer Aplikasi eksternal global	backendServices (global)
Load Balancer Aplikasi Klasik	backendServices (global)
Load Balancer Aplikasi eksternal regional	regionBackendServices (regional)

Protokol ke backend

Layanan backend untuk Load Balancer Aplikasi harus menggunakan salah satu protokol berikut untuk mengirim permintaan ke backend:

• HTTP, yang menggunakan HTTP/1.1 dan tidak menggunakan TLS
• HTTPS, yang menggunakan HTTP/1.1 dan TLS
• HTTP/2, yang menggunakan HTTP/2 dan TLS (HTTP/2 tanpa enkripsi tidak didukung.)

Load balancer hanya menggunakan protokol layanan backend yang Anda tentukan untuk berkomunikasi dengan backend-nya. Load balancer tidak kembali ke protokol yang berbeda jika tidak dapat berkomunikasi dengan backend menggunakan protokol layanan backend yang ditentukan.

Protokol layanan backend tidak perlu cocok dengan protokol yang digunakan oleh klien untuk berkomunikasi dengan load balancer. Misalnya, klien dapat mengirim permintaan ke load balancer menggunakan HTTP/2, tetapi load balancer dapat berkomunikasi dengan backend menggunakan HTTP/1.1 (HTTP atau HTTPS).

Bucket backend

Bucket backend mengarahkan traffic masuk ke bucket Cloud Storage. Untuk contoh yang menunjukkan cara menambahkan bucket ke Load Balancer Aplikasi eksternal, lihat Menyiapkan load balancer dengan bucket backend. Untuk mengetahui informasi umum tentang Cloud Storage, lihat Apa itu Cloud Storage?

Backend

Tabel berikut menentukan backend dan fitur terkait yang didukung oleh Application Load Balancer eksternal dalam 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^†	NEG Zona^‡	NEG Internet	NEG Serverless	NEG Hybrid	NEG Private Service Connect
Load Balancer Aplikasi eksternal global
Load Balancer Aplikasi Klasik									Paket Premium
Load Balancer Aplikasi eksternal regional

^*Backend di layanan backend harus memiliki jenis yang sama: semua grup instance atau semua jenis NEG yang sama. Pengecualian untuk aturan ini adalah bahwa NEG zona GCE_VM_IP_PORT dan NEG hybrid dapat digunakan di layanan backend yang sama untuk mendukung arsitektur hybrid.

^† Kombinasi grup instance terkelola zona, terkelola zona, dan terkelola regional didukung di layanan backend yang sama. Saat menggunakan penskalaan otomatis untuk grup instance terkelola yang merupakan backend untuk dua layanan backend atau lebih, konfigurasikan kebijakan penskalaan otomatis grup instance untuk menggunakan beberapa sinyal.

^‡ NEG zona harus menggunakan endpoint GCE_VM_IP_PORT.

^# IAP dan Cloud CDN tidak kompatibel satu sama lain. Keduanya tidak dapat diaktifkan di layanan backend yang sama.

Backend dan jaringan VPC

Batasan lokasi backend bergantung pada jenis load balancer.

Untuk backend Load Balancer Aplikasi eksternal global, hal berikut berlaku:

• Instance backend (untuk backend grup instance) dan endpoint backend (untuk backend NEG) dapat berada di jaringan VPC mana pun dalam organisasi yang sama. Jaringan VPC yang berbeda tidak perlu dihubungkan menggunakan Peering Jaringan VPC karena GFE berkomunikasi langsung dengan backend di jaringan VPC masing-masing.

• Bucket Cloud Storage tidak dikaitkan dengan jaringan VPC. Project tersebut dapat berada di project mana pun dalam organisasi yang sama.

  Load Balancer Aplikasi eksternal global juga mendukung lingkungan VPC Bersama tempat Anda dapat berbagi jaringan VPC dan resource terkait di seluruh project. Namun, untuk Load Balancer Aplikasi eksternal global, Anda tidak perlu mengonfigurasi VPC Bersama agar dapat mereferensikan layanan backend atau bucket backend dari project lain di organisasi Anda.

Untuk backend Load Balancer Aplikasi klasik, hal berikut berlaku:

• Semua instance backend dari backend grup instance dan semua endpoint backend dari backend NEG harus berada dalam project yang sama. Namun, backend grup instance atau NEG dapat menggunakan jaringan VPC yang berbeda di project tersebut. Jaringan VPC yang berbeda tidak perlu dihubungkan menggunakan Peering Jaringan VPC karena GFE berkomunikasi langsung dengan backend di jaringan VPC masing-masing.

• Bucket Cloud Storage tidak dikaitkan dengan jaringan VPC. Namun, keduanya harus berada dalam project yang sama dengan load balancer.

Untuk backend Load Balancer Aplikasi eksternal regional, hal berikut berlaku:

• Untuk grup instance, NEG zona, dan NEG konektivitas campuran, semua backend harus berada di project dan region yang sama dengan layanan backend. Namun, load balancer dapat mereferensikan backend yang menggunakan jaringan VPC yang berbeda di project yang sama dengan layanan backend (kemampuan ini dalam Pratinjau). Konektivitas antara jaringan VPC load balancer dan jaringan VPC backend dapat dikonfigurasi menggunakan Peering Jaringan VPC, tunnel Cloud VPN, lampiran VLAN Cloud Interconnect, atau framework Network Connectivity Center.

  Definisi jaringan backend

  • Untuk NEG zonal dan NEG campuran, Anda menentukan jaringan VPC secara eksplisit saat membuat NEG.
  • Untuk grup instance terkelola, jaringan VPC ditentukan dalam template instance.
  • Untuk grup instance tidak terkelola, jaringan VPC grup instance ditetapkan agar cocok dengan jaringan VPC antarmuka nic0 untuk VM pertama yang ditambahkan ke grup instance.

  Persyaratan jaringan backend

  Jaringan backend Anda harus memenuhi salah satu persyaratan jaringan berikut:

  • Jaringan VPC backend harus sama persis dengan jaringan VPC aturan penerusan.

  • Jaringan VPC backend harus terhubung ke jaringan VPC aturan penerusan menggunakan Peering Jaringan VPC. Anda harus mengonfigurasi pertukaran rute subnet untuk mengizinkan komunikasi antara subnet khusus proxy di jaringan VPC aturan penerusan dan subnet yang digunakan oleh instance backend atau endpoint.

• Jaringan VPC backend dan jaringan VPC aturan penerusan harus berupa jari-jari VPC di hub Network Connectivity Center yang sama. Filter impor dan ekspor harus mengizinkan komunikasi antara subnet khusus proxy di jaringan VPC aturan penerusan dan subnet yang digunakan oleh instance atau endpoint backend.

• Untuk semua jenis backend lainnya, semua backend harus berada di jaringan dan region VPC yang sama.

  Load Balancer Aplikasi eksternal regional juga mendukung lingkungan VPC Bersama tempat Anda dapat berbagi jaringan VPC dan resource terkaitnya di seluruh project. Jika Anda ingin layanan backend dan backend Load Balancer Aplikasi eksternal regional berada di project yang berbeda dengan aturan penerusan, Anda harus mengonfigurasi load balancer di lingkungan VPC Bersama dengan referensi layanan lintas project.

Backend dan antarmuka jaringan

Jika Anda menggunakan backend grup instance, paket akan selalu dikirim ke nic0. Jika Anda ingin mengirim paket ke NIC yang berbeda, gunakan backend NEG.

Jika Anda menggunakan backend NEG zonal, paket akan dikirim ke antarmuka jaringan apa pun yang diwakili oleh endpoint di NEG. Endpoint NEG harus berada di jaringan VPC yang sama dengan jaringan VPC yang ditentukan secara eksplisit oleh NEG.

Health check

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

Untuk pemeriksaan health check, Anda harus membuat aturan firewall izinkan ingress yang memungkinkan pemeriksaan health check menjangkau instance backend Anda. Biasanya, pemeriksaan health check berasal dari mekanisme pemeriksaan kesehatan terpusat Google.

Load Balancer Aplikasi eksternal regional yang menggunakan backend NEG campuran adalah pengecualian untuk aturan ini karena health check-nya berasal dari subnet khusus proxy. Untuk mengetahui detailnya, lihat Ringkasan NEG Hybrid.

Protokol health check

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

Tabel berikut menentukan cakupan health check yang didukung oleh Load Balancer Aplikasi eksternal dalam setiap mode.

Mode load balancer	Jenis health check
Load Balancer Aplikasi eksternal global	Global
Load Balancer Aplikasi Klasik	Global
Load Balancer Aplikasi eksternal regional	Regional

Untuk mengetahui informasi selengkapnya tentang pemeriksaan kesehatan, lihat artikel berikut:

• Ringkasan health check
• Membuat health check

Aturan firewall

Load balancer memerlukan aturan firewall berikut:

• Untuk Load Balancer Aplikasi eksternal global, aturan izin masuk untuk mengizinkan traffic dari Google Front End (GFE) menjangkau backend Anda. Untuk Load Balancer Aplikasi eksternal regional, aturan izin masuk untuk mengizinkan traffic dari subnet khusus proxy menjangkau backend Anda.
• Aturan izin masuk untuk mengizinkan traffic dari rentang pemeriksaan health check. Untuk mengetahui informasi selengkapnya tentang probe health check dan alasan Anda perlu mengizinkan traffic darinya, lihat Memeriksa aturan firewall dan rentang IP.

Aturan firewall diterapkan di tingkat instance VM, bukan di proxy GFE. Anda tidak dapat menggunakan aturan firewall Google Cloud untuk mencegah traffic menjangkau load balancer. Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik, Anda dapat menggunakan Google Cloud Armor untuk mencapai hal ini.

Port untuk aturan firewall ini harus dikonfigurasi sebagai berikut:

• Izinkan traffic ke port tujuan untuk setiap health check layanan backend.

• Untuk backend grup instance: Tentukan port yang akan dikonfigurasi oleh pemetaan antara port bernama layanan backend dan nomor port yang terkait dengan port bernama tersebut di setiap grup instance. Nomor port dapat bervariasi di antara grup instance yang ditetapkan ke layanan backend yang sama.

• Untuk backend NEG GCE_VM_IP_PORT: Izinkan traffic ke nomor port endpoint.

Tabel berikut merangkum rentang alamat IP sumber yang diperlukan untuk aturan firewall:

Mode load balancer	Rentang sumber health check	Rentang sumber permintaan
Load Balancer Aplikasi eksternal global	35.191.0.0/16 130.211.0.0/22 Untuk traffic IPv6 ke backend: 2600:2d00:1:b029::/64	Sumber traffic GFE bergantung pada jenis backend: Grup instance dan NEG zona (GCE_VM_IP_PORT): 130.211.0.0/22 35.191.0.0/16 Untuk traffic IPv6 ke backend: 2600:2d00:1:1::/64 NEG konektivitas hybrid (NON_GCP_PRIVATE_IP_PORT): 130.211.0.0/22 35.191.0.0/16 NEG Internet (INTERNET_FQDN_PORT dan INTERNET_IP_PORT): 34.96.0.0/20 34.127.192.0/18 SERVERLESS NEG dan bucket backend: Jaringan produksi Google menangani perutean paket
Load Balancer Aplikasi Klasik	35.191.0.0/16 130.211.0.0/22	Sumber traffic GFE bergantung pada jenis backend: Grup instance, NEG zona (GCE_VM_IP_PORT), dan NEG konektivitas hybrid (NON_GCP_PRIVATE_IP_PORT): 35.191.0.0/16 130.211.0.0/22 NEG Internet (INTERNET_FQDN_PORT dan INTERNET_IP_PORT): 34.96.0.0/20 34.127.192.0/18 SERVERLESS NEG dan bucket backend: Jaringan produksi Google menangani pemilihan rute paket.
Load Balancer Aplikasi eksternal regional	35.191.0.0/16 130.211.0.0/22 Untuk traffic IPv6 ke backend: 2600:2d00:1:b029::/64 Mencantumkan rentang probe health check Google dalam daftar yang diizinkan tidak diperlukan untuk NEG hibrida. Namun, jika Anda menggunakan kombinasi NEG campuran dan zonal dalam satu layanan backend, Anda harus mengizinkan rentang probe pemeriksaan kesehatan Google untuk NEG zonal.	Subnet khusus proxy yang Anda konfigurasikan.

Penting: Pastikan untuk mengizinkan paket dari rentang health check lengkap. Jika aturan firewall Anda hanya mengizinkan paket dari sebagian rentang, Anda mungkin melihat kegagalan health check karena load balancer tidak dapat berkomunikasi dengan backend Anda. Hal ini menyebabkan respons HTTP 502.

Dukungan GKE

GKE menggunakan Load Balancer Aplikasi eksternal dengan cara berikut:

• Gateway Eksternal yang dibuat menggunakan pengontrol GKE Gateway dapat menggunakan mode Load Balancer Aplikasi Eksternal apa pun. Anda mengontrol mode load balancer dengan memilih GatewayClass. Pengontrol GKE Gateway selalu menggunakan backend NEG zonal GCE_VM_IP_PORT.

• Ingress eksternal yang dibuat menggunakan pengontrol Ingress GKE selalu berupa Load Balancer Aplikasi Klasik. Pengontrol GKE Ingress lebih memilih untuk menggunakan backend NEG zonal GCE_VM_IP_PORT, meskipun backend grup instance juga didukung.

• Anda dapat menggunakan NEG zonal GCE_VM_IP_PORT yang dibuat dan dikelola oleh Layanan GKE sebagai backend untuk Load Balancer Aplikasi atau Load Balancer Jaringan Proxy. Untuk mengetahui informasi selengkapnya, lihat Load balancing berbasis container melalui NEG zona mandiri.

Arsitektur VPC Bersama

Load Balancer Aplikasi eksternal mendukung jaringan yang menggunakan VPC Bersama. VPC Bersama memungkinkan organisasi menghubungkan resource dari beberapa project ke jaringan VPC umum sehingga resource dapat berkomunikasi satu sama lain secara aman dan efisien menggunakan alamat IP internal dari jaringan tersebut. Jika Anda belum memahami VPC Bersama, baca Ringkasan VPC Bersama.

Ada banyak cara untuk mengonfigurasi Load Balancer Aplikasi eksternal dalam jaringan VPC Bersama. Terlepas dari jenis deployment, semua komponen load balancer harus berada di organisasi yang sama.

Load balancer	Komponen frontend	Komponen backend
Load Balancer Aplikasi eksternal global	Jika Anda menggunakan jaringan VPC Bersama untuk backend, buat jaringan yang diperlukan di project host VPC Bersama. Alamat IP eksternal global, aturan penerusan, proxy HTTP(S) target, dan peta URL terkait harus ditentukan dalam project yang sama. Project ini dapat berupa project host atau project layanan.	Anda dapat melakukan salah satu hal berikut: Buat layanan backend, bucket backend, dan backend (grup instance, NEG tanpa server, atau jenis backend lain yang didukung) di project layanan yang sama seperti komponen frontend. Buat layanan backend, bucket backend, dan backend (grup instance, NEG tanpa server, atau jenis backend lainnya yang didukung) di project layanan. 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 dirujuknya. Health check yang terkait dengan layanan backend juga harus ditentukan dalam project yang sama dengan layanan backend. Backend dapat menjadi bagian dari jaringan VPC Bersama dari project host atau jaringan VPC mandiri, yaitu jaringan VPC yang tidak dibagikan dalam project layanan.
Load Balancer Aplikasi Klasik	Alamat IP eksternal global, aturan penerusan, proxy HTTP(S) target, dan peta URL terkait harus ditentukan di project host atau layanan yang sama dengan backend.	Layanan backend global harus ditentukan dalam project host atau layanan yang sama dengan backend (grup instance atau NEG). Health check yang terkait dengan layanan backend juga harus ditentukan dalam project yang sama dengan layanan backend.
Load Balancer Aplikasi eksternal regional	Buat jaringan dan subnet khusus proxy yang diperlukan di project host VPC Bersama. Alamat IP eksternal regional, aturan penerusan, proxy HTTP(S) target, dan peta URL terkait harus ditentukan dalam project yang sama. Project ini dapat berupa project host atau project layanan.	Anda dapat melakukan salah satu hal berikut: Buat layanan backend dan backend (grup instance, NEG tanpa server, atau jenis backend lain yang didukung) di project layanan yang sama sebagai komponen frontend. Buat layanan backend dan backend (grup instance, NEG tanpa server, 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 dirujuknya. Health check yang terkait dengan layanan backend juga harus ditentukan dalam project yang sama dengan layanan backend.

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 project layanan

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

Komponen dan backend load balancer harus menggunakan jaringan VPC yang sama.

Load Balancer Aplikasi eksternal regional di jaringan VPC Bersama

Backend serverless di lingkungan VPC Bersama

Untuk load balancer yang menggunakan backend NEG serverless, layanan fungsi Cloud Run atau Cloud Run backend harus berada dalam project yang sama dengan NEG serverless.

Selain itu, untuk Load Balancer Aplikasi eksternal regional yang mendukung referensi layanan lintas project, layanan backend, NEG serverless, dan layanan Cloud Run harus selalu berada dalam project layanan yang sama.

Referensi layanan lintas project

Referensi layanan lintas project adalah model deployment dengan frontend dan peta URL load balancer berada dalam satu project, sedangkan layanan backend dan backend load balancer berada dalam project yang berbeda.

Referensi layanan lintas project memungkinkan organisasi mengonfigurasi satu load balancer pusat dan merutekan traffic ke ratusan layanan yang didistribusikan di beberapa project yang berbeda. Anda dapat mengelola semua aturan dan kebijakan pemilihan rute traffic secara terpusat di satu peta URL. Anda juga dapat mengaitkan load balancer dengan satu kumpulan nama host dan sertifikat SSL. Oleh karena itu, Anda dapat mengoptimalkan jumlah load balancer yang diperlukan untuk men-deploy aplikasi, serta menurunkan kemampuan pengelolaan, biaya operasional, dan persyaratan kuota.

Dengan memiliki project yang berbeda untuk setiap tim fungsional, Anda juga dapat mencapai pemisahan peran dalam organisasi. Pemilik layanan dapat berfokus pada pembuatan layanan dalam project layanan, sementara tim jaringan dapat menyediakan dan memelihara load balancer di project lain, dan keduanya dapat dihubungkan 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 dengan peran IAM khusus yang disebut peran Pengguna Layanan Load Balancer Compute (roles/compute.loadBalancerServiceUser).

Dukungan referensi layanan lintas project berbeda-beda berdasarkan jenis load balancer:

• Untuk Load Balancer Aplikasi eksternal global, frontend dan peta URL load balancer Anda dapat mereferensikan layanan backend atau bucket backend dari project apa pun dalam organisasi yang sama. Tidak ada batasan jaringan VPC yang berlaku. Meskipun Anda dapat menggunakan lingkungan VPC Bersama untuk mengonfigurasi deployment lintas project seperti yang ditunjukkan dalam contoh ini, hal ini bukan merupakan persyaratan.

• Untuk Load Balancer Aplikasi eksternal regional, Anda harus membuat load balancer di lingkungan VPC Bersama. Frontend dan peta URL load balancer harus berada di project host atau layanan, dan layanan backend serta backend load balancer dapat didistribusikan di seluruh project host atau layanan di lingkungan VPC Bersama yang sama.

Untuk mempelajari cara mengonfigurasi VPC Bersama untuk Load Balancer Aplikasi eksternal global—dengan dan tanpa referensi layanan lintas project, lihat Menyiapkan Load Balancer Aplikasi eksternal global dengan VPC Bersama.

Untuk mempelajari cara mengonfigurasi VPC Bersama untuk Load Balancer Aplikasi eksternal regional—dengan dan tanpa referensi layanan lintas project, lihat Menyiapkan Load Balancer Aplikasi eksternal regional dengan VPC Bersama.

Batasan umum terkait referensi layanan lintas project

• Referensi layanan lintas project dapat digunakan dengan grup instance, NEG tanpa server, dan sebagian besar jenis backend lainnya yang didukung. Namun, batasan berikut berlaku:

  • Dengan Load Balancer Aplikasi eksternal global, Anda tidak dapat mereferensikan layanan backend lintas project jika layanan backend memiliki backend NEG serverless dengan App Engine.

  • Dengan Load Balancer Aplikasi eksternal regional, Anda tidak dapat mereferensikan layanan backend lintas project jika layanan backend memiliki backend NEG internet regional.
• Referensi layanan lintas project tidak didukung untuk Load Balancer Aplikasi klasik.
• Google Cloud tidak membedakan resource (misalnya, layanan backend) yang menggunakan nama yang sama di beberapa project. Oleh karena itu, saat menggunakan referensi layanan lintas project, sebaiknya Anda menggunakan nama layanan backend yang unik di seluruh project dalam organisasi Anda.

Contoh 1: Frontend dan backend load balancer di project layanan yang berbeda

Berikut adalah contoh deployment VPC Bersama 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 project layanan yang berbeda

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

Berikut adalah contoh deployment VPC Bersama tempat frontend dan peta URL load balancer dibuat di project host dan layanan backend (dan backend) dibuat di project layanan.

Dalam hal ini, Admin Jaringan atau Admin Load Balancer di project host akan memerlukan akses ke layanan backend di 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.

Frontend load balancer dan peta URL di project host (klik untuk memperbesar).

Contoh 3: Frontend dan backend load balancer di project yang berbeda

Berikut adalah contoh deployment tempat frontend dan peta URL Load Balancer Aplikasi eksternal global dibuat di project yang berbeda dari layanan dan backend backend load balancer. Jenis deployment ini tidak menggunakan VPC Bersama dan hanya didukung untuk Load Balancer Aplikasi eksternal global.

Frontend dan backend load balancer di project yang berbeda (klik untuk memperbesar).

Cara kerja koneksi

Koneksi Load Balancer Aplikasi eksternal global

Load Balancer Aplikasi eksternal global diterapkan oleh banyak proxy yang disebut Google Front End (GFE). Tidak ada satu proxy saja. Di Paket Premium, alamat IP eksternal global yang sama diiklankan dari berbagai titik kehadiran, dan permintaan klien diarahkan ke GFE terdekat klien.

Bergantung pada lokasi klien Anda, beberapa GFE dapat memulai koneksi HTTP(S) ke backend Anda. Paket yang dikirim dari GFE memiliki alamat IP sumber dari rentang yang sama dengan yang digunakan oleh pemeriksa health check: 35.191.0.0/16 dan 130.211.0.0/22.

Catatan: Untuk NEG internet, permintaan dari load balancer berasal dari rentang IP yang berbeda-beda, bergantung pada jenis NEG (global atau regional). Untuk mengetahui informasi selengkapnya, lihat Mengautentikasi permintaan.

Bergantung pada konfigurasi layanan backend, protokol yang digunakan oleh setiap GFE untuk terhubung ke backend Anda dapat berupa HTTP, HTTPS, atau HTTP/2. Untuk koneksi HTTP atau HTTPS, versi HTTP yang digunakan adalah HTTP 1.1.

Keepalive HTTP diaktifkan secara default, seperti yang ditentukan dalam spesifikasi HTTP 1.1. Keepalive HTTP mencoba menggunakan sesi TCP yang sama secara efisien; tetapi, tidak ada jaminan. GFE menggunakan waktu tunggu keepalive HTTP klien 610 detik dan nilai waktu tunggu keepalive backend default 600 detik. Anda dapat memperbarui waktu tunggu keepalive HTTP klien, tetapi nilai waktu tunggu keepalive backend bersifat tetap. Anda dapat mengonfigurasi waktu tunggu permintaan/respons dengan menetapkan waktu tunggu layanan backend. Meskipun terkait erat, keepalive HTTP dan waktu tunggu tidak ada hubungannya. Untuk informasi selengkapnya, lihat waktu tunggu dan percobaan ulang.

Untuk memastikan traffic di-load balance secara merata, load balancer dapat menutup koneksi TCP dengan rapi baik dengan mengirim paket FIN ACK setelah menyelesaikan respons yang menyertakan header Connection: close, atau dapat mengeluarkan frame GOAWAY HTTP/2 setelah menyelesaikan respons. Perilaku ini tidak mengganggu permintaan atau respons aktif apa pun.

Jumlah koneksi HTTP dan sesi TCP bervariasi bergantung pada jumlah GFE yang terhubung, jumlah klien yang terhubung ke GFE, protokol ke backend, dan tempat backend di-deploy.

Untuk mengetahui informasi selengkapnya, lihat Cara kerja Load Balancer Aplikasi eksternal dalam panduan solusi: Pengoptimalan Kapasitas Aplikasi dengan Load Balancing Global.

Koneksi Load Balancer Aplikasi eksternal regional

Load Balancer Aplikasi eksternal regional adalah layanan terkelola yang diterapkan di proxy Envoy. Load Balancer Aplikasi eksternal regional menggunakan subnet bersama yang disebut subnet khusus proxy untuk menyediakan kumpulan alamat IP yang digunakan Google untuk menjalankan proxy Envoy atas nama Anda. Flag --purpose untuk subnet khusus proxy ini ditetapkan ke REGIONAL_MANAGED_PROXY. Semua load balancer berbasis Envoy regional di jaringan dan region tertentu berbagi subnet ini.

Klien menggunakan alamat IP dan port load balancer untuk terhubung ke load balancer. Permintaan klien diarahkan ke subnet khusus proxy di region yang sama dengan klien. Load balancer menghentikan permintaan klien, lalu membuka koneksi baru dari subnet khusus proxy ke backend Anda. Oleh karena itu, paket yang dikirim dari load balancer memiliki alamat IP sumber dari subnet khusus proxy.

Bergantung pada konfigurasi layanan backend, protokol yang digunakan oleh proxy Envoy untuk terhubung ke backend Anda dapat berupa HTTP, HTTPS, atau HTTP/2. Jika HTTP atau HTTPS, versi HTTP-nya adalah HTTP 1.1. Keepalive HTTP diaktifkan secara default, seperti yang ditentukan dalam spesifikasi HTTP 1.1. Proxy Envoy menetapkan waktu tunggu keepalive HTTP klien dan waktu tunggu keepalive backend ke nilai default masing-masing sebesar 600 detik. Anda dapat memperbarui waktu tunggu keepalive HTTP klien, tetapi nilai waktu tunggu keepalive backend bersifat tetap. Anda dapat mengonfigurasi waktu tunggu permintaan/respons dengan menetapkan waktu tunggu layanan backend. Untuk informasi selengkapnya, lihat waktu tunggu dan percobaan ulang.

Komunikasi klien dengan load balancer

• Klien dapat berkomunikasi dengan load balancer menggunakan protokol HTTP 1.1 atau HTTP/2.
• Saat HTTPS digunakan, klien modern akan menggunakan HTTP/2 secara default. Hal ini dikontrol di klien, bukan di load balancer HTTPS.
• Anda tidak dapat menonaktifkan HTTP/2 dengan membuat perubahan konfigurasi pada load balancer. Namun, Anda dapat mengonfigurasi beberapa klien untuk menggunakan HTTP 1.1, bukan HTTP/2. Misalnya, dengan curl, gunakan parameter --http1.1.
• Load Balancer Aplikasi Eksternal mendukung respons HTTP/1.1 100 Continue.

Untuk mengetahui daftar lengkap protokol yang didukung oleh aturan penerusan Load Balancer Aplikasi eksternal di setiap mode, lihat Fitur load balancer.

Alamat IP sumber untuk paket klien

Alamat IP sumber untuk paket, seperti yang dilihat oleh backend, bukan alamat IP eksternal Google Cloud dari load balancer. Dengan kata lain, ada dua koneksi TCP.

Untuk Load Balancer Aplikasi eksternal global:

• Koneksi 1, dari klien asli ke load balancer (GFE):

  • Alamat IP sumber: klien asli (atau alamat IP eksternal jika klien berada di balik NAT atau proxy penerusan).
  • Alamat IP tujuan: alamat IP load balancer Anda.

• Koneksi 2, dari load balancer (GFE) ke VM atau endpoint backend:

  • Alamat IP sumber: alamat IP dalam salah satu rentang yang ditentukan di Aturan firewall.

  • Alamat IP tujuan: alamat IP internal VM atau penampung backend di jaringan VPC.

Catatan: Untuk NEG internet, permintaan dari load balancer berasal dari rentang IP yang berbeda. Untuk mengetahui informasi selengkapnya, lihat Mengautentikasi permintaan.

Untuk Load Balancer Aplikasi eksternal regional:

• Koneksi 1, dari klien asli ke load balancer (subnet khusus proxy):

  • Alamat IP sumber: klien asli (atau alamat IP eksternal jika klien berada di balik NAT atau proxy penerusan).
  • Alamat IP tujuan: alamat IP load balancer Anda.

• Koneksi 2, dari load balancer (subnet khusus proxy) ke VM atau endpoint backend:

  • Alamat IP sumber: alamat IP di subnet khusus proxy yang digunakan bersama di antara semua load balancer berbasis Envoy yang di-deploy di region dan jaringan yang sama dengan load balancer.

  • Alamat IP tujuan: alamat IP internal VM atau penampung backend di jaringan VPC.

Jalur pemilihan rute khusus

Google Cloud menggunakan rute khusus yang tidak ditentukan di jaringan VPC Anda untuk merutekan paket untuk jenis traffic berikut:

• Untuk health check, kecuali health check Envoy terdistribusi. Untuk mengetahui informasi selengkapnya, lihat Jalur untuk health check.

• Antara GFE dan backend Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik. Untuk informasi selengkapnya, lihat Jalur antara Front End dan backend Google.

Google Cloud menggunakan rute subnet untuk subnet khusus proxy untuk merutekan paket untuk jenis traffic berikut:

• Saat menggunakan health check Envoy terdistribusi.

Untuk Load Balancer Aplikasi eksternal regional, Google Cloud menggunakan proxy Envoy open source untuk menghentikan permintaan klien ke load balancer. Load balancer akan menghentikan sesi TCP dan membuka sesi TCP baru dari subnet khusus proxy region ke backend Anda. Rute yang ditentukan dalam jaringan VPC Anda memfasilitasi komunikasi dari proxy Envoy ke backend Anda dan dari backend Anda ke proxy Envoy.

Port yang terbuka

GFE memiliki beberapa port terbuka untuk mendukung layanan Google lainnya yang berjalan di arsitektur yang sama. Saat menjalankan pemindaian port, Anda mungkin melihat port terbuka lainnya untuk layanan Google lain yang berjalan di GFE.

Kedua load balancer berbasis GFE—Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik—selalu menampilkan port 80 dan 443 sebagai terbuka (beserta port lain yang telah Anda konfigurasi dalam aturan penerusan load balancer). Namun, jika Anda belum mengonfigurasi aturan penerusan untuk port 80 atau untuk port 443, setiap koneksi yang dikirim ke port tersebut akan ditolak. Sebaliknya, Load Balancer Aplikasi eksternal regional diimplementasikan menggunakan proxy Envoy dan tidak menampilkan port terbuka tambahan selama pemindaian.

Menjalankan pemindaian port pada alamat IP load balancer berbasis GFE tidak berguna dari perspektif audit karena alasan berikut:

• Pemindaian port (misalnya, dengan nmap) umumnya tidak mengharapkan paket respons atau paket TCP RST saat melakukan probing TCP SYN. GFE akan mengirim paket SYN-ACK sebagai respons terhadap probe SYN hanya untuk port tempat Anda telah mengonfigurasi aturan penerusan. GFE hanya mengirim paket ke backend sebagai respons terhadap paket yang dikirim ke alamat IP load balancer dan port tujuan yang dikonfigurasi pada aturan penerusannya. Paket yang dikirim ke alamat IP atau port yang berbeda tidak dikirim ke backend Anda.

  GFE menerapkan fitur keamanan seperti Google Cloud Armor. Dengan Google Cloud Armor Standard, GFE memberikan perlindungan yang selalu aktif dari serangan DDoS volumetrik dan berbasis protokol serta serangan bertubi-tubi menggunakan SYN. Perlindungan ini tersedia meskipun Anda belum mengonfigurasi Google Cloud Armor secara eksplisit. Anda hanya akan ditagih jika mengonfigurasi kebijakan keamanan, atau jika mendaftar ke Managed Protection Plus.

• Paket yang dikirim ke alamat IP load balancer Anda dapat dijawab oleh GFE apa pun di fleet Google; namun, memindai alamat IP load balancer dan kombinasi port tujuan hanya menginterogasi satu GFE per koneksi TCP. Alamat IP load balancer Anda tidak ditetapkan ke satu perangkat atau sistem. Dengan demikian, memindai alamat IP load balancer berbasis GFE tidak akan memindai semua GFE di fleet Google.

Dengan mempertimbangkan hal tersebut, berikut beberapa cara yang lebih efektif untuk mengaudit keamanan instance backend Anda:

• Auditor keamanan harus memeriksa konfigurasi aturan penerusan untuk konfigurasi load balancer. Aturan penerusan menentukan port tujuan yang digunakan load balancer untuk menerima paket dan meneruskannya ke backend. Untuk load balancer berbasis GFE, setiap aturan penerusan eksternal hanya dapat mereferensikan satu port TCP tujuan. Untuk load balancer yang menggunakan port TCP 443, port UDP 443 digunakan saat koneksi diupgrade ke QUIC (HTTP/3).

• Auditor keamanan harus memeriksa konfigurasi aturan firewall yang berlaku untuk VM backend. Aturan firewall yang Anda tetapkan memblokir traffic dari GFE ke VM backend, tetapi tidak memblokir traffic masuk ke GFE. Untuk praktik terbaik, lihat bagian aturan firewall.

TLS termination

Tabel berikut merangkum cara penghentian TLS ditangani oleh Load Balancer Aplikasi eksternal.

Mode load balancer	TLS termination
Load Balancer Aplikasi eksternal global	TLS dihentikan di GFE, yang dapat berada di mana saja di dunia.
Load Balancer Aplikasi Klasik	TLS dihentikan di GFE, yang dapat berada di mana saja di dunia.
Load Balancer Aplikasi eksternal regional	TLS dihentikan di proxy Envoy yang berada di subnet khusus proxy di region yang dipilih oleh pengguna. Gunakan mode load balancer ini jika Anda memerlukan kontrol geografis atas region tempat TLS dihentikan.

Waktu tunggu dan percobaan ulang

Load Balancer Aplikasi eksternal mendukung jenis waktu tunggu berikut untuk traffic HTTP/HTTPS:

Jenis dan deskripsi waktu tunggu	Nilai default	Mendukung nilai waktu tunggu kustom
		Global	Klasik	Regional
Waktu tunggu layanan backend^1 Waktu tunggu permintaan dan respons. Merepresentasikan jumlah waktu maksimum yang diizinkan antara load balancer yang mengirim byte pertama permintaan ke backend dan backend yang menampilkan byte terakhir respons HTTP ke load balancer. Jika backend belum menampilkan seluruh respons HTTP ke load balancer dalam batas waktu ini, data respons yang tersisa akan dihapus.	Untuk NEG serverless di layanan backend: 60 menit Untuk semua jenis backend lainnya di layanan backend: 30 detik Untuk bucket backend: 24 jam (86.400 detik)
Waktu tunggu keepalive HTTP klien Waktu maksimum koneksi TCP antara klien dan proxy load balancer dapat tidak aktif. (Koneksi TCP yang sama mungkin digunakan untuk beberapa permintaan HTTP.) Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik, proxy load balancer adalah GFE lapisan pertama. Untuk Load Balancer Aplikasi eksternal regional, proxy load balancer adalah software Envoy.	Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik: 610 detik Untuk Load Balancer Aplikasi eksternal regional: 600 detik
Waktu tunggu keepalive HTTP backend Jumlah waktu maksimum koneksi TCP antara proxy load balancer dan backend dapat tidak aktif. (Koneksi TCP yang sama mungkin digunakan untuk beberapa permintaan HTTP.) Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik, proxy load balancer adalah GFE lapisan kedua. Untuk Load Balancer Aplikasi eksternal regional, proxy load balancer adalah software Envoy.	Untuk layanan backend: 10 menit (600 detik) Untuk bucket backend: 6 menit (360 detik)
Waktu tunggu tidak ada aktivitas sesi QUIC Jumlah waktu maksimum sesi QUIC dapat tidak ada aktivitas antara klien (downstream) dan GFE Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik.	Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik: Waktu tunggu tidak ada aktivitas sesi QUIC adalah minimum dari waktu tunggu tidak ada aktivitas klien atau waktu tunggu tidak ada aktivitas GFE (300 detik). Waktu tunggu tidak ada aktivitas GFE ditetapkan pada 300 detik. Waktu tunggu tidak ada aktivitas klien dapat dikonfigurasi.

¹Tidak dapat dikonfigurasi untuk backend NEG serverless. Tidak dapat dikonfigurasi untuk bucket backend.

Waktu tunggu layanan backend

Waktu tunggu layanan backend yang dapat dikonfigurasi menunjukkan jumlah waktu maksimum load balancer menunggu backend Anda memproses permintaan HTTP dan menampilkan respons HTTP yang sesuai. Kecuali untuk NEG tanpa server, nilai default untuk 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 lengkap. Dalam situasi ini, jika load balancer setidaknya telah menerima header respons HTTP dari backend, load balancer akan menampilkan header respons lengkap dan sebanyak mungkin isi respons yang dapat diperoleh dalam waktu tunggu layanan backend.

Anda harus menetapkan waktu tunggu layanan backend ke jumlah waktu terlama yang diperlukan backend untuk memproses respons HTTP. Anda harus meningkatkan waktu tunggu layanan backend jika software yang berjalan di backend Anda memerlukan lebih banyak waktu untuk memproses permintaan HTTP dan menampilkan seluruh responsnya. Misalnya, Anda harus meningkatkan waktu tunggu jika melihat respons 408 HTTP dengan jsonPayload.statusDetail client_timed_out.

Waktu tunggu layanan backend menerima nilai antara 1 dan 2,147,483,647 detik; tetapi, nilai yang lebih besar bukanlah opsi konfigurasi yang praktis. Google Cloud juga tidak menjamin bahwa koneksi TCP yang mendasarinya dapat tetap terbuka selama keseluruhan nilai waktu tunggu layanan backend. Untuk Load Balancer Aplikasi global dan klasik, GFE menerapkan waktu tunggu layanan backend maksimum yang efektif sebesar 86,400 detik (1 hari). Sistem klien harus menerapkan logika percobaan ulang, bukan mengandalkan koneksi TCP yang terbuka untuk jangka waktu yang lama.

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

Konsol

Ubah kolom Timeout pada layanan backend load balancer.

gcloud

Gunakan perintah gcloud compute backend-services update untuk mengubah parameter --timeout resource layanan backend.

API

Untuk Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik, ubah parameter timeoutSec untuk resource backendServices global.

Untuk Load Balancer Aplikasi eksternal regional, ubah parameter timeoutSec untuk resource regionBackendServices.

Waktu tunggu koneksi WebSocket tidak selalu sama dengan waktu tunggu layanan backend. Waktu tunggu koneksi WebSocket bergantung pada jenis load balancer:

Mode load balancer	Nilai default	Deskripsi waktu tunggu untuk websocket
Load Balancer Aplikasi eksternal global	waktu tunggu layanan backend: 30 detik	Koneksi websocket aktif tidak menggunakan waktu tunggu layanan backend yang dikonfigurasi dari load balancer. Koneksi akan otomatis ditutup setelah 24 jam (86.400 detik). Batas 24 jam ini bersifat tetap dan menggantikan waktu tunggu layanan backend jika lebih dari 24 jam. Koneksi websocket yang tidak ada aktivitas akan ditutup setelah waktu tunggu layanan backend habis. Sebaiknya jangan gunakan nilai waktu tunggu layanan backend yang lebih besar dari 24 jam (86.400 detik) karena Google Cloud secara berkala memulai ulang GFE untuk update software dan pemeliharaan rutin lainnya. Nilai waktu tunggu layanan backend Anda tidak menunda aktivitas pemeliharaan. Makin lama nilai waktu tunggu layanan backend, makin besar kemungkinan Google Cloud menghentikan koneksi TCP untuk pemeliharaan.
Load Balancer Aplikasi Klasik	waktu tunggu layanan backend: 30 detik	Koneksi WebSocket, baik tidak aktif maupun aktif, akan otomatis ditutup setelah waktu tunggu layanan backend habis. Sebaiknya jangan gunakan nilai waktu tunggu layanan backend yang lebih besar dari 24 jam (86.400 detik) karena Google Cloud secara berkala memulai ulang GFE untuk update software dan pemeliharaan rutin lainnya. Nilai waktu tunggu layanan backend Anda tidak menunda aktivitas pemeliharaan. Makin lama nilai waktu tunggu layanan backend, makin besar kemungkinan Google Cloud menghentikan koneksi TCP untuk pemeliharaan.
Load Balancer Aplikasi eksternal regional	waktu tunggu layanan backend: 30 detik	Koneksi websocket aktif tidak menggunakan waktu tunggu layanan backend load balancer. Koneksi websocket yang tidak ada aktivitas akan ditutup setelah waktu tunggu layanan backend habis. Google Cloud secara berkala memulai ulang atau mengubah jumlah tugas software Envoy yang ditayangkan. Makin lama nilai waktu tunggu layanan backend, makin besar kemungkinan tugas Envoy memulai ulang atau menghentikan koneksi TCP.

Load Balancer Aplikasi eksternal regional menggunakan parameter routeActions.timeout peta URL yang dikonfigurasi dan mengabaikan waktu tunggu layanan backend. Jika routeActions.timeout tidak dikonfigurasi, nilai waktu tunggu layanan backend akan digunakan. Jika routeActions.timeout disediakan, waktu tunggu layanan backend akan diabaikan, dan nilai routeActions.timeout akan digunakan sebagai waktu tunggu permintaan dan respons.

Waktu tunggu keepalive HTTP klien habis

Waktu tunggu keepalive HTTP klien menunjukkan jumlah waktu maksimum yang dapat dihabiskan koneksi TCP dalam keadaan tidak ada aktivitas antara klien (downstream) dan salah satu jenis proxy berikut:

• Untuk Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik: Front End Google lapisan pertama

• Untuk Load Balancer Aplikasi eksternal regional: proxy Envoy

Waktu tunggu keepalive HTTP mewakili waktu tunggu siaga TCP untuk koneksi TCP yang mendasarinya. Waktu tunggu keepalive HTTP klien tidak berlaku untuk websocket.

• Untuk Load Balancer Aplikasi eksternal global, nilai default-nya adalah 610 detik. Anda dapat mengonfigurasi waktu tunggu keepalive HTTP klien dengan nilai antara 5 dan 1.200 detik.
• Untuk Load Balancer Aplikasi klasik, waktu tunggu keepalive HTTP klien ditetapkan pada 610 detik.
• Untuk Load Balancer Aplikasi eksternal regional, nilai default-nya adalah 600 detik. Anda dapat mengonfigurasi waktu tunggu keepalive HTTP klien dengan nilai antara 5 dan 600 detik.

Untuk mengonfigurasi parameter waktu tunggu keepalive, gunakan salah satu metode berikut:

Konsol

Ubah kolom HTTP keepalive timeout dari konfigurasi frontend load balancer.

gcloud

Gunakan perintah gcloud compute target-http-proxies update atau perintah gcloud compute target-https-proxies update untuk mengubah parameter --http-keep-alive-timeout-sec dari proxy HTTP target atau resource proxy HTTPS target.

Catatan:

Untuk Load Balancer Aplikasi eksternal regional, Anda tidak dapat memperbarui parameter waktu tunggu keepalive proxy HTTP(S) target regional secara langsung. Untuk memperbarui parameter waktu tunggu keepalive proxy target regional, Anda perlu melakukan hal berikut:

1. Buat proxy target baru dengan setelan waktu tunggu yang diinginkan.
2. Mencerminkan semua setelan lainnya dari proxy target saat ini ke proxy baru. Untuk proxy HTTPS target, tindakan ini mencakup penautan sertifikat SSL atau peta sertifikat ke proxy target baru.
3. Perbarui aturan penerusan agar mengarah ke proxy target baru.
4. Hapus proxy target lama.

API

Ubah parameter httpKeepAliveTimeoutSec untuk resource targetHttpProxies atau resource targetHttpsProxies.

Catatan:

Untuk Load Balancer Aplikasi eksternal regional, Anda tidak dapat memperbarui parameter waktu tunggu keepalive proxy HTTP(S) target regional secara langsung. Untuk memperbarui parameter waktu tunggu keepalive proxy target regional, Anda perlu melakukan hal berikut:

1. Buat proxy target baru dengan setelan waktu tunggu yang diinginkan.
2. Mencerminkan semua setelan lainnya dari proxy target saat ini ke proxy baru. Untuk proxy HTTPS target, tindakan ini mencakup penautan sertifikat SSL atau peta sertifikat ke proxy target baru.
3. Perbarui aturan penerusan agar mengarah ke proxy target baru.
4. Hapus proxy target lama.

Waktu tunggu keepalive HTTP klien load balancer harus lebih besar dari waktu tunggu keepalive HTTP (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 perlombaan mungkin terjadi. Dari perspektif klien downstream, koneksi TCP yang sudah dibuat diizinkan untuk tidak ada aktivitas lebih lama dari yang diizinkan oleh load balancer. Artinya, klien downstream dapat mengirim paket setelah load balancer menganggap koneksi TCP ditutup. Jika hal itu terjadi, load balancer akan merespons dengan paket reset TCP (RST).

Waktu tunggu keepalive HTTP backend

Load Balancer Aplikasi Eksternal adalah proxy yang menggunakan minimal dua koneksi TCP:

• Untuk Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik, koneksi TCP pertama ada antara klien (downstream) dan GFE lapisan pertama. GFE lapisan pertama terhubung ke GFE lapisan kedua, lalu GFE lapisan kedua membuka koneksi TCP kedua ke backend Anda.

• Untuk Load Balancer Aplikasi eksternal regional, koneksi TCP pertama ada antara klien (downstream) dan proxy Envoy. Proxy Envoy kemudian membuka koneksi TCP kedua ke backend Anda.

Koneksi TCP sekunder load balancer mungkin tidak ditutup setelah setiap permintaan; koneksi tersebut 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 websocket.

Waktu tunggu keepalive backend ditetapkan pada 10 menit (600 detik) dan tidak dapat diubah. Waktu tunggu keepalive backend load balancer harus lebih singkat dari waktu tunggu keepalive yang digunakan oleh software yang berjalan di backend Anda. Hal ini menghindari kondisi race saat sistem operasi backend Anda dapat 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 keepalive HTTP (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;

Waktu tunggu sesi QUIC tidak ada aktivitas

Waktu tunggu tidak ada aktivitas sesi QUIC menunjukkan jumlah waktu maksimum yang dapat dihabiskan sesi QUIC dalam keadaan tidak ada aktivitas antara klien dan GFE Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik.

Nilai waktu tunggu tidak ada aktivitas sesi QUIC ditentukan sebagai minimum dari waktu tunggu tidak ada aktivitas klien atau waktu tunggu tidak ada aktivitas GFE (300 detik). Waktu tunggu tidak ada aktivitas GFE ditetapkan pada 300 detik. Waktu tunggu tidak ada aktivitas klien dapat dikonfigurasi.

Upaya coba lagi

Dukungan untuk logika percobaan ulang bergantung pada mode Load Balancer Aplikasi eksternal.

Mode load balancer	Logika percobaan ulang
Load Balancer Aplikasi eksternal global	Dapat dikonfigurasi menggunakan kebijakan percobaan ulang di peta URL. Jumlah percobaan ulang default (numRetries) adalah 1. Jumlah maksimum percobaan ulang yang dapat dikonfigurasi menggunakan kebijakan percobaan ulang adalah 25. perTryTimeout maksimum yang dapat dikonfigurasi adalah 24 jam. Tanpa kebijakan percobaan ulang, permintaan yang gagal dan tidak memiliki isi HTTP (misalnya, permintaan GET) yang menghasilkan respons HTTP 502, 503, atau 504 (retryConditions=["gateway-error"]) akan dicoba ulang sekali. Permintaan POST HTTP tidak dicoba lagi. Permintaan yang dicoba ulang hanya menghasilkan satu entri log untuk respons akhir.
Load Balancer Aplikasi Klasik	Kebijakan percobaan ulang tidak dapat diubah untuk percobaan ulang koneksi. Permintaan POST HTTP tidak dicoba lagi. Permintaan GET HTTP selalu dicoba lagi satu kali selama 80% atau lebih backend berfungsi dengan baik. Jika ada satu instance backend dalam grup dan koneksi ke instance backend tersebut gagal, persentase instance backend yang tidak sehat adalah 100%, sehingga GFE tidak mencoba lagi permintaan tersebut. Load balancer akan mencoba kembali permintaan GET yang gagal jika permintaan pertama gagal sebelum menerima header respons dari instance backend. Permintaan yang dicoba ulang hanya menghasilkan satu entri log untuk respons akhir. Untuk mengetahui informasi selengkapnya, lihat Logging dan pemantauan Load Balancer Aplikasi Eksternal. Permintaan yang gagal akan menyebabkan load balancer menyintesis respons HTTP 502.
Load Balancer Aplikasi eksternal regional	Dapat dikonfigurasi menggunakan kebijakan percobaan ulang di peta URL. Jumlah percobaan ulang default (numRetries) adalah 1. Jumlah maksimum percobaan ulang yang dapat dikonfigurasi menggunakan kebijakan percobaan ulang adalah 25. perTryTimeout maksimum yang dapat dikonfigurasi adalah 24 jam. Tanpa kebijakan percobaan ulang, permintaan yang gagal dan tidak memiliki isi HTTP (misalnya, permintaan GET) yang menghasilkan respons HTTP 502, 503, atau 504 akan dicoba ulang sekali. Permintaan POST HTTP tidak dicoba lagi. Permintaan yang dicoba ulang hanya menghasilkan satu entri log untuk respons akhir.

Protokol WebSocket didukung dengan GKE Ingress.

Penanganan permintaan dan respons ilegal

Load balancer memblokir permintaan klien dan respons backend agar tidak menjangkau backend atau klien, karena sejumlah alasan. Beberapa alasan hanya untuk kepatuhan HTTP/1.1 dan alasan lainnya adalah untuk menghindari data yang tidak terduga diteruskan ke atau dari backend. Tidak satu pun pemeriksaan yang dapat dinonaktifkan.

Load balancer memblokir permintaan berikut untuk kepatuhan HTTP/1.1:

• API ini tidak dapat mengurai baris pertama permintaan.
• Header tidak memiliki pemisah titik dua (:).
• Header atau baris pertama berisi karakter yang tidak valid.
• Panjang konten bukan angka yang valid, atau ada beberapa header panjang konten.
• Ada beberapa kunci encoding transfer, atau ada nilai encoding transfer yang tidak dikenali.
• Ada isi yang tidak dikelompokkan dan tidak ada panjang konten yang ditentukan.
• Potongan isi tidak dapat diuraikan. Ini adalah satu-satunya kasus saat beberapa data mencapai backend. Load balancer menutup koneksi ke klien dan backend saat menerima bagian yang tidak dapat diuraikan.

Penanganan permintaan

Load balancer akan memblokir permintaan jika salah satu hal berikut terpenuhi:

• Total ukuran header permintaan dan URL permintaan melebihi batas untuk ukuran header permintaan maksimum untuk Application Load Balancer eksternal.
• Metode permintaan tidak mengizinkan isi, tetapi permintaan memiliki isi.
• Permintaan berisi header Upgrade, dan header Upgrade tidak digunakan untuk mengaktifkan koneksi WebSocket.
• Versi HTTP tidak diketahui.

Penanganan respons

Load balancer memblokir respons backend jika salah satu dari hal berikut berlaku:

• Total ukuran header respons melebihi batas ukuran header respons maksimum untuk Load Balancer Aplikasi eksternal.
• Versi HTTP tidak diketahui.

Saat menangani permintaan dan respons, load balancer dapat menghapus atau menulis ulang header hop-by-hop di HTTP/1.1 sebelum meneruskannya ke tujuan yang diinginkan.

Distribusi traffic

Saat menambahkan grup instance backend atau NEG ke layanan backend, Anda menentukan mode balancing, yang menentukan metode untuk mengukur beban backend dan kapasitas target. Load Balancer Aplikasi Eksternal mendukung dua mode penyeimbangan:

• RATE, misalnya grup atau NEG, adalah target jumlah maksimum permintaan (kueri) per detik (RPS, QPS). Target RPS/QPS maksimum dapat dilampaui jika semua backend berada pada atau di atas kapasitas.

• UTILIZATION adalah penggunaan backend VM dalam grup instance.

Cara traffic didistribusikan di antara backend bergantung pada mode load balancer.

Load Balancer Aplikasi eksternal global

Sebelum Google Front End (GFE) mengirim permintaan ke instance backend, GFE akan memperkirakan instance backend mana yang memiliki kapasitas untuk menerima permintaan. Estimasi kapasitas ini dibuat secara proaktif, bukan pada saat permintaan datang. GFE menerima informasi berkala tentang kapasitas yang tersedia dan mendistribusikan permintaan yang masuk sesuai kebutuhan.

Makna kapasitas sebagian bergantung pada mode balancing. Untuk mode RATE, hal ini relatif sederhana: GFE menentukan dengan tepat jumlah permintaan yang dapat ditetapkan per detik. Load balancing berbasis UTILIZATION lebih kompleks: load balancer memeriksa penggunaan instance saat ini, lalu memperkirakan beban kueri yang dapat ditangani setiap instance. Estimasi ini berubah dari waktu ke waktu seiring perubahan penggunaan instance dan pola traffic.

Kedua faktor tersebut—estimasi kapasitas dan penetapan proaktif—memengaruhi distribusi di antara instance. Dengan demikian, Cloud Load Balancing berperilaku berbeda dari load balancer round robin sederhana yang menyebarkan permintaan persis 50:50 di antara dua instance. Sebagai gantinya, load balancing Google Cloud mencoba mengoptimalkan pemilihan instance backend untuk setiap permintaan.

Untuk Load Balancer Aplikasi eksternal global, load balancing bersifat dua tingkat. Mode penyeimbangan menentukan bobot atau fraksi traffic yang harus dikirim ke setiap backend (grup instance atau NEG). Kemudian, kebijakan load balancing (LocalityLbPolicy) menentukan cara traffic didistribusikan ke instance atau endpoint dalam grup. Untuk informasi selengkapnya, lihat Kebijakan lokalitas load balancing (dokumentasi API layanan backend).

Untuk Load Balancer Aplikasi klasik, mode balancing digunakan untuk memilih backend yang paling menguntungkan (grup instance atau NEG). Traffic kemudian didistribusikan dengan cara round robin di antara instance atau endpoint dalam backend.

Cara permintaan didistribusikan

Load Balancer Aplikasi eksternal berbasis GFE menggunakan proses berikut untuk mendistribusikan permintaan masuk:

1. Dari klien ke GFE lapisan pertama. Router edge mengiklankan alamat IP eksternal aturan penerusan di batas jaringan Google. Setiap iklan mencantumkan next hop ke sistem load balancing Lapisan 3/4 (Maglev). Sistem Maglev merutekan traffic ke Google Front End (GFE) lapisan pertama.
   • Saat menggunakan Paket Premium, Google akan mengiklankan alamat IP load balancer Anda dari semua titik kehadiran di seluruh dunia. Setiap alamat IP load balancer adalah anycast global.
   • Saat menggunakan Paket Standar, Google mengiklankan alamat IP load balancer Anda dari titik kehadiran yang terkait dengan wilayah aturan penerusan. Load balancer menggunakan alamat IP eksternal regional. Penggunaan aturan penerusan Tingkat Standar membatasi Anda untuk menggunakan backend grup instance dan NEG zonal di region yang sama dengan aturan penerusan load balancer.
2. Dari GFE lapisan pertama ke GFE lapisan kedua. GFE lapisan pertama menghentikan TLS jika diperlukan, lalu merutekan traffic ke GFE lapisan kedua sesuai dengan proses berikut:
   • GFE lapisan pertama mengurai peta URL dan memilih layanan backend atau bucket backend.
   • Untuk layanan backend dengan NEG internet, GFE lapisan pertama memilih gateway penerusan eksternal lapisan kedua yang ditempatkan bersama dengan GFE lapisan pertama. Gateway penerusan mengirimkan permintaan ke endpoint NEG internet. Dengan ini, proses distribusi permintaan untuk NEG internet telah selesai.
   • Untuk layanan backend dengan NEG serverless dan NEG Private Service Connect (PSC), serta bucket backend satu region, GFE lapisan pertama memilih GFE lapisan kedua di region yang cocok dengan region NEG atau bucket. Untuk bucket Cloud Storage multi-region, GFE lapisan pertama memilih GFE lapisan kedua di region bucket, atau region yang sedekat mungkin dengan bucket multi-region (ditentukan oleh waktu perjalanan bolak-balik jaringan).
   • Untuk layanan backend dengan grup instance, NEG zonal dengan GCE_VM_IP_PORT endpoint, dan NEG campuran, sistem pengelolaan kapasitas Google akan memberi tahu GFE lapisan pertama tentang kapasitas yang digunakan dan dikonfigurasi untuk setiap backend. Kapasitas yang dikonfigurasi untuk backend ditentukan oleh mode balancing, kapasitas target mode balancing, dan penghitung skala kapasitas.
     • Paket Standar: GFE lapisan pertama memilih GFE lapisan kedua di region yang berisi backend.
     • Tingkat Premium: GFE lapisan pertama memilih GFE lapisan kedua dari kumpulan region yang berlaku. Wilayah yang berlaku adalah semua wilayah tempat backend telah dikonfigurasi, tidak termasuk wilayah dengan backend yang dikonfigurasi dan memiliki kapasitas nol. GFE lapisan pertama memilih GFE lapisan kedua terdekat di region yang berlaku (ditentukan oleh waktu perjalanan bolak-balik jaringan). Jika backend dikonfigurasi di dua region atau lebih, GFE lapisan pertama dapat menyalurkan permintaan ke region lain yang berlaku jika region pilihan pertama penuh. Spillover ke wilayah lain dapat dilakukan jika semua backend di wilayah pilihan pertama sudah penuh.
3. GFE lapisan kedua memilih backend. GFE lapisan kedua terletak di zona region. Mereka menggunakan proses berikut untuk memilih backend:
   • Untuk layanan backend dengan NEG serverless, NEG Private Service Connect, dan bucket backend, GFE lapisan kedua meneruskan permintaan ke sistem produksi Google. Tindakan ini mengakhiri proses distribusi permintaan untuk backend ini.

   • Untuk layanan backend dengan grup instance, NEG zonal dengan endpoint GCE_VM_IP_PORT, dan NEG campuran, sistem pemeriksaan kesehatan Google akan memberi tahu GFE lapisan kedua tentang status pemeriksaan kesehatan instance atau endpoint backend.

     Khusus Tingkat Premium: Jika GFE lapisan kedua tidak memiliki instance atau endpoint backend yang berfungsi di regionnya, GFE tersebut dapat mengirim permintaan ke GFE lapisan kedua lain di region yang berlaku dan berbeda dengan backend yang dikonfigurasi. Dampak lintasan antara GFE lapisan kedua di region yang berbeda tidak menghabiskan semua kemungkinan kombinasi region ke region. Jika perlu mengalihkan traffic dari backend di region tertentu, alih-alih mengonfigurasi backend agar gagal dalam health check, Anda harus menetapkan scaler kapasitas backend ke nol sehingga GFE lapisan pertama mengecualikan region selama langkah sebelumnya.

   GFE lapisan kedua kemudian mengarahkan permintaan ke instance backend atau endpoint di zona dalam region-nya seperti yang dibahas pada langkah berikutnya.

4. GFE lapisan kedua memilih zona. Secara default, GFE lapisan kedua menggunakan algoritma WATERFALL_BY_REGION dengan setiap GFE lapisan kedua lebih memilih untuk memilih instance backend atau endpoint di zona yang sama dengan zona yang berisi GFE lapisan kedua. Karena WATERFALL_BY_REGION meminimalkan traffic antarzona, dengan tingkat permintaan yang rendah, setiap GFE lapisan kedua mungkin secara eksklusif mengirim permintaan ke backend di zona yang sama dengan GFE lapisan kedua itu sendiri.

   Khusus untuk Load Balancer Aplikasi eksternal global, GFE lapisan kedua dapat dikonfigurasi untuk menggunakan salah satu algoritma alternatif berikut dengan menggunakan serviceLbPolicy:

   • SPRAY_TO_REGION: GFE lapisan kedua tidak lebih memilih memilih instance backend atau endpoint di zona yang sama dengan GFE lapisan kedua. GFE lapisan kedua mencoba mendistribusikan traffic ke semua instance atau endpoint backend di semua zona region. Hal ini dapat menyebabkan distribusi beban yang lebih merata dengan mengorbankan peningkatan traffic antarzona.
   • WATERFALL_BY_ZONE: GFE lapisan kedua sangat lebih memilih memilih instance backend atau endpoint di zona yang sama dengan GFE lapisan kedua. GFE lapisan kedua hanya mengarahkan permintaan ke backend di zona yang berbeda setelah semua backend di zona saat ini mencapai kapasitas yang dikonfigurasi.
5. GFE lapisan kedua memilih instance atau endpoint dalam zona. Secara default, GFE lapisan kedua mendistribusikan permintaan di antara backend dengan cara round-robin. Khusus untuk Load Balancer Aplikasi eksternal global, Anda dapat mengubahnya menggunakan kebijakan lokalitas load balancing (localityLbPolicy). Kebijakan lokalitas load balancing hanya berlaku untuk backend dalam zona yang dipilih yang telah dibahas pada langkah sebelumnya.

Load Balancer Aplikasi eksternal regional

Untuk Load Balancer Aplikasi eksternal regional, distribusi traffic didasarkan pada mode load balancing dan kebijakan lokalitas load balancing.

Mode penyeimbangan menentukan bobot dan fraksi traffic yang harus dikirim ke setiap grup (grup instance atau NEG). Kebijakan lokalitas load balancing (LocalityLbPolicy) menentukan cara backend dalam grup di-load balancing.

Saat menerima traffic, layanan backend akan mengarahkan traffic terlebih dahulu ke backend (grup instance atau NEG) sesuai dengan mode balancing backend. Setelah backend dipilih, traffic kemudian didistribusikan di antara instance atau endpoint dalam grup backend tersebut sesuai dengan kebijakan lokalitas load balancing.

Untuk informasi selengkapnya, lihat referensi berikut:

• Mode balancing
• Kebijakan lokalitas load balancing (dokumentasi API layanan backend regional).

Afinitas sesi

Afinitas sesi memberikan upaya terbaik untuk mengirim permintaan dari klien tertentu ke backend yang sama selama backend tersebut responsif dan memiliki kapasitas, sesuai dengan mode balancing yang dikonfigurasi.

Saat Anda menggunakan afinitas sesi, sebaiknya gunakan mode penyeimbangan RATE, bukan UTILIZATION. Afinitas sesi berfungsi paling baik jika Anda menetapkan mode balancing ke permintaan per detik (RPS).

Load Balancer Aplikasi Eksternal menawarkan jenis afinitas sesi berikut:

• TIDAK ADA. Afinitas sesi tidak ditetapkan untuk load balancer.
• Afinitas IP klien
• Afinitas berbasis cookie
• Afinitas kolom header
• Afinitas Cookie HTTP
• Afinitas sesi berbasis cookie stateful

Tabel berikut meringkas opsi afinitas sesi yang didukung oleh Load Balancer Aplikasi eksternal:

Mode load balancer	Opsi afinitas sesi
	Tidak ada	IP Klien	Cookie yang dihasilkan	Kolom header	Cookie HTTP	Cookie stateful
Load Balancer Aplikasi eksternal global
Load Balancer Aplikasi Klasik
Load Balancer Aplikasi eksternal regional

Ketersediaan tinggi dan failover

Ketersediaan tinggi dan failover di Load Balancer Aplikasi eksternal dapat dikonfigurasi di tingkat load balancer. Hal ini ditangani dengan membuat Load Balancer Aplikasi eksternal regional cadangan di region mana pun tempat Anda memerlukan pencadangan.

Tabel berikut menjelaskan perilaku failover.

Mode load balancer	Metode failover
Load Balancer Aplikasi eksternal global Load Balancer Aplikasi klasik	Anda dapat mengonfigurasi konfigurasi failover aktif-pasif yang mengalihkan traffic ke Load Balancer Aplikasi eksternal regional cadangan. Anda menggunakan health check untuk mendeteksi pemadaman layanan dan kebijakan perutean Cloud DNS untuk merutekan traffic saat failover dipicu.
Load Balancer Aplikasi eksternal regional	Gunakan salah satu metode berikut untuk memastikan deployment dengan ketersediaan tinggi: Anda dapat mengonfigurasi konfigurasi failover aktif-pasif yang mengalihkan traffic ke Load Balancer Aplikasi eksternal regional cadangan. Anda menggunakan health check untuk mendeteksi pemadaman layanan dan kebijakan perutean failover Cloud DNS untuk merutekan traffic saat failover dipicu oleh health check yang gagal. Untuk mengetahui detailnya, lihat Failover untuk Load Balancer Aplikasi eksternal. Anda dapat mengonfigurasi konfigurasi failover aktif-aktif dengan men-deploy beberapa Load Balancer Aplikasi eksternal regional individual di region yang Anda tentukan sebagai yang paling mendukung traffic untuk aplikasi Anda. Anda menggunakan kebijakan perutean geolokasi Cloud DNS untuk merutekan traffic ke region yang sesuai berdasarkan asal permintaan klien. Anda juga dapat menggunakan health check untuk mendeteksi pemadaman layanan dan merutekan traffic hanya ke load balancer yang berfungsi dengan baik. Untuk mengetahui detailnya, lihat Ketersediaan tinggi untuk Load Balancer Aplikasi eksternal regional.

Dukungan HTTP/2

HTTP/2 adalah revisi besar dari protokol HTTP/1. HTTP/2 didukung untuk koneksi antara klien dan Load Balancer Aplikasi eksternal, serta untuk koneksi antara load balancer dan backend-nya.

Load balancer secara otomatis menegosiasikan HTTP/2 dengan klien sebagai bagian dari handshake TLS menggunakan ekstensi TLS ALPN. Meskipun load balancer dikonfigurasi untuk menggunakan HTTPS, klien modern akan menggunakan HTTP/2 secara default. Hal ini dikontrol di sisi klien, bukan di load balancer.

Jika klien tidak mendukung HTTP/2 dan load balancer dikonfigurasi untuk menggunakan HTTP/2 antara load balancer dan instance backend, load balancer mungkin masih menegosiasikan koneksi HTTPS atau menerima permintaan HTTP yang tidak aman. Permintaan HTTPS atau HTTP tersebut kemudian diubah oleh load balancer untuk melakukan proxy permintaan melalui HTTP/2 ke instance backend.

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

Streaming serentak maksimum HTTP/2

Setelan HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS menjelaskan jumlah maksimum streaming yang diterima endpoint, yang dimulai oleh peer. Nilai yang diiklankan oleh klien HTTP/2 ke load balancer Google Cloud secara efektif tidak berarti karena load balancer tidak memulai streaming ke klien.

Jika load balancer menggunakan HTTP/2 untuk berkomunikasi dengan server yang berjalan di VM, load balancer akan mematuhi nilai SETTINGS_MAX_CONCURRENT_STREAMS yang diiklankan oleh server. Jika nilai nol diiklankan, load balancer tidak dapat meneruskan permintaan ke server, dan hal ini dapat menyebabkan error.

Batasan HTTP/2

• HTTP/2 antara load balancer dan instance dapat memerlukan koneksi TCP yang jauh lebih banyak ke instance daripada HTTP(S). Penggabungan koneksi, pengoptimalan yang mengurangi jumlah koneksi ini dengan HTTP(S), saat ini tidak tersedia dengan HTTP/2. Akibatnya, Anda mungkin melihat latensi backend yang tinggi karena koneksi backend dibuat lebih sering.
• HTTP/2 antara load balancer dan backend tidak mendukung pengoperasian Protokol WebSocket melalui satu aliran koneksi HTTP/2 (RFC 8441).
• HTTP/2 antara load balancer dan backend tidak mendukung push server.
• Rasio error dan volume permintaan gRPC tidak terlihat di Google Cloud API atau konsol Google Cloud. Jika endpoint gRPC menampilkan error, log load balancer dan data pemantauan akan melaporkan kode respons HTTP OK 200.

Dukungan HTTP/3

HTTP/3 adalah protokol internet generasi berikutnya. Protokol ini dibuat berdasarkan QUIC IETF, protokol yang dikembangkan dari protokol QUIC Google asli. HTTP/3 didukung antara Load Balancer Aplikasi eksternal, Cloud CDN, dan klien.

Dukungan Google QUIC (juga dikenal sebagai gQUIC) dihapus pada April 2023 untuk mendukung HTTP/3 daripada IETF QUIC, yang merupakan standar IETF dan telah terbukti memiliki performa lebih baik daripada gQUIC.

Secara khusus:

• IETF QUIC adalah protokol lapisan transpor yang memberikan kontrol kemacetan dan keandalan yang mirip dengan TCP, menggunakan TLS 1.3 untuk keamanan, dan meningkatkan performa.
• HTTP/3 adalah lapisan aplikasi yang dibuat di atas IETF QUIC, dan bergantung pada QUIC untuk menangani multiplexing, kontrol kemacetan, deteksi kehilangan, dan pengiriman ulang.
• HTTP/3 memungkinkan inisiasi koneksi klien yang lebih cepat, menghentikan pemblokiran head-of-line di stream multipleks, dan mendukung migrasi koneksi saat alamat IP klien berubah.
• HTTP/3 didukung untuk koneksi antara klien dan load balancer, bukan koneksi antara load balancer dan backend-nya.
• Koneksi HTTP/3 menggunakan algoritma kontrol kemacetan BBR.

HTTP/3 di load balancer dapat meningkatkan waktu pemuatan halaman web, mengurangi buffering ulang video, dan meningkatkan throughput pada koneksi latensi yang lebih tinggi.

Tabel berikut menentukan dukungan HTTP/3 untuk Load Balancer Aplikasi eksternal dalam setiap mode.

Mode load balancer	Dukungan HTTP/3
Load Balancer Aplikasi eksternal global (selalu Paket Premium)
Load Balancer Aplikasi Klasik di Paket Premium
Load Balancer Aplikasi Klasik di Paket Standar
Load Balancer Aplikasi eksternal regional (Paket Premium atau Standar)

Cara HTTP/3 dinegosiasikan

Saat HTTP/3 diaktifkan, load balancer akan mengiklankan dukungan ini kepada klien, sehingga klien yang mendukung HTTP/3 dapat mencoba membuat koneksi HTTP/3 dengan load balancer HTTPS.

• Klien yang diimplementasikan dengan benar selalu kembali ke HTTPS atau HTTP/2 saat tidak dapat membuat koneksi HTTP/3.
• Klien yang mendukung HTTP/3 menggunakan pengetahuan sebelumnya yang di-cache tentang dukungan HTTP/3 untuk menghemat perjalanan bolak-balik yang tidak perlu di masa mendatang.
• Karena penggantian ini, mengaktifkan atau menonaktifkan HTTP/3 di load balancer tidak akan mengganggu kemampuan load balancer untuk terhubung ke klien.

Dukungan diiklankan di header respons HTTP Alt-Svc. Jika HTTP/3 diaktifkan, respons dari load balancer akan menyertakan nilai header alt-svc berikut:

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000"

Catatan: Header Alt-Svc mengiklankan beberapa versi HTTP/3 untuk mendukung draf sebelumnya yang digunakan oleh beberapa klien—misalnya, h3-29.

Jika HTTP/3 telah ditetapkan secara eksplisit ke DISABLE, respons tidak menyertakan header respons alt-svc.

Jika Anda mengaktifkan HTTP/3 di load balancer HTTPS, beberapa situasi dapat menyebabkan klien Anda kembali ke HTTPS atau HTTP/2, bukan menegosiasikan HTTP/3. Contoh ini meliputi:

• Saat klien mendukung versi HTTP/3 yang tidak kompatibel dengan versi HTTP/3 yang didukung oleh load balancer HTTPS.
• Saat load balancer mendeteksi bahwa traffic UDP diblokir atau dibatasi kapasitasnya dengan cara yang akan mencegah HTTP/3 berfungsi.
• Klien tidak mendukung HTTP/3 sama sekali, sehingga tidak mencoba melakukan negosiasi koneksi HTTP/3.

Jika koneksi kembali ke HTTPS atau HTTP/2, kami tidak menganggapnya sebagai kegagalan load balancer.

Sebelum mengaktifkan HTTP/3, pastikan perilaku yang dijelaskan sebelumnya dapat diterima untuk beban kerja Anda.

Mengonfigurasi HTTP/3

NONE (default) dan ENABLE mengaktifkan dukungan HTTP/3 untuk load balancer Anda.

Saat HTTP/3 diaktifkan, load balancer akan mengiklankannya kepada klien, yang memungkinkan klien yang mendukungnya untuk menegosiasikan versi HTTP/3 dengan load balancer. Klien yang tidak mendukung HTTP/3 tidak menegosiasikan koneksi HTTP/3. Anda tidak perlu menonaktifkan HTTP/3 secara eksplisit kecuali jika Anda telah mengidentifikasi implementasi klien yang rusak.

Load Balancer Aplikasi Eksternal menyediakan tiga cara untuk mengonfigurasi HTTP/3 seperti yang ditunjukkan dalam tabel berikut.

Nilai quicOverride	Perilaku
NONE	Dukungan untuk HTTP/3 diiklankan kepada klien.
ENABLE	Dukungan untuk HTTP/3 diiklankan kepada klien. Catatan: TLS 0-RTT (juga dikenal sebagai TLS Early Data) belum didukung untuk HTTP/3.
DISABLE	Secara eksplisit menonaktifkan HTTP/3 iklan dan Google QUIC untuk klien.

Untuk mengaktifkan (atau menonaktifkan) HTTP/3 secara eksplisit, ikuti langkah-langkah berikut.

Konsol: HTTPS

Catatan: Menetapkan negosiasi HTTP/3 saat ini tidak didukung di halaman proxy target dan harus dikonfigurasi dengan mengedit konfigurasi load balancer.

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

Buka Load balancing

1. Pilih load balancer yang ingin Anda edit.
2. Klik Frontend configuration.
3. Pilih alamat IP dan port frontend yang ingin Anda edit. Untuk mengedit konfigurasi HTTP/3, protokolnya harus HTTPS.

Mengaktifkan HTTP/3

1. Pilih menu QUIC negotiation.
2. Untuk mengaktifkan HTTP/3 secara eksplisit untuk frontend ini, pilih Enabled.
3. Jika Anda memiliki beberapa aturan frontend yang mewakili IPv4 dan IPv6, pastikan untuk mengaktifkan HTTP/3 di setiap aturan.

Menonaktifkan HTTP/3

1. Pilih menu QUIC negotiation.
2. Untuk menonaktifkan HTTP/3 secara eksplisit untuk frontend ini, pilih Nonaktif.
3. Jika Anda memiliki beberapa aturan frontend yang mewakili IPv4 dan IPv6, pastikan untuk menonaktifkan HTTP/3 untuk setiap aturan.

gcloud: HTTPS

Sebelum menjalankan perintah ini, Anda harus membuat resource sertifikat SSL untuk setiap sertifikat.

gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
    --global \
    --quic-override=QUIC_SETTING

Ganti QUIC_SETTING dengan salah satu dari berikut ini:

• NONE (default): memungkinkan Google mengontrol kapan HTTP/3 diiklankan.

  Jika Anda memilih NONE, HTTP/3 akan diiklankan kepada klien, tetapi Google QUIC tidak diiklankan. Di konsol Google Cloud, opsi ini disebut Automatic (Default).

• ENABLE: mengiklankan HTTP/3 kepada klien.

• DISABLE: tidak mengiklankan HTTP/3 kepada klien.

API: HTTPS

POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride

{
  "quicOverride": QUIC_SETTING
}

Ganti QUIC_SETTING dengan salah satu dari berikut ini:

• NONE (default): Memungkinkan Google mengontrol kapan HTTP/3 diiklankan.

  Jika Anda memilih NONE, HTTP/3 akan diiklankan kepada klien, tetapi Google QUIC tidak diiklankan. Di konsol Google Cloud, opsi ini disebut Automatic (Default).

• ENABLE: Mengiklankan HTTP/3 dan Google QUIC kepada klien.

• DISABLE: Tidak mengiklankan HTTP/3 atau Google QUIC kepada klien.

Dukungan WebSocket

Load balancer berbasis HTTP(S) Google Cloud mendukung protokol websocket saat Anda menggunakan HTTP atau HTTPS sebagai protokol ke backend. Load balancer tidak memerlukan konfigurasi apa pun untuk membuat proxy koneksi websocket.

Protokol websocket menyediakan saluran komunikasi full-duplex antara klien dan load balancer. Untuk mengetahui informasi selengkapnya, lihat RFC 6455.

Protokol websocket berfungsi sebagai berikut:

1. Load balancer mengenali permintaan Upgrade websocket dari klien HTTP(S). Permintaan berisi header Connection: Upgrade, Upgrade: websocket, diikuti dengan header permintaan terkait websocket lainnya yang relevan.
2. Backend mengirimkan respons Upgrade websocket. Instance backend mengirimkan respons 101 switching protocol dengan header Connection: Upgrade, Upgrade: websocket, dan header respons terkait websocket lainnya.
3. Load balancer melakukan proxy traffic dua arah selama durasi koneksi saat ini.

Jika instance backend menampilkan respons error dengan kode respons 426 atau 502, load balancer akan menutup koneksi.

Waktu tunggu koneksi WebSocket bergantung pada jenis load balancer (global, regional, atau klasik). Untuk mengetahui detailnya, lihat Waktu tunggu layanan backend habis.

Afinitas sesi untuk websocket berfungsi sama seperti untuk permintaan lainnya. Untuk mengetahui informasi selengkapnya, lihat Afinitas sesi.

Dukungan gRPC

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

• Sistem terdistribusi berlatensi rendah dan sangat skalabel
• Mengembangkan klien seluler yang berkomunikasi dengan server cloud
• Mendesain 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 melakukan proxy permintaan secara menyeluruh melalui HTTP/2. Untuk melakukannya:

1. Mengonfigurasi load balancer HTTPS.
2. Aktifkan 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 di load balancer yang dikonfigurasi untuk menggunakan HTTP/2 antara load balancer dan instance backend. Permintaan HTTP atau HTTPS tersebut diubah oleh load balancer untuk melakukan proxy permintaan melalui HTTP/2 ke instance backend.

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

Jika Anda ingin mengonfigurasi Load Balancer Aplikasi eksternal menggunakan HTTP/2 dengan Ingress Google Kubernetes Engine atau menggunakan gRPC dan HTTP/2 dengan Ingress, lihat HTTP/2 untuk load balancing dengan Ingress.

Untuk informasi tentang cara memecahkan masalah HTTP/2, lihat Memecahkan masalah HTTP/2 ke backend.

Untuk informasi tentang batasan HTTP/2, lihat batasan HTTP/2.

Dukungan TLS

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

Saat menggunakan HTTPS sebagai protokol layanan backend, load balancer dapat menegosiasikan TLS 1.0, 1.1, 1.2, atau 1.3 ke backend.

Dukungan TLS bersama

TLS Bersama, atau mTLS, adalah protokol standar industri untuk autentikasi bersama antara klien dan server. Hal ini memastikan bahwa klien dan server melakukan autentikasi satu sama lain dengan memverifikasi bahwa masing-masing memiliki sertifikat yang valid yang dikeluarkan oleh certificate authority (CA) tepercaya. Tidak seperti TLS standar, yang hanya mengautentikasi server, mTLS mewajibkan klien dan server untuk menunjukkan sertifikat, yang mengonfirmasi identitas kedua belah pihak sebelum komunikasi dilakukan.

Semua Load Balancer Aplikasi mendukung mTLS. Dengan mTLS, load balancer meminta klien mengirim sertifikat untuk mengautentikasi dirinya sendiri selama handshake TLS dengan load balancer. Anda dapat mengonfigurasi penyimpanan kepercayaan Pengelola Sertifikat yang kemudian digunakan load balancer untuk memvalidasi rantai kepercayaan sertifikat klien.

Untuk informasi selengkapnya tentang mTLS, lihat Autentikasi TLS bersama.

Batasan

• Load balancer HTTPS tidak mengirim notifikasi penutupan close_notify saat menghentikan koneksi SSL. Artinya, load balancer menutup koneksi TCP, bukan melakukan penonaktifan SSL.
• Load balancer HTTPS hanya mendukung karakter kecil dalam domain di atribut nama umum (CN) atau atribut nama alternatif subjek (SAN) sertifikat. Sertifikat dengan karakter huruf besar dalam domain hanya ditampilkan jika ditetapkan sebagai sertifikat primer di proxy target.
• Load balancer HTTPS tidak menggunakan ekstensi Server Name Indication (SNI) saat terhubung ke backend, kecuali untuk load balancer dengan backend Internet NEG. Untuk mengetahui detail selengkapnya, lihat Enkripsi dari load balancer ke backend.

• Saat menggunakan Load Balancer Aplikasi eksternal regional dengan Cloud Run di lingkungan VPC Bersama, jaringan VPC mandiri di project layanan dapat mengirim traffic ke layanan Cloud Run lainnya yang di-deploy di project layanan lain dalam lingkungan VPC Bersama yang sama. Ini adalah masalah yang diketahui dan bentuk akses ini akan diblokir pada masa mendatang.

• Google Cloud tidak menjamin bahwa koneksi TCP yang mendasarinya dapat tetap terbuka selama keseluruhan nilai waktu tunggu layanan backend. Sistem klien harus menerapkan logika percobaan ulang, bukan mengandalkan koneksi TCP yang terbuka untuk jangka waktu yang lama.

• Anda tidak dapat membuat Load Balancer Aplikasi eksternal regional di Paket Premium menggunakan konsol Google Cloud. Selain itu, hanya region yang mendukung Paket Standar yang tersedia untuk load balancer ini di konsol Google Cloud. Gunakan gcloud CLI atau API. Sebagai gantinya, gunakan gcloud CLI atau API.

• Cloud CDN memungkinkan Anda memaksa objek atau kumpulan objek untuk diabaikan oleh cache dengan meminta invalidasi cache. Saat Anda menggunakan Load Balancer Aplikasi eksternal global dengan referensi layanan lintas project VPC Bersama, secara default, admin project layanan tidak akan memiliki izin yang diperlukan untuk meminta pembatalan validasi cache. Hal ini karena pembatalan validasi cache dikonfigurasi di project frontend (yaitu project yang memiliki aturan penerusan, proxy target, dan peta URL load balancer). Dengan demikian, pembatalan validasi cache hanya dapat dikeluarkan oleh akun utama yang memiliki peran IAM untuk mengonfigurasi resource terkait load balancer di project frontend (misalnya, peran Compute Network Admin). Admin layanan, yang mengontrol penyediaan layanan backend dalam project terpisah, harus bekerja sama dengan admin load balancer project frontend untuk mengeluarkan pembatalan validasi cache untuk layanan lintas project mereka.

Langkah selanjutnya

• Untuk mempelajari cara men-deploy Load Balancer Aplikasi eksternal global, lihat Menyiapkan Load Balancer Aplikasi eksternal dengan backend Compute Engine.

• Untuk mempelajari cara men-deploy Load Balancer Aplikasi eksternal regional, lihat Menyiapkan Load Balancer Aplikasi eksternal regional dengan backend Compute Engine.

• Jika Anda adalah pengguna Load Balancer Aplikasi klasik yang sudah ada, pastikan Anda meninjau Ringkasan migrasi saat merencanakan deployment baru dengan Load Balancer Aplikasi eksternal global.

• Untuk mempelajari cara mengotomatiskan penyiapan Load Balancer Aplikasi eksternal dengan Terraform, lihat Contoh modul Terraform untuk Load Balancer Aplikasi eksternal.

• Untuk mempelajari cara mengonfigurasi kemampuan pengelolaan traffic lanjutan yang tersedia dengan Load Balancer Aplikasi eksternal global, lihat Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global.

• Untuk mempelajari cara mengonfigurasi kemampuan pengelolaan traffic lanjutan yang tersedia dengan Load Balancer Aplikasi eksternal regional, lihat Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal regional.

• Untuk mempelajari cara menayangkan situs, lihat Menayangkan situs.

• Untuk menemukan lokasi PoP Google, lihat lokasi GFE.

• Untuk mempelajari pengelolaan kapasitas, lihat Tutorial pengelolaan kapasitas dengan load balancing dan Pengoptimalan kapasitas aplikasi dengan load balancing global.

• Untuk mempelajari cara menggunakan Pengelola Sertifikat guna menyediakan dan mengelola sertifikat SSL, lihat Ringkasan Pengelola Sertifikat.

• Untuk menyisipkan logika kustom ke jalur data load balancing, konfigurasikan plugin atau info Ekstensi Layanan.

• Khusus untuk Load Balancer Aplikasi eksternal regional, Anda dapat mencoba menggunakan Apigee Shadow API Discovery untuk menemukan API bayangan (juga dikenal sebagai API yang tidak terdokumentasi) di infrastruktur Google Cloud yang ada. Pastikan Anda membaca batasan terkait sebelum mengaktifkan Penemuan Shadow API.