Masalah dan batasan

Cloud Tasks memungkinkan Anda membangun sistem asinkron yang tangguh saat Anda mendesain perilaku eksekusi antrean dan batas layanan tertentu. Anda dapat mencegah bottleneck pemrosesan dan penundaan yang tidak terduga dengan memperhitungkan pengiriman minimal sekali, throttling sistem, dan kapasitas resource target.

Urutan eksekusi

Kecuali untuk tugas yang dijadwalkan untuk dijalankan di masa mendatang, task queue sepenuhnya tidak bergantung pada platform terkait urutan eksekusi. Tidak ada jaminan atau upaya terbaik yang dilakukan untuk menjalankan tugas dalam urutan tertentu. Secara khusus: tidak ada jaminan bahwa tugas lama akan dijalankan kecuali jika antrean benar-benar dikosongkan. Ada sejumlah kasus umum saat tugas yang lebih baru dijalankan lebih cepat daripada tugas yang lebih lama, dan pola seputar hal ini dapat berubah tanpa pemberitahuan.

Penundaan eksekusi

Eksekusi Cloud Tasks terkadang mungkin mengalami sedikit penundaan, yang biasanya berlangsung beberapa menit, karena mulai ulang sistem internal. Tugas tertunda, tetapi tidak ada tugas yang hilang. Peristiwa ini adalah peristiwa tingkat sistem tanpa solusi. Peristiwa ini tidak dicatat dalam log, dan kemunculannya tidak memiliki linimasa yang ditetapkan.

Eksekusi duplikat

Cloud Tasks bertujuan untuk semantik "eksekusi tepat satu kali" yang ketat. Namun, dalam situasi ketika kompromi desain harus dibuat antara eksekusi yang dijamin dan eksekusi duplikat, layanan akan memilih eksekusi yang dijamin. Oleh karena itu, sejumlah eksekusi duplikat yang bukan nol akan terjadi. Pastikan aplikasi Anda menangani eksekusi duplikat dengan baik agar tidak menyebabkan kegagalan yang tidak terduga. Dalam produksi, lebih dari 99,999% tugas hanya dijalankan sekali.

Keterbatasan resource

Sumber backlog yang paling umum dalam antrean pemrosesan langsung adalah kehabisan resource pada instance target. Jika Anda mencoba menjalankan 100 tugas per detik pada frontend instance yang hanya dapat memproses 10 permintaan per detik, backlog akan terbentuk. Hal ini biasanya muncul dalam salah satu dari dua cara, yang umumnya dapat diselesaikan dengan meningkatkan jumlah permintaan pemrosesan instance.

Error backoff dan tarif yang diterapkan

Server yang kelebihan beban dapat mulai menampilkan error backoff: HTTP 503 (untuk target App Engine), atau HTTP 429 atau 5xx (untuk target eksternal). Cloud Tasks bereaksi terhadap error ini dengan memperlambat eksekusi hingga error berhenti. Throttling sistem ini mencegah worker mengalami kelebihan beban. Setelan Anda tidak diubah.

Throttling sistem terjadi dalam situasi berikut:

• Cloud Tasks akan melakukan backoff pada semua error. Biasanya, Cloud Tasks menggunakan backoff yang ditentukan dalam retry_config. Namun, jika worker menampilkan respons error HTTP 429 Too Many Requests, 503 Service Unavailable, atau 5xx, atau jika tingkat error tinggi, Cloud Tasks akan menerapkan tingkat pengiriman yang lebih rendah dan mempertimbangkan jeda percobaan ulang yang ditentukan dalam header respons HTTP Retry-After. Setelah error berhenti dan pengendali target menampilkan respons HTTP 2xx, antrean akan secara bertahap meningkatkan kembali kecepatan pengiriman yang diterapkan.

• Untuk mencegah lonjakan traffic dan memperlancar peningkatan beban yang tiba-tiba, Cloud Tasks secara bertahap meningkatkan pengiriman saat antrean baru dibuat, dilanjutkan setelah dijeda, atau tidak aktif bahkan setelah beberapa menit tanpa pengiriman aktif. Peningkatan ini juga terjadi saat sejumlah besar tugas tiba-tiba tersedia untuk dikirim, seperti selama lonjakan pembuatan tugas atau saat banyak tugas dijadwalkan untuk waktu yang sama. Dari status cold atau tidak ada aktivitas, Cloud Tasks mulai mengirimkan pada tingkat dasar yang rendah dan secara progresif meningkatkan tingkat pengiriman yang diterapkan di seluruh interval evaluasi berkala. Kecepatan akan terus meningkat menuju kecepatan max_dispatches_per_second yang Anda konfigurasi selama permintaan antrean tetap jenuh dan pengendali target menampilkan respons HTTP 2xx. Untuk mengetahui informasi selengkapnya tentang peningkatan cold atau idle dan mengelola antrean yang dilanjutkan, lihat Peningkatan antrean awal dan Kelebihan beban target.

Lonjakan latensi dan serentak maksimum

Server yang kelebihan beban juga dapat merespons dengan peningkatan latensi yang besar. Dalam situasi ini, permintaan akan tetap terbuka lebih lama. Karena antrean berjalan dengan jumlah tugas serentak maksimum, hal ini dapat menyebabkan antrean tidak dapat menjalankan tugas pada tingkat yang diharapkan. Meningkatkan nilai max_concurrent_dispatches untuk antrean yang terpengaruh dapat membantu dalam situasi saat nilai telah ditetapkan terlalu rendah, sehingga menyebabkan pembatasan kapasitas buatan. Namun, meningkatkan max_concurrent_dispatches kemungkinan tidak akan mengurangi tekanan resource yang mendasarinya.

Masalah peningkatan skala dengan tugas yang berjalan lama

Antrean Cloud Tasks meningkatkan outputnya sebagian berdasarkan jumlah tugas yang berhasil dikirim sebelumnya. Jika pengendali tugas memerlukan waktu yang cukup lama—dalam hitungan menit—untuk menyelesaikan tugas dan menampilkan respons berhasil, mungkin akan ada jeda dalam tingkat peningkatan antrean.

Melihat lebih dari 5.000 tugas

Jika Anda memiliki lebih dari 5.000 tugas, beberapa tugas tidak akan terlihat di konsolGoogle Cloud . Gunakan gcloud CLI untuk melihat semua tugas.

Metrik kedalaman antrean maksimum yang dilaporkan

Metrik kedalaman antrean maksimum yang dilaporkan oleh Cloud Tasks dibatasi hingga 1.000.000 tugas. Hal ini dimaksudkan untuk meningkatkan performa worker tugas yang mendasarinya dan tidak ada dampak terhadap jumlah tugas yang dapat dikirim ke atau diproses oleh antrean Anda. Tugas yang dikirim ke antrean di atas batas kedalaman antrean akan terus dijalankan sebagaimana mestinya.

Untuk mengambil kedalaman antrean saat ini di atas 1.000.000 tugas, Anda dapat menggunakan metode queues.tasks.list. Metode ini menampilkan semua tugas dengan penomoran halaman, sehingga Anda dapat menggabungkan data, dan melakukan operasi penghitungan. Namun, bergantung pada ukuran kedalaman antrean, metode ini mungkin mengalami batasan kuota.

Membuat ulang antrean dengan nama yang sama

Menghapus antrean akan menghapus semua tugas dalam antrean secara permanen dan tidak dapat diubah, termasuk tugas terjadwal dan tugas yang menunggu untuk dieksekusi atau dicoba ulang. Baik Anda maupun Cloud Customer Care tidak dapat memulihkan antrean atau tugas yang dihapus.

Setelah menghapus antrean, Anda harus menunggu 3 hari sebelum membuat ulang dengan nama yang sama. Periode tunggu ini mencegah perilaku yang tidak terduga dalam tugas yang sedang dieksekusi pada saat penghapusan dan menghindari kegagalan proses internal selama siklus penghapusan dan pembuatan ulang. Periode tunggu berlaku untuk antrean yang dihapus melalui antarmuka apa pun, termasuk konsol Google Cloud , gcloud CLI, REST atau RPC API, atau Terraform.

Selama periode tombstone hingga 3 hari ini, permintaan pembuatan antrean mungkin tampak berhasil tanpa membuat ulang antrean, dan mengupload file queue.yaml yang menyertakan nama antrean yang dihapus mungkin gagal. Untuk mengonfirmasi bahwa antrean dengan nama yang sama telah dibuat ulang, ambil antrean menggunakan perintah gcloud tasks queues describe atau metode projects.locations.queues.get. Respons yang berhasil (200 OK) mengonfirmasi bahwa antrean telah dibuat ulang.

Untuk menghapus tugas atau mengubah antrean tanpa kehilangan antrean atau memicu masa tunggu 3 hari, hapus permanen semua tugas dari antrean, perbarui antrean di tempat, atau jeda antrean, bukan menghapus dan membuatnya kembali. Jika Anda mengelola antrean dengan Terraform, tetapkan prevent_destroy = true di blok lifecycle untuk mencegah penghapusan antrean yang tidak disengaja.

Target yang tidak didukung saat menggunakan perimeter aman

Jika Anda telah menyiapkan perimeter aman menggunakan Kontrol Layanan VPC, permintaan HTTP dari eksekusi Cloud Tasks akan diblokir untuk target yang tidak didukung, dan gagal dengan kode error TARGET_TYPE_NOT_PERMITTED_FOR_VPC. Untuk mengetahui informasi selengkapnya, lihat Menyiapkan perimeter layanan menggunakan Kontrol Layanan VPC.

Batasan lokasi resource

Cloud Tasks mendukung pembatasan lokasi resource; namun, batasan berlaku untuk region berikut:

• us-central1
• us-central2 (region Google Cloud pribadi)

Jika Anda menentukan salah satu region dalam kebijakan organisasi, Anda harus menyertakan us-central1 dan us-central2, meskipun Anda tidak membuat resource Cloud Tasks di kedua region tersebut. Anda dapat menyertakan region us-central2 dalam kebijakan organisasi meskipun organisasi Anda tidak menggunakan region pribadi.