Artikel ini menjelaskan cara menyebarkan aplikasi web penting misi dengan menggunakan Azure App Service. Arsitektur ini menggunakan pola aplikasi web yang andal sebagai titik awal. Gunakan arsitektur ini jika Anda memiliki beban kerja warisan dan ingin mengadopsi layanan platform-as-a-service (PaaS).
Pola aplikasi web yang andal untuk .NET menyediakan panduan untuk memperbarui atau mereplatformasi aplikasi web yang Anda pindahkan ke cloud, meminimalkan perubahan kode yang diperlukan, dan menargetkan tujuan tingkat layanan (SLO) sebesar 99,9%. Beban kerja misi penting memiliki persyaratan keandalan dan ketersediaan yang tinggi. Untuk mencapai SLO 99,95%, 99,99%, atau lebih tinggi, Anda perlu menerapkan pola desain misi penting tambahan dan kekakuan operasional. Artikel ini menjelaskan area teknis utama dan cara menerapkan dan memperkenalkan praktik desain misi penting.
Catatan
Panduan dalam artikel ini didasarkan pada metodologi desain dan praktik terbaik dalam seri beban kerja misi penting Well-Architected Framework.
Bagian berikut ini menjelaskan cara:
- Tinjau beban kerja yang ada untuk memahami komponen, alur pengguna dan sistemnya, serta persyaratan ketersediaan dan skalabilitasnya.
- Kembangkan dan terapkan arsitektur unit skala untuk mengoptimalkan skalabilitas end-to-end melalui kompartemenalisasi dan untuk menstandarkan proses penambahan dan penghapusan kapasitas.
- Terapkan unit skala stateless dan sementara atau stempel penyebaran untuk mengaktifkan skalabilitas dan penyebaran zero-downtime.
- Tentukan apakah Anda dapat membagi beban kerja menjadi komponen untuk mempersiapkan skalabilitas. Komponen individual diperlukan untuk skalabilitas dan alur pemisahan.
- Bersiaplah untuk distribusi global dengan menyebarkan beban kerja di lebih dari satu wilayah Azure untuk meningkatkan kedekatan dengan pelanggan dan mempersiapkan potensi pemadaman regional.
- Memisahkan komponen dan mengimplementasikan arsitektur berbasis peristiwa.
Sistem
Diagram berikut menerapkan pertimbangan sebelumnya ke pola aplikasi web yang andal.
Unduh file Visio arsitektur ini.
Kotak merah mewakili unit skala dengan layanan yang menskalakan bersama-sama. Untuk menskalakannya secara efektif bersama-sama, optimalkan ukuran setiap layanan, SKU, dan alamat IP yang tersedia. Misalnya, jumlah maksimum permintaan yang dilayani Azure App Configuration berkorelasi dengan jumlah permintaan per detik yang disediakan unit skala. Saat menambahkan lebih banyak kapasitas di suatu wilayah, Anda juga harus menambahkan lebih banyak unit skala individual.
Unit skala individu ini tidak memiliki inter-dependensi dan hanya berkomunikasi dengan layanan bersama di luar unit skala individu. Anda dapat menguji unit skala independen di muka. Untuk menghindari memengaruhi area penyebaran lain, luncurkan unit skala independen dan perkenalkan opsi untuk mengganti layanan dalam rilis baru.
Untuk beban kerja misi penting, unit skala independen bersifat sementara, yang mengoptimalkan proses peluncuran dan memberikan skalabilitas di dalam dan di seluruh wilayah. Hindari menyimpan status dalam unit skala independen. Pertimbangkan untuk menggunakan Azure Cache for Redis untuk penyimpanan di unit skala, dan hanya menyimpan status atau data penting yang juga disimpan dalam database. Jika ada pemadaman unit skala atau Anda beralih ke unit skala lain, mungkin ada perlambatan atau proses masuk baru yang diperlukan, tetapi Azure Cache for Redis masih berjalan.
Application Insights dikecualikan dari unit skala. Kecualikan layanan yang menyimpan atau memantau data. Pisahkan mereka ke dalam grup sumber daya mereka sendiri dengan siklus hidup mereka sendiri.
Saat Anda mengganti unit skala atau menyebarkan yang baru, simpan data historis dan gunakan satu instans per wilayah.
Untuk informasi selengkapnya, lihat Desain aplikasi beban kerja misi penting di Azure.
Komponen
Arsitektur ini menggunakan komponen berikut.
- App Service adalah platform hosting aplikasi.
- Permintaan cache Azure Cache for Redis .
- App Configuration menyimpan pengaturan konfigurasi.
- Azure SQL adalah database back-end.
- Application Insights mendapatkan telemetri dari aplikasi.
Alternatif
Dalam pola aplikasi web yang andal, Anda dapat:
- Gunakan Azure Kubernetes Service (AKS) alih-alih App Service. Opsi ini berfungsi dengan baik untuk beban kerja kompleks yang memiliki sejumlah besar layanan mikro. AKS memberikan kontrol lebih besar atas infrastruktur yang mendasar dan memungkinkan penyiapan multitier yang kompleks.
- Kontainerisasi beban kerja. App Service mendukung kontainerisasi, tetapi dalam contoh ini beban kerja tidak dalam kontainer. Gunakan kontainer untuk meningkatkan keandalan dan portabilitas.
Untuk informasi selengkapnya, lihat Pertimbangan platform aplikasi untuk beban kerja misi penting di Azure.
Pilih platform aplikasi
Tingkat ketersediaan tergantung pada pilihan dan konfigurasi platform aplikasi Anda. Pertimbangkan panduan misi penting berikut:
- Gunakan zona ketersediaan jika memungkinkan.
- Pilih layanan platform yang tepat untuk beban kerja Anda.
- Kontainerisasi beban kerja.
Set ketersediaan menyebarkan penyebaran di beberapa domain kesalahan dan pembaruan dalam pusat data. Zona ketersediaan menyebarkan penyebaran di setiap pusat data dalam wilayah Azure. Zona ketersediaan sering diprioritaskan, tetapi strategi mana yang Anda gunakan tergantung pada beban kerja Anda. Misalnya, beban kerja yang sensitif terhadap latensi atau cerewet mungkin mendapat manfaat dari memprioritaskan set ketersediaan. Jika Anda menyebarkan beban kerja di seluruh zona ketersediaan, beban kerja tersebut dapat meningkatkan latensi dan biaya untuk lalu lintas zona. Saat Anda menggunakan zona ketersediaan, pastikan bahwa semua layanan dalam unit skala mendukungnya. Semua layanan dalam pola aplikasi web yang andal mendukung zona ketersediaan.
Pilih platform data
Platform database yang Anda pilih memengaruhi arsitektur beban kerja secara keseluruhan, terutama dukungan konfigurasi aktif-aktif atau pasif platform. Pola aplikasi web yang andal menggunakan Azure SQL, yang secara asli tidak mendukung penyebaran aktif-aktif dengan operasi tulis di lebih dari satu instans. Jadi tingkat database terbatas pada strategi pasif aktif. Strategi aktif-aktif pada tingkat aplikasi dimungkinkan jika ada replika baca-saja dan Anda hanya menulis ke satu wilayah.
Unduh file Visio arsitektur ini.
Beberapa database umum dalam arsitektur kompleks, seperti arsitektur layanan mikro yang memiliki database untuk setiap layanan. Beberapa database memungkinkan adopsi database tulis multi-primer seperti Azure Cosmos DB, yang meningkatkan ketersediaan tinggi dan latensi rendah. Latensi lintas wilayah dapat membuat batasan. Sangat penting untuk mempertimbangkan persyaratan dan faktor nonfungsi seperti konsistensi, pengoperasian, biaya, dan kompleksitas. Memungkinkan layanan individual menggunakan penyimpanan data terpisah dan teknologi data khusus untuk memenuhi persyaratan uniknya. Untuk informasi selengkapnya, lihat Pertimbangan platform data untuk beban kerja misi penting di Azure.
Menentukan model kesehatan
Dalam beban kerja multitier kompleks yang tersebar di beberapa pusat data dan wilayah geografis, Anda harus menentukan model kesehatan. Tentukan alur pengguna dan sistem, tentukan dan pahami dependensi antara layanan, pahami efek bahwa pemadaman atau penurunan performa pada salah satu layanan dapat memiliki beban kerja secara keseluruhan, dan memantau dan memvisualisasikan pengalaman pelanggan untuk mengaktifkan pemantauan yang tepat dan meningkatkan tindakan manual dan otomatis.
Diagram sebelumnya menunjukkan bagaimana pemadaman atau degradasi satu komponen, seperti App Configuration, dapat menyebabkan potensi penurunan performa bagi pelanggan.
Ketika Anda memisahkan komponen ke dalam unit skala, hal ini memungkinkan Anda untuk berhenti mengirim lalu lintas ke bagian aplikasi yang terpengaruh, seperti unit skala yang terpengaruh atau wilayah lengkap.
Untuk informasi selengkapnya, lihat Pemodelan kesehatan dan pengamatan beban kerja misi penting di Azure.
Keamanan dan jaringan
Ada persyaratan jaringan dan keamanan yang ketat untuk beban kerja yang bermigrasi dari penyebaran perusahaan lokal. Tidak semua proses lokal yang dibuat diterjemahkan ke lingkungan cloud. Evaluasi persyaratan ini jika berlaku di lingkungan cloud.
Identitas sering kali menjadi perimeter keamanan utama untuk pola cloud-native. Pelanggan perusahaan mungkin memerlukan langkah-langkah keamanan yang lebih substansial. Untuk mengatasi persyaratan keamanan jaringan mereka, sebagian besar layanan Azure PaaS dapat menggunakan Azure Private Link untuk mengimplementasikan jaringan sebagai perimeter keamanan. Private Link dapat memastikan bahwa layanan hanya dapat diakses dari dalam jaringan virtual. Semua layanan hanya dapat diakses melalui titik akhir privat. Diagram berikut menunjukkan bagaimana satu-satunya titik akhir publik yang menghadap internet adalah Azure Front Door.
Unduh file Visio arsitektur ini.
Agar pola aplikasi web yang andal menyiapkan jaringan sebagai perimeter keamanan, harus menggunakan:
- Private Link untuk semua layanan yang mendukungnya.
- Azure Front Door premium sebagai satu-satunya titik akhir publik yang menghadap internet.
- Jumpbox untuk mengakses layanan melalui Azure Bastion.
- Agen build yang dihost sendiri yang dapat mengakses layanan.
Persyaratan jaringan umum lainnya untuk aplikasi penting misi adalah membatasi lalu lintas keluar untuk mencegah penyelundupan data. Batasi lalu lintas keluar dengan merutekan firewall Azure melalui perangkat firewall yang tepat dan memfilternya dengan perangkat. Arsitektur garis besar misi-kritis Azure dengan kontrol jaringan menggunakan firewall dan Private Link.
Penyebaran dan pengujian
Waktu henti yang disebabkan oleh rilis yang salah atau kesalahan manusia dapat menjadi masalah untuk beban kerja yang harus selalu tersedia. Berikut adalah beberapa area utama yang perlu dipertimbangkan:
- Penyebaran waktu henti nol
- Penyebaran biru/hijau Ephemeral
- Menganalisis siklus hidup komponen individu dan mengelompokkannya bersama-sama
- Validasi berkelanjutan
Penyebaran zero-downtime adalah kunci untuk beban kerja misi-kritis. Beban kerja yang harus selalu aktif dan berjalan tidak dapat memiliki jendela pemeliharaan untuk meluncurkan versi yang lebih baru. Untuk mengatasi batasan ini, arsitektur misi-kritis Azure mengikuti pola penyebaran waktu henti nol. Perubahan diluncurkan sebagai unit skala baru atau stempel yang diuji ujung ke ujung sebelum lalu lintas dirutekan secara bertahap ke unit skala tersebut. Setelah semua lalu lintas dirutekan ke stempel baru, stempel lama dinonaktifkan dan dihapus.
Untuk informasi selengkapnya, lihat Penyebaran dan pengujian untuk beban kerja misi penting di Azure.
Langkah berikutnya
- jalur Pembelajaran: Membangun beban kerja misi penting di Azure
- Proyek tantangan: Merancang aplikasi web misi penting
- Pelajari modul: Merancang model kesehatan untuk beban kerja misi penting Anda