Penyebaran perusahaan ketersediaan tinggi menggunakan App Service Environment

Zona ketersediaan adalah kumpulan pusat data yang dipisahkan secara fisik di wilayah tertentu. Menyebarkan sumber daya di seluruh zona memastikan bahwa pemadaman yang terbatas pada zona tidak memengaruhi ketersediaan aplikasi Anda. Arsitektur ini menunjukkan bagaimana Anda dapat meningkatkan ketahanan penyebaran Lingkungan App Service dengan menyebarkannya dalam arsitektur zona-redudan. Zona ini tidak terkait dengan kedekatan. Mereka dapat memetakan ke lokasi fisik yang berbeda untuk langganan yang berbeda. Arsitektur mengasumsikan penyebaran langganan tunggal.

Saat Anda mengonfigurasi App Service Environment menjadi zona redundan, platform secara otomatis menyebarkan instans paket Azure App Service di tiga zona di wilayah yang dipilih. Oleh karena itu, jumlah instans paket App Service minimum selalu tiga.

Layanan Azure yang mendukung zona ketersediaan dapat berupa zonal, zona redundan, atau keduanya. Layanan zona dapat disebarkan ke zona tertentu. Layanan redundansi zona dapat disebarkan secara otomatis di seluruh zona. Untuk panduan dan rekomendasi terperinci, lihat Dukungan zona ketersediaan. Versi App Service Environment (v2) sebelumnya hanya mendukung penyebaran zonal, tetapi versi saat ini (v3) mendukung penyebaran zona-redundan.

Implementasi referensi untuk arsitektur ini tersedia di GitHub.

Arsitektur

Unduh file Visio arsitektur ini.

Sumber daya dalam subnet App Service Environment dalam implementasi referensi ini sama dengan sumber daya dalam arsitektur penyebaran App Service Environment standar. Implementasi referensi ini menggunakan kemampuan zona redundan dari App Service Environment v3 dan Azure Cache for Redis untuk memberikan ketersediaan yang lebih tinggi. Perhatikan bahwa ruang lingkup dari arsitektur referensi ini terbatas pada satu wilayah.

Alur kerja

Bagian ini menjelaskan sifat ketersediaan untuk layanan yang digunakan dalam arsitektur ini:

• App Service Environment v3 dapat dikonfigurasi untuk redundansi zona. Anda hanya dapat mengonfigurasi redundansi zona selama pembuatan Lingkungan App Service dan hanya di wilayah yang mendukung semua dependensi App Service Environment v3. Setiap paket App Service di Lingkungan App Service zona-redundan harus memiliki minimal tiga instans sehingga dapat disebarkan di tiga zona. Biaya minimum adalah untuk sembilan instans. Untuk informasi selengkapnya, lihat panduan harga ini. Untuk panduan dan rekomendasi terperinci, lihat Dukungan Lingkungan App Service untuk Zona Ketersediaan.

• Azure Virtual Network mencakup semua zona ketersediaan yang berada dalam satu wilayah. Subnet di jaringan virtual juga lintas zona ketersediaan. Untuk informasi selengkapnya, lihat persyaratan jaringan untuk Lingkungan App Service.

• Application Gateway v2 bersifat zona-redundan. Layaknya jaringan virtual, ini mencakup beberapa zona ketersediaan per wilayah. Oleh karena itu, gateway aplikasi tunggal cukup untuk sistem yang sangat tersedia, seperti yang ditunjukkan dalam arsitektur referensi. Arsitektur referensi menggunakan WAF SKU Application Gateway, yang memberikan peningkatan perlindungan terhadap ancaman dan kerentanan umum, berdasarkan implementasi Core Rule Set (CRS) dari Open Web Application Security Project (OWASP). Untuk informasi selengkapnya, lihat Menskalakan Application Gateway v2 dan WAF v2.

• Azure Firewall memiliki dukungan yang terintegrasi untuk ketersediaan tinggi. Ini dapat melintasi beberapa zona tanpa konfigurasi tambahan.

  Jika perlu, Anda juga dapat mengonfigurasi zona ketersediaan tertentu saat menyebarkan firewall. Lihat Azure Firewall dan Zona Ketersediaan untuk informasi selengkapnya. (Konfigurasi ini tidak digunakan dalam arsitektur referensi.)

• MICROSOFT Entra ID adalah layanan global yang sangat tersedia dan sangat redundan, mencakup zona ketersediaan dan wilayah. Untuk informasi selengkapnya, lihat Memajukan ketersediaan Microsoft Entra.

• GitHub Actions menyediakan kemampuan integrasi berkelanjutan dan penyebaran berkelanjutan (CI/CD) dalam arsitektur ini. Karena Lingkungan App Service berada di jaringan virtual, komputer virtual digunakan sebagai jumpbox di jaringan virtual untuk menyebarkan aplikasi dalam paket App Service. Tindakan ini membangun aplikasi di luar jaringan virtual. Untuk keamanan yang ditingkatkan dan konektivitas RDP/SSH yang mulus, pertimbangkan untuk menggunakan Azure Bastion untuk jumpbox.

• Azure Cache for Redis adalah layanan zona-redundan. Cache zona-redundan berjalan pada VM yang disebarkan di beberapa zona ketersediaan. Layanan ini memberikan ketahanan dan ketersediaan yang lebih tinggi.

Pertimbangan

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

Ketersediaan

Lingkungan App Service

Anda dapat menyebarkan Lingkungan App Service di seluruh zona ketersediaan untuk memberikan ketahanan dan keandalan untuk beban kerja penting bisnis Anda. Konfigurasi ini juga dikenal sebagai redundansi zona.

Saat Anda menerapkan redundansi zona, platform secara otomatis menyebarkan instans paket App Service di tiga zona di wilayah yang dipilih. Oleh karena itu, jumlah instans paket App Service minimum selalu tiga. Jika Anda menentukan kapasitas yang lebih besar dari tiga, dan jumlah instans dapat dibagi tiga, instans disebarkan secara merata. Jika tidak, setiap instans yang tersisa ditambahkan ke zona yang tersisa atau disebarkan di dua zona yang tersisa.

• Anda mengonfigurasi zona ketersediaan saat membuat Lingkungan App Service.
• Semua paket App Service yang dibuat di Lingkungan App Service tersebut memerlukan minimal tiga instans. Mereka akan secara otomatis menjadi zona redundan.
• Anda hanya dapat menentukan zona ketersediaan saat membuat Lingkungan App Service baru. Anda tidak dapat mengonversi Lingkungan App Service yang sudah ada sebelumnya untuk menggunakan zona ketersediaan.
• Zona ketersediaan hanya didukung di subset wilayah.

Untuk informasi selengkapnya, lihat Memigrasikan lingkungan App Service ke dukungan zona ketersediaan.

Ketahanan

Aplikasi yang berjalan di Lingkungan App Service membentuk kumpulan backend untuk Application Gateway. Ketika permintaan ke aplikasi berasal dari internet publik, gateway meneruskan permintaan ke aplikasi yang berjalan di Lingkungan App Service. Arsitektur referensi ini menerapkan pemeriksaan kesehatan dalam frontend web utama, votingApp. Pemeriksaan kesehatan ini memeriksa apakah API web dan cache Redis sehat. Anda dapat melihat kode yang mengimplementasikan pemeriksaan ini di Startup.cs:

            var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionStrings:VotingDataAPIBaseUri"))
            {
                Path = "/health"
            };

            services.AddHealthChecks()
                .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
                .AddRedis(Configuration.GetValue<string>("ConnectionStrings:RedisConnectionString"));

Kode berikut menunjukkan bagaimana skrip commands_ha.azcli mengonfigurasi kumpulan backend dan pemeriksaan kesehatan untuk gateway aplikasi:

# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
{
    "name": "votapp",
    "routingPriority": 100,
    "hostName": "${APPGW_APP1_URL}",
    "backendAddresses": [
      {
        "fqdn": "${INTERNAL_APP1_URL}"
      }
    ],
    "certificate": {
      "data": "${CERT_DATA_1}",
      "password": "${PFX_PASSWORD}"
    },
    "probePath": "/health"
  }
]

Jika salah satu komponen (frontend web, API, atau cache) gagal dalam pemeriksaan kesehatan, Application Gateway merutekan permintaan ke aplikasi lain di kumpulan backend. Konfigurasi ini memastikan bahwa permintaan selalu dirutekan ke aplikasi dalam subnet App Service Environment yang sepenuhnya tersedia.

Pengujian juga diterapkan dalam implementasi referensi standar. Di sana, gateway hanya mengembalikan kesalahan jika pemeriksaan kesehatan gagal. Namun, implementasi yang sangat tersedia meningkatkan ketahanan aplikasi dan kualitas pengalaman pengguna.

Pengoptimalan biaya

Pengoptimalan biaya adalah tentang mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.

Pertimbangan biaya untuk arsitektur ketersediaan tinggi mirip dengan penyebaran standar.

Perbedaan berikut dapat mempengaruhi biaya:

• Anda dikenakan biaya untuk setidaknya sembilan instans paket App Service di Lingkungan App Service zona-redundan. Untuk informasi selengkapnya, lihat Harga App Service Environment.
• Azure Cache for Redis juga merupakan layanan zona-redundan. Cache zona redundan berjalan pada VM yang disebarkan di beberapa zona ketersediaan untuk memberikan ketahanan dan ketersediaan yang lebih tinggi.

Tradeoff untuk sistem yang sangat tersedia, tangguh, dan sangat aman adalah peningkatan biaya. Gunakan kalkulator harga untuk mengevaluasi kebutuhan Anda sehubungan dengan harga.

Pertimbangan penyebaran

Implementasi referensi ini menggunakan alur CI/CD tingkat produksi yang sama dengan penyebaran standar, dengan hanya satu VM jumpbox. Namun, Anda mungkin memutuskan untuk menggunakan satu jumpbox untuk masing-masing dari tiga zona. Arsitektur ini hanya menggunakan satu jumpbox karena jumpbox tidak memengaruhi ketersediaan aplikasi. Jumpbox hanya digunakan untuk penyebaran dan pengujian.

Menyebarkan skenario ini

Untuk informasi tentang menyebarkan implementasi referensi untuk arsitektur ini, lihat readme GitHub. Gunakan skrip untuk penyebaran ketersediaan tinggi.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

• Deep Bhattacharya | Arsitek Solusi Cloud
• Suhas Rao | Arsitek Solusi Cloud

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Anda dapat memodifikasi arsitektur ini dengan menskalakan aplikasi Anda secara horizontal, dalam wilayah yang sama atau di beberapa wilayah, berdasarkan kapasitas beban puncak yang diharapkan. Mereplikasi aplikasi Anda di beberapa wilayah dapat membantu mengurangi risiko kegagalan pusat data geografis yang lebih luas, seperti yang disebabkan oleh gempa bumi atau bencana alam lainnya. Untuk mempelajari selengkapnya tentang penskalakan horizontal, lihat Skala Terdistribusi Geografis dengan Lingkungan App Service. Untuk solusi perutean global dan sangat tersedia, pertimbangkan untuk menggunakan Azure Front Door.