Mengelola risiko penskalaan

Cloud Tasks memungkinkan Anda mengirim tugas asinkron dalam jumlah besar sekaligus mengontrol kecepatan traffic mencapai antrean dan layanan downstream. Dengan menerapkan pola peningkatan bertahap dan kontrol kapasitas, Anda dapat menskalakan workload dengan lancar tanpa memicu lonjakan latensi antrean atau kelebihan beban target saat traffic meningkat lebih cepat daripada kemampuan infrastruktur untuk beradaptasi.

Ringkasan

Dokumen ini memberikan panduan tentang praktik terbaik untuk mempertahankan performa Cloud Tasks yang tinggi dalam antrean traffic tinggi. Antrean TPS tinggi adalah antrean yang memiliki 500 tugas yang dibuat atau dikirim per detik (TPS) atau lebih. Grup antrean TPS tinggi adalah kumpulan antrean yang berdekatan, misalnya [queue0001, queue0002, …, queue0099], yang memiliki setidaknya 2.000 tugas yang dibuat atau dikirim per detik secara total. Anda dapat melihat TPS historis antrean atau grup antrean menggunakan metrik Cloud Monitoring, api/request_count untuk operasi CreateTask, dan queue/task_attempt_count untuk upaya tugas. Antrean dan grup antrean dengan traffic tinggi rentan terhadap dua class kegagalan yang berbeda:

Kelebihan beban antrean terjadi saat pembuatan dan pengiriman tugas ke antrean atau grup antrean tertentu meningkat lebih cepat daripada kemampuan infrastruktur antrean untuk beradaptasi. Infrastruktur Google menggunakan lapisan adaptif yang secara dinamis mengalokasikan ulang beban berdasarkan pola traffic, dan adaptasi ini memerlukan waktu. Demikian pula, kelebihan beban target terjadi saat tingkat pengiriman tugas menyebabkan lonjakan traffic di infrastruktur target downstream. Dalam kedua kasus tersebut, ikuti pola 500/50/5: saat menskalakan melebihi 500 TPS, tingkatkan traffic tidak lebih dari 50% setiap 5 menit.

Terlepas dari pola 500/50/5 untuk workload TPS tinggi, peningkatan antrean awal memengaruhi semua antrean saat dimulai dari status cold atau tidak ada aktivitas, termasuk antrean yang dikonfigurasi untuk tingkat pengiriman sedang. Dokumen ini mengulas berbagai skenario yang dapat menimbulkan risiko penskalaan dan memberikan contoh cara mengelola peningkatan antrean dan menerapkan pola 500/50/5.

Peningkatan antrean awal

Pola 500/50/5 berlaku untuk antrean TPS tinggi yang sudah beroperasi dalam status stabil. Peningkatan antrean awal adalah mekanisme sistem terpisah yang berlaku untuk semua antrean, termasuk antrean yang dikonfigurasi untuk tingkat pengiriman sedang seperti 20-100 TPS, saat bertransisi dari status dingin atau tidak ada aktivitas ke operasi status stabil.

Antrean memasuki status dingin atau tidak ada aktivitas dalam salah satu situasi berikut:

  • Antrean baru dibuat atau dilanjutkan setelah dijeda.

  • Antrean tidak aktif bahkan selama beberapa menit tanpa pengiriman aktif.

  • Antrean sedang dipulihkan setelah mundur dari respons error HTTP 429 atau 5xx downstream. Untuk mengetahui informasi selengkapnya tentang pengaruh backoff error terhadap rasio pengiriman, lihat Error backoff dan rasio yang diterapkan.

Saat tugas tiba di antrean yang dingin atau tidak ada aktivitas, Cloud Tasks tidak akan langsung mengirimkan tugas pada tingkat max_dispatches_per_second yang dikonfigurasi. Untuk melindungi target downstream dari lonjakan traffic yang tiba-tiba, Cloud Tasks mulai mengirimkan tugas dengan kecepatan dasar yang rendah, seperti sekitar 1 TPS. Kemudian, sistem akan meningkatkan rasio pengiriman yang diterapkan secara progresif di seluruh interval evaluasi berkala. Kecepatan yang diterapkan akan terus meningkat selama permintaan antrean tetap jenuh dan pengendali target menampilkan respons HTTP 2xx. Bergantung pada target kapasitas Anda, mencapai nilai max_dispatches_per_second yang tinggi dapat memerlukan waktu beberapa menit.

Jika workload Anda mengirimkan traffic yang tidak stabil dan dipisahkan oleh periode tidak ada aktivitas singkat selama beberapa menit atau lebih, antrean akan direset ke status dingin di antara burst dan mengulangi proses peningkatan ini pada setiap burst. Untuk meminimalkan penundaan peningkatan skala untuk workload yang sensitif terhadap burst, ikuti praktik terbaik berikut:

  • Pertahankan aliran traffic dasar yang stabil untuk menjaga antrean yang sensitif terhadap latensi tetap aktif di antara lonjakan.

  • Gunakan kembali antrean yang ada, daripada sering menghapus dan membuat ulang antrean.

  • Sediakan kapasitas target downstream yang memadai agar pengendali menampilkan respons HTTP 2xx dan menghindari menampilkan respons error HTTP 429 atau 5xx yang mereset kapasitas pengiriman yang diterapkan.

Mendiagnosis throttling antrean

Jika antrean Anda mengirimkan tugas lebih lambat dari tingkat max_dispatches_per_second yang dikonfigurasi, periksa apakah bottleneck berasal dari peningkatan antrean cold atau tidak ada aktivitas, backoff kemacetan target, atau batas konkurensi.

Peningkatan antrean dingin atau tidak ada aktivitas

Peningkatan antrean awal kemungkinan adalah penyebabnya jika semua kondisi berikut berlaku:

  • Antrean baru saja dibuat, dilanjutkan setelah dijeda, atau tidak ada aktivitas selama beberapa menit sebelum traffic tiba.
  • Upaya tugas berhasil tanpa error target, yang menampilkan response_code="OK" dalam metrik Monitoring cloudtasks.googleapis.com/queue/task_attempt_count.
  • Pengiriman dalam proses tetap berada di bawah max_concurrent_dispatches, sementara cloudtasks.googleapis.com/queue/depth atau cloudtasks.googleapis.com/queue/task_attempt_delays ditingkatkan. Pada saat yang sama, tingkat pengiriman di cloudtasks.googleapis.com/queue/task_attempt_count meningkat secara progresif di seluruh interval evaluasi berkala.

Untuk mengetahui informasi selengkapnya tentang metrik Monitoring, lihat Mengirim metrik ke Monitoring.

Backoff kemacetan dan kelebihan beban target

Cloud Tasks secara dinamis mengurangi tingkat pengiriman jika target downstream Anda menampilkan respons error HTTP 429 Too Many Requests atau HTTP 5xx, seperti HTTP 503 Service Unavailable. Backoff kemacetan ini mencegah kelebihan beban target.

Untuk memeriksa apakah error target menyebabkan Cloud Tasks membatasi pengiriman, lihat metrik Monitoring cloudtasks.googleapis.com/queue/task_attempt_count yang dikelompokkan menurut label response_code. Jika logging antrean diaktifkan, Anda juga dapat memeriksa log respons percobaan di Logs Explorer:

resource.type="cloud_tasks_queue"
jsonPayload.attemptResponseLog.status!="OK"

Di response_code dan jsonPayload.attemptResponseLog.status, Cloud Tasks mencatat kode status gRPC kanonis, bukan kode status HTTP numerik. Misalnya, HTTP 429 dipetakan ke RESOURCE_EXHAUSTED, HTTP 503 dipetakan ke UNAVAILABLE, HTTP 500 dipetakan ke INTERNAL, dan HTTP 504 atau waktu tunggu dipetakan ke DEADLINE_EXCEEDED.

Jika Anda mengamati status error server RESOURCE_EXHAUSTED, UNAVAILABLE, atau lainnya dari target, skalakan instance layanan target atau tingkatkan konkurensi target sebelum meningkatkan batas pengiriman antrean.

Untuk mengetahui informasi selengkapnya tentang cara mengaktifkan log antrean, lihat Menggunakan Cloud Logging dengan antrean.

Bottleneck konkurensi

Menurut hukum Little, latensi target downstream membatasi throughput pengiriman maksimum Anda:

Max Throughput (tasks/sec) = min(
  max_dispatches_per_second,
  max_concurrent_dispatches / Downstream Latency in seconds
)

Misalnya, jika latensi eksekusi downstream adalah 2 detik dan max_concurrent_dispatches ditetapkan ke 100, throughput dibatasi hingga 50 tugas per detik, meskipun max_dispatches_per_second dikonfigurasi ke 500.

Untuk mendiagnosis apakah konkurensi adalah bottleneck, bagi max_concurrent_dispatches dengan latensi respons target yang dicatat dalam kolom jsonPayload.attemptResponseLog.attemptDuration di Logging. Bandingkan nilai minimum yang dihitung ini dengan tingkat pengiriman sebenarnya dalam metrik Monitoring cloudtasks.googleapis.com/queue/task_attempt_count. Jika pengiriman aktual mencapai batas di dekat nilai minimum ini sementara cloudtasks.googleapis.com/queue/depth atau cloudtasks.googleapis.com/queue/task_attempt_delays bertambah, lakukan salah satu tindakan berikut:

  • Jika target downstream Anda memiliki kapasitas cadangan, seperti saat tugas menghabiskan sebagian besar durasinya untuk menunggu I/O eksternal, tingkatkan max_concurrent_dispatches.
  • Jika target downstream Anda sudah menggunakan resource yang tinggi, meningkatkan max_concurrent_dispatches dapat memperburuk kelebihan beban target. Sebagai gantinya, lakukan penyebaran skala instance target atau kurangi latensi eksekusi pengendali.

Kelebihan beban antrean

Antrean atau grup antrean dapat kelebihan beban kapan saja saat traffic meningkat tiba-tiba. Akibatnya, antrean ini dapat mengalami:

  • Peningkatan latensi pembuatan tugas
  • Peningkatan rasio error pembuatan tugas
  • Pengurangan frekuensi pengiriman

Untuk mencegah hal ini, buat kontrol dalam situasi apa pun saat tingkat pembuatan atau pengiriman antrean atau grup antrean dapat melonjak secara tiba-tiba. Mulailah dengan maksimum 500 operasi per detik ke antrean atau grup antrean yang tidak aktif, lalu tingkatkan traffic sebesar 50% setiap 5 menit. Secara teori, Anda dapat meningkatkan hingga 740 ribu operasi per detik setelah 90 menit menggunakan jadwal peningkatan ini. Ada sejumlah keadaan yang dapat menyebabkan hal ini terjadi.

Contoh:

  • Meluncurkan fitur baru yang sangat memanfaatkan Cloud Tasks
  • Memindahkan traffic antar-antrean
  • Menyeimbangkan kembali traffic di lebih banyak atau lebih sedikit antrean
  • Menjalankan tugas batch yang memasukkan tugas dalam jumlah besar

Dalam kasus ini dan kasus lainnya, ikuti pola 500/50/5.

Menggunakan pemisahan traffic App Engine

Jika aplikasi App Engine membuat tugas, Anda dapat memanfaatkan pemisahan traffic App Engine (lingkungan standar App Engine atau lingkungan fleksibel App Engine) untuk memperlancar peningkatan traffic. Dengan membagi traffic antar-versi (lingkungan standar atau lingkungan fleksibel), Anda dapat meningkatkan permintaan yang dikelola kapasitasnya dari waktu ke waktu untuk melindungi kondisi antrean. Sebagai contoh, pertimbangkan kasus peningkatan traffic ke grup antrean yang baru diperluas: biarkan [queue0000, queue0199] menjadi urutan antrean TPS tinggi yang menerima total 100.000 pembuatan TPS pada puncaknya.

Misalkan [queue0200, queue0399] adalah urutan antrean baru. Setelah Anda mengalihkan semua traffic, jumlah antrean dalam urutan akan berlipat ganda dan rentang antrean baru akan menerima 50% dari total traffic urutan.

Saat men-deploy versi yang meningkatkan jumlah antrean, tingkatkan traffic secara bertahap ke versi baru, dan dengan demikian antrean baru, menggunakan pemisahan traffic:

  • Mulai alihkan 1% traffic ke rilis baru. Misalnya, 50% dari 1% dari 100.000 TPS menghasilkan 500 TPS ke kumpulan antrean baru.
  • Setiap 5 menit, tingkatkan traffic yang dikirim ke rilis baru sebesar 50%, seperti yang dijelaskan dalam tabel berikut:
Menit sejak awal deployment % dari total traffic yang dialihkan ke versi baru % dari total traffic ke antrean baru % dari total traffic ke antrean lama
0 1.0 0,5 99,5
5 1,5 0,75 99,25
10 2.3 1,15 98,85
15 3.4 1,7 98,3
20 5.1 2,55 97,45
25 7.6 3.8 96,2
30 11.4 5.7 94,3
35 17,1 8,55 91,45
40 25,6 12,8 87,2
45 38,4 19,2 80,8
50 57,7 28,85 71,15
55 86,5 43,25 56,75
60 100 50 50

Lonjakan traffic yang didorong oleh rilis

Saat meluncurkan rilis yang meningkatkan traffic secara signifikan ke antrean atau grup antrean, peluncuran bertahap, sekali lagi, merupakan mekanisme penting untuk memperlancar peningkatan. Luncurkan instance Anda secara bertahap sehingga peluncuran awal tidak melebihi total 500 operasi per detik ke antrean baru, dengan peningkatan tidak lebih dari 50% setiap 5 menit.

Antrean atau grup antrean TPS tinggi yang baru

Antrean yang baru dibuat sangat rentan. Grup antrean, misalnya [queue0000, queue0001, …, queue0199], sama sensitifnya dengan antrean tunggal selama tahap peluncuran awal. Untuk antrean ini, peluncuran bertahap adalah strategi yang penting. Luncurkan layanan baru atau yang telah diupdate yang membuat antrean atau grup antrean dengan TPS tinggi secara bertahap. Pertahankan beban awal di bawah 500 TPS, dan lakukan peningkatan bertahap sebesar 50% atau kurang dengan interval minimal 5 menit.

Grup antrean yang baru diperluas

Saat meningkatkan total kapasitas grup antrean, misalnya memperluas [queue0000-queue0199 menjadi queue0000-queue0399], ikuti pola 500/50/5. Untuk prosedur peluncuran, grup antrean baru berperilaku sama seperti antrean individual. Terapkan pola 500/50/5 ke grup baru secara keseluruhan, bukan hanya ke antrean individual dalam grup.

Untuk perluasan grup antrean ini, peluncuran bertahap adalah strategi yang penting. Jika sumber traffic Anda adalah App Engine, Anda dapat menggunakan pemisahan traffic. Saat memigrasikan layanan untuk menambahkan tugas ke jumlah antrean yang meningkat, luncurkan instance secara bertahap sehingga peluncuran awal tidak melebihi total 500 operasi ke antrean baru, dan tingkatkan traffic tidak lebih dari 50% setiap 5 menit.

Perluasan grup antrean darurat

Terkadang, Anda mungkin ingin memperluas grup antrean yang ada, misalnya karena Anda memperkirakan tugas akan ditambahkan ke grup antrean lebih cepat daripada yang dapat dikirim oleh grup. Jika Anda mendistribusikan nama antrean baru secara merata di antara nama antrean yang ada dalam urutan leksikografis, Anda dapat langsung mengirim traffic ke antrean tersebut. Pastikan tidak ada lebih dari 50% antrean baru yang disisipkan dan traffic ke setiap antrean kurang dari 500 TPS. Metode ini adalah alternatif untuk menggunakan pemisahan traffic dan peluncuran bertahap.

Untuk mendapatkan jenis penamaan yang disisipkan ini, tambahkan akhiran ke antrean yang diakhiri dengan angka genap. Misalnya, jika Anda memiliki 200 antrean yang sudah ada [queue0000-queue0199] dan ingin membuat 100 antrean baru, pilih [queue0000a, queue0002a, queue0004a, …, queue0198a] sebagai nama antrean baru, bukan [queue0200-queue0299].

Jika memerlukan peningkatan lebih lanjut, Anda masih dapat menyisipkan hingga 50% lebih banyak antrean setiap 5 menit.

Enqueue tugas batch atau berskala besar

Saat Anda perlu menambahkan tugas dalam jumlah besar, misalnya jutaan atau miliaran, pola injeksi ganda dapat berguna. Daripada membuat tugas dari satu tugas, gunakan antrean injektor. Setiap tugas yang ditambahkan ke antrean injektor akan di-fan out dan menambahkan 100 tugas ke antrean atau grup antrean yang relevan. Anda dapat mempercepat antrean injektor seiring waktu—misalnya, mulai dari 5 TPS untuk menghasilkan 500 TPS di antrean target atau grup antrean, lalu tingkatkan kecepatannya sebesar 50% setiap 5 menit.

Tugas bernama

