Garis dasar aplikasi web yang sangat tersedia dan redundan antar zona

Azure App Service
Azure Application Gateway
Azure Storage
Database Azure SQL
Tautan Privat Azure
Microsoft Azure Virtual Network
Azure Monitor

Arsitektur garis besar ini dibangun pada arsitektur aplikasi web dasar dan memberikan panduan terperinci untuk merancang aplikasi web yang aman, redundan zona, dan sangat tersedia di Azure. Dalam arsitektur ini, Azure Application Gateway dengan Azure Web Application Firewall mengekspos titik akhir publik dan merutekan permintaan ke Azure App Service melalui Azure Private Link. Aplikasi App Service menggunakan integrasi jaringan virtual dan Private Link untuk berkomunikasi dengan aman dengan solusi platform as a service (PaaS) Azure seperti Azure Key Vault dan Azure SQL Database.

Penting

Contoh implementasi menunjukkan implementasi App Service garis besar ini di Azure. Gunakan sebagai fondasi untuk solusi produksi Anda.

Arsitektur

Diagram yang memperlihatkan arsitektur App Service garis besar dengan redundansi zona dan ketersediaan tinggi.

Unduh file Visio arsitektur ini.

Komponen

Arsitektur ini berbagi banyak komponen dengan arsitektur aplikasi web dasar. Daftar berikut ini hanya menjelaskan komponen yang berbeda dari atau memperluas arsitektur dasar:

  • Application Gateway adalah penyeimbang beban HTTP dan HTTPS lapisan-7 serta pengelola lalu lintas web. Dalam arsitektur ini, Application Gateway bertindak sebagai satu titik masuk publik. Application Gateway mengakhiri Keamanan Lapisan Transportasi (TLS) dan mengevaluasi aturan Azure Web Application Firewall. Kemudian meneruskan permintaan yang disetujui secara privat ke instans App Service di seluruh zona ketersediaan.

  • Azure Web Application Firewall adalah layanan cloud-native yang melindungi aplikasi web dari eksploitasi umum, seperti injeksi SQL dan scripting lintas situs (XSS). Dalam arsitektur ini, Azure Web Application Firewall berjalan di Application Gateway dan memblokir permintaan berbahaya sebelum mencapai App Service. Penyiapan ini meningkatkan keamanan dan membantu menjaga ketersediaan.

  • Key Vault adalah layanan yang menyimpan dan mengelola rahasia, kunci enkripsi, dan sertifikat dengan aman. Dalam arsitektur ini, ia menyimpan sertifikat TLS (X.509) yang digunakan Application Gateway, dan menyimpan rahasia aplikasi yang diakses App Service secara privat.

  • Microsoft Azure Virtual Network adalah layanan yang menyediakan jaringan virtual privat yang terisolasi dan aman di Azure. Dalam arsitektur ini, jaringan virtual menyediakan titik akhir privat, integrasi App Service, dan subnet khusus untuk Application Gateway. Penyiapan ini mengisolasi lalu lintas dan memungkinkan App Service berkomunikasi dengan aman dengan layanan Azure dependen melalui titik akhir privat.

  • Private Link adalah layanan jaringan yang menyediakan akses privat ke layanan Azure melalui jaringan backbone Microsoft untuk menghilangkan paparan internet publik. Dalam arsitektur ini, Private Link memungkinkan koneksi masuk privat ke App Service dan koneksi keluar privat dari App Service ke layanan seperti Key Vault, SQL Database, dan Azure Storage.

  • Azure DNS adalah layanan hosting untuk domain Domain Name System (DNS). Ini menyediakan penyelesaian nama dengan menggunakan infrastruktur Microsoft Azure. Zona DNS pribadi memetakan nama domain lengkap layanan (FQDN) ke alamat IP titik akhir pribadi. Dalam arsitektur ini, zona DNS privat memetakan domain default App Service dan domain layanan PaaS lainnya ke alamat titik akhir privat mereka sehingga semua lalu lintas tetap berada di jaringan privat.

Jaringan

Keamanan jaringan terpusat pada arsitektur garis besar App Service. Pada tingkat tinggi, arsitektur jaringan menyediakan kemampuan berikut:

  • Satu titik masuk aman untuk lalu lintas klien

  • Pemfilteran lalu lintas melalui Azure Web Application Firewall

  • Enkripsi TLS end-to-end untuk data saat transit

  • Meminimalkan pengambilan data tanpa izin melalui Private Link, yang menjaga lalu lintas tetap berada di dalam Azure

  • Pengelompokan logis dan isolasi sumber daya jaringan melalui segmentasi jaringan

Alur jaringan

Diagram yang memperlihatkan alur jaringan dalam arsitektur jaringan App Service garis besar.

Alur masuk

Langkah-langkah berikut menjelaskan alur masuk dari internet ke instans App Service:

  1. Pengguna mengeluarkan permintaan ke alamat IP publik Application Gateway.

  2. Application Gateway mengevaluasi aturan Web Application Firewall, yang melindungi dari serangan seperti injeksi XSS dan SQL. Jika aturan mendeteksi pelanggaran, Application Gateway mengembalikan kesalahan kepada pemohon dan berhenti memproses. Jika tidak, Application Gateway merutekan permintaan ke kumpulan back-end, yang dalam hal ini adalah domain default App Service.

  3. Zona privatelink.azurewebsites.net DNS privat ditautkan ke jaringan virtual. Zona DNS berisi catatan A yang memetakan domain default App Service ke alamat IP privat titik akhir privat App Service. Azure DNS menggunakan catatan ini untuk memetakan domain bawaan ke alamat IP titik akhir privat.

  4. Application Gateway merutekan permintaan ke instans App Service melalui titik akhir privat.

Aliran keluar

Langkah-langkah berikut menjelaskan alur keluar dari App Service ke layanan Azure PaaS:

  1. App Service mengirimkan permintaan ke nama DNS layanan Azure yang diperlukan, seperti Key Vault, Storage, SQL Database, atau layanan Azure lainnya yang mendukung Private Link. Fitur integrasi jaringan virtual App Service merutekan permintaan melalui jaringan virtual.

  2. Mirip dengan langkah 3 dalam alur masuk, zona DNS privat yang ditautkan berisi catatan A yang memetakan domain layanan Azure ke alamat IP titik akhir privatnya. Azure DNS menggunakan rekam ini untuk memetakan domain ke alamat IP titik akhir privat dari layanan tersebut.

  3. Jaringan virtual merutekan permintaan ke layanan melalui titik akhir privat.

Lalu lintas keluar yang tidak masuk ke layanan Azure PaaS keluar melalui alamat IP publik yang dibagikan oleh beberapa pelanggan. Misalnya, aplikasi web mungkin memanggil API publik selama permintaan HTTP. Untuk mengontrol jenis lalu lintas keluar ini, rutekan melalui perangkat jaringan seperti Azure Firewall. Firewall menerapkan terjemahan alamat jaringan sumber (SNAT), sehingga alur bersumber dari alamat IP publik firewall daripada kumpulan keluar App Service bersama, yang memberi Anda identitas keluar stabil yang dapat diizinkan oleh mitra hilir. Untuk informasi selengkapnya, lihat Mengontrol lalu lintas keluar dengan menggunakan Azure Firewall.

Implementasi Application Gateway

Application Gateway adalah penyeimbang beban lapisan-7 yang dapat diskalakan dan regional, yang mendukung Azure Web Application Firewall dan mengurangi beban TLS. Saat Anda menerapkan Application Gateway untuk lalu lintas masuk ke App Service, pertimbangkan poin-poin berikut:

  • Sebarkan Application Gateway dan konfigurasikan kebijakan Azure Web Application Firewall yang menggunakan kumpulan aturan yang dikelola Microsoft. Gunakan mode Pencegahan untuk memblokir serangan web sebelum mencapai layanan asal seperti App Service.

  • Terapkan enkripsi TLS end-to-end.

  • Gunakan titik akhir privat untuk menerapkan akses privat masuk ke App Service.

  • Terapkan autoscaling sehingga Application Gateway menyesuaikan kapasitas berdasarkan permintaan lalu lintas.

  • Pertimbangkan untuk menggunakan setidaknya tiga instance dan menerapkannya di semua zona ketersediaan yang didukung oleh wilayah Anda. Application Gateway sangat tersedia, tetapi membuat instans baru setelah kegagalan dapat memakan waktu hingga tujuh menit, bahkan untuk satu instans skala. Sebarkan beberapa instans di seluruh zona ketersediaan untuk memastikan bahwa instans tetap tersedia saat instans baru dimulai.

  • Blokir akses jaringan publik di App Service untuk memastikan isolasi jaringan. Di Bicep, atur publicNetworkAccess ke Disabled di bawah properties.

