Pola aplikasi web yang andal untuk .NET - Terapkan pola

Artikel ini memperlihatkan kepada Anda cara menerapkan pola Reliable Web App. Pola Reliable Web App adalah serangkaian prinsip dan teknik implementasi yang menentukan bagaimana Anda harus memodifikasi aplikasi web (replatform) saat bermigrasi ke cloud. Ini berfokus pada pembaruan kode minimal yang perlu Anda buat agar berhasil di cloud.

Untuk memfasilitasi aplikasi panduan ini, ada implementasi referensi pola Reliable Web App yang dapat Anda sebarkan.

Arsitektur implementasi referensi. Unduh file Visio arsitektur ini.

Panduan berikut menggunakan implementasi referensi sebagai contoh di seluruh. Untuk menerapkan pola Reliable Web App, ikuti rekomendasi ini yang selaras dengan pilar Kerangka Kerja Yang Dirancang Dengan Baik:

Keandalan

Keandalan memastikan aplikasi Anda dapat mencapai komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Daftar periksa Tinjauan desain untuk Keandalan. Pola Reliable Web App memperkenalkan dua pola desain utama di tingkat kode untuk meningkatkan keandalan: pola Coba Lagi dan pola Pemutus Sirkuit.

Gunakan pola Coba Lagi

Pola Coba lagi mengatasi gangguan layanan sementara, kesalahan sementara yang disebut, yang biasanya diselesaikan dalam hitungan detik. Kesalahan ini sering diakibatkan oleh pembatasan layanan, distribusi beban dinamis, dan masalah jaringan di lingkungan cloud. Menerapkan pola Coba Lagi melibatkan mengirim ulang permintaan yang gagal, memungkinkan penundaan dan upaya yang dapat dikonfigurasi sebelum kegagalan berakhir.

Aplikasi yang menggunakan pola Coba Lagi harus mengintegrasikan kit pengembangan perangkat lunak klien (SDK) Azure dan mekanisme coba lagi khusus layanan untuk meningkatkan efisiensi. Aplikasi yang tidak memiliki pola ini harus mengadopsinya menggunakan panduan berikut.

Coba layanan Azure dan SDK klien terlebih dahulu

Sebagian besar layanan Azure dan SDK klien memiliki mekanisme coba lagi bawaan. Anda harus menggunakan mekanisme coba lagi bawaan untuk layanan Azure untuk mempercepat implementasi.

Contoh: Implementasi referensi menggunakan ketahanan koneksi di Entity Framework Core untuk menerapkan pola Coba Lagi dalam permintaan ke Azure SQL Database (lihat kode berikut).

services.AddDbContextPool<ConcertDataContext>(options => options.UseSqlServer(sqlDatabaseConnectionString,
    sqlServerOptionsAction: sqlOptions =>
    {
        sqlOptions.EnableRetryOnFailure(
        maxRetryCount: 5,
        maxRetryDelay: TimeSpan.FromSeconds(3),
        errorNumbersToAdd: null);
    }));

Gunakan pustaka Polly saat pustaka klien tidak mendukung percobaan ulang

Anda mungkin perlu melakukan panggilan ke dependensi yang bukan layanan Azure atau tidak mendukung pola Coba Lagi secara asli. Dalam hal ini, Anda harus menggunakan pustaka Polly untuk menerapkan pola Coba Lagi. Polly adalah pustaka ketahanan .NET dan penanganan kesalahan sementara. Dengan itu, Anda dapat menggunakan API yang fasih untuk menjelaskan perilaku di lokasi pusat aplikasi.

Contoh: Implementasi referensi menggunakan Polly untuk menyiapkan injeksi dependensi ASP.NET Core. Polly memberlakukan pola Coba Lagi setiap kali kode membuat objek yang memanggil IConcertSearchService objek. Dalam kerangka kerja Polly, perilaku tersebut dikenal sebagai kebijakan. Kode mengekstrak kebijakan ini dalam GetRetryPolicy metode , dan GetRetryPolicy metode menerapkan pola Coba Lagi setiap kali aplikasi web front-end memanggil layanan pencarian konser API web (lihat kode berikut).

private void AddConcertSearchService(IServiceCollection services)
{
    var baseUri = Configuration["App:RelecloudApi:BaseUri"];
    if (string.IsNullOrWhiteSpace(baseUri))
    {
        services.AddScoped<IConcertSearchService, MockConcertSearchService>();
    }
    else
    {
        services.AddHttpClient<IConcertSearchService, RelecloudApiConcertSearchService>(httpClient =>
        {
            httpClient.BaseAddress = new Uri(baseUri);
            httpClient.DefaultRequestHeaders.Add(HeaderNames.Accept, "application/json");
            httpClient.DefaultRequestHeaders.Add(HeaderNames.UserAgent, "Relecloud.Web");
        })
        .AddPolicyHandler(GetRetryPolicy())
        .AddPolicyHandler(GetCircuitBreakerPolicy());
    }
}

private static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy()
{
    var delay = Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromMilliseconds(500), retryCount: 3);
    return HttpPolicyExtensions
      .HandleTransientHttpError()
      .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
      .WaitAndRetryAsync(delay);
}

Penangan kebijakan untuk RelecloudApiConcertSearchService instans menerapkan pola Coba Lagi pada semua permintaan ke API. Ini menggunakan HandleTransientHttpError logika untuk mendeteksi permintaan HTTP yang dapat diulang dengan aman dan kemudian mencoba kembali permintaan berdasarkan konfigurasi. Ini termasuk beberapa keacakan untuk memuluskan potensi ledakan lalu lintas ke API jika terjadi kesalahan.

Menggunakan pola Pemutus Sirkuit

Memasangkan pola Retry dan Circuit Breaker memperluas kemampuan aplikasi untuk menangani gangguan layanan yang tidak terkait dengan kesalahan sementara. Pola Circuit Breaker mencegah aplikasi terus mencoba mengakses layanan yang tidak responsif. Pola Circuit Breaker merilis aplikasi dan menghindari pemborosan siklus CPU sehingga aplikasi mempertahankan integritas performanya untuk pengguna akhir.

Contoh: Implementasi referensi menambahkan pola Circuit Breaker dalam GetCircuitBreakerPolicy metode (lihat kode berikut).

private static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy()
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));
}

Dalam kode, handler kebijakan untuk RelecloudApiConcertSearchService instans menerapkan pola Circuit Breaker pada semua permintaan ke API. Ini menggunakan HandleTransientHttpError logika untuk mendeteksi permintaan HTTP yang dapat diulang dengan aman tetapi membatasi jumlah kesalahan agregat selama periode waktu tertentu.

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. Pola Reliable Web App menggunakan identitas terkelola untuk mengimplementasikan keamanan yang ber sentris identitas. Titik akhir privat, firewall aplikasi web, dan akses terbatas ke aplikasi web menyediakan ingress yang aman.

Menerapkan hak istimewa paling sedikit

Untuk memastikan keamanan dan efisiensi, hanya berikan pengguna (identitas pengguna) dan layanan Azure (identitas beban kerja) izin yang mereka butuhkan.

Menetapkan izin ke identitas pengguna

Menilai kebutuhan aplikasi Anda untuk menentukan serangkaian peran yang mencakup semua tindakan pengguna tanpa tumpang tindih. Petakan setiap pengguna ke peran yang paling tepat. Pastikan mereka hanya menerima akses ke apa yang diperlukan untuk tugas mereka.

Menetapkan izin ke identitas beban kerja

Berikan hanya izin yang penting untuk operasi, seperti tindakan CRUD dalam database atau mengakses rahasia. Izin identitas beban kerja tetap ada, sehingga Anda tidak dapat memberikan izin just-in-time atau jangka pendek untuk identitas beban kerja.

• Lebih suka kontrol akses berbasis peran (RBAC). Selalu mulai dengan Azure RBAC untuk menetapkan izin. Ini menawarkan kontrol yang tepat, memastikan akses dapat diaudit dan terperinci. Gunakan Azure RBAC untuk memberikan hanya izin yang diperlukan bagi layanan untuk melakukan fungsi yang dimaksudkan.

• Tambahan dengan kontrol akses tingkat layanan Azure. Jika Azure RBAC tidak mencakup skenario tertentu, lengkapi dengan kebijakan akses tingkat layanan Azure.

Mengonfigurasi autentikasi dan otorisasi pengguna

Autentikasi dan otorisasi adalah aspek penting dari keamanan aplikasi web. Autentikasi adalah proses memverifikasi identitas pengguna. Otorisasi menentukan tindakan yang diizinkan pengguna untuk dilakukan dalam aplikasi. Tujuannya adalah untuk menerapkan autentikasi dan otorisasi tanpa melemahkan postur keamanan Anda. Untuk memenuhi tujuan ini, Anda perlu menggunakan fitur platform aplikasi Azure (Azure App Service) dan idP (ID Microsoft Entra).

Mengonfigurasi autentikasi pengguna

Amankan aplikasi web Anda dengan mengaktifkan autentikasi pengguna melalui fitur platform Anda. Azure App Service mendukung autentikasi dengan penyedia identitas seperti ID Microsoft Entra, membongkar beban kerja autentikasi dari kode Anda.

Mengonfigurasi autentikasi dan otorisasi layanan

Konfigurasikan autentikasi dan otorisasi layanan sehingga layanan di lingkungan Anda memiliki izin untuk melakukan fungsi yang diperlukan. Gunakan Identitas Terkelola di ID Microsoft Entra untuk mengotomatiskan pembuatan dan pengelolaan identitas layanan, menghilangkan manajemen kredensial manual. Identitas terkelola memungkinkan aplikasi web Anda mengakses layanan Azure dengan aman, seperti Azure Key Vault dan database. Ini juga memfasilitasi integrasi alur CI/CD untuk penyebaran ke Azure App Service. Namun, dalam skenario seperti penyebaran hibrid atau dengan sistem warisan, lanjutkan menggunakan solusi autentikasi lokal Anda untuk menyederhanakan migrasi. Transisi ke identitas terkelola saat sistem Anda siap untuk pendekatan manajemen identitas modern. Untuk informasi selengkapnya, lihat Memantau identitas terkelola.

Gunakan DefaultAzureCredential untuk menyiapkan kode

Gunakan DefaultAzureCredential untuk memberikan kredensial untuk pengembangan lokal dan identitas terkelola di cloud. DefaultAzureCredentialTokenCredential menghasilkan untuk akuisisi token OAuth. Ini menangani sebagian besar skenario Azure SDK dan pustaka klien Microsoft. Ini mendeteksi lingkungan aplikasi untuk menggunakan identitas yang benar dan meminta token akses sesuai kebutuhan. DefaultAzureCredential menyederhanakan autentikasi untuk aplikasi yang disebarkan Azure Untuk informasi selengkapnya, lihat DefaultAzureCredential.

Contoh: Implementasi referensi menggunakan DefaultAzureCredential kelas selama start up untuk mengaktifkan penggunaan identitas terkelola antara API web dan Key Vault (lihat kode berikut).

builder.Configuration.AddAzureAppConfiguration(options =>
{
     options
        .Connect(new Uri(builder.Configuration["Api:AppConfig:Uri"]), new DefaultAzureCredential())
        .ConfigureKeyVault(kv =>
        {
            // Some of the values coming from Azure App Configuration are stored Key Vault. Use
            // the managed identity of this host for the authentication.
            kv.SetCredential(new DefaultAzureCredential());
        });
});

Menggunakan infrastruktur sebagai kode untuk membuat identitas terkelola

Anda harus menggunakan templat Bicep untuk membuat dan mengonfigurasi infrastruktur Azure untuk mendukung identitas terkelola. Identitas terkelola tidak menggunakan rahasia atau kata sandi, sehingga Anda tidak memerlukan Key Vault atau strategi rotasi rahasia untuk memastikan integritas. Anda dapat menyimpan string koneksi di App Configuration Service.

Contoh: Implementasi referensi menggunakan templat Bicep untuk (1) membuat identitas terkelola, (2) mengaitkan identitas dengan aplikasi web, dan (3) memberikan izin identitas untuk mengakses database SQL. Argumen Authentication dalam string koneksi memberi tahu pustaka klien Microsoft untuk terhubung dengan identitas terkelola (lihat kode berikut).

    Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default

Untuk informasi selengkapnya, lihat Koneksi ke database SQL dari .NET App Service.

Menggunakan penyimpanan rahasia pusat untuk mengelola rahasia

Saat Anda memindahkan aplikasi ke cloud, gunakan Azure Key Vault untuk menyimpan semua rahasia tersebut dengan aman. Repositori terpusat ini menawarkan penyimpanan yang aman, rotasi kunci, audit akses, dan pemantauan untuk layanan yang tidak mendukung identitas terkelola. Untuk konfigurasi aplikasi, Azure App Configuration disarankan.

Contoh: Implementasi referensi menyimpan rahasia berikut di Key Vault: (1) Nama pengguna dan kata sandi database PostgreSQL, (2) kata sandi Redis Cache, dan (3) rahasia klien untuk ID Microsoft Entra yang terkait dengan implementasi Microsoft Authentication Library (MSAL).

Jangan letakkan Key Vault dalam alur permintaan HTTP

Muat rahasia dari Key Vault saat pengaktifan aplikasi alih-alih selama setiap permintaan HTTP. Key Vault ditujukan untuk menyimpan dan mengambil data sensitif dengan aman selama penyebaran. Akses frekuensi tinggi dalam permintaan HTTP dapat melebihi kemampuan throughput Key Vault, yang mengarah ke batasan permintaan dan kesalahan kode status HTTP 429. Untuk informasi selengkapnya, lihat Batas transaksi Key Vault.

Menggunakan satu metode untuk mengakses rahasia di Key Vault

Saat mengonfigurasi aplikasi web untuk mengakses rahasia di Key Vault, Anda memiliki dua opsi utama:

• Pengaturan Aplikasi App Service: Gunakan pengaturan aplikasi di App Service untuk menyuntikkan rahasia secara langsung sebagai variabel lingkungan.

• Referensi rahasia langsung: Referensi langsung rahasia dalam kode aplikasi Anda. Tambahkan referensi tertentu dalam file properti aplikasi Anda, seperti application.properties untuk aplikasi Java, sehingga aplikasi Anda dapat berkomunikasi dengan Key Vault.

