Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global

Halaman ini memberi Anda ringkasan kemampuan pengelolaan traffic lanjutan yang tersedia untuk Load Balancer Aplikasi eksternal global. Halaman ini hanya untuk Load Balancer Aplikasi eksternal global. Load balancer ini selalu bersifat global dan selalu menggunakan Paket Premium. Jika Anda menggunakan load balancer dalam mode yang berbeda, lihat salah satu halaman berikut:

Load Balancer Aplikasi eksternal global mendukung fitur pengelolaan traffic lanjutan berikut:
  • Pengarahan traffic. Mengarahkan traffic secara cerdas berdasarkan parameter HTTP(S) (misalnya, host, jalur, header, dan parameter permintaan lainnya).
  • Tindakan traffic. Melakukan tindakan berbasis permintaan dan berbasis 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, pengarahan traffic dapat mengirimkan traffic tersebut ke instance layanan yang ditetapkan untuk menangani traffic seluler, dan mengirimkan traffic yang tidak memiliki user-agent:Mobile ke instance yang ditetapkan untuk menangani traffic dari perangkat lain.

Pengarahan traffic Cloud Load Balancing.
Gambar 1. Pengarahan traffic Cloud Load Balancing (klik untuk memperbesar).

Tindakan traffic: pemisahan traffic berbasis bobot

Men-deploy versi baru layanan produksi yang ada umumnya menimbulkan risiko tertentu. Meskipun pengujian Anda berhasil di staging, Anda mungkin tidak ingin langsung menerapkan versi baru kepada 100% pengguna. 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 mengalihkan persentase secara bertahap 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. Pembagian traffic Cloud Load Balancing (klik untuk memperbesar).
Jangan mengonfigurasi afinitas sesi jika Anda menggunakan pemisahan traffic berbobot. Jika Anda melakukannya, konfigurasi pemisahan traffic berbobot akan lebih diutamakan.

Kebijakan traffic: duplikasi permintaan

Organisasi Anda mungkin memiliki persyaratan kepatuhan khusus yang mewajibkan semua traffic di-mirror ke layanan tambahan yang dapat, misalnya, mencatat detail permintaan dalam database untuk pemutaran 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 mengetahui informasi selengkapnya, lihat Ringkasan Ekstensi Layanan.

Komponen pengelolaan traffic

Secara umum, load balancer menyediakan pengelolaan traffic dengan memanfaatkan resource peta URL global dan layanan backend global.

Anda dapat menyiapkan pengarahan traffic dan tindakan traffic menggunakan peta URL. ResourceGoogle Cloud yang terkait dengan peta URL mencakup berikut ini:

  • Aturan rute
  • Pencocokan aturan
  • Tindakan aturan

Anda dapat menyiapkan kebijakan traffic menggunakan resource Google Cloud layanan backend yang terkait dengan layanan backend mencakup berikut ini:

  • 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 eksternal global, backend untuk traffic Anda ditentukan dengan menggunakan pendekatan dua fase:

  • Load balancer memilih layanan backend atau bucket backend berdasarkan aturan yang ditentukan dalam peta URL global.
  • Layanan backend memilih instance backend berdasarkan kebijakan yang ditentukan dalam layanan backend global.

Saat mengonfigurasi perutean, Anda dapat memilih antara mode berikut:

  • Aturan host dan jalur sederhana
  • Aturan host, jalur, dan rute lanjutan

Kedua mode ini 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 kecocokan jalur terpanjang 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 yang umum mungkin terlihat seperti berikut, dengan traffic video menuju video-backend-service, dan semua traffic lainnya menuju web-backend-service. defaultService dan service dapat mengarah ke layanan backend atau bucket backend. Contoh ini menunjukkan layanan backend.

gcloud compute url-maps describe lb-map
defaultService: global/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: lb-map
pathMatchers:
- defaultService: global/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: global/backendServices/video-backend-service

Aturan host, jalur, dan 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 kecocokan jalur terpanjang terlebih dahulu).

Seperti dalam contoh aturan host dan jalur sederhana sebelumnya, Anda dapat mengonfigurasi pengelolaan 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.

defaultService dan service dapat mengarah ke layanan backend atau bucket backend. Contoh ini menunjukkan layanan backend.

gcloud compute url-maps describe lb-map
defaultService: global/backendServices/service-a
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: lb-map
pathMatchers:
- defaultService: global/backendServices/service-a
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: ''
    routeAction:
      weightedBackendServices:
      - backendService: global/backendServices/service-a
        weight: 95
      - backendService: global/backendServices/service-b
        weight: 5

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 mengetahui informasi selengkapnya, lihat hostRules[] dan defaultService di dokumentasi API peta URL global.

Pencocok jalur

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

Pencocokan jalur terdiri dari hal-hal berikut:

  • Satu atau beberapa aturan jalur (pathRules) atau aturan rute (routeRules).
  • Layanan default (defaultService), yang merupakan layanan backend atau bucket backend default yang digunakan saat tidak ada layanan backend atau bucket backend lain yang cocok.
Untuk mengetahui informasi selengkapnya, lihat pathMatchers[], pathMatchers[].pathRules[], dan pathMatchers[].routeRules[] dalam dokumentasi API peta URL global.

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 mengetahui informasi selengkapnya, lihat pathRules[] dalam dokumentasi API peta URL global.

Aturan rute

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

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 peka huruf besar/kecil). Hal ini memungkinkan Anda, misalnya, mengirim permintaan HTTP(S) ke serangkaian backend berdasarkan keberadaan header HTTP yang ditentukan secara kustom.

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

Jika Anda memiliki beberapa aturan rute, load balancer akan mengeksekusinya dalam urutan prioritas (berdasarkan kolom priority), yang memungkinkan Anda menentukan logika kustom untuk pencocokan, perutean, 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:

  1. Mencari aturan pencocokan pertama yang cocok dengan permintaan.
  2. Berhenti mencari aturan kecocokan lainnya.
  3. Menerapkan tindakan di 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 menurun seiring bertambahnya nomornya sehingga aturan dengan prioritas 4 dievaluasi sebelum aturan dengan prioritas 25. Aturan pertama yang cocok dengan permintaan akan diterapkan.

Nomor prioritas dapat memiliki kesenjangan. Anda tidak dapat membuat lebih dari satu aturan dengan prioritas yang sama.
Deskripsi (description) Deskripsi opsional hingga 1.024 karakter.
Layanan (service) URL lengkap atau sebagian dari resource layanan backend yang menjadi tujuan pengalihan traffic jika aturan ini cocok.
Aturan pencocokan (matchRules) Satu atau beberapa aturan yang dievaluasi terhadap permintaan. matchRules ini dapat mencocokkan semua atau sebagian kecil atribut HTTP permintaan, seperti jalur, header HTTP, dan parameter kueri (GET).

Dalam matchRule, semua kriteria yang cocok harus dipenuhi agar routeActions routeRule dapat diterapkan. Jika routeRule memiliki beberapa matchRules, routeActions dari routeRule akan berlaku saat permintaan cocok dengan salah satu matchRules routeRule.
Tindakan rute (routeAction) Memungkinkan Anda menentukan tindakan yang akan dilakukan jika kriteria aturan pencocokan terpenuhi. Tindakan ini mencakup pembagian traffic, penulisan ulang URL, percobaan ulang dan pencerminan, injeksi kesalahan, dan kebijakan CORS.
Tindakan pengalihan (urlRedirect) Anda dapat mengonfigurasi tindakan untuk merespons dengan pengalihan HTTP saat kriteria aturan kecocokan 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 mengetahui informasi selengkapnya tentang kolom berikut, lihat dokumentasi API peta URL global.
  • 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 melakukan 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 yang di-load balance:

    curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
    
  • Jalur mengikuti nama host; misalnya /images. Aturan 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 global.

Tindakan rute

Tindakan rute adalah tindakan spesifik yang harus dilakukan 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. Untuk penulisan ulang bagian jalur, Anda dapat menggunakan karakter pengganti di pathTemplateRewrite.
Transformasi header (headerAction) Menambahkan atau menghapus header permintaan sebelum mengirim permintaan ke layanan backend. Anda juga dapat menambahkan atau menghapus header respons setelah menerima respons dari layanan backend. Mencoba menambahkan dan menghapus header yang sama akan menyebabkan header dihapus, kecuali jika tanda replace: True digunakan dengan operasi requestHeadersToAdd.
Duplikasi traffic (requestMirrorPolicy)

Selain meneruskan permintaan ke layanan backend yang dipilih, mengirimkan permintaan yang identik ke layanan backend mirror yang dikonfigurasi berdasarkan fire and forget. Load balancer tidak menunggu respons dari backend yang menerima permintaan yang diduplikasi.

Duplikasi 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 saat kedua layanan backend memiliki backend grup instance terkelola, NEG zona, atau NEG hybrid. Fitur ini tidak didukung untuk NEG internet, NEG serverless, dan backend Private Service Connect.
  • Permintaan ke layanan backend yang di-mirror 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 sehingga 99% traffic dikirim ke layanan yang menjalankan aplikasi versi stabil, sementara 1% traffic dikirim ke layanan terpisah yang menjalankan aplikasi versi lebih baru.
Percobaan ulang (retryPolicy)

Mengonfigurasi kondisi saat load balancer mencoba ulang permintaan yang gagal, durasi tunggu load balancer sebelum mencoba ulang, dan jumlah maksimum percobaan ulang yang diizinkan.

Perhatikan hal-hal berikut:
  • Kebijakan percobaan ulang tidak didukung dengan backend NEG internet.

  • Untuk menonaktifkan percobaan ulang, Anda harus menyetel numRetries ke 1 secara eksplisit.

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 kesalahan (faultInjectionPolicy) Memunculkan error saat memproses permintaan untuk menyimulasikan kegagalan, termasuk latensi tinggi, kelebihan beban layanan, kegagalan layanan, dan partisi jaringan. Fitur ini berguna untuk menguji ketahanan layanan terhadap kesalahan yang disimulasikan.
Penambahan penundaan (faultInjectionPolicy) Memperkenalkan penundaan untuk sebagian permintaan yang ditentukan pengguna sebelum mengirim permintaan ke layanan backend yang dipilih.
Batalkan injeksi (faultInjectionPolicy) Merespons sebagian kecil permintaan secara langsung 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 layanan tunggal (service).
  • Membagi traffic di antara beberapa layanan (weightedBackendServices weight:x, dengan x harus dari 0 hingga 1000).
  • URL pengalihan (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).
  • Menetapkan waktu tunggu (timeout).
  • Membuat kesalahan pada persentase traffic (faultInjectionPolicy).
  • Tambahkan kebijakan CORS (corsPolicy).
  • Memanipulasi header permintaan atau respons (headerAction).
Untuk mengetahui informasi selengkapnya tentang konfigurasi dan semantik tindakan rute, lihat bagian berikut dalam dokumentasi API peta URL global.
  • 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.

Untuk contoh lengkap, lihat Menyiapkan pengalihan HTTP-ke-HTTPS untuk Load Balancer Aplikasi eksternal global.

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 penghapusan host yang tidak responsif dari layanan backend.
Fitur kebijakan traffic berikut dikonfigurasi di layanan backend global.

Kebijakan traffic (API field name) Deskripsi
Kebijakan lokalitas load balancing (LocalityLbPolicy)

Untuk layanan backend atau bucket, distribusi traffic didasarkan pada mode load balancing dan kebijakan lokalitas load balancing.

Mode penyeimbangan menentukan fraksi traffic yang harus dikirim ke setiap backend (bucket, grup instance, atau NEG GCE_VM_IP_PORT). Kebijakan load balancing (LocalityLbPolicy) menentukan cara load balancing backend dalam zona atau dalam grup. Saat menerima traffic, layanan backend pertama-tama mengarahkan traffic ke backend (bucket, grup instance, atau NEG GCE_VM_IP_PORT) sesuai dengan mode load 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 konstituen.

Untuk mode penyeimbangan yang didukung, lihat Mode penyeimbangan.

Untuk algoritma kebijakan load balancing yang didukung, lihat localityLbPolicy di global dokumentasi API layanan backend.

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 berupaya sebaik mungkin untuk mengirim permintaan dari klien tertentu ke backend yang sama selama backend tersebut responsif dan memiliki kapasitas.

Setelan afinitas sesi hanya dipenuhi jika kebijakan lokalitas load balancing ditetapkan ke RING_HASH atau MAGLEV.

Untuk mengetahui informasi selengkapnya tentang afinitas sesi, lihat consistentHash di dokumentasi API layanan backend global.

Deteksi outlier (outlierDetection)

Serangkaian kebijakan yang menentukan kriteria untuk penghentian paksa 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 mengetahui informasi selengkapnya tentang deteksi pencilan, lihat outlierDetection di global dokumentasi API layanan backend.

Langkah berikutnya