Zona ketersediaan adalah kumpulan pusat data yang terpisah secara fisik dalam suatu wilayah tertentu. Mereplikasi penyebaran Anda di beberapa zona, memastikan bahwa pemadaman listrik lokal yang terjadi dalam satu zona tidak berdampak negatif terhadap ketersediaan aplikasi Anda. Arsitektur ini menunjukkan cara Anda dapat meningkatkan ketahanan penyebaran ASE dengan cara melakukan penyebaran di berbagai zona ketersediaan. Zona-zona ini tidak memiliki kaitan karena alasan kedekatan. Mereka dapat memetakan ke lokasi fisik yang berbeda untuk langganan yang berbeda. Arsitektur ini mengasumsikan menggunakan penyebaran langganan tunggal.
Implementasi referensi untuk arsitektur ini tersedia di GitHub.
Arsitektur
Konten subnet ASE yang digunakan dalam implementasi referensi ini sama dengan yang ada di arsitektur penyebaran ASE standar yang dijelaskan di sini. Implementasi referensi ini mereplikasi penyebaran di dua subnet ASE. Setiap subnet memiliki aplikasi web, API, dan instans fungsinya sendiri yang dijalankan dalam paket App Service masing-masing. Cache Redis yang dibutuhkan oleh aplikasi juga direplikasi demi performa yang lebih baik. Perhatikan bahwa ruang lingkup dari arsitektur referensi ini terbatas pada satu wilayah.
Alur kerja
Bagian berikut menunjukkan sifat ketersediaan dari layanan yang digunakan dalam arsitektur ini:
App Services Environments dapat disebarkan ke beberapa zona ketersediaan, hanya dalam mode internal atau ILB. Implementasi referensi ini menerapkan dua subnet ASE, masing-masing di zona ketersediaan yang berbeda. Setidaknya, dua zona ketersediaan direkomendasikan untuk ketahanan end-to-end aplikasi Anda. Semua sumber daya runtime ILB ASE akan ditempatkan di zona yang ditentukan: alamat IP penyeimbang beban internal ASE, sumber daya komputasi serta penyimpanan file utama yang diperlukan oleh ASE untuk menjalankan semua aplikasi yang disebarkan pada ASE tersebut. Untuk panduan dan rekomendasi terperinci, baca App Service Environment Support for Availability Zones.
Azure Virtual Network atau Vnet mencakup semua zona ketersediaan yang terbatas dalam satu wilayah. Subnet dalam VNet juga menjangkau seluruh zona ketersediaan. Arsitektur referensi ini membuat subnet untuk setiap penyebaran ASE yang dibuat untuk zona ketersediaan. Untuk informasi lebih lanjut, baca persyaratan jaringan untuk Lingkungan App Service.
Application Gatewayv2 bersifat zona-redundan. Layaknya jaringan virtual, ini mencakup beberapa zona ketersediaan per wilayah. Ini berarti satu gateway aplikasi cukup untuk sistem dengan ketersediaan tinggi, seperti yang ditunjukkan dalam arsitektur referensi ini. Ini tidak didukung oleh SKU v1. Untuk detail lebih lanjut, lihat Penskalaan Otomatis dan Application Gateway v2 yang Zona-redundan.
Azure Firewall memiliki dukungan yang terintegrasi untuk ketersediaan tinggi. Ini dapat menjangkau banyak zona tanpa memerlukan konfigurasi lainnya. Hal ini memungkinkan penggunaan satu firewall tunggal untuk aplikasi yang disebarkan di lebih dari satu zona, seperti yang dilakukan dalam arsitektur referensi ini. Meskipun tidak digunakan dalam arsitektur ini, jika perlu Anda juga dapat mengkonfigurasikan zona ketersediaan tertentu saat menyebarkan firewall. Lihat Azure Firewall dan Zona Ketersediaan untuk informasi lebih lanjut.
Azure Active Directory adalah layanan global dengan ketersediaan & redundansi yang tinggi, yang mencakup zona ketersediaan serta wilayah. Baca Memajukan ketersediaan Azure Active Directory untuk wawasan lebih lanjut.
Azure Pipelines mendukung pemrosesan paralel dari aktivitas CI/CD. Gunakan ini dalam fase penyebaran, untuk menyebarkan aplikasi yang telah dibangun ke beberapa subnet ASE secara bersamaan, melalui beberapa VM jumpbox atau subnet Bastion. Arsitektur ini menggunakan dua mesin virtual jumpbox untuk membantu melakukan penyebaran secara bersamaan. Perhatikan jumlah pekerjaan paralel yang berkaitan dengan tingkat harga. Tingkat gratis dasar CI/CD yang dihosting Microsoft memungkinkan hingga 10 tugas untuk diparalelkan, masing-masing berjalan hingga 6 jam.
Azure Cache for Redis bukanlah layanan yang bersifat zona-sadar. Arsitektur ini membuat dua subnet untuk menahan Redis Cache, masing-masing disematkan ke zona ketersediaan subnet ASE. Hal ini disarankan karena semakin dekat jarak cache ke aplikasi, kinerja aplikasi akan semakin baik. Ingatlah bahwa ini adalah fitur pratinjau, dan hanya tersedia untuk tingkat Premium.
Pertimbangan
Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.
Ketersediaan
App Service Environments
Lingkungan App Service dengan ILB dapat disebarkan ke zona ketersediaan tertentu. Zona ketersediaan adalah pusat data mandiri yang terpisah secara geografis yang berada dalam wilayah yang sama. Jika satu pusat data tidak berfungsi, dan jika didukung oleh arsitektur Anda, maka aplikasi yang disebarkan ke pusat data lain dapat menjamin ketersediaan.
Manfaatkan fitur ini dengan:
- menyebarkan setidaknya dua lingkungan tersebut ke dua zona yang berbeda, dengan aplikasi yang diduplikasi di setiap ASE, dan
- menyeimbangkan upstram lalu lintas ke ASE, menggunakan App Gateway zona-redundan, seperti yang ditunjukkan dalam arsitektur referensi ini.
Beberapa poin lainnya yang perlu dipertimbangkan:
- ASE ILB yang diterapkan ke suatu zona memastikan waktu aktif untuk aplikasi dan sumber daya yang sudah diterapkan yang digunakan oleh mereka. Namun, penskalaan paket layanan aplikasi, pembuatan aplikasi, dan penerapan aplikasi mungkin masih dipengaruhi oleh pemadaman di zona lain.
- Templat ARM harus digunakan untuk penerapan awal ILB ASE ke zona ketersediaan. Setelah itu, ia dapat diakses melalui portal atau baris perintah. Properti zonaharus diatur ke 1, 2, atau 3 yang menunjukkan zona logis.
- Jaringan virtual secara default adalah zone-redundant, maka semua subnet ASE yang zona-deoloyed dapat berada dalam jaringan virtual yang sama.
- ASE yang menghadap eksternal tidak dapat disematkan ke zona ketersediaan.
Baca Dukungan Lingkungan App Service untuk Zona Ketersediaan untuk mengetahui rincian lebih.
Resiliency
Aplikasi pada kedua subnet ASE membentuk kolam backend untuk Application Gateway. Ketika suatu permintaan ke aplikasi dibuat dari internet publik, gateway dapat memilih salah satu dari dua contoh aplikasi. Application Gateway secara default memantau kesehatan sumber daya kolam backend, seperti yang dijelaskan dalam ulasan pemantauan kesehatan Application Gateway. Dalam pengaturan referensi, pemeriksaan default hanya dapat memantau antarmuka web. Karena antarmuka web menggunakan komponen lain, mungkin terlihat baik-baik saja tetapi masih gagal jika dependensi gagal karena kegagalan yang terjadi di zona pusat data. Untuk menghindari kegagalan seperti itu, gunakan pengujian khusus untuk mengontrol apa arti sebenarnya dari kesehatan aplikasi. Arsitektur referensi ini mengimplementasikan Health Checkspada antarmuka web utama, votingApp. Pemeriksaan kesehatan ini memeriksa apakah API serta Redis dalam kondisi baik. Lihat cuplikan yang mengimplementasikan penyelidikan 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"));
Cuplikan berikut menunjukkan bagaimana skrip deploy_ha.sh mengonfigurasi kumpulan backend dan pemeriksaan kesehatan untuk App Gateway:
# Generates parameters file for appgw arm script
cat <<EOF > appgwApps.parameters.json
[
{
"name": "votapp",
"hostName": "${APPGW_APP1_URL}",
"backendAddresses": [
{
"fqdn": "${INTERNAL_APP1_URL1}"
},
{
"fqdn": "${INTERNAL_APP1_URL2}"
}
],
"certificate": {
"data": "${CERT_DATA_1}",
"password": "${PFX_PASSWORD}"
},
"probePath": "/health"
},
...
Jika salah satu komponen gagal dalam pemeriksaan, yaitu antarmuka web, API, atau cache, Application Gateway akan menjalankan permintaan ke aplikasi lain dari kumpulan backend. Ini memastikan bahwa permintaan selalu dijalankan ke aplikasi dalam subnet ASE yang tersedia.
Pengujian juga diterapkan dalam implementasi referensi standar. Di sana, gateway hanya mengembalikan kesalahan jika pemeriksaan terhadap sistem gagal. Namun, dalam implementasi tersedia, ini meningkatkan ketahanan aplikasi dan kualitas pengalaman pengguna.
Pengoptimalan biaya
Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.
Pertimbangan biaya untuk arsitektur kebutuhan tingkat tinggi sebagian besar mirip dengan penerapan standar.
Perbedaan berikut dapat mempengaruhi biaya:
- Beberapa penerapan App Service.
- Beberapa contoh penerapan Azure Cache for Redis tingkat premium . Arsitektur referensi ini menggunakan tingkat Premium, karena:
- Hanya Redis Cache Premium yang dapat digunakan dalam jaringan virtual, dan
- Penyematan zona Redis Cache, fitur pratinjau publik, hanya tersedia diPremium tier.
Pertukaran untuk kebutuhan tingkat tinggi, sistem yang tangguh, dan aman akan meningkatkan biaya. Evaluasi kebutuhan perusahaan sehubungan dengan penetapan harga, menggunakan pricing calculator.
Pertimbangan penyebaran
Implementasi referensi ini memperluas alur CI/CD produksi yang digunakan dalam penerapan standar, dengan menggunakan satu mesin virtual jumpbox per zona ketersediaan. Ini melayani dua tujuan:
- Sematkan mesin virtual ke zona ketersediaan yang sama yang digunakan oleh sumber daya ASE, untuk memastikan waktu aktif dalam penerapan jika terjadi kegagalan terbatas pada satu atau dua zona.
- Ini juga membantu mensejajarkan penerapan, dengan menggunakan mesin virtual sebagai kumpulan Azure Pipelines agents.
File azure-pipelines.yml dalam implementasi referensi ini menggambarkan penyebaran paralel, dengan membuat tahap penyebaran terpisah untuk setiap zona ASE.
Menyebarkan skenario ini
Untuk menerapkan implementasi referensi untuk arsitektur ini, lihat GitHub readme, dan ikuti skrip untuk penyebaran kebutuhan yang tinggi.
Langkah berikutnya
Anda dapat memperluas pembelajaran dalam arsitektur referensi ini, dan 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 disebabkan gempa bumi atau bencana alam lainnya. Untuk mempelajari lebih lanjut tentang penskalaan horizontal, bacaGeo Distributed Scale with App Service Environments. Untuk routing solution kebutuhan global dan tersedia, pertimbangkan untuk menggunakanAzure Front Door.