Aliran dari App Service ke layanan Azure

Arsitektur ini menggunakan integrasi jaringan virtual untuk merutekan lalu lintas App Service ke titik akhir privat melalui jaringan virtual. Arsitektur dasar tidak mengizinkan semua routing lalu lintas, sehingga semua lalu lintas keluar harus melalui jaringan virtual. Sebaliknya, ini hanya merutekan lalu lintas internal yang ditujukan kepada titik akhir privat.

Untuk layanan Azure yang tidak memerlukan akses internet publik, izinkan titik akhir privat dan blokir titik akhir publik. Titik akhir privat meningkatkan keamanan dengan mengizinkan App Service terhubung ke layanan Private Link langsung dari jaringan virtual privat tanpa alamat IP publik.

Dalam arsitektur ini, SQL Database, Storage, dan Key Vault semuanya memiliki titik akhir publik yang diblokir. Firewall layanan mereka hanya mengizinkan lalu lintas dari layanan Azure resmi lainnya. Konfigurasikan layanan Azure lainnya, seperti Azure Cosmos DB dan Azure Managed Redis, dengan titik akhir privat. Dalam arsitektur ini, Azure Monitor tidak menggunakan titik akhir privat, tetapi Anda dapat menerapkannya dengan menggunakan Azure Monitor Private Link Scope (AMPLS).

Arsitektur garis besar mengimplementasikan zona DNS privat untuk setiap layanan. Setiap zona DNS privat berisi catatan A yang memetakan FQDN layanan ke alamat IP titik akhir privat. Zona ditautkan ke jaringan virtual. Grup zona DNS privat secara otomatis membuat dan memperbarui catatan DNS untuk titik akhir privat.

Pertimbangkan poin-poin berikut saat Anda menerapkan integrasi jaringan virtual dan titik akhir privat:

Segmentasi dan keamanan jaringan virtual

Jaringan dalam arsitektur ini memiliki subnet terpisah untuk Application Gateway, komponen integrasi App Service, dan titik akhir privat. Kelompok keamanan jaringan (NSG) pada setiap subnet hanya mengizinkan lalu lintas masuk dan keluar yang diperlukan. Tabel berikut ini menjelaskan pilihan aturan NSG yang bisa Anda tambahkan ke setiap subnet.

Subnet Lalu Lintas Masuk Keluar
GatewaySubnet AppGw.In.Allow.ControlPlane: Izinkan akses pesawat kontrol masuk.

AppGw.In.Allow443.Internet: Izinkan akses HTTPS internet masuk.
AppGw.Out.Allow.PrivateEndpoints: Izinkan akses keluar ke PrivateEndpointsSubnet.

AppPlan.Out.Allow.AzureMonitor: Izinkan akses keluar ke Azure Monitor.
PrivateEndpointsSubnet Aturan default: Izinkan akses masuk dari jaringan virtual. Aturan default: Izinkan akses keluar ke jaringan virtual.
AppServiceSubnet Aturan default: Izinkan akses masuk dari jaringan virtual. AppPlan.Out.Allow.PrivateEndpoints: Izinkan akses keluar ke PrivateEndpointsSubnet.

AppPlan.Out.Allow.AzureMonitor: Izinkan akses keluar ke Azure Monitor.

Pertimbangkan poin-poin berikut saat Anda menerapkan segmentasi dan keamanan jaringan virtual:

  • Aktifkan perlindungan DDoS untuk jaringan virtual yang berisi subnet gateway aplikasi dengan alamat IP publik.

  • Tambahkan NSG ke setiap subnet jika memungkinkan. Gunakan aturan ketat yang memungkinkan fungsionalitas solusi penuh.

  • Gunakan grup keamanan aplikasi untuk mengelompokkan sumber daya secara logis, yang menyederhanakan pembuatan aturan NSG di lingkungan yang kompleks.

Tabel berikut ini memperlihatkan contoh skema jaringan.

Jenis Nama Rentang alamat
Jaringan virtual Awalan alamat 10.0.0.0/16
Subnet GatewaySubnet 10.0.1.0/24
Subnet AppServiceSubnet 10.0.0.0/24
Subnet PrivateEndpointsSubnet 10.0.2.0/27
Subnet AgentsSubnet 10.0.2.32/27

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat Anda gunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Well-Architected Framework.

Reliability

Keandalan membantu memastikan bahwa aplikasi Anda dapat memenuhi komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Daftar Periksa Tinjauan Desain untuk Keandalan.

Arsitektur App Service dasar berfokus pada redundansi zona untuk layanan regional utama. Zona ketersediaan adalah lokasi yang terpisah secara fisik dalam wilayah yang memberikan ketersediaan tinggi dan toleransi kesalahan. Saat Anda menyebarkan dua instans atau lebih di seluruh zona ketersediaan di wilayah yang didukung, kegagalan satu zona tidak memengaruhi yang lain. Pendekatan ini membantu menjaga ketersediaan layanan.

Arsitektur ini juga memastikan instans layanan Azure yang memadai untuk memenuhi permintaan. Bagian berikut memberikan panduan keandalan untuk setiap layanan utama dalam arsitektur.

Application Gateway

Sebarkan Application Gateway dalam konfigurasi zona-redundan dengan jumlah instans skala minimum tiga atau lebih. Beberapa instans memastikan bahwa layanan tetap tersedia pada saat kegagalan tanpa menunggu waktu mulai yang memakan waktu enam hingga tujuh menit yang diperlukan untuk menyiapkan instans baru.

App Service

  • Terapkan setidaknya dua instans App Service yang mendukung zona ketersediaan. Untuk ketahanan yang lebih tinggi, sebarkan setidaknya satu instans untuk setiap zona ketersediaan di wilayah Anda, ditambah instans tambahan dalam setiap zona untuk redundansi.

  • Terapkan titik akhir pemeriksaan kesehatan di aplikasi Anda dan konfigurasikan fitur pemeriksaan kesehatan Layanan Aplikasi untuk mengalihkan permintaan dari instans yang tidak berfungsi dengan baik. Untuk informasi selengkapnya, lihat Memantau instans App Service dengan menggunakan pemeriksaan kesehatan dan Pemeriksaan kesehatan di ASP.NET Core.

  • Kapasitas provisi berlebih untuk menangani kegagalan zona.

Blob Storage

  • Gunakan penyimpanan zona redundan (ZRS), yang mereplikasi data secara sinkron di tiga zona ketersediaan di wilayah tersebut. Buat akun penyimpanan ZRS Standar atau Penyimpanan redundan zona geografis Standar (GZRS) untuk memastikan replikasi data di seluruh zona ketersediaan.

  • Buat akun penyimpanan terpisah untuk penyebaran, aset web, dan data lainnya untuk mengelola dan mengonfigurasi setiap akun secara independen.

SQL Database

Keamanan

Keamanan memberikan jaminan terhadap serangan yang sengaja dan penyalahgunaan data serta sistem yang berharga bagi Anda. Untuk informasi selengkapnya, lihat daftar periksa tinjauan desain untuk Keamanan.

Arsitektur App Service dasar berfokus pada rekomendasi keamanan penting untuk aplikasi web Anda. Anda harus memahami cara kerja enkripsi dan identitas di setiap lapisan untuk membantu mengamankan beban kerja Anda.

App Service

  • Nonaktifkan metode autentikasi lokal untuk penyebaran situs Protokol Transfer File (FTP) dan Manajemen Kontrol Sumber (SCM).

  • Nonaktifkan debugging jarak jauh.

  • Gunakan versi TLS terbaru yang didukung semua klien Anda.

  • Aktifkan paket Microsoft Defender untuk App Service.

  • Gunakan versi terbaru platform yang didukung, bahasa komputer, protokol, dan kerangka kerja.

  • Pertimbangkan App Service Environment jika Anda memerlukan isolasi yang lebih tinggi atau akses jaringan yang aman.

Enkripsi

Aplikasi web produksi harus mengenkripsi data saat transit dengan menggunakan HTTPS. HTTPS bergantung pada TLS dan menggunakan kunci publik dan privat untuk enkripsi. Simpan sertifikat TLS (X.509) di Key Vault dan berikan izin Application Gateway untuk mengambil kunci privat. Untuk data tidak aktif, beberapa layanan secara otomatis mengenkripsi data, dan yang lain memungkinkan Anda menyesuaikan pengaturan.

Data dalam transmisi

Arsitektur garis besar mengenkripsi data saat transit dari pengguna ke aplikasi web di App Service.

Diagram yang memperlihatkan alur enkripsi App Service garis besar.

Alur kerja berikut menjelaskan cara kerja enkripsi pada tingkat tinggi:

  1. Pengguna mengirim permintaan HTTPS ke aplikasi web.

  2. Permintaan HTTPS mencapai gateway aplikasi.

  3. Gateway aplikasi menggunakan sertifikat (X.509) di Key Vault untuk membuat koneksi TLS yang aman dengan browser web pengguna. Gateway aplikasi mendekripsi permintaan HTTPS sehingga firewall aplikasi web dapat memeriksanya.

  4. Gateway aplikasi membuat koneksi TLS ke App Service untuk mengenkripsi ulang permintaan pengguna. App Service menyediakan dukungan asli untuk HTTPS, sehingga Anda tidak perlu menambahkan sertifikat ke App Service. Gateway aplikasi mengirimkan lalu lintas terenkripsi ke App Service. App Service mendekripsi lalu lintas, dan aplikasi web memproses permintaan.

Pertimbangkan rekomendasi berikut saat Anda mengonfigurasi enkripsi data dalam transit:

  • Buat atau unggah sertifikat Anda ke Key Vault. Enkripsi HTTPS memerlukan sertifikat (X.509). Anda memerlukan sertifikat dari otoritas sertifikat tepercaya untuk domain kustom Anda.

  • Simpan kunci privat ke sertifikat di Key Vault.

  • Berikan akses Application Gateway ke kunci privat sertifikat. Untuk informasi selengkapnya, lihat Memberikan izin dengan menggunakan kontrol akses berbasis peran Azure (Azure RBAC) dan Identitas terkelola untuk sumber daya Azure. Jangan gunakan kebijakan akses Key Vault untuk menyediakan akses. Kebijakan akses memungkinkan Anda hanya memberikan izin yang luas, bukan nilai tertentu.

  • Aktifkan enkripsi end-to-end. App Service merupakan kumpulan layanan back-end untuk aplikasi gateway. Saat Anda mengonfigurasi pengaturan back-end untuk kumpulan back-end, gunakan protokol HTTPS pada port back-end 443.

Data tidak aktif
  • Gunakan enkripsi data transparan untuk mengenkripsi data sensitif di SQL Database. Enkripsi data transparan mengenkripsi seluruh database, cadangan, dan file log transaksi dan tidak memerlukan perubahan pada aplikasi web Anda.

  • Tempatkan data sensitif dalam databasenya sendiri dan aktifkan enkripsi hanya untuk database tersebut. Pendekatan ini meminimalkan latensi enkripsi database.

  • Pahami dukungan enkripsi bawaan. Azure Storage secara otomatis mengenkripsi data tidak aktif melalui enkripsi sisi server (Standar Enkripsi Tingkat Lanjut (AES) 256-bit). Azure Monitor secara otomatis mengenkripsi data tidak aktif melalui kunci yang dikelola Microsoft.

Pemerintahan

Azure Policy membantu menerapkan keputusan arsitektur dan keamanan untuk aplikasi web. Ini dapat mencegah sumber daya yang tidak patuh disebarkan (mode tolak) atau menandainya untuk ditinjau (mode audit). Pendekatan ini membantu mendeteksi penyimpangan konfigurasi dari arsitektur yang Anda maksudkan, apakah penyimpangan terjadi melalui penyebaran infrastruktur sebagai kode (IaC) atau perubahan manual di portal Microsoft Azure.

Tempatkan semua sumber daya dalam arsitektur Anda di bawah tata kelola Azure Policy. Gunakan kebijakan bawaan atau inisiatif kebijakan jika memungkinkan untuk menerapkan topologi jaringan penting, fitur layanan, keamanan, dan keputusan pemantauan. Pertimbangkan kebijakan bawaan berikut:

  • App Service harus menonaktifkan akses jaringan publik.
  • App Service harus menggunakan integrasi jaringan virtual.
  • App Service harus menggunakan Private Link untuk menyambungkan ke layanan PaaS.
  • App Service harus menonaktifkan metode autentikasi lokal untuk penyebaran situs FTP dan SCM.
  • App Service sebaiknya menonaktifkan penelusuran kesalahan jarak jauh.
  • Aplikasi App Service harus menggunakan versi TLS terbaru.
  • Defender untuk App Service harus diaktifkan.
  • Azure Web Application Firewall harus diaktifkan untuk Application Gateway.

Lihat kebijakan bawaan lainnya untuk layanan utama seperti Application Gateway dan komponen jaringan, App Service, Key Vault, dan komponen pemantauan. Anda dapat membuat kebijakan kustom atau menggunakan kebijakan komunitas, seperti kebijakan dari zona pendaratan Azure, jika kebijakan bawaan tidak memenuhi kebutuhan Anda. Lebih suka kebijakan bawaan jika memungkinkan.

Manajemen identitas dan akses

Arsitektur garis besar App Service mengonfigurasi autentikasi dan otorisasi untuk identitas pengguna (pengguna) dan identitas beban kerja (sumber daya Azure). Ini menerapkan prinsip hak istimewa paling sedikit.

Identitas pengguna.
  • Gunakan mekanisme autentikasi terintegrasi untuk App Service, juga disebut EasyAuth. EasyAuth menyederhanakan integrasi penyedia identitas dengan aplikasi web Anda. Ini menangani autentikasi di luar aplikasi web Anda, sehingga Anda tidak perlu membuat perubahan kode yang signifikan.

  • Konfigurasikan URL balasan untuk domain kustom. Atur URL pengalihan ke https://<application-gateway-endpoint>/.auth/login/<provider>/callback.

    Ganti <application-gateway-endpoint> dengan alamat IP publik atau nama domain kustom gateway aplikasi Anda. Ganti <provider> dengan penyedia autentikasi Anda, seperti aad untuk ID Microsoft Entra.

    Untuk instruksi penyiapan, lihat pertimbangan Azure Front Door atau Integrasi Gateway Aplikasi dengan App Service.

Identitas beban kerja
  • Gunakan identitas terkelola untuk identitas beban kerja. Identitas terkelola menghilangkan kebutuhan pengembang untuk mengelola kredensial autentikasi.

  • Gunakan identitas terkelola yang ditetapkan pengguna. Identitas yang ditetapkan sistem dapat menyebabkan terjadinya kegagalan penyebaran IaC berdasarkan kondisi lomba dan urutan operasi. Identitas terkelola yang ditetapkan pengguna menghindari beberapa skenario kesalahan penyebaran ini. Untuk mengetahui informasi selengkapnya, lihat identitas terkelola.

Pengoptimalan Biaya

Pengoptimalan Biaya berfokus pada cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk optimalisasi biaya.

Perkiraan harga Azure ini hanya mencakup komponen dalam arsitektur ini, termasuk komponen yang dibawa dari aplikasi web Dasar. Ubah dengan perubahan arsitektur apa pun yang diperlukan kasus penggunaan Anda.

Keunggulan Operasional

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

Penyebaran untuk aplikasi App Service dasar mengikuti panduan arsitektur Azure Pipelines. Karena arsitektur garis besar menolak akses publik ke App Service dan mengamankan akun penyimpanan penyebaran dalam jaringan virtual, Anda tidak dapat menyebarkan dari luar jaringan virtual. Untuk mengatasi batasan ini, arsitektur menggunakan agen penyebaran yang dihost sendiri yang berjalan dalam jaringan virtual. Panduan penyebaran berikut berfokus pada penyebaran kode aplikasi, bukan perubahan infrastruktur atau database.

Diagram yang memperlihatkan arsitektur penyebaran App Service garis besar.

Alur penyebaran

  1. Jalur pelepasan mengirimkan permintaan tugas ke antrian tugas untuk agen yang di-host sendiri. Pekerjaan ini menginstruksikan agen untuk mengunggah artefak build file zip publikasi ke akun Storage.

  2. Agen penyebaran yang dihost sendiri melakukan polling antrean, mengambil permintaan pekerjaan, dan mengunduh pekerjaan dan membangun artefak.

  3. Agen penyebaran mandiri mengunggah file zip ke akun penyimpanan melalui titik akhir privat akun penyimpanan.

  4. Alur berlanjut, dan agen terkelola mengambil pekerjaan berikutnya. Agen terkelola melakukan panggilan antarmuka baris perintah (CLI) untuk memperbarui pengaturan aplikasi WEBSITE_RUN_FROM_PACKAGE untuk mereferensikan file zip publikasi baru untuk slot penahapan.

    az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
    
  5. Layanan Aplikasi menarik file zip publikasi baru dari penyimpanan melalui endpoint privat akun Penyimpanan. Ini memulai ulang instans penahapan dengan paket baru karena WEBSITE_RUN_FROM_PACKAGE diatur ke nama file yang berbeda.

  6. Pipeline melanjutkan dan menjalankan uji asap atau menunggu persetujuan manual. Setelah pengujian atau persetujuan yang berhasil, alur kerja menukar slot penahapan dan produksi.

Panduan penyebaran

Terapkan panduan penyebaran berikut untuk arsitektur garis besar:

  • Jalankan penyebaran Anda langsung dari paket di App Service untuk menghindari konflik penyebaran. Pendekatan ini memasang paket ZIP secara langsung sebagai direktori wwwroot yang hanya dapat dibaca daripada menyalin file. Ini menghilangkan konflik kunci file antara penyebaran dan runtime serta memastikan bahwa hanya aplikasi yang disebarkan sepenuhnya yang berjalan.

  • Sertakan nomor versi dalam nama file zip paket yang disebarkan. Saat Anda memperbarui WEBSITE_RUN_FROM_PACKAGE pengaturan aplikasi untuk mereferensikan paket penyebaran yang memiliki nama file yang berbeda, App Service secara otomatis menarik paket baru dan memulai ulang.

  • Gunakan slot penyebaran untuk penyebaran kode yang andal.

  • Pertimbangkan untuk menggunakan agen terkelola dan yang dihost sendiri.

  • Gunakan IaC untuk mengotomatiskan penyebaran infrastruktur.

  • Validasi performa dan ketahanan beban kerja terus menerus dengan menggunakan layanan seperti Azure Load Testing dan Azure Chaos Studio.

Konfigurasi

Aplikasi memerlukan nilai konfigurasi dan rahasia. Gunakan panduan berikut untuk manajemen konfigurasi dan rahasia:

  • Jangan pernah menyimpan rahasia seperti kata sandi atau kunci akses di kontrol sumber. Simpan rahasia di Key Vault.

  • Simpan konfigurasi aplikasi dalam konfigurasi App Service. Jika Anda memerlukan konfigurasi eksternal atau dukungan bendera fitur, gunakan Azure App Configuration.

  • Gunakan referensi Key Vault dalam konfigurasi App Service untuk mengekspos rahasia dengan aman di aplikasi Anda.

  • Konfigurasikan pengaturan aplikasi masing-masing slot jika slot produksi dan pengujian Anda memerlukan nilai yang berbeda. Secara default, pengaturan aplikasi bertukar dengan slot selama penyebaran.

  • Gunakan variabel lingkungan lokal atau fitur khusus platform untuk pengembangan lokal. Konfigurasi App Service mengekspos pengaturan aplikasi sebagai variabel lingkungan. Alat pengembangan seperti Visual Studio memungkinkan Anda mengatur variabel lingkungan di profil peluncuran dan menyediakan penyimpanan yang aman untuk pengaturan lokal melalui rahasia pengguna.

Pemantauan

Pemantauan mengumpulkan dan menganalisis data dari sistem teknologi informasi (IT) untuk memberikan pengamatan. Dalam arsitektur ini, pemantauan melacak kesehatan dan keamanan aplikasi web di beberapa lapisan, yang membantu mempertahankan operasi yang andal.

Pantau tiga lapisan kunci:

  • Kode aplikasi: Lacak telemetri khusus aplikasi dan metrik kustom.

  • Infrastruktur (runtime): Pantau lingkungan runtime App Service.

  • Platform (sumber daya Azure): Kumpulkan metrik dan log dari layanan Azure seperti Application Gateway, SQL Database, dan Key Vault.

Untuk informasi selengkapnya, lihat Log aktivitas Azure, log sumber daya Azure, dan pengelogan aplikasi App Service.

Memantau platforma

Pemantauan platform mengumpulkan data dari layanan Azure di arsitektur Anda.

Application Gateway

Application Gateway memantau kesehatan kumpulan backend melalui pemeriksaan kesehatan bawaan. Gunakan log akses Application Gateway untuk mengumpulkan informasi seperti tanda waktu, kode respons HTTP, dan jalur URL. Untuk informasi selengkapnya, lihat Log diagnostik dan kesehatan back-end.

App Service

App Service menyediakan kemampuan pemantauan bawaan dan terintegrasi untuk meningkatkan pengamatan. Jika aplikasi web Anda sudah memiliki fitur telemetri dan pemantauan, seperti instrumentasi dalam proses, fitur tersebut terus berfungsi di App Service.

  • Aktifkan instrumentasi otomatis untuk memperluas instrumentasi tanpa perubahan kode. Fitur ini menyediakan visibilitas pemantauan performa aplikasi (APM). Untuk informasi selengkapnya, lihat Memantau performa App Service.

  • Aktifkan pelacakan terdistribusi untuk melacak permintaan di beberapa layanan dan dependensi. Anda dapat memantau sistem cloud terdistribusi melalui pelacakan terdistribusi dan profiler performa.

  • Gunakan instrumentasi berbasis kode untuk telemetri kustom. Application Insights juga mendukung instrumentasi berbasis kode untuk telemetri aplikasi kustom. Tambahkan Distro OpenTelemetry Azure Monitor ke kode Anda.

  • Aktifkan log App Service untuk diagnostik tingkat platform. App Service menyediakan empat jenis log untuk pemecahan masalah: log aplikasi, log server web, pesan kesalahan terperinci, dan pelacakan permintaan yang gagal.

  • Gunakan pengelogan terstruktur. Tambahkan pustaka pengelogan terstruktur ke kode aplikasi Anda. Perbarui kode Anda untuk menggunakan pasangan kunci-nilai dan aktifkan log aplikasi di App Service untuk menyimpannya di ruang kerja Analitik Log Anda.

  • Aktifkan fitur pemeriksaan kesehatan App Service untuk menjaga ketersediaan. Pemeriksaan kesehatan mendeteksi instans yang tidak sehat, mengalihkan lalu lintas dari instans tersebut, dan menggantinya secara otomatis. Fitur ini memerlukan dua atau beberapa instans App Service.

Database

Efisiensi Performa

Efisiensi Performa mengacu pada kemampuan beban kerja Anda untuk menskalakan untuk memenuhi tuntutan pengguna secara efisien. Untuk informasi selengkapnya, lihat daftar periksa tinjauan desain untuk Efisiensi Performa.

Application Gateway

  • Terapkan penskalaan otomatis untuk Application Gateway untuk menskalakan masuk atau keluar untuk memenuhi permintaan.

  • Atur jumlah instans maksimum ke angka yang lebih tinggi dari kebutuhan yang Anda harapkan. Anda hanya membayar unit kapasitas yang Anda gunakan.

  • Atur jumlah instans minimum yang dapat menangani lonjakan kecil dalam lalu lintas. Anda dapat menggunakan penggunaan unit komputasi rata-rata untuk menghitung jumlah instans minimum Anda.

  • Ikuti panduan tentang mengubah ukuran subnet Application Gateway.

App Service

SQL Database

Penskalaan database melibatkan banyak pertimbangan di luar cakupan arsitektur ini. Untuk informasi selengkapnya tentang penskalaan SQL Database, lihat sumber daya berikut ini:

Panduan skalabilitas lainnya

  • Tinjau batas dan kuota langganan untuk memastikan bahwa layanan diskalakan sesuai permintaan.

  • Pertimbangkan caching untuk jenis-jenis data berikut demi meningkatkan performa dan skalabilitas:

    • Data transaksi semistatik
    • Status sesi
    • Output HTML kompleks

Langkah berikutnya