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 yang memungkinkan Anda menggunakan fitur berikut:

• Pengarahan lalu lintas. 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. Menyempurnakan 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:

• Ringkasan peta URL
• Menggunakan peta URL
• Memahami layanan backend

Catatan: Untuk Load Balancer Aplikasi internal lintas region, Anda harus menggunakan API peta URL global dan layanan backend global.

Anda dapat menggunakan contoh yang disediakan dalam dokumen ini dengan mengganti regions/REGION/backendServices dengan global/backendServices.

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 mengirim traffic yang tidak memiliki user-agent:Mobile ke instance yang ditetapkan untuk menangani traffic dari perangkat lain.

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

Tindakan traffic: pemisahan traffic berbasis bobot

Men-deploy versi baru dari layanan produksi yang sudah ada umumnya akan menimbulkan beberapa risiko. Meskipun pengujian Anda lulus staging, Anda mungkin tidak ingin langsung menerapkan versi baru pada 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 baru layanan. Setelah memvalidasi bahwa versi produksi baru berfungsi seperti yang diharapkan, Anda dapat mengubah persentase secara bertahap hingga 100% traffic mencapai versi baru layanan Anda. Pembagian traffic biasanya digunakan untuk men-deploy versi baru, pengujian A/B, migrasi layanan, dan proses serupa.

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

Kebijakan traffic: pencerminan permintaan

Organisasi Anda mungkin memiliki persyaratan kepatuhan tertentu yang mewajibkan semua traffic dicerminkan ke layanan tambahan yang dapat, misalnya, merekam detail permintaan di database untuk diputar ulang di lain waktu.

Ekstensibilitas dengan Ekstensi Layanan

Info Ekstensi Layanan memungkinkan Anda memasukkan logika kustom ke jalur data load balancing. Dengan ekstensi ini, Anda dapat menginstruksikan Load Balancer Aplikasi yang didukung untuk melakukan panggilan gRPC ke aplikasi atau layanan yang dikelola pengguna selama pemrosesan data.

Untuk mengetahui informasi selengkapnya, lihat Ringkasan Ekstensi Layanan.

Komponen pengelolaan traffic

Pada tingkat tinggi, load balancer menyediakan pengelolaan traffic dengan memanfaatkan resource peta URL regional dan resource 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 lalu lintas 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 mencakup:

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

Diagram berikut menunjukkan resource yang digunakan untuk menerapkan setiap fitur.

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 dengan menggunakan pendekatan dua tahap:

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

Saat mengonfigurasi pemilihan rute, Anda dapat memilih antara mode berikut:

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

Kedua mode ini saling eksklusif. Setiap peta URL hanya dapat berisi satu mode atau mode lainnya.

Aturan host dan jalur sederhana

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

Diagram berikut menunjukkan alur logis aturan host dan jalur yang sederhana.

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

Pada awalnya, permintaan akan 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 akan dievaluasi. Aturan jalur dievaluasi berdasarkan kecocokan jalur terpanjang, dan Anda dapat menentukan aturan jalur dalam urutan apa pun. Setelah kecocokan paling spesifik ditemukan, permintaan akan dirutekan ke layanan backend yang sesuai. Jika permintaan tidak cocok, layanan backend default akan digunakan.

Aturan host dan jalur yang sederhana mungkin terlihat seperti berikut, saat traffic video mengarah ke video-backend-service, dan semua traffic lainnya mengarah 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 yang sederhana. Opsi ini mengaktifkan 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 terpanjang-jalur-cocok-pertama).

Seperti pada contoh aturan host dan jalur sederhana sebelumnya, Anda dapat mengonfigurasi pengelolaan traffic lanjutan menggunakan peta URL. Misalnya, peta URL berikut mengonfigurasi pemilihan rute 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 Anda, kolom host permintaan dievaluasi berdasarkan 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 dalam 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-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[] dalam dokumentasi API peta URL regional.

Aturan jalur

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

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

Aturan rute

Aturan rute (routeRules) mencocokkan informasi dalam permintaan masuk dan membuat keputusan perutean 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 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 khusus.

Catatan: Opsi pencocokan dan semantik berbeda-beda bergantung pada bagian permintaan yang Anda cocokkan. Untuk informasi selengkapnya, lihat matchRules[] dalam 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, perutean, dan tindakan lainnya.

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

Google Cloud akan melakukan tindakan berikut:

1. Mencari aturan kecocokan pertama yang cocok dengan permintaan.
2. Berhenti melihat aturan pencocokan lainnya.
3. 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 sampai 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 berkurang saat jumlahnya meningkat, sehingga aturan dengan prioritas 4 dievaluasi sebelum aturan dengan prioritas 25. Aturan pertama yang sesuai dengan permintaan akan diterapkan. Ada beberapa angka prioritas di nomor prioritas. 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 resource layanan backend tempat traffic diarahkan jika aturan ini cocok.
Aturan pencocokan (matchRules)	Satu atau beberapa aturan yang dievaluasi terhadap permintaan. matchRules ini dapat cocok dengan semua atau sebagian 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 diambil jika kriteria aturan pencocokan terpenuhi. Tindakan ini mencakup pemisahan traffic, penulisan ulang URL, percobaan ulang dan pencerminan, injeksi fault, dan kebijakan CORS.
Tindakan pengalihan (urlRedirect)	Anda dapat mengonfigurasi tindakan agar merespons dengan pengalihan HTTP jika kriteria aturan kecocokan terpenuhi. Kolom ini tidak dapat digunakan bersama tindakan rute.
Tindakan header (headerAction)	Anda dapat mengonfigurasi aturan transformasi header respons dan permintaan jika kriteria dalam matchRules terpenuhi.

Untuk mengetahui 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) cocok dengan satu atau beberapa atribut permintaan dan mengambil tindakan yang ditentukan dalam aturan rute. Daftar berikut menyediakan 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 sebagai alamat IP yang di-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 di awal jalur yang harus dicocokkan.

• 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[] di dokumentasi API peta URL regional.

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. Kode 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.
Pencerminan traffic (requestMirrorPolicy)	Selain meneruskan permintaan ke layanan backend yang dipilih, juga mengirimkan permintaan yang identik ke layanan backend duplikasi yang dikonfigurasi secara aktifkan dan lupakan. Load balancer tidak menunggu respons dari backend yang akan dikirimi permintaan yang dicerminkan. Pencerminan berguna untuk menguji versi baru layanan backend. Anda juga dapat menggunakannya untuk men-debug error produksi pada layanan backend versi debug, bukan pada versi produksi.
Pemisahan traffic berbobot (weightedBackendServices)	Memungkinkan traffic untuk aturan yang cocok didistribusikan ke beberapa layanan backend, sebanding dengan bobot yang ditetapkan pengguna yang ditetapkan untuk masing-masing 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 stabil dari sebuah aplikasi, sementara 1% traffic dikirim ke layanan terpisah yang menjalankan versi lebih baru dari aplikasi tersebut.
Percobaan ulang (retryPolicy)	Mengonfigurasi kondisi saat load balancer mencoba ulang permintaan yang gagal, lama waktu 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 sejak permintaan diproses sepenuhnya hingga respons diproses sepenuhnya. Waktu tunggu mencakup semua percobaan ulang.
Injeksi kesalahan (faultInjectionPolicy)	Memberikan error saat melayani permintaan untuk menyimulasikan kegagalan, termasuk latensi tinggi, overload layanan, kegagalan layanan, dan partisi jaringan. Fitur ini berguna untuk menguji ketahanan layanan terhadap kesalahan yang disimulasikan.
Tunda injeksi (faultInjectionPolicy)	Memperkenalkan penundaan untuk bagian permintaan yang ditentukan pengguna sebelum mengirim permintaan ke layanan backend yang dipilih.
Batalkan injeksi (faultInjectionPolicy)	Merespons langsung sebagian kecil permintaan dengan kode status HTTP yang ditetapkan 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:

• Rutekan traffic ke satu layanan (service).
• Memisahkan 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).
• Coba lagi permintaan yang gagal (retryPolicy).
• Setel waktu tunggu (timeout).
• Membuat kesalahan pada 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 yang sama.

Agar dua aturan penerusan dapat menggunakan alamat IP internal yang sama, Anda harus mencadangkan alamat IP dan menyertakan flag --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 resource layanan backend, Anda dapat mengonfigurasi kebijakan traffic untuk menyesuaikan 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).

Dengan kebijakan traffic, Anda dapat:

• 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 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 pembobotan/fraksi traffic yang harus dikirim ke setiap backend (grup instance atau NEG GCE_VM_IP_PORT). Kebijakan load balancing (LocalityLbPolicy) menentukan cara backend di dalam zona atau dalam grup melakukan load balancing. Saat menerima traffic, layanan backend akan mengarahkan traffic ke backend (grup instance atau GCE_VM_IP_PORT NEG) terlebih dahulu sesuai dengan mode penyeimbangan backend. Setelah backend dipilih, traffic kemudian didistribusikan di antara instance atau endpoint di setiap zona sesuai dengan kebijakan lokalitas. Untuk grup instance terkelola regional, kebijakan lokalitas berlaku untuk setiap zona konstituen. Untuk mode balancing yang didukung, lihat Mode balancing. 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, dan afinitas cookie yang dihasilkan. Afinitas sesi memberikan upaya terbaik untuk mengirim permintaan dari klien tertentu ke backend yang sama selama bagian belakangnya responsif dan memiliki kapasitas. Untuk mengetahui informasi selengkapnya tentang afinitas sesi, lihat consistentHash di dokumentasi API layanan backend regional.
Deteksi pencilan (outlierDetection)	Serangkaian kebijakan yang menentukan kriteria untuk mengeluarkan VM backend atau endpoint 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 dalam dokumentasi API layanan backend regional.
Pemutusan sirkuit (circuitBreakers)	Menetapkan batas atas volume koneksi dan permintaan per koneksi ke layanan backend. Untuk informasi selengkapnya tentang pemecahan sirkuit, lihat circuitBreakers di dokumentasi API layanan backend regional.

Langkah selanjutnya

• Guna mengonfigurasi pengelolaan traffic untuk Load Balancer Aplikasi internal, baca artikel Menyiapkan pengelolaan traffic untuk Load Balancer Aplikasi internal.