Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi internal

Load Balancer Aplikasi internal regional dan Load Balancer Aplikasi internal lintas region mendukung fitur pengelolaan traffic lanjutan berikut:

Pembimbingan traffic. Mengarahkan traffic secara cerdas berdasarkan parameter HTTP(S) (misalnya, host, jalur, header, dan parameter permintaan lainnya).
Tindakan traffic. Melakukan tindakan berbasis permintaan dan respons (misalnya, pengalihan dan transformasi header).
Kebijakan traffic. Menyesuaikan perilaku load balancing (misalnya, algoritma load balancing lanjutan).

Anda dapat menyiapkan fitur ini menggunakan peta URL dan layanan backend. Untuk informasi selengkapnya, lihat topik berikut:

Contoh kasus penggunaan

Pengelolaan traffic menangani banyak kasus penggunaan. Bagian ini memberikan beberapa contoh tingkat tinggi.

Pengarahan traffic: pemilihan rute berbasis header

Pengarahan traffic memungkinkan Anda mengarahkan traffic ke instance layanan berdasarkan parameter HTTP seperti header permintaan. Misalnya, jika perangkat pengguna adalah perangkat seluler dengan user-agent:Mobile di header permintaan, pemilihan traffic dapat mengirim traffic tersebut ke instance layanan yang ditetapkan untuk menangani traffic seluler, dan mengirim traffic yang tidak memiliki user-agent:Mobile ke instance yang ditetapkan untuk menangani traffic dari perangkat lain.

Pengarah traffic Cloud Load Balancing. — **Gambar 1.** Pengalihan traffic Cloud Load Balancing (klik untuk memperbesar).

Tindakan traffic: pemisahan traffic berbasis bobot

Men-deploy versi baru dari layanan produksi yang ada umumnya menimbulkan beberapa risiko. Meskipun pengujian Anda lulus di staging, Anda mungkin tidak ingin langsung menguji 100% pengguna dengan versi baru. Dengan pengelolaan traffic, Anda dapat menentukan pemisahan traffic berbasis persentase di beberapa layanan backend.

Misalnya, Anda dapat mengirim 95% traffic ke versi layanan sebelumnya dan 5% ke versi layanan baru. Setelah memvalidasi bahwa versi produksi baru berfungsi seperti yang diharapkan, Anda dapat secara bertahap mengubah persentase hingga 100% traffic mencapai versi baru layanan Anda. Pemisahan traffic biasanya digunakan untuk men-deploy versi baru, pengujian A/B, migrasi layanan, dan proses serupa.

Pembagian traffic Cloud Load Balancing. — **Gambar 2.** Pemisahan traffic Cloud Load Balancing (klik untuk memperbesar).

Kebijakan traffic: pencerminan permintaan

Organisasi Anda mungkin memiliki persyaratan kepatuhan tertentu yang mewajibkan agar semua traffic dicerminkan ke layanan tambahan yang dapat, misalnya, mencatat detail permintaan dalam database untuk diputar ulang nanti.

Ekstensibilitas dengan Ekstensi Layanan

Integrasi dengan Ekstensi Layanan memungkinkan Anda menyisipkan logika kustom ke jalur data load balancing Load Balancer Aplikasi yang didukung.

Untuk informasi selengkapnya, lihat Ringkasan Ekstensi Layanan.

Komponen pengelolaan traffic

Pada tingkat tinggi, load balancer menyediakan pengelolaan traffic dengan memanfaatkan resource peta URL regional dan layanan backend regional.

Untuk Load Balancer Aplikasi internal lintas-region, pengelolaan traffic menggunakan resource peta URL global dan layanan backend global.

Anda dapat menyiapkan pengarahan traffic dan tindakan traffic menggunakan peta URL. Resource Google Cloud yang terkait dengan peta URL mencakup hal berikut:

Aturan rute
Pencocokan aturan
Tindakan aturan

Anda dapat menyiapkan kebijakan traffic menggunakan layanan backend. Resource Google Cloud yang terkait dengan layanan backend meliputi hal berikut:

Pemutus rangkaian
Kebijakan load balancer lokalitas
Setelan load balancer hash konsisten
Deteksi outlier

Diagram berikut menunjukkan resource yang digunakan untuk menerapkan setiap fitur.

Model data Cloud Load Balancing. — **Gambar 3.** Model data Cloud Load Balancing (klik untuk memperbesar).

Merutekan permintaan ke backend

Di Load Balancer Aplikasi internal regional, backend untuk traffic Anda ditentukan menggunakan pendekatan dua fase:

Load balancer memilih layanan backend dengan backend. Backend dapat berupa instance virtual machine (VM) Compute Engine dalam grup instance tidak terkelola, VM Compute Engine dalam grup instance terkelola (MIG), atau penampung melalui node Google Kubernetes Engine (GKE) dalam grup endpoint jaringan (NEG). Load balancer memilih layanan backend berdasarkan aturan yang ditentukan dalam peta URL regional.
Layanan backend memilih instance backend berdasarkan kebijakan yang ditentukan dalam layanan backend regional.

Saat mengonfigurasi perutean, Anda dapat memilih antara mode berikut:

Aturan host dan jalur sederhana
Host, jalur, dan aturan rute lanjutan

Kedua mode tersebut bersifat eksklusif. Setiap peta URL hanya dapat berisi satu mode atau mode lainnya.

Aturan host dan jalur sederhana

Dalam aturan host dan jalur sederhana, peta URL berfungsi seperti yang dijelaskan dalam ringkasan peta URL.

Diagram berikut menunjukkan alur logis aturan host dan jalur sederhana.

Alur peta URL dengan aturan host dan jalur sederhana. — **Gambar 4.** Alur peta URL dengan aturan host dan jalur sederhana (klik untuk memperbesar).

Permintaan awalnya dievaluasi menggunakan aturan host. Host adalah domain yang ditentukan oleh permintaan. Jika host permintaan cocok dengan salah satu entri di kolom hosts, pencocok jalur terkait akan digunakan.

Selanjutnya, pencocok jalur dievaluasi. Aturan jalur dievaluasi berdasarkan jalur terpanjang yang cocok terlebih dahulu, dan Anda dapat menentukan aturan jalur dalam urutan apa pun. Setelah kecocokan yang paling spesifik ditemukan, permintaan akan dirutekan ke layanan backend yang sesuai. Jika permintaan tidak cocok, layanan backend default akan digunakan.

Aturan host dan jalur sederhana standar mungkin terlihat seperti berikut, dengan traffic video diarahkan ke video-backend-service, dan semua traffic lainnya diarahkan ke web-backend-service.

gcloud compute url-maps describe lb-map

defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: regions/us-west1/backendServices/video-backend-service
region: regions/us-west1

Host, jalur, dan aturan rute lanjutan

Aturan host, jalur, dan rute lanjutan memberikan opsi konfigurasi tambahan dibandingkan dengan aturan host dan jalur sederhana. Opsi ini memungkinkan pola pengelolaan traffic yang lebih canggih dan juga mengubah beberapa semantik. Misalnya, aturan rute memiliki nilai prioritas terkait dan ditafsirkan dalam urutan prioritas (bukan dengan menggunakan semantik longest-path-matches-first).

Seperti pada contoh aturan host dan jalur sederhana sebelumnya, Anda dapat mengonfigurasi manajemen traffic lanjutan menggunakan peta URL. Misalnya, peta URL berikut mengonfigurasi perutean dengan 95% traffic dirutekan ke satu layanan backend, dan 5% traffic dirutekan ke layanan backend lain.

gcloud compute url-maps describe lb-map

defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/service-a
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: ''
    routeAction:
      weightedBackendServices:
      - backendService: regions/us-west1/backendServices/service-a
        weight: 95
      - backendService: regions/us-west1/backendServices/service-b
        weight: 5
region: regions/us-west1

Aturan host

Saat permintaan mencapai load balancer, kolom host permintaan akan dievaluasi terhadap hostRules yang ditentukan dalam peta URL. Setiap aturan host terdiri dari daftar satu atau beberapa host dan satu pencocok jalur (pathMatcher). Jika tidak ada hostRules yang ditentukan, permintaan akan dirutekan ke defaultService.

Untuk informasi selengkapnya, lihat hostRules[] dan defaultService di dokumentasi API peta URL regional.

Pencocok jalur

Setelah permintaan cocok dengan aturan host, load balancer akan mengevaluasi pencocok jalur yang sesuai dengan host.

Pencocok jalur terdiri dari hal berikut:

Satu atau beberapa aturan jalur (pathRules) atau aturan rute (routeRules).
Layanan default (defaultService), yang merupakan layanan backend default yang digunakan saat tidak ada layanan backend lain yang cocok.

Untuk informasi selengkapnya, lihat pathMatchers[], pathMatchers[].pathRules[], dan pathMatchers[].routeRules[] di dokumentasi API peta URL regional.

Aturan jalur

Aturan jalur (pathRules) menentukan satu atau beberapa jalur URL, seperti / atau /video. Aturan jalur umumnya ditujukan untuk jenis perutean berbasis host dan jalur sederhana yang dijelaskan sebelumnya.

Untuk informasi selengkapnya, lihat pathRules[] di dokumentasi API peta URL regional.

Aturan rute

Aturan rute (routeRules) mencocokkan informasi dalam permintaan yang masuk dan membuat keputusan pemilihan rute berdasarkan kecocokan tersebut.

Aturan rute dapat berisi berbagai aturan pencocokan (matchRules) dan berbagai tindakan rute (routeAction).

Aturan pencocokan mengevaluasi permintaan masuk berdasarkan jalur, header, dan parameter kueri permintaan HTTP(S). Aturan pencocokan mendukung berbagai jenis pencocokan (misalnya, pencocokan awalan) serta pengubah (misalnya, tidak sensitif huruf besar/kecil). Hal ini memungkinkan Anda, misalnya, mengirim permintaan HTTP(S) ke kumpulan backend berdasarkan keberadaan header HTTP yang ditentukan secara kustom.

Catatan: Opsi dan semantik pencocokan berbeda-beda bergantung pada bagian permintaan yang Anda cocokkan. Untuk informasi selengkapnya, lihat matchRules[] di dokumentasi API peta URL regional.

Jika Anda memiliki beberapa aturan rute, load balancer akan menjalankannya dalam urutan prioritas (berdasarkan kolom priority), yang memungkinkan Anda menentukan logika kustom untuk pencocokan, pemilihan rute, dan tindakan lainnya.

Dalam aturan rute tertentu, saat kecocokan pertama dibuat, load balancer berhenti mengevaluasi aturan kecocokan, dan aturan kecocokan yang tersisa akan diabaikan.

Google Cloud melakukan tindakan berikut:

Mencari aturan kecocokan pertama yang cocok dengan permintaan.
Berhenti melihat aturan pencocokan lainnya.
Menerapkan tindakan dalam tindakan rute yang sesuai.

Aturan rute memiliki beberapa komponen, seperti yang dijelaskan dalam tabel berikut.

Komponen aturan rute (`API field name`)	Deskripsi
Prioritas (`priority`)	Angka dari 0 hingga 2.147.483.647 (yaitu, (2^31)-1) yang ditetapkan ke aturan rute dalam pencocok jalur tertentu. Prioritas menentukan urutan evaluasi aturan rute. Prioritas aturan akan menurun seiring bertambahnya jumlah aturan sehingga aturan dengan prioritas `4` dievaluasi sebelum aturan dengan prioritas `25`. Aturan pertama yang cocok dengan permintaan akan diterapkan. Angka prioritas dapat memiliki celah. Anda tidak dapat membuat lebih dari satu aturan dengan prioritas yang sama.
Deskripsi (`description`)	Deskripsi opsional maksimal 1.024 karakter.
Layanan (`service`)	URL lengkap atau sebagian dari resource layanan backend yang dituju traffic jika aturan ini cocok.
Aturan pencocokan (`matchRules`)	Satu atau beberapa aturan yang dievaluasi terhadap permintaan. `matchRules` ini dapat mencocokkan semua atau sebagian atribut HTTP permintaan, seperti jalur, header HTTP, dan parameter kueri (GET). Dalam `matchRule`, semua kriteria pencocokan harus dipenuhi agar `routeActions` `routeRule` dapat diterapkan. Jika `routeRule` memiliki beberapa `matchRules`, `routeActions` dari `routeRule` akan diterapkan saat permintaan cocok dengan salah satu `matchRules` `routeRule`.
Tindakan rute (`routeAction`)	Memungkinkan Anda menentukan tindakan yang akan dilakukan saat kriteria aturan pencocokan terpenuhi. Tindakan ini mencakup pemisahan traffic, penulisan ulang URL, percobaan ulang dan pencerminan, injeksi error, dan kebijakan CORS.
Tindakan pengalihan (`urlRedirect`)	Anda dapat mengonfigurasi tindakan untuk merespons dengan pengalihan HTTP saat kriteria aturan pencocokan terpenuhi. Kolom ini tidak dapat digunakan bersama dengan tindakan rute.
Tindakan header (`headerAction`)	Anda dapat mengonfigurasi aturan transformasi header permintaan dan respons saat kriteria dalam `matchRules` terpenuhi.

Untuk informasi selengkapnya, lihat kolom berikut dalam dokumentasi API peta URL regional:

routeRules[]
routeRules[].priority
routeRules[].description
routeRules[].service
routeRules[].matchRules[]
routeRules[].routeAction
routeRules[].urlRedirect
routeRules[].headerAction

Aturan pencocokan

Aturan pencocokan (matchRules) mencocokkan satu atau beberapa atribut permintaan dan mengambil tindakan yang ditentukan dalam aturan rute. Daftar berikut memberikan beberapa contoh atribut permintaan yang dapat dicocokkan menggunakan aturan pencocokan:

Host: Nama host adalah bagian nama domain dari URL; misalnya, bagian nama host dari URL http://example.net/video/hd adalah example.net. Dalam permintaan, nama host berasal dari header Host, seperti yang ditunjukkan dalam contoh perintah curl ini, dengan 10.1.2.9 adalah alamat IP load-balanced:
```
curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
```
Jalur mengikuti nama host; misalnya /images. Aturan ini dapat menentukan apakah seluruh jalur atau hanya bagian awal jalur yang perlu cocok.
Parameter permintaan HTTP lainnya, seperti header HTTP, yang memungkinkan pencocokan cookie, serta pencocokan berdasarkan parameter kueri (variabel GET).

Untuk mengetahui daftar lengkap aturan pencocokan yang didukung, lihat pathMatchers[].routeRules[].matchRules[] dalam dokumentasi API peta URL regional.

Tindakan rute

Tindakan rute adalah tindakan tertentu yang akan diambil saat aturan rute cocok dengan atribut permintaan.

Tindakan rute (`API field name`)	Deskripsi
Pengalihan (`urlRedirect`)	Menampilkan kode respons 3xx yang dapat dikonfigurasi. Tindakan ini juga menetapkan header respons `Location` dengan URI yang sesuai, menggantikan host dan jalur seperti yang ditentukan dalam tindakan pengalihan.
Penulisan ulang URL (`urlRewrite`)	Menulis ulang bagian nama host URL, bagian jalur URL, atau keduanya, sebelum mengirim permintaan ke layanan backend yang dipilih.
Transformasi header (`headerAction`)	Menambahkan atau menghapus header permintaan sebelum mengirim permintaan ke layanan backend. Juga dapat menambahkan atau menghapus header respons setelah menerima respons dari layanan backend.
Duplikasi traffic (`requestMirrorPolicy`)	Selain meneruskan permintaan ke layanan backend yang dipilih, layanan ini mengirimkan permintaan yang identik ke layanan backend mirror yang dikonfigurasi secara fire and forget. Load balancer tidak menunggu respons dari backend tempat permintaan yang diduplikasi dikirim. Penduplikasian berguna untuk menguji versi baru layanan backend. Anda juga dapat menggunakannya untuk men-debug error produksi pada versi debug layanan backend, bukan pada versi produksi. Perhatikan batasan berikut saat menggunakan pencerminan traffic: Duplikasi traffic didukung jika kedua layanan backend memiliki backend grup instance terkelola, NEG zonal, atau NEG hybrid. Fitur ini tidak didukung untuk NEG internet, NEG serverless, dan backend Private Service Connect. Permintaan ke layanan backend yang dicerminkan tidak menghasilkan log atau metrik apa pun untuk Cloud Logging dan Cloud Monitoring.
Pemisahan traffic berbobot (`weightedBackendServices`)	Memungkinkan traffic untuk aturan yang cocok didistribusikan ke beberapa layanan backend, sebanding dengan bobot yang ditentukan pengguna yang ditetapkan ke setiap layanan backend. Kemampuan ini berguna untuk mengonfigurasi deployment bertahap atau pengujian A/B. Misalnya, tindakan rute dapat dikonfigurasi sedemikian rupa sehingga 99% traffic dikirim ke layanan yang menjalankan versi aplikasi yang stabil, sedangkan 1% traffic dikirim ke layanan terpisah yang menjalankan versi aplikasi yang lebih baru.
Percobaan ulang (`retryPolicy`)	Mengonfigurasi kondisi saat load balancer mencoba ulang permintaan yang gagal, berapa lama load balancer menunggu sebelum mencoba ulang, dan jumlah maksimum percobaan ulang yang diizinkan.
Waktu tunggu (`timeout`)	Menentukan waktu tunggu untuk rute yang dipilih. Waktu tunggu dihitung dari waktu permintaan diproses sepenuhnya hingga waktu respons diproses sepenuhnya. Waktu tunggu mencakup semua percobaan ulang.
Injeksi error (`faultInjectionPolicy`)	Menyebabkan error saat melayani permintaan untuk menyimulasikan kegagalan, termasuk latensi tinggi, kelebihan beban layanan, kegagalan layanan, dan partisi jaringan. Fitur ini berguna untuk menguji ketahanan layanan terhadap kesalahan simulasi.
Menunda injeksi (`faultInjectionPolicy`)	Memperkenalkan penundaan untuk bagian permintaan yang ditentukan pengguna sebelum mengirim permintaan ke layanan backend yang dipilih.
Membatalkan injeksi (`faultInjectionPolicy`)	Merespons langsung sebagian permintaan dengan kode status HTTP yang ditentukan pengguna, bukan meneruskan permintaan tersebut ke layanan backend.
Kebijakan keamanan (`corsPolicy`)	Kebijakan cross-origin resource sharing (CORS) menangani setelan untuk menerapkan permintaan CORS.

Anda dapat menentukan salah satu tindakan rute berikut:

Mengarahkan traffic ke satu layanan (service).
Membagi traffic di antara beberapa layanan (weightedBackendServices weight:x, dengan x harus antara 0 hingga 1.000).
URL alihan (urlRedirect).

Selain itu, Anda dapat menggabungkan salah satu tindakan rute yang disebutkan sebelumnya dengan satu atau beberapa tindakan rute berikut:

Duplikasi traffic (requestMirrorPolicy).
Menulis ulang host dan jalur URL (urlRewrite).
Mencoba lagi permintaan yang gagal (retryPolicy).
Tetapkan waktu tunggu (timeout).
Membuat kesalahan ke persentase traffic (faultInjectionPolicy).
Tambahkan kebijakan CORS (corsPolicy).
Memanipulasi header permintaan atau respons (headerAction).

Untuk informasi selengkapnya tentang konfigurasi dan semantik tindakan rute, lihat hal berikut dalam dokumentasi API peta URL regional:

urlRedirect
urlRewrite
headerAction
requestMirrorPolicy
weightedBackendServices
retryPolicy
timeout
faultInjectionPolicy
corsPolicy

Pengalihan HTTP-ke-HTTPS