Penting untuk memilih salah satu metode ini dan tetap dengannya untuk kesederhanaan dan untuk menghindari kompleksitas yang tidak perlu.

Lebih suka metode akses sementara

Gunakan izin sementara untuk melindungi dari akses dan pelanggaran yang tidak sah. Gunakan tanda tangan akses bersama (SAS) untuk akses sementara. Gunakan SAS Delegasi Pengguna untuk memaksimalkan keamanan saat memberikan akses sementara. Ini adalah satu-satunya SAS yang menggunakan kredensial Microsoft Entra dan tidak memerlukan kunci akun penyimpanan.

Menggunakan titik akhir privat

Gunakan titik akhir privat di semua lingkungan produksi untuk semua layanan Azure yang didukung. Titik akhir privat menyediakan koneksi privat antara sumber daya di jaringan virtual Azure dan layanan Azure. Secara default, komunikasi ke sebagian besar layanan Azure melintasi internet publik. Titik akhir privat tidak memerlukan perubahan kode, konfigurasi aplikasi, atau string koneksi apa pun. Untuk informasi selengkapnya, lihat Cara membuat titik akhir privat dan Praktik terbaik untuk keamanan titik akhir.

Contoh: Azure App Configuration, Azure SQL Database, Azure Cache for Redis, Azure Storage, Azure App Service, dan Key Vault menggunakan titik akhir privat.

Menggunakan firewall aplikasi web dan membatasi lalu lintas internet masuk

Semua lalu lintas internet masuk ke aplikasi web harus melewati firewall aplikasi web untuk melindungi dari eksploitasi web umum. Paksa semua lalu lintas internet masuk untuk melewati load balancer publik, jika Anda memilikinya, dan firewall aplikasi web.

Contoh: Implementasi referensi memaksa semua lalu lintas internet masuk melalui Front Door dan Azure Web Application Firewall. Dalam produksi, pertahankan nama host HTTP asli.

Mengonfigurasi keamanan database

Akses tingkat administrator ke database memberikan izin untuk melakukan operasi istimewa. Operasi istimewa termasuk membuat dan menghapus database, memodifikasi skema tabel, atau mengubah izin pengguna. Pengembang sering memerlukan akses tingkat administrator untuk mempertahankan database atau memecahkan masalah.

• Hindari izin permanen yang ditingkatkan. Anda hanya boleh memberi pengembang akses just-in-time untuk melakukan operasi istimewa. Dengan akses just-in-time, pengguna menerima izin sementara untuk melakukan tugas istimewa

• Jangan berikan izin yang ditingkatkan aplikasi. Anda tidak boleh memberikan akses tingkat administrator ke identitas aplikasi. Anda harus mengonfigurasi akses paling tidak istimewa untuk aplikasi ke database. Ini membatasi radius ledakan bug dan pelanggaran keamanan.

Pengoptimalan biaya

Pengoptimalan biaya adalah tentang melihat cara untuk mengurangi pengeluaran dan overhead manajemen yang tidak perlu. Untuk informasi selengkapnya, lihat Daftar periksa Tinjauan desain untuk Pengoptimalan Biaya. Pola Reliable Web App mengimplementasikan teknik rightsizing, autoscaling, dan penggunaan sumber daya yang efisien untuk aplikasi web yang lebih hemat biaya.

Sumber daya rightsize untuk setiap lingkungan

Pahami berbagai tingkat performa layanan Azure dan hanya gunakan SKU yang sesuai untuk kebutuhan setiap lingkungan. Lingkungan produksi memerlukan SKU yang memenuhi perjanjian tingkat layanan (SLA), fitur, dan skala yang diperlukan untuk produksi. Lingkungan nonproduksi biasanya tidak memerlukan kemampuan yang sama. Untuk penghematan tambahan, pertimbangkan opsi harga Azure Dev/Test, Reservasi Azure, dan paket penghematan Azure untuk komputasi.

Contoh: Implementasi referensi menggunakan parameter Bicep untuk memicu konfigurasi penyebaran sumber daya. Salah satu parameter ini menunjukkan tingkat sumber daya (SKU) untuk disebarkan. Aplikasi web menggunakan SKU yang lebih berkinerja dan mahal untuk lingkungan produksi dan SKU yang lebih murah untuk lingkungan nonproduksi (lihat kode berikut).

var redisCacheSkuName = isProd ? 'Standard' : 'Basic'
var redisCacheFamilyName = isProd ? 'C' : 'C'
var redisCacheCapacity = isProd ? 1 : 0

Menggunakan skala otomatis

Skala otomatis mengotomatiskan penskalaan horizontal untuk lingkungan produksi. Skala otomatis berdasarkan metrik performa. Pemicu performa pemanfaatan CPU adalah titik awal yang baik jika Anda tidak memahami kriteria penskalaan aplikasi Anda. Anda perlu mengonfigurasi dan menyesuaikan pemicu penskalaan (CPU, RAM, jaringan, dan disk) agar sesuai dengan perilaku aplikasi web Anda. Jangan menskalakan secara vertikal untuk memenuhi perubahan permintaan yang sering. Biayanya lebih murah. Untuk informasi selengkapnya, lihat Penskalaan di Azure App Service dan Autoscale di Microsoft Azure.

Contoh: Implementasi referensi menggunakan konfigurasi berikut dalam templat Bicep. Ini membuat aturan skala otomatis untuk Azure App Service. Aturan ini menskalakan hingga 10 instans dan default ke satu instans. Ini menggunakan penggunaan CPU sebagai pemicu untuk penskalaan masuk dan keluar. Platform hosting aplikasi web menskalakan pada penggunaan CPU 85% dan menskalakan di 60%. Pengaturan peluasan skala 85%, daripada persentase yang lebih dekat ke 100%, menyediakan buffer untuk melindungi dari akumulasi lalu lintas pengguna yang disebabkan oleh sesi lengket. Ini juga melindungi dari ledakan lalu lintas yang tinggi dengan menskalakan lebih awal untuk menghindari penggunaan CPU maksimum. Aturan skala otomatis ini tidak universal (lihat kode berikut).

resource autoScaleRule 'Microsoft.Insights/autoscalesettings@2022-10-01' = if (autoScaleSettings != null) { 
  name: '${name}-autoscale' 
  location: location 
  tags: tags 
  properties: { 
    targetResourceUri: appServicePlan.id 
    enabled: true 
    profiles: [ 
      { 
        name: 'Auto created scale condition' 
        capacity: { 
          minimum: string(zoneRedundant ? 3 : autoScaleSettings!.minCapacity) 
          maximum: string(autoScaleSettings!.maxCapacity) 
          default: string(zoneRedundant ? 3 : autoScaleSettings!.minCapacity) 
        } 
        rules: [ 
          ... 
        ] 
      } 
    ] 
  } 
}

Menggunakan sumber daya secara efisien

• Gunakan layanan bersama. Memusatkan dan berbagi sumber daya tertentu memberikan pengoptimalan biaya dan overhead manajemen yang lebih rendah. Tempatkan sumber daya jaringan bersama di jaringan virtual hub.

  Contoh: Implementasi referensi menempatkan Azure Firewall, Azure Bastion, dan Key Vault di jaringan virtual hub.

• Hapus lingkungan yang tidak digunakan. Hapus lingkungan nonproduksi setelah berjam-jam atau selama liburan untuk mengoptimalkan biaya. Anda dapat menggunakan infrastruktur sebagai kode untuk menghapus sumber daya Azure dan seluruh lingkungan. Hapus deklarasi sumber daya yang ingin Anda hapus dari templat Bicep. Gunakan operasi bagaimana-jika untuk mempratinjau perubahan sebelum diterapkan. Cadangkan data yang Anda butuhkan nanti. Pahami dependensi pada sumber daya yang Anda hapus. Jika ada dependensi, Anda mungkin perlu memperbarui atau menghapus sumber daya tersebut juga. Untuk informasi selengkapnya, lihat Operasi bagaimana-jika penyebaran Bicep.

• Kolokasikan fungsionalitas. Jika ada kapasitas cadangan, kolokasikan sumber daya dan fungsionalitas aplikasi pada satu sumber daya Azure. Misalnya, beberapa aplikasi web dapat menggunakan satu server (Paket App Service) atau satu cache dapat mendukung beberapa jenis data.

  Contoh: Implementasi referensi menggunakan satu instans Azure Cache for Redis untuk manajemen sesi di front-end (menyimpan token keranjang dan MSAL) dan aplikasi web back-end (menyimpan data Konser Mendatang). Ini memilih SKU Redis terkecil, menawarkan lebih dari kapasitas yang diperlukan, digunakan secara efisien dengan menggunakan beberapa jenis data untuk mengontrol biaya.

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. Pola Reliable Web App menerapkan infrastruktur sebagai kode untuk penyebaran infrastruktur dan pemantauan untuk pengamatan.

Mengotomatiskan penyebaran

Gunakan alur CI/CD untuk menyebarkan perubahan dari kontrol sumber ke produksi. Jika Anda menggunakan Azure DevOps, Anda harus menggunakan Azure Pipelines. Jika Anda menggunakan GitHub, gunakan tindakan GitHub. Azure mendukung templat ARM (JSON), Bicep, dan Terraform dan memiliki templat untuk setiap sumber daya Azure Untuk informasi selengkapnya, lihat Templat Bicep, Azure Resource Manager, dan Terraform dan Infrastruktur yang Dapat Diulang.

Contoh: Implementasi referensi menggunakan Azure Dev CLI dan infrastruktur sebagai kode (templat Bicep) untuk membuat sumber daya Azure, menyiapkan konfigurasi, dan menyebarkan sumber daya yang diperlukan.

Mengonfigurasi pemantauan

Untuk memantau aplikasi web Anda, kumpulkan dan analisis metrik dan log dari kode aplikasi, infrastruktur (runtime), dan platform (sumber daya Azure). Tambahkan pengaturan diagnostik untuk setiap sumber daya Azure dalam arsitektur Anda. Setiap layanan Azure memiliki sekumpulan log dan metrik yang berbeda yang dapat Anda ambil. Untuk informasi selengkapnya, lihat Memantau platform dan Memantau App Service.

Memantau metrik garis besar

Gunakan Azure Application Insights untuk melacak metrik dasar, seperti throughput permintaan, durasi permintaan rata-rata, kesalahan, dan pemantauan dependensi. Gunakan AddApplicationInsightsTelemetry dari paket Microsoft.ApplicationInsights.AspNetCore NuGet untuk mengaktifkan pengumpulan telemetri. Untuk informasi selengkapnya, lihat Mengaktifkan telemetri Application Insights dan injeksi Dependensi di .NET.

Contoh: Implementasi referensi menggunakan kode untuk mengonfigurasi metrik dasar di Application Insights (lihat kode berikut).

public void ConfigureServices(IServiceCollection services)
{
   ...
   services.AddApplicationInsightsTelemetry(Configuration["App:Api:ApplicationInsights:ConnectionString"]);
   ...
}

Membuat telemetri kustom sesuai kebutuhan

Gunakan Application Insights untuk mengumpulkan telemetri kustom untuk lebih memahami pengguna aplikasi web Anda. Buat instans TelemetryClient kelas dan gunakan TelemetryClient metode untuk membuat metrik yang tepat. Ubah kueri menjadi widget Dasbor Azure.

Contoh: Implementasi referensi menambahkan metrik yang membantu tim operasi mengidentifikasi bahwa aplikasi web berhasil menyelesaikan transaksi. Ini memvalidasi bahwa aplikasi web online dengan memantau apakah pelanggan dapat melakukan pemesanan, bukan dengan mengukur jumlah permintaan atau penggunaan CPU. Implementasi referensi menggunakan TelemetryClient melalui injeksi dependensi dan TrackEvent metode untuk mengumpulkan telemetri pada peristiwa yang terkait dengan aktivitas keliru. Telemetri melacak tiket yang ditambahkan, dihapus, dan dibeli pengguna (lihat kode berikut).

• AddToCart menghitung berapa kali pengguna menambahkan tiket tertentu (ConcertID) ke kelir.
• RemoveFromCart mencatat tiket yang dihapus pengguna dari kelir.
• CheckoutCart merekam peristiwa setiap kali pengguna membeli tiket.

this.telemetryClient.TrackEvent menghitung tiket yang ditambahkan ke kelir. Ini memasok nama peristiwa (AddToCart) dan menentukan kamus yang memiliki concertId dan count (lihat kode berikut).

this.telemetryClient.TrackEvent("AddToCart", new Dictionary<string, string> {
    { "ConcertId", concertId.ToString() },
    { "Count", count.ToString() }
});

Untuk informasi selengkapnya, lihat:

• API Application Insights untuk aktivitas dan metrik kustom
• Kelas TelemetryClient
• Metode klien telemetri

Mengumpulkan metrik berbasis log

Lacak metrik berbasis log untuk mendapatkan lebih banyak visibilitas ke dalam kesehatan dan metrik aplikasi penting. Anda dapat menggunakan kueri Bahasa Kueri Kusto (KQL) di Application Insights untuk menemukan dan menata data. Untuk informasi selengkapnya, lihat Metrik berbasis log Azure Application Insights dan Metrik berbasis log dan pra-integrasi di Application Insights.

Mengaktifkan diagnostik platform

Pengaturan diagnostik di Azure memungkinkan Anda menentukan log dan metrik platform yang ingin Anda kumpulkan dan tempat menyimpannya. Log platform adalah log bawaan yang menyediakan informasi diagnostik dan audit. Anda dapat mengaktifkan diagnostik platform untuk sebagian besar layanan Azure, tetapi setiap layanan menentukan kategori lognya sendiri. Layanan Azure yang berbeda memiliki kategori log untuk dipilih.

• Aktifkan diagnostik untuk semua layanan yang didukung. Layanan Azure membuat log platform secara otomatis, tetapi layanan tidak menyimpannya secara otomatis. Anda harus mengaktifkan pengaturan diagnostik untuk setiap layanan, dan Anda harus mengaktifkannya untuk setiap layanan Azure yang mendukung diagnostik.

• Kirim diagnostik ke tujuan yang sama dengan log aplikasi. Saat mengaktifkan diagnostik, Anda memilih log yang ingin Anda kumpulkan dan ke mana harus mengirimnya. Anda harus mengirim log platform ke tujuan yang sama dengan log aplikasi sehingga Anda dapat menghubungkan dua himpunan data.

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 Ulasan desain untuk Efisiensi Performa. Pola Reliable Web App menggunakan pola Cache-Aside untuk meminimalkan latensi untuk data yang sangat diminta.

Menggunakan pola Cache-Aside

Pola Cache-Aside adalah strategi penembolokan yang meningkatkan manajemen data dalam memori. Pola menetapkan aplikasi tanggung jawab menangani permintaan data dan memastikan konsistensi antara cache dan penyimpanan persisten, seperti database. Saat aplikasi web menerima permintaan data, aplikasi web pertama-tama mencari cache. Jika data hilang, data mengambilnya dari database, merespons permintaan, dan memperbarui cache yang sesuai. Pendekatan ini mempersingkat waktu respons dan meningkatkan throughput dan mengurangi kebutuhan akan penskalaan yang lebih besar. Ini juga memperkuat ketersediaan layanan dengan mengurangi beban pada datastore utama dan meminimalkan risiko pemadaman.

Contoh: Implementasi referensi meningkatkan efisiensi aplikasi dengan penembolokan data penting, seperti informasi untuk konser yang akan datang sangat penting untuk penjualan tiket. Ini menggunakan cache memori terdistribusi ASP.NET Core untuk penyimpanan item dalam memori. Aplikasi ini secara otomatis menggunakan Azure Cache for Redis saat menemukan string koneksi tertentu. Ini juga mendukung lingkungan pengembangan lokal tanpa Redis untuk menyederhanakan penyiapan dan mengurangi biaya dan kompleksitas. Metode (AddAzureCacheForRedis) mengonfigurasi aplikasi untuk menggunakan Azure Cache for Redis (lihat kode berikut).

private void AddAzureCacheForRedis(IServiceCollection services)
{
    if (!string.IsNullOrWhiteSpace(Configuration["App:RedisCache:ConnectionString"]))
    {
        services.AddStackExchangeRedisCache(options =>
        {
            options.Configuration = Configuration["App:RedisCache:ConnectionString"];
        });
    }
    else
    {
        services.AddDistributedMemoryCache();
    }
}

Untuk informasi selengkapnya, lihat Penembolokan terdistribusi di metode ASP.NET Core dan AddDistributedMemoryCache.

Cache data dengan kebutuhan tinggi

Prioritaskan penembolokan untuk data yang paling sering diakses. Identifikasi poin data utama yang mendorong keterlibatan pengguna dan performa sistem. Terapkan strategi penembolokan khusus untuk area ini untuk mengoptimalkan efektivitas pola Cache-Aside, secara signifikan mengurangi latensi dan beban database. Gunakan Azure Monitor untuk melacak CPU, memori, dan penyimpanan database. Metrik ini membantu Anda menentukan apakah Anda dapat menggunakan SKU database yang lebih kecil.

Contoh: Implementasi referensi menyimpan data yang mendukung Konser Mendatang. Halaman Konser Mendatang membuat kueri terbanyak ke SQL Database dan menghasilkan output yang konsisten untuk setiap kunjungan. Pola Cache-Aside menyimpan data setelah permintaan pertama halaman ini untuk mengurangi beban pada database. Kode berikut menggunakan GetUpcomingConcertsAsync metode untuk menarik data ke cache Redis dari SQL Database. Metode ini mengisi cache dengan konser terbaru. Metode memfilter menurut waktu, mengurutkan data, dan mengembalikan data ke pengontrol untuk menampilkan hasilnya (lihat kode berikut).

public async Task<ICollection<Concert>> GetUpcomingConcertsAsync(int count)
{
    IList<Concert>? concerts;
    var concertsJson = await this.cache.GetStringAsync(CacheKeys.UpcomingConcerts);
    if (concertsJson != null)
    {
        // There is cached data. Deserialize the JSON data.
        concerts = JsonSerializer.Deserialize<IList<Concert>>(concertsJson);
    }
    else
    {
        // There's nothing in the cache. Retrieve data from the repository and cache it for one hour.
        concerts = await this.database.Concerts.AsNoTracking()
            .Where(c => c.StartTime > DateTimeOffset.UtcNow && c.IsVisible)
            .OrderBy(c => c.StartTime)
            .Take(count)
            .ToListAsync();
        concertsJson = JsonSerializer.Serialize(concerts);
        var cacheOptions = new DistributedCacheEntryOptions {
            AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1)
        };
        await this.cache.SetStringAsync(CacheKeys.UpcomingConcerts, concertsJson, cacheOptions);
    }
    return concerts ?? new List<Concert>();
}

Menjaga data cache tetap segar

Jadwalkan pembaruan cache reguler untuk disinkronkan dengan perubahan database terbaru. Tentukan laju refresh optimal berdasarkan volatilitas data dan kebutuhan pengguna. Praktik ini memastikan aplikasi menggunakan pola Cache-Aside untuk memberikan akses cepat dan informasi saat ini.

Contoh: Implementasi referensi menyimpan data hanya selama satu jam. Ini memiliki proses untuk menghapus kunci cache ketika data berubah. Metode CreateConcertAsync menghapus kunci cache (lihat kode berikut).

public async Task<CreateResult> CreateConcertAsync(Concert newConcert)
{
    database.Add(newConcert);
    await this.database.SaveChangesAsync();
    this.cache.Remove(CacheKeys.UpcomingConcerts);
    return CreateResult.SuccessResult(newConcert.Id);
}

Memastikan konsistensi data

Terapkan mekanisme untuk memperbarui cache segera setelah operasi penulisan database apa pun. Gunakan pembaruan berbasis peristiwa atau kelas manajemen data khusus untuk memastikan koherensi cache. Menyinkronkan cache secara konsisten dengan modifikasi database adalah pusat dari pola Cache-Aside.

Contoh: Implementasi referensi menggunakan UpdateConcertAsync metode untuk menjaga data dalam cache tetap konsisten (lihat kode berikut).

public async Task<UpdateResult> UpdateConcertAsync(Concert existingConcert), 
{
   database.Update(existingConcert);
   await database.SaveChangesAsync();
   this.cache.Remove(CacheKeys.UpcomingConcerts);
   return UpdateResult.SuccessResult();
}

Menguji performa database

Performa database dapat memengaruhi performa dan skalabilitas aplikasi. Penting untuk menguji performa database Anda untuk memastikan database dioptimalkan. Beberapa pertimbangan utama termasuk memilih wilayah cloud yang tepat, pengumpulan koneksi, pola cache-aside, dan mengoptimalkan kueri.

• Uji lompatan jaringan. Memindahkan aplikasi ke cloud dapat memperkenalkan hop dan latensi jaringan tambahan ke database Anda. Anda harus menguji hop tambahan yang diperkenalkan oleh lingkungan cloud baru.

• Menetapkan garis besar performa. Anda harus menggunakan metrik performa lokal sebagai garis besar awal untuk membandingkan performa aplikasi di cloud.

Langkah berikutnya

Sebarkan implementasi referensi dengan mengikuti instruksi di repositori GitHub. Gunakan sumber daya berikut untuk mempelajari selengkapnya tentang aplikasi .NET, aplikasi web, praktik terbaik cloud, dan migrasi.

Meningkatkan aplikasi .NET Framework

Implementasi referensi disebarkan ke App Service yang menjalankan Windows, tetapi dapat berjalan di Linux. Platform Windows App Service memungkinkan Anda memindahkan aplikasi web .NET Framework ke Azure tanpa meningkatkan ke versi kerangka kerja yang lebih baru. Untuk informasi tentang paket Linux App Service atau fitur baru dan peningkatan performa yang ditambahkan ke versi terbaru .NET, lihat panduan berikut.

• Gambaran umum porting dari .NET Framework ke .NET. Dapatkan panduan berdasarkan jenis aplikasi .NET spesifik Anda.
• Gambaran umum Asisten Peningkatan .NET. Pelajari tentang alat konsol yang dapat membantu Anda mengotomatiskan banyak tugas yang terkait dengan peningkatan proyek .NET Framework.
• Migrasi dari ASP.NET ke ASP.NET Core di Visual Studio. Pelajari tentang ekstensi Visual Studio yang dapat membantu Anda dengan migrasi tambahan aplikasi web.

Pengantar aplikasi web di Azure

Untuk pengenalan langsung aplikasi web .NET di Azure, lihat panduan ini untuk menyebarkan aplikasi web .NET dasar.

Praktik terbaik cloud

Untuk panduan adopsi dan arsitektur Azure, lihat:

• Cloud Adoption Framework. Dapat membantu organisasi Anda menyiapkan dan menjalankan strategi untuk membangun solusi di Azure.
• Kerangka Kerja Yang Dirancang Dengan Baik. Sekumpulan tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja.

Untuk aplikasi yang memerlukan SLO yang lebih tinggi daripada pola Reliable Web App, lihat beban kerja misi penting.

Panduan migrasi

Alat dan sumber daya berikut ini dapat membantu Anda memigrasikan sumber daya lokal ke Azure.

• Azure Migrate menyediakan layanan migrasi, modernisasi, dan pengoptimalan yang disederhanakan untuk Azure yang menangani penilaian dan migrasi aplikasi web, SQL Server, dan komputer virtual.
• Panduan Migrasi Database Azure menyediakan sumber daya untuk berbagai jenis database, dan alat berbeda yang dirancang untuk skenario migrasi Anda.
• Akselerator zona pendaratan Azure App Service menyediakan panduan untuk pengerasan dan penskalaan penyebaran App Service.
• Penilaian aplikasi dan kode Azure Migrate