Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Azure App Service adalah platform as a service (PaaS) yang menyediakan lingkungan hosting yang dikelola sepenuhnya untuk membangun, menyebarkan, dan menskalakan aplikasi web. Sebagai solusi PaaS, App Service mengabstraksi infrastruktur yang mendasar, memungkinkan Anda untuk fokus pada pengembangan aplikasi Anda. App Service (Aplikasi Web) menjalankan aplikasi Anda dalam konteks paket App Service, yang menentukan sumber daya, sistem operasi, wilayah, dan model harga (Sku) yang digunakan untuk menghosting aplikasi Anda.
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-prinsip pilar Well-Architected Framework Azure.
Penting
Cara menggunakan panduan ini
Setiap bagian berisi daftar periksa desain menyoroti pertimbangan dan strategi arsitektur untuk Azure App Service. Rekomendasi menawarkan panduan khusus untuk menerapkan 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 telah dipetakan sesuai perspektif desain. Gunakan rekomendasi untuk membangun bukti konsep Anda atau mengoptimalkan lingkungan Anda yang ada.
Arsitektur dasar yang menunjukkan rekomendasi utama: arsitektur dasar App Service.
cakupan teknologi
Tinjauan ini berfokus pada keputusan yang saling terkait untuk sumber daya Azure berikut:
- Rencana Layanan Aplikasi
- 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, aliran 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.
Prioritaskan alur pengguna: Tidak semua alur sama pentingnya. Identifikasi jalur penting dalam aplikasi Anda dan 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 lapisan 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, bagian belakang 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 mendasar atau yang diabstraksi dari App Service Memiliki redundansi komponen pada instans dan ketergantungan. Pantau kesehatan instans, performa jaringan, dan performa penyimpanan. Kegagalan dependensi eksternal Gunakan pola desain seperti pola Retry dan pola Circuit Breaker . Pantau dependensi eksternal dan atur batas waktu yang sesuai. Kegagalan karena lalu lintas dirutekan ke server yang tidak sehat Pantau kondisi 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, instance aplikasi terhubung dengan penyimpanan blob. Pertimbangkan untuk mengonfigurasi akun penyimpanan terkait tersebut dengan penyimpanan zona-redundan (ZRS) jika aplikasi menggunakan penyebaran zona-redundan.
Gunakan Beberapa Instans: Menjalankan aplikasi Anda hanya pada satu instans adalah titik kegagalan tunggal segera. Alokasikan beberapa instans untuk aplikasi Anda guna memastikan ketersediaannya tetap tinggi. Jika satu instans gagal, instans lain masih dapat menangani permintaan masuk. Perlu diingat bahwa kode aplikasi Anda harus dapat menangani beberapa instans tanpa masalah sinkronisasi saat membaca dari atau menulis ke sumber data.
Memiliki redundansi dalam komponen jaringan. Misalnya, gunakan alamat IP redundan zona dan penyeimbang beban.
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. Penskalaan horizontal (penskalaan keluar) memungkinkan Anda menambahkan lebih banyak instans untuk mendistribusikan beban, sementara penskalaan vertikal (peningkatan skala) melibatkan peningkatan kapasitas instans yang ada (CPU, memori). Berhati-hatilah terhadap penyediaan berlebihan, karena menambahkan instans yang tidak perlu meningkatkan biaya tanpa peningkatan kinerja yang jelas.
Terkadang Anda dapat meningkatkan skala untuk menangani beban. Namun, jika beban terus meningkat, lakukan skalabilitas ke instans baru. Lebih memilih Automatic atau Autoscaling daripada pendekatan manual. Selalu pertahankan buffer kapasitas tambahan selama operasi penskalaan untuk mencegah penurunan performa[Pilih opsi penskalaan untuk App Service](Penskalaan otomatis di Azure App Service)
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.
Usahakan untuk membuat aplikasi stateless kapan pun 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 kehilangan status sesi ketika 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 instance di dalam rencana, yang dapat memengaruhi reliabilitas dalam 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 dasar misi kritis dengan App Service.
Rencanakan pemulihan Anda: Redundansi sangat penting untuk kelangsungan bisnis. Beralih ke instans lain jika satu instans tidak dapat dijangkau. Jelajahi kemampuan pemulihan otomatis di App Service, seperti memperbaiki instans secara otomatis.
Terapkan pola desain untuk menangani penurunan layanan yang terkendali dalam menghadapi kegagalan sementara, seperti masalah konektivitas jaringan, serta peristiwa skala besar seperti gangguan regional. Pertimbangkan pola desain berikut:
Pola Bulkhead segmen aplikasi Anda ke dalam grup terisolasi untuk mencegah kegagalan memengaruhi seluruh sistem.
Pola Queue-Based Penyeimbangan Beban mengantre item pekerjaan yang berfungsi sebagai penyangga untuk meratakan 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.
Melakukan pengujian keandalan: Melakukan 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 langganan dan layanan Azure, kuota, dan batasan.
Menggunakan fitur Pemeriksaan Kesehatan untuk mengidentifikasi pekerja yang tidak responsif: App Service memiliki kemampuan bawaan yang secara berkala melakukan ping jalur tertentu dari aplikasi web Anda. Platform melakukan ping jalur ini untuk menentukan apakah aplikasi Anda sehat dan merespons permintaan. Ketika situs Anda diskalakan ke beberapa instance, App Service akan mengecualikan instance yang tidak sehat dari melayani permintaan, sehingga meningkatkan ketersediaan Anda secara keseluruhan. Jalur pemeriksaan kesehatan aplikasi harus memeriksa komponen penting aplikasi, seperti database, cache, atau layanan pesan Anda. Ini memastikan bahwa status yang dikembalikan oleh jalur pemeriksaan kesehatan adalah gambaran yang akurat tentang kesehatan keseluruhan aplikasi Anda. Atur Jalur Pemeriksaan Kesehatan Anda
Gunakan fitur Auto-Heal: Terkadang aplikasi Anda mungkin mengalami perilaku tak terduga yang dapat diselesaikan dengan hidupkan ulang sederhana. Fitur Auto-Heal memungkinkan Anda menentukan 'kondisi' yang akan memicu Auto-Heal dan 'tindakan' yang akan dimulai Auto-Heal ketika kondisi terpenuhi. alat diagnostik Layanan Aplikasi dan fitur Auto-Heal
Laporan Skor Ketahanan App Service: Untuk meninjau rekomendasi praktik terbaik yang disesuaikan, lihat Laporan Skor Ketahanan.Laporan Skor Ketahanan App Service
Rekomendasi
Rekomendasi | Manfaat |
---|---|
(App Service) Pilih tingkat Premium v3 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 V3 menawarkan fitur penskalaan tingkat lanjut dan memastikan redundansi jika kegagalan terjadi. |
(App Service) Mengaktifkan redundansi zona. Pertimbangkan untuk menyediakan lebih dari tiga instance untuk meningkatkan kemampuan menghadapi kesalahan. Periksa dukungan regional untuk redundansi zona karena tidak semua wilayah menawarkan fitur ini. |
Aplikasi Anda dapat bertahan terhadap kegagalan dalam satu zona saat beberapa instans tersebar di berbagai zona. Lalu lintas secara otomatis beralih ke instans yang sehat di zona yang lain dan menjaga keandalan aplikasi jika satu zona tidak tersedia. |
(Aplikasi Web) Pertimbangkan untuk menonaktifkan fitur afinitas ARR (application request routing). Afinitas ARR membuat sesi berkelanjutan yang mengembalikan 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 agar instance Layanan Aplikasi Anda tetap tanpa status. Layanan Aplikasi tanpa status mengurangi kompleksitas dan memastikan perilaku yang konsisten di seluruh sistem. Hapus sesi tetap sehingga App Service dapat menambahkan atau menghapus instans untuk penskalaan secara horizontal. |
(Aplikasi Web) 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 batas dilanggar. Penyembuhan otomatis memungkinkan pemeliharaan proaktif otomatis. |
(Aplikasi Web) 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. Penyeimbang beban mengalihkan lalu lintas dari instans yang tidak sehat, mengarahkan pengguna ke simpul yang sehat. |
Keamanan
Tujuan pilar Keamanan adalah untuk memberikan jaminan kerahasiaan, integritas, dan ketersediaan terhadap beban kerja.
Prinsip desain Security menyediakan strategi desain tingkat tinggi untuk mencapai tujuan tersebut secara spesifik dengan menerapkan pendekatan pada desain teknis dalam konteks hosting pada App Service.
Daftar periksa desain
Mulai strategi desain Anda berdasarkan daftar periksa tinjauan desain untuk Keamanan dan mengidentifikasi kerentanan serta kontrol untuk memperbaiki 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 dukungan tumpukan yang sudah tidak didukung lagi.
Buat segmentasi melalui batas isolasi untuk mengatasi pelanggaran: Terapkan dengan 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. Menyuntikkan aplikasi App Service di jaringan virtual Azure untuk isolasi dan menentukan 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.
Terapkan 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, Pembaca, dan Pemilik generik.
Terapkan kontrol keamanan jaringan: Integrasikan App Service Anda dengan jaringan virtual (VNet) untuk mengontrol lalu lintas keluar. Gunakan titik akhir privat untuk mengontrol lalu lintas masuk dan membatasi akses ke App Service Anda dari dalam VNet Anda dan menonaktifkan akses internet publik. Mengamankan jaringan Anda, mengontrol lalu lintas Masuk dan Keluar
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 di subnet titik akhir privat agar 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-fitur jaringan pada App Service.
Mengenkripsi data: Melindungi data saat transit dengan Keamanan Lapisan Transportasi (TLS) dari ujung ke ujung. Gunakan kunci yang dikelola pelanggan Anda untuk enkripsi penuh data yang disimpan. Untuk informasi selengkapnya, lihat Enkripsi tidak aktif menggunakan kunci yang dikelola pelanggan.
Jangan gunakan protokol warisan seperti TLS 1.0 dan 1.1. Pastikan bahwa semua aplikasi web hanya menggunakan HTTPS dan terapkan TLS 1.2 atau yang lebih tinggi. Versi TLS minimum yang ditetapkan adalah 1.2. Untuk informasi selengkapnya, lihat gambaran umum App Service TLS.
Semua instans App Service Anda memiliki nama domain default. Gunakan domain kustom dan amankan domain tersebut dengan sertifikat.
Enkripsi TLS End-to-end: Enkripsi TLS end-to-end tersedia dalam paket App Service Premium. Fitur ini mengenkripsi lalu lintas Anda di seluruh transaksi, meminimalkan risiko intersepsi lalu lintas.
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 terbatas di aplikasi web Anda untuk hanya menerima permintaan dari domain, header, dan kriteria lainnya yang diizinkan. Menerapkan kebijakan CORS dengan definisi kebijakan Azure bawaan.
Gunakan identitas terkelola: Aktifkan identitas terkelola untuk App Service Anda untuk mengakses layanan Azure lainnya dengan aman tanpa perlu mengelola kredensial. Pelajari tentang identitas terkelola.
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. Lihat panduan pemantauan log untuk panduan terperinci.
Pertimbangkan pengelogan sebagai bagian dari proses pemodelan ancaman Saat Anda menilai ancaman.
Rekomendasi
Rekomendasi | Manfaat |
---|---|
(Aplikasi Web) Menetapkan 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 Anda jika Anda menggunakan kontainer dalam penyebaran Anda. |
Aplikasi mengambil rahasia dari Key Vault untuk mengautentikasi komunikasi keluar dari aplikasi. Azure mengelola identitas dan tidak mengharuskan Anda untuk menyediakan atau mengganti rahasia apa pun. Anda memiliki identitas yang berbeda untuk mengontrol dengan lebih terperinci. Identitas yang terpisah memudahkan pencabutan jika identitas terganggu. |
(Aplikasi Web) Konfigurasikan 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. |
(Aplikasi Web) 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 OpenID Connect. 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. |
(Aplikasi Web) 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. |
(Aplikasi Web) Untuk menerapkan pengerasan: - Nonaktifkan autentikasi dasar yang menggunakan nama pengguna dan kata sandi untuk mendukung autentikasi berbasis ID Microsoft Entra. - Nonaktifkan debugging jarak jauh agar 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. |
(Aplikasi Web) 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. |
(App Service) Aktifkan Microsoft Defender untuk Cloud di 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. |
(App Service) Aktifkan pencatatan 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 area 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 tinjauan 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, dihitung hingga detik, berdasarkan tingkat harga paket App Service Anda. Biaya berlaku untuk setiap instans VM yang diperluas dalam paket Anda, tergantung pada waktu yang Anda alokasikan untuk instans tersebut. Perhatikan sumber daya komputasi yang jarang digunakan yang dapat meningkatkan biaya Anda akibat alokasi berlebihan karena pemilihan SKU yang tidak optimal, atau konfigurasi pengurangan 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 Anda atau brankas kunci untuk melindungi rahasia beban kerja, yang terintegrasi dengan sumber daya App Service Anda juga dapat menambah biaya. Untuk informasi selengkapnya, lihat model penagihan layanan aplikasi.
Pertimbangkan trade-off antara kepadatan dan isolasi: Anda dapat menggunakan App Service plan untuk menghosting beberapa aplikasi pada komputasi yang sama, dengan memanfaatkan lingkungan bersama untuk menghemat biaya. Untuk informasi selengkapnya, lihat Tradeoffs.
Evaluasi efek dari strategi penskalaan Anda terhadapbiaya: Anda harus merancang, menguji, dan mengonfigurasi dengan benar untuk penskalaan ke luar dan ke dalam saat Anda menerapkan penskalaan otomatis. Tetapkan batas maksimum dan minimum secara spesifik pada autoscaling.
Secara proaktif menginisialisasi aplikasi untuk penskalaan yang andal. Misalnya, jangan menunggu hingga CPU mencapai 95% penggunaan. Sebagai gantinya, memicu penskalaan pada 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 cache untuk meminimalkan biaya transfer data. Mulai dengan caching dalam memori lokal, kemudian jelajahi opsi caching 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 mereka secara strategis untuk skenario seperti penyebaran biru-hijau yang dapat beralih antara 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 | Manfaat |
---|---|
(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. |
(App Service) Manfaatkan diskon dan jelajahi harga pilihan untuk: - Lingkungan tingkat rendah dengan rencana pengembangan/pengujian . - reservasi Azure dan paket penghematan Azure untuk komputasi khusus yang Anda sediakan di tingkat Premium V3 dan App Service Environment. 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. |
(Aplikasi Web) Memantau biaya yang dikeluarkan sumber daya App Service. Jalankan alat analisis biaya di portal Microsoft Azure. Membuat 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. |
(App Service) Menskalakan ketika permintaan menurun. Untuk menskalakan ke dalam, 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 , observabilitas, dan manajemen rilis.
Prinsip desain Operational Excellence menyediakan strategi desain tingkat tinggi untuk mencapai tujuan tersebut menuju persyaratan operasional beban kerja.
Daftar periksa desain
Mulai strategi desain Anda berdasarkan daftar periksa tinjauan desain untuk Keunggulan Operasional, guna menentukan proses untuk observabilitas, pengujian, dan penyebaran terkait 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.
Gunakan Pertukaran dengan Pratampil (pertukaran multi-fase). Pertukaran dengan Tinjauan Awal dapat digunakan untuk menguji aplikasi di slot penahapan dibandingkan dengan pengaturan produksi dan juga memanaskan aplikasi. Setelah melakukan pengujian dan pemanasan semua jalur yang diperlukan, Anda kemudian dapat menyelesaikan pertukaran dan aplikasi akan mulai menerima lalu lintas produksi tanpa memulai ulang.
Jalankan pengujian otomatis: Sebelum Anda mempromosikan rilis aplikasi web Anda, 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.
Mengotomatiskan penyebaran: Gunakan alur CI/CD dengan Azure DevOps atau GitHub Actions untuk mengotomatiskan penyebaran dan mengurangi upaya manual Penyebaran berkelanjutan ke Azure App Service.
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 App Service aplikasi web Anda.
Setiap cap mewakili unit mandiri yang dapat Anda perbesar atau perkecil dengan cepat. Unit yang didasarkan pada stempel ini bersifat sementara dan tanpa status. Desain tanpa status (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 mengatur komponen dengan kemampuan 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 bersifat sementara.
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 | Manfaat |
---|---|
(Aplikasi Web) 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. |
(Aplikasi Web) Mengaktifkan 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 yang diizinkan 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. |
(Aplikasi Web) Manfaatkan sertifikat terkelola App Service untuk mengalihkan manajemen sertifikat 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. |
(App Service) Validasikan perubahan aplikasi di slot staging sebelum 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 Kinerja guna menentukan garis dasar berdasarkan indikator kinerja utama untuk Aplikasi Web.
Mengidentifikasi dan memantau indikator performa: Tetapkan target untuk indikator utama untuk aplikasi, seperti volume permintaan masuk, waktu yang dibutuhkan aplikasi untuk merespons 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: Mensimulasikan 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.
Pilihtingkat yang tepat : Gunakan komputasi khusus untuk beban kerja produksi. Tingkat premium V3 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 tarif 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 skala.
Gunakanpenembolokan: Mengambil informasi dari sumber daya yang tidak sering berubah dan mahal untuk diakses memengaruhi performa. Kueri kompleks, termasuk gabungan dan beberapa pencarian, berkontribusi pada waktu eksekusi. Lakukan penyimpanan sementara untuk meminimalkan waktu dan latensi pemrosesan. Cache hasil kueri untuk menghindari pengambilan data 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 Cache.
Tinjau pola antipatif performa: Untuk memastikan aplikasi web berkinerja baik dan meningkatkan skalanya sesuai dengan persyaratan bisnis Anda, hindari pola antipatif yang umum . Berikut adalah beberapa antipattern yang dikoreksi App Service.
Antipatern Deskripsi Front End Sibuk Tugas intensif sumber daya dapat meningkatkan waktu respons untuk permintaan pengguna dan menyebabkan latensi tinggi.
Pindahkan proses yang mengonsumsi sumber daya signifikan ke back end terpisah. Gunakan broker pesan untuk mengantre tugas yang membutuhkan sumber daya besar yang diproses oleh sisi belakang secara asinkron.Tanpa Penembolokan Melayani permintaan dari cache perantara di depan database back-end untuk mengurangi latensi. Tetangga berisik Sistem multipenyewa berbagi sumber daya antar 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 | Manfaat |
---|---|
(App Service) Mengaktifkan pengaturan AlwaysOn saat aplikasi berbagi satu paket App Service. Aplikasi App Service secara otomatis dinonaktifkan saat tidak aktif untuk menghemat sumber daya. Permintaan berikutnya memicu cold start (memulai dari awal), yang dapat menyebabkan permintaan habis waktu. | Aplikasi tidak pernah ditutup saat Always On diaktifkan. |
(Web Apps) Pertimbangkan untuk menggunakan http/2 untuk aplikasi guna meningkatkan efisiensi protokol. | Pilih HTTP/2 daripada HTTP/1.1 karena HTTP/2 memultipleks secara penuh koneksi, memanfaatkan kembali koneksi untuk mengurangi overhead, dan mengompresi tajuk untuk meminimalkan transfer data. |
Kompromi
Anda mungkin harus membuat kompromi dalam 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, seperti perebutan sumber daya. 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. Untuk aplikasi penting yang membutuhkan ketersediaan dan performa tinggi, lingkungan terisolasi seperti App Service Environment V3 (ASE) menyediakan sumber daya khusus tetapi dengan biaya yang lebih tinggi. Pertimbangkan untuk menggunakan lingkungan bersama untuk beban kerja non-kritis dan lingkungan terisolasi untuk aplikasi penting misi.
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. Kontensi sumber daya diminimalkan dari perspektif kinerja. Isolasi memungkinkan penskalaan independen berdasarkan permintaan tertentu dan perencanaan kapasitas individu.
Sebagai kerugian, pendekatan ini lebih mahal dan membutuhkan kekakuan operasional.
strategi penskalaan yang dapat diandalkan
Strategi penskalakan yang terdefinisi dengan baik memastikan bahwa aplikasi Anda dapat menangani berbagai beban tanpa mengorbankan performa. Namun, ada kompromi biaya. Operasi penskalaan 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 dengan cukup awal untuk memastikan inisialisasi sumber daya dilakukan dengan tepat pada saat pelanggan menggunakan sumber daya.
Kerugian dari sumber daya yang dialokasikan berlebih adalah biayanya lebih tinggi. Anda dikenai biaya per detik untuk setiap instans, termasuk instans yang sudah diisi sebelumnya. Tingkat yang lebih tinggi mencakup instans yang sudah dipersiapkan. Tentukan apakah kemampuan dengan tingkat yang lebih mahal sepadan dengan investasi.
redundansi bangunan
Redundansi menawarkan ketahanan tetapi juga menimbulkan biaya. Tujuan tingkat layanan (SLO) untuk beban kerja Anda menentukan ambang performa yang dapat diterima. Menjadi boros jika redundansi melampaui 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 telah diterapkan. 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 praktik terbaik untuk mengoptimalkan penyebaran Azure Anda. Berikut adalah beberapa rekomendasi yang dapat membantu Anda meningkatkan keandalan, keamanan, efektivitas biaya, performa, dan keunggulan operasional instans aplikasi web Anda.
- Keandalan
- Keamanan
- Pengoptimalan Biaya
- Performa
- Keunggulan Operasional
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 Basic.
Untuk arsitektur dasar sebagai titik awal Anda untuk penyebaran tingkat produksi, lihat Baseline aplikasi web zona redundan yang sangat tersedia.
Gunakan dokumentasi produk berikut untuk membangun keahlian implementasi Anda: