Ringkasan grup endpoint jaringan tanpa server

Grup endpoint jaringan (NEG) menentukan grup endpoint backend untuk load balancer. NEG serverless adalah backend yang mengarah ke resource Cloud Run, App Engine, fungsi Cloud Run, atau API Gateway.

NEG tanpa server dapat merepresentasikan salah satu hal berikut:

  • Resource Cloud Run atau sekelompok resource.
  • Fungsi Cloud Run atau grup fungsi (sebelumnya Cloud Run functions generasi ke-2).
  • Cloud Run function (generasi ke-1) atau grup fungsi
  • Aplikasi lingkungan standar App Engine atau lingkungan fleksibel App Engine, layanan tertentu dalam aplikasi, versi tertentu dari aplikasi, atau grup layanan.
  • API Gateway yang menyediakan akses ke layanan Anda melalui REST API yang konsisten di semua layanan, terlepas dari implementasi layanan. Kemampuan ini berada dalam Pratinjau.

Load balancer yang didukung

Tabel berikut mencantumkan produk serverless yang didukung oleh setiap Load Balancer Aplikasi. NEG serverless tidak didukung oleh Load Balancer Jaringan proxy dan Load Balancer Jaringan passthrough.

Jenis NEG serverless Load Balancer Aplikasi
Regional
internal		 Lintas region
internal		 Global
eksternal		 Klasik Regional
eksternal

Cloud Run

Mendukung Cloud Run dan fungsi Cloud Run (generasi ke-2)
App Engine

Cloud Functions

Mendukung fungsi Cloud Run (generasi ke-1), yang sebelumnya dikenal sebagai Cloud Functions generasi ke-1

Kasus penggunaan

Saat load balancer diaktifkan untuk aplikasi serverless, Anda dapat melakukan hal berikut:

  • Konfigurasi aplikasi serverless untuk menyalurkan dari alamat IP IPv4 khusus yang tidak digunakan bersama dengan layanan lain.
  • Petakan satu URL ke beberapa fungsi atau layanan tanpa server yang ditayangkan di domain yang sama. Dalam dokumen ini, lihat Masker URL.
  • Bagikan ruang URL dengan platform komputasi Google Cloud lainnya. Dengan menggunakan beberapa layanan backend, satu load balancer dapat mengirim traffic ke beberapa jenis backend. Load balancer memilih layanan backend yang benar berdasarkan host atau jalur URL permintaan.
  • Gunakan kembali sertifikat SSL dan kunci pribadi yang sama dengan yang Anda gunakan untuk Compute Engine, Google Kubernetes Engine, dan Cloud Storage. Dengan menggunakan kembali sertifikat yang sama, Anda tidak perlu mengelola sertifikat terpisah untuk aplikasi serverless.

Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik

Menyiapkan Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik memungkinkan aplikasi serverless Anda terintegrasi dengan layanan cloud yang ada. Anda dapat melakukan hal berikut:

  • Lindungi layanan Anda dengan Google Cloud Armor, produk keamanan WAF dan pertahanan DDoS di edge yang tersedia untuk semua layanan yang diakses melalui Load Balancer Aplikasi eksternal. Ada beberapa batasan yang terkait dengan kemampuan ini, terutama untuk Cloud Run dan App Engine.
  • Aktifkan layanan Anda untuk mengoptimalkan pengiriman menggunakan Cloud CDN. Cloud CDN menyimpan konten ke dalam cache di lokasi yang dekat dengan pengguna Anda. Cloud CDN menyediakan kemampuan seperti invalidasi cache dan URL bertanda tangan Cloud CDN.
  • Gunakan infrastruktur Edge Google untuk mengakhiri koneksi HTTP(S) pengguna di lokasi yang lebih dekat dengan pengguna, sehingga mengurangi latensi.

Untuk mempelajari cara mengonfigurasi load balancer dengan backend komputasi serverless, lihat dokumentasi berikut:

Mengintegrasikan Load Balancer Aplikasi eksternal dengan API Gateway memungkinkan backend serverless Anda memanfaatkan semua fitur yang disediakan oleh Cloud Load Balancing. Untuk mengetahui informasi selengkapnya, lihat Load Balancer Aplikasi Eksternal untuk API Gateway. Untuk mengonfigurasi Load Balancer Aplikasi eksternal untuk merutekan traffic ke API Gateway, lihat Mulai menggunakan Load Balancer Aplikasi eksternal untuk API Gateway. Kemampuan ini berada dalam Pratinjau.

Load Balancer Aplikasi eksternal regional

Dengan Load Balancer Aplikasi eksternal regional, Anda dapat menjalankan beban kerja dengan persyaratan peraturan atau kepatuhan di backend Cloud Run atau Cloud Run Functions (generasi ke-2). Misalnya, jika Anda mewajibkan konfigurasi jaringan dan penghentian traffic aplikasi Anda berada di region tertentu, Application Load Balancer eksternal regional sering kali menjadi opsi yang lebih disukai untuk mematuhi kontrol yurisdiksi yang diperlukan.

Untuk mempelajari cara mengonfigurasi Load Balancer Aplikasi eksternal regional dengan backend komputasi serverless, lihat Menyiapkan Load Balancer Aplikasi eksternal regional dengan Cloud Run.

Load Balancer Aplikasi internal regional dan Load Balancer Aplikasi internal lintas region

Jika backend Cloud Run atau Cloud Run Functions (generasi ke-2) dikonfigurasi dengan Load Balancer Aplikasi internal, Anda dapat melakukan hal berikut:

  • Aktifkan fitur pengelolaan traffic lanjutan seperti penyisipan kesalahan, penulisan ulang header, pengalihan, pemisahan traffic, dan lainnya, untuk layanan Cloud Run dan Cloud Run functions (generasi ke-2) Anda.
  • Migrasikan layanan lama dengan lancar dari Compute Engine, GKE, atau infrastruktur lokal ke Cloud Run dan fungsi Cloud Run (generasi ke-2) untuk memanfaatkan pembagian traffic berbasis bobot guna mengalihkan traffic secara bertahap ke Cloud Run tanpa waktu non-operasional.
  • Lindungi layanan Cloud Run dan fungsi Cloud Run (generasi ke-2) Anda dengan VPC Service Controls.
  • Tetapkan satu titik ingress internal yang menerapkan kebijakan untuk layanan Anda yang berjalan di Cloud Run, Cloud Run Functions (generasi ke-2), Compute Engine, dan GKE.

Untuk mempelajari cara mengonfigurasi Load Balancer Aplikasi internal regional dengan backend komputasi serverless, lihat Menyiapkan Load Balancer Aplikasi internal regional dengan Cloud Run.

Bagian selanjutnya di halaman ini membahas cara menggunakan NEG serverless dengan Load Balancer Aplikasi Anda. Untuk mengetahui informasi selengkapnya tentang jenis NEG lainnya, lihat Ringkasan grup endpoint jaringan.

Jenis endpoint

NEG tanpa server tidak memiliki endpoint jaringan seperti port atau alamat IP. NEG ini hanya dapat mengarah ke resource Cloud Run, App Engine, API Gateway, atau Cloud Run Functions yang ada di region yang sama dengan NEG.

Saat membuat NEG serverless, Anda menentukan nama domain yang sepenuhnya memenuhi syarat (FQDN) resource fungsi Cloud Run, App Engine, API Gateway, atau Cloud Run. Endpoint berjenis SERVERLESS. Jenis endpoint lainnya tidak didukung di NEG tanpa server.

NEG tanpa server tidak dapat memiliki lebih dari satu endpoint. Endpoint mengarah ke aplikasi tanpa server atau masker URL. Load balancer berfungsi sebagai frontend untuk aplikasi komputasi serverless dan memproksi traffic ke endpoint yang ditentukan. Namun, jika layanan backend berisi beberapa NEG serverless di region yang berbeda, load balancer akan mengirimkan traffic ke NEG di region terdekat untuk meminimalkan latensi permintaan.

Tingkat jaringan

Untuk Load Balancer Aplikasi eksternal global, Anda dapat menggunakan NEG serverless di load balancer menggunakan Tingkatan Layanan Jaringan Standar atau Premium. Tingkat Premium hanya diperlukan jika Anda ingin menyiapkan NEG serverless di beberapa region.

Load Balancer Aplikasi eksternal regional selalu menggunakan Paket Standar.

Load Balancer Aplikasi internal lintas region dan Load Balancer Aplikasi internal regional selalu memiliki tingkat Premium.

Komponen load balancing

Load balancer yang menggunakan backend NEG tanpa server memerlukan konfigurasi khusus hanya untuk layanan backend. Konfigurasi frontend sama dengan load balancer berbasis proxy lainnya. Google Cloud Selain itu, Load Balancer Aplikasi internal memerlukan subnet khusus proxy untuk menjalankan proxy Envoy atas nama Anda.

Diagram berikut menunjukkan contoh deployment NEG tanpa server.

Eksternal global

Diagram ini menunjukkan cara NEG serverless cocok dengan arsitektur Load Balancer Aplikasi eksternal global.

Load Balancer Aplikasi eksternal global untuk aplikasi serverless.
Load Balancer Aplikasi eksternal global untuk aplikasi serverless (klik untuk memperbesar).

Eksternal regional

Diagram ini menunjukkan cara NEG serverless cocok dengan arsitektur Load Balancer Aplikasi eksternal regional.

Load Balancer Aplikasi eksternal regional untuk aplikasi serverless.
Load Balancer Aplikasi eksternal regional untuk aplikasi serverless (klik untuk memperbesar).

Internal regional

Diagram ini menunjukkan cara NEG serverless sesuai dengan model Load Balancer Aplikasi internal regional.

Load Balancer Aplikasi internal regional untuk aplikasi serverless.
Load Balancer Aplikasi internal regional untuk aplikasi serverless (klik untuk memperbesar).

Lintas region

Diagram ini menunjukkan cara NEG serverless sesuai dengan model Load Balancer Aplikasi internal lintas region.

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

Komponen frontend

Tidak diperlukan konfigurasi frontend khusus untuk load balancing dengan backend NEG tanpa server. Aturan penerusan digunakan untuk merutekan traffic menurut alamat IP, port, dan protokol ke proxy target. Proxy target kemudian menghentikan koneksi dari klien.

Peta URL digunakan oleh Load Balancer Aplikasi untuk menyiapkan perutean permintaan berbasis URL ke layanan backend yang sesuai.

Untuk mengetahui detail selengkapnya tentang setiap komponen ini, lihat bagian arsitektur di ringkasan load balancer tertentu:

Layanan backend

Layanan backend memberikan informasi konfigurasi ke load balancer. Load balancer menggunakan informasi di layanan backend untuk mengarahkan traffic masuk ke satu atau beberapa backend yang terpasang. NEG serverless dapat digunakan sebagai backend untuk load balancer tertentu.

Batasan berikut berlaku bergantung pada jenis load balancer:

  • Layanan backend global yang digunakan oleh Load Balancer Aplikasi eksternal global dapat memiliki beberapa NEG serverless yang terpasang, tetapi hanya satu NEG serverless per region.
  • Layanan backend regional yang digunakan oleh Load Balancer Aplikasi internal regional dan Load Balancer Aplikasi eksternal regional hanya dapat memiliki satu NEG serverless yang terpasang padanya.
  • Layanan backend global yang digunakan oleh Load Balancer Aplikasi internal lintas region hanya dapat memiliki resource Cloud Run dan Cloud Run Functions (generasi ke-2) yang terpasang padanya.

Setiap NEG serverless dapat mengarah ke salah satu hal berikut:

  • FQDN untuk satu resource
  • Masker URL yang mengarah ke beberapa resource yang ditayangkan di domain yang sama

Masker URL adalah template skema URL yang memberi tahu backend NEG tanpa server cara memetakan permintaan pengguna ke layanan yang benar. Masker URL berguna jika Anda menggunakan domain kustom untuk aplikasi serverless dan memiliki beberapa layanan yang ditayangkan di domain yang sama. Daripada membuat NEG serverless terpisah untuk setiap resource, Anda dapat membuat NEG dengan mask URL generik untuk domain kustom. Untuk mengetahui informasi dan contoh selengkapnya, lihat Mask URL.

Untuk batasan tambahan saat menambahkan NEG serverless sebagai backend, lihat Batasan.

Deteksi outlier untuk NEG serverless

Deteksi pencilan adalah konfigurasi opsional yang dapat diaktifkan pada layanan backend global yang memiliki NEG tanpa server yang terpasang padanya. Analisis deteksi pencilan hanya tersedia untuk Load Balancer Aplikasi internal lintas-region, Load Balancer Aplikasi eksternal global, dan tidak tersedia untuk Load Balancer Aplikasi klasik. Analisis deteksi pencilan mengidentifikasi NEG serverless yang tidak responsif berdasarkan pola respons HTTP-nya, dan mengurangi tingkat error dengan merutekan sebagian besar permintaan baru dari resource yang tidak responsif ke resource yang responsif. Untuk mempelajari cara kerja algoritma deteksi pencilan dan memahami batasannya, lihat contoh berikut.

Asumsikan ada layanan backend dengan dua NEG tanpa server yang terpasang padanya—satu di region REGION_A dan satu lagi di region REGION_B. Jika NEG serverless yang berfungsi sebagai backend untuk Load Balancer Aplikasi eksternal global di region REGION_A tidak responsif, deteksi pencilan akan mengidentifikasi NEG serverless sebagai tidak sehat. Berdasarkan analisis deteksi pencilan, beberapa permintaan baru kemudian dikirim ke NEG tanpa server di region REGION_B.

Berdasarkan jenis error server yang terjadi, Anda dapat menggunakan salah satu metode deteksi pencilan berikut untuk mengaktifkan deteksi pencilan:

  • Error 5xx berturut-turut. Kode status HTTP seri 5xx memenuhi syarat sebagai error.
  • Error gateway berturut-turut. Hanya kode status HTTP 502, 503, dan 504 yang memenuhi syarat sebagai error.

Perhatikan bahwa meskipun setelah mengaktifkan deteksi pencilan, Anda mungkin akan melihat beberapa permintaan dikirim ke resource yang tidak sehat dan dengan demikian menampilkan error 5XX kepada klien. Hal ini karena hasil algoritma deteksi outlier (penghentian endpoint dari kumpulan load balancing dan mengembalikannya ke kumpulan) dieksekusi secara independen oleh setiap instance proxy load balancer. Dalam kebanyakan kasus, lebih dari satu instance proxy menangani traffic yang diterima oleh layanan backend. Oleh karena itu, ada kemungkinan bahwa endpoint yang tidak responsif terdeteksi dan dikeluarkan hanya oleh beberapa proxy, dan saat hal ini terjadi, proxy lain dapat terus mengirim permintaan ke endpoint yang sama yang tidak responsif.

Untuk mengurangi rasio error lebih lanjut, Anda dapat mengonfigurasi parameter deteksi pencilan yang lebih agresif. Sebaiknya konfigurasikan nilai yang lebih tinggi untuk batas penolakan (outlierDetection.baseEjectionTime). Misalnya, pengujian kami menunjukkan bahwa menetapkan outlierDetection.baseEjectionTime ke 180 detik dengan QPS berkelanjutan yang lebih tinggi dari 100 menghasilkan rasio error yang diamati kurang dari 5%. Untuk mempelajari lebih lanjut API deteksi pencilan, lihat outlierDetection dalam dokumentasi API layanan backend global.

Kolom outlierDetection berikut tidak didukung saat layanan backend memiliki NEG tanpa server yang terpasang padanya:

  • outlierDetection.enforcingSuccessRate
  • outlierDetection.successRateMinimumHosts
  • outlierDetection.successRateRequestVolume
  • outlierDetection.successRateStdevFactor

Untuk mempelajari cara mengonfigurasi deteksi pencilan, lihat Menyiapkan Load Balancer Aplikasi eksternal global dengan backend serverless: Mengaktifkan deteksi pencilan.

Masker URL

Backend NEG serverless dapat mengarah ke satu resource Cloud Run (atau App Engine atau Cloud Run Functions jika berlaku), atau masker URL yang mengarah ke beberapa resource. Masker URL adalah template skema URL Anda. NEG serverless menggunakan template ini untuk memetakan permintaan ke resource yang sesuai.

Masker URL adalah fitur opsional yang mempermudah konfigurasi NEG tanpa server saat aplikasi tanpa server Anda terdiri dari beberapa resource Cloud Run, fungsi Cloud Run, atau App Engine. NEG serverless yang digunakan dengan Load Balancer Aplikasi internal hanya dapat menggunakan mask URL yang mengarah ke layanan Cloud Run atau Cloud Run Functions (generasi ke-2).

Masker URL berguna jika aplikasi serverless Anda dipetakan ke domain kustom, bukan alamat default yang disediakan Google Cloud . Dengan domain kustom seperti example.com, Anda dapat men-deploy beberapa resource ke subdomain atau jalur yang berbeda di domain yang sama. Dalam kasus tersebut, alih-alih membuat backend NEG tanpa server terpisah untuk setiap resource, Anda dapat membuat satu NEG tanpa server dengan masker URL generik untuk domain kustom (misalnya, example.com/<service>). NEG mengekstrak nama layanan dari URL permintaan.

Ilustrasi berikut menunjukkan Load Balancer Aplikasi eksternal dengan satu layanan backend dan NEG tanpa server yang menggunakan mask URL untuk memetakan permintaan pengguna ke layanan yang berbeda.

Mendistribusikan traffic ke aplikasi serverless.
Menggunakan masker URL untuk mendistribusikan traffic ke berbagai layanan (klik untuk memperbesar).

Masker URL berfungsi optimal saat resource aplikasi Anda menggunakan skema URL yang dapat diprediksi. Keuntungan menggunakan masker URL, bukan peta URL, adalah Anda tidak perlu membuat NEG tanpa server terpisah untuk layanan login dan search. Anda juga tidak perlu mengubah konfigurasi load balancer setiap kali menambahkan resource baru ke aplikasi.

Batasan

  • NEG tanpa server tidak dapat memiliki endpoint jaringan seperti alamat IP atau port.
  • NEG tanpa server hanya dapat mengarah ke resource tanpa server yang berada di region yang sama dengan tempat NEG dibuat.
  • Untuk load balancer yang menggunakan backend NEG Serverless, NEG serverless harus dibuat di project yang sama dengan resource Cloud Run, App Engine, API Gateway, atau Cloud Run Functions yang ditunjuk oleh NEG. Anda mungkin melihat permintaan gagal jika menghubungkan layanan yang tidak berada dalam project yang sama dengan NEG tanpa server.
  • Load balancer yang dikonfigurasi dengan NEG tanpa server tidak dapat mendeteksi apakah resource tanpa server yang mendasarinya berfungsi seperti yang diharapkan. Artinya, meskipun resource Anda menampilkan error, load balancer akan terus mengarahkan traffic ke resource tersebut. Pastikan untuk menguji secara menyeluruh versi baru aset Anda sebelum merutekan traffic pengguna ke versi tersebut.

Batasan dengan layanan backend

Batasan berikut berlaku untuk layanan backend yang memiliki backend NEG tanpa server:

  • Layanan backend global yang digunakan oleh Load Balancer Aplikasi eksternal global hanya dapat memiliki satu NEG serverless per region. Untuk menggabungkan beberapa NEG serverless dalam satu layanan backend, semua NEG harus merepresentasikan deployment yang setara secara fungsional di region yang berbeda. Misalnya, NEG dapat mengarah ke resource fungsi Cloud Run, App Engine, atau Cloud Run yang sama yang di-deploy di region yang berbeda.
  • Layanan backend global yang digunakan oleh Load Balancer Aplikasi internal lintas region hanya dapat memiliki satu resource Cloud Run atau Cloud Run Functions (generasi ke-2) yang terpasang padanya.
  • Layanan backend regional hanya dapat memiliki satu NEG tanpa server yang terpasang padanya.
  • Referensi layanan lintas project dalam deployment VPC Bersama didukung dengan konfigurasi yang berisi NEG serverless. Untuk menggunakan fitur ini, Anda membuat komponen frontend load balancer (alamat IP, aturan penerusan, proxy target, dan peta URL) dalam project yang berbeda dengan komponen backend load balancer (layanan backend dan NEG tanpa server). Perhatikan bahwa layanan backend, NEG serverless terkait, dan resource serverless pendukung (Cloud Run, App Engine, API Gateway, atau fungsi Cloud Run), harus selalu dibuat dalam project yang sama.
  • Setelan waktu tunggu layanan backend tidak berlaku untuk layanan backend dengan backend NEG tanpa server. Mencoba mengubah properti resource.timeoutSec layanan backend akan menghasilkan error berikut: Timeout sec is not supported for a backend service with Serverless network endpoint groups.
    Untuk layanan backend dengan backend NEG tanpa server, waktu tunggu default adalah 60 menit. Waktu tunggu ini tidak dapat dikonfigurasi. Jika aplikasi Anda memerlukan koneksi yang berjalan lama, konfigurasikan klien Anda untuk mencoba ulang permintaan jika gagal.
  • Semua NEG serverless yang digabungkan dalam layanan backend juga harus menggunakan jenis backend yang sama. Artinya, NEG serverless Cloud Run hanya dapat digabungkan dengan NEG serverless Cloud Run lainnya, dan NEG serverless App Engine hanya dapat digabungkan dengan NEG serverless App Engine.
  • Anda tidak dapat menggabungkan NEG tanpa server dengan jenis NEG lainnya dalam layanan backend yang sama. Misalnya, Anda tidak dapat merutekan ke cluster GKE dan layanan Cloud Run dari layanan backend yang sama.
  • Saat menyiapkan layanan backend yang merutekan ke NEG tanpa server, kolom tertentu dibatasi:
    • Anda tidak dapat menentukan mode penyeimbangan. Artinya, nilai RATE,UTILIZATION, dan CONNECTION tidak berpengaruh pada distribusi traffic load balancer.
    • Health check tidak didukung untuk backend serverless. Oleh karena itu, layanan backend yang berisi backend NEG tanpa server tidak dapat dikonfigurasi dengan health check. Namun, Anda dapat mengaktifkan deteksi anomali secara opsional untuk mengidentifikasi resource serverless yang tidak berfungsi dan merutekan permintaan baru ke resource serverless yang berfungsi.
  • Anda tidak dapat menggunakan perintah gcloud compute backend-services edit untuk mengubah layanan backend dengan backend NEG tanpa server. Sebagai solusi, gunakan perintah gcloud compute backend-services update sebagai gantinya.

Batasan tambahan berlaku bergantung pada jenis load balancer dan backend serverless.

Batasan pada Load Balancer Aplikasi internal regional dan Load Balancer Aplikasi eksternal regional

  • NEG serverless yang digunakan dengan Load Balancer Aplikasi internal regional atau Load Balancer Aplikasi eksternal regional hanya dapat mengarah ke resource Cloud Run atau Cloud Run Functions (generasi ke-2).
  • Untuk project yang menggunakan NEG serverless, batas kueri per detik (QPS) adalah 5.000 QPS per project untuk traffic yang dikirim ke NEG serverless mana pun yang dikonfigurasi dengan Load Balancer Aplikasi eksternal regional atau Load Balancer Aplikasi internal regional. Batas ini digabungkan di semua Load Balancer Aplikasi eksternal regional dan Load Balancer Aplikasi internal regional dalam project. Ini bukan batas per load balancer.

Batasan dengan Load Balancer Aplikasi internal lintas region

  • NEG serverless yang digunakan dengan Load Balancer Aplikasi internal lintas region hanya dapat mengarah ke resource Cloud Run atau Cloud Run Functions (generasi ke-2).

Batasan pada Load Balancer Aplikasi eksternal global

Bagian ini mencantumkan batasan yang akan Anda temui saat mengonfigurasi NEG serverless dengan Load Balancer Aplikasi eksternal global.

Batasan dengan Cloud Run

Batasan App Engine

  • Load balancing multi-region tidak didukung dengan App Engine. Hal ini karena App Engine memerlukan 1 region per project.
  • Jika menggunakan IAP, Anda harus menggunakan ID klien OAuth yang sama untuk semua layanan App Engine yang terkait dengan satu load balancer.
  • Hanya satu kebijakan IAP yang diizinkan di jalur permintaan. Misalnya, jika Anda telah menetapkan kebijakan IAP di layanan backend, Anda tidak boleh menetapkan kebijakan IAP lain di aplikasi App Engine.
  • Load Balancer Aplikasi eksternal global dengan backend lingkungan fleksibel App Engine dan backend lingkungan standar App Engine tidak mendukung referensi layanan lintas project.
  • Sebaiknya gunakan kontrol masuk sehingga aplikasi Anda hanya menerima permintaan yang dikirim dari load balancer (dan VPC jika Anda menggunakannya). Jika tidak, pengguna dapat menggunakan URL App Engine aplikasi Anda untuk mengabaikan load balancer, kebijakan keamanan Cloud Armor, sertifikat SSL, dan kunci pribadi yang diteruskan melalui load balancer.

Batasan dengan API Gateway

Untuk mengetahui informasi selengkapnya, lihat Batasan pada NEG serverless dan API Gateway.

Batasan fitur pengelolaan traffic

  • Fitur pengelolaan traffic lanjutan seperti kebijakan lokalitas load balancing dan afinitas sesi tidak didukung dengan backend NEG serverless.
  • Menentukan afinitas sesi pada layanan backend dengan backend NEG tanpa server tidak akan berfungsi. Sebagai solusi untuk Cloud Run, gunakan fitur afinitas sesi spesifiknya.

Harga

Untuk melihat informasi harga load balancer dengan NEG serverless, lihat Semua harga jaringan: Cloud Load Balancing.

Langkah berikutnya