Mengontrol penggunaan sumber daya yang digunakan oleh instans aplikasi, penyewa individu, atau seluruh layanan. Hal ini dapat memungkinkan sistem untuk terus berfungsi dan memenuhi perjanjian tingkat layanan, bahkan ketika peningkatan permintaan membebani sumber daya secara ekstrem.
Konteks dan masalah
Beban pada aplikasi cloud biasanya bervariasi dari waktu ke waktu berdasarkan jumlah pengguna aktif atau jenis aktivitas yang mereka lakukan. Misalnya, lebih banyak pengguna cenderung aktif selama jam kerja, atau sistem mungkin diminta untuk melakukan analitik yang mahal secara komputasi di akhir setiap bulan. Mungkin juga ada ledakan aktivitas yang tiba-tiba dan tak terduga. Jika persyaratan pemrosesan sistem melebihi kapasitas sumber daya yang tersedia, kinerjanya akan buruk dan bahkan bisa gagal. Jika sistem harus memenuhi tingkat layanan yang disepakati, kegagalan seperti itu tidak dapat diterima.
Ada banyak strategi yang tersedia untuk menangani berbagai beban di cloud, tergantung pada tujuan bisnis untuk aplikasi. Salah satu strateginya adalah menggunakan autoscaling untuk mencocokkan sumber daya yang disediakan dengan kebutuhan pengguna pada waktu tertentu. Hal ini berpotensi memenuhi permintaan pengguna secara konsisten, sekaligus mengoptimalkan biaya operasional. Namun, meskipun penskalaan otomatis dapat memicu provisi lebih banyak sumber daya, provisi ini tidak langsung. Jika permintaan tumbuh dengan cepat, akan ada jendela waktu di mana terjadi defisit sumber daya.
Solusi
Strategi alternatif untuk penskalaan otomatis adalah mengizinkan aplikasi menggunakan sumber daya hanya hingga batas tertentu, dan kemudian membatasinya saat batas ini tercapai. Sistem harus memantau cara menggunakan sumber daya sehingga, saat penggunaan melebihi ambang batas, sistem dapat membatasi permintaan dari satu atau beberapa pengguna. Ini memungkinkan sistem untuk terus berfungsi dan memenuhi perjanjian tingkat layanan (SLA) apa pun yang ada. Untuk informasi lebih lanjut tentang pemantauan penggunaan sumber daya, lihat Bimbingan Instrumentasi dan Telemetri.
Sistem dapat menerapkan beberapa strategi pelambatan, termasuk:
Menolak permintaan dari pengguna individual yang telah mengakses API sistem lebih dari n kali per detik selama periode waktu tertentu. Hal ini mengharuskan sistem untuk mengukur penggunaan sumber daya pada setiap penyewa atau pengguna yang menjalankan aplikasi. Untuk informasi selengkapnya, lihat Panduan Pengukuran Layanan.
Menonaktifkan atau menurunkan fungsionalitas layanan non-esensial yang dipilih sehingga layanan esensial dapat berjalan tanpa hambatan dengan sumber daya yang memadai. Misalnya, jika aplikasi mengalirkan output video, hal tersebut bisa beralih ke resolusi yang lebih rendah.
Menggunakan perataan beban untuk memperlancar volume aktivitas (pendekatan ini dibahas secara lebih rinci oleh pola Perataan Beban Berbasis Antrian ). Dalam lingkungan multipenyewa, pendekatan ini akan mengurangi performa untuk setiap penyewa. Jika sistem harus mendukung campuran penyewa dengan SLA yang berbeda, pekerjaan bagi penyewa bernilai tinggi dapat segera dilakukan. Permintaan untuk penyewa lain dapat ditunda, dan ditangani ketika backlog telah menurun. Pola Antrean Prioritas dapat digunakan untuk membantu menerapkan pendekatan ini, karena dapat mengekspos titik akhir yang berbeda untuk berbagai tingkat/prioritas layanan.
Menunda operasi yang dilakukan atas nama aplikasi atau penyewa dengan prioritas lebih rendah. Operasi ini bisa ditangguhkan atau dibatasi, dengan pengecualian yang dibuat untuk memberi tahu penyewa bahwa sistem sedang sibuk dan operasi tersebut harus dicoba lagi nanti.
Anda harus berhati-hati saat mengintegrasikan dengan beberapa layanan pihak ketiga yang mungkin menjadi tidak tersedia atau mengembalikan kesalahan. Kurangi jumlah permintaan bersamaan yang sedang diproses sehingga log tidak perlu diisi dengan kesalahan. Anda juga menghindari biaya yang terkait dengan percobaan kembali pemrosesan permintaan yang akan gagal karena layanan pihak ke-3 tersebut. Kemudian, ketika permintaan berhasil diproses, kembali ke pemrosesan permintaan yang tidak diberlakukan secara teratur. Salah satu pustaka yang mengimplementasikan fungsionalitas ini adalah NServiceBus.
Gambar tersebut menunjukkan grafik area untuk penggunaan sumber daya (kombinasi memori, CPU, bandwidth, dan faktor lainnya) terhadap waktu untuk aplikasi yang menggunakan tiga fitur. Fitur adalah area fungsionalitas, seperti komponen yang melakukan serangkaian tugas tertentu, sepotong kode yang melakukan perhitungan kompleks, atau elemen yang menyediakan layanan seperti cache dalam memori. Fitur-fitur ini diberi label A, B, dan C.
Area tepat di bawah garis untuk fitur menunjukkan sumber daya yang digunakan oleh aplikasi saat mereka memanggil fitur ini. Misalnya, area di bawah garis untuk Fitur A menunjukkan sumber daya yang digunakan oleh aplikasi yang menggunakan Fitur A, dan area di antara garis untuk Fitur A dan Fitur B menunjukkan sumber daya yang digunakan oleh aplikasi yang menggunakan Fitur B. Menggabungkan area untuk setiap fitur menunjukkan total penggunaan sumber daya sistem.
Gambar sebelumnya mengilustrasikan efek dari operasi penangguhan. Tepat sebelum waktu T1, total sumber daya yang dialokasikan untuk semua aplikasi yang menggunakan fitur ini mencapai ambang batas (batas penggunaan sumber daya). Pada titik ini, aplikasi berada dalam bahaya melelahkan sumber daya yang tersedia. Dalam sistem ini, Fitur B kurang penting daripada Fitur A atau Fitur C, sehingga dinonaktifkan sementara dan sumber daya yang digunakan dirilis. Antara waktu T1 dan T2, aplikasi yang menggunakan Fitur A dan Fitur C terus berjalan seperti biasa. Akhirnya, penggunaan sumber daya dari kedua fitur ini berkurang ke titik ketika, pada waktu T2, ada kapasitas yang cukup untuk mengaktifkan Fitur B lagi.
Pendekatan auto-skaling dan throttling juga dapat dikombinasikan untuk membantu menjaga aplikasi responsif dan dalam SLA. Jika permintaan diperkirakan akan tetap tinggi, pelambatan memberikan solusi sementara sistem menurun. Pada titik ini, fungsionalitas penuh sistem dapat dipulihkan.
Gambar berikutnya menunjukkan grafik area dari keseluruhan penggunaan sumber daya oleh semua aplikasi yang berjalan dalam sistem terhadap waktu, dan mengilustrasikan bagaimana pelambatan dapat dikombinasikan dengan penskalaan otomatis.
Pada waktu T1, ambang batas yang menentukan batas lunak penggunaan sumber daya tercapai. Pada titik ini, sistem dapat mulai menskalakan. Namun, jika sumber daya baru tidak tersedia cukup cepat, maka sumber daya yang ada mungkin habis dan sistem bisa gagal. Untuk mencegah hal ini terjadi, sistem sementara dibatasi, seperti yang dijelaskan sebelumnya. Ketika autoscaling telah selesai dan sumber daya tambahan tersedia, pembatasan dapat dilonggarkan.
Masalah dan pertimbangan
Anda harus mempertimbangkan poin berikut saat memutuskan cara menerapkan pola ini:
Pembatasani aplikasi, dan strategi yang digunakan, adalah keputusan arsitektural yang memengaruhi seluruh desain sistem. Pembatasan harus dipertimbangkan secara dini dalam proses desain aplikasi karena tidak mudah untuk ditambahkan begitu sistem telah diterapkan.
Pembatasan harus dilakukan dengan cepat. Sistem harus mampu mendeteksi peningkatan aktivitas dan bereaksi sesuai dengan hal tersebut. Sistem juga harus dapat kembali ke keadaan semula dengan cepat setelah beban mereda. Hal ini mensyaratkan agar data kinerja yang tepat untuk terus-menerus ditangkap dan dipantau.
Jika layanan perlu menolak permintaan pengguna untuk sementara waktu, layanan harus mengembalikan kode kesalahan tertentu seperti 429 ("Terlalu banyak permintaan") dan 503 ("Server Terlalu Sibuk") sehingga aplikasi klien dapat memahami bahwa alasan penolakan untuk melayani permintaan disebabkan oleh pembatasan.
- HTTP 429 menunjukkan aplikasi panggilan mengirim terlalu banyak permintaan dalam jendela waktu dan melebihi batas yang telah ditentukan.
- HTTP 503 menunjukkan layanan belum siap untuk menangani permintaan. Penyebab umumnya adalah layanan mengalami lonjakan beban yang lebih sementara dari yang diharapkan.
Aplikasi klien dapat menunggu beberapa saat sebelum mencoba kembali permintaan. Header Retry-After HTTP harus disertakan, untuk mendukung klien dalam memilih strategi coba lagi.
Pembatasan dapat digunakan sebagai tindakan sementara saat sistem melakukan penskalaan otomatis. Dalam beberapa kasus, lebih baik hanya pembatasan, daripada menskalakan, jika ledakan aktivitas tiba-tiba dan tidak diharapkan berumur panjang karena penskalakan dapat menambah biaya yang berjalan cukup besar.
Jika pembatasan digunakan sebagai tindakan sementara saat sistem melakukan penskalaan otomatis, dan jika permintaan sumber daya meningkat dengan sangat cepat, sistem mungkin tidak dapat terus berfungsi—bahkan saat beroperasi dalam mode pembatasan. Jika hal ini tidak dapat diterima, pertimbangkan untuk mempertahankan cadangan kapasitas yang lebih besar dan mengonfigurasi penskalaan otomatis yang lebih agresif.
Menormalkan biaya sumber daya untuk operasi yang berbeda karena umumnya tidak membawa biaya eksekusi yang sama. Misalnya, batas pembatasan mungkin lebih rendah untuk operasi baca dan lebih tinggi untuk operasi tulis. Tidak mempertimbangkan biaya operasi dapat mengakibatkan kapasitas habis dan mengekspos vektor serangan potensial.
Perubahan konfigurasi dinamis perilaku pembatasan pada runtime diinginkan. Jika sistem menghadapi beban abnormal yang tidak dapat ditangani konfigurasi yang diterapkan, batas pembatasan mungkin perlu meningkatkan atau mengurangi untuk menstabilkan sistem dan mengikuti lalu lintas saat ini. Penyebaran yang mahal, berisiko, dan lambat tidak diinginkan pada saat ini. Menggunakan konfigurasi pembatasan pola Penyimpanan Konfigurasi Eksternal di luar dan dapat diubah dan diterapkan tanpa penyebaran.
Kapan menggunakan pola ini
Gunakan pola ini:
Untuk memastikan bahwa sistem terus memenuhi perjanjian tingkat layanan.
Untuk mencegah penyewa tunggal memonopoli sumber daya yang disediakan oleh aplikasi.
Untuk menangani lledakan dalam aktivitas.
Untuk membantu mengoptimalkan biaya sistem dengan membatasi tingkat sumber daya maksimum yang diperlukan agar tetap berfungsi.
Desain beban kerja
Arsitek harus mengevaluasi bagaimana pola Pembatasan dapat digunakan dalam desain beban kerja mereka untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Contohnya:
| Pilar | Bagaimana pola ini mendukung tujuan pilar |
|---|---|
| Keputusan desain keandalan membantu beban kerja Anda menjadi tahan terhadap kerusakan dan untuk memastikan bahwa keputusan tersebut pulih ke status berfungsi penuh setelah kegagalan terjadi. | Anda merancang batas untuk membantu mencegah kelelahan sumber daya yang mungkin menyebabkan kerusakan. Anda juga dapat menggunakan pola ini sebagai mekanisme kontrol dalam rencana degradasi yang anggun. - RE:07 Pelestarian Mandiri |
| Keputusan desain keamanan membantu memastikan kerahasiaan, integritas, dan ketersediaan data dan sistem beban kerja Anda. | Anda dapat merancang batas untuk membantu mencegah kelelahan sumber daya yang dapat mengakibatkan penyalahgunaan otomatis sistem. - Kontrol JARINGAN SE:06 - Sumber daya PENGERASAN SE:08 |
| Pengoptimalan Biaya difokuskan untuk mempertahankan dan meningkatkan pengembalian beban kerja Anda pada investasi. | Batas yang diberlakukan dapat menginformasikan pemodelan biaya dan bahkan dapat langsung terikat dengan model bisnis aplikasi Anda. Mereka juga menempatkan batas atas yang jelas pada pemanfaatan, yang dapat diperhitungkan ke dalam ukuran sumber daya. - Model biaya CO:02 - Biaya penskalan CO:12 |
| Efisiensi Performa membantu beban kerja Anda memenuhi tuntutan secara efisien melalui pengoptimalan dalam penskalaan, data, kode. | Ketika sistem berada di bawah permintaan tinggi, pola ini membantu mengurangi kemacetan yang dapat menyebabkan penyempitan performa. Anda juga dapat menggunakannya untuk secara proaktif menghindari skenario tetangga yang berisik. - Perencanaan kapasitas PE:02 - PE:05 Penskalaan dan pemartisian |
Seperti halnya keputusan desain apa pun, pertimbangkan tradeoff terhadap tujuan pilar lain yang mungkin diperkenalkan dengan pola ini.
Contoh
Gambar akhir menggambarkan bagaimana pembatasan dapat diimplementasikan dalam sistem multipenyewa. Pengguna dari masing-masing organisasi penyewa mengakses aplikasi yang dihosting cloud tempat mereka mengisi dan mengirimkan survei. Aplikasi ini berisi instrumentasi yang memantau tingkat di mana pengguna mengirimkan permintaan ke aplikasi.
Agar pengguna tidak dapat mengakses salah satu penyewa yang mempengaruhi daya tanggap dan ketersediaan aplikasi untuk semua pengguna lain, batas diterapkan ke jumlah permintaan per detik yang dapat dikirim oleh satu penyewa. Aplikasi memblokir permintaan yang melebihi batas ini.
Langkah berikutnya
Panduan berikut ini mungkin juga relevan ketika menerapkan pola ini:
- Instrumentasi dan Panduan Telemetri. Pelambatan tergantung pada pengumpulan informasi tentang seberapa besar layanan sedang digunakan. Menjelaskan cara menghasilkan dan menangkap informasi pemantauan khusus.
- Panduan Pengukuran Layanan. Menjelaskan cara mengukur penggunaan layanan untuk mendapatkan pemahaman tentang cara layanan digunakan. Informasi ini dapat berguna dalam menentukan cara membatasi layanan.
- Panduan Penskalaan Otomatis. Pembatasan dapat digunakan sebagai tindakan sementara saat sistem melakukan penskalaan otomatis, atau untuk menghilangkan kebutuhan sistem untuk penskalaan otomatis. Berisi informasi tentang strategi penskalaan otomatis.
Sumber daya terkait
Pola dan panduan berikut mungkin juga relevan saat menerapkan pola ini:
- Pola Pemerataan Beban Berdasarkan Antrean. Peningkatan muatan berbasis antrean adalah mekanisme yang umum digunakan untuk menerapkan pembatasan. Antrian dapat bertindak sebagai buffer yang membantu meratakan kecepatan permintaan yang dikirim oleh aplikasi ke layanan.
- Pola Antrean Prioritas. Suatu sistem dapat menggunakan antrian prioritas sebagai bagian dari strategi pembatasannya untuk mempertahankan kinerja untuk aplikasi yang penting atau bernilai lebih tinggi, sekaligus mengurangi kinerja aplikasi yang kurang penting.
- Pola Penyimpanan Konfigurasi Eksternal. Memusatkan dan eksternalisasi kebijakan pembatasan menyediakan kemampuan untuk mengubah konfigurasi saat runtime tanpa perlu penyebaran ulang. Layanan dapat berlangganan perubahan konfigurasi, sehingga segera menerapkan konfigurasi baru, untuk menstabilkan sistem.