Membuat deployment multi-region untuk API Gateway
Tutorial ini menunjukkan cara mengonfigurasi load balancer HTTP(S) untuk mengaktifkan deployment multi-region untuk API Gateway.
Membuat load balancer HTTP(S) untuk mendukung deployment API Gateway multi-region dapat meningkatkan ketersediaan dan mengurangi latensi untuk layanan Anda dengan menayangkan dari lebih dari satu region. Anda dapat lebih meminimalkan latensi dan memaksimalkan waktu aktif dengan perutean lintas region, yang menayangkan permintaan dari region yang tersedia dan paling dekat dengan pengguna Anda.
Untuk tujuan tutorial ini, Anda akan mengonfigurasi satu skema URL non-regional yang berfungsi di mana saja di seluruh dunia, tetapi menayangkan permintaan pengguna dari deployment API Gateway 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 dirutekan ke region lain untuk memastikan ketersediaan.
Sebelum memulai
Sebelum mengonfigurasi deployment multi-region, ikuti Panduan Memulai API Gateway 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 API Gateway:
my-gateway-eu
ke region di Eropamy-gateway-us
ke region di AS
Konfigurasikan izin
Dalam tutorial ini, Anda akan membuat grup endpoint jaringan (NEG) tanpa server dan load balancer HTTP(S) eksternal di 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 frontend 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 memperoleh, 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 tidak ingin menyiapkan domain saat ini, Anda dapat menggunakan sertifikat SSL yang ditandatangani sendiri untuk 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 diperlukan oleh sertifikat yang dikelola Google), Anda masih dapat menggunakan petunjuk di halaman ini untuk menyiapkan load balancer HTTP.
Membuat load balancer HTTP(S)
Buat NEG tanpa server untuk setiap instance API Gateway.
Grup endpoint jaringan (NEG) menentukan grup endpoint backend untuk load balancer. NEG tanpa server adalah backend yang mengarah ke layanan seperti API Gateway, seperti yang ditunjukkan pada gambar di bawah:
Untuk membuat NEG serverless untuk setiap instance gateway, jalankan perintah berikut, dengan:
- SERVERLESS_NEG_NAME adalah nama NEG tanpa server yang akan dibuat.
- GATEWAY_ID menentukan nama gateway.
- REGION_ID adalah region deployment untuk NEG serverless (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 tanpa server untuk instance gateway berikutnya, menggunakan nilai yang sesuai untuk instance gateway kedua, misalnya,
api-gateway-serverless-neg-us
untukmy-gateway-us
di regionus-central1
.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 ditunjukkan pada gambar di bawah:
Untuk membuat layanan backend dan menambahkan NEG tanpa server sebagai backend ke layanan backend, jalankan perintah berikut, dengan:
- 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 (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 tanpa server kedua, misalnya,
api-gateway-serverless-neg-us
untukmy-gateway-us
di regionus-central1
.Buat peta URL untuk mengarahkan permintaan masuk ke layanan backend, seperti yang ditunjukkan pada gambar di bawah:
Untuk membuat peta URL, jalankan perintah berikut, dengan:
- 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 layanan yang berbeda 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.
Buat sertifikat SSL untuk proxy target Anda, seperti yang ditunjukkan pada gambar di bawah:
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
Buat proxy HTTP(S) target untuk merutekan permintaan ke peta URL, seperti yang ditunjukkan pada gambar di bawah:
Untuk membuat proxy target, gunakan perintah berikut, dengan:
- TARGET_HTTP_PROXY_NAME adalah nama proxy target yang akan dibuat.
- URL_MAP_NAME adalah nama peta URL yang dibuat di 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
Buat aturan penerusan untuk mengarahkan permintaan masuk ke proxy, seperti yang ditunjukkan pada gambar di bawah:
Gunakan perintah berikut untuk membuat aturan penerusan, dengan:
- 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 agar domain Anda 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 spesifik untuk langkah ini bergantung pada penyedia DNS Anda.
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, gunakan perintah ini:
gcloud compute forwarding-rules list
Perbarui data A atau AAAA DNS domain Anda agar mengarah ke alamat IP load balancer sehingga traffic yang dikirim ke URL domain kustom yang ada akan dirutekan melalui load balancer. Mungkin perlu waktu beberapa detik atau beberapa jam agar DNS menerapkan perubahan ini ke server DNS.
Uji untuk mengonfirmasi bahwa gateway Anda menerima traffic menggunakan
curl
atau dengan membuka URL di browser. Contoh:https://my-app-domain
Setelah pengujian, Anda akan melihat respons yang dihasilkan oleh layanan Cloud Run. Misalnya, ini dapat berupa halaman HTML "Hello World" atau respons lain yang diharapkan yang dihasilkan oleh layanan backend secara langsung. Ini berarti permintaan Anda akan melalui load balancer, dan layanan backend menginstruksikan load balancer untuk mengirimkannya ke gateway Anda.
Pertimbangan
Sebelum menerapkan deployment API Gateway multi-region, pertimbangkan hal berikut:
API Gateway saat ini tidak mendukung health check. Dengan konfigurasi pemilihan rute lintas region yang diuraikan di atas, jika gateway atau layanan backend-nya menampilkan error di satu region, tetapi keseluruhan infrastruktur API Gateway di region tersebut tersedia dan memiliki kapasitas, load balancer HTTP(S) Anda tidak akan mengalihkan traffic ke region lain.
Menggabungkan berbagai region dalam satu aturan penerusan memerlukan harga Paket Premium. Untuk mengetahui informasi selengkapnya tentang cara menghitung harga dan penggunaan, lihat Harga Network Service Tiers.
Praktik terbaik
Saat menggunakan penayangan multi-region, sebaiknya gunakan solusi penyimpanan data terkelola yang direplikasi secara global seperti Cloud Spanner untuk memastikan bahwa semua data dikelola secara global.