Saat Anda membuat tugas baru, Cloud Tasks akan menetapkan nama yang unik pada tugas tersebut secara default. Anda dapat menetapkan nama Anda sendiri untuk tugas menggunakan parameter name. Namun, hal ini menimbulkan beban performa yang signifikan, sehingga mengakibatkan peningkatan latensi dan berpotensi meningkatkan tingkat error yang terkait dengan tugas bernama. Nama tugas berurutan, seperti stempel waktu, dapat meningkatkan overhead ini secara signifikan.

Jika Anda menetapkan nama Anda sendiri, gunakan imbuhan yang didistribusikan dengan baik untuk nama tugas, seperti hash konten. Untuk mengetahui informasi selengkapnya tentang penamaan tugas, lihat referensi kolom Task.name.

Target overload

Cloud Tasks dapat membebani layanan dan resource downstream yang Anda gunakan, seperti App Engine, Firestore dalam mode Datastore (Datastore), dan jaringan Anda, jika pengiriman antrean tiba-tiba melonjak. Jika backlog tugas telah menumpuk, melanjutkan antrean tersebut berpotensi membebani layanan ini secara berlebihan. Untuk melindungi dari kelebihan beban target, ikuti pola 500/50/5: jika antrean mengirimkan lebih dari 500 TPS, tingkatkan traffic yang dipicu oleh antrean tidak lebih dari 50% setiap 5 menit. Untuk memantau peningkatan traffic secara proaktif, gunakan metrik Monitoring. Anda dapat menggunakan pemberitahuan Monitoring untuk mendeteksi situasi yang berpotensi berbahaya.

Melanjutkan antrean TPS tinggi

Saat Anda melanjutkan antrean yang dijeda, Cloud Tasks akan menerapkan peningkatan antrean awal dan secara bertahap meningkatkan tingkat pengiriman dari baseline rendah ke tingkat max_dispatches_per_second yang dikonfigurasi antrean. Namun, jika backlog tugas yang besar menumpuk dalam antrean TPS tinggi atau di beberapa antrean yang Anda lanjutkan secara bersamaan, kecepatan pengiriman masih dapat meningkat lebih cepat daripada kemampuan layanan target downstream untuk melakukan penskalaan. Untuk mencegah kelebihan beban target saat melanjutkan antrean dengan backlog yang besar, lakukan secara bertahap saat Anda melanjutkan beberapa antrean. Atau, turunkan sementara rasio max_dispatches_per_second dan tingkatkan secara bertahap dengan mengikuti pola 500/50/5. Untuk mengetahui informasi selengkapnya tentang cara Cloud Tasks membatasi dan meningkatkan pengiriman saat antrean dilanjutkan, lihat Error backoff dan tarif yang diterapkan.

Tugas terjadwal massal

Sejumlah besar tugas yang dijadwalkan untuk dikirim secara bersamaan juga dapat menimbulkan risiko kelebihan beban target. Jika Anda perlu memulai banyak tugas sekaligus, pertimbangkan untuk menggunakan kontrol kapasitas antrean untuk meningkatkan kapasitas pengiriman secara bertahap atau menyediakan kapasitas target terlebih dahulu.

Peningkatan fan-out

Saat mengupdate layanan yang dipanggil Cloud Tasks, meningkatkan jumlah panggilan jarak jauh dapat menimbulkan risiko produksi. Misalnya, tugas dalam antrean TPS tinggi memanggil pengendali /task-foo. Rilis baru dapat meningkatkan biaya panggilan /task-foo secara signifikan jika, misalnya, rilis baru tersebut menambahkan beberapa panggilan Datastore yang mahal ke pengendali. Hasil akhir dari rilis semacam ini adalah peningkatan besar-besaran dalam traffic Datastore yang langsung terkait dengan perubahan traffic pengguna. Gunakan peluncuran bertahap atau pemisahan traffic untuk mengelola peningkatan.

Upaya coba lagi

Kode Anda dapat mencoba ulang saat terjadi kegagalan saat melakukan panggilan Cloud Tasks API. Namun, jika sebagian besar permintaan gagal karena error sisi server, rasio percobaan ulang yang tinggi dapat membebani antrean Anda lebih lanjut dan memperlambat pemulihan. Batasi jumlah traffic keluar jika klien Anda mendeteksi bahwa sebagian besar permintaan gagal karena error sisi server. Misalnya, Anda dapat menggunakan algoritma Throttling Adaptif yang dijelaskan dalam bab Menangani Overload di buku Site Reliability Engineering. Library klien gRPC Google menerapkan variasi algoritma ini.