Pola Reliable Web App untuk .NET

Azure App Service

Azure Front Door

Azure Cache untuk Redis

.NET

Artikel ini menyediakan panduan untuk menerapkan pola Reliable Web App. Pola ini menjelaskan cara memodifikasi (replatform) aplikasi web untuk migrasi cloud. Ini menyediakan arsitektur preskriptif, kode, dan panduan konfigurasi yang selaras dengan prinsip Azure Well-Architected Framework.

Mengapa pola Reliable Web App untuk .NET?

Pola Reliable Web App adalah serangkaian prinsip dan teknik implementasi yang menentukan bagaimana Anda harus mereplatformasi aplikasi web saat Anda memigrasikannya ke cloud. Ini berfokus pada pembaruan kode minimal yang perlu Anda buat agar berhasil di cloud. Panduan berikut menggunakan implementasi referensi sebagai contoh di seluruh. Panduan ini mengikuti perjalanan replatform perusahaan fiktif Relecloud untuk memberikan konteks bisnis untuk perjalanan Anda. Sebelum menerapkan pola Reliable Web App untuk .NET, Relecloud memiliki aplikasi web tiket lokal monolitik yang menggunakan kerangka kerja ASP.NET.

Petunjuk / Saran

Ada implementasi referensi (sampel) dari pola Reliable Web App. Ini mewakili status akhir implementasi Reliable Web App untuk perusahaan fiktif bernama Relecloud. Ini adalah aplikasi web tingkat produksi yang menampilkan semua pembaruan kode, arsitektur, dan konfigurasi yang dibahas dalam artikel ini. Sebarkan dan gunakan implementasi referensi untuk memandu implementasi pola Reliable Web App Anda.

Cara menerapkan pola Reliable Web App

Artikel ini mencakup arsitektur, kode, dan panduan konfigurasi untuk menerapkan pola Reliable Web App. Gunakan tautan berikut untuk masuk ke panduan spesifik yang Anda butuhkan:

• Konteks bisnis. Selaraskan panduan ini dengan konteks bisnis Anda dan pelajari cara menentukan tujuan segera dan jangka panjang yang mendorong keputusan replatforming.
• panduan Arsitektur . Pelajari cara memilih layanan cloud yang tepat dan merancang arsitektur yang memenuhi persyaratan bisnis Anda.
• Panduan kode. Terapkan tiga pola desain untuk meningkatkan keandalan dan efisiensi performa aplikasi web Anda di cloud: pola Coba Lagi, Pemutus Sirkuit, dan Cache-Aside.
• panduan Konfigurasi . Mengonfigurasi autentikasi dan otorisasi, identitas terkelola, lingkungan yang disahkan, infrastruktur sebagai kode, dan pemantauan.

Konteks bisnis

Langkah pertama dalam mereplatformasi aplikasi web adalah menentukan tujuan bisnis Anda. Anda harus menetapkan tujuan langsung, seperti tujuan tingkat layanan (SLO) dan target pengoptimalan biaya, dan juga tujuan di masa mendatang untuk aplikasi web Anda. Tujuan ini memengaruhi pilihan layanan cloud dan arsitektur aplikasi web Anda di cloud. Tentukan SLO target untuk aplikasi web Anda, seperti waktu aktif 99,9%. Hitung SLA komposit untuk semua layanan yang memengaruhi ketersediaan aplikasi web Anda.

Misalnya, Relecloud memiliki prakiraan penjualan yang positif dan mengantisipasi peningkatan permintaan pada aplikasi web tiket mereka. Untuk memenuhi permintaan ini, mereka mendefinisikan tujuan untuk aplikasi web:

• Terapkan perubahan kode bernilai rendah dan bernilai tinggi.
• Jangkau SLO 99,9%.
• Mengadopsi praktik DevOps.
• Buat lingkungan yang dioptimalkan biaya.
• Meningkatkan keandalan dan keamanan.

Infrastruktur lokal Relecloud bukanlah solusi hemat biaya untuk mencapai tujuan ini. Mereka memutuskan bahwa memigrasikan aplikasi web mereka ke Azure adalah cara paling hemat biaya untuk mencapai tujuan langsung dan masa depan mereka.

Panduan arsitektur

Pola Reliable Web App memiliki beberapa elemen arsitektur penting. Anda memerlukan DNS untuk mengelola resolusi titik akhir, firewall aplikasi web untuk memblokir lalu lintas HTTP berbahaya, dan load balancer untuk merutekan dan membantu melindungi permintaan pengguna masuk. Platform aplikasi menghosting kode aplikasi web Anda dan melakukan panggilan ke semua layanan back-end melalui titik akhir privat dalam jaringan virtual. Alat pemantauan performa aplikasi menangkap metrik dan log untuk membantu Anda memahami aplikasi web Anda.

Gambar 1. Elemen arsitektur penting dari pola Reliable Web App.

Merancang arsitektur

Rancang infrastruktur Anda untuk mendukung metrik pemulihan Anda, seperti tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO). RTO memengaruhi ketersediaan dan harus mendukung SLO Anda. Tentukan RPO dan konfigurasikan redundansi data untuk memenuhi RPO.

• Pilih keandalan infrastruktur. Tentukan berapa banyak zona dan wilayah ketersediaan yang Anda butuhkan untuk memenuhi persyaratan ketersediaan Anda. Tambahkan zona dan wilayah ketersediaan hingga SLA komposit memenuhi SLO Anda. Pola Reliable Web App mendukung beberapa wilayah untuk konfigurasi aktif-aktif atau pasif aktif. Misalnya, implementasi referensi menggunakan konfigurasi pasif aktif untuk memenuhi SLO sebesar 99,9%.

  Untuk aplikasi web multi-wilayah, konfigurasikan load balancer Anda untuk merutekan lalu lintas ke wilayah kedua untuk mendukung konfigurasi aktif-aktif atau pasif aktif, tergantung pada kebutuhan bisnis Anda. Dua wilayah memerlukan layanan yang sama, kecuali satu wilayah memiliki jaringan virtual hub yang menghubungkan wilayah. Mengadopsi topologi jaringan hub-and-spoke untuk mempusatkan dan berbagi sumber daya, seperti firewall jaringan. Jika Anda memiliki komputer virtual, tambahkan host bastion ke jaringan virtual hub untuk mengelolanya dengan keamanan yang ditingkatkan. (Lihat gambar 2.)

  

  Gambar 2. Pola Reliable Web App dengan wilayah kedua dan topologi hub-and-spoke.

• Pilih topologi jaringan. Pilih topologi jaringan yang tepat untuk persyaratan web dan jaringan Anda. Jika Anda berencana menggunakan beberapa jaringan virtual, gunakan topologi jaringan hub-and-spoke . Ini memberikan manfaat biaya, manajemen, dan keamanan dan opsi konektivitas hibrid ke jaringan lokal dan virtual.

Pilih layanan Azure yang tepat

Saat memindahkan aplikasi web ke cloud, Anda harus memilih layanan Azure yang memenuhi persyaratan bisnis Anda dan selaras dengan fitur aplikasi web lokal saat ini. Penyelarasan ini membantu meminimalkan upaya replatforming. Misalnya, gunakan layanan yang memungkinkan Anda menyimpan mesin database yang sama dan mendukung middleware dan kerangka kerja yang ada. Bagian berikut ini menyediakan panduan untuk memilih layanan Azure yang tepat untuk aplikasi web Anda.

Misalnya, sebelum dipindahkan ke cloud, aplikasi web tiket Relecloud adalah aplikasi ASP.NET monolitik lokal. Ini berjalan pada dua komputer virtual dan menggunakan database SQL Server. Aplikasi web menderita masalah umum dengan skalabilitas dan penyebaran fitur. Titik awal ini, tujuan bisnis mereka, dan SLO mendorong pilihan layanan mereka.

• Platform aplikasi: Gunakan Azure App Service sebagai platform aplikasi Anda. Relecloud memilih App Service sebagai platform aplikasi karena alasan berikut:

  • Perjanjian tingkat layanan tinggi (SLA). Ini memiliki SLA tinggi yang memenuhi lingkungan produksi SLO 99,9%.
  • Mengurangi overhead manajemen. Ini adalah solusi yang dikelola sepenuhnya yang menangani penskalaan, pemeriksaan kesehatan, dan penyeimbangan beban.
  • Dukungan .NET. Ini mendukung versi .NET tempat aplikasi ditulis.
  • Kemampuan kontainerisasi. Aplikasi web dapat bertemu di cloud tanpa kontainer, tetapi platform aplikasi juga mendukung kontainerisasi tanpa mengubah layanan Azure.
  • Penskalakan otomatis. Aplikasi web dapat secara otomatis menskalakan masuk dan keluar berdasarkan lalu lintas pengguna dan pengaturan konfigurasi. Platform ini juga mendukung peningkatan atau penurunan skala untuk mengakomodasi persyaratan hosting yang berbeda.

• Manajemen identitas: Gunakan ID Microsoft Entra sebagai solusi manajemen identitas dan akses Anda. Relecloud memilih MICROSOFT Entra ID karena alasan berikut:

  • Autentikasi dan otorisasi. Aplikasi perlu mengautentikasi dan mengotorisasi karyawan pusat panggilan.
  • Dapat diskalakan. Microsoft Entra ID menskalakan untuk mendukung skenario yang lebih besar.
  • Kontrol identitas pengguna. Karyawan pusat panggilan dapat menggunakan identitas perusahaan yang ada.
  • Dukungan protokol otorisasi. MICROSOFT Entra ID mendukung OAuth 2.0 untuk identitas terkelola.

• Database: Gunakan layanan yang memungkinkan Anda menyimpan mesin database yang sama. Gunakan pohon keputusan penyimpanan data untuk memandu pilihan Anda. Aplikasi web Relecloud menggunakan SQL Server lokal. Mereka ingin menggunakan skema database, prosedur tersimpan, dan fungsi yang ada. Beberapa produk SQL tersedia di Azure, tetapi Relecloud memilih Azure SQL Database karena alasan berikut:

  • Keandalan. Tingkat tujuan umum menyediakan SLA tinggi dan redundansi multi-wilayah. Ini dapat mendukung beban pengguna yang tinggi.
  • Mengurangi overhead manajemen. SQL Database menyediakan instans database SQL terkelola.
  • Dukungan migrasi. Ini mendukung migrasi database dari SQL Server lokal.
  • Konsistensi dengan konfigurasi lokal. Ini mendukung prosedur, fungsi, dan tampilan tersimpan yang ada.
  • Ketahanan. Ini mendukung pencadangan dan pemulihan titik waktu.
  • Keahlian dan pengerjaan ulang minimal. SQL Database memungkinkan Relecloud memanfaatkan keahlian yang ada dan membutuhkan pekerjaan minimal untuk diadopsi.

• Pemantauan performa aplikasi: Gunakan Application Insights untuk menganalisis telemetri untuk aplikasi Anda. Relecloud memilih untuk menggunakan Application Insights karena alasan berikut:

  • Integrasi dengan Azure Monitor. Ini menyediakan integrasi terbaik dengan Azure Monitor.
  • Deteksi anomali. Ini secara otomatis mendeteksi anomali performa.
  • Pemecahan masalah. Ini membantu Anda mendiagnosis masalah di aplikasi yang sedang berjalan.
  • Pemantauan. Ini mengumpulkan informasi tentang bagaimana pengguna menggunakan aplikasi dan memungkinkan Anda untuk dengan mudah melacak peristiwa kustom.
  • Kesenjangan visibilitas. Solusi lokal tidak memiliki solusi pemantauan performa aplikasi. Application Insights menyediakan integrasi yang mudah dengan platform dan kode aplikasi.

• Cache: Pilih apakah akan menambahkan cache ke arsitektur aplikasi web Anda. Azure Cache for Redis adalah solusi cache Azure utama. Ini adalah penyimpanan data dalam memori terkelola yang didasarkan pada perangkat lunak Redis. Beban aplikasi web Relecloud sangat miring untuk melihat konser dan detail tempat. Relecloud menambahkan Azure Cache for Redis karena alasan berikut:

  • Mengurangi overhead manajemen. Ini adalah layanan yang dikelola sepenuhnya.
  • Kecepatan dan volume. Ini memiliki throughput data tinggi dan baca latensi rendah untuk data yang umum diakses dan berubah lambat.
  • Beragam dukungan. Ini adalah lokasi cache terpadu untuk semua instans aplikasi web yang akan digunakan.
  • Penyimpanan data eksternal. Server aplikasi lokal melakukan penembolokan lokal VM. Penyiapan ini tidak membongkar data yang sangat sering, dan tidak dapat membatalkan data.
  • Sesi nonsticky. Eksternalisasi status sesi mendukung sesi nonsticky.

• Load balancer: aplikasi web yang menggunakan solusi PaaS harus menggunakan Azure Front Door, Azure Application Gateway, atau keduanya, tergantung pada arsitektur dan persyaratan aplikasi web. Gunakan pohon keputusan load balancer untuk memilih load balancer yang tepat. Relecloud memerlukan load balancer lapisan-7 yang dapat merutekan lalu lintas di beberapa wilayah. Perusahaan ini membutuhkan aplikasi web multi-wilayah untuk memenuhi SLO 99,9%. Relecloud memilih Azure Front Door karena alasan berikut:

  • Penyeimbangan beban global. Ini adalah load balancer lapisan-7 yang dapat merutekan lalu lintas di beberapa wilayah.
  • Firewall aplikasi web. Ini terintegrasi secara asli dengan Azure Web Application Firewall.
  • Fleksibilitas perutean. Ini memungkinkan tim aplikasi untuk mengonfigurasi ingress perlu mendukung perubahan di masa mendatang dalam aplikasi.
  • Akselerasi lalu lintas. Ini menggunakan anycast untuk mencapai titik kehadiran Azure terdekat dan menemukan rute tercepat ke aplikasi web.
  • Domain kustom. Ini mendukung nama domain kustom dengan validasi domain yang fleksibel.
  • Pemeriksaan kesehatan. Aplikasi ini memerlukan pemantauan pemeriksaan kesehatan cerdas. Azure Front Door menggunakan respons dari pemeriksaan untuk menentukan asal terbaik untuk merutekan permintaan klien.
  • Memantau dukungan. Ini mendukung laporan bawaan dengan dasbor all-in-one untuk Azure Front Door dan pola keamanan. Anda dapat mengonfigurasi pemberitahuan yang terintegrasi dengan Azure Monitor. Azure Front Door memungkinkan aplikasi untuk mencatat setiap permintaan dan pemeriksaan kesehatan yang gagal.
  • Perlindungan DDoS. Ini memiliki perlindungan DDoS lapisan 3-4 bawaan.
  • Jaringan pengiriman konten. Ini memposisikan Relecloud untuk menggunakan jaringan pengiriman konten. Jaringan pengiriman konten menyediakan akselerasi situs.

• Firewall aplikasi web: Gunakan Azure Web Application Firewall untuk memberikan perlindungan terpusat dari eksploitasi dan kerentanan web umum. Relecloud menggunakan Azure Web Application Firewall karena alasan berikut:

  • Perlindungan global. Ini memberikan perlindungan aplikasi web global yang ditingkatkan tanpa mengorbankan performa.
  • Perlindungan botnet. Tim dapat memantau dan mengonfigurasi pengaturan untuk mengatasi masalah keamanan yang terkait dengan botnet.
  • Paritas dengan lokal. Solusi lokal berjalan di belakang firewall aplikasi web yang dikelola oleh IT.
  • Kemudahan penggunaan. Web Application Firewall terintegrasi dengan Azure Front Door.

• Penyimpanan konfigurasi: Pilih apakah akan menambahkan penyimpanan konfigurasi aplikasi ke aplikasi web Anda. Azure App Configuration adalah layanan untuk mengelola pengaturan aplikasi dan bendera fitur secara terpusat. Tinjau praktik terbaik App Configuration untuk memutuskan apakah layanan ini cocok untuk aplikasi Anda. Relecloud ingin mengganti konfigurasi berbasis file dengan penyimpanan konfigurasi pusat yang terintegrasi dengan platform dan kode aplikasi. Mereka menambahkan App Configuration ke arsitektur karena alasan berikut:

  • Keleluasaan. Ini mendukung bendera fitur. Bendera fitur memungkinkan pengguna untuk memilih ikut serta dan keluar dari fitur pratinjau awal di lingkungan produksi tanpa memerlukan penyebaran ulang aplikasi.
  • Dukungan alur Git. Sumber kebenaran untuk data konfigurasi diperlukan untuk menjadi repositori Git. Alur diperlukan untuk memperbarui data di penyimpanan konfigurasi pusat.
  • Dukungan identitas terkelola. Ini mendukung identitas terkelola untuk menyederhanakan dan membantu mengamankan koneksi ke penyimpanan konfigurasi.

• Manajer rahasia: Gunakan Azure Key Vault jika Anda memiliki rahasia untuk dikelola di Azure. Anda dapat menggabungkan Key Vault di aplikasi .NET dengan menggunakan objek ConfigurationBuilder. Aplikasi web lokal Relecloud menyimpan rahasia dalam file konfigurasi kode, tetapi praktik keamanan yang lebih baik adalah menyimpan rahasia di lokasi yang mendukung kontrol RBAC dan audit. Meskipun identitas terkelola adalah solusi pilihan untuk menyambungkan ke sumber daya Azure, Relecloud memiliki rahasia aplikasi yang perlu mereka kelola. Relecloud menggunakan Key Vault karena alasan berikut:

  • Enkripsi. Ini mendukung enkripsi saat tidak aktif dan saat transit.
  • Dukungan identitas terkelola. Layanan aplikasi dapat menggunakan identitas terkelola untuk mengakses penyimpanan rahasia.
  • Pemantauan dan pengelogan. Key Vault memfasilitasi akses audit dan menghasilkan pemberitahuan saat rahasia tersimpan berubah.
  • Integrasi. Key Vault menyediakan integrasi asli dengan penyimpanan konfigurasi Azure (App Configuration) dan platform hosting web (App Service).

• solusi Storage: Lihat opsi penyimpanan Azure untuk memilih solusi penyimpanan yang tepat berdasarkan kebutuhan Anda. Aplikasi web lokal Relecloud memiliki penyimpanan disk yang dipasang ke setiap server web, tetapi tim ingin menggunakan solusi penyimpanan data eksternal. Relecloud memilih Azure Blob Storage karena alasan berikut:

  • Akses keamanan yang ditingkatkan. Aplikasi web dapat menghilangkan titik akhir untuk mengakses penyimpanan yang terekspos ke internet publik dengan akses anonim.
  • Enkripsi. Blob Storage mengenkripsi data saat tidak aktif dan saat transit.
  • Ketahanan. Blob Storage mendukung penyimpanan zona redundan (ZRS). Penyimpanan redundansi zona mereplikasi data secara sinkron di tiga zona ketersediaan Azure di wilayah utama. Setiap zona ketersediaan berada di lokasi fisik terpisah yang memiliki daya, pendinginan, dan jaringan independen. Konfigurasi ini harus membuat gambar tiket tahan terhadap kerugian.

• Keamanan titik akhir: Gunakan Azure Private Link untuk mengakses solusi platform as a service (PaaS) melalui titik akhir privat di jaringan virtual Anda. Lalu lintas antara jaringan virtual Anda dan layanan berjalan di seluruh jaringan backbone Microsoft. Relecloud memilih Private Link karena alasan berikut:

  • Komunikasi keamanan yang ditingkatkan. Private Link memungkinkan aplikasi mengakses layanan secara privat di platform Azure dan mengurangi jejak jaringan penyimpanan data untuk membantu melindungi dari kebocoran data.
  • Usaha minimal. Titik akhir privat mendukung platform aplikasi web dan platform database yang digunakan aplikasi web. Kedua platform mencerminkan konfigurasi lokal yang ada, sehingga diperlukan perubahan minimal.

• Keamanan jaringan. Gunakan Azure Firewall untuk mengontrol lalu lintas masuk dan keluar di tingkat jaringan. Gunakan Azure Bastion untuk menyambungkan ke komputer virtual dengan keamanan yang ditingkatkan, tanpa mengekspos port RDP/SSH. Relecloud mengadopsi topologi jaringan hub-and-spoke dan ingin menempatkan layanan keamanan jaringan bersama di hub. Azure Firewall meningkatkan keamanan dengan memeriksa semua lalu lintas keluar dari spoke untuk meningkatkan keamanan jaringan. Relecloud memerlukan Azure Bastion untuk penyebaran keamanan yang ditingkatkan dari jump host di subnet DevOps.

Panduan kode

Agar berhasil memindahkan aplikasi web ke cloud, Anda perlu memperbarui kode aplikasi web dengan pola Coba Lagi, pola Pemutus Sirkuit, dan pola Cache-Aside.

Gambar 3. Peran pola desain.

Setiap pola desain memberikan manfaat desain beban kerja yang selaras dengan satu atau beberapa pilar Well-Architected Framework. Berikut adalah gambaran umum pola yang harus Anda terapkan:

1. Pola coba lagi. Pola Coba lagi menangani kegagalan sementara dengan mencoba kembali operasi yang mungkin gagal secara terputus-putus. Terapkan pola ini pada semua panggilan keluar ke layanan Azure lainnya.

2. Pola Pemutus Sirkuit. Pola Circuit Breaker mencegah aplikasi mencoba kembali operasi yang tidak sementara. Terapkan pola ini dalam semua panggilan keluar ke layanan Azure lainnya.

3. Cache-Aside pola. Pola Cache-Aside memuat data sesuai permintaan ke dalam cache dari penyimpanan data. Terapkan pola ini pada permintaan ke database.

Pola rancangan	Keandalan (RE)	Keamanan (SE)	Pengoptimalan Biaya (CO)	Keunggulan Operasional (OE)	Efisiensi Performa (PE)	Mendukung prinsip WAF
Pola coba lagi	✔					RE:07
pola Pemutus Sirkuit	✔				✔	RE:03 RE:07 PE:07 PE:11
polaCache-Aside	✔				✔	RE:05 PE:08 PE:12

Menerapkan pola Coba Lagi

Tambahkan pola Coba lagi ke kode aplikasi Anda untuk mengatasi gangguan layanan sementara. Gangguan ini disebut kesalahan sementara. Kesalahan sementara biasanya diselesaikan sendiri dalam hitungan detik. Pola Coba Lagi memungkinkan Anda mengirim ulang permintaan yang gagal. Ini juga memungkinkan Anda untuk mengonfigurasi penundaan antara percobaan ulang dan jumlah upaya yang harus dilakukan sebelum kegagalan kecocokan.

• Gunakan mekanisme coba lagi bawaan. Gunakan mekanisme coba lagi bawaan yang disediakan sebagian besar layanan Azure untuk mempercepat implementasi Anda. Misalnya, implementasi referensi menggunakan ketahanan koneksi di Entity Framework Core untuk menerapkan pola Coba Lagi dalam permintaan ke SQL Database:

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

• Gunakan pustaka pemrograman coba lagi. Untuk komunikasi HTTP, integrasikan pustaka ketahanan standar seperti Polly atau Microsoft.Extensions.Http.Resilience. Pustaka ini menyediakan mekanisme coba lagi komprehensif yang sangat penting untuk mengelola komunikasi dengan layanan web eksternal. Misalnya, implementasi referensi menggunakan Polly untuk menerapkan pola Coba Lagi setiap kali kode membuat objek yang memanggil objek IConcertSearchService:

  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);
  }
  

Terapkan pola Pemutus Sirkuit

Gunakan pola Circuit Breaker untuk menangani gangguan layanan yang bukan kesalahan sementara. Pola Circuit Breaker mencegah aplikasi terus mencoba mengakses layanan yang tidak responsif. Ini merilis aplikasi dan membantu mencegah pemborbuan siklus CPU sehingga aplikasi mempertahankan integritas performanya untuk pengguna akhir.

Misalnya, implementasi referensi menerapkan pola Circuit Breaker pada semua permintaan ke API. Ini menggunakan logika HandleTransientHttpError untuk mendeteksi permintaan HTTP yang dapat diulang kembali dengan aman tetapi membatasi jumlah kesalahan agregat selama periode waktu tertentu:

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

Menerapkan pola Cache-Aside

Tambahkan pola Cache-Aside ke aplikasi web Anda untuk meningkatkan manajemen data dalam memori. Pola menetapkan aplikasi tanggung jawab menangani permintaan data dan memastikan konsistensi antara cache dan penyimpanan persisten, seperti database. Ini mempersingkat waktu respons, meningkatkan throughput, dan mengurangi kebutuhan akan lebih banyak penskalaan. Ini juga mengurangi beban pada datastore utama, yang meningkatkan keandalan dan pengoptimalan biaya. Untuk menerapkan pola Cache-Aside, ikuti rekomendasi berikut:

• Konfigurasikan aplikasi untuk menggunakan cache. Aplikasi produksi harus menggunakan cache Redis terdistribusi. Cache ini meningkatkan performa dengan mengurangi kueri database. Ini juga memungkinkan sesi nonsticky sehingga load balancer dapat mendistribusikan lalu lintas secara merata. Implementasi referensi menggunakan cache Redis terdistribusi. Metode AddAzureCacheForRedis mengonfigurasi aplikasi untuk menggunakan Azure Cache for Redis:

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

• Cache data dengan kebutuhan tinggi. Terapkan pola Cache-Aside pada data berkebutuh tinggi untuk meningkatkan efektivitasnya. Gunakan Azure Monitor untuk melacak CPU, memori, dan penyimpanan database. Metrik ini membantu Anda menentukan apakah Anda dapat menggunakan SKU database yang lebih kecil setelah menerapkan pola Cache-Aside. Misalnya, implementasi referensi menyimpan data dengan kebutuhan tinggi yang mendukung halaman Konser Mendatang. Metode GetUpcomingConcertsAsync menarik data ke cache Redis dari SQL Database dan mengisi cache dengan data konser terbaru:

  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>();
  }
  

• Jaga agar data cache tetap segar. Jadwalkan pembaruan cache reguler untuk disinkronkan dengan perubahan database terbaru. Gunakan volatilitas data dan pengguna perlu menentukan laju refresh yang optimal. Praktik ini memastikan bahwa aplikasi menggunakan pola Cache-Aside untuk memberikan akses cepat dan informasi saat ini. Misalnya, implementasi referensi menyimpan data hanya selama satu jam dan menggunakan metode CreateConcertAsync untuk menghapus kunci cache saat data berubah:

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

• Pastikan 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. Implementasi referensi menggunakan metode UpdateConcertAsync untuk menjaga data dalam cache tetap konsisten:

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

Panduan konfigurasi

Bagian berikut memberikan panduan tentang menerapkan pembaruan konfigurasi. Setiap bagian selaras dengan satu atau beberapa pilar Kerangka Kerja Well-Architected.

Konfigurasi	Keandalan (RE)	Keamanan (SE)	Pengoptimalan Biaya (CO)	Keunggulan Operasional (OE)	Efisiensi Performa (PE)	Mendukung prinsip WAF
Mengonfigurasi autentikasi dan otorisasi pengguna		✔		✔		SE:05 OE:10
Menerapkan identitas terkelola		✔		✔		SE:05 OE:10
Lingkungan rightsize			✔			CO:05 CO:06
Menerapkan penskalakan otomatis	✔		✔		✔	RE:06 CO:12 PE:05
Mengotomatiskan penyebaran sumber daya				✔		OE:05
Menerapkan pemantauan			✔	✔	✔	OE:07 PE:04

Mengonfigurasi autentikasi dan otorisasi pengguna

Saat Anda memigrasikan aplikasi web ke Azure, konfigurasikan mekanisme autentikasi dan otorisasi pengguna. Ikuti rekomendasi berikut:

• Gunakan platform identitas. Gunakan platform Identitas Microsoft untuk menyiapkan autentikasi aplikasi web. Platform ini mendukung aplikasi yang menggunakan satu direktori Microsoft Entra, beberapa direktori Microsoft Entra dari organisasi yang berbeda, dan identitas Microsoft atau akun sosial.

• Membuat pendaftaran aplikasi. ID Microsoft Entra memerlukan pendaftaran aplikasi di penyewa utama. Pendaftaran aplikasi membantu memastikan bahwa pengguna yang mendapatkan akses ke aplikasi web memiliki identitas di penyewa utama.

• Gunakan fitur platform. Minimalkan kebutuhan akan kode autentikasi kustom dengan menggunakan kemampuan platform untuk mengautentikasi pengguna dan mengakses data. Misalnya, App Service menyediakan dukungan autentikasi bawaan, sehingga Anda dapat memasukkan pengguna dan mengakses data saat menulis kode minimal atau tanpa kode di aplikasi web Anda.

• Menerapkan otorisasi dalam aplikasi. Gunakan RBAC untuk menetapkan hak istimewa paling sedikit untuk peran aplikasi. Tentukan peran tertentu untuk tindakan pengguna yang berbeda untuk menghindari tumpang tindih dan memastikan kejelasan. Petakan pengguna ke peran yang sesuai dan pastikan mereka hanya memiliki akses ke sumber daya dan tindakan yang diperlukan.

• Lebih suka akses sementara ke penyimpanan. Gunakan izin sementara untuk melindungi dari akses dan pelanggaran yang tidak sah. Misalnya, Anda dapat menggunakan tanda tangan akses bersama (SAS) untuk membatasi akses ke jangka waktu tertentu. Gunakan SAS delegasi pengguna untuk memaksimalkan keamanan saat Anda memberikan akses sementara. Ini adalah satu-satunya SAS yang menggunakan kredensial ID Microsoft Entra dan tidak memerlukan kunci akun penyimpanan permanen.

• Menerapkan otorisasi di Azure. Gunakan Azure RBAC untuk menetapkan hak istimewa paling sedikit ke identitas pengguna. Azure RBAC menentukan sumber daya Azure yang dapat diakses identitas, apa yang dapat mereka lakukan dengan sumber daya tersebut, dan area yang dapat mereka akses.

• Hindari izin permanen yang ditingkatkan. Gunakan Microsoft Entra Privileged Identity Management untuk memberikan akses just-in-time untuk operasi istimewa. Misalnya, pengembang sering memerlukan akses tingkat administrator untuk membuat/menghapus database, mengubah skema tabel, dan mengubah izin pengguna. Saat Anda menggunakan akses just-in-time, identitas pengguna menerima izin sementara untuk melakukan tugas istimewa.

Menggunakan identitas terkelola

Gunakan identitas terkelola untuk semua layanan Azure yang mendukungnya. Identitas terkelola memungkinkan sumber daya Azure (identitas beban kerja) untuk mengautentikasi dan berinteraksi dengan layanan Azure lainnya tanpa mengharuskan Anda mengelola kredensial. Untuk menyederhanakan migrasi, Anda dapat terus menggunakan solusi autentikasi lokal untuk sistem hibrid dan warisan, tetapi Anda harus mentransisikannya ke identitas terkelola sesegera mungkin. Untuk menerapkan identitas terkelola, ikuti rekomendasi berikut:

• Pilih jenis identitas terkelola yang tepat. Lebih suka identitas terkelola yang ditetapkan pengguna saat Anda memiliki dua atau beberapa sumber daya Azure yang memerlukan sekumpulan izin yang sama. Pendekatan ini lebih efisien daripada membuat identitas terkelola yang ditetapkan sistem untuk masing-masing sumber daya tersebut dan menetapkan izin yang sama untuk semuanya. Jika tidak, gunakan identitas terkelola yang ditetapkan sistem.

• Konfigurasikan hak istimewa paling sedikit. Gunakan Azure RBAC untuk hanya memberikan 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. Jika Azure RBAC tidak mencakup skenario tertentu, lengkapi Azure RBAC dengan kebijakan akses tingkat layanan Azure.

• Berikan keamanan untuk rahasia yang tersisa. Simpan rahasia yang tersisa di Azure Key Vault. Muat rahasia dari Key Vault saat pengaktifan aplikasi alih-alih selama setiap permintaan HTTP. Akses frekuensi tinggi dalam permintaan HTTP dapat melebihi batas transaksi Key Vault. Simpan konfigurasi aplikasi di Azure App Configuration.

Implementasi referensi menggunakan argumen Authentication dalam string koneksi database SQL sehingga App Service dapat tersambung ke database SQL dengan menggunakan identitas terkelola: Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default. Ini menggunakan DefaultAzureCredential untuk memungkinkan API web terhubung ke Key Vault dengan menggunakan identitas terkelola:

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

Lingkungan rightsize

Gunakan tingkat performa (SKU) layanan Azure yang memenuhi kebutuhan setiap lingkungan tanpa melebihinya. Untuk menyesuaikan lingkungan Anda, ikuti rekomendasi berikut:

• Memperkirakan biaya. Gunakan kalkulator harga Azure untuk memperkirakan biaya setiap lingkungan.

• Mengoptimalkan lingkungan produksi dengan biaya. Lingkungan produksi memerlukan SKU yang memenuhi perjanjian tingkat layanan (SLA), fitur, dan skala yang diperlukan untuk produksi. Terus memantau penggunaan sumber daya dan menyesuaikan SKU agar selaras dengan kebutuhan performa aktual.

• Lingkungan praproduksi pengoptimalan biaya.lingkungan Praproduksi harus menggunakan sumber daya berbiaya rendah dan memanfaatkan diskon seperti harga Azure Dev/Test. Di lingkungan ini, Anda harus menonaktifkan layanan yang tidak diperlukan. Pada saat yang sama, pastikan bahwa lingkungan praproduksi cukup mirip dengan lingkungan produksi untuk menghindari pengenalan risiko. Mempertahankan saldo ini memastikan bahwa pengujian tetap efektif tanpa menimbulkan biaya yang tidak perlu.

• Gunakan infrastruktur sebagai kode (IaC) untuk menentukan SKU. Terapkan IaC untuk memilih dan menyebarkan SKU yang benar secara dinamis berdasarkan lingkungan. Pendekatan ini meningkatkan konsistensi dan menyederhanakan manajemen.

Misalnya, implementasi referensi menggunakan parameter Bicep untuk menyebarkan tingkat yang lebih mahal (SKU) ke lingkungan produksi:

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

Menerapkan penskalakan otomatis

Penskalaan otomatis membantu memastikan bahwa aplikasi web tetap tangguh, responsif, dan mampu menangani beban kerja dinamis secara efisien. Untuk menerapkan penskalaan otomatis, ikuti rekomendasi berikut:

• Mengotomatiskan peluasan skala. Gunakan skala otomatis Azure untuk mengotomatiskan penskalakan horizontal di lingkungan produksi. Konfigurasikan aturan autoscaling untuk memperluas skala berdasarkan metrik performa utama sehingga aplikasi Anda dapat menangani berbagai beban.

• Menyempurnakan pemicu penskalakan. Gunakan pemanfaatan CPU sebagai pemicu penskalaan awal jika Anda tidak terbiasa dengan persyaratan penskalaan aplikasi Anda. Persempit pemicu penskalan Anda untuk menyertakan metrik lain seperti RAM, throughput jaringan, dan I/O disk. Tujuannya adalah untuk mencocokkan perilaku aplikasi web Anda untuk performa yang lebih baik.

• Berikan buffer peluasan skala. Atur ambang penskalan Anda untuk dipicu sebelum kapasitas maksimum tercapai. Misalnya, konfigurasikan penskalaan agar terjadi pada pemanfaatan CPU 85% daripada menunggu hingga mencapai 100%. Pendekatan proaktif ini membantu menjaga performa dan menghindari potensi hambatan.

Mengotomatiskan penyebaran sumber daya

Gunakan otomatisasi untuk menyebarkan dan memperbarui sumber daya dan kode Azure di semua lingkungan. Ikuti rekomendasi berikut:

• Gunakan infrastruktur sebagai kode. Sebarkan infrastruktur sebagai kode dengan menggunakan alur integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD). Azure menyediakan templat Bicep, ARM (JSON), dan Terraform bawaan untuk setiap sumber daya Azure.

• Gunakan alur integrasi berkelanjutan/penyebaran berkelanjutan (CI/CD). Gunakan alur CI/CD untuk menyebarkan kode dari kontrol sumber ke berbagai lingkungan Anda, seperti pengujian, penahapan, dan produksi. Gunakan Azure Pipelines jika Anda bekerja dengan Azure DevOps. Gunakan GitHub Actions untuk proyek GitHub.

• Mengintegrasikan pengujian unit. Prioritaskan eksekusi dan lolos semua pengujian unit dalam alur Anda sebelum penyebaran apa pun ke App Services. Masukkan kualitas kode dan alat cakupan seperti SonarQube untuk mencapai cakupan pengujian yang komprehensif.

• Mengadopsi kerangka kerja tiruan. Untuk pengujian yang melibatkan titik akhir eksternal, gunakan kerangka kerja tiruan. Kerangka kerja ini memungkinkan Anda membuat titik akhir yang disimulasikan. Mereka menghilangkan kebutuhan untuk mengonfigurasi titik akhir eksternal nyata dan memastikan kondisi pengujian yang seragam di seluruh lingkungan.

• Lakukan pemindaian keamanan. Gunakan pengujian keamanan aplikasi statis (SAST) untuk menemukan kelemahan keamanan dan kesalahan pengkodean dalam kode sumber Anda. Selain itu, lakukan analisis komposisi perangkat lunak (SCA) untuk memeriksa pustaka dan komponen pihak ketiga untuk risiko keamanan. Alat untuk analisis ini mudah diintegrasikan ke dalam GitHub dan Azure DevOps.

Menerapkan pemantauan

Terapkan pemantauan aplikasi dan platform untuk meningkatkan keunggulan operasional dan efisiensi performa aplikasi web Anda. Untuk menerapkan pemantauan, ikuti rekomendasi berikut:

• Kumpulkan telemetri aplikasi. Gunakan autoinstrumentasi di Azure Application Insights untuk mengumpulkan telemetriaplikasi , seperti throughput permintaan, durasi permintaan rata-rata, kesalahan, dan pemantauan dependensi. Anda tidak perlu membuat perubahan kode apa pun untuk menggunakan telemetri ini.

  Implementasi referensi menggunakan AddApplicationInsightsTelemetry dari paket NuGet Microsoft.ApplicationInsights.AspNetCore untuk mengaktifkan pengumpulan telemetri :

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

• Membuat metrik aplikasi kustom. Gunakan instrumentasi berbasis kode untuk telemetri aplikasi kustom. Tambahkan Application Insights SDK ke kode Anda dan gunakan API Application Insights.

  Implementasi referensi mengumpulkan telemetri pada peristiwa yang terkait dengan aktivitas kelistrikan. this.telemetryClient.TrackEvent menghitung tiket yang ditambahkan ke kelir. Ini menyediakan nama peristiwa (AddToCart) dan menentukan kamus yang memiliki concertId dan count:

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

• Pantau platform. Aktifkan diagnostik untuk semua layanan yang didukung. Kirim diagnostik ke tujuan yang sama dengan log aplikasi untuk korelasi. Layanan Azure membuat log platform secara otomatis tetapi hanya menyimpannya saat Anda mengaktifkan diagnostik. Aktifkan pengaturan diagnostik untuk setiap layanan yang mendukung diagnostik.

Menyebarkan implementasi referensi

Implementasi referensi memandu pengembang melalui migrasi yang disimulasikan dari aplikasi ASP.NET lokal ke Azure, menyoroti perubahan yang diperlukan selama fase adopsi awal. Contoh ini menggunakan aplikasi tiket konser untuk perusahaan fiksi Relecloud, yang menjual tiket melalui aplikasi web lokalnya. Relecloud menetapkan tujuan berikut untuk aplikasi web mereka:

• Menerapkan perubahan kode bernilai rendah dan bernilai tinggi.
• Raih SLO 99,9%.
• Mengadopsi praktik DevOps.
• Buat lingkungan yang dioptimalkan biaya.
• Tingkatkan keandalan dan keamanan.

Relecloud menentukan bahwa infrastruktur lokal mereka bukan solusi hemat biaya untuk memenuhi tujuan ini. Mereka memutuskan bahwa memigrasikan aplikasi web mereka ke Azure adalah cara paling hemat biaya untuk mencapai tujuan langsung dan masa depan mereka. Arsitektur berikut mewakili status akhir implementasi pola Reliable Web App Relecloud.

Gambar 4. Arsitektur implementasi referensi. Unduh file visio arsitektur ini.

Implementasi referensi

Artikel ini menyediakan panduan untuk menerapkan pola Reliable Web App. Pola ini menjelaskan cara memodifikasi (replatform) aplikasi web untuk migrasi cloud. Ini menyediakan arsitektur preskriptif, kode, dan panduan konfigurasi yang selaras dengan prinsip Azure Well-Architected Framework.

Mengapa pola Reliable Web App untuk .NET?

Pola Reliable Web App adalah serangkaian prinsip dan teknik implementasi yang menentukan bagaimana Anda harus mereplatformasi aplikasi web saat Anda memigrasikannya ke cloud. Ini berfokus pada pembaruan kode minimal yang perlu Anda buat agar berhasil di cloud. Panduan berikut menggunakan implementasi referensi sebagai contoh di seluruh. Panduan ini mengikuti perjalanan replatform perusahaan fiktif Relecloud untuk memberikan konteks bisnis untuk perjalanan Anda. Sebelum menerapkan pola Reliable Web App untuk .NET, Relecloud memiliki aplikasi web tiket lokal monolitik yang menggunakan kerangka kerja ASP.NET.

Petunjuk / Saran

Ada implementasi referensi (sampel) dari pola Reliable Web App. Ini mewakili status akhir implementasi Reliable Web App untuk perusahaan fiktif bernama Relecloud. Ini adalah aplikasi web tingkat produksi yang menampilkan semua pembaruan kode, arsitektur, dan konfigurasi yang dibahas dalam artikel ini. Sebarkan dan gunakan implementasi referensi untuk memandu implementasi pola Reliable Web App Anda.

Cara menerapkan pola Reliable Web App

Artikel ini mencakup arsitektur, kode, dan panduan konfigurasi untuk menerapkan pola Reliable Web App. Gunakan tautan berikut untuk masuk ke panduan spesifik yang Anda butuhkan:

• Konteks bisnis. Selaraskan panduan ini dengan konteks bisnis Anda dan pelajari cara menentukan tujuan segera dan jangka panjang yang mendorong keputusan replatforming.
• panduan Arsitektur . Pelajari cara memilih layanan cloud yang tepat dan merancang arsitektur yang memenuhi persyaratan bisnis Anda.
• Panduan kode. Terapkan tiga pola desain untuk meningkatkan keandalan dan efisiensi performa aplikasi web Anda di cloud: pola Coba Lagi, Pemutus Sirkuit, dan Cache-Aside.
• panduan Konfigurasi . Mengonfigurasi autentikasi dan otorisasi, identitas terkelola, lingkungan yang disahkan, infrastruktur sebagai kode, dan pemantauan.

Konteks bisnis

Langkah pertama dalam mereplatformasi aplikasi web adalah menentukan tujuan bisnis Anda. Anda harus menetapkan tujuan langsung, seperti tujuan tingkat layanan (SLO) dan target pengoptimalan biaya, dan juga tujuan di masa mendatang untuk aplikasi web Anda. Tujuan ini memengaruhi pilihan layanan cloud dan arsitektur aplikasi web Anda di cloud. Tentukan SLO target untuk aplikasi web Anda, seperti waktu aktif 99,9%. Hitung SLA komposit untuk semua layanan yang memengaruhi ketersediaan aplikasi web Anda.

Misalnya, Relecloud memiliki prakiraan penjualan yang positif dan mengantisipasi peningkatan permintaan pada aplikasi web tiket mereka. Untuk memenuhi permintaan ini, mereka mendefinisikan tujuan untuk aplikasi web:

• Terapkan perubahan kode bernilai rendah dan bernilai tinggi.
• Jangkau SLO 99,9%.
• Mengadopsi praktik DevOps.
• Buat lingkungan yang dioptimalkan biaya.
• Meningkatkan keandalan dan keamanan.

Infrastruktur lokal Relecloud bukanlah solusi hemat biaya untuk mencapai tujuan ini. Mereka memutuskan bahwa memigrasikan aplikasi web mereka ke Azure adalah cara paling hemat biaya untuk mencapai tujuan langsung dan masa depan mereka.

Panduan arsitektur

Pola Reliable Web App memiliki beberapa elemen arsitektur penting. Anda memerlukan DNS untuk mengelola resolusi titik akhir, firewall aplikasi web untuk memblokir lalu lintas HTTP berbahaya, dan load balancer untuk merutekan dan membantu melindungi permintaan pengguna masuk. Platform aplikasi menghosting kode aplikasi web Anda dan melakukan panggilan ke semua layanan back-end melalui titik akhir privat dalam jaringan virtual. Alat pemantauan performa aplikasi menangkap metrik dan log untuk membantu Anda memahami aplikasi web Anda.

Gambar 1. Elemen arsitektur penting dari pola Reliable Web App.

Merancang arsitektur

Rancang infrastruktur Anda untuk mendukung metrik pemulihan Anda, seperti tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO). RTO memengaruhi ketersediaan dan harus mendukung SLO Anda. Tentukan RPO dan konfigurasikan redundansi data untuk memenuhi RPO.

• Pilih keandalan infrastruktur. Tentukan berapa banyak zona dan wilayah ketersediaan yang Anda butuhkan untuk memenuhi persyaratan ketersediaan Anda. Tambahkan zona dan wilayah ketersediaan hingga SLA komposit memenuhi SLO Anda. Pola Reliable Web App mendukung beberapa wilayah untuk konfigurasi aktif-aktif atau pasif aktif. Misalnya, implementasi referensi menggunakan konfigurasi pasif aktif untuk memenuhi SLO sebesar 99,9%.

  Untuk aplikasi web multi-wilayah, konfigurasikan load balancer Anda untuk merutekan lalu lintas ke wilayah kedua untuk mendukung konfigurasi aktif-aktif atau pasif aktif, tergantung pada kebutuhan bisnis Anda. Dua wilayah memerlukan layanan yang sama, kecuali satu wilayah memiliki jaringan virtual hub yang menghubungkan wilayah. Mengadopsi topologi jaringan hub-and-spoke untuk mempusatkan dan berbagi sumber daya, seperti firewall jaringan. Jika Anda memiliki komputer virtual, tambahkan host bastion ke jaringan virtual hub untuk mengelolanya dengan keamanan yang ditingkatkan. (Lihat gambar 2.)

  

  Gambar 2. Pola Reliable Web App dengan wilayah kedua dan topologi hub-and-spoke.

• Pilih topologi jaringan. Pilih topologi jaringan yang tepat untuk persyaratan web dan jaringan Anda. Jika Anda berencana menggunakan beberapa jaringan virtual, gunakan topologi jaringan hub-and-spoke . Ini memberikan manfaat biaya, manajemen, dan keamanan dan opsi konektivitas hibrid ke jaringan lokal dan virtual.

Pilih layanan Azure yang tepat

Saat memindahkan aplikasi web ke cloud, Anda harus memilih layanan Azure yang memenuhi persyaratan bisnis Anda dan selaras dengan fitur aplikasi web lokal saat ini. Penyelarasan ini membantu meminimalkan upaya replatforming. Misalnya, gunakan layanan yang memungkinkan Anda menyimpan mesin database yang sama dan mendukung middleware dan kerangka kerja yang ada. Bagian berikut ini menyediakan panduan untuk memilih layanan Azure yang tepat untuk aplikasi web Anda.

Misalnya, sebelum dipindahkan ke cloud, aplikasi web tiket Relecloud adalah aplikasi ASP.NET monolitik lokal. Ini berjalan pada dua komputer virtual dan menggunakan database SQL Server. Aplikasi web menderita masalah umum dengan skalabilitas dan penyebaran fitur. Titik awal ini, tujuan bisnis mereka, dan SLO mendorong pilihan layanan mereka.

• Platform aplikasi: Gunakan Azure App Service sebagai platform aplikasi Anda. Relecloud memilih App Service sebagai platform aplikasi karena alasan berikut:

  • Perjanjian tingkat layanan tinggi (SLA). Ini memiliki SLA tinggi yang memenuhi lingkungan produksi SLO 99,9%.
  • Mengurangi overhead manajemen. Ini adalah solusi yang dikelola sepenuhnya yang menangani penskalaan, pemeriksaan kesehatan, dan penyeimbangan beban.
  • Dukungan .NET. Ini mendukung versi .NET tempat aplikasi ditulis.
  • Kemampuan kontainerisasi. Aplikasi web dapat bertemu di cloud tanpa kontainer, tetapi platform aplikasi juga mendukung kontainerisasi tanpa mengubah layanan Azure.
  • Penskalakan otomatis. Aplikasi web dapat secara otomatis menskalakan masuk dan keluar berdasarkan lalu lintas pengguna dan pengaturan konfigurasi. Platform ini juga mendukung peningkatan atau penurunan skala untuk mengakomodasi persyaratan hosting yang berbeda.

• Manajemen identitas: Gunakan ID Microsoft Entra sebagai solusi manajemen identitas dan akses Anda. Relecloud memilih MICROSOFT Entra ID karena alasan berikut:

  • Autentikasi dan otorisasi. Aplikasi perlu mengautentikasi dan mengotorisasi karyawan pusat panggilan.
  • Dapat diskalakan. Microsoft Entra ID menskalakan untuk mendukung skenario yang lebih besar.
  • Kontrol identitas pengguna. Karyawan pusat panggilan dapat menggunakan identitas perusahaan yang ada.
  • Dukungan protokol otorisasi. MICROSOFT Entra ID mendukung OAuth 2.0 untuk identitas terkelola.

• Database: Gunakan layanan yang memungkinkan Anda menyimpan mesin database yang sama. Gunakan pohon keputusan penyimpanan data untuk memandu pilihan Anda. Aplikasi web Relecloud menggunakan SQL Server lokal. Mereka ingin menggunakan skema database, prosedur tersimpan, dan fungsi yang ada. Beberapa produk SQL tersedia di Azure, tetapi Relecloud memilih Azure SQL Database karena alasan berikut:

  • Keandalan. Tingkat tujuan umum menyediakan SLA tinggi dan redundansi multi-wilayah. Ini dapat mendukung beban pengguna yang tinggi.
  • Mengurangi overhead manajemen. SQL Database menyediakan instans database SQL terkelola.
  • Dukungan migrasi. Ini mendukung migrasi database dari SQL Server lokal.
  • Konsistensi dengan konfigurasi lokal. Ini mendukung prosedur, fungsi, dan tampilan tersimpan yang ada.
  • Ketahanan. Ini mendukung pencadangan dan pemulihan titik waktu.
  • Keahlian dan pengerjaan ulang minimal. SQL Database memungkinkan Relecloud memanfaatkan keahlian yang ada dan membutuhkan pekerjaan minimal untuk diadopsi.

• Pemantauan performa aplikasi: Gunakan Application Insights untuk menganalisis telemetri untuk aplikasi Anda. Relecloud memilih untuk menggunakan Application Insights karena alasan berikut:

  • Integrasi dengan Azure Monitor. Ini menyediakan integrasi terbaik dengan Azure Monitor.
  • Deteksi anomali. Ini secara otomatis mendeteksi anomali performa.
  • Pemecahan masalah. Ini membantu Anda mendiagnosis masalah di aplikasi yang sedang berjalan.
  • Pemantauan. Ini mengumpulkan informasi tentang bagaimana pengguna menggunakan aplikasi dan memungkinkan Anda untuk dengan mudah melacak peristiwa kustom.
  • Kesenjangan visibilitas. Solusi lokal tidak memiliki solusi pemantauan performa aplikasi. Application Insights menyediakan integrasi yang mudah dengan platform dan kode aplikasi.

• Cache: Pilih apakah akan menambahkan cache ke arsitektur aplikasi web Anda. Azure Cache for Redis adalah solusi cache Azure utama. Ini adalah penyimpanan data dalam memori terkelola yang didasarkan pada perangkat lunak Redis. Beban aplikasi web Relecloud sangat miring untuk melihat konser dan detail tempat. Relecloud menambahkan Azure Cache for Redis karena alasan berikut:

  • Mengurangi overhead manajemen. Ini adalah layanan yang dikelola sepenuhnya.
  • Kecepatan dan volume. Ini memiliki throughput data tinggi dan baca latensi rendah untuk data yang umum diakses dan berubah lambat.
  • Beragam dukungan. Ini adalah lokasi cache terpadu untuk semua instans aplikasi web yang akan digunakan.
  • Penyimpanan data eksternal. Server aplikasi lokal melakukan penembolokan lokal VM. Penyiapan ini tidak membongkar data yang sangat sering, dan tidak dapat membatalkan data.
  • Sesi nonsticky. Eksternalisasi status sesi mendukung sesi nonsticky.

• Load balancer: aplikasi web yang menggunakan solusi PaaS harus menggunakan Azure Front Door, Azure Application Gateway, atau keduanya, tergantung pada arsitektur dan persyaratan aplikasi web. Gunakan pohon keputusan load balancer untuk memilih load balancer yang tepat. Relecloud memerlukan load balancer lapisan-7 yang dapat merutekan lalu lintas di beberapa wilayah. Perusahaan ini membutuhkan aplikasi web multi-wilayah untuk memenuhi SLO 99,9%. Relecloud memilih Azure Front Door karena alasan berikut:

  • Penyeimbangan beban global. Ini adalah load balancer lapisan-7 yang dapat merutekan lalu lintas di beberapa wilayah.
  • Firewall aplikasi web. Ini terintegrasi secara asli dengan Azure Web Application Firewall.
  • Fleksibilitas perutean. Ini memungkinkan tim aplikasi untuk mengonfigurasi ingress perlu mendukung perubahan di masa mendatang dalam aplikasi.
  • Akselerasi lalu lintas. Ini menggunakan anycast untuk mencapai titik kehadiran Azure terdekat dan menemukan rute tercepat ke aplikasi web.
  • Domain kustom. Ini mendukung nama domain kustom dengan validasi domain yang fleksibel.
  • Pemeriksaan kesehatan. Aplikasi ini memerlukan pemantauan pemeriksaan kesehatan cerdas. Azure Front Door menggunakan respons dari pemeriksaan untuk menentukan asal terbaik untuk merutekan permintaan klien.
  • Memantau dukungan. Ini mendukung laporan bawaan dengan dasbor all-in-one untuk Azure Front Door dan pola keamanan. Anda dapat mengonfigurasi pemberitahuan yang terintegrasi dengan Azure Monitor. Azure Front Door memungkinkan aplikasi untuk mencatat setiap permintaan dan pemeriksaan kesehatan yang gagal.
  • Perlindungan DDoS. Ini memiliki perlindungan DDoS lapisan 3-4 bawaan.
  • Jaringan pengiriman konten. Ini memposisikan Relecloud untuk menggunakan jaringan pengiriman konten. Jaringan pengiriman konten menyediakan akselerasi situs.

• Firewall aplikasi web: Gunakan Azure Web Application Firewall untuk memberikan perlindungan terpusat dari eksploitasi dan kerentanan web umum. Relecloud menggunakan Azure Web Application Firewall karena alasan berikut:

  • Perlindungan global. Ini memberikan perlindungan aplikasi web global yang ditingkatkan tanpa mengorbankan performa.
  • Perlindungan botnet. Tim dapat memantau dan mengonfigurasi pengaturan untuk mengatasi masalah keamanan yang terkait dengan botnet.
  • Paritas dengan lokal. Solusi lokal berjalan di belakang firewall aplikasi web yang dikelola oleh IT.
  • Kemudahan penggunaan. Web Application Firewall terintegrasi dengan Azure Front Door.

• Penyimpanan konfigurasi: Pilih apakah akan menambahkan penyimpanan konfigurasi aplikasi ke aplikasi web Anda. Azure App Configuration adalah layanan untuk mengelola pengaturan aplikasi dan bendera fitur secara terpusat. Tinjau praktik terbaik App Configuration untuk memutuskan apakah layanan ini cocok untuk aplikasi Anda. Relecloud ingin mengganti konfigurasi berbasis file dengan penyimpanan konfigurasi pusat yang terintegrasi dengan platform dan kode aplikasi. Mereka menambahkan App Configuration ke arsitektur karena alasan berikut:

  • Keleluasaan. Ini mendukung bendera fitur. Bendera fitur memungkinkan pengguna untuk memilih ikut serta dan keluar dari fitur pratinjau awal di lingkungan produksi tanpa memerlukan penyebaran ulang aplikasi.
  • Dukungan alur Git. Sumber kebenaran untuk data konfigurasi diperlukan untuk menjadi repositori Git. Alur diperlukan untuk memperbarui data di penyimpanan konfigurasi pusat.
  • Dukungan identitas terkelola. Ini mendukung identitas terkelola untuk menyederhanakan dan membantu mengamankan koneksi ke penyimpanan konfigurasi.

• Manajer rahasia: Gunakan Azure Key Vault jika Anda memiliki rahasia untuk dikelola di Azure. Anda dapat menggabungkan Key Vault di aplikasi .NET dengan menggunakan objek ConfigurationBuilder. Aplikasi web lokal Relecloud menyimpan rahasia dalam file konfigurasi kode, tetapi praktik keamanan yang lebih baik adalah menyimpan rahasia di lokasi yang mendukung kontrol RBAC dan audit. Meskipun identitas terkelola adalah solusi pilihan untuk menyambungkan ke sumber daya Azure, Relecloud memiliki rahasia aplikasi yang perlu mereka kelola. Relecloud menggunakan Key Vault karena alasan berikut:

  • Enkripsi. Ini mendukung enkripsi saat tidak aktif dan saat transit.
  • Dukungan identitas terkelola. Layanan aplikasi dapat menggunakan identitas terkelola untuk mengakses penyimpanan rahasia.
  • Pemantauan dan pengelogan. Key Vault memfasilitasi akses audit dan menghasilkan pemberitahuan saat rahasia tersimpan berubah.
  • Integrasi. Key Vault menyediakan integrasi asli dengan penyimpanan konfigurasi Azure (App Configuration) dan platform hosting web (App Service).

• solusi Storage: Lihat opsi penyimpanan Azure untuk memilih solusi penyimpanan yang tepat berdasarkan kebutuhan Anda. Aplikasi web lokal Relecloud memiliki penyimpanan disk yang dipasang ke setiap server web, tetapi tim ingin menggunakan solusi penyimpanan data eksternal. Relecloud memilih Azure Blob Storage karena alasan berikut:

  • Akses keamanan yang ditingkatkan. Aplikasi web dapat menghilangkan titik akhir untuk mengakses penyimpanan yang terekspos ke internet publik dengan akses anonim.
  • Enkripsi. Blob Storage mengenkripsi data saat tidak aktif dan saat transit.
  • Ketahanan. Blob Storage mendukung penyimpanan zona redundan (ZRS). Penyimpanan redundansi zona mereplikasi data secara sinkron di tiga zona ketersediaan Azure di wilayah utama. Setiap zona ketersediaan berada di lokasi fisik terpisah yang memiliki daya, pendinginan, dan jaringan independen. Konfigurasi ini harus membuat gambar tiket tahan terhadap kerugian.

• Keamanan titik akhir: Gunakan Azure Private Link untuk mengakses solusi platform as a service (PaaS) melalui titik akhir privat di jaringan virtual Anda. Lalu lintas antara jaringan virtual Anda dan layanan berjalan di seluruh jaringan backbone Microsoft. Relecloud memilih Private Link karena alasan berikut:

  • Komunikasi keamanan yang ditingkatkan. Private Link memungkinkan aplikasi mengakses layanan secara privat di platform Azure dan mengurangi jejak jaringan penyimpanan data untuk membantu melindungi dari kebocoran data.
  • Usaha minimal. Titik akhir privat mendukung platform aplikasi web dan platform database yang digunakan aplikasi web. Kedua platform mencerminkan konfigurasi lokal yang ada, sehingga diperlukan perubahan minimal.

• Keamanan jaringan. Gunakan Azure Firewall untuk mengontrol lalu lintas masuk dan keluar di tingkat jaringan. Gunakan Azure Bastion untuk menyambungkan ke komputer virtual dengan keamanan yang ditingkatkan, tanpa mengekspos port RDP/SSH. Relecloud mengadopsi topologi jaringan hub-and-spoke dan ingin menempatkan layanan keamanan jaringan bersama di hub. Azure Firewall meningkatkan keamanan dengan memeriksa semua lalu lintas keluar dari spoke untuk meningkatkan keamanan jaringan. Relecloud memerlukan Azure Bastion untuk penyebaran keamanan yang ditingkatkan dari jump host di subnet DevOps.

Panduan kode

Agar berhasil memindahkan aplikasi web ke cloud, Anda perlu memperbarui kode aplikasi web dengan pola Coba Lagi, pola Pemutus Sirkuit, dan pola Cache-Aside.

Gambar 3. Peran pola desain.

Setiap pola desain memberikan manfaat desain beban kerja yang selaras dengan satu atau beberapa pilar Well-Architected Framework. Berikut adalah gambaran umum pola yang harus Anda terapkan:

1. Pola coba lagi. Pola Coba lagi menangani kegagalan sementara dengan mencoba kembali operasi yang mungkin gagal secara terputus-putus. Terapkan pola ini pada semua panggilan keluar ke layanan Azure lainnya.

2. Pola Pemutus Sirkuit. Pola Circuit Breaker mencegah aplikasi mencoba kembali operasi yang tidak sementara. Terapkan pola ini dalam semua panggilan keluar ke layanan Azure lainnya.

3. Cache-Aside pola. Pola Cache-Aside memuat data sesuai permintaan ke dalam cache dari penyimpanan data. Terapkan pola ini pada permintaan ke database.

Pola rancangan	Keandalan (RE)	Keamanan (SE)	Pengoptimalan Biaya (CO)	Keunggulan Operasional (OE)	Efisiensi Performa (PE)	Mendukung prinsip WAF
Pola coba lagi	✔					RE:07
pola Pemutus Sirkuit	✔				✔	RE:03 RE:07 PE:07 PE:11
polaCache-Aside	✔				✔	RE:05 PE:08 PE:12

Menerapkan pola Coba Lagi

Tambahkan pola Coba lagi ke kode aplikasi Anda untuk mengatasi gangguan layanan sementara. Gangguan ini disebut kesalahan sementara. Kesalahan sementara biasanya diselesaikan sendiri dalam hitungan detik. Pola Coba Lagi memungkinkan Anda mengirim ulang permintaan yang gagal. Ini juga memungkinkan Anda untuk mengonfigurasi penundaan antara percobaan ulang dan jumlah upaya yang harus dilakukan sebelum kegagalan kecocokan.

• Gunakan mekanisme coba lagi bawaan. Gunakan mekanisme coba lagi bawaan yang disediakan sebagian besar layanan Azure untuk mempercepat implementasi Anda. Misalnya, implementasi referensi menggunakan ketahanan koneksi di Entity Framework Core untuk menerapkan pola Coba Lagi dalam permintaan ke SQL Database:

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

• Gunakan pustaka pemrograman coba lagi. Untuk komunikasi HTTP, integrasikan pustaka ketahanan standar seperti Polly atau Microsoft.Extensions.Http.Resilience. Pustaka ini menyediakan mekanisme coba lagi komprehensif yang sangat penting untuk mengelola komunikasi dengan layanan web eksternal. Misalnya, implementasi referensi menggunakan Polly untuk menerapkan pola Coba Lagi setiap kali kode membuat objek yang memanggil objek IConcertSearchService:

  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);
  }
  

Terapkan pola Pemutus Sirkuit

Gunakan pola Circuit Breaker untuk menangani gangguan layanan yang bukan kesalahan sementara. Pola Circuit Breaker mencegah aplikasi terus mencoba mengakses layanan yang tidak responsif. Ini merilis aplikasi dan membantu mencegah pemborbuan siklus CPU sehingga aplikasi mempertahankan integritas performanya untuk pengguna akhir.

Misalnya, implementasi referensi menerapkan pola Circuit Breaker pada semua permintaan ke API. Ini menggunakan logika HandleTransientHttpError untuk mendeteksi permintaan HTTP yang dapat diulang kembali dengan aman tetapi membatasi jumlah kesalahan agregat selama periode waktu tertentu:

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

Menerapkan pola Cache-Aside

Tambahkan pola Cache-Aside ke aplikasi web Anda untuk meningkatkan manajemen data dalam memori. Pola menetapkan aplikasi tanggung jawab menangani permintaan data dan memastikan konsistensi antara cache dan penyimpanan persisten, seperti database. Ini mempersingkat waktu respons, meningkatkan throughput, dan mengurangi kebutuhan akan lebih banyak penskalaan. Ini juga mengurangi beban pada datastore utama, yang meningkatkan keandalan dan pengoptimalan biaya. Untuk menerapkan pola Cache-Aside, ikuti rekomendasi berikut:

• Konfigurasikan aplikasi untuk menggunakan cache. Aplikasi produksi harus menggunakan cache Redis terdistribusi. Cache ini meningkatkan performa dengan mengurangi kueri database. Ini juga memungkinkan sesi nonsticky sehingga load balancer dapat mendistribusikan lalu lintas secara merata. Implementasi referensi menggunakan cache Redis terdistribusi. Metode AddAzureCacheForRedis mengonfigurasi aplikasi untuk menggunakan Azure Cache for Redis:

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

• Cache data dengan kebutuhan tinggi. Terapkan pola Cache-Aside pada data berkebutuh tinggi untuk meningkatkan efektivitasnya. Gunakan Azure Monitor untuk melacak CPU, memori, dan penyimpanan database. Metrik ini membantu Anda menentukan apakah Anda dapat menggunakan SKU database yang lebih kecil setelah menerapkan pola Cache-Aside. Misalnya, implementasi referensi menyimpan data dengan kebutuhan tinggi yang mendukung halaman Konser Mendatang. Metode GetUpcomingConcertsAsync menarik data ke cache Redis dari SQL Database dan mengisi cache dengan data konser terbaru:

  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>();
  }
  

• Jaga agar data cache tetap segar. Jadwalkan pembaruan cache reguler untuk disinkronkan dengan perubahan database terbaru. Gunakan volatilitas data dan pengguna perlu menentukan laju refresh yang optimal. Praktik ini memastikan bahwa aplikasi menggunakan pola Cache-Aside untuk memberikan akses cepat dan informasi saat ini. Misalnya, implementasi referensi menyimpan data hanya selama satu jam dan menggunakan metode CreateConcertAsync untuk menghapus kunci cache saat data berubah:

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

• Pastikan 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. Implementasi referensi menggunakan metode UpdateConcertAsync untuk menjaga data dalam cache tetap konsisten:

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

Panduan konfigurasi

Bagian berikut memberikan panduan tentang menerapkan pembaruan konfigurasi. Setiap bagian selaras dengan satu atau beberapa pilar Kerangka Kerja Well-Architected.

Konfigurasi	Keandalan (RE)	Keamanan (SE)	Pengoptimalan Biaya (CO)	Keunggulan Operasional (OE)	Efisiensi Performa (PE)	Mendukung prinsip WAF
Mengonfigurasi autentikasi dan otorisasi pengguna		✔		✔		SE:05 OE:10
Menerapkan identitas terkelola		✔		✔		SE:05 OE:10
Lingkungan rightsize			✔			CO:05 CO:06
Menerapkan penskalakan otomatis	✔		✔		✔	RE:06 CO:12 PE:05
Mengotomatiskan penyebaran sumber daya				✔		OE:05
Menerapkan pemantauan			✔	✔	✔	OE:07 PE:04

Mengonfigurasi autentikasi dan otorisasi pengguna

Saat Anda memigrasikan aplikasi web ke Azure, konfigurasikan mekanisme autentikasi dan otorisasi pengguna. Ikuti rekomendasi berikut:

• Gunakan platform identitas. Gunakan platform Identitas Microsoft untuk menyiapkan autentikasi aplikasi web. Platform ini mendukung aplikasi yang menggunakan satu direktori Microsoft Entra, beberapa direktori Microsoft Entra dari organisasi yang berbeda, dan identitas Microsoft atau akun sosial.

• Membuat pendaftaran aplikasi. ID Microsoft Entra memerlukan pendaftaran aplikasi di penyewa utama. Pendaftaran aplikasi membantu memastikan bahwa pengguna yang mendapatkan akses ke aplikasi web memiliki identitas di penyewa utama.

• Gunakan fitur platform. Minimalkan kebutuhan akan kode autentikasi kustom dengan menggunakan kemampuan platform untuk mengautentikasi pengguna dan mengakses data. Misalnya, App Service menyediakan dukungan autentikasi bawaan, sehingga Anda dapat memasukkan pengguna dan mengakses data saat menulis kode minimal atau tanpa kode di aplikasi web Anda.

• Menerapkan otorisasi dalam aplikasi. Gunakan RBAC untuk menetapkan hak istimewa paling sedikit untuk peran aplikasi. Tentukan peran tertentu untuk tindakan pengguna yang berbeda untuk menghindari tumpang tindih dan memastikan kejelasan. Petakan pengguna ke peran yang sesuai dan pastikan mereka hanya memiliki akses ke sumber daya dan tindakan yang diperlukan.

• Lebih suka akses sementara ke penyimpanan. Gunakan izin sementara untuk melindungi dari akses dan pelanggaran yang tidak sah. Misalnya, Anda dapat menggunakan tanda tangan akses bersama (SAS) untuk membatasi akses ke jangka waktu tertentu. Gunakan SAS delegasi pengguna untuk memaksimalkan keamanan saat Anda memberikan akses sementara. Ini adalah satu-satunya SAS yang menggunakan kredensial ID Microsoft Entra dan tidak memerlukan kunci akun penyimpanan permanen.

• Menerapkan otorisasi di Azure. Gunakan Azure RBAC untuk menetapkan hak istimewa paling sedikit ke identitas pengguna. Azure RBAC menentukan sumber daya Azure yang dapat diakses identitas, apa yang dapat mereka lakukan dengan sumber daya tersebut, dan area yang dapat mereka akses.

• Hindari izin permanen yang ditingkatkan. Gunakan Microsoft Entra Privileged Identity Management untuk memberikan akses just-in-time untuk operasi istimewa. Misalnya, pengembang sering memerlukan akses tingkat administrator untuk membuat/menghapus database, mengubah skema tabel, dan mengubah izin pengguna. Saat Anda menggunakan akses just-in-time, identitas pengguna menerima izin sementara untuk melakukan tugas istimewa.

