Infrastruktur Google dirancang untuk beroperasi secara elastis pada skala tinggi: 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 memungkinkan pengiriman volume traffic yang sangat tinggi, Cloud Tasks mengekspos risiko produksi dalam situasi di mana traffic dapat meningkat lebih cepat daripada yang dapat diadaptasikan infrastruktur.
Ringkasan
Dokumen ini memberikan panduan tentang praktik terbaik untuk mempertahankan performa Cloud Tasks yang tinggi dalam antrean dengan traffic yang tinggi. Antrean TPS tinggi adalah antrean yang berisi 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 secara total memiliki setidaknya 2.000 tugas yang dibuat atau dikirim. TPS historis dari antrean atau grup antrean dapat dilihat menggunakan metrik Stackdriver, api/request_count untuk operasi "CreateTask", dan queue/task_attempt_count untuk percobaan tugas. Antrean dengan traffic tinggi dan grup antrean rentan terhadap dua kelas luas yang berbeda:
Kelebihan antrean terjadi saat pembuatan dan pengiriman tugas ke masing-masing antrean atau grup antrean meningkat lebih cepat daripada yang dapat diadaptasi oleh infrastruktur antrean. Demikian pula, overload target terjadi saat tingkat pengiriman tugas menyebabkan lonjakan traffic di infrastruktur target downstream. Dalam kedua kasus tersebut, sebaiknya ikuti pola 500/50/5: saat menskalakan di atas 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.
Antrean berlebih
Antrean atau grup antrean dapat kelebihan beban setiap kali traffic meningkat secara tiba-tiba. Akibatnya, antrean ini dapat mengalami:
- Peningkatan latensi pembuatan tugas
- Peningkatan tingkat error pembuatan tugas
- Mengurangi rasio pengiriman
Untuk melindunginya, sebaiknya buat kontrol dalam situasi apa pun ketika tingkat pembuatan atau pengiriman grup antrean atau antrean dapat melonjak tiba-tiba. Sebaiknya gunakan maksimum 500 operasi per detik ke grup cold queue atau antrean, lalu meningkatkan traffic sebesar 50% setiap 5 menit. Secara teori, Anda dapat berkembang menjadi 740 ribu operasi per detik setelah 90 menit menggunakan jadwal peningkatan ini. Ada sejumlah situasi di mana hal ini dapat 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 memasukkan tugas dalam jumlah besar
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 (Standar/Flex) untuk peningkatan traffic yang lancar. Dengan membagi traffic antar-versi (Standard/Flex), permintaan yang perlu dikelola tarif dapat dijalankan seiring waktu untuk melindungi kondisi antrean. Sebagai contoh, pertimbangkan kasus memutar traffic ke grup antrean yang baru diperluas: Misalkan [queue0000, queue0199] adalah urutan antrean TPS tinggi yang menerima total 100.000 TPS pada puncaknya.
Misalkan [queue0200, queue0399] adalah urutan antrean baru. Setelah semua traffic diubah, jumlah antrean dalam urutan menjadi dua kali lipat dan rentang antrean yang baru menerima 50% dari total traffic urutan.
Saat men-deploy versi yang meningkatkan jumlah antrean, secara bertahap tingkatkan traffic ke versi baru, dan juga antrean baru, menggunakan pemisahan traffic:
- Mulai alihkan 1% traffic ke rilis baru. Misalnya,50% dari 1% dari 100.000 TPS menghasilkan 500 TPS untuk kumpulan antrean baru.
- Setiap 5 menit, tingkatkan traffic yang dikirim ke rilis baru sebesar 50%, seperti yang dijelaskan dalam tabel berikut:
| Menit sejak deployment dimulai | % dari total traffic 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 berbasis rilis
Saat meluncurkan rilis yang meningkatkan traffic secara signifikan ke grup antrean atau antrean, peluncuran bertahap merupakan mekanisme penting untuk memperlancar peningkatan tersebut. Luncurkan instance Anda secara bertahap sehingga peluncuran awal tidak melebihi total 500 operasi ke antrean baru, dan tingkatkan tidak lebih dari 50% setiap 5 menit.
Antrean TPS Tinggi baru atau grup antrean
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 merupakan strategi penting. Meluncurkan layanan baru atau yang diupdate, yang membuat antrean TPS tinggi atau grup antrean, secara bertahap sehingga beban awal di bawah 500 TPS dan peningkatan 50% atau kurang dilakukan secara bertahap 5 menit atau lebih.
Grup antrean yang baru diperluas
Saat meningkatkan total kapasitas grup antrean, misalnya memperluas [queue0000-queue0199 ke queue0000-queue0399], ikuti pola 500/50/5. Penting untuk diperhatikan bahwa untuk prosedur peluncuran, grup antrean baru berperilaku tidak berbeda dengan antrean individual. Terapkan pola 500/50/5 ke grup baru secara keseluruhan, bukan hanya pada antrean individual dalam grup. Untuk ekspansi grup antrean ini, peluncuran bertahap sekali lagi merupakan strategi penting. Jika sumber traffic adalah App Engine, Anda dapat menggunakan pemisahan traffic (lihat Lonjakan Traffic Berbasis Rilis). Saat memigrasikan layanan Anda untuk menambahkan tugas ke peningkatan jumlah antrean, luncurkan instance secara bertahap sehingga peluncuran awal tidak melebihi total 500 operasi ke antrean baru, yang meningkat 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 ketika diurutkan secara leksikografis, traffic dapat langsung dikirim ke antrean tersebut selama tidak ada lebih dari 50% antrean interleave baru dan traffic ke setiap antrean kurang dari 500 TPS. Metode ini adalah alternatif dari penggunaan pemisahan traffic dan peluncuran bertahap seperti yang dijelaskan di bagian di atas.
Jenis penamaan sisipan ini dapat dicapai dengan menambahkan akhiran ke antrean yang diakhiri dengan bilangan genap. Misalnya, jika Anda memiliki 200 antrean yang ada [queue0000-queue0199] dan ingin membuat 100 antrean baru, pilih [queue0000a, queue0002a, queue0004a, ..., queue0198a] sebagai nama antrean baru 0198a], bukan [queue0000a].
Jika memerlukan peningkatan lebih lanjut, Anda masih dapat menyisipkan hingga 50% antrean lagi setiap 5 menit.
Antrean tugas berskala besar/batch
Jika sejumlah besar tugas, misalnya jutaan atau miliaran, perlu ditambahkan, pola injeksi ganda dapat berguna. Daripada membuat tugas dari satu tugas, gunakan antrean injektor. Setiap tugas yang ditambahkan ke antrean injektor akan menyebar dan menambahkan 100 tugas ke antrean atau grup antrean yang diinginkan. Antrean injektor dapat dipercepat seiring waktu, misalnya mulai pada 5 TPS, lalu meningkat sebesar 50% setiap 5 menit.
Tugas Bernama
Saat Anda membuat tugas baru, Cloud Tasks akan menetapkan nama unik untuk tugas tersebut secara default. Anda bisa menetapkan nama Anda sendiri ke tugas menggunakan parameter name. Namun, hal ini menimbulkan overhead performa yang signifikan, sehingga mengakibatkan peningkatan latensi dan potensi peningkatan rasio error terkait tugas yang diberi nama. Biaya ini dapat diperbesar secara signifikan jika tugas diberi nama secara berurutan, seperti dengan stempel waktu. Jadi, jika Anda menetapkan nama Anda sendiri, sebaiknya gunakan awalan yang didistribusikan dengan baik untuk nama tugas, seperti hash konten. Lihat dokumentasi untuk 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 terakumulasi, membatalkan jeda antrean tersebut dapat berpotensi membebani layanan ini. Pertahanan yang direkomendasikan adalah pola 500/50/5 yang sama dengan pola yang disarankan untuk kelebihan antrean: jika antrean mengirim lebih dari 500 TPS, tingkatkan traffic yang dipicu oleh antrean tidak lebih dari 50% setiap 5 menit. Gunakan metrik Stackdriver untuk memantau peningkatan traffic Anda secara proaktif. Pemberitahuan Stackdriver dapat digunakan untuk mendeteksi situasi yang berpotensi berbahaya.
Menghentikan atau melanjutkan antrean TPS tinggi
Jika antrean atau serangkaian antrean tidak dijeda atau diaktifkan kembali, antrean akan melanjutkan
pengiriman. Jika antrean memiliki banyak tugas, tingkat pengiriman antrean yang baru diaktifkan dapat meningkat secara dramatis dari 0 TPS hingga kapasitas penuh antrean. Untuk mengoptimalkannya, antrean bertahap dilanjutkan atau kontrol kecepatan pengiriman antrean menggunakan maxDispatchesPerSecond Cloud Tasks.
Tugas terjadwal massal
Tugas dalam jumlah besar, yang dijadwalkan untuk dikirimkan pada saat yang sama, juga dapat menimbulkan risiko kelebihan beban target. Jika Anda perlu memulai tugas dalam jumlah besar sekaligus, pertimbangkan untuk menggunakan kontrol kecepatan antrean untuk meningkatkan kecepatan pengiriman secara bertahap atau secara eksplisit mengaktifkan kapasitas target di awal.
Fan-out meningkat
Saat mengupdate layanan yang dijalankan melalui Cloud Tasks, peningkatan jumlah panggilan jarak jauh dapat menimbulkan risiko produksi. Contohnya, tugas dalam antrean TPS tinggi memanggil pengendali /task-foo. Rilis baru dapat meningkatkan biaya panggilan /task-foo secara signifikan jika, misalnya, rilis baru menambahkan beberapa panggilan Datastore yang mahal ke pengendali. Hasil bersih dari rilis tersebut adalah peningkatan besar pada traffic Datastore yang langsung terkait dengan perubahan traffic pengguna. Gunakan peluncuran bertahap atau pemisahan traffic untuk mengelola peningkatan.
Upaya coba lagi
Kode Anda dapat dicoba lagi jika gagal 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 permintaan berjalan lebih lambat. Oleh karena itu, sebaiknya batasi jumlah traffic keluar jika klien Anda mendeteksi bahwa sebagian besar permintaan gagal dengan error sisi server, misalnya menggunakan algoritma Throttling Adaptif yang dijelaskan dalam bab Menangani Kelebihan Beban dalam buku Site Reliablity Engineering. Library klien gRPC Google menerapkan variasi algoritma ini.