REL01-BP03 Mengakomodasi kuota layanan tetap dan kendala melalui arsitektur - AWS Well-Architected Framework
Panduan implementasiSumber daya

REL01-BP03 Mengakomodasi kuota layanan tetap dan kendala melalui arsitektur

Waspadai kuota layanan, kendala layanan, dan batas sumber daya fisik yang tidak dapat diubah. Rancang arsitektur untuk aplikasi dan layanan untuk mencegah batasan ini memengaruhi keandalan.

Contohnya antara lain bandwidth jaringan, ukuran payload invokasi fungsi nirserver, tingkat burst throttle untuk gateway API, dan sambungan pengguna serentak ke basis data.

Hasil yang diinginkan: Performa aplikasi atau layanan sesuai yang diharapkan dalam kondisi normal dan lalu lintas tinggi. Aplikasi dan layanan telah dirancang untuk berfungsi dengan batasan untuk kuota layanan atau kendala tetap sumber daya tersebut.

Antipola umum:

  • Memilih desain yang menggunakan sumber daya 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 burst tetapi dalam jangka waktu yang lama.

  • Memilih desain yang tidak dapat diskalakan atau dimodifikasi jika kuota layanan tetap akan terlampaui. Contohnya, ukuran payload SQS sebesar 256 KB.

  • Observabilitas belum dirancang dan diimplementasikan untuk memantau dan memberikan peringatan tentang ambang batas kuota layanan yang mungkin berisiko selama lalu lintas sedang tinggi.

Manfaat menjalankan praktik terbaik ini: Verifikasi bahwa aplikasi akan beroperasi di bawah semua tingkat beban layanan yang diproyeksikan tanpa gangguan atau penurunan kualitas.

Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan: Sedang

Panduan implementasi

Tidak seperti sumber daya atau kuota layanan lunak yang diganti dengan unit kapasitas lebih tinggi, kuota tetap layanan AWS tidak dapat diubah. Ini berarti semua jenis layanan AWS ini harus dievaluasi untuk mengetahui potensi batas kapasitas keras ketika digunakan dalam desain aplikasi.

Batas keras ditunjukkan di konsol Service Quotas. Jika kolom menunjukkan DAPAT DISESUAIKAN = Tidak, 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 mendesain aplikasi python untuk beroperasi dalam fungsi Lambda, aplikasi harus dievaluasi untuk menentukan apakah ada peluang Lambda akan beroperasi lebih lama dari 15 menit. Jika kode mungkin akan dijalankan lebih dari batas kuota layanan ini, desain atau teknologi lain harus dipertimbangkan. Jika batas ini tercapai setelah deployment produksi, aplikasi akan mengalami penurunan kualitas dan gangguan sampai 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, strategi harus digunakan untuk menemukan apakah batas keras dapat tercapai. Pengujian stres, pengujian beban, dan pengujian kekacauan harus menjadi bagian dari rencana pengujian pendahuluan.

Langkah implementasi

  • Tinjau daftar lengkap layanan AWS 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 menjelaskan batas-batas ini di lokasi lain.

  • Saat Anda mendesain aplikasi Anda, tinjau 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 kegagalan zona dan kegagalan Wilayah. Jika progres 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 Terbaik Terkait:

Dokumen terkait:

Video terkait:

Alat terkait: