Aplikasi web dasar

Artikel ini menyediakan arsitektur dasar yang ditujukan untuk mempelajari tentang menjalankan aplikasi web di Azure App Service dalam satu wilayah.

Sistem

Gambar 1: Arsitektur Azure App Service Dasar

Unduh file Visio arsitektur ini.

Alur kerja

1. Pengguna mengeluarkan permintaan HTTPS ke domain default App Service di azurewebsites.net. Domain ini secara otomatis menunjuk ke IP publik bawaan App Service Anda. Koneksi TLS dibuat dari klien langsung ke layanan aplikasi. Sertifikat dikelola sepenuhnya oleh Azure.
2. Easy Auth, fitur Azure App Service, memastikan bahwa pengguna yang mengakses situs diautentikasi dengan ID Microsoft Entra.
3. Kode aplikasi Anda yang disebarkan ke App Service menangani permintaan. Misalnya, kode tersebut mungkin tersambung ke instans Azure SQL Database, menggunakan string koneksi yang dikonfigurasi di App Service yang dikonfigurasi sebagai pengaturan aplikasi.
4. Informasi tentang permintaan asli ke App Service dan panggilan ke Azure SQL Database dicatat di Application Insights.

Komponen

• ID Microsoft Entra adalah layanan manajemen identitas dan akses berbasis cloud. Ini menyediakan sarana kontrol identitas tunggal untuk mengelola izin dan peran bagi pengguna yang mengakses aplikasi web Anda. Ini terintegrasi dengan App Service dan menyederhanakan autentikasi dan otorisasi untuk aplikasi web.
• App Service adalah platform yang dikelola sepenuhnya untuk membangun, menyebarkan, dan menskalakan aplikasi web.
• Azure Monitor adalah layanan pemantauan yang mengumpulkan, menganalisis, dan bertindak berdasarkan data telemetri di seluruh penyebaran Anda.
• Azure SQL Database adalah layanan database relasional terkelola untuk data relasional.

Rekomendasi dan pertimbangan

Komponen yang tercantum dalam tautan arsitektur ini ke panduan layanan Azure Well-Architected. Panduan layanan memandu rekomendasi dan pertimbangan terperinci untuk layanan tertentu. Bagian ini memperluas panduan tersebut dengan menyoroti rekomendasi dan pertimbangan Utama Azure Well-Architected Framework yang berlaku untuk arsitektur ini. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Arsitektur dasar ini tidak ditujukan untuk penyebaran produksi. Arsitektur ini mendukung kesederhanaan dan efisiensi biaya atas fungsionalitas untuk memungkinkan Anda mengevaluasi dan mempelajari Azure App Service. Bagian berikut menguraikan beberapa kekurangan arsitektur dasar ini, bersama dengan rekomendasi dan pertimbangan.

Keandalan

Keandalan memastikan aplikasi Anda dapat mencapai komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keandalan.

Karena arsitektur ini tidak dirancang untuk penyebaran produksi, berikut ini menguraikan beberapa fitur keandalan penting yang dihilangkan dalam arsitektur ini:

• Paket App Service dikonfigurasi untuk Standard tingkatan, yang tidak memiliki dukungan zona ketersediaan Azure. App Service menjadi tidak tersedia jika terjadi masalah apa pun dengan instans, rak, atau pusat data yang menghosting instans.
• Azure SQL Database dikonfigurasi untuk Basic tingkatan, yang tidak mendukung redundansi zona. Ini berarti bahwa data tidak direplikasi di seluruh zona ketersediaan Azure, berisiko kehilangan data yang diterapkan jika terjadi pemadaman.
• Penyebaran ke arsitektur ini dapat mengakibatkan waktu henti dengan penyebaran aplikasi, karena sebagian besar teknik penyebaran mengharuskan semua instans yang sedang berjalan dimulai ulang. Pengguna mungkin mengalami kesalahan 503 selama proses ini. Ini dibahas dalam arsitektur garis besar melalui slot penyebaran. Desain aplikasi yang cermat, manajemen skema, dan penanganan konfigurasi aplikasi diperlukan untuk mendukung penyebaran slot bersamaan. Gunakan POC ini untuk merancang dan memvalidasi pendekatan penyebaran produksi berbasis slot Anda.
• Autoscaling tidak diaktifkan dalam arsitektur dasar ini. Untuk mencegah masalah keandalan karena kurangnya sumber daya komputasi yang tersedia, Anda harus melakukan provisi berlebih untuk selalu berjalan dengan komputasi yang cukup untuk menangani kapasitas bersamaan maks.

Lihat cara mengatasi masalah keandalan ini di bagian keandalan di aplikasi web redundan zona dasar yang sangat tersedia.

Jika beban kerja ini pada akhirnya akan memerlukan arsitektur aktif-aktif atau aktif-pasif multi-wilayah, lihat Aplikasi web multi-wilayah yang sangat tersedia untuk panduan tentang menyebarkan beban kerja yang dihosting App Service Anda di beberapa wilayah.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keamanan.

Karena arsitektur ini tidak dirancang untuk penyebaran produksi, berikut ini menguraikan beberapa fitur keamanan penting yang dihilangkan dalam arsitektur ini, bersama dengan rekomendasi dan pertimbangan keandalan lainnya:

• Arsitektur dasar ini tidak menerapkan privasi jaringan. Data dan bidang manajemen untuk sumber daya, seperti Azure App Service dan Azure SQL Server, dapat dijangkau melalui internet publik. Menghilangkan jaringan privat secara signifikan meningkatkan permukaan serangan arsitektur Anda. Untuk melihat cara menerapkan jaringan privat memastikan fitur keamanan berikut, lihat bagian jaringan dari aplikasi web redundan zona dasar yang sangat tersedia:

  • Satu titik masuk aman untuk lalu lintas klien
  • Lalu lintas jaringan difilter baik di tingkat paket maupun di tingkat DDoS.
  • Penyelundupan data diminimalkan dengan menjaga lalu lintas di Azure dengan menggunakan Private Link
  • Sumber daya jaringan dikelompokkan secara logis dan diisolasi satu sama lain melalui segmentasi jaringan.

• Arsitektur dasar ini tidak menyertakan penyebaran Azure Web Application Firewall. Aplikasi web tidak dilindungi dari eksploitasi dan kerentanan umum. Lihat implementasi garis besar untuk melihat bagaimana Web Application Firewall dapat diimplementasikan dengan Azure Application Gateway dalam arsitektur Azure App Services.

• Arsitektur dasar ini menyimpan rahasia seperti Azure SQL Server string koneksi di Pengaturan Aplikasi. Saat pengaturan aplikasi dienkripsi, saat pindah ke produksi, pertimbangkan untuk menyimpan rahasia di Azure Key Vault untuk meningkatkan tata kelola. Solusi yang lebih baik adalah menggunakan identitas terkelola untuk autentikasi dan tidak memiliki rahasia yang disimpan dalam string koneksi.

• Membiarkan penelusuran kesalahan jarak jauh dan titik akhir Kudu diaktifkan saat dalam pengembangan atau fase bukti konsep baik-baik saja. Saat pindah ke produksi, Anda harus menonaktifkan sarana kontrol, penyebaran, atau akses jarak jauh yang tidak perlu.

• Membiarkan metode autentikasi lokal untuk penyebaran situs FTP dan SCM diaktifkan tidak masalah saat dalam fase pengembangan atau bukti konsep. Saat pindah ke produksi, Anda harus menonaktifkan autentikasi lokal ke titik akhir tersebut.

• Anda tidak perlu mengaktifkan Pertahanan Microsoft untuk App Service dalam fase bukti konsep. Saat pindah ke produksi, Anda harus mengaktifkan Defender for App Service untuk menghasilkan rekomendasi keamanan yang harus Anda terapkan untuk meningkatkan postur keamanan Anda dan mendeteksi beberapa ancaman ke App Service Anda.

• Azure App Service menyertakan titik akhir SSL pada subdomain azurewebsites.net tanpa biaya tambahan. Permintaan HTTP dialihkan ke titik akhir HTTPS secara default. Untuk penyebaran produksi, Anda biasanya akan menggunakan domain kustom yang terkait dengan gateway aplikasi atau manajemen API di depan penyebaran App Service Anda.

• Gunakan mekanisme autentikasi terintegrasi untuk App Service ("EasyAuth"). EasyAuth menyederhanakan proses integrasi penyedia identitas ke dalam aplikasi web Anda. Ini menangani autentikasi di luar aplikasi web Anda, sehingga Anda tidak perlu membuat perubahan kode yang signifikan.

• Gunakan identitas terkelola untuk identitas beban kerja. Identitas terkelola menghilangkan kebutuhan pengembang untuk mengelola kredensial autentikasi. Arsitektur dasar mengautentikasi ke SQL Server melalui kata sandi dalam string koneksi. Pertimbangkan untuk menggunakan identitas terkelola untuk mengautentikasi ke Azure SQL Server.

Untuk beberapa pertimbangan keamanan lainnya, lihat Mengamankan aplikasi di Azure App Service.

Keunggulan operasional

Keunggulan operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keunggulan Operasional.

Bagian berikut memberikan panduan sekeliling konfigurasi, pemantauan, dan penyebaran aplikasi App Service Anda.

Konfigurasi aplikasi

Karena arsitektur dasar tidak ditujukan untuk produksi, arsitektur ini menggunakan konfigurasi App Service untuk menyimpan nilai dan rahasia konfigurasi. Menyimpan rahasia dalam konfigurasi App Service tidak masalah untuk fase PoC. Anda tidak menggunakan rahasia nyata dan tidak memerlukan tata kelola rahasia yang diperlukan beban kerja produksi.

Berikut ini adalah rekomendasi dan pertimbangan konfigurasi:

• Mulailah dengan menggunakan konfigurasi App Service untuk menyimpan nilai konfigurasi dan string koneksi dalam bukti penyebaran konsep. Pengaturan aplikasi dan string koneksi dienkripsi dan didekripsi tepat sebelum disuntikkan ke aplikasi Anda saat dimulai.
• Saat Anda pindah ke fase produksi, simpan rahasia Anda di Azure Key Vault. Penggunaan Azure Key Vault meningkatkan tata kelola rahasia dengan dua cara:
  • Eksternalisasi penyimpanan rahasia Anda ke Azure Key Vault memungkinkan Anda memusatkan penyimpanan rahasia Anda. Anda memiliki satu tempat untuk mengelola rahasia.
  • Dengan menggunakan Azure Key Vault, Anda dapat mencatat setiap interaksi dengan rahasia, termasuk setiap kali rahasia diakses.
• Saat beralih ke produksi, Anda dapat mempertahankan penggunaan konfigurasi Azure Key Vault dan App Service dengan menggunakan referensi Key Vault.

Diagnostik dan pemantauan

Selama fase bukti konsep, penting untuk mendapatkan pemahaman tentang log dan metrik apa yang tersedia untuk ditangkap. Berikut ini adalah rekomendasi dan pertimbangan untuk pemantauan dalam fase bukti konsep:

• Aktifkan pembuatan log diagnostik untuk semua sumber log item. Mengonfigurasi penggunaan semua pengaturan diagnostik membantu Anda memahami log dan metrik apa yang disediakan untuk Anda di luar kotak dan celah apa pun yang perlu Anda tutup menggunakan kerangka kerja pengelogan dalam kode aplikasi Anda. Saat pindah ke produksi, Anda harus menghilangkan sumber log yang tidak menambahkan nilai dan menambahkan kebisingan dan biaya ke sink log beban kerja Anda.
• Konfigurasikan pengelogan untuk menggunakan Azure Log Analytics. Azure Log Analytics memberi Anda platform yang dapat diskalakan untuk mempusatkan pengelogan yang mudah dikueri.
• Gunakan Application Insights atau alat Manajemen Performa Aplikasi (APM) lain untuk memancarkan telemetri dan log untuk memantau performa aplikasi.

Penyebaran

Berikut ini mencantumkan panduan tentang penyebaran aplikasi App Service Anda.

• Ikuti panduan di CI/CD untuk Azure Web Apps dengan Azure Pipelines untuk mengotomatiskan penyebaran aplikasi Anda. Mulai bangun logika penyebaran Anda di fase PoC. Menerapkan CI/CD di awal proses pengembangan memungkinkan Anda untuk melakukan iterasi dengan cepat dan aman pada aplikasi Saat Anda beralih ke produksi.
• Gunakan templat ARM untuk menyebarkan sumber daya Azure dan dependensinya. Penting untuk memulai proses ini dalam fase PoC. Saat Anda beralih ke produksi, Anda ingin kemampuan untuk secara otomatis menyebarkan infrastruktur Anda.
• Gunakan Templat ARM yang berbeda dan integrasikan dengan layanan Azure DevOps. Penyiapan ini memungkinkan Anda membuat lingkungan yang berbeda. Misalnya, Anda dapat mereplikasi skenario seperti produksi atau lingkungan pengujian beban hanya saat diperlukan dan menghemat biaya.

Untuk informasi selengkapnya, lihat bagian DevOps di Azure Well-Architected Framework.

Kontainer

Arsitektur dasar dapat digunakan untuk menyebarkan kode yang didukung langsung ke instans Windows atau Linux. Atau, App Service juga merupakan platform hosting kontainer untuk menjalankan aplikasi web kontainer Anda. App Service menawarkan berbagai kontainer bawaan. Jika Anda menggunakan aplikasi kustom atau multi-kontainer untuk lebih menyempurnakan lingkungan runtime Anda atau untuk mendukung bahasa kode yang tidak didukung secara asli, Anda harus memperkenalkan registri kontainer.

Sarana kontrol

Selama fase POC, dapatkan kenyamanan dengan sarana kontrol Azure App Service seperti yang diekspos melalui layanan Kudu. Layanan ini memaparkan API penyebaran umum, seperti penyebaran ZIP, mengekspos log mentah dan variabel lingkungan.

Jika menggunakan kontainer, pastikan untuk memahami kemampuan Kudu untuk Membuka sesi SSH ke kontainer untuk mendukung kemampuan penelusuran kesalahan tingkat lanjut.

Efisiensi kinerja

Efisiensi performa adalah kemampuan beban kerja Anda untuk diskalakan agar memenuhi permintaan yang diberikan oleh pengguna dengan cara yang efisien. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Efisiensi Performa.

Karena arsitektur ini tidak dirancang untuk penyebaran produksi, berikut ini menguraikan beberapa fitur efisiensi performa penting yang dihilangkan dalam arsitektur ini, bersama dengan rekomendasi dan pertimbangan lainnya.

Hasil dari bukti konsep Anda harus berupa pilihan SKU yang Anda perkirakan cocok untuk beban kerja Anda. Beban kerja Anda harus dirancang untuk memenuhi permintaan secara efisien melalui penskalaan horizontal dengan menyesuaikan jumlah instans komputasi yang disebarkan dalam Paket App Service. Jangan merancang sistem agar bergantung pada perubahan SKU komputasi agar selaras dengan permintaan.

• App Service dalam arsitektur dasar ini tidak memiliki penskalakan otomatis yang diimplementasikan. Layanan ini tidak secara dinamis menskalakan keluar atau masuk agar tetap selaras dengan permintaan secara efisien.
  • Tingkat Standar mendukung pengaturan skala otomatis untuk memungkinkan Anda mengonfigurasi autoscaling berbasis aturan. Bagian dari proses POC Anda harus sampai pada pengaturan penskalaan otomatis yang efisien berdasarkan kebutuhan sumber daya kode aplikasi Anda dan karakteristik penggunaan yang diharapkan.
  • Untuk penyebaran produksi, pertimbangkan tingkat Premium yang mendukung penskalaan otomatis di mana platform secara otomatis menangani keputusan penskalaan.
• Ikuti panduan untuk meningkatkan database individual tanpa waktu henti aplikasi jika Anda memerlukan tingkat layanan atau tingkat performa yang lebih tinggi untuk SQL Database.

Menyebarkan skenario ini

Panduan ini didukung oleh contoh implementasi yang menampilkan implementasi App Service dasar di Azure.

Langkah berikutnya

Sumber daya terkait

• Aplikasi web redundan zona dasar
• Aplikasi web multi-wilayah yang sangat tersedia

Dokumentasi produk:

• Gambaran umum Layanan Aplikasi
• Gambaran Umum Azure Monitor
• Ringkasan paket Azure App Service
• Gambaran Umum Analitik Log di Azure Monitor
• Apa itu ID Microsoft Entra?
• Apa itu Azure SQL Database?

Modul Microsoft Learn:

• Mengonfigurasi dan mengelola Azure Monitor
• Mengonfigurasi ID Microsoft Entra
• Mengonfigurasi Azure Monitor
• Menyebarkan dan mengonfigurasi server, instans, dan database untuk Azure SQL
• Menjelajahi Azure App Service
• Menghosting aplikasi web dengan Azure App Service
• Menghosting domain Anda di Azure DNS
• Menerapkan Azure Key Vault
• Mengelola pengguna dan grup di ID Microsoft Entra