Membuat deployment multi-region untuk Gateway API

Tutorial ini menunjukkan cara mengonfigurasi load balancer HTTP(S) guna mengaktifkan deployment multi-region untuk Gateway API.

Membuat load balancer HTTP(S) untuk mendukung deployment Gateway API multi-region dapat meningkatkan ketersediaan dan mengurangi latensi untuk layanan Anda dengan melakukan inferensi dari lebih dari satu region. Anda dapat meminimalkan latensi dan memaksimalkan waktu beroperasi lebih lanjut dengan perutean lintas region, yang melayani permintaan dari region tersedia yang terdekat dengan pengguna Anda.

Untuk keperluan tutorial ini, Anda akan mengonfigurasi satu skema URL non-regional yang berfungsi di mana saja di dunia, tetapi melayani permintaan pengguna dari deployment Gateway API terdekat. Dengan konfigurasi ini, permintaan idealnya dirutekan ke region yang memberikan latensi minimal kepada pengguna. Jika region terdekat tidak tersedia atau melebihi kapasitas, permintaan akan dialihkan ke region lain untuk memastikan ketersediaan.

Sebelum memulai

Sebelum mengonfigurasi deployment multi-region, ikuti Panduan Memulai Gateway API untuk men-deploy layanan Cloud Run dan membuat gateway yang mengarah ke layanan tersebut.

Untuk tutorial ini, deploy layanan Anda ke dua region yang berbeda. Misalnya, Anda dapat men-deploy dua instance Gateway API:

  • my-gateway-eu ke wilayah di Eropa
  • my-gateway-us ke suatu wilayah di AS

Konfigurasikan izin

Dalam tutorial ini, Anda akan membuat grup endpoint jaringan (NEG) serverless dan load balancer HTTP(S) eksternal di sebuah project Cloud. Tindakan ini memerlukan peran pemilik atau editor project, atau peran IAM Compute Engine berikut:

Tugas Peran yang Diperlukan
Membuat komponen jaringan dan load balancer Admin Jaringan
Membuat dan mengubah NEG Compute Instance Admin
Membuat dan mengubah sertifikat SSL Security Admin

Membuat resource sertifikat SSL

Untuk membuat load balancer HTTPS, resource sertifikat SSL harus ditambahkan ke front end load balancer. Buat resource sertifikat SSL menggunakan sertifikat SSL yang dikelola Google atau sertifikat SSL yang dikelola sendiri.

  • Sertifikat yang dikelola Google. Sebaiknya gunakan sertifikat yang dikelola Google karena Google Cloud mendapatkan, mengelola, dan memperpanjang sertifikat ini secara otomatis. Untuk membuat sertifikat yang dikelola Google, Anda harus memiliki domain dan data DNS untuk domain tersebut agar sertifikat dapat disediakan. Jika belum memiliki domain, Anda bisa mendapatkannya dari Google Domains. Selain itu, Anda harus memperbarui data A DNS domain agar mengarah ke alamat IP load balancer yang dibuat di langkah berikutnya. Untuk petunjuk mendetail, lihat Menggunakan sertifikat yang dikelola Google.

  • Sertifikat yang ditandatangani sendiri. Jika saat ini Anda tidak ingin menyiapkan domain, Anda dapat menggunakan sertifikat SSL yang ditandatangani sendiri untuk melakukan pengujian.

Tutorial ini mengasumsikan bahwa Anda telah membuat resource sertifikat SSL.

Jika ingin menguji proses ini tanpa membuat resource sertifikat SSL (atau domain seperti yang diwajibkan oleh sertifikat yang dikelola Google), Anda tetap dapat menggunakan petunjuk di halaman ini untuk menyiapkan load balancer HTTP.

Membuat load balancer HTTP(S)

  1. Buat NEG serverless untuk setiap instance Gateway API.

    Grup endpoint jaringan (NEG) menentukan grup endpoint backend untuk load balancer. NEG serverless adalah backend yang mengarah ke layanan seperti Gateway API, seperti yang ditampilkan dalam gambar di bawah:

    diagram neg serverless sebagai backend untuk gateway multi-region

    Untuk membuat NEG serverless bagi setiap instance gateway, jalankan perintah berikut, dengan kondisi:

    • SERVERLESS_NEG_NAME adalah nama NEG serverless yang akan dibuat.
    • GATEWAY_ID menentukan nama gateway.
    • REGION_ID adalah region deployment untuk NEG serverless (ini harus cocok dengan region gateway).
    gcloud beta compute network-endpoint-groups create SERVERLESS_NEG_NAME \
      --region=REGION_ID \
      --network-endpoint-type=serverless \
      --serverless-deployment-platform=apigateway.googleapis.com \
      --serverless-deployment-resource=GATEWAY_ID

    Contoh:

    gcloud beta compute network-endpoint-groups create api-gateway-serverless-neg-eu \
      --region=europe-west1 \
      --network-endpoint-type=serverless \
      --serverless-deployment-platform=apigateway.googleapis.com \
      --serverless-deployment-resource=my-gateway-eu

    Ulangi perintah ini untuk membuat NEG serverless untuk instance gateway berikutnya, menggunakan nilai yang sesuai untuk instance gateway kedua, misalnya,api-gateway-serverless-neg-us untuk my-gateway-us di region us-central1.

  2. Buat layanan backend untuk menentukan cara Cloud Load Balancing mendistribusikan traffic.

    Konfigurasi layanan backend berisi kumpulan nilai, seperti protokol yang digunakan untuk terhubung ke backend, berbagai setelan distribusi dan sesi, health check, dan waktu tunggu, seperti yang ditampilkan dalam gambar di bawah:

    diagram neg serverless sebagai backend untuk layanan backend dengan beberapa deployment

    Untuk membuat layanan backend dan menambahkan NEG serverless sebagai backend ke layanan backend, jalankan perintah berikut, dengan kondisi berikut:

    • BACKEND_SERVICE_NAME adalah nama layanan backend Anda.
    • SERVERLESS_NEG_NAME adalah nama NEG serverless yang dibuat di langkah sebelumnya.
    • REGION_ID adalah region deployment untuk NEG serverless (ini harus cocok dengan region gateway).
    gcloud compute backend-services create BACKEND_SERVICE_NAME \
      --global \ 
    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
      --global \
      --network-endpoint-group=SERVERLESS_NEG_NAME \
      --network-endpoint-group-region=REGION_ID

    Contoh:

    gcloud compute backend-services add-backend api-gateway-backend-service \
      --global \
      --network-endpoint-group=api-gateway-serverless-neg-eu \
      --network-endpoint-group-region=europe-west1

    Ulangi perintah ini untuk menambahkan NEG tanpa server kedua ke layanan backend, menggunakan nilai yang sesuai untuk NEG serverless kedua, misalnya, api-gateway-serverless-neg-us untuk my-gateway-us di region us-central1.

  3. Buat peta URL untuk mengarahkan permintaan masuk ke layanan backend, seperti yang ditampilkan dalam gambar di bawah ini:

    diagram peta URL ke layanan backend dengan beberapa deployment

    Untuk membuat peta URL, jalankan perintah berikut, dengan kondisi:

    • URL_MAP_NAME adalah nama peta URL yang akan dibuat.
    • BACKEND_SERVICE_NAME adalah nama layanan backend Anda.
    gcloud compute url-maps create URL_MAP_NAME \
      --default-service BACKEND_SERVICE_NAME

    Contoh:

    gcloud compute url-maps create api-gateway-url-map \
      --default-service api-gateway-backend-service

    Contoh peta URL ini hanya menargetkan satu layanan backend yang mewakili satu gateway, sehingga aturan host atau pencocok jalur tidak diperlukan. Jika memiliki lebih dari satu layanan backend, Anda dapat menggunakan aturan host untuk mengarahkan permintaan ke layanan yang berbeda berdasarkan nama host. Gunakan pencocok jalur untuk mengarahkan permintaan ke berbagai layanan berdasarkan jalur permintaan.

    Contoh:

    gcloud compute url-maps add-path-matcher api-gateway-url-map \
      --path-matcher-name=my-pm2  \
      --default-service=my-host-default-backend \
      --path-rules="/video=video-service,/video/*=video-service" \
      --new-hosts my-hosts.com
    gcloud compute url-maps add-host-rule api-gateway-url-map \
      --hosts=my-app-domain \
      --path-matcher-name=my-app-path-matcher

    Untuk mempelajari aturan host dan pencocok jalur lebih lanjut, lihat dokumentasi Peta URL.

  4. Buat sertifikat SSL untuk proxy target, seperti yang ditampilkan dalam gambar di bawah:

    diagram sertifikat ssl untuk proxy target dengan beberapa deployment

    Untuk membuat load balancer HTTPS, resource sertifikat SSL diperlukan untuk proxy target HTTPS. Anda dapat membuat resource sertifikat SSL menggunakan sertifikat SSL yang dikelola Google atau sertifikat SSL yang dikelola sendiri. Sebaiknya gunakan sertifikat yang dikelola Google.

    Untuk membuat sertifikat yang dikelola Google, Anda harus memiliki domain. Jika tidak memiliki domain, Anda dapat menggunakan sertifikat SSL yang ditandatangani sendiri untuk pengujian.

    Untuk membuat resource sertifikat SSL yang dikelola Google:

    gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME
      --domains DOMAIN

    Untuk membuat resource sertifikat SSL yang dikelola sendiri:

    gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
      --certificate CRT_FILE_PATH \
      --private-key KEY_FILE_PATH
  5. Buat proxy HTTP(S) target untuk mengarahkan permintaan ke peta URL, seperti yang ditunjukkan pada gambar di bawah:

    diagram proxy http ke peta URL

    Untuk membuat proxy target, gunakan perintah berikut, dengan kondisi:

    • TARGET_HTTP_PROXY_NAME adalah nama proxy target yang akan dibuat.
    • URL_MAP_NAME adalah nama peta URL yang dibuat pada langkah sebelumnya.
    • Opsional: SSL_CERT_NAME adalah nama sertifikat SSL yang dibuat.
    gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
      --ssl-certificates=SSL_CERT_NAME
      --url-map=URL_MAP_NAME

    Contoh:

    gcloud compute target-http-proxies create api-gateway-https-proxy \
      --ssl-certificates=hello-cert
      --url-map=api-gateway-url-map
  6. Buat aturan penerusan untuk mengarahkan permintaan masuk ke proxy, seperti yang ditampilkan dalam gambar di bawah ini:

    diagram aturan penerusan ke proxy http

    Gunakan perintah berikut untuk membuat aturan penerusan, dengan kondisi:

    • HTTPS_FORWARDING_RULE_NAME adalah nama aturan yang akan dibuat.
    • TARGET_HTTP_PROXY_NAME adalah nama proxy target yang akan dibuat.
    gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
      --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
      --global \
      --ports=443

    Contoh:

    gcloud compute forwarding-rules create my-fw \
      --target-https-proxy=api-gateway-https-proxy \
      --global \
      --ports=443

Memperbarui data DNS dengan alamat IP load balancer

Jika Anda memiliki domain kustom, langkah ini diperlukan untuk menyiapkan setelan DNS untuk domain Anda agar mengarah ke alamat IP baru layanan Anda. Hal ini juga diperlukan jika Anda membuat load balancer HTTP(S) dengan sertifikat yang dikelola Google (yang memerlukan domain). Sebaiknya alokasikan dan gunakan alamat IP statis saat digunakan dengan DNS. Petunjuk khusus untuk langkah ini bergantung pada penyedia DNS Anda.

  1. Untuk mengirim traffic ke load balancer, data DNS domain Anda (dalam tutorial ini, my-app-domain) harus mengarah ke alamat IP load balancer.

    Untuk menemukan alamat IP aturan penerusan global Anda, gunakan perintah ini:

    gcloud compute forwarding-rules list
  2. Perbarui data DNS A atau AAAA domain Anda agar mengarah ke alamat IP load balancer, sehingga traffic yang dikirim ke URL domain kustom yang ada akan dirutekan melalui load balancer. Diperlukan waktu beberapa detik atau hingga beberapa jam bagi DNS untuk menerapkan perubahan ini ke server DNS.

  3. Uji untuk mengonfirmasi bahwa gateway Anda menerima traffic menggunakan curl atau dengan membuka URL di browser Anda. Contoh: https://my-app-domain

    Setelah pengujian, Anda akan melihat respons yang dihasilkan oleh layanan Cloud Run. Misalnya, halaman ini dapat berupa halaman HTML "Hello World" atau respons yang diharapkan lain yang dibuat oleh layanan backend secara langsung. Ini berarti permintaan Anda melewati load balancer, dan layanan backend menginstruksikan load balancer untuk mengirimkannya ke gateway Anda.

Pertimbangan

Sebelum menerapkan deployment Gateway API multi-region, pertimbangkan hal berikut:

  1. Gateway API saat ini tidak mendukung health check. Dengan konfigurasi perutean lintas region yang diuraikan di atas, jika gateway Anda atau layanan backend-nya menampilkan error di satu region, tetapi keseluruhan infrastruktur Gateway API di region tersebut tersedia dan memiliki kapasitas, load balancer HTTP(S) Anda tidak akan mengarahkan traffic ke region lain.

  2. Menggabungkan region yang berbeda dalam satu aturan penerusan memerlukan harga Paket Premium. Untuk mengetahui informasi lebih lanjut tentang penghitungan harga dan penggunaan, lihat harga Tingkat Layanan Jaringan.

Praktik terbaik

Saat menggunakan penyaluran multi-region, sebaiknya gunakan solusi penyimpanan data terkelola yang direplikasi secara global, seperti Cloud Spanner untuk memastikan bahwa semua data dikelola secara global.