Ringkasan grup endpoint jaringan serverless

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

NEG serverless dapat mewakili salah satu dari hal berikut:

  • Layanan Cloud Run atau grup layanan.
  • Fungsi Cloud Functions atau sekelompok fungsi.
  • Aplikasi App Engine (Standard atau Flex), layanan tertentu dalam aplikasi, versi aplikasi tertentu, atau grup layanan.
  • Gateway API yang menyediakan akses ke layanan Anda melalui REST API yang konsisten di semua layanan, apa pun implementasi layanannya. Kemampuan ini berada dalam Pratinjau.

Load balancer yang didukung

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

Platform serverless Load Balancer Aplikasi
Internal
regional		 Internal
lintas region		 Eksternal
global		 Klasik Eksternal
regional
Cloud Run
App Engine
Cloud Functions

Kasus penggunaan

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

  • Konfigurasikan aplikasi serverless Anda untuk melakukan inferensi dari alamat IP IPv4 khusus yang tidak dibagikan dengan layanan lain.
  • Memetakan satu URL ke beberapa fungsi atau layanan serverless yang ditayangkan di domain yang sama. Dalam dokumen ini, lihat Masker URL.
  • Berbagi 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 pertahanan DDoS edge, dan keamanan WAF 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 penayangan menggunakan Cloud CDN. Cloud CDN menyimpan konten yang dekat dengan pengguna Anda ke dalam cache. Cloud CDN menyediakan kemampuan seperti pembatalan cache dan URL bertanda tangan Cloud CDN.
  • Gunakan infrastruktur Edge Google untuk menghentikan koneksi HTTP(S) pengguna lebih dekat dengan pengguna, sehingga mengurangi latensi.

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

Dengan mengintegrasikan Load Balancer Aplikasi eksternal dengan Gateway API, backend serverless Anda dapat memanfaatkan semua fitur yang disediakan oleh Cloud Load Balancing. Untuk mengetahui informasi selengkapnya, lihat Load Balancer Aplikasi Eksternal untuk Gateway API. Untuk mengonfigurasi Load Balancer Aplikasi eksternal guna mengarahkan traffic ke Gateway API, lihat Memulai Load Balancer Aplikasi eksternal untuk Gateway API. Kemampuan ini berada dalam Pratinjau.

Load Balancer Aplikasi eksternal regional

Dengan menggunakan Load Balancer Aplikasi eksternal regional, Anda dapat menjalankan workload dengan persyaratan peraturan atau kepatuhan di backend Cloud Run. Misalnya, jika Anda mengharuskan konfigurasi jaringan dan penghentian traffic aplikasi Anda berada di region tertentu, Load Balancer Aplikasi eksternal regional sering kali menjadi opsi yang disarankan 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

Saat Load Balancer Aplikasi internal dikonfigurasi dengan backend Cloud Run, Anda dapat melakukan hal berikut:

  • Aktifkan fitur pengelolaan traffic lanjutan seperti injeksi fault, penulisan ulang header, pengalihan, pemisahan traffic, dan lainnya, untuk layanan Cloud Run Anda.
  • Migrasikan layanan lama dengan lancar dari Compute Engine, GKE, atau infrastruktur lokal ke Cloud Run dan manfaatkan pemisahan traffic berbasis bobot untuk mengalihkan traffic ke Cloud Run secara bertahap tanpa periode nonaktif.
  • Lindungi layanan Cloud Run Anda dengan Kontrol Layanan VPC.
  • Tetapkan titik masuk internal tunggal yang memberlakukan kebijakan untuk layanan Anda yang berjalan di Cloud Run, 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 dari 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 serverless tidak memiliki endpoint jaringan seperti port atau alamat IP. API tersebut hanya dapat mengarah ke layanan Cloud Run, App Engine, Gateway API, atau Cloud Functions yang berada di region yang sama dengan NEG.

Saat membuat NEG serverless, tentukan nama domain (FQDN) yang sepenuhnya memenuhi syarat dari layanan Cloud Run, App Engine, API Gateway, atau Cloud Functions. Endpoint adalah jenis SERVERLESS. Jenis endpoint lainnya tidak didukung di NEG serverless.

NEG serverless tidak boleh memiliki lebih dari satu endpoint. Endpoint mengarah ke aplikasi serverless atau URL mask. Load balancer berfungsi sebagai frontend untuk aplikasi komputasi serverless dan mem-proxy 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 Tingkat Layanan Jaringan Standar atau Premium. Paket Premium diperlukan hanya jika Anda ingin menyiapkan NEG serverless di beberapa region.

Load Balancer Aplikasi eksternal regional selalu berupa Tingkat Standar.

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

Komponen load balancing

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

Diagram berikut menunjukkan contoh deployment NEG serverless.

Eksternal global

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

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

Eksternal regional

Diagram ini menunjukkan kesesuaian NEG serverless 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 kesesuaian NEG serverless 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 kesesuaian NEG serverless 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 {i>frontend<i}

Tidak ada konfigurasi frontend khusus yang diperlukan untuk load balancing dengan backend NEG serverless. Aturan penerusan digunakan untuk mengarahkan 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 pemilihan rute permintaan berbasis URL ke layanan backend yang sesuai.

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

Layanan backend

Layanan backend memberikan informasi konfigurasi ke load balancer. Load balancing 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.

Pembatasan 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 padanya, 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 layanan Cloud Run yang terkait.

Setiap NEG serverless dapat mengarah ke salah satu hal berikut:

  • FQDN untuk fungsi atau layanan tunggal
  • Masker URL yang mengarah ke beberapa fungsi atau layanan yang ditayangkan di domain yang sama

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

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

Deteksi pencilan untuk NEG serverless

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

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

Berdasarkan jenis error server yang ditemukan, 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.

Perlu diperhatikan bahwa meskipun setelah mengaktifkan deteksi pencilan, Anda mungkin akan melihat beberapa permintaan yang dikirim ke layanan yang tidak responsif sehingga menampilkan error 5XX ke klien. Hal ini karena hasil algoritma deteksi pencilan (pengeluaran endpoint dari kumpulan load balancing dan mengembalikannya ke kumpulan load balancing) dijalankan secara independen oleh setiap instance proxy load balancer. Dalam kebanyakan kasus, lebih dari satu instance proxy menangani traffic yang diterima oleh layanan backend. Dengan demikian, mungkin endpoint yang tidak responsif hanya terdeteksi dan dikeluarkan oleh sebagian proxy. Selama hal ini terjadi, proxy lain dapat terus mengirim permintaan ke endpoint tidak responsif yang sama.

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

Kolom outlierDetection berikut tidak didukung saat layanan backend memiliki NEG serverless yang dilampirkan:

  • 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 layanan Cloud Run (atau App Engine atau Cloud Functions jika berlaku), atau URL mask yang mengarah ke beberapa layanan. Masker URL adalah template skema URL Anda. NEG serverless menggunakan template ini untuk memetakan permintaan ke layanan yang sesuai.

Masker URL adalah fitur opsional yang mempermudah konfigurasi NEG serverless jika aplikasi serverless Anda terdiri dari beberapa layanan Cloud Run, Cloud Functions, atau App Engine. NEG serverless yang digunakan dengan Load Balancer Aplikasi internal hanya dapat menggunakan mask URL yang mengarah ke layanan Cloud Run.

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 memiliki beberapa layanan yang di-deploy ke subdomain atau jalur yang berbeda di domain yang sama. Dalam kasus tersebut, daripada membuat backend NEG serverless terpisah untuk setiap layanan, Anda dapat membuat satu NEG serverless dengan mask URL generik untuk domain kustom (misalnya, example.com/<service>). NEG akan mengekstrak nama layanan dari URL permintaan.

Ilustrasi berikut menunjukkan Load Balancer Aplikasi eksternal dengan satu layanan backend dan NEG serverless, yang menggunakan URL mask untuk memetakan permintaan pengguna ke berbagai layanan.

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

Masker URL berfungsi paling baik saat layanan aplikasi Anda menggunakan skema URL yang dapat diprediksi. Keuntungan menggunakan mask URL dibandingkan peta URL adalah Anda tidak perlu membuat NEG serverless terpisah untuk layanan login dan search. Anda juga tidak perlu mengubah konfigurasi load balancer setiap kali menambahkan layanan baru ke aplikasi.

Batasan

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

Batasan dengan layanan backend

Batasan berikut berlaku untuk layanan backend yang memiliki backend NEG serverless:

  • 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 berbagai region. Misalnya, NEG dapat mengarah ke layanan Cloud Run, App Engine, atau Cloud Functions yang sama dengan yang di-deploy di region berbeda.
  • Layanan backend global yang digunakan oleh Load Balancer Aplikasi internal lintas region hanya dapat memiliki satu layanan Cloud Run yang terpasang.
  • Layanan backend regional hanya dapat memiliki satu NEG serverless yang terlampir.
  • Referensi layanan lintas-project di deployment VPC Bersama didukung dengan konfigurasi yang berisi NEG serverless. Untuk menggunakan fitur ini, buat 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 serverless). Perhatikan bahwa layanan backend, NEG serverless terkait, dan layanan serverless pendukung (Cloud Run, App Engine, Gateway API, atau Cloud Functions), harus selalu dibuat dalam project yang sama.
  • Setelan waktu tunggu layanan backend tidak berlaku untuk layanan backend dengan backend NEG serverless. 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 serverless, 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 lagi 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 lain, sedangkan NEG serverless App Engine hanya dapat digabungkan dengan NEG serverless App Engine.
  • Anda tidak dapat menggabungkan NEG serverless dengan jenis NEG lain pada 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 dirutekan ke NEG serverless, 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 serverless tidak dapat dikonfigurasi dengan health check. Namun, Anda dapat mengaktifkan deteksi pencilan secara opsional untuk mengidentifikasi layanan serverless yang tidak responsif dan merutekan permintaan baru ke layanan serverless yang responsif.
  • Anda tidak dapat menggunakan perintah gcloud compute backend-services edit untuk mengubah layanan backend dengan backend NEG serverless. Sebagai solusi, gunakan perintah gcloud compute backend-services update sebagai gantinya.

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

Batasan dengan 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 layanan Cloud Run.
  • Untuk project yang menggunakan NEG serverless, batas kueri per detik (QPS) adalah 5.000 QPS per project untuk traffic yang dikirim ke NEG serverless 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 terkait Load Balancer Aplikasi internal lintas region

  • NEG serverless yang digunakan dengan Load Balancer Aplikasi internal lintas region hanya dapat mengarah ke layanan Cloud Run.

Batasan dengan Load Balancer Aplikasi eksternal global

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

Batasan terkait App Engine

  • Load Balancer Aplikasi eksternal global dengan backend lingkungan fleksibel App Engine tidak mendukung penggunaan pereferensi layanan lintas-project. Lingkungan standar App Engine didukung.

Batasan dengan Cloud Run

  • Load Balancer Aplikasi eksternal dengan NEG serverless tidak mendukung Cloud Run for Anthos.
  • Load Balancer Aplikasi Eksternal tidak mendukung permintaan yang diautentikasi ke layanan Cloud Run.

Batasan pada Cloud Functions

  • IAP tidak berfungsi dengan Cloud Functions.

Batasan terkait App Engine

  • Load balancing multi-region tidak didukung dengan App Engine. Hal ini karena App Engine memerlukan 1 region per project.
  • Hanya satu kebijakan IAP yang diizinkan pada jalur permintaan. Misalnya, jika sudah menetapkan kebijakan IAP di layanan backend, Anda sebaiknya tidak menetapkan kebijakan IAP lain di aplikasi App Engine.
  • Sebaiknya gunakan kontrol traffic 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 Google Cloud Armor, sertifikat SSL, dan kunci pribadi yang diteruskan melalui load balancer.

Batasan dengan Gateway API

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

Harga

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

Langkah selanjutnya