Menggunakan identitas terkelola

Gunakan identitas terkelola untuk semua layanan Azure yang mendukungnya. Identitas terkelola memungkinkan sumber daya Azure (identitas beban kerja) untuk mengautentikasi dan berinteraksi dengan layanan Azure lainnya tanpa mengharuskan Anda mengelola kredensial. Untuk menyederhanakan migrasi, Anda dapat terus menggunakan solusi autentikasi lokal untuk sistem hibrid dan warisan, tetapi Anda harus mentransisikannya ke identitas terkelola sesegera mungkin. Untuk menerapkan identitas terkelola, ikuti rekomendasi berikut:

• Pilih jenis identitas terkelola yang tepat. Lebih suka identitas terkelola yang ditetapkan pengguna saat Anda memiliki dua atau beberapa sumber daya Azure yang memerlukan sekumpulan izin yang sama. Pendekatan ini lebih efisien daripada membuat identitas terkelola yang ditetapkan sistem untuk masing-masing sumber daya tersebut dan menetapkan izin yang sama untuk semuanya. Jika tidak, gunakan identitas terkelola yang ditetapkan sistem.

• Konfigurasikan hak istimewa paling sedikit. Gunakan Azure RBAC untuk hanya memberikan 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. Jika Azure RBAC tidak mencakup skenario tertentu, lengkapi Azure RBAC dengan kebijakan akses tingkat layanan Azure.

• Berikan keamanan untuk rahasia yang tersisa. Simpan rahasia yang tersisa di Azure Key Vault. Muat rahasia dari Key Vault saat pengaktifan aplikasi alih-alih selama setiap permintaan HTTP. Akses frekuensi tinggi dalam permintaan HTTP dapat melebihi batas transaksi Key Vault. Simpan konfigurasi aplikasi di Azure App Configuration.

Implementasi referensi menggunakan argumen Authentication dalam string koneksi database SQL sehingga App Service dapat tersambung ke database SQL dengan menggunakan identitas terkelola: Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default. Ini menggunakan DefaultAzureCredential untuk memungkinkan API web terhubung ke Key Vault dengan menggunakan identitas terkelola:

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

Lingkungan rightsize

Gunakan tingkat performa (SKU) layanan Azure yang memenuhi kebutuhan setiap lingkungan tanpa melebihinya. Untuk menyesuaikan lingkungan Anda, ikuti rekomendasi berikut:

• Memperkirakan biaya. Gunakan kalkulator harga Azure untuk memperkirakan biaya setiap lingkungan.

• Mengoptimalkan lingkungan produksi dengan biaya. Lingkungan produksi memerlukan SKU yang memenuhi perjanjian tingkat layanan (SLA), fitur, dan skala yang diperlukan untuk produksi. Terus memantau penggunaan sumber daya dan menyesuaikan SKU agar selaras dengan kebutuhan performa aktual.

• Lingkungan praproduksi pengoptimalan biaya.lingkungan Praproduksi harus menggunakan sumber daya berbiaya rendah dan memanfaatkan diskon seperti harga Azure Dev/Test. Di lingkungan ini, Anda harus menonaktifkan layanan yang tidak diperlukan. Pada saat yang sama, pastikan bahwa lingkungan praproduksi cukup mirip dengan lingkungan produksi untuk menghindari pengenalan risiko. Mempertahankan saldo ini memastikan bahwa pengujian tetap efektif tanpa menimbulkan biaya yang tidak perlu.

• Gunakan infrastruktur sebagai kode (IaC) untuk menentukan SKU. Terapkan IaC untuk memilih dan menyebarkan SKU yang benar secara dinamis berdasarkan lingkungan. Pendekatan ini meningkatkan konsistensi dan menyederhanakan manajemen.

Misalnya, implementasi referensi menggunakan parameter Bicep untuk menyebarkan tingkat yang lebih mahal (SKU) ke lingkungan produksi:

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

Menerapkan penskalakan otomatis

Penskalaan otomatis membantu memastikan bahwa aplikasi web tetap tangguh, responsif, dan mampu menangani beban kerja dinamis secara efisien. Untuk menerapkan penskalaan otomatis, ikuti rekomendasi berikut:

• Mengotomatiskan peluasan skala. Gunakan skala otomatis Azure untuk mengotomatiskan penskalakan horizontal di lingkungan produksi. Konfigurasikan aturan autoscaling untuk memperluas skala berdasarkan metrik performa utama sehingga aplikasi Anda dapat menangani berbagai beban.

• Menyempurnakan pemicu penskalakan. Gunakan pemanfaatan CPU sebagai pemicu penskalaan awal jika Anda tidak terbiasa dengan persyaratan penskalaan aplikasi Anda. Persempit pemicu penskalan Anda untuk menyertakan metrik lain seperti RAM, throughput jaringan, dan I/O disk. Tujuannya adalah untuk mencocokkan perilaku aplikasi web Anda untuk performa yang lebih baik.

• Berikan buffer peluasan skala. Atur ambang penskalan Anda untuk dipicu sebelum kapasitas maksimum tercapai. Misalnya, konfigurasikan penskalaan agar terjadi pada pemanfaatan CPU 85% daripada menunggu hingga mencapai 100%. Pendekatan proaktif ini membantu menjaga performa dan menghindari potensi hambatan.

Mengotomatiskan penyebaran sumber daya

Gunakan otomatisasi untuk menyebarkan dan memperbarui sumber daya dan kode Azure di semua lingkungan. Ikuti rekomendasi berikut:

• Gunakan infrastruktur sebagai kode. Sebarkan infrastruktur sebagai kode dengan menggunakan alur integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD). Azure menyediakan templat Bicep, ARM (JSON), dan Terraform bawaan untuk setiap sumber daya Azure.

• Gunakan alur integrasi berkelanjutan/penyebaran berkelanjutan (CI/CD). Gunakan alur CI/CD untuk menyebarkan kode dari kontrol sumber ke berbagai lingkungan Anda, seperti pengujian, penahapan, dan produksi. Gunakan Azure Pipelines jika Anda bekerja dengan Azure DevOps. Gunakan GitHub Actions untuk proyek GitHub.

• Mengintegrasikan pengujian unit. Prioritaskan eksekusi dan lolos semua pengujian unit dalam alur Anda sebelum penyebaran apa pun ke App Services. Masukkan kualitas kode dan alat cakupan seperti SonarQube untuk mencapai cakupan pengujian yang komprehensif.

• Mengadopsi kerangka kerja tiruan. Untuk pengujian yang melibatkan titik akhir eksternal, gunakan kerangka kerja tiruan. Kerangka kerja ini memungkinkan Anda membuat titik akhir yang disimulasikan. Mereka menghilangkan kebutuhan untuk mengonfigurasi titik akhir eksternal nyata dan memastikan kondisi pengujian yang seragam di seluruh lingkungan.

• Lakukan pemindaian keamanan. Gunakan pengujian keamanan aplikasi statis (SAST) untuk menemukan kelemahan keamanan dan kesalahan pengkodean dalam kode sumber Anda. Selain itu, lakukan analisis komposisi perangkat lunak (SCA) untuk memeriksa pustaka dan komponen pihak ketiga untuk risiko keamanan. Alat untuk analisis ini mudah diintegrasikan ke dalam GitHub dan Azure DevOps.

Menerapkan pemantauan

Terapkan pemantauan aplikasi dan platform untuk meningkatkan keunggulan operasional dan efisiensi performa aplikasi web Anda. Untuk menerapkan pemantauan, ikuti rekomendasi berikut:

• Kumpulkan telemetri aplikasi. Gunakan autoinstrumentasi di Azure Application Insights untuk mengumpulkan telemetriaplikasi , seperti throughput permintaan, durasi permintaan rata-rata, kesalahan, dan pemantauan dependensi. Anda tidak perlu membuat perubahan kode apa pun untuk menggunakan telemetri ini.

  Implementasi referensi menggunakan AddApplicationInsightsTelemetry dari paket NuGet Microsoft.ApplicationInsights.AspNetCore untuk mengaktifkan pengumpulan telemetri :

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

• Membuat metrik aplikasi kustom. Gunakan instrumentasi berbasis kode untuk telemetri aplikasi kustom. Tambahkan Application Insights SDK ke kode Anda dan gunakan API Application Insights.

  Implementasi referensi mengumpulkan telemetri pada peristiwa yang terkait dengan aktivitas kelistrikan. this.telemetryClient.TrackEvent menghitung tiket yang ditambahkan ke kelir. Ini menyediakan nama peristiwa (AddToCart) dan menentukan kamus yang memiliki concertId dan count:

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

• Pantau platform. Aktifkan diagnostik untuk semua layanan yang didukung. Kirim diagnostik ke tujuan yang sama dengan log aplikasi untuk korelasi. Layanan Azure membuat log platform secara otomatis tetapi hanya menyimpannya saat Anda mengaktifkan diagnostik. Aktifkan pengaturan diagnostik untuk setiap layanan yang mendukung diagnostik.

Menyebarkan implementasi referensi

Implementasi referensi memandu pengembang melalui migrasi yang disimulasikan dari aplikasi ASP.NET lokal ke Azure, menyoroti perubahan yang diperlukan selama fase adopsi awal. Contoh ini menggunakan aplikasi tiket konser untuk perusahaan fiksi Relecloud, yang menjual tiket melalui aplikasi web lokalnya. Relecloud menetapkan tujuan berikut untuk aplikasi web mereka:

• Menerapkan perubahan kode bernilai rendah dan bernilai tinggi.
• Raih SLO 99,9%.
• Mengadopsi praktik DevOps.
• Buat lingkungan yang dioptimalkan biaya.
• Tingkatkan keandalan dan keamanan.

Relecloud menentukan bahwa infrastruktur lokal mereka bukan solusi hemat biaya untuk memenuhi tujuan ini. Mereka memutuskan bahwa memigrasikan aplikasi web mereka ke Azure adalah cara paling hemat biaya untuk mencapai tujuan langsung dan masa depan mereka. Arsitektur berikut mewakili status akhir implementasi pola Reliable Web App Relecloud.

Gambar 4. Arsitektur implementasi referensi. Unduh file visio arsitektur ini.

Implementasi referensi