Jika perlu mengalihkan traffic HTTP ke HTTPS, Anda dapat membuat dua aturan penerusan dengan alamat IP umum.

Agar dua aturan penerusan dapat berbagi alamat IP internal yang sama, Anda harus memesan alamat IP dan menyertakan tanda --purpose=SHARED_LOADBALANCER_VIP:

gcloud compute addresses create NAME \
    --region=us-west1 \
    --subnet=backend-subnet \
    --purpose=SHARED_LOADBALANCER_VIP

Untuk contoh lengkapnya, lihat Menyiapkan pengalihan HTTP-ke-HTTPS untuk Load Balancer Aplikasi internal.

Kebijakan traffic

Dengan menggunakan resource layanan backend, Anda dapat mengonfigurasi kebijakan traffic untuk menyetel load balancing dalam grup instance atau grup endpoint jaringan (NEG). Kebijakan ini hanya berlaku setelah layanan backend dipilih menggunakan peta URL Anda (seperti yang dijelaskan sebelumnya).

Kebijakan traffic memungkinkan Anda:

Mengontrol algoritma load balancing di antara instance dalam layanan backend.
Mengontrol volume koneksi ke layanan upstream.
Mengontrol penggusuran host yang tidak responsif dari layanan backend.

Fitur kebijakan traffic berikut dikonfigurasi di layanan backend regional.

Kebijakan traffic (`API field name`)	Deskripsi
Kebijakan lokalitas load balancing (`LocalityLbPolicy`)	Untuk layanan backend, distribusi traffic didasarkan pada mode load balancing dan kebijakan lokalitas load balancing. Mode penyeimbangan menentukan bobot/fraksi traffic yang harus dikirim ke setiap backend (grup instance atau NEG `GCE_VM_IP_PORT`). Kebijakan load balancing (`LocalityLbPolicy`) menentukan cara backend dalam zona atau dalam grup di-load balancing. Saat menerima traffic, layanan backend akan mengarahkan traffic terlebih dahulu ke backend (grup instance atau NEG `GCE_VM_IP_PORT`) sesuai dengan mode balancing backend. Setelah backend dipilih, traffic kemudian didistribusikan di antara instance atau endpoint dalam setiap zona sesuai dengan kebijakan lokalitas. Untuk grup instance terkelola regional, kebijakan lokalitas berlaku untuk setiap zona penyusun. Untuk mode penyeimbangan yang didukung, lihat Mode penyeimbangan. Untuk algoritma kebijakan load balancing yang didukung, lihat `localityLbPolicy` di dokumentasi API layanan backend regional.
Afinitas sesi (`consistentHash`)	Mencakup afinitas berbasis cookie HTTP, afinitas berbasis header HTTP, afinitas alamat IP klien, afinitas sesi berbasis cookie stateful, dan afinitas cookie yang dihasilkan. Afinitas sesi memberikan upaya terbaik untuk mengirim permintaan dari klien tertentu ke backend yang sama selama backend tersebut responsif dan memiliki kapasitas. Untuk informasi selengkapnya tentang afinitas sesi, lihat `consistentHash` di dokumentasi API layanan backend regional.
Deteksi outlier (`outlierDetection`)	Kumpulan kebijakan yang menentukan kriteria untuk pengosongan VM atau endpoint backend yang tidak responsif di NEG, beserta kriteria yang menentukan kapan backend atau endpoint dianggap cukup responsif untuk menerima traffic lagi. Untuk informasi selengkapnya tentang deteksi outlier, lihat `outlierDetection` di dokumentasi API layanan backend regional.
Pemutusan sirkuit (`circuitBreakers`)	Menetapkan batas atas volume koneksi dan permintaan per koneksi ke layanan backend. Untuk informasi selengkapnya tentang pemutusan sirkuit, lihat `circuitBreakers` di dokumentasi API layanan backend regional.

Langkah selanjutnya

Untuk mengonfigurasi pengelolaan traffic untuk Load Balancer Aplikasi internal, lihat Menyiapkan pengelolaan traffic untuk Load Balancer Aplikasi internal.