Perspektif Azure Well-Architected Framework di Azure App Service (Web Apps)
Azure App Service adalah solusi komputasi platform as a service (PaaS) yang dapat Anda gunakan untuk menghosting beban kerja Anda di platform Azure. Ini adalah layanan terkelola penuh yang mengabstraksi komputasi yang mendasar dan membongkar tanggung jawab membangun, menyebarkan, dan menskalakan ke platform. Layanan aplikasi selalu berjalan dalam paket App Service. Paket layanan yang Anda pilih menentukan wilayah tempat beban kerja berjalan, konfigurasi komputasi, dan sistem operasi. Beberapa model penagihan tersedia untuk App Service.
Artikel ini mengasumsikan bahwa sebagai arsitek, Anda meninjau pohon keputusan komputasi dan memilih App Service sebagai komputasi untuk beban kerja Anda. Panduan dalam artikel ini memberikan rekomendasi arsitektur yang dipetakan ke prinsip pilar Azure Well-Architected Framework.
Penting
Cara menggunakan panduan ini
Setiap bagian memiliki daftar periksa desain yang menyajikan area kekhawatiran arsitektur bersama dengan strategi desain yang dilokalkan ke cakupan teknologi.
Juga termasuk rekomendasi tentang kemampuan teknologi yang dapat membantu mewujudkan strategi tersebut. Rekomendasi tidak mewakili daftar lengkap semua konfigurasi yang tersedia untuk fitur Web Apps Azure App Service dan dependensinya. Sebaliknya, mereka mencantumkan rekomendasi utama yang dipetakan ke perspektif desain. Gunakan rekomendasi untuk membangun bukti konsep Anda atau mengoptimalkan lingkungan Anda yang ada.
Arsitektur dasar yang menunjukkan rekomendasi utama: Arsitektur garis besar App Service.
Cakupan teknologi
Tinjauan ini berfokus pada keputusan yang saling terkait untuk sumber daya Azure berikut:
- Paket App Service
- Aplikasi Web
Penawaran Azure lainnya dikaitkan dengan App Service, seperti Azure Functions, Azure Logic Apps, dan App Service Environment. Penawaran tersebut berada di luar cakupan untuk artikel ini. Lingkungan App Service terkadang dirujuk untuk membantu mengklarifikasi fitur atau opsi penawaran App Service inti.
Keandalan
Tujuan pilar Keandalan adalah untuk memberikan fungsionalitas berkelanjutan dengan membangun ketahanan yang cukup dan kemampuan untuk memulihkan dengan cepat dari kegagalan.
Prinsip desain Keandalan menyediakan strategi desain tingkat tinggi yang diterapkan untuk komponen individu, alur sistem, dan sistem secara keseluruhan.
Daftar periksa desain
Mulai strategi desain Anda berdasarkan daftar periksa tinjauan desain untuk Keandalan. Tentukan relevansinya dengan persyaratan bisnis Anda sambil mengingat tingkatan dan fitur App Service dan dependensinya. Perluas strategi untuk menyertakan lebih banyak pendekatan sesuai kebutuhan.
Memprioritaskan alur pengguna: Tidak semua alur sama pentingnya. Tetapkan prioritas untuk setiap alur untuk memandu keputusan desain Anda. Desain alur pengguna dapat memengaruhi tingkat layanan dan jumlah instans yang Anda pilih untuk paket dan konfigurasi App Service.
Misalnya, aplikasi Anda mungkin menyertakan tingkat front-end dan back-end yang berkomunikasi melalui broker pesan. Anda dapat memilih untuk mensegmentasi tingkatan di beberapa aplikasi web untuk memungkinkan penskalaan independen, manajemen siklus hidup, dan pemeliharaan. Menempatkan aplikasi besar dalam satu paket dapat menyebabkan masalah memori atau CPU dan memengaruhi keandalan.
Anda mungkin memerlukan lebih banyak instans di ujung depan untuk performa optimal di sisi antarmuka pengguna. Namun, back end mungkin tidak memerlukan jumlah instans yang sama.
Mengantisipasi potensi kegagalan: Merencanakan strategi mitigasi untuk potensi kegagalan. Tabel berikut ini memperlihatkan contoh analisis mode kegagalan.
Kegagalan Mitigasi Kegagalan komponen App Service yang mendasar atau diabstraksi Memiliki redundansi komponen dalam instans dan dependensi. Pantau kesehatan instans, performa jaringan, dan performa penyimpanan. Kegagalan dependensi eksternal Gunakan pola desain seperti pola Coba Lagi dan pola Pemutus Sirkuit. Pantau dependensi eksternal dan atur batas waktu yang sesuai. Kegagalan karena lalu lintas dirutekan ke instans yang tidak sehat Pantau kesehatan instans. Pertimbangkan responsivitas, dan hindari mengirim permintaan ke instans yang tidak sehat. Untuk informasi selengkapnya, lihat Analisis mode kegagalan untuk aplikasi Azure.
Membangun redundansi: Membangun redundansi dalam aplikasi dan infrastruktur pendukung. Sebarkan instans di seluruh zona ketersediaan untuk meningkatkan toleransi kesalahan. Lalu lintas dirutekan ke zona lain jika satu zona gagal. Sebarkan aplikasi Anda di beberapa wilayah untuk memastikan bahwa aplikasi Anda tetap tersedia, bahkan jika seluruh wilayah mengalami pemadaman.
Bangun tingkat redundansi yang sama dalam layanan dependen. Misalnya, instans aplikasi mengikat penyimpanan blob. Pertimbangkan untuk mengonfigurasi akun penyimpanan terkait dengan penyimpanan zona-redundan (ZRS) jika aplikasi menggunakan penyebaran zona-redundan.
Memiliki redundansi dalam komponen jaringan. Misalnya, gunakan alamat IP zona-redundan dan load balancer.
Memiliki strategi penskalaan yang andal: Beban tak terduga pada aplikasi dapat membuatnya tidak dapat diandalkan. Pertimbangkan pendekatan penskalakan yang tepat berdasarkan karakteristik beban kerja Anda. Terkadang Anda dapat meningkatkan skala untuk menangani beban. Namun, jika beban terus meningkat, peluasan skala ke instans baru. Lebih suka penskalakan otomatis daripada pendekatan manual. Selalu pertahankan buffer kapasitas tambahan selama operasi penskalaan untuk mencegah penurunan performa.
Tingkat paket App Service yang Anda pilih memengaruhi penskalaan dalam hal jumlah instans dan unit komputasi.
Pastikan inisialisasi aplikasi yang tepat sehingga instans baru dihangatkan dengan cepat dan dapat menerima permintaan.
Berusahalah untuk aplikasi stateless jika memungkinkan. Status penskalaan yang andal dengan instans baru dapat meningkatkan kompleksitas. Pertimbangkan penyimpanan data eksternal yang dapat Anda skalakan secara independen jika Anda perlu menyimpan status aplikasi. Menyimpan status sesi dalam memori dapat mengakibatkan hilangnya status sesi saat ada masalah dengan aplikasi atau App Service. Ini juga membatasi kemungkinan penyebaran beban di seluruh instans lain.
Uji aturan autoscaling Anda secara teratur. Simulasikan skenario beban untuk memverifikasi bahwa aplikasi Anda diskalakan seperti yang diharapkan. Anda harus mencatat peristiwa penskalakan sehingga Anda dapat memecahkan masalah yang mungkin timbul dan mengoptimalkan strategi penskalakan Anda dari waktu ke waktu.
App Service memiliki batasan jumlah instans dalam paket, yang dapat memengaruhi keandalan penskalaan. Salah satu strateginya adalah menggunakan stempel penyebaran yang identik, masing-masing menjalankan instans paket App Service dengan titik akhirnya sendiri. Sangat penting bahwa Anda berada di depan semua stempel dengan load balancer eksternal untuk mendistribusikan lalu lintas di seluruhnya. Gunakan Azure Application Gateway untuk penyebaran zona tunggal dan Azure Front Door untuk penyebaran multi-regional. Pendekatan ini sangat ideal untuk aplikasi misi penting di mana keandalan sangat penting. Untuk informasi selengkapnya, lihat Garis besar misi penting dengan App Service.
Paket App Service mendistribusikan lalu lintas di seluruh instans dan memantau kesehatannya. Perhatikan bahwa load balancer eksternal mungkin tidak segera mendeteksi apakah satu instans gagal.
Rencanakan pemulihan Anda: Redundansi sangat penting untuk kelangsungan bisnis. Failover ke instans lain jika satu instans tidak dapat dijangkau. Jelajahi kemampuan penyembuhan otomatis di App Service, seperti perbaikan instans otomatis.
Terapkan pola desain untuk menangani degradasi yang anggun untuk kedua kegagalan sementara, seperti masalah konektivitas jaringan, dan peristiwa skala besar seperti pemadaman regional. Pertimbangkan pola desain berikut:
Pola Bulkhead mengelompokkan aplikasi Anda ke dalam grup terisolasi untuk mencegah kegagalan memengaruhi seluruh sistem.
Pola Perataan Beban Berbasis Antrean mengantrekan item kerja yang berfungsi sebagai buffer untuk memperlancar lonjakan lalu lintas.
Pola Coba lagi menangani kegagalan sementara karena gangguan jaringan, koneksi database yang terputus, atau layanan sibuk.
Pola Circuit Breaker mencegah aplikasi berulang kali mencoba melakukan operasi yang kemungkinan gagal.
Anda dapat menggunakan WebJobs untuk menjalankan tugas latar belakang di aplikasi web Anda. Untuk menjalankan tugas tersebut dengan andal, pastikan bahwa aplikasi yang menghosting pekerjaan Anda berjalan terus-menerus sesuai jadwal atau berdasarkan pemicu berbasis peristiwa.
Untuk informasi selengkapnya, lihat Pola keandalan.
Lakukan pengujian keandalan: Lakukan pengujian beban untuk mengevaluasi keandalan dan performa aplikasi Anda di bawah beban. Rencana pengujian harus mencakup skenario yang memvalidasi operasi pemulihan otomatis Anda.
Gunakan injeksi kesalahan untuk secara sengaja memperkenalkan kegagalan dan memvalidasi mekanisme penyembuhan diri dan pelestarian diri Anda. Jelajahi pustaka kesalahan yang disediakan oleh Azure Chaos Studio.
App Service memberlakukan batas sumber daya pada aplikasi yang dihosting. Paket App Service menentukan batas ini. Pastikan pengujian Anda mengonfirmasi bahwa aplikasi berjalan dalam batas sumber daya tersebut. Untuk informasi selengkapnya, lihat Batas, kuota, dan batasan langganan dan layanan Azure.
Gunakan pemeriksaan kesehatan untuk mengidentifikasi pekerja yang tidak responsif: App Service memiliki kemampuan bawaan yang secara berkala melakukan ping pada jalur tertentu dari aplikasi web Anda. Instans yang tidak responsif dihapus dari load balancer dan diganti dengan instans baru.
Rekomendasi
| Rekomendasi | Keuntungan |
|---|---|
| (Paket App Service) Pilih tingkat Premium dari paket App Service untuk beban kerja produksi. Atur jumlah maksimum dan minimum pekerja sesuai dengan perencanaan kapasitas Anda. Untuk informasi selengkapnya, lihat Gambaran umum paket App Service. |
Paket App Service premium menawarkan fitur penskalaan tingkat lanjut dan memastikan redundansi jika kegagalan terjadi. |
| (Paket App Service) Aktifkan redundansi zona. Pertimbangkan untuk menyediakan lebih dari tiga instans untuk meningkatkan toleransi kesalahan. Periksa dukungan regional untuk redundansi zona karena tidak semua wilayah menawarkan fitur ini. |
Aplikasi Anda dapat menahan kegagalan dalam satu zona saat beberapa instans tersebar di seluruh zona. Lalu lintas secara otomatis beralih ke instans sehat di zona lain dan mempertahankan keandalan aplikasi jika satu zona tidak tersedia. |
| (App Service) Pertimbangkan untuk menonaktifkan fitur afinitas perutean permintaan aplikasi (ARR). Afinitas ARR membuat sesi lengket yang mengalihkan pengguna ke simpul yang menangani permintaan mereka sebelumnya. | Permintaan masuk didistribusikan secara merata di semua simpul yang tersedia saat Anda menonaktifkan afinitas ARR. Permintaan yang didistribusikan secara merata mencegah lalu lintas membebani node tunggal apa pun. Permintaan dapat dialihkan dengan mulus ke simpul sehat lainnya jika node tidak tersedia. Hindari afinitas sesi untuk memastikan bahwa instans App Service Anda tetap stateless. App Service stateless mengurangi kompleksitas dan memastikan perilaku yang konsisten di seluruh simpul. Hapus sesi lekat sehingga App Service dapat menambahkan atau menghapus instans untuk diskalakan secara horizontal. |
| (App Service) Tentukan aturan penyembuhan otomatis berdasarkan jumlah permintaan, permintaan lambat, batas memori, dan indikator lain yang merupakan bagian dari garis besar performa Anda. Pertimbangkan konfigurasi ini sebagai bagian dari strategi penskalaan Anda. | Aturan penyembuhan otomatis membantu aplikasi Anda pulih secara otomatis dari masalah tak terduga. Aturan yang dikonfigurasi memicu tindakan penyembuhan saat ambang dilanggar. Penyembuhan otomatis memungkinkan pemeliharaan proaktif otomatis. |
| (App Service) Aktifkan fitur pemeriksaan kesehatan dan berikan jalur yang merespons permintaan pemeriksaan kesehatan. | Pemeriksaan kesehatan dapat mendeteksi masalah lebih awal. Kemudian sistem dapat secara otomatis mengambil tindakan korektif ketika permintaan pemeriksaan kesehatan gagal. Load balancer merutekan lalu lintas dari instans yang tidak sehat, yang mengarahkan pengguna ke simpul yang sehat. |
Keamanan
Tujuan pilar Keamanan adalah untuk memberikan jaminan kerahasiaan, integritas, dan ketersediaan terhadap beban kerja.
Prinsip desain Keamanan menyediakan strategi desain tingkat tinggi untuk mencapai tujuan tersebut dengan menerapkan pendekatan pada desain teknis sekeliling hosting di App Service.
Daftar periksa desain
Mulai strategi desain Anda berdasarkan daftar periksa ulasan desain untuk Keamanan dan identifikasi kerentanan dan kontrol untuk meningkatkan postur keamanan. Perluas strategi untuk menyertakan lebih banyak pendekatan sesuai kebutuhan.
Tinjau garis besar keamanan: Untuk meningkatkan postur keamanan aplikasi Anda yang dihosting pada paket App Service, tinjau garis besar keamanan untuk App Service.
Gunakan runtime dan pustaka terbaru: Uji build aplikasi Anda secara menyeluruh sebelum Anda melakukan pembaruan untuk menangkap masalah lebih awal dan memastikan transisi yang lancar ke versi baru. App Service mendukung kebijakan dukungan runtime bahasa untuk memperbarui tumpukan yang ada dan menghentikan tumpukan akhir dukungan.
Buat segmentasi melalui batas isolasi untuk berisi pelanggaran: Terapkan segmentasi identitas. Misalnya, terapkan kontrol akses berbasis peran (RBAC) untuk menetapkan izin tertentu berdasarkan peran. Ikuti prinsip hak istimewa paling sedikit untuk membatasi hak akses hanya untuk apa yang diperlukan. Buat juga segmentasi di tingkat jaringan. Masukkan aplikasi App Service di jaringan virtual Azure untuk isolasi dan tentukan grup keamanan jaringan (NSG) untuk memfilter lalu lintas.
Paket App Service menawarkan tingkat Lingkungan App Service yang menyediakan isolasi tingkat tinggi. Dengan App Service Environment, Anda mendapatkan komputasi dan jaringan khusus.
Menerapkan kontrol akses pada identitas: Batasi akses masuk ke aplikasi web dan akses keluar dari aplikasi web ke sumber daya lain. Konfigurasi ini menerapkan kontrol akses pada identitas dan membantu mempertahankan postur keamanan keseluruhan beban kerja.
Gunakan ID Microsoft Entra untuk semua kebutuhan autentikasi dan otorisasi. Gunakan peran bawaan, seperti Kontributor Paket Web, Kontributor Situs Web, dan Kontributor generik, Pembaca, dan Pemilik.
Mengontrol lalu lintas jaringan ke dan dari aplikasi: Jangan mengekspos titik akhir aplikasi ke internet publik. Sebagai gantinya, tambahkan titik akhir privat di aplikasi web yang ditempatkan di subnet khusus. Front aplikasi Anda dengan proksi terbalik yang berkomunikasi dengan titik akhir privat tersebut. Pertimbangkan untuk menggunakan Application Gateway atau Azure Front Door untuk tujuan tersebut.
Sebarkan firewall aplikasi web (WAF) untuk melindungi dari kerentanan umum. Application Gateway dan Azure Front Door memiliki kemampuan WAF terintegrasi.
Konfigurasikan aturan proksi terbalik dan pengaturan jaringan dengan tepat untuk mencapai tingkat keamanan dan kontrol yang diinginkan. Misalnya, tambahkan aturan NSG pada subnet titik akhir privat untuk hanya menerima lalu lintas dari proksi terbalik.
Lalu lintas keluar dari aplikasi ke layanan PaaS lainnya harus melalui titik akhir privat. Pertimbangkan untuk menempatkan komponen firewall untuk membatasi lalu lintas keluar ke internet publik. Kedua pendekatan mencegah penyelundupan data.
Untuk tampilan komprehensif, lihat Fitur jaringan App Service.
Mengenkripsi data: Melindungi data saat transit dengan Keamanan Lapisan Transportasi (TLS) end-to-end. Gunakan kunci yang dikelola pelanggan Anda untuk enkripsi penuh data tidak aktif. Untuk informasi selengkapnya, lihat Enkripsi saat tidak aktif menggunakan kunci yang dikelola pelanggan.
Jangan gunakan protokol warisan seperti TLS 1.0 dan 1.1. App Service mengaktifkan 1.2 secara default. Untuk informasi selengkapnya, lihat Gambaran umum TLS App Service.
Semua instans App Service Anda memiliki nama domain default. Gunakan domain kustom dan amankan domain tersebut dengan sertifikat.
Kurangi permukaan serangan: Hapus konfigurasi default yang tidak Anda butuhkan. Misalnya, nonaktifkan penelusuran kesalahan jarak jauh, autentikasi lokal untuk situs Source Control Manager (SCM), dan autentikasi dasar. Nonaktifkan protokol yang tidak aman seperti HTTP dan Protokol Transfer File (FTP). Menerapkan konfigurasi melalui kebijakan Azure. Untuk informasi selengkapnya, lihat Kebijakan Azure.
Menerapkan kebijakan berbagi sumber daya lintas asal (CORS) yang ketat: Gunakan kebijakan CORS ketat di aplikasi web Anda untuk hanya menerima permintaan dari domain, header, dan kriteria lainnya yang diizinkan. Menerapkan kebijakan CORS dengan definisi kebijakan Azure bawaan.
Melindungi rahasia aplikasi: Anda perlu menangani informasi sensitif, seperti kunci API atau token autentikasi. Alih-alih melakukan hardcoding rahasia ini langsung ke dalam kode aplikasi atau file konfigurasi, Anda dapat menggunakan referensi Azure Key Vault di pengaturan aplikasi. Saat aplikasi dimulai, App Service secara otomatis mengambil nilai rahasia dari Key Vault dengan menggunakan identitas terkelola aplikasi.
Aktifkan log sumber daya untuk aplikasi Anda: Aktifkan log sumber daya untuk aplikasi Anda untuk membuat jejak aktivitas komprehensif yang menyediakan data berharga selama penyelidikan yang mengikuti insiden keamanan.
Pertimbangkan pengelogan sebagai bagian dari proses pemodelan ancaman Saat Anda menilai ancaman.
Rekomendasi
| Rekomendasi | Keuntungan |
|---|---|
| (App Service) Tetapkan identitas terkelola ke aplikasi web. Untuk mempertahankan batas isolasi, jangan bagikan atau gunakan kembali identitas di seluruh aplikasi. Pastikan Anda terhubung dengan aman ke registri kontainer jika Anda menggunakan kontainer untuk penyebaran Anda. |
Aplikasi mengambil rahasia dari Key Vault untuk mengautentikasi komunikasi keluar dari aplikasi. Azure mengelola identitas dan tidak mengharuskan Anda untuk menyediakan atau memutar rahasia apa pun. Anda memiliki identitas yang berbeda untuk granularitas kontrol. Identitas yang berbeda memudahkan pencabutan jika identitas disusupi. |
| (App Service) Mengonfigurasi domain kustom untuk aplikasi. Nonaktifkan HTTP dan hanya terima permintaan HTTPS. |
Domain kustom memungkinkan komunikasi yang aman melalui HTTPS menggunakan protokol Keamanan Lapisan Transportasi (TLS), yang memastikan perlindungan data sensitif dan membangun kepercayaan pengguna. |
| (App Service) mengevaluasi apakah autentikasi bawaan App Service adalah mekanisme yang tepat untuk mengautentikasi pengguna yang mengakses aplikasi Anda. Autentikasi bawaan App Service terintegrasi dengan ID Microsoft Entra. Fitur ini menangani validasi token dan manajemen identitas pengguna di beberapa penyedia masuk dan mendukung Koneksi OpenID. Dengan fitur ini, Anda tidak memiliki otorisasi pada tingkat terperinci, dan Anda tidak memiliki mekanisme untuk menguji autentikasi. | Saat menggunakan fitur ini, Anda tidak perlu menggunakan pustaka autentikasi dalam kode aplikasi, yang mengurangi kompleksitas. Pengguna sudah diautentikasi ketika permintaan mencapai aplikasi. |
| (App Service) Konfigurasikan aplikasi untuk integrasi jaringan virtual. Gunakan titik akhir privat untuk aplikasi App Service. Blokir semua lalu lintas publik. Rutekan penarikan gambar kontainer melalui integrasi jaringan virtual. Semua lalu lintas keluar dari aplikasi melewati jaringan virtual. |
Dapatkan manfaat keamanan menggunakan jaringan virtual Azure. Misalnya, aplikasi dapat mengakses sumber daya dengan aman dalam jaringan. Tambahkan titik akhir privat untuk membantu melindungi aplikasi Anda. Titik akhir privat membatasi paparan langsung ke jaringan publik dan memungkinkan akses terkontrol melalui proksi terbalik. |
| (App Service) Untuk menerapkan pengerasan: - Nonaktifkan autentikasi dasar yang menggunakan nama pengguna dan kata sandi yang mendukung autentikasi berbasis ID Microsoft Entra. - Nonaktifkan penelusuran kesalahan jarak jauh sehingga port masuk tidak dibuka. - Aktifkan kebijakan CORS untuk memperketat permintaan masuk. - Nonaktifkan protokol, seperti FTP. |
Kami tidak merekomendasikan autentikasi dasar sebagai metode penyebaran yang aman. MICROSOFT Entra ID menggunakan autentikasi berbasis token OAuth 2.0, yang menawarkan banyak keuntungan dan peningkatan yang mengatasi batasan yang terkait dengan autentikasi dasar. Kebijakan membatasi akses ke sumber daya aplikasi, hanya mengizinkan permintaan dari domain tertentu, dan mengamankan permintaan lintas wilayah. |
| (App Service) Selalu gunakan referensi Key Vault sebagai pengaturan aplikasi. |
Rahasia dipisahkan dari konfigurasi aplikasi Anda. Pengaturan aplikasi dienkripsi saat tidak aktif. App Service juga mengelola rotasi rahasia. |
| (Paket App Service) Aktifkan Microsoft Defender untuk Cloud untuk App Service. | Dapatkan perlindungan real time untuk sumber daya yang berjalan dalam paket App Service. Jaga dari ancaman dan tingkatkan postur keamanan Anda secara keseluruhan. |
| (Paket App Service) Aktifkan pembuatan log diagnostik dan tambahkan instrumentasi ke aplikasi Anda. Log dikirim ke akun Azure Storage, Azure Event Hubs, dan Analitik Log. Untuk informasi selengkapnya tentang jenis log audit, lihat Jenis log yang didukung. | Pengelogan menangkap pola akses. Ini mencatat peristiwa yang relevan yang memberikan wawasan berharga tentang bagaimana pengguna berinteraksi dengan aplikasi atau platform. Informasi ini sangat penting untuk tujuan akuntabilitas, kepatuhan, dan keamanan. |
Pengoptimalan Biaya
Pengoptimalan Biaya berfokus pada mendeteksi pola pengeluaran, memprioritaskan investasi di area penting, dan mengoptimalkan orang lain untuk memenuhi anggaran organisasi sambil memenuhi persyaratan bisnis.
Prinsip desain Pengoptimalan Biaya menyediakan strategi desain tingkat tinggi untuk mencapai tujuan tersebut dan membuat tradeoff seperlunya dalam desain teknis yang terkait dengan aplikasi web Anda dan lingkungan tempat mereka berjalan.
Daftar periksa desain
Mulai strategi desain Anda berdasarkan daftar periksa ulasan desain untuk Pengoptimalan Biaya untuk investasi dan sesuaikan desain sehingga beban kerja selaras dengan anggaran yang dialokasikan untuk beban kerja. Desain Anda harus menggunakan kemampuan Azure yang tepat, memantau investasi, dan menemukan peluang untuk dioptimalkan dari waktu ke waktu.
Perkirakan biaya awal: Sebagai bagian dari latihan pemodelan biaya Anda, gunakan kalkulator harga Azure untuk mengevaluasi perkiraan biaya yang terkait dengan berbagai tingkatan berdasarkan jumlah instans yang Anda rencanakan untuk dijalankan. Setiap tingkat App Service menawarkan opsi komputasi yang berbeda.
Terus memantau model biaya untuk melacak pengeluaran.
Mengevaluasi opsi diskon: Tingkat yang lebih tinggi mencakup instans komputasi khusus. Anda dapat menerapkan diskon reservasi jika beban kerja Anda memiliki pola penggunaan yang dapat diprediksi dan konsisten. Pastikan Anda menganalisis data penggunaan untuk menentukan jenis reservasi yang sesuai dengan beban kerja Anda. Untuk informasi selengkapnya, lihat Menghemat biaya dengan instans cadangan App Service.
Memahami pengukur penggunaan: Azure mengenakan tarif per jam, prorata ke yang kedua, berdasarkan tingkat harga paket App Service Anda. Biaya berlaku untuk setiap instans yang diskalakan dalam paket Anda, berdasarkan waktu Anda mengalokasikan instans VM. Perhatikan sumber daya komputasi yang kurang digunakan yang dapat meningkatkan biaya Anda sebagai akibat dari keseluruhan alokasi karena pemilihan SKU suboptimal, atau konfigurasi penyempitan skala yang dikonfigurasi dengan buruk.
Fitur App Service tambahan, seperti pendaftaran domain kustom dan sertifikat kustom, mungkin menambahkan biaya. Sumber daya lain, seperti jaringan virtual untuk mengisolasi solusi atau brankas kunci Anda untuk melindungi rahasia beban kerja, yang terintegrasi dengan sumber daya App Service Anda juga dapat menambahkan biaya. Untuk informasi selengkapnya, lihat Model penagihan App Services.
Pertimbangkan tradeoff antara kepadatan dan isolasi: Anda dapat menggunakan paket App Service untuk menghosting beberapa aplikasi pada komputasi yang sama, yang menghemat biaya dengan lingkungan bersama. Untuk informasi selengkapnya, lihat Tradeoffs.
Mengevaluasi efek strategi penskalaan Anda terhadap biaya: Anda harus merancang, menguji, dan mengonfigurasi penskalaan dengan benar dan untuk penskalaan saat Menerapkan penskalaan otomatis. Tetapkan batas maksimum dan minimum yang tepat pada autoscaling.
Secara proaktif menginisialisasi aplikasi untuk penskalaan yang andal. Misalnya, jangan menunggu hingga CPU mencapai penggunaan 95%. Sebagai gantinya, picu penskalaan sekitar 65% untuk memungkinkan waktu yang cukup bagi instans baru untuk dialokasikan dan diinisialisasi selama proses penskalaan. Namun, strategi ini mungkin menyebabkan kapasitas yang tidak digunakan.
Kami menyarankan agar Anda menggabungkan dan menyeimbangkan mekanisme untuk peningkatan dan penskalaan. Misalnya, aplikasi dapat meningkatkan skala untuk beberapa waktu dan kemudian meluaskan skala seperlunya. Jelajahi tingkat tinggi yang menawarkan kapasitas besar dan penggunaan sumber daya yang efisien. Berdasarkan pola penggunaan, tingkat Premium yang lebih tinggi sering lebih hemat biaya karena lebih mampu.
Mengoptimalkan biaya lingkungan: Pertimbangkan tingkat Dasar atau Gratis untuk menjalankan lingkungan pra-produksi. Tingkatan ini berkinerja rendah dan biaya rendah. Jika Anda menggunakan tingkat Dasar atau Gratis, gunakan tata kelola untuk memberlakukan tingkatan, batasi jumlah instans dan CPU, batasi penskalaan, dan batasi retensi log.
Menerapkan pola desain: Strategi ini mengurangi volume permintaan yang dihasilkan beban kerja Anda. Pertimbangkan untuk menggunakan pola seperti pola Backend untuk Frontend dan pola Agregasi Gateway, yang dapat meminimalkan jumlah permintaan dan mengurangi biaya.
Memeriksa biaya terkait data secara teratur: Periode retensi data yang diperpanjang atau tingkat penyimpanan yang mahal dapat menyebabkan biaya penyimpanan yang tinggi. Lebih banyak pengeluaran dapat terakumulasi karena penggunaan bandwidth dan retensi data pengelogan yang berkepanjangan.
Pertimbangkan untuk menerapkan penembolokan untuk meminimalkan biaya transfer data. Mulailah dengan penembolokan dalam memori lokal, lalu jelajahi opsi penembolokan terdistribusi untuk mengurangi jumlah permintaan ke database back-end. Pertimbangkan biaya lalu lintas bandwidth yang terkait dengan komunikasi lintas wilayah jika database Anda terletak di wilayah yang berbeda.
Optimalkan biaya penyebaran: Manfaatkan slot penyebaran untuk mengoptimalkan biaya. Slot berjalan di lingkungan komputasi yang sama dengan instans produksi. Gunakan secara strategis untuk skenario seperti penyebaran biru-hijau yang beralih antar slot. Pendekatan ini meminimalkan waktu henti dan memastikan transisi yang lancar.
Gunakan slot penyebaran dengan hati-hati. Anda dapat memperkenalkan masalah, seperti pengecualian atau kebocoran memori, yang mungkin memengaruhi instans yang ada dan instans baru. Pastikan Anda menguji perubahan secara menyeluruh. Untuk panduan operasional, lihat Keunggulan Operasional.
Rekomendasi
| Rekomendasi | Keuntungan |
|---|---|
| (Paket App Service) Pilih tingkat Gratis atau Dasar untuk lingkungan yang lebih rendah. Kami merekomendasikan tingkatan ini untuk penggunaan eksperimental. Hapus tingkatan saat Anda tidak lagi membutuhkannya. | Tingkat Gratis dan Dasar ramah anggaran dibandingkan dengan tingkat yang lebih tinggi. Mereka memberikan solusi hemat biaya untuk lingkungan nonproduksi yang tidak memerlukan fitur lengkap dan performa paket premium. |
| (Paket App Service) Manfaatkan diskon dan jelajahi harga pilihan untuk: - Lingkungan yang lebih rendah dengan rencana dev/test. - Reservasi Azure dan paket penghematan Azure untuk komputasi khusus yang Anda provisikan di tingkat Premium V3 dan Lingkungan App Service. Gunakan instans cadangan untuk beban kerja stabil yang memiliki pola penggunaan yang dapat diprediksi. |
Paket dev/test memberikan pengurangan tarif untuk layanan Azure, yang membuatnya hemat biaya untuk lingkungan nonproduksi. Gunakan instans cadangan untuk membayar di muka untuk sumber daya komputasi dan mendapatkan diskon yang signifikan. |
| (App Service) Memantau biaya yang dikeluarkan sumber daya App Service. Jalankan alat analisis biaya di portal Azure. Buat anggaran dan pemberitahuan untuk memberi tahu pemangku kepentingan. |
Anda dapat mengidentifikasi lonjakan biaya, inefisiensi, atau pengeluaran tak terduga sejak dini. Pendekatan proaktif ini membantu Anda memberikan kontrol anggaran untuk mencegah pengeluaran berlebih. |
| (Paket App Service) Menskalakan ketika permintaan menurun. Untuk menskalakan, tentukan aturan skala untuk mengurangi jumlah instans di Azure Monitor. | Cegah pemborongan dan kurangi pengeluaran yang tidak perlu. |
Keunggulan Operasional
Keunggulan Operasional terutama berfokus pada prosedur untuk praktik pengembangan, pengamatan, dan manajemen rilis.
Prinsip desain Keunggulan Operasional menyediakan strategi desain tingkat tinggi untuk mencapai tujuan tersebut terhadap persyaratan operasional beban kerja.
Daftar periksa desain
Mulai strategi desain Anda berdasarkan daftar periksa ulasan desain untuk Keunggulan Operasional untuk menentukan proses untuk pengamatan, pengujian, dan penyebaran yang terkait dengan Web Apps.
Mengelola rilis: Gunakan slot penyebaran untuk mengelola rilis secara efektif. Anda dapat menyebarkan aplikasi Anda ke slot, melakukan pengujian, dan memvalidasi fungsionalitasnya. Setelah verifikasi, Anda dapat memindahkan aplikasi ke produksi dengan lancar. Proses ini tidak dikenakan biaya tambahan karena slot berjalan di lingkungan komputer virtual (VM) yang sama dengan instans produksi.
Jalankan pengujian otomatis: Sebelum Anda mempromosikan rilis aplikasi web, uji performa, fungsionalitas, dan integrasinya secara menyeluruh dengan komponen lain. Gunakan Azure Load Testing, yang terintegrasi dengan Apache JMeter, alat populer untuk pengujian performa. Jelajahi alat otomatis untuk jenis pengujian lain, seperti Phantom untuk pengujian fungsi.
Menyebarkan unit yang tidak dapat diubah: Terapkan pola Stempel Penyebaran untuk menggabungkan App Service ke dalam stempel yang tidak dapat diubah. App Service mendukung penggunaan kontainer, yang secara inheren tidak dapat diubah. Pertimbangkan kontainer kustom untuk aplikasi web App Service Anda.
Setiap stempel mewakili unit mandiri yang dapat Anda skalakan atau skalakan dengan cepat. Unit yang didasarkan pada stempel ini bersifat sementara dan tanpa status. Desain stateless menyederhanakan operasi dan pemeliharaan. Pendekatan ini sangat ideal untuk aplikasi misi penting. Misalnya, lihat Garis besar misi-kritis dengan App Service.
Gunakan teknologi infrastruktur sebagai kode (IaC), seperti Bicep, untuk memberi stempel unit dengan pengulangan dan konsistensi.
Menjaga lingkungan produksi tetap aman: Buat paket App Service terpisah untuk menjalankan lingkungan produksi dan pra-produksi. Jangan membuat perubahan langsung di lingkungan produksi untuk memastikan stabilitas dan keandalan. Instans terpisah memungkinkan fleksibilitas dalam pengembangan dan pengujian sebelum Anda mempromosikan perubahan pada produksi.
Gunakan lingkungan rendah untuk menjelajahi fitur dan konfigurasi baru dengan cara yang terisolasi. Jaga lingkungan pengembangan dan pengujian tetap ephemeral.
Mengelola sertifikat: Untuk domain kustom, Anda perlu mengelola sertifikat TLS.
Memiliki proses untuk mendapatkan, memperbarui, dan memvalidasi sertifikat. Offload proses ini ke App Service jika memungkinkan. Jika Anda menggunakan sertifikat Anda sendiri, Anda harus mengelola perpanjangannya. Pilih pendekatan yang paling sesuai dengan persyaratan keamanan Anda.
| Rekomendasi | Keuntungan |
|---|---|
| (App Service) Pantau kesehatan instans Anda dan aktifkan pemeriksaan kesehatan instans. Siapkan jalur tertentu untuk menangani permintaan pemeriksaan kesehatan. |
Anda dapat segera mendeteksi masalah dan mengambil tindakan yang diperlukan untuk menjaga ketersediaan dan performa. |
| (App Service) Aktifkan log diagnostik untuk aplikasi dan instans . Pengelogan yang sering dapat memperlambat performa sistem, menambah biaya penyimpanan, dan menimbulkan risiko jika Anda memiliki akses tidak aman ke log. Ikuti praktik terbaik berikut: - Catat tingkat informasi yang tepat. - Tetapkan kebijakan retensi. - Simpan jejak audit akses resmi dan upaya yang tidak sah. - Perlakukan log sebagai data dan terapkan kontrol perlindungan data. |
Log diagnostik memberikan wawasan berharga tentang perilaku aplikasi Anda. Pantau pola lalu lintas dan identifikasi anomali. |
| (App Service) Manfaatkan sertifikat terkelola App Service untuk membongkar manajemen sertifikasi ke Azure. | App Service secara otomatis menangani proses seperti pengadaan sertifikat, verifikasi sertifikat, perpanjangan sertifikat, dan mengimpor sertifikat dari Key Vault. Atau, unggah sertifikat Anda ke Key Vault dan otorisasi penyedia sumber daya App Service untuk mengaksesnya. |
| (Paket App Service) Validasi perubahan aplikasi di slot penahapan sebelum Anda menukarnya dengan slot produksi. | Hindari waktu henti dan kesalahan. Kembali dengan cepat ke status baik terakhir yang diketahui jika Anda mendeteksi masalah setelah pertukaran. |
Efisiensi Performa
Efisiensi Performa adalah tentang mempertahankan pengalaman pengguna bahkan ketika ada peningkatan beban dengan mengelola kapasitas. Strategi ini mencakup penskalaan sumber daya, mengidentifikasi dan mengoptimalkan potensi hambatan, dan mengoptimalkan performa puncak.
Prinsip desain Efisiensi Performa menyediakan strategi desain tingkat tinggi untuk mencapai tujuan kapasitas tersebut terhadap penggunaan yang diharapkan.
Daftar periksa desain
Mulai strategi desain Anda berdasarkan daftar periksa tinjauan desain untuk Efisiensi Performa untuk menentukan garis besar berdasarkan indikator performa utama untuk Web Apps.
Identifikasi dan pantau indikator performa: Tetapkan target untuk indikator utama untuk aplikasi, seperti volume permintaan masuk, waktu yang dibutuhkan aplikasi untuk menanggapi permintaan, permintaan tertunda, dan kesalahan dalam respons HTTP. Pertimbangkan indikator utama sebagai bagian dari garis besar performa untuk beban kerja.
Ambil metrik App Service yang membentuk dasar indikator performa. Kumpulkan log untuk mendapatkan wawasan tentang penggunaan dan aktivitas sumber daya. Gunakan alat pemantauan performa aplikasi (APM), seperti Application Insights, untuk mengumpulkan dan menganalisis data performa dari aplikasi. Untuk informasi selengkapnya, lihat Referensi data pemantauan App Service.
Sertakan instrumentasi tingkat kode, pelacakan transaksi, dan pembuatan profil performa.
Menilai kapasitas: Simulasikan berbagai skenario pengguna untuk menentukan kapasitas optimal yang Anda butuhkan untuk menangani lalu lintas yang diharapkan. Gunakan Pengujian Beban untuk memahami perilaku aplikasi Anda di bawah tingkat beban yang berbeda.
Pilih tingkat yang tepat: Gunakan komputasi khusus untuk beban kerja produksi. Tingkat premium menawarkan SKU yang lebih besar dengan peningkatan kapasitas memori dan CPU, lebih banyak instans, dan lebih banyak fitur, seperti redundansi zona. Untuk informasi selengkapnya, lihat Tingkat harga Premium V3.
Optimalkan strategi penskalaan Anda: Jika memungkinkan, gunakan penskalaan otomatis alih-alih menyesuaikan jumlah instans secara manual saat beban aplikasi berubah. Dengan autoscaling, App Service menyesuaikan kapasitas server berdasarkan aturan atau pemicu yang telah ditentukan sebelumnya. Pastikan Anda melakukan pengujian performa yang memadai dan menetapkan aturan yang tepat untuk pemicu yang tepat.
Jika Anda memprioritaskan kesederhanaan selama penyiapan awal, gunakan opsi penskalaan otomatis yang tidak mengharuskan Anda menentukan aturan dan Anda hanya perlu menetapkan batas.
Memiliki sumber daya yang memadai tersedia untuk memastikan performa optimal. Alokasikan sumber daya dengan tepat untuk mempertahankan target performa, seperti waktu respons atau throughput. Pertimbangkan keseluruhan alokasi sumber daya jika diperlukan.
Saat Anda menentukan aturan skala otomatis, perhitungkan waktu yang diperlukan aplikasi Anda untuk menginisialisasi. Pertimbangkan overhead ini ketika Anda membuat semua keputusan penskalakan.
Gunakan penembolokan: Mengambil informasi dari sumber daya yang tidak sering berubah dan mahal untuk diakses memengaruhi performa. Kueri kompleks, termasuk gabungan dan beberapa pencarian, berkontribusi pada runtime. Lakukan penembolokan untuk meminimalkan waktu dan latensi pemrosesan. Hasil kueri cache untuk menghindari perjalanan pulang pergi berulang ke database atau back end dan mengurangi waktu pemrosesan untuk permintaan berikutnya.
Untuk informasi selengkapnya tentang menggunakan cache lokal dan terdistribusi dalam beban kerja, lihat Penembolokan.
Tinjau antipattern performa: Untuk memastikan aplikasi web berkinerja dan menskalakan sesuai dengan kebutuhan bisnis Anda, hindari antipattern khas. Berikut adalah beberapa antipattern yang dikoreksi App Service.
Antipattern Deskripsi Front End Sibuk Tugas intensif sumber daya dapat meningkatkan waktu respons untuk permintaan pengguna dan menyebabkan latensi tinggi.
Pindahkan proses yang menggunakan sumber daya yang signifikan ke backend yang terpisah. Gunakan broker pesan untuk mengantre tugas intensif sumber daya yang diambil ujung belakang untuk diproses secara asinkron.Tidak Ada Penembolokan Melayani permintaan dari cache perantara di depan database back-end untuk mengurangi latensi. Tetangga yang Berisik Sistem multipenyewa berbagi sumber daya di antara penyewa. Aktivitas satu penyewa dapat memiliki efek negatif pada penggunaan sistem penyewa lain. Lingkungan App Service menyediakan lingkungan yang sepenuhnya terisolasi dan khusus untuk menjalankan aplikasi App Service.
Rekomendasi
| Rekomendasi | Keuntungan |
|---|---|
| Aktifkan pengaturan AlwaysOn saat aplikasi berbagi satu paket App Service. Aplikasi App Service secara otomatis membongkar saat diam untuk menyimpan sumber daya. Permintaan berikutnya memicu cold start, yang dapat menyebabkan batas waktu permintaan. | Aplikasi tidak pernah dibongkar dengan Always On diaktifkan. |
| Pertimbangkan untuk menggunakan HTTP/2 untuk aplikasi guna meningkatkan efisiensi protokol. | Pilih HTTP/2 melalui HTTP/1.1 karena koneksi multipleks penuh HTTP/2, menggunakan kembali koneksi untuk mengurangi overhead, dan mengompresi header untuk meminimalkan transfer data. |
Tradeoffs
Anda mungkin harus membuat tradeoff desain jika Anda menggunakan pendekatan dalam daftar periksa pilar. Berikut adalah beberapa contoh keuntungan dan kelemahannya.
Kepadatan dan isolasi
Kepadatan yang lebih tinggi: Kolokasikan beberapa aplikasi dalam paket App Service yang sama untuk meminimalkan sumber daya. Semua aplikasi berbagi sumber daya seperti CPU dan memori, yang dapat menghemat uang dan mengurangi kompleksitas operasional. Pendekatan ini juga mengoptimalkan penggunaan sumber daya. Aplikasi dapat menggunakan sumber daya diam dari aplikasi lain jika pola beban berubah dari waktu ke waktu.
Pertimbangkan juga kerugiannya. Misalnya, lonjakan penggunaan atau ketidakstabilan aplikasi dapat memengaruhi performa aplikasi lain. Insiden dalam satu aplikasi juga dapat meresap ke aplikasi lain dalam lingkungan bersama, yang dapat memengaruhi keamanan.
Isolasi yang lebih tinggi: Isolasi membantu menghindari gangguan. Strategi ini berlaku untuk keamanan, performa, dan bahkan pemisahan lingkungan pengembangan, pengujian, dan produksi.
Lingkungan App Service memberikan kontrol yang lebih baik atas keamanan dan perlindungan data karena setiap aplikasi dapat memiliki pengaturan keamanannya sendiri. Lingkungan Anda dapat berisi pelanggaran karena isolasi membatasi radius ledakan. Ketidakcocokan sumber daya diminimalkan dari perspektif performa. Isolasi memungkinkan penskalaan independen berdasarkan permintaan tertentu dan perencanaan kapasitas individu.
Sebagai kerugian, pendekatan ini lebih mahal dan membutuhkan kekakuan operasional.
Strategi penskalakan yang andal
Strategi penskalakan yang terdefinisi dengan baik memastikan bahwa aplikasi Anda dapat menangani berbagai beban tanpa mengorbankan performa. Namun, ada pertukaran biaya. Operasi penskalan membutuhkan waktu. Ketika sumber daya baru dialokasikan, aplikasi harus diinisialisasi dengan benar sebelum dapat memproses permintaan secara efektif. Anda dapat menyediakan sumber daya secara berlebihan (instans prewarm) untuk menyediakan jaring pengaman. Tanpa kapasitas tambahan itu, selama fase inisialisasi, mungkin ada penundaan dalam melayani permintaan, yang memengaruhi pengalaman pengguna. Operasi penskalaan otomatis dapat memicu cukup awal untuk mengaktifkan inisialisasi sumber daya yang tepat pada saat pelanggan menggunakan sumber daya.
Sebagai kerugian, sumber daya yang kelebihan provisi lebih mahal. Anda dikenai biaya per detik untuk setiap instans, termasuk instans yang sudah diisi sebelumnya. Tingkat yang lebih tinggi mencakup instans yang sudah ada sebelumnya. Tentukan apakah kemampuan dengan tingkat yang lebih mahal sepadan dengan investasi.
Membangun redundansi
Redundansi menawarkan ketahanan tetapi juga menimbulkan biaya. Tujuan tingkat layanan (SLO) untuk beban kerja Anda menentukan ambang performa yang dapat diterima. Itu menjadi boros jika redundansi melebihi persyaratan SLO. Mengevaluasi apakah kelebihan redundansi meningkatkan SLO atau menambahkan kompleksitas yang tidak perlu.
Pertimbangkan juga kerugiannya. Misalnya, redundansi multi-wilayah memberikan ketersediaan tinggi tetapi menambah kompleksitas dan biaya karena sinkronisasi data, mekanisme failover, dan komunikasi antar-wilayah. Tentukan apakah redundansi zona dapat memenuhi SLA Anda.
Kebijakan Azure
Azure menyediakan serangkaian kebijakan bawaan yang luas yang terkait dengan App Service dan dependensinya. Sekumpulan kebijakan Azure dapat mengaudit beberapa rekomendasi sebelumnya. Misalnya, Anda dapat memeriksa apakah:
Kontrol jaringan yang tepat ada. Misalnya, Anda dapat menggabungkan segmentasi jaringan dengan menempatkan App Service di Azure Virtual Network melalui injeksi jaringan virtual untuk memiliki kontrol yang lebih besar atas konfigurasi jaringan. Aplikasi ini tidak memiliki titik akhir publik dan terhubung ke layanan Azure melalui titik akhir privat.
Kontrol identitas ada di tempatnya. Misalnya, aplikasi menggunakan identitas terkelola untuk mengautentikasi dirinya sendiri terhadap sumber daya lain. Autentikasi bawaan App Service (Easy Auth) memverifikasi permintaan masuk.
Fitur seperti penelusuran kesalahan jarak jauh dan autentikasi dasar dinonaktifkan, untuk mengurangi permukaan serangan.
Untuk tata kelola komprehensif, tinjau definisi bawaan Azure Policy dan kebijakan lain yang mungkin memengaruhi keamanan lapisan komputasi.
Rekomendasi Azure Advisor
Azure Advisor adalah konsultan cloud yang dipersonalisasi yang membantu Anda mengikuti cara terbaik untuk mengoptimalkan pengoperasian Azure Anda. Berikut adalah beberapa rekomendasi yang dapat membantu Anda meningkatkan keandalan, keamanan, efektivitas biaya, performa, dan keunggulan operasional instans aplikasi web Anda.
Langkah berikutnya
Pertimbangkan artikel berikut sebagai sumber daya yang menunjukkan rekomendasi yang disorot dalam artikel ini.
Gunakan arsitektur referensi ini sebagai contoh cara menerapkan rekomendasi ini ke beban kerja.
Jika Anda belum pernah menyebarkan aplikasi web, lihat Aplikasi web dasar.
Untuk arsitektur dasar sebagai titik awal Anda untuk penyebaran tingkat produksi, lihat Garis besar aplikasi web redundan zona yang sangat tersedia.
Gunakan dokumentasi produk berikut untuk membangun keahlian implementasi Anda: