Jika Anda menggunakan metrik Pub/Sub sebagai sinyal untuk menskalakan otomatis pipeline, berikut beberapa rekomendasi.
Menggunakan lebih dari satu sinyal untuk menskalakan otomatis pipeline
Jangan hanya menggunakan metrik Pub/Sub untuk menskalakan otomatis pipeline. Hal ini dapat menyebabkan skenario di mana Anda memiliki satu titik kegagalan untuk keputusan penskalaan otomatis. Sebagai gantinya, gunakan kombinasi sinyal untuk memicu penskalaan otomatis. Contoh sinyal tambahan adalah tingkat penggunaan CPU klien. Sinyal ini dapat menunjukkan apakah tugas klien menangani pekerjaan dan apakah penskalaan dapat memungkinkan tugas klien menangani lebih banyak pekerjaan. Beberapa contoh sinyal dari produk Cloud lain yang dapat Anda gunakan untuk pipeline adalah sebagai berikut:
Compute Engine mendukung penskalaan otomatis berdasarkan sinyal seperti penggunaan CPU dan metrik Monitoring. Compute Engine juga mendukung beberapa metrik dan beberapa sinyal untuk keandalan yang lebih baik.
Untuk mengetahui informasi selengkapnya tentang penskalaan dengan metrik Monitoring, lihat Menskalakan berdasarkan metrik Monitoring. Untuk mengetahui informasi selengkapnya tentang penskalaan dengan penggunaan CPU, lihat Menskalakan berdasarkan penggunaan CPU.
Penskalaan otomatis Pod horizontal (HPA) Google Kubernetes Engine mendukung penskalaan otomatis berdasarkan penggunaan resource seperti penggunaan CPU dan memori, metrik Kubernetes kustom, dan metrik eksternal seperti metrik Monitoring untuk Pub/Sub. Fitur ini juga mendukung beberapa sinyal.
Untuk mengetahui informasi selengkapnya, lihat Penskalaan otomatis Pod horizontal.
Menggunakan versi regional metrik, bukan versi global
Pub/Sub menawarkan dua versi dari setiap metrik yang biasanya digunakan dengan penskalaan otomatis. Pastikan Anda menggunakan versi dengan akhiran by_region:
Jangan gunakan versi global metrik ini jika Anda ingin penskalaan otomatis Anda tahan terhadap gangguan satu region. Versi global metrik ini memerlukan perhitungan backlog di semua region yang diketahui memiliki pesan, yang berarti ketidaktersediaan di satu region akan menyebabkan kesenjangan data. Sebaliknya, versi by_region metrik menghitung dan melaporkan backlog berdasarkan per region. Jika backlog tidak dapat dihitung untuk satu region, metrik akan tetap melaporkan nilai untuk region lainnya.
Menghindari penggunaan metrik throughput sisi pelanggan untuk menskalakan otomatis pelanggan
Hindari penggunaan metrik throughput sisi pelanggan seperti subscription/ack_message_count untuk menskalakan otomatis klien pelanggan. Sebagai gantinya, pertimbangkan untuk menggunakan metrik yang secara langsung mencerminkan backlog pesan yang menunggu untuk diproses, seperti subscription/num_unacked_messages atau subscription/oldest_unacked_message_age yang disebutkan sebelumnya.
Masalah terkait penggunaan metrik throughput sisi pelanggan untuk penskalaan otomatis
Penggunaan metrik ini dapat menyebabkan masalah karena metrik ini mewakili jumlah traffic antara Pub/Sub dan pelanggan. Penskalaan berdasarkan metrik tersebut dapat membuat loop referensial mandiri di mana penurunan pesan yang dikirim atau dikonfirmasi akan menyebabkan penurunan skala klien. Misalnya, hal ini dapat terjadi jika ada penurunan traffic sementara atau ada masalah dengan salah satu pelanggan Anda.
Jika klien Anda memperkecil skala ke nol atau mendekati nol, semua traffic langganan yang sedang berlangsung dapat berhenti, dan pelanggan mungkin tidak dapat memproses pesan, meskipun pesan baru tiba. Hal ini dapat menyebabkan latensi penyerapan yang signifikan dan menyebabkan status yang tidak dapat dipulihkan untuk klien pelanggan Anda.
Menangani kesenjangan metrik saat terjadi
Jangan berasumsi bahwa tidak adanya metrik berarti tidak ada pesan yang akan diproses. Misalnya, jika sebagai respons terhadap metrik yang tidak ada, Anda memperkecil skala tugas pemrosesan ke nol, pesan yang sudah ada dalam backlog atau yang dipublikasikan selama waktu ini mungkin tidak digunakan. Hal ini akan meningkatkan latensi end-to-end. Untuk meminimalkan latensi, tetapkan jumlah tugas minimum lebih besar dari nol sehingga Anda selalu siap menangani pesan yang dipublikasikan, meskipun metrik Pub/Sub terbaru menunjukkan antrean kosong.
Autoscaler Compute Engine dan HPA Google Kubernetes Engine dirancang untuk mempertahankan jumlah replika saat ini jika metrik tidak tersedia. Hal ini memberikan jaring pengaman jika tidak ada metrik yang tersedia.
Anda juga dapat menerapkan mekanisme kontrol aliran Pub/Sub untuk membantu mencegah tugas kewalahan jika tidak sengaja diturunkan skalanya karena metrik tidak ada.