Pertimbangan platform aplikasi untuk beban kerja misi penting di Azure

Azure menyediakan banyak layanan komputasi untuk menghosting aplikasi yang sangat tersedia. Layanan berbeda dalam kemampuan dan kompleksitas. Kami menyarankan agar Anda memilih layanan berdasarkan:

• Persyaratan non-fungsional untuk keandalan, ketersediaan, performa, dan keamanan.
• Faktor keputusan seperti skalabilitas, biaya, pengoperasian, dan kompleksitas.

Pilihan platform hosting aplikasi adalah keputusan penting yang memengaruhi semua area desain lainnya. Misalnya, perangkat lunak pengembangan warisan atau kepemilikan mungkin tidak berjalan di layanan PaaS atau aplikasi dalam kontainer. Batasan ini akan memengaruhi pilihan platform komputasi Anda.

Aplikasi misi penting dapat menggunakan lebih dari satu layanan komputasi untuk mendukung beberapa beban kerja komposit dan layanan mikro, masing-masing dengan persyaratan yang berbeda.

Area desain ini memberikan rekomendasi yang terkait dengan pilihan komputasi, desain, dan opsi konfigurasi. Kami juga menyarankan Agar Anda membiasakan diri dengan pohon keputusan Komputasi.

Penting

Artikel ini adalah bagian dari seri beban kerja misi penting Azure Well-Architected Framework . Jika Anda tidak terbiasa dengan seri ini, kami sarankan Anda memulai dengan Apa itu beban kerja misi penting?.

Distribusi global sumber daya platform

Pola khas untuk beban kerja misi penting mencakup sumber daya global dan sumber daya regional.

Layanan Azure, yang tidak dibatasi ke wilayah Azure tertentu, disebarkan atau dikonfigurasi sebagai sumber daya global. Beberapa kasus penggunaan termasuk mendistribusikan lalu lintas di beberapa wilayah, menyimpan status permanen untuk seluruh aplikasi, dan penembolokan data statis global. Jika Anda perlu mengakomodasi arsitektur unit skala dan distribusi global, pertimbangkan bagaimana sumber daya didistribusikan atau direplikasi secara optimal di seluruh wilayah Azure.

Sumber daya lain disebarkan secara regional. Sumber daya ini, yang disebarkan sebagai bagian dari stempel penyebaran, biasanya sesuai dengan unit skala. Namun, suatu wilayah dapat memiliki lebih dari satu stempel, dan stempel dapat memiliki lebih dari satu unit. Keandalan sumber daya regional sangat penting karena mereka bertanggung jawab untuk menjalankan beban kerja utama.

Gambar berikut menunjukkan desain tingkat tinggi. Pengguna mengakses aplikasi melalui titik masuk global pusat yang kemudian mengalihkan permintaan ke stempel penyebaran regional yang sesuai:

Metodologi desain misi-kritis membutuhkan penyebaran multi-wilayah. Model ini memastikan toleransi kegagalan regional, sehingga aplikasi tetap tersedia bahkan ketika seluruh wilayah turun. Saat Anda merancang aplikasi multi-wilayah, pertimbangkan strategi penyebaran yang berbeda, seperti aktif/aktif dan aktif/pasif, bersama dengan persyaratan aplikasi, karena ada trade-off yang signifikan untuk setiap pendekatan. Untuk beban kerja misi penting, kami sangat merekomendasikan model aktif/aktif.

Tidak setiap beban kerja mendukung atau mengharuskan menjalankan beberapa wilayah secara bersamaan. Anda harus menimbang persyaratan aplikasi tertentu terhadap trade-off untuk menentukan keputusan desain yang optimal. Untuk skenario aplikasi tertentu yang memiliki target keandalan yang lebih rendah, aktif/pasif atau sharding dapat menjadi alternatif yang cocok.

Zona ketersediaan dapat menyediakan penyebaran regional yang sangat tersedia di berbagai pusat data dalam suatu wilayah. Hampir semua layanan Azure tersedia dalam konfigurasi zonal, di mana layanan didelegasikan ke zona tertentu, atau konfigurasi zona-redundan, di mana platform secara otomatis memastikan bahwa layanan mencakup seluruh zona dan dapat menahan pemadaman zona. Konfigurasi ini memberikan toleransi kesalahan hingga tingkat pusat data.

Mempertimbangkan rancangan

• Kemampuan regional dan zonal. Tidak semua layanan dan kemampuan tersedia di setiap wilayah Azure. Pertimbangan ini dapat memengaruhi wilayah yang Anda pilih. Selain itu, zona ketersediaan tidak tersedia di setiap wilayah.

• Pasangan regional. Wilayah Azure dikelompokkan ke dalam pasangan regional yang terdiri dari dua wilayah dalam satu geografi. Beberapa layanan Azure menggunakan wilayah berpasangan untuk memastikan kelangsungan bisnis dan untuk memberikan tingkat perlindungan terhadap kehilangan data. Misalnya, penyimpanan geo-redundan Azure (GRS) mereplikasi data ke wilayah berpasangan sekunder secara otomatis, memastikan bahwa data tahan lama jika wilayah utama tidak dapat dipulihkan. Jika pemadaman memengaruhi beberapa wilayah Azure, setidaknya satu wilayah di setiap pasangan diprioritaskan untuk pemulihan.

• Konsistensi data. Untuk tantangan konsistensi, pertimbangkan untuk menggunakan penyimpanan data yang didistribusikan secara global, arsitektur regional bertanda, dan penyebaran yang sebagian aktif/aktif. Dalam penyebaran parsial, beberapa komponen aktif di semua wilayah sementara yang lain terletak secara terpusat di wilayah utama.

• Penyebaran yang aman. Kerangka kerja praktik penyebaran aman Azure (SDP) memastikan bahwa semua perubahan kode dan konfigurasi (pemeliharaan terencana) ke platform Azure mengalami peluncuran bertahap. Kesehatan dianalisis untuk degradasi selama rilis. Setelah fase kenari dan pilot berhasil diselesaikan, pembaruan platform diserialisasikan di seluruh pasangan regional, sehingga hanya satu wilayah di setiap pasangan yang diperbarui pada waktu tertentu.

• Kapasitas platform. Seperti penyedia cloud lainnya, Azure memiliki sumber daya terbatas. Tidak tersedia dapat disebabkan oleh keterbatasan kapasitas di wilayah. Jika ada pemadaman regional, ada peningkatan permintaan sumber daya saat beban kerja mencoba memulihkan dalam wilayah yang dipasangkan. Pemadaman mungkin menciptakan masalah kapasitas, di mana pasokan sementara tidak memenuhi permintaan.

Rekomendasi desain

• Sebarkan solusi Anda di setidaknya dua wilayah Azure untuk membantu melindungi dari pemadaman regional. Sebarkan di wilayah yang memiliki kemampuan dan karakteristik yang diperlukan beban kerja. Kemampuan harus memenuhi target performa dan ketersediaan sambil memenuhi persyaratan residensi dan retensi data.

  Misalnya, beberapa persyaratan kepatuhan data mungkin membatasi jumlah wilayah yang tersedia dan berpotensi memaksa penyusupan desain. Dalam kasus seperti itu, kami sangat menyarankan Anda menambahkan investasi tambahan dalam pembungkus operasional untuk memprediksi, mendeteksi, dan merespons kegagalan. Misalkan Anda dibatasi untuk geografi dengan dua wilayah, dan hanya salah satu wilayah tersebut yang mendukung zona ketersediaan (model pusat data 3 + 1). Buat pola penyebaran sekunder menggunakan isolasi domain kesalahan untuk memungkinkan kedua wilayah disebarkan dalam konfigurasi aktif, dan pastikan bahwa wilayah utama menampung beberapa stempel penyebaran.

  Jika wilayah Azure yang sesuai tidak semua menawarkan kemampuan yang Anda butuhkan, bersiaplah untuk membahayakan konsistensi stempel penyebaran regional untuk memprioritaskan distribusi geografis dan memaksimalkan keandalan. Jika hanya satu wilayah Azure yang cocok, sebarkan beberapa stempel penyebaran (unit skala regional) di wilayah yang dipilih untuk mengurangi beberapa risiko, dan menggunakan zona ketersediaan untuk memberikan toleransi kesalahan tingkat pusat data. Namun, kompromi yang signifikan dalam distribusi geografis secara dramatis membatasi SLA komposit yang dapat dicapai dan keandalan keseluruhan.

  Penting

  Untuk skenario yang menargetkan SLO yang lebih besar dari atau sama dengan 99,99%, kami merekomendasikan minimal tiga wilayah penyebaran untuk memaksimalkan SLA komposit dan keandalan keseluruhan. Hitung SLA komposit untuk semua alur pengguna. Pastikan bahwa SLA komposit selaras dengan target bisnis.

• Untuk skenario aplikasi skala tinggi yang memiliki volume lalu lintas yang signifikan, rancang solusi untuk menskalakan di beberapa wilayah untuk menavigasi potensi batasan kapasitas dalam satu wilayah. Stempel penyebaran regional tambahan akan mencapai SLA komposit yang lebih tinggi. Menggunakan sumber daya global membatasi peningkatan SLA komposit yang Anda capai dengan menambahkan lebih banyak wilayah.

• Tentukan dan validasi tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO) Anda.

• Dalam satu geografi, prioritaskan penggunaan pasangan regional untuk mendapatkan manfaat dari peluncuran berseri SDP untuk pemeliharaan terencana dan prioritas regional untuk pemeliharaan yang tidak direncanakan.

• Kolokasikan sumber daya Azure secara geografis dengan pengguna untuk meminimalkan latensi jaringan dan memaksimalkan performa end-to-end.

  • Anda juga dapat menggunakan solusi seperti Content Delivery Network (CDN) atau penembolokan tepi untuk mendorong latensi jaringan yang optimal untuk basis pengguna terdistribusi. Untuk informasi selengkapnya, lihat Perutean lalu lintas global, Layanan pengiriman aplikasi, dan Penembolokan dan pengiriman konten statis.

• Selaraskan ketersediaan layanan saat ini dengan peta jalan produk saat Anda memilih wilayah penyebaran. Beberapa layanan mungkin tidak segera tersedia di setiap wilayah.

Kontainerisasi

Kontainer mencakup kode aplikasi dan file konfigurasi, pustaka, dan dependensi terkait yang perlu dijalankan aplikasi. Kontainerisasi menyediakan lapisan abstraksi untuk kode aplikasi dan dependensinya dan menciptakan pemisahan dari platform hosting yang mendasar. Paket perangkat lunak tunggal sangat portabel dan dapat berjalan secara konsisten di berbagai platform infrastruktur dan penyedia cloud. Pengembang tidak perlu menulis ulang kode dan dapat menyebarkan aplikasi dengan lebih cepat dan lebih andal.

Penting

Kami menyarankan agar Anda menggunakan kontainer untuk paket aplikasi yang sangat penting. Mereka meningkatkan pemanfaatan infrastruktur karena Anda dapat menghosting beberapa kontainer pada infrastruktur virtual yang sama. Selain itu, karena semua perangkat lunak disertakan dalam kontainer, Anda dapat memindahkan aplikasi di berbagai sistem operasi, terlepas dari runtime atau versi pustaka. Manajemen juga lebih mudah dengan kontainer daripada dengan hosting virtual tradisional.

Aplikasi misi penting perlu diskalakan dengan cepat untuk menghindari penyempitan performa. Karena gambar kontainer dibuat sebelumnya, Anda dapat membatasi startup untuk terjadi hanya selama bootstrapping aplikasi, yang memberikan skalabilitas yang cepat.

Mempertimbangkan rancangan

• Pemantauan. Mungkin sulit bagi layanan pemantauan untuk mengakses aplikasi yang ada dalam kontainer. Anda biasanya memerlukan perangkat lunak pihak ketiga untuk mengumpulkan dan menyimpan indikator status kontainer seperti penggunaan CPU atau RAM.

• Keamanan. Kernel OS platform hosting dibagikan di beberapa kontainer, menciptakan satu titik serangan. Namun, risiko akses VM host terbatas karena kontainer diisolasi dari sistem operasi yang mendasar.

• Negara bagian. Meskipun dimungkinkan untuk menyimpan data dalam sistem file kontainer yang sedang berjalan, data tidak akan bertahan saat kontainer dibuat ulang. Sebagai gantinya, pertahankan data dengan memasang penyimpanan eksternal atau menggunakan database eksternal.

Rekomendasi desain

• Kontainerkan semua komponen aplikasi. Gunakan gambar kontainer sebagai model utama untuk paket penyebaran aplikasi.

• Prioritaskan runtime kontainer berbasis Linux jika memungkinkan. Gambarnya lebih ringan, dan fitur baru untuk simpul/kontainer Linux sering dirilis.

• Membuat kontainer tidak dapat diubah dan diganti, dengan siklus hidup pendek.

• Pastikan untuk mengumpulkan semua log dan metrik yang relevan dari kontainer, host kontainer, dan kluster yang mendasar. Kirim log dan metrik yang dikumpulkan ke sink data terpadu untuk pemrosesan dan analisis lebih lanjut.

• Simpan gambar kontainer di Azure Container Registry. Gunakan replikasi geografis untuk mereplikasi gambar kontainer di semua wilayah. Aktifkan Microsoft Defender untuk registri kontainer untuk menyediakan pemindaian kerentanan untuk gambar kontainer. Pastikan akses ke registri dikelola oleh ID Microsoft Entra.

Hosting dan orkestrasi kontainer

Beberapa platform aplikasi Azure dapat menghosting kontainer secara efektif. Ada kelebihan dan kekurangan yang terkait dengan masing-masing platform ini. Bandingkan opsi dalam konteks kebutuhan bisnis Anda. Namun, selalu optimalkan keandalan, skalabilitas, dan performa. Untuk informasi selengkapnya, lihat artikel berikut ini:

• Pohon keputusan komputasi
• Perbandingan opsi kontainer

Penting

Azure Kubernetes Service (AKS) dan Azure Container Apps harus menjadi pilihan pertama Anda untuk manajemen kontainer tergantung pada kebutuhan Anda. Meskipun Azure App Service bukan orkestrator, sebagai platform kontainer gesekan rendah, ini masih merupakan alternatif yang layak untuk AKS.

Pertimbangan dan rekomendasi desain untuk Azure Kubernetes Service

AKS, layanan Kubernetes terkelola, memungkinkan provisi kluster cepat tanpa memerlukan aktivitas administrasi kluster yang kompleks dan menawarkan set fitur yang mencakup kemampuan jaringan dan identitas tingkat lanjut. Untuk serangkaian rekomendasi lengkap, lihat tinjauan Azure Well-Architected Framework - AKS.

Penting

Ada beberapa keputusan konfigurasi dasar yang tidak dapat Anda ubah tanpa menyebarkan kembali kluster AKS. Contohnya termasuk pilihan antara kluster AKS publik dan privat, mengaktifkan Azure Network Policy, integrasi Microsoft Entra, dan penggunaan identitas terkelola untuk AKS alih-alih perwakilan layanan.

Keandalan

AKS mengelola sarana kontrol Kubernetes asli. Jika sarana kontrol tidak tersedia, beban kerja akan mengalami waktu henti. Manfaatkan fitur keandalan yang ditawarkan oleh AKS:

• Sebarkan kluster AKS di berbagai wilayah Azure sebagai unit skala untuk memaksimalkan keandalan dan ketersediaan. Gunakan zona ketersediaan untuk memaksimalkan ketahanan dalam wilayah Azure dengan mendistribusikan sarana kontrol AKS dan simpul agen di seluruh pusat data yang terpisah secara fisik. Namun, jika latensi kolokasi bermasalah, Anda dapat melakukan penyebaran AKS dalam satu zona atau menggunakan grup penempatan kedekatan untuk meminimalkan latensi internode.

• Gunakan AKS Uptime SLA untuk kluster produksi untuk memaksimalkan jaminan ketersediaan titik akhir API Kubernetes.

Skalabilitas

Mempertimbangkan batas skala AKS, seperti jumlah simpul, kumpulan simpul per kluster, dan kluster per langganan.

• Jika batas skala adalah batasan, manfaatkan strategi unit skala, dan sebarkan lebih banyak unit dengan kluster.

• Aktifkan autoscaler kluster untuk secara otomatis menyesuaikan jumlah node agen sebagai respons terhadap batasan sumber daya.

• Gunakan autoscaler pod horizontal untuk menyesuaikan jumlah pod dalam penyebaran berdasarkan pemanfaatan CPU atau metrik lainnya.

• Untuk skenario skala tinggi dan ledakan, pertimbangkan untuk menggunakan simpul virtual untuk skala ekstensif dan cepat.

• Tentukan permintaan dan batasan sumber daya pod dalam manifes penyebaran aplikasi. Jika tidak, Anda mungkin mengalami masalah performa.

Isolasi

Pertahankan batasan antara infrastruktur yang digunakan oleh beban kerja dan alat sistem. Berbagi infrastruktur dapat menyebabkan pemanfaatan sumber daya tinggi dan skenario tetangga yang bising.

• Gunakan kumpulan simpul terpisah untuk layanan sistem dan beban kerja. Kumpulan simpul khusus untuk komponen beban kerja harus didasarkan pada persyaratan untuk sumber daya infrastruktur khusus seperti VM GPU memori tinggi. Secara umum, untuk mengurangi overhead manajemen yang tidak perlu, hindari menyebarkan sejumlah besar kumpulan simpul.

• Gunakan taint dan toleransi untuk menyediakan simpul khusus dan membatasi aplikasi intensif sumber daya.

• Evaluasi afinitas aplikasi dan persyaratan anti-afinitas dan konfigurasikan kolokasi kontainer yang sesuai pada simpul.

Keamanan

Kubernetes vanili default memerlukan konfigurasi yang signifikan untuk memastikan postur keamanan yang sesuai untuk skenario misi-kritis. AKS mengatasi berbagai risiko keamanan di luar kotak. Fitur termasuk kluster privat, audit dan pengelogan ke Log Analytics, gambar simpul yang diperkeras, dan identitas terkelola.

• Terapkan panduan konfigurasi yang disediakan dalam garis besar keamanan AKS.

• Gunakan fitur AKS untuk menangani identitas kluster dan manajemen akses untuk mengurangi overhead operasional dan menerapkan manajemen akses yang konsisten.

• Gunakan identitas terkelola alih-alih perwakilan layanan untuk menghindari manajemen dan rotasi kredensial. Anda dapat menambahkan identitas terkelola di tingkat kluster. Pada tingkat pod, Anda dapat menggunakan identitas terkelola melalui Microsoft Entra Workload ID.

• Gunakan integrasi Microsoft Entra untuk manajemen akun dan kata sandi terpusat, manajemen akses aplikasi, dan perlindungan identitas yang ditingkatkan. Gunakan RBAC Kubernetes dengan ID Microsoft Entra untuk hak istimewa paling sedikit, dan minimalkan pemberian hak istimewa administrator untuk membantu melindungi akses konfigurasi dan rahasia. Selain itu, batasi akses ke file konfigurasi kluster Kubernetes dengan menggunakan kontrol akses berbasis peran Azure. Batasi akses ke tindakan yang dapat dilakukan kontainer, berikan jumlah izin paling sedikit, dan hindari penggunaan eskalasi hak istimewa root.

Peningkatan

Kluster dan simpul perlu ditingkatkan secara teratur. AKS mendukung versi Kubernetes yang selaras dengan siklus rilis Kubernetes asli.

• Berlangganan Roadmap AKS publik dan Catatan Rilis di GitHub untuk tetap mendapatkan informasi terbaru tentang perubahan, peningkatan, dan, yang paling penting, rilis dan penghentian versi Kubernetes yang akan datang.

• Terapkan panduan yang disediakan dalam daftar periksa AKS untuk memastikan keselarasan dengan praktik terbaik.

• Waspadai berbagai metode yang didukung oleh AKS untuk memperbarui simpul dan/atau kluster. Metode ini dapat manual atau otomatis. Anda dapat menggunakan Pemeliharaan Terencana untuk menentukan jendela pemeliharaan untuk operasi ini. Gambar baru dirilis setiap minggu. AKS juga mendukung saluran peningkatan otomatis untuk meningkatkan kluster AKS secara otomatis ke versi Kubernetes yang lebih baru dan/atau gambar simpul yang lebih baru saat tersedia.

Jaringan

Evaluasi plugin jaringan yang paling sesuai dengan kasus penggunaan Anda. Tentukan apakah Anda memerlukan kontrol lalu lintas terperinci antar pod. Azure mendukung kubenet, Azure CNI, dan membawa CNI Anda sendiri untuk kasus penggunaan tertentu.

Prioritaskan penggunaan Azure CNI setelah menilai persyaratan jaringan dan ukuran kluster. Azure CNI memungkinkan penggunaan kebijakan jaringan Azure atau Calico untuk mengontrol lalu lintas dalam kluster.

Pemantauan

Alat pemantauan Anda harus dapat menangkap log dan metrik dari pod yang sedang berjalan. Anda juga harus mengumpulkan informasi dari API Metrik Kubernetes untuk memantau kesehatan sumber daya dan beban kerja yang berjalan.

• Gunakan Azure Monitor dan Application Insights untuk mengumpulkan metrik, log, dan diagnostik dari sumber daya AKS untuk pemecahan masalah.

• Aktifkan dan tinjau log sumber daya Kube.

• Mengonfigurasi metrik Prometheus di Azure Monitor. Wawasan kontainer di Monitor menyediakan onboarding, memungkinkan kemampuan pemantauan di luar kotak, dan memungkinkan kemampuan yang lebih canggih melalui dukungan Prometheus bawaan.

Pemerintahan

Gunakan kebijakan untuk menerapkan perlindungan terpusat ke kluster AKS dengan cara yang konsisten. Terapkan penetapan kebijakan pada cakupan langganan atau yang lebih tinggi untuk mendorong konsistensi di seluruh tim pengembangan.

• Kontrol fungsi mana yang diberikan ke pod, dan apakah menjalankan bertentangan dengan kebijakan, dengan menggunakan Azure Policy. Akses ini ditentukan melalui kebijakan bawaan yang disediakan oleh Add-on Azure Policy untuk AKS.

• Tetapkan garis besar keandalan dan keamanan yang konsisten untuk konfigurasi kluster dan pod AKS dengan menggunakan Azure Policy.

• Gunakan Add-on Azure Policy untuk AKS untuk mengontrol fungsi pod, seperti hak istimewa root, dan untuk melarang pod yang tidak sesuai dengan kebijakan.

Catatan

Saat Anda menyebarkan ke zona pendaratan Azure, kebijakan Azure untuk membantu Anda memastikan keandalan dan keamanan yang konsisten harus disediakan oleh implementasi zona pendaratan.

Implementasi referensi misi penting menyediakan serangkaian kebijakan dasar untuk mendorong konfigurasi keandalan dan keamanan yang direkomendasikan.

Pertimbangan dan rekomendasi desain untuk Azure App Service

Untuk skenario beban kerja berbasis web dan API, App Service mungkin merupakan alternatif yang layak untuk AKS. Ini menyediakan platform kontainer gesekan rendah tanpa kompleksitas Kubernetes. Untuk serangkaian rekomendasi lengkap, lihat Pertimbangan keandalan untuk App Service dan Keunggulan operasional untuk App Service.

Keandalan

Evaluasi penggunaan port TCP dan SNAT. Koneksi TCP digunakan untuk semua koneksi keluar. Port SNAT digunakan untuk koneksi keluar ke alamat IP publik. Kelelahan port SNAT adalah skenario kegagalan umum. Anda harus secara prediktif mendeteksi masalah ini dengan pengujian beban saat menggunakan Diagnostik Azure untuk memantau port. Jika terjadi kesalahan SNAT, Anda perlu menskalakan di lebih banyak atau lebih banyak pekerja atau menerapkan praktik pengkodian untuk membantu mempertahankan dan menggunakan kembali port SNAT. Contoh praktik pengkodian yang dapat Anda gunakan termasuk pengumpulan koneksi dan pemuatan sumber daya yang malas.

Kelelahan port TCP adalah skenario kegagalan lain. Ini terjadi ketika jumlah koneksi keluar dari pekerja tertentu melebihi kapasitas. Jumlah port TCP yang tersedia tergantung pada ukuran pekerja. Untuk rekomendasi, lihat port TCP dan SNAT.

Skalabilitas

Rencanakan persyaratan skalabilitas dan pertumbuhan aplikasi di masa mendatang sehingga Anda dapat menerapkan rekomendasi yang sesuai sejak awal. Dengan demikian, Anda dapat menghindari utang migrasi teknis saat solusi tumbuh.

• Aktifkan skala otomatis untuk memastikan bahwa sumber daya yang memadai tersedia untuk permintaan layanan. Evaluasi penskalaan per aplikasi untuk hosting dengan kepadatan tinggi di App Service.

• Ketahuilah bahwa App Service memiliki batas instans lunak default per paket App Service.

• Terapkan aturan skala otomatis. Paket App Service diskalakan jika ada aturan dalam profil yang terpenuhi tetapi hanya menskalakan jika semua aturan dalam profil terpenuhi. Gunakan kombinasi aturan peluasan skala dan penyempisan skala untuk memastikan bahwa skala otomatis dapat mengambil tindakan untuk peluasan skala dan penyempisan skala. Pahami perilaku beberapa aturan penskalaan dalam satu profil.

• Ketahuilah bahwa Anda dapat mengaktifkan penskalaan per aplikasi pada tingkat paket App Service untuk memungkinkan aplikasi menskalakan secara independen dari paket App Service yang menghostingnya. Aplikasi dialokasikan untuk simpul yang tersedia melalui pendekatan upaya terbaik untuk distribusi yang merata. Meskipun distribusi yang merata tidak dijamin, platform memastikan bahwa dua instans aplikasi yang sama tidak dihosting pada instans yang sama.

Pemantauan

Pantau perilaku aplikasi dan dapatkan akses ke log dan metrik yang relevan untuk memastikan bahwa aplikasi Anda berfungsi seperti yang diharapkan.

• Anda dapat menggunakan pembuatan log diagnostik untuk menyerap log tingkat aplikasi dan tingkat platform ke Log Analytics, Azure Storage, atau alat pihak ketiga melalui Azure Event Hubs.

• Pemantauan performa aplikasi dengan Application Insights memberikan wawasan mendalam tentang performa aplikasi.

• Aplikasi misi penting harus memiliki kemampuan untuk menyembuhkan diri sendiri jika ada kegagalan. Aktifkan Pemulihan Otomatis untuk mendaur ulang pekerja yang tidak sehat secara otomatis.

• Anda perlu menggunakan pemeriksaan kesehatan yang sesuai untuk menilai semua dependensi hilir penting, yang membantu memastikan kesehatan secara keseluruhan. Kami sangat menyarankan Anda mengaktifkan Pemeriksaan Kesehatan untuk mengidentifikasi pekerja yang tidak responsif.

Penyebaran

Untuk mengatasi batas default instans per paket App Service, sebarkan paket App Service di beberapa unit skala dalam satu wilayah. Sebarkan paket App Service dalam konfigurasi zona ketersediaan untuk memastikan bahwa simpul pekerja didistribusikan di seluruh zona dalam suatu wilayah. Pertimbangkan untuk membuka tiket dukungan untuk meningkatkan jumlah maksimum pekerja menjadi dua kali jumlah instans yang Anda butuhkan untuk melayani beban puncak normal.

Registri kontainer

Registri kontainer menghosting gambar yang disebarkan ke lingkungan runtime kontainer seperti AKS. Anda perlu mengonfigurasi registri kontainer Anda untuk beban kerja misi penting dengan hati-hati. Pemadaman seharusnya tidak menyebabkan keterlambatan dalam menarik gambar, terutama selama operasi penskalaan. Pertimbangan dan rekomendasi berikut berfokus pada Azure Container Registry dan menjelajahi trade-off yang terkait dengan model penyebaran terpusat dan federasi.

Mempertimbangkan rancangan

• Format. Pertimbangkan untuk menggunakan registri kontainer yang bergantung pada format dan standar yang disediakan Docker untuk operasi pendorongan dan penarikan. Solusi ini kompatibel dan sebagian besar dapat dipertukarkan.

• Model penyebaran. Anda dapat menyebarkan registri kontainer sebagai layanan terpusat yang digunakan oleh beberapa aplikasi dalam organisasi Anda. Atau Anda dapat menyebarkannya sebagai komponen khusus untuk beban kerja aplikasi tertentu.

• Registri publik. Gambar kontainer disimpan di Docker Hub atau registri publik lainnya yang ada di luar Azure dan jaringan virtual tertentu. Ini belum tentu menjadi masalah, tetapi dapat menyebabkan berbagai masalah yang terkait dengan ketersediaan layanan, pembatasan, dan penyelundupan data. Untuk beberapa skenario aplikasi, Anda perlu mereplikasi gambar kontainer publik dalam registri kontainer privat untuk membatasi lalu lintas keluar, meningkatkan ketersediaan, atau menghindari potensi pembatasan.

Rekomendasi desain

• Gunakan instans registri kontainer yang didedikasikan untuk beban kerja aplikasi. Hindari membuat dependensi pada layanan terpusat kecuali persyaratan ketersediaan dan keandalan organisasi sepenuhnya selaras dengan aplikasi.

  Dalam pola arsitektur inti yang direkomendasikan, registri kontainer adalah sumber daya global yang hidup lama. Pertimbangkan untuk menggunakan satu registri kontainer global per lingkungan. Misalnya, gunakan registri produksi global.

• Pastikan bahwa SLA untuk registri publik selaras dengan target keandalan dan keamanan Anda. Perhatikan batas pembatasan khusus untuk kasus penggunaan yang bergantung pada Docker Hub.

• Prioritaskan Azure Container Registry untuk menghosting gambar kontainer.

Pertimbangan dan rekomendasi desain untuk Azure Container Registry

Layanan asli ini menyediakan berbagai fitur, termasuk replikasi geografis, autentikasi Microsoft Entra, bangunan kontainer otomatis, dan patching melalui tugas Container Registry.

Keandalan

Konfigurasikan replikasi geografis ke semua wilayah penyebaran untuk menghapus dependensi regional dan mengoptimalkan latensi. Container Registry mendukung ketersediaan tinggi melalui replikasi geografis ke beberapa wilayah yang dikonfigurasi, memberikan ketahanan terhadap pemadaman regional. Jika suatu wilayah menjadi tidak tersedia, wilayah lain terus melayani permintaan gambar. Ketika wilayah kembali online, Container Registry memulihkan dan mereplikasi perubahan pada wilayah tersebut. Kemampuan ini juga menyediakan kolokasi registri dalam setiap wilayah yang dikonfigurasi, mengurangi latensi jaringan dan biaya transfer data lintas wilayah.

Di wilayah Azure yang menyediakan dukungan zona ketersediaan, tingkat Premium Container Registry mendukung redundansi zona untuk memberikan perlindungan terhadap kegagalan zonal. Tingkat Premium juga mendukung titik akhir privat untuk membantu mencegah akses tidak sah ke registri, yang dapat menyebabkan masalah keandalan.

Host gambar yang dekat dengan sumber daya komputasi yang mengkonsumsi, dalam wilayah Azure yang sama.

Penguncian gambar

Gambar dapat dihapus, sebagai akibat dari, misalnya, kesalahan manual. Container Registry mendukung penguncian versi gambar atau repositori untuk mencegah perubahan atau penghapusan. Ketika versi gambar yang disebarkan sebelumnya diubah di tempat, penyebaran versi yang sama mungkin memberikan hasil yang berbeda sebelum dan sesudah perubahan.

Jika Anda ingin melindungi instans Container Registry dari penghapusan, gunakan kunci sumber daya.

Gambar yang diberi tag

Gambar Container Registry yang ditandai dapat diubah secara default, yang berarti bahwa tag yang sama dapat digunakan pada beberapa gambar yang didorong ke registri. Dalam skenario produksi, ini dapat menyebabkan perilaku yang tidak dapat diprediksi yang dapat memengaruhi waktu aktif aplikasi.

Pengelolaan identitas dan akses

Gunakan autentikasi terintegrasi Microsoft Entra untuk mendorong dan menarik gambar alih-alih mengandalkan kunci akses. Untuk keamanan yang ditingkatkan, nonaktifkan sepenuhnya penggunaan kunci akses admin.

Komputasi tanpa server

Komputasi tanpa server menyediakan sumber daya sesuai permintaan dan menghilangkan kebutuhan untuk mengelola infrastruktur. Penyedia cloud secara otomatis menyediakan, menskalakan, dan mengelola sumber daya yang diperlukan untuk menjalankan kode aplikasi yang disebarkan. Azure menyediakan beberapa platform komputasi tanpa server:

• Azure Functions. Saat Anda menggunakan Azure Functions, logika aplikasi diimplementasikan sebagai blok kode yang berbeda, atau fungsi, yang berjalan sebagai respons terhadap peristiwa, seperti permintaan HTTP atau pesan antrean. Setiap fungsi diskalakan seperlunya untuk memenuhi permintaan.

• Azure Logic Apps. Logic Apps paling cocok untuk membuat dan menjalankan alur kerja otomatis yang mengintegrasikan berbagai aplikasi, sumber data, layanan, dan sistem. Seperti Azure Functions, Logic Apps menggunakan pemicu bawaan untuk pemrosesan berbasis peristiwa. Namun, alih-alih menyebarkan kode aplikasi, Anda dapat membuat aplikasi logika dengan menggunakan antarmuka pengguna grafis yang mendukung blok kode seperti kondisi dan perulangan.

• Azure API Management. Anda dapat menggunakan API Management untuk menerbitkan, mengubah, memelihara, dan memantau API keamanan yang ditingkatkan dengan menggunakan tingkat Konsumsi.

• Power Apps dan Power Automate. Alat-alat ini memberikan pengalaman pengembangan kode rendah atau tanpa kode, dengan logika alur kerja sederhana dan integrasi yang dapat dikonfigurasi melalui koneksi di antarmuka pengguna.

Untuk aplikasi misi penting, teknologi tanpa server menyediakan pengembangan dan operasi yang disederhanakan, yang dapat berharga untuk kasus penggunaan bisnis sederhana. Namun, kesederhanaan ini dikenakan fleksibilitas dalam hal skalabilitas, keandalan, dan performa, dan itu tidak layak untuk sebagian besar skenario aplikasi misi-kritis.

Bagian berikut memberikan pertimbangan desain dan rekomendasi untuk menggunakan Azure Functions dan Logic Apps sebagai platform alternatif untuk skenario alur kerja non-kritis.

Pertimbangan dan rekomendasi desain untuk Azure Functions

Beban kerja misi penting memiliki alur sistem yang penting dan tidak penting. Azure Functions adalah pilihan yang layak untuk alur yang tidak memiliki persyaratan bisnis yang ketat yang sama dengan alur sistem penting. Ini sangat cocok untuk alur berbasis peristiwa yang memiliki proses berumur pendek karena fungsi melakukan operasi berbeda yang berjalan secepat mungkin.

Pilih opsi hosting Azure Functions yang sesuai untuk tingkat keandalan aplikasi. Kami merekomendasikan paket Premium karena memungkinkan Anda mengonfigurasi ukuran instans komputasi. Paket Khusus adalah opsi tanpa server paling sedikit. Ini menyediakan skala otomatis, tetapi operasi skala ini lebih lambat daripada paket lainnya. Kami menyarankan agar Anda menggunakan paket Premium untuk memaksimalkan keandalan dan performa.

Ada beberapa pertimbangan keamanan. Saat Anda menggunakan pemicu HTTP untuk mengekspos titik akhir eksternal, gunakan firewall aplikasi web (WAF) untuk memberikan tingkat perlindungan untuk titik akhir HTTP dari vektor serangan eksternal umum.

Kami merekomendasikan penggunaan titik akhir privat untuk membatasi akses ke jaringan virtual privat. Mereka juga dapat mengurangi risiko penyelundupan data, seperti skenario admin berbahaya.

Anda perlu menggunakan alat pemindaian kode pada kode Azure Functions dan mengintegrasikan alat tersebut dengan alur CI/CD.

Pertimbangan dan rekomendasi desain untuk Azure Logic Apps

Seperti Azure Functions, Logic Apps menggunakan pemicu bawaan untuk pemrosesan berbasis peristiwa. Namun, alih-alih menyebarkan kode aplikasi, Anda dapat membuat aplikasi logika dengan menggunakan antarmuka pengguna grafis yang mendukung blok seperti kondisional, perulangan, dan konstruksi lainnya.

Beberapa mode penyebaran tersedia. Kami merekomendasikan mode Standar untuk memastikan penyebaran penyewa tunggal dan mengurangi skenario tetangga yang bising. Mode ini menggunakan runtime Logic Apps penyewa tunggal kontainer, yang didasarkan pada Azure Functions. Dalam mode ini, aplikasi logika dapat memiliki beberapa alur kerja stateful dan stateless. Anda harus mengetahui batas konfigurasi.

Migrasi yang dibatasi melalui IaaS

Banyak aplikasi yang memiliki penyebaran lokal yang ada menggunakan teknologi virtualisasi dan perangkat keras redundan untuk memberikan tingkat keandalan misi penting. Modernisasi sering dihalangi oleh kendala bisnis yang mencegah keselarasan penuh dengan pola arsitektur garis besar cloud-native (Bintang Utara) yang direkomendasikan untuk beban kerja misi penting. Itulah sebabnya banyak aplikasi mengadopsi pendekatan bertahap, dengan penyebaran cloud awal menggunakan virtualisasi dan Azure Virtual Machines sebagai model hosting aplikasi utama. Penggunaan komputer virtual IaaS mungkin diperlukan dalam skenario tertentu:

• Layanan PaaS yang tersedia tidak memberikan performa atau tingkat kontrol yang diperlukan.
• Beban kerja memerlukan akses sistem operasi, driver tertentu, atau konfigurasi jaringan dan sistem.
• Beban kerja tidak mendukung berjalan dalam kontainer.
• Tidak ada dukungan vendor untuk beban kerja pihak ketiga.

Bagian ini berfokus pada cara terbaik untuk menggunakan Azure Virtual Machines dan layanan terkait untuk memaksimalkan keandalan platform aplikasi. Ini menyoroti aspek-aspek utama dari metodologi desain misi-kritis yang mengubah skenario migrasi cloud-native dan IaaS.

Mempertimbangkan rancangan

• Biaya operasional penggunaan komputer virtual IaaS jauh lebih tinggi daripada biaya penggunaan layanan PaaS karena persyaratan manajemen komputer virtual dan sistem operasi. Mengelola komputer virtual harus sering meluncurkan paket dan pembaruan perangkat lunak.

• Azure menyediakan kemampuan untuk meningkatkan ketersediaan komputer virtual:

  • Set ketersediaan dapat membantu melindungi dari kegagalan jaringan, disk, dan daya dengan mendistribusikan komputer virtual di seluruh domain kesalahan dan memperbarui domain.
  • Zona ketersediaan dapat membantu Anda mencapai tingkat keandalan yang lebih tinggi dengan mendistribusikan VM di seluruh pusat data yang dipisahkan secara fisik dalam suatu wilayah.
  • Virtual Machine Scale Sets menyediakan fungsionalitas untuk secara otomatis menskalakan jumlah komputer virtual dalam grup. Mereka juga menyediakan kemampuan untuk memantau kesehatan instans dan secara otomatis memperbaiki instans yang tidak sehat.

Rekomendasi desain

Penting

Gunakan layanan dan kontainer PaaS jika memungkinkan untuk mengurangi kompleksitas dan biaya operasional. Gunakan komputer virtual IaaS hanya ketika Anda perlu.

• Ukuran SKU VM yang tepat untuk memastikan pemanfaatan sumber daya yang efektif.

• Sebarkan tiga atau beberapa komputer virtual di seluruh zona ketersediaan untuk mencapai toleransi kesalahan tingkat pusat data.

  • Jika Anda menyebarkan perangkat lunak off-the-shelf komersial, konsultasikan dengan vendor perangkat lunak dan uji secara memadai sebelum menyebarkan perangkat lunak ke dalam produksi.

• Untuk beban kerja yang tidak dapat disebarkan di seluruh zona ketersediaan, gunakan set ketersediaan yang berisi tiga VM atau lebih.

  • Pertimbangkan set ketersediaan hanya jika zona ketersediaan tidak memenuhi persyaratan beban kerja, seperti untuk beban kerja yang cerewet dengan persyaratan latensi rendah.

• Prioritaskan penggunaan Virtual Machine Scale Sets untuk skalabilitas dan redundansi zona. Titik ini sangat penting untuk beban kerja yang memiliki berbagai beban. Misalnya, jika jumlah pengguna aktif atau permintaan per detik adalah beban yang bervariasi.

• Jangan mengakses komputer virtual individual secara langsung. Gunakan load balancer di depannya jika memungkinkan.

• Untuk melindungi dari pemadaman regional, sebarkan komputer virtual aplikasi di beberapa wilayah Azure.

  • Lihat area desain jaringan dan konektivitas untuk detail tentang cara merutekan lalu lintas secara optimal antara wilayah penyebaran aktif.

• Untuk beban kerja yang tidak mendukung penyebaran aktif/aktif multi-wilayah, pertimbangkan untuk menerapkan penyebaran aktif/pasif dengan menggunakan komputer virtual siaga panas/hangat untuk failover regional.

• Gunakan gambar standar dari Marketplace Azure daripada gambar kustom yang perlu dipertahankan.

• Terapkan proses otomatis untuk menyebarkan dan meluncurkan perubahan pada komputer virtual, menghindari intervensi manual. Untuk informasi selengkapnya, lihat Pertimbangan IaaS di area Desain prosedur operasional .

• Terapkan eksperimen chaos untuk menyuntikkan kesalahan aplikasi ke komponen komputer virtual, dan amati mitigasi kesalahan. Untuk informasi selengkapnya, lihat Validasi dan pengujian berkelanjutan.

• Pantau komputer virtual dan pastikan bahwa log dan metrik diagnostik diserap ke dalam sink data terpadu.

• Terapkan praktik keamanan untuk skenario aplikasi misi penting, jika berlaku, dan praktik terbaik Keamanan untuk beban kerja IaaS di Azure.

Langkah selanjutnya

Tinjau pertimbangan untuk platform data.

Platform data