Infrastruktur Google dirancang untuk beroperasi secara elastis dalam skala besar: sebagian besar lapisan dapat beradaptasi dengan peningkatan permintaan traffic hingga skala besar. Pola desain inti yang memungkinkan hal ini adalah lapisan adaptif -- komponen infrastruktur yang secara dinamis mengalokasikan ulang beban berdasarkan pola traffic. Namun, adaptasi ini memerlukan waktu. Karena Cloud Tasks memungkinkan pengiriman traffic dengan volume yang sangat tinggi, Cloud Tasks memaparkan risiko produksi dalam situasi ketika traffic dapat meningkat lebih cepat daripada kemampuan adaptasi infrastruktur.
Ringkasan
Dokumen ini memberikan panduan tentang praktik terbaik untuk mempertahankan performa Cloud Tasks yang tinggi dalam antrean dengan 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 sekumpulan antrean yang berdekatan, misalnya [queue0001, queue0002, …, queue0099], yang memiliki total minimal 2.000 tugas yang dibuat atau dikirim. TPS historis antrean atau grup antrean dapat dilihat menggunakan metrik Cloud Monitoring, api/request_count untuk operasi “CreateTask” dan queue/task_attempt_count untuk percobaan tugas. Antrean dan grup antrean dengan traffic tinggi rentan terhadap dua kelas kegagalan yang berbeda:
Overload antrean terjadi saat pembuatan dan pengiriman tugas ke antrean atau grup antrean tertentu meningkat lebih cepat daripada kemampuan infrastruktur antrean untuk beradaptasi. Demikian pula, kelebihan beban target terjadi saat kecepatan pengiriman tugas menyebabkan lonjakan traffic di infrastruktur target hilir. Dalam kedua kasus tersebut, sebaiknya ikuti pola 500/50/5: saat melakukan penskalaan di luar 500 TPS, tingkatkan traffic tidak lebih dari 50% setiap 5 menit. Dokumen ini meninjau berbagai skenario yang dapat menimbulkan risiko penskalaan dan memberikan contoh cara menerapkan pola ini.
Kelebihan beban antrean
Antrean atau grup antrean dapat menjadi kelebihan beban kapan saja saat traffic meningkat secara tiba-tiba. Akibatnya, antrean ini dapat mengalami:
- Peningkatan latensi pembuatan tugas
- Peningkatan rasio error pembuatan tugas
- Rasio pengiriman yang lebih rendah
Untuk mencegah hal ini, sebaiknya tetapkan kontrol dalam situasi apa pun saat kecepatan pembuatan atau pengiriman antrean atau grup antrean dapat meningkat secara tiba-tiba. Sebaiknya gunakan maksimum 500 operasi per detik ke antrean dingin atau grup antrean, lalu tingkatkan traffic sebesar 50% setiap 5 menit. Secara teori, Anda dapat meningkatkan hingga 740 ribu operasi per detik setelah 90 menit menggunakan jadwal kenaikan ini. Ada sejumlah keadaan yang dapat menyebabkan hal ini terjadi.
Contoh:
- Meluncurkan fitur baru yang banyak menggunakan Cloud Tasks
- Memindahkan traffic antar-antrean
- Menyeimbangkan kembali traffic di lebih banyak atau lebih sedikit antrean
- Menjalankan tugas batch yang menyisipkan sejumlah besar tugas
Dalam kasus ini dan lainnya, ikuti pola 500/50/5.
Menggunakan pemisahan traffic App Engine
Jika tugas dibuat oleh aplikasi App Engine, Anda dapat memanfaatkan pembagian traffic App Engine (Standard/Flex) untuk memperlancar peningkatan traffic. Dengan membagi traffic antar-versi (Standar/Flex), permintaan yang perlu dikelola lajunya dapat diluncurkan dari waktu ke waktu untuk melindungi kondisi antrean. Sebagai contoh, pertimbangkan kasus peningkatan traffic ke grup antrean yang baru diperluas: Misalkan [queue0000, queue0199] adalah urutan antrean TPS tinggi yang menerima total 100.000 pembuatan TPS pada puncaknya.
Misalkan [queue0200, queue0399] adalah urutan antrean baru. Setelah semua traffic dialihkan, jumlah antrean dalam urutan telah berlipat ganda dan rentang antrean baru 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 mengalihkan 1% traffic ke rilis baru. Misalnya,50% dari 1% dari 100.000 TPS menghasilkan 500 TPS ke set 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 dipicu rilis
Saat meluncurkan rilis yang secara signifikan meningkatkan traffic ke antrean atau grup antrean, peluncuran bertahap sekali lagi menjadi mekanisme penting untuk memperlancar peningkatan tersebut. Luncurkan instance Anda secara bertahap sehingga peluncuran awal tidak melebihi total 500 operasi ke antrean baru, dengan peningkatan tidak lebih dari 50% setiap 5 menit.
Grup antrean atau antrean High-TPS 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 diupdate, yang membuat antrean atau grup antrean TPS tinggi, secara bertahap sehingga beban awal di bawah 500 TPS dan peningkatan sebesar 50% atau kurang dilakukan secara bertahap dengan selisih 5 menit atau lebih.
Grup antrean yang baru diperluas
Saat meningkatkan total kapasitas grup antrean, misalnya memperluas [queue0000-queue0199 menjadi queue0000-queue0399], ikuti pola 500/50/5. Penting untuk diperhatikan bahwa, untuk prosedur peluncuran, grup antrean baru tidak berperilaku berbeda dengan 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 sekali lagi menjadi strategi yang penting. Jika sumber traffic Anda adalah App Engine, Anda dapat menggunakan pemisahan traffic (lihat Lonjakan Traffic yang Dipicu Rilis). Saat memigrasikan layanan untuk menambahkan tugas ke jumlah antrean yang lebih banyak, luncurkan instance Anda secara bertahap sehingga peluncuran awal tidak melebihi total 500 operasi ke antrean baru, dengan peningkatan tidak lebih dari 50% setiap 5 menit.
Perluasan grup antrean darurat
Terkadang, Anda mungkin ingin memperluas grup antrean yang ada, misalnya karena tugas diharapkan ditambahkan ke grup antrean lebih cepat daripada yang dapat dikirimkan oleh grup. Jika nama antrean baru tersebar secara merata di antara nama antrean yang ada saat diurutkan secara leksikografis, traffic dapat segera dikirim ke antrean tersebut selama tidak ada lebih dari 50% antrean baru yang disisipkan dan traffic ke setiap antrean kurang dari 500 TPS. Metode ini merupakan alternatif untuk menggunakan pemisahan traffic dan peluncuran bertahap seperti yang dijelaskan di bagian di atas.
Jenis penamaan yang diselingi ini dapat dicapai dengan menambahkan 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 Anda memerlukan peningkatan lebih lanjut, Anda tetap dapat menyisipkan hingga 50% lebih banyak antrean setiap 5 menit.
Penjadwalan tugas batch/skala besar
Jika sejumlah besar tugas, misalnya jutaan atau miliaran, perlu ditambahkan, pola injeksi ganda dapat bermanfaat. Daripada membuat tugas dari satu tugas, gunakan antrean injector. Setiap tugas yang ditambahkan ke antrean injector akan didistribusikan dan menambahkan 100 tugas ke antrean atau grup antrean yang diinginkan. Antrean injector dapat dipercepat dari waktu ke waktu, misalnya mulai pada 5 TPS, lalu meningkat 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. Biaya ini dapat meningkat secara signifikan jika tugas diberi nama secara berurutan, seperti dengan stempel waktu. Jadi, jika Anda menetapkan nama Anda sendiri, sebaiknya gunakan imbuhan yang didistribusikan dengan baik untuk nama tugas, seperti hash konten. Lihat dokumentasi untuk mengetahui detail selengkapnya tentang penamaan tugas.
Kelebihan target
Cloud Tasks dapat membebani layanan lain yang Anda gunakan, seperti App Engine, Datastore, dan penggunaan jaringan Anda, jika pengiriman dari antrean meningkat secara drastis dalam waktu singkat. Jika backlog tugas telah menumpuk, maka melanjutkan antrean tersebut berpotensi membebani layanan ini. Pertahanan yang direkomendasikan sama dengan pola 500/50/5 yang disarankan untuk kelebihan beban antrean: 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 Cloud Monitoring. Anda dapat menggunakan pemberitahuan Cloud Monitoring untuk mendeteksi situasi yang berpotensi berbahaya.
Membatalkan jeda atau melanjutkan antrean TPS tinggi
Saat antrean atau rangkaian antrean dilanjutkan atau diaktifkan kembali, antrean akan melanjutkan pengiriman. Jika antrean memiliki banyak tugas, kecepatan pengiriman antrean yang baru diaktifkan
dapat meningkat secara drastis dari 0 TPS menjadi kapasitas penuh antrean. Untuk
meningkatkan, atur jeda dan lanjutkan antrean atau kontrol kecepatan pengiriman antrean menggunakan
maxDispatchesPerSecond Cloud Tasks.
Tugas terjadwal massal
Sejumlah besar tugas yang dijadwalkan untuk dikirim pada saat yang sama juga dapat menimbulkan risiko kelebihan beban target. Jika Anda perlu memulai sejumlah besar tugas sekaligus, pertimbangkan untuk menggunakan kontrol kecepatan antrean untuk meningkatkan kecepatan pengiriman secara bertahap atau secara eksplisit meningkatkan kapasitas target terlebih dahulu.
Peningkatan fan-out
Saat memperbarui layanan yang dijalankan melalui Cloud Tasks, peningkatan jumlah
panggilan jarak jauh dapat menimbulkan risiko produksi. Misalnya, tugas dalam antrean TPS tinggi memanggil pengendali /task-foo. Rilis baru dapat meningkatkan biaya pemanggilan /task-foo secara signifikan jika, misalnya, rilis baru tersebut menambahkan beberapa panggilan Datastore yang mahal ke handler. Hasil
bersih dari rilis tersebut adalah peningkatan besar 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 lagi saat terjadi kegagalan saat melakukan panggilan Cloud Tasks API. Namun, jika sebagian besar permintaan gagal karena error sisi server, tingkat percobaan ulang yang tinggi dapat semakin membebani antrean Anda dan menyebabkan pemulihan yang lebih lambat. Oleh karena itu, sebaiknya batasi jumlah traffic keluar jika klien Anda mendeteksi bahwa sebagian besar permintaan gagal karena error sisi server, misalnya menggunakan algoritma Pembatasan Adaptif yang dijelaskan dalam bab Menangani Kelebihan Beban dalam buku Site Reliability Engineering. Library klien gRPC Google menerapkan variasi algoritma ini.