Pengelolaan traffic gateway

Halaman ini menjelaskan cara kerja pengelolaan traffic Gateway.

Ringkasan

Jaringan Google Kubernetes Engine (GKE) dibuat berdasarkan Cloud Load Balancing. Dengan Cloud Load Balancing, sebuah IP anycast tunggal memberikan pengelolaan traffic global. Pengelolaan traffic Google menyediakan load balancing, penskalaan otomatis, dan pengelolaan kapasitas secara global dan regional untuk menyediakan distribusi traffic yang setara, stabil, dan berlatensi rendah. Dengan Gateway GKE controller, pengguna GKE dapat memanfaatkan kontrol pengelolaan traffic global Google secara deklaratif dan berbasis Kubernetes.

Untuk mencoba lonjakan traffic antar-cluster, lihat Men-deploy load balancing berbasis kapasitas. Untuk mencoba penskalaan otomatis berbasis traffic, lihat Penskalaan otomatis berdasarkan traffic load balancer.

Pengelolaan traffic

Load balancing, penskalaan otomatis, dan pengelolaan kapasitas adalah dasar dari sistem pengelolaan traffic. Keduanya beroperasi bersama untuk menyamakan dan menstabilkan beban sistem.

  • Load balancing mendistribusikan traffic di seluruh Pod backend sesuai dengan lokasi, kondisi, dan beragam algoritma load balancing.
  • Autoscaling menskalakan replika workload untuk menciptakan kapasitas yang lebih besar guna menyerap lebih banyak traffic.
  • Pengelolaan kapasitas memantau penggunaan Layanan sehingga traffic dapat diluapkan ke backend yang masih memiliki kapasitas, bukan memengaruhi ketersediaan atau performa aplikasi.

Kemampuan tersebut dapat digabungkan dengan berbagai cara, bergantung pada sasaran Anda. Misalnya:

  • Jika ingin memanfaatkan Spot VM berbiaya rendah, Anda dapat mengoptimalkannya untuk mendistribusikan traffic secara merata di seluruh Spot VM meski harus mengorbankan latensi. Dengan menggunakan load balancing dan pengelolaan kapasitas, GKE akan meluapkan traffic antar region berdasarkan kapasitas sehingga Spot VM dapat dimanfaatkan sepenuhnya di mana pun tersedia.
  • Jika ingin mengoptimalkan latensi pengguna dengan mengorbankan penyediaan yang berlebihan, Anda dapat men-deploy cluster GKE di banyak region dan meningkatkan kapasitas secara dinamis setiap kali beban meningkat. Menggunakan load balancing dan penskalaan otomatis GKE akan menskalakan otomatis jumlah Pod saat traffic melonjak, sehingga traffic tidak perlu diluapkan ke region lain. Kapasitas region akan bertambah besar sehingga dapat sepenuhnya menangani beban sedekat mungkin dengan pengguna.

Diagram berikut menunjukkan load balancing, penskalaan otomatis, dan pengelolaan kapasitas yang beroperasi bersama:

Diagram load balancing, penskalaan otomatis, dan pengelolaan kapasitas

Dalam diagram, workload di cluster gke-us gagal. Load balancing dan health check menghabiskan koneksi aktif dan mengalihkan traffic ke cluster terdekat berikutnya. Workload di gke-asia menerima lebih banyak traffic daripada kapasitas yang dimilikinya, sehingga workload ini mengalihkan beban menjadi gke-eu. gke-eu menerima lebih banyak beban daripada biasanya karena peristiwa di gke-us dan gke-asia sehingga gke-eu melakukan penskalaan otomatis untuk meningkatkan kapasitas traffic-nya.

Untuk mempelajari lebih lanjut cara Cloud Load Balancing menangani pengelolaan traffic, lihat pengelolaan kapasitas global.

Kemampuan pengelolaan traffic

Resource Gateway, HTTPRoute, Service, dan Policy menyediakan kontrol untuk mengelola traffic di GKE. Gateway GKE controller adalah bidang kontrol yang memantau resource ini.

Kemampuan pengelolaan traffic berikut tersedia saat men-deploy Layanan di GKE:

  • Kapasitas layanan: kemampuan untuk menentukan jumlah kapasitas traffic yang dapat diterima Layanan sebelum Pod diskalakan otomatis atau traffic diluapkan ke cluster lain yang tersedia.
  • Penskalaan otomatis berbasis traffic: penskalaan otomatis Pod dalam Layanan berdasarkan permintaan HTTP yang diterima per detik.
  • Load balancing multi-cluster: kemampuan untuk melakukan load balancing pada Layanan yang dihosting di beberapa cluster GKE atau di beberapa region.
  • Pemisahan traffic: distribusi traffic eksplisit dan berbasis bobot di seluruh backend. Pemisahan traffic didukung dengan Gateway cluster tunggal di GA.

Dukungan pengelolaan traffic

Kemampuan pengelolaan traffic yang tersedia bergantung pada GatewayClass yang Anda deploy. Untuk daftar lengkap dukungan fitur, lihat Kemampuan GatewayClass. Tabel berikut merangkum dukungan GatewayClass untuk pengelolaan traffic:

GatewayClass Kapasitas layanan Penskalaan otomatis traffic Load balancing multi-cluster Pemisahan traffic1
gke-l7-global-external-managed
gke-l7-regional-external-managed
gke-l7-rilb
gke-l7-gxlb
gke-l7-global-external-managed-mc
gke-l7-regional-external-managed-mc
gke-l7-rilb-mc
gke-l7-gxlb-mc
1 Pemisahan traffic didukung dengan Gateway cluster tunggal di GA.

Load balancing global, regional, dan zonal

Kapasitas layanan, lokasi, dan kondisi layanan menentukan jumlah traffic yang dikirim load balancer ke backend tertentu. Keputusan load balancing dibuat pada level berikut, dimulai dengan level global untuk load balancer global dan level regional untuk load balancer regional:

  • Global: traffic dikirim ke region Google Cloud terdekat ke klien yang memiliki backend responsif yang masih memiliki kapasitas. Selama region masih memiliki kapasitas, region tersebut akan menerima semua traffic terdekat. Jika suatu region tidak memiliki kapasitas, kelebihan traffic akan diluapkan ke region terdekat berikutnya yang masih memiliki kapasitas. Untuk mempelajari lebih lanjut, lihat load balancing global.
  • Regional: traffic dikirim oleh load balancer ke region tertentu. Beban traffic diseimbangkan di seluruh zona sesuai dengan kapasitas penyaluran zona yang tersedia. Untuk mempelajari lebih lanjut, lihat load balancing regional.
  • Zonal: setelah traffic ditentukan untuk zona tertentu, load balancer mendistribusikan traffic secara merata di seluruh backend dalam zona tersebut. Koneksi TCP yang ada dan setelan persistensi sesi akan dipertahankan, sehingga permintaan berikutnya akan mengarah ke backend yang sama, asalkan Pod backend responsif. Untuk mempelajari lebih lanjut, lihat load balancing zonal.

Load balancing global dan traffic luapan.

Untuk mencoba konsep berikut di cluster Anda sendiri, lihat Load balancing berbasis kapasitas.

Dalam kondisi normal, traffic dikirim ke backend yang terdekat dengan klien. Traffic berhenti di titik kehadiran (PoP) Google terdekat ke klien, lalu melintasi backbone Google hingga mencapai backend terdekat, seperti yang ditentukan oleh latensi jaringan. Jika backend di suatu region tidak memiliki kapasitas yang tersisa, traffic akan diluapkan ke cluster terdekat berikutnya dengan backend yang responsif, yang masih memiliki kapasitas. Jika kurang dari 50% Pod backend dalam suatu zona tidak responsif, traffic secara bertahap akan beralih ke zona atau region lain, terlepas dari kapasitas yang dikonfigurasi.

Traffic luapan hanya terjadi dalam kondisi berikut:

  • Anda menggunakan Gateway multi-cluster.
  • Anda memiliki Layanan yang sama yang di-deploy di beberapa cluster, yang dilayani oleh Gateway multi-cluster.
  • Anda telah mengonfigurasi kapasitas Layanan sehingga traffic melebihi kapasitas layanan di satu cluster, tetapi tidak di cluster lainnya.

Diagram berikut menunjukkan cara kerja load balancing global dengan traffic luapan:

Load balancing global dengan traffic luapan

Dalam diagram:

  • Gateway multi-cluster menyediakan load balancing internet global untuk Layanan store. Layanan di-deploy di dua cluster GKE, satu di us-west1 dan satu lagi di europe-west1. Setiap cluster menjalankan 2 replika.
  • Setiap Layanan dikonfigurasi dengan max-rate-per-endpoint="10", yang berarti setiap Layanan memiliki total kapasitas 2 replika * 10 RPS = 20 RPS di setiap cluster.
  • PoP Google di Amerika Utara menerima 6 RPS. Semua traffic dikirim ke backend responsif terdekat yang masih memiliki kapasitas, yaitu cluster GKE di us-west1.
  • PoP Eropa menerima 30 RPS kumulatif. Backend terdekat berada di europe-west1, tetapi backend tersebut hanya memiliki kapasitas 20 RPS. Karena backend di us-west1 memiliki kapasitas berlebih, 10 RPS diluapkan ke us-west1 sehingga menerima total 16 RPS dan mendistribusikan 8 RPS ke setiap pod.

Mencegah traffic luapan.

Traffic luapan membantu mencegah kelebihan kapasitas aplikasi yang dapat memengaruhi performa atau ketersediaan.

Namun, Anda mungkin tidak ingin meluapkan traffic. Aplikasi yang sensitif terhadap latensi, misalnya, mungkin tidak mendapatkan manfaat dari traffic luapan ke backend yang lokasinya lebih jauh.

Anda dapat menggunakan salah satu metode berikut untuk mencegah traffic luapan:

  • Hanya gunakan Gateway cluster tunggal yang dapat menghosting Layanan hanya dalam satu cluster.
  • Meskipun menggunakan Gateway multi-cluster, replika aplikasi yang di-deploy di beberapa cluster dapat di-deploy sebagai Layanan terpisah. Dari perspektif Gateway, hal ini memungkinkan load balancing multi-cluster, tetapi tidak menggabungkan semua endpoint Layanan antar-cluster.
  • Tetapkan kapasitas Layanan pada tingkat yang cukup tinggi sehingga kapasitas traffic tidak akan terlampaui secara realistis, kecuali jika benar-benar diperlukan.

Load balancing dalam suatu region

Dalam suatu region, traffic didistribusikan di seluruh zona sesuai dengan kapasitas backend yang tersedia. Ini tidak menggunakan luapan (overflow), melainkan load balancing secara proporsional dengan kapasitas Layanan di setiap zona. Setiap alur atau sesi apa pun selalu dikirim ke satu Pod backend yang konsisten, dan tidak dibagi.

Diagram berikut menunjukkan bagaimana distribusi traffic dalam satu region:

Traffic didistribusikan dalam satu region

Dalam diagram:

  • Sebuah Layanan di-deploy di cluster GKE regional. Layanan memiliki 4 Pod yang di-deploy secara tidak merata di seluruh zona. 3 Pod berada di zona A, 1 Pod di zona B, dan 0 Pod di zona C.
  • Layanan dikonfigurasi dengan maxRatePerEndpoint="10". Zona A memiliki total kapasitas 30 RPS, zona B memiliki 10 RPS kapasitas total, dan zona C memiliki 0 RPS dari total kapasitas, karena tidak memiliki Pod.
  • Gateway menerima total 16 RPS traffic dari klien yang berbeda. Traffic ini didistribusikan di seluruh zona secara proporsional dengan kapasitas yang tersisa di setiap zona.
  • Alur traffic dari setiap sumber atau klien secara konsisten di-load balanced ke Pod backend tunggal sesuai dengan setelan persistensi sesi. Distribusi traffic dibagi di berbagai alur traffic sumber sehingga setiap alur tidak pernah dibagi. Akibatnya, jumlah minimum keberagaman sumber atau klien diperlukan untuk mendistribusikan traffic secara terperinci di seluruh backend.

Misalnya, jika traffic masuk melonjak dari 16 RPS menjadi 60 RPS, salah satu skenario berikut akan terjadi:

  • Jika menggunakan Gateway cluster tunggal, tidak ada cluster atau region lain yang menjadi tujuan luapan traffic ini. Traffic terus didistribusikan sesuai dengan kapasitas zona relatif, meskipun traffic masuk melebihi kapasitas total. Akibatnya, zona A menerima 45 RPS dan zona B menerima 15 RPS.
  • Jika menggunakan Gateway multi-cluster dengan Layanan yang didistribusikan di beberapa cluster, traffic dapat diluapkan ke cluster lain dan region lain seperti yang dijelaskan dalam Load balancing global dan traffic luapan. Zona A menerima 30 RPS, zona B menerima 10 RPS, dan 20 RPS diluapkan ke cluster lain.

Load balancing dalam suatu zona

Setelah traffic dikirim ke suatu zona, traffic tersebut akan didistribusikan secara merata ke semua backend dalam zona tersebut. Sesi HTTP bersifat tetap, bergantung pada setelan afinitas sesi. Kecuali jika backend tidak tersedia, koneksi TCP yang ada tidak akan pernah dipindahkan ke backend yang berbeda. Ini berarti koneksi yang berumur panjang terus berlanjut ke Pod backend yang sama meskipun koneksi baru meluap karena kapasitas yang terbatas. Load balancer memprioritaskan mempertahankan koneksi yang ada daripada koneksi baru.

Kapasitas layanan

Dengan kapasitas layanan, Anda dapat menentukan nilai Permintaan per Detik (RPS) per Pod dalam Layanan. Nilai ini menunjukkan rata-rata RPS maksimum per Pod yang dapat diterima oleh Layanan. Nilai ini dapat dikonfigurasi di Layanan dan digunakan untuk menentukan penskalaan otomatis berbasis traffic dan load balancing berbasis kapasitas.

Persyaratan

Kapasitas layanan memiliki persyaratan dan batasan berikut:

  • Hanya memengaruhi load balancing jika Anda menggunakan penskalaan otomatis berbasis traffic atau Gateway multi-cluster. Jika Anda tidak menggunakan keduanya, kapasitas Layanan tidak akan memengaruhi traffic jaringan.

Mengonfigurasi kapasitas Layanan

Gateway cluster tunggal

Pastikan cluster GKE Anda menjalankan versi 1.31.1-gke.2008000 atau yang lebih baru. Versi sebelumnya dapat menggunakan anotasi networking.gke.io/max-rate-per-endpoint seperti yang dijelaskan di tab Gateway Multi-cluster.

Untuk menggunakan Gateway cluster tunggal guna mengonfigurasi kapasitas Layanan, buat Layanan dan GCPBackendPolicy terkait. Gunakan manifes berikut untuk membuat Layanan:

apiVersion: v1
kind: Service
metadata:
  name: store
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

Konfigurasikan objek GCPBackendPolicy menggunakan kolom maxRatePerEndpoint dengan RPS maksimum. Gunakan manifes berikut untuk mengonfigurasi objek GCPBackendPolicy:

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: store
spec:
  default:
    maxRatePerEndpoint: "RATE_PER_SECOND"
  targetRef:
    group: ""
    kind: Service
    name: store

Gateway Multi-cluster

Untuk menggunakan Gateway multi-cluster guna mengonfigurasi kapasitas Layanan, buat Layanan menggunakan anotasi networking.gke.io/max-rate-per-endpoint. Gunakan manifes berikut untuk membuat Layanan dengan RPS maksimum:

apiVersion: v1
kind: Service
metadata:
  name: store
annotations:
  networking.gke.io/max-rate-per-endpoint: "RATE_PER_SECOND"
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

Ganti RATE_PER_SECOND dengan permintaan HTTP/HTTPS maksimum per detik yang harus diterima satu Pod dalam Layanan ini.

Nilai maxRatePerEndpoint membuat kapasitas dinamis untuk Layanan berdasarkan jumlah Pod dalam Layanan. Total nilai kapasitas Layanan dihitung dengan mengalikan nilai maxRatePerEndpoint dengan jumlah replika, seperti yang dijelaskan dalam formula berikut:

Total Service capacity = maxRatePerEndpoint * number of replicas

Jika autoscaler meningkatkan jumlah Pod dalam Layanan, total kapasitas Layanan akan dihitung sebagaimana mestinya. Jika suatu Layanan diperkecil skalanya hingga nol Pod, berarti Layanan tersebut memiliki kapasitas nol dan tidak menerima traffic apa pun dari load balancer.

Kapasitas layanan dan NEG mandiri

Kapasitas layanan juga dapat dikonfigurasi saat menggunakan NEG mandiri, tetapi tidak menggunakan setelan maxRatePerEndpoint. Jika menggunakan NEG mandiri, maxRatePerEndpoint dikonfigurasi secara manual saat menambahkan NEG ke resource Layanan Backend. Dengan menggunakan perintah gcloud compute backend-services add-backend, flag --max-rate-per-endpoint dapat mengonfigurasi kapasitas untuk setiap NEG satu per satu.

Tindakan ini dapat berguna untuk alur kerja berikut:

Tidak ada perbedaan fungsional saat mengonfigurasi kapasitas layanan dengan NEG mandiri. Penskalaan otomatis traffic dan spillover traffic didukung.

Menentukan kapasitas Layanan Anda

Menentukan nilai untuk maxRatePerEndpoint memerlukan pemahaman tentang karakteristik performa aplikasi dan sasaran load balancing Anda. Strategi berikut dapat membantu Anda menentukan karakteristik performa aplikasi:

  • Amati aplikasi Anda di lingkungan pengujian dan lingkungan produksi saat dikonfigurasi tanpa kapasitas Layanan.
  • Gunakan Cloud Monitoring untuk membuat korelasi antara permintaan traffic dan tujuan tingkat layanan performa (SLO) Anda.
  • Tentukan SLO performa untuk aplikasi Anda. SLO tersebut mungkin salah satu atau beberapa dari yang berikut, bergantung pada apa yang Anda anggap sebagai performa "buruk" atau "tidak stabil". Semua hal berikut dapat dikumpulkan dari metrik load balancer Cloud Monitoring:
    • Kode error response
    • Respons atau latensi total
    • Backend yang tidak responsif atau periode nonaktif
  • Amati aplikasi Anda dengan ramai traffic di lingkungan pengujian dan produksi. Dalam lingkungan pengujian, fokuskan aplikasi Anda pada peningkatan beban permintaan agar Anda dapat melihat dampak dari berbagai metrik performa ketika traffic meningkat. Dalam lingkungan produksi, amati level pola traffic yang realistis.

Kapasitas Layanan default

Semua Layanan yang terpasang ke resource GKE memiliki kapasitas Layanan default yang dikonfigurasi meskipun tidak dikonfigurasi secara eksplisit. Untuk mempelajari lebih lanjut, lihat Kapasitas layanan default.

Tabel berikut menjelaskan kapasitas default:

Jenis resource load balancing maxRatePerEndpoint Default
Ingress (internal dan external) 1 RPS
Gateway (semua GatewayClass) 100.000.000 RPS
MultiClusterIngress 100.000.000 RPS

Penskalaan otomatis berbasis traffic

Penskalaan otomatis berbasis traffic adalah kemampuan GKE yang mengintegrasikan sinyal traffic secara native dari load balancer untuk menskalakan Pod secara otomatis. Penskalaan otomatis berbasis traffic hanya didukung untuk Gateway cluster tunggal.

Untuk menggunakan penskalaan otomatis berbasis traffic, lihat Penskalaan otomatis berdasarkan traffic load balancer.

Penskalaan otomatis berbasis traffic memberikan manfaat berikut:

  • Aplikasi yang tidak terikat dengan CPU atau memori mutlak mungkin memiliki batas kapasitas yang tidak tercermin dalam penggunaan CPU atau memorinya.
  • Traffic, atau permintaan per detik (RPS) adalah metrik yang lebih mudah dipahami dalam beberapa kasus karena lebih selaras dengan penggunaan aplikasi dan metrik bisnis seperti kunjungan halaman atau pengguna aktif harian (DAU).
  • Traffic adalah indikator utama yang merepresentasikan permintaan instan dibandingkan dengan CPU atau memori yang merupakan indikator yang lambat.
  • Kombinasi metrik penskalaan otomatis CPU, memori, dan traffic memberikan cara holistik aplikasi penskalaan otomatis yang menggunakan beberapa dimensi untuk memastikan bahwa kapasitas disediakan dengan tepat.

Diagram berikut menunjukkan cara kerja penskalaan otomatis berbasis traffic:

Penskalaan otomatis berbasis traffic

Dalam diagram:

  • Pemilik layanan mengonfigurasi kapasitas Layanan dan pemakaian target untuk Deployment.
  • Gateway menerima traffic dari klien yang menuju ke Layanan store. Gateway mengirimkan telemetri pemakaian ke Autoscaler Pod GKE. Pemakaian setara dengan traffic aktual yang diterima oleh setiap Pod dibagi dengan kapasitas Pod yang dikonfigurasi.
  • Penskalaan otomatis Pod GKE menaikkan atau menurunkan skala Pod sesuai dengan penggunaan target yang dikonfigurasi.

Perilaku penskalaan otomatis

Diagram berikut menunjukkan cara kerja penskalaan otomatis berbasis traffic pada aplikasi yang menerima 10 RPS melalui load balancer:

Penskalaan otomatis berbasis traffic dengan 10 RPS

Dalam diagram, pemilik layanan telah mengonfigurasi kapasitas Layanan store ke 10 RPS, yang berarti bahwa setiap Pod dapat menerima maksimum 10 RPS. HorizontalPodAutoscaler dikonfigurasi dengan averageValue disetel ke 70, yang berarti bahwa target pemakaian adalah 70% dari 10 RPS per Pod.

Autoscaler mencoba menskalakan replika untuk mencapai persamaan berikut:

replicas = ceiling[ current traffic / ( averageValue * maxRatePerEndpoint) ]

Dalam diagram, persamaan ini dihitung dengan:

ceiling[ 10 rps / (0.7 * 10 rps) ] = ceiling[ 1.4 ] = 2 replicas

10 RPS traffic menghasilkan 2 replika. Setiap replika menerima 5 RPS, yang berada di bawah target penggunaan sebesar 7 RPS.

Pemisahan traffic

Pemisahan traffic menggunakan rasio eksplisit, yang disebut bobot, yang menentukan proporsi permintaan HTTP yang dikirim ke Layanan. Resource HTTPRoute memungkinkan Anda mengonfigurasi bobot pada daftar Layanan. Bobot relatif di antara Layanan menentukan pemisahan traffic di antara layanan-layanan tersebut. Hal ini berguna untuk memisahkan traffic selama peluncuran, perubahan terbatas, atau untuk keadaan darurat.

Diagram berikut menjelaskan contoh konfigurasi pemisahan traffic:

Konfigurasi pemisahan traffic

Dalam diagram:

  • Pemilik layanan mengonfigurasi dua layanan untuk satu rute, dengan aturan yang membagi traffic 90% ke store-v1 dan 10% ke store-v2.
  • Gateway menerima traffic dari klien yang mengarah ke URL aplikasi Play Store dan traffic tersebut dibagi sesuai dengan aturan yang telah dikonfigurasi. 90% rute lalu lintas ke store-v1 dan 10% rute ke store-v2.

Pembagian traffic didukung antar-Layanan di cluster yang sama dan juga antar-Layanan di cluster yang berbeda:

  • Pemisahan traffic antar-Layanan: digunakan untuk memisahkan traffic untuk peluncuran versi aplikasi. Dengan menggunakan contoh pemisahan traffic, Anda akan memiliki dua Deployment terpisah, store-v1 dan store-v2, yang masing-masing memiliki Layanan sendiri, store-v1 dan store-v2. Bobot dikonfigurasi di antara dua Layanan untuk mengalihkan traffic secara bertahap hingga store-v2 diluncurkan sepenuhnya.

  • Pembagian traffic antar-ServiceImports: digunakan untuk mengalihkan traffic ke atau dari cluster tertentu untuk pemeliharaan, migrasi, atau keadaan darurat. ServiceImport merupakan Layanan multi-cluster dan memungkinkan pemisahan traffic antara Layanan yang berbeda pada cluster yang berbeda. Latihan Pemilihan rute multi-cluster berwarna blue-green dengan Gateway menunjukkan pembagian traffic di seluruh cluster.

Bobot vs kapasitas

Bobot dan kapasitas mengontrol jumlah traffic yang dikirim ke berbagai Layanan. Meskipun memiliki efek yang mirip, keduanya beroperasi secara berbeda dan memiliki kasus penggunaan yang berbeda. Keduanya dapat dan harus digunakan bersama, meskipun untuk tujuan yang berbeda.

Bobot

Bobot adalah kontrol traffic eksplisit. Bobot menentukan proporsi traffic yang tepat, terlepas dari traffic yang masuk dan pemanfaatan backend. Dalam contoh pemisahan traffic, jika store-v2 kelebihan kapasitas, atau jika semua replikanya gagal, 10% traffic akan tetap dialokasikan untuk store-v2, yang berpotensi menyebabkan traffic berkurang. Hal ini karena bobot tidak mengubah proporsi traffic berdasarkan pemakaian atau kondisi.

Bobot paling cocok untuk kasus penggunaan berikut:

  • Mengalihkan traffic antara berbagai versi layanan untuk peluncuran.
  • Mengaktifkan layanan secara manual menggunakan pemisahan traffic eksplisit.
  • Mengalihkan traffic dari set backend untuk keperluan darurat atau pemeliharaan.

Kapasitas

Kapasitas adalah kontrol traffic implisit. Kapasitas menentukan proporsi traffic secara tidak langsung karena proporsi traffic bergantung pada jumlah traffic masuk, pemakaian backend, dan lokasi sumber traffic. Kapasitas adalah properti yang melekat pada Layanan dan biasanya jauh lebih jarang diperbarui.

Kapasitas paling cocok untuk kasus penggunaan berikut:

  • Mencegah pemakaian backend yang berlebihan selama lonjakan traffic.
  • Mengontrol tingkat penskalaan otomatis terkait traffic.

Mengonfigurasi kapasitas Layanan untuk meluapkan traffic mungkin tidak selalu merupakan perilaku yang Anda inginkan. Pertimbangkan contoh load balancing global. Kapasitas layanan melindungi backend dari pemakaian yang berlebihan dengan traffic luapan, tetapi hal ini dapat mengakibatkan latensi tambahan untuk permintaan yang telah diluapkan, karena permintaan tersebut berpindah ke region yang lebih terpencil.

Jika aplikasi Anda tidak terlalu sensitif terhadap pemakaian yang berlebihan, sebaiknya konfigurasikan kapasitas Layanan yang sangat tinggi sehingga traffic tidak akan diluapkan ke region lain. Jika ketersediaan atau latensi aplikasi Anda sensitif terhadap pemakaian yang berlebihan, meluapkan traffic ke cluster atau region lain mungkin lebih baik daripada menyerap traffic berlebih di backend yang dipakai secara berlebihan. Untuk mempelajari lebih lanjut cara mengonfigurasi kapasitas Layanan untuk aplikasi Anda, lihat Menentukan kapasitas Layanan.

Langkah berikutnya