Jika Anda menggunakan metrik Pub/Sub sebagai sinyal untuk melakukan penskalaan otomatis pada pipeline, berikut beberapa rekomendasi.
Menggunakan lebih dari satu sinyal untuk melakukan penskalaan otomatis pada pipeline Anda
Jangan hanya menggunakan metrik Pub/Sub untuk melakukan penskalaan otomatis pada pipeline Anda. 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 sedang menangani pekerjaan dan apakah penskalaan dapat memungkinkan tugas klien menangani lebih banyak pekerjaan. Berikut beberapa contoh sinyal dari produk Cloud lain yang dapat Anda gunakan untuk pipeline:
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 pemakaian CPU, lihat Menskalakan berdasarkan pemakaian 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. Solusi ini juga mendukung beberapa sinyal.
Untuk mengetahui informasi selengkapnya, lihat Penskalaan otomatis Pod horizontal.
Gunakan metrik versi regional, bukan versi global
Pub/Sub menawarkan dua versi setiap metrik yang biasanya digunakan dengan penskalaan otomatis. Pastikan Anda menggunakan versi dengan akhiran by_region:
Jangan gunakan versi global dari 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, metrik versi by_region menghitung dan melaporkan backlog berdasarkan per region. Jika backlog tidak dapat dihitung untuk satu wilayah, metrik tetap melaporkan nilai untuk wilayah lain.
Hindari 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 merepresentasikan jumlah traffic antara Pub/Sub dan pelanggan. Penskalaan berdasarkan metrik tersebut dapat membuat loop self-referential di mana penurunan pesan yang dikirim atau dikonfirmasi 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 melakukan penskalaan ke nol atau mendekati nol, semua traffic berlangganan yang sedang berlangsung dapat berhenti, dan pelanggan mungkin tidak dapat memproses pesan, meskipun pesan baru tiba. Hal ini dapat menyebabkan jeda penyerapan yang signifikan dan menyebabkan status yang tidak dapat dipulihkan untuk klien subscriber Anda.
Menangani kesenjangan metrik saat terjadi
Jangan berasumsi bahwa tidak adanya metrik berarti tidak ada pesan yang perlu diproses. Misalnya, jika sebagai respons terhadap metrik yang hilang, Anda mengurangi skala tugas pemrosesan menjadi 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 yang lebih besar dari nol sehingga Anda selalu siap menangani pesan yang dipublikasikan, meskipun metrik Pub/Sub terbaru menunjukkan antrean kosong.
Penskala otomatis 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 alur Pub/Sub untuk membantu mencegah tugas menjadi kewalahan jika tidak sengaja diturunkan skalanya karena metrik tidak ada.