Garis dasar kritis misi dengan App Service
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. Pendekatan ini membantu Anda meminimalkan perubahan kode yang diperlukan dan menargetkan tujuan tingkat layanan (SLO) 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 memperkenalkan dan menerapkan praktik desain misi penting.
Nota
Panduan dalam artikel ini didasarkan pada metodologi desain dan praktik terbaik dalam seri beban kerja misi pentingWell-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.
Arsitektur
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 dependensi satu sama lain dan hanya berkomunikasi dengan layanan bersama di luar unit skala individu. Anda dapat menggunakan unit skala ini dalam penyebaran biru-hijau dengan meluncurkan unit skala baru, memvalidasi bahwa unit tersebut berfungsi dengan benar, dan secara bertahap memindahkan lalu lintas produksi ke unit tersebut.
Dalam skenario ini, kami menganggap unit skala sebagai sementara, yang mengoptimalkan proses peluncuran dan memberikan skalabilitas di dalam dan di seluruh wilayah. Saat Anda mengambil pendekatan ini, Anda harus menyimpan data hanya di database karena database direplikasi ke wilayah sekunder. Jika Anda perlu menyimpan data di unit skala, pertimbangkan untuk menggunakan Azure Cache for Redis untuk penyimpanan di unit skala. Jika unit skala harus ditinggalkan, mengisi ulang cache dapat meningkatkan latensi, tetapi tidak menyebabkan pemadaman.
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 untuk setiap 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.
Pertimbangan untuk ketersediaan tinggi
Terlepas dari platform aplikasi yang Anda pilih, kami sarankan Anda memprioritaskan penggunaan zona ketersediaan untuk beban kerja produksi.
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 tidak secara asli mendukung penyebaran aktif-aktif yang memiliki operasi tulis di lebih dari satu instans. Dalam konfigurasi ini, platform data terbatas pada strategi pasif aktif. Strategi aktif-aktif (parsial) pada tingkat aplikasi dimungkinkan jika ada replika baca-saja di semua wilayah dan Anda hanya menulis ke satu wilayah.
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.
Untuk menentukan model kesehatan:
- Menentukan alur pengguna dan sistem
- Tentukan dan pahami dependensi antara layanan
- Memahami efek bahwa pemadaman atau penurunan performa pada salah satu layanan dapat terjadi pada beban kerja keseluruhan
- Pantau dan visualisasikan 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.
Kriteria untuk menentukan kesehatan unit skala didefinisikan dalam model kesehatan. Model ini kemudian terhubung ke titik akhir kesehatan unit skala, yang memungkinkan penyeimbang beban global untuk mengkueri status kesehatan unit skala dan menggunakan informasi tersebut untuk keputusan perutean.
Untuk informasi selengkapnya, lihat Pemodelan kesehatan dan pengamatan beban kerja misi penting di Azure.
Keamanan dan jaringan
Beban kerja misi-kritis memiliki persyaratan jaringan dan keamanan yang ketat. Terapkan ketekunan terutama untuk beban kerja yang dimigrasikan dari lingkungan lokal karena tidak semua praktik keamanan lokal yang ditetapkan diterjemahkan ke lingkungan cloud. Sebaiknya Anda mengevaluasi kembali persyaratan keamanan selama migrasi aplikasi.
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, layanan Azure PaaS dapat menggunakan Azure Private Link untuk mengimplementasikan jaringan sebagai perimeter keamanan. Private Link membantu memastikan bahwa layanan hanya dapat diakses dari dalam jaringan virtual. Semua layanan kemudian hanya dapat diakses melalui titik akhir privat. Diagram berikut menunjukkan bagaimana satu-satunya titik akhir publik yang menghadap internet adalah Azure Front Door.
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.
- Jump box 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. Kemudian, filter lalu lintas dengan menggunakan 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
- Analisis siklus hidup komponen individual dan yang dikelompokkan
- 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 selanjutnya
- 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