Infrastruktur Google dirancang untuk beroperasi secara elastis dalam 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 mengalokasikan ulang beban secara dinamis berdasarkan pola traffic. Namun, adaptasi ini memerlukan waktu. Karena Cloud Tasks memungkinkan pengiriman traffic dalam volume yang sangat tinggi, hal ini akan menimbulkan risiko produksi dalam situasi saat 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 traffic tinggi. Antrean TPS tinggi adalah antrean yang memiliki 500 tugas yang dibuat atau dikirimkan per detik (TPS) atau lebih. Grup antrean TPS tinggi adalah kumpulan antrean yang berdekatan, misalnya [queue0001, queue0002, …, queue0099], yang memiliki total setidaknya 2.000 tugas yang dibuat atau dikirim. TPS historis antrean atau grup antrean dapat dilihat menggunakan metrik Stackdriver, api/request_count untuk operasi “CreateTask” dan queue/task_attempt_count untuk upaya tugas. Antrean dan grup antrean traffic tinggi
rentan terhadap dua jenis kegagalan yang berbeda:
Kelebihan beban antrean terjadi saat pembuatan dan pengiriman tugas ke antrean atau grup antrean individual 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 downstream. Dalam kedua kasus tersebut, sebaiknya ikuti pola 500/50/5: saat menskalakan 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 kelebihan beban setiap kali traffic meningkat secara tiba-tiba. Akibatnya, antrean ini dapat mengalami:
- Peningkatan latensi pembuatan tugas
- Peningkatan rasio error pembuatan tugas
- Pengurangan rasio pengiriman
Untuk mencegah hal ini, sebaiknya tetapkan kontrol dalam situasi apa pun saat kecepatan pembuatan atau pengiriman antrean atau grup antrean dapat melonjak 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 traffic baca menjadi 740 ribu operasi per detik setelah 90 menit menggunakan jadwal peningkatan ini. Ada sejumlah situasi yang dapat menyebabkan hal ini terjadi.
Contoh:
- Meluncurkan fitur baru yang banyak menggunakan Cloud Tasks
- Memindahkan traffic antar-antrean
- Menyeimbangkan 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 pemisahan traffic App Engine (Standar/Flex) untuk memperlancar peningkatan traffic. Dengan memisahkan traffic antar-versi (Standar/Flex), permintaan yang perlu dikelola kapasitasnya dapat diaktifkan dari waktu ke waktu untuk melindungi kesehatan antrean. Sebagai contoh, pertimbangkan kasus pengaktifan traffic ke grup antrean yang baru diperluas: [queue0000, queue0199] adalah urutan antrean TPS tinggi yang menerima total pembuatan 100.000 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% 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 disebabkan oleh rilis
Saat meluncurkan rilis yang secara signifikan meningkatkan traffic ke antrean atau grup antrean, peluncuran gradual, sekali lagi, adalah mekanisme penting untuk meminimalkan peningkatan. Luncurkan instance secara bertahap sehingga peluncuran awal tidak melebihi total 500 operasi ke antrean baru, dengan peningkatan tidak lebih dari 50% setiap 5 menit.
Antrean atau grup 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 diperbarui, yang membuat antrean atau grup antrean TPS tinggi, secara bertahap sehingga beban awal berada di bawah 500 TPS dan peningkatan sebesar 50% atau kurang dilakukan secara bertahap dengan jeda 5 menit atau lebih.
Grup antrean yang baru diperluas
Saat meningkatkan kapasitas total grup antrean, misalnya memperluas [queue0000-queue0199 menjadi queue0000-queue0399], ikuti pola 500/50/5. Perlu 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 lagi menjadi strategi yang penting. Jika sumber traffic Anda adalah App Engine, Anda dapat menggunakan pemisahan traffic (lihat Puncak Traffic yang Dipicu Rilis). Saat memigrasikan layanan untuk menambahkan tugas ke peningkatan jumlah antrean, luncurkan instance secara bertahap sehingga peluncuran awal tidak melebihi 500 total 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 grup dapat mengirimnya. Jika nama antrean baru tersebar secara merata di antara nama antrean yang ada saat 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 untuk menggunakan pemisahan traffic dan peluncuran bertahap seperti yang dijelaskan di bagian di atas.
Jenis penamaan interleaved ini dapat dilakukan dengan menambahkan akhiran ke antrean yang diakhiri dengan angka 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, bukan [queue0200-queue0299].
Jika memerlukan peningkatan lebih lanjut, Anda masih dapat menyilangkan hingga 50% lebih banyak antrean setiap 5 menit.
Antrean tugas berskala besar/batch
Jika tugas dalam jumlah besar, misalnya jutaan atau miliaran, perlu ditambahkan, pola injeksi ganda dapat berguna. 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 dengan 5 TPS, lalu meningkat 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 overhead 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 detail selengkapnya tentang pemberian nama tugas.
Kelebihan beban 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 antrean tugas telah menumpuk, menghentikan jeda antrean tersebut berpotensi membebani layanan ini. Pertahanan yang direkomendasikan adalah pola 500/50/5 yang sama seperti yang disarankan untuk kelebihan beban antrean: jika antrean mengirim lebih dari 500 TPS, tingkatkan traffic yang dipicu oleh antrean maksimal 50% setiap 5 menit. Gunakan metrik Stackdriver untuk memantau peningkatan traffic secara proaktif. Pemberitahuan Stackdriver dapat digunakan untuk mendeteksi situasi yang berpotensi berbahaya.
Menghentikan jeda atau melanjutkan antrean TPS tinggi
Jika antrean atau serangkaian antrean dijeda atau diaktifkan kembali, antrean akan melanjutkan
pengiriman. Jika antrean memiliki banyak tugas, kecepatan pengiriman antrean yang baru diaktifkan
dapat meningkat secara dramatis dari 0 TPS hingga kapasitas penuh antrean. Untuk
meningkatkan, jeda resume antrean atau kontrol kecepatan pengiriman antrean menggunakan maxDispatchesPerSecond
Cloud Tasks.
Tugas terjadwal massal
Banyak tugas, yang dijadwalkan untuk dikirimkan secara bersamaan, juga dapat menimbulkan risiko kelebihan beban target. Jika Anda perlu memulai tugas dalam jumlah besar sekaligus, pertimbangkan untuk menggunakan kontrol kapasitas antrean untuk meningkatkan kapasitas pengiriman secara bertahap atau secara eksplisit meningkatkan kapasitas target terlebih dahulu.
Peningkatan fan-out
Saat mengupdate layanan yang dijalankan melalui 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 bersih dari rilis tersebut adalah peningkatan besar 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 gagal saat melakukan panggilan Cloud Tasks API. Namun, jika proporsi signifikan permintaan gagal dengan error sisi server, rasio percobaan ulang yang tinggi dapat membuat antrean Anda semakin kelebihan beban dan menyebabkannya pulih 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 Adaptive Throttling yang dijelaskan dalam bab Menangani Kelebihan Beban dalam buku Site Reliability Engineering. Library klien gRPC Google menerapkan variasi algoritma ini.