Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
REL01-BP03 Mengakomodasi kuota dan kendala layanan tetap melalui arsitektur
Perhatikan kuota layanan (service quotas), batasan layanan, dan batas sumber daya fisik yang tidak dapat diubah. Rancang arsitektur untuk aplikasi dan layanan agar batas ini tidak memengaruhi keandalan.
Contohnya termasuk bandwidth jaringan, ukuran payload pemanggilan fungsi tanpa server, kecepatan burst throttle untuk API gateway, dan koneksi pengguna bersamaan ke database.
Hasil yang diinginkan: Aplikasi atau layanan berfungsi sebagaimana yang diharapkan, baik saat kondisi lalu lintas normal atau pun sedang tinggi. Aplikasi dan layanan telah dirancang untuk berfungsi dengan batasan untuk kuota layanan (service quotas) atau kendala tetap sumber daya tersebut.
Anti-pola umum:
-
Memilih sebuah desain yang menggunakan sebuah sumber daya dari sebuah layanan, tidak menyadari bahwa terdapat kendala desain yang akan menyebabkan desain ini gagal begitu Anda menyesuaikan skala.
-
Melakukan tolok ukur yang tidak realistis dan akan mencapai kuota tetap layanan selama pengujian. Contohnya, menjalankan pengujian pada batas lonjakan tetapi dalam jangka waktu yang lama.
-
Memilih desain yang tidak dapat diskalakan atau dimodifikasi jika kuota layanan (service quotas) tetap akan terlampaui. Misalnya, ukuran SQS muatan 256KB.
-
Observabilitas belum dirancang dan diimplementasikan untuk memantau dan memberikan peringatan tentang ambang batas kuota layanan (service quotas) yang mungkin berisiko selama lalu lintas sedang tinggi
Manfaat menerapkan praktik terbaik ini: Memverifikasi bahwa aplikasi akan berjalan berdasarkan semua tingkat beban layanan yang diproyeksikan tanpa terjadi gangguan atau degradasi.
Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan: Sedang
Panduan implementasi
Tidak seperti kuota layanan lunak atau sumber daya yang diganti dengan unit berkapasitas lebih tinggi, kuota AWS tetap layanan tidak dapat diubah. Ini berarti bahwa semua jenis AWS layanan ini harus dievaluasi untuk potensi batas kapasitas keras ketika digunakan dalam desain aplikasi.
Batas keras ditunjukkan di konsol Service Quotas. Jika kolom menampilkan ADJUSTABLE = No
, layanan memiliki batas keras. Batas keras juga ditunjukkan di beberapa halaman konfigurasi sumber daya. Contohnya, Lambda memiliki batas keras spesifik yang tidak dapat disesuaikan.
Sebagai contoh, ketika merancang desain dari sebuah aplikasi python untuk beroperasi dalam fungsi Lambda, aplikasi tersebut harus dievaluasi untuk menentukan apakah ada peluang bagi Lambda untuk beroperasi lebih lama dari 15 menit. Jika kode mungkin akan dijalankan lebih dari batas kuota layanan (service quotas) ini, desain atau teknologi lain harus dipertimbangkan. Jika batas ini tercapai setelah deployment produksi, maka aplikasi akan mengalami penurunan kualitas dan gangguan sampai aplikasi itu dapat diperbaiki. Tidak seperti kuota lunak, tidak ada metode untuk mengubah batas-batas ini meskipun dalam kondisi darurat Keparahan 1.
Setelah aplikasi telah di-deploy ke lingkungan pengujian, Anda harus berstrategi untuk menemukan apakah batas keras dapat tercapai. Pengujian stres, pengujian beban, dan pengujian kekacauan harus menjadi bagian dari rencana pengujian pendahuluan.
Langkah-langkah implementasi
-
Tinjau daftar lengkap AWS layanan yang dapat digunakan dalam fase desain aplikasi.
-
Tinjau batas kuota lunak dan batas kuota keras untuk semua layanan ini. Tidak semua batas ditunjukkan di konsol Service Quotas. Beberapa layanan menggambarkan batasan ini di lokasi yang lain.
-
Saat Anda mendesain aplikasi Anda, lakukan peninjauan terhadap pendorong teknologi dan bisnis beban kerja Anda, seperti hasil bisnis, kasus penggunaan, sistem yang dependen, target ketersediaan, dan objek pemulihan bencana. Biarkan pendorong teknologi dan bisnis Anda memandu proses untuk mengidentifikasi sistem terdistribusi yang tepat untuk beban kerja Anda.
-
Analisis beban layanan di berbagai Wilayah dan akun. Banyak batas keras yang berbasis wilayah untuk layanan. Tetapi, beberapa batas berbasis akun.
-
Analisis arsitektur ketangguhan untuk penggunaan sumber daya selama terjadi kegagalan zona dan kegagalan Wilayah. Jika kemajuan desain multi-Wilayah menggunakan pendekatan aktif/aktif, aktif/pasif – panas, aktif/pasif - dingin, dan aktif/pasif - pilot light, kasus-kasus kegagalan ini akan menyebabkan penggunaan yang lebih tinggi. Hal ini akan menimbulkan potensi kasus penggunaan untuk mencapai batas keras.
Sumber daya
Praktik-praktik terbaik terkait:
Dokumen terkait:
-
AWS Pilar Keandalan Well-Architected Framework: Ketersediaan
-
AWS Service Quotas (sebelumnya disebut sebagai batas layanan)
-
AWS Trusted Advisor Pemeriksaan Praktik Terbaik (lihat bagian Batas Layanan)
-
Mengelola siklus hidup akun di lingkungan SaaS account-per-tenant AWS
-
Mengelola dan memantau API pembatasan dalam beban kerja Anda
-
Lihat AWS Trusted Advisor rekomendasi dalam skala besar dengan AWS Organizations
-
Mengotomatisasi Peningkatan Batas Layanan dan Dukungan Perusahaan dengan AWS Control Tower
-
Tindakan, sumber daya, dan kunci syarat untuk layanan Service Quotas
Video terkait:
Alat terkait: