Analisis mode kegagalan untuk aplikasi Azure

Analisis mode kegagalan (FMA) adalah proses untuk membangun ketahanan ke dalam suatu sistem, dengan mengidentifikasi titik-titik kegagalan yang mungkin terjadi dalam sistem. FMA harus menjadi bagian dari fase arsitektur dan desain, sehingga Anda dapat membangun pemulihan kegagalan ke dalam sistem dari awal.

Berikut adalah proses umum untuk melakukan FMA:

1. Identifikasi semua komponen dalam sistem. Sertakan dependensi eksternal, seperti penyedia identitas, layanan pihak ketiga, dan sebagainya.

2. Untuk setiap komponen, identifikasi potensi kegagalan yang bisa terjadi. Satu komponen mungkin memiliki lebih dari satu mode kegagalan. Misalnya, Anda harus mempertimbangkan kegagalan baca dan kegagalan tulis secara terpisah, karena dampak dan kemungkinan langkah mitigasi akan berbeda.

3. Nilai setiap mode kegagalan sesuai dengan risiko keseluruhannya. Pertimbangkan faktor-faktor ini:

   • Apa kemungkinan kegagalannya. Apakah itu relatif umum? Sangat jarang? Anda tidak perlu angka pasti; tujuannya adalah untuk membantu menentukan peringkat prioritas.
   • Apa dampaknya terhadap aplikasi, dalam hal ketersediaan, kehilangan data, biaya moneter, dan gangguan bisnis?

4. Untuk setiap mode kegagalan, tentukan bagaimana aplikasi akan merespons dan memulihkan. Pertimbangkan tradeoff dalam biaya dan kompleksitas aplikasi.

Sebagai titik awal untuk proses FMA Anda, artikel ini berisi katalog kemungkinan mode kegagalandan langkah-langkah mitigasinya. Katalog diatur oleh teknologi atau layanan Azure, ditambah kategori umum untuk rancangan tingkat aplikasi. Katalog tidak lengkap, tetapi mencakup banyak layanan inti Azure.

Catatan

Kegagalan harus dibedakan dari kesalahan. Kegagalan adalah peristiwa tak terduga dalam sistem yang mencegahnya terus berfungsi secara normal. Misalnya, kerusakan perangkat keras yang menyebabkan partisi jaringan gagal. Biasanya, kegagalan memerlukan intervensi atau desain khusus untuk kelas kegagalan tersebut. Sebaliknya, kesalahan adalah bagian yang diharapkan dari operasi normal, segera ditangani dan sistem akan terus beroperasi pada kapasitas yang sama setelah kesalahan. Misalnya, kesalahan yang ditemukan selama validasi input dapat ditangani melalui logika bisnis.

App Service

Aplikasi App Service ditutup.

Deteksi. Kemungkinan penyebabnya:

• Penutupan yang diduga

  • Operator menutup aplikasi; misalnya, menggunakan portal Microsoft Azure.
  • Aplikasi ini dibongkar karena idle. (Hanya jika pengaturan Always On dinonaktifkan.)

• Penutupan tak terduga

  • Aplikasi crash.
  • Instans VM App Service menjadi tidak tersedia.

Pengelogan Application_End akan menangkap penutupan domain aplikasi (crash proses lunak) dan merupakan satu-satunya cara untuk menangkap penutupan domain aplikasi.

Pemulihan:

• Jika penutupan diduga, gunakan peristiwa penutupan aplikasi untuk menutup tanpa gangguan. Misalnya, dalam ASP.NET, gunakan metode Application_End.
• Jika dibongkar saat idle, aplikasi secara otomatis dimulai ulang pada permintaan berikutnya. Namun, Anda akan dikenakan biaya "mulai dingin".
• Untuk mencegah aplikasi dibongkar saat idle, aktifkan pengaturan Always On di aplikasi web. Lihat Mengonfigurasi aplikasi web di Azure App Service.
• Untuk mencegah operator mematikan aplikasi, atur kunci sumber daya dengan tingkat ReadOnly. Lihat Mengunci sumber daya dengan Azure Resource Manager.
• Jika aplikasi crash atau VM App Service menjadi tidak tersedia, App Service secara otomatis memulai ulang aplikasi.

Diagnostik. Log aplikasi dan log server web. Lihat Mengaktifkan pengelogan diagnostik untuk aplikasi web di Azure App Service.

Pengguna tertentu berulang kali membuat permintaan yang buruk atau membebani sistem.

Deteksi. Autentikasi pengguna dan sertakan ID pengguna dalam log aplikasi.

Pemulihan:

• Gunakan Azure API Management untuk membatasi permintaan dari pengguna. Lihat Pembatasan permintaan tingkat lanjut dengan Azure API Management
• Blokir pengguna.

Diagnostik. Catat semua permintaan autentikasi.

Pembaruan yang buruk disebarkan.

Deteksi. Pantau kesehatan aplikasi melalui portal Azure (lihat Memantau performa aplikasi web Azure) atau terapkan pola pemantauan titik akhir kesehatan.

Pemulihat:. Gunakan beberapa slot penyebaran dan kembali ke penyebaran terakhir yang diketahui. Untuk informasi selengkapnya, lihat Aplikasi web dasar.

Microsoft Entra ID

Autentikasi OpenID Connect gagal.

Deteksi. Kemungkinan mode kegagalan mencakup:

1. ID Microsoft Entra tidak tersedia, atau tidak dapat dijangkau karena masalah jaringan. Pengalihan ke titik akhir autentikasi gagal, dan middleware OpenID Connect memberikan pengecualian.
2. Penyewa Microsoft Entra tidak ada. Pengalihan ke titik akhir autentikasi mengembalikan kode galat HTTP, dan middleware OpenID Connect memberikan pengecualian.
3. Pengguna tidak dapat mengautentikasi. Tidak ada strategi deteksi yang diperlukan; ID Microsoft Entra menangani kegagalan masuk.

Pemulihan:

1. Tangkap pengecualian yang tidak tertangani dari middleware.
2. Tangani peristiwa AuthenticationFailed.
3. Alihkan pengguna ke halaman kesalahan.
4. Percobaan ulang pengguna.

Pencarian Azure

Menulis data ke Azure Search gagal.

Deteksi. Tangkap kesalahan Microsoft.Rest.Azure.CloudException.

Pemulihan:

Search .NET SDK secara otomatis mencoba kembali setelah kegagalan sementara. Pengecualian apa pun yang diberikan oleh SDK klien harus diperlakukan sebagai kesalahan bukan sementara.

Kebijakan percobaan ulang default menggunakan back-off eksponensial. Untuk menggunakan kebijakan coba ulang yang berbeda, panggil SetRetryPolicy di kelas SearchIndexClient atau SearchServiceClient. Untuk informasi selengkapnya, lihat Percobaan Ulang Otomatis.

Diagnostik. Gunakan Analitik Lalu Lintas Pencarian.

Membaca data dari Azure Search gagal.

Deteksi. Tangkap kesalahan Microsoft.Rest.Azure.CloudException.

Pemulihan:

Search .NET SDK secara otomatis mencoba kembali setelah kegagalan sementara. Pengecualian apa pun yang diberikan oleh SDK klien harus diperlakukan sebagai kesalahan bukan sementara.

Kebijakan percobaan ulang default menggunakan back-off eksponensial. Untuk menggunakan kebijakan coba ulang yang berbeda, panggil SetRetryPolicy di kelas SearchIndexClient atau SearchServiceClient. Untuk informasi selengkapnya, lihat Percobaan Ulang Otomatis.

Diagnostik. Gunakan Analitik Lalu Lintas Pencarian.

Cassandra

Membaca atau menulis ke node gagal.

Deteksi. Tangkap pengecualiannya. Untuk klien .NET, ini biasanya akan menjadi System.Web.HttpException. Klien lain mungkin memiliki jenis pengecualian lainnya. Untuk informasi selengkapnya, lihat Penanganan kesalahan Cassandra dilakukan dengan benar.

Pemulihan:

• Setiap klien Cassandra memiliki kebijakan dan kemampuan percobaan ulang sendiri. Untuk informasi selengkapnya, lihat Penanganan kesalahan Cassandra dilakukan dengan benar.
• Gunakan penyebaran berbasis rak, dengan node data yang didistribusikan di seluruh domain kesalahan.
• Sebarkan ke beberapa wilayah dengan konsistensi kuorum lokal. Jika kegagalan bukan sementara terjadi, alihkan ke wilayah lain.

Diagnostik. Log aplikasi

Layanan Cloud

Peran web atau pekerja secara tak terduga ditutup.

Deteksi. Peristiwa RoleEnvironment.Stopping diaktifkan.

Pemulihan. Timpa metode RoleEntryPoint.OnStop untuk membersihkan tanpa gangguan. Untuk informasi selengkapnya, lihat Cara yang Tepat untuk Menangani Peristiwa OnStop Azure (blog).

Azure Cosmos DB

Membaca data gagal.

Deteksi. Tangkap System.Net.Http.HttpRequestException atau Microsoft.Azure.Documents.DocumentClientException.

Pemulihan:

• SDK secara otomatis mencoba kembali upaya yang gagal. Untuk mengatur jumlah percobaan ulang dan waktu tunggu maksimum, konfigurasikan ConnectionPolicy.RetryOptions. Pengecualian yang diajukan klien berada di luar kebijakan percobaan kembali atau bukan kesalahan sementara.
• Jika Azure Cosmos DB membatasi klien, azure Cosmos DB mengembalikan kesalahan HTTP 429. Periksa kode status di DocumentClientException. Jika Anda mendapatkan kesalahan 429 secara konsisten, pertimbangkan untuk meningkatkan nilai throughput koleksi.
  • Jika Anda menggunakan API MongoDB, layanan akan mengembalikan kode kesalahan 16500 saat dibatasi.
• Aktifkan redundansi zona saat Anda bekerja dengan wilayah yang mendukung zona ketersediaan. Saat Anda menggunakan redundansi zona, Azure Cosmos DB secara otomatis melakukan failover jika terjadi pemadaman zona. Untuk informasi selengkapnya, lihat Mencapai ketersediaan tinggi dengan Azure Cosmos DB.
• Jika Anda merancang solusi multi-wilayah, replikasi database Azure Cosmos DB di dua wilayah atau lebih. Semua replika dapat dibaca. Dengan menggunakan SDK klien, tentukan parameter PreferredLocations. Ini adalah daftar urutan wilayah Azure. Semua bacaan akan dikirim ke wilayah pertama yang tersedia di daftar . Jika permintaan gagal, klien akan mencoba wilayah lain dalam daftar, secara berurutan. Untuk informasi selengkapnya, lihat Cara menyiapkan distribusi global di Azure Cosmos DB for NoSQL.

Diagnostik. Catat semua kesalahan di sisi klien.

Membaca data gagal.

Deteksi. Tangkap System.Net.Http.HttpRequestException atau Microsoft.Azure.Documents.DocumentClientException.

Pemulihan:

• SDK secara otomatis mencoba kembali upaya yang gagal. Untuk mengatur jumlah percobaan ulang dan waktu tunggu maksimum, konfigurasikan ConnectionPolicy.RetryOptions. Pengecualian yang diajukan klien berada di luar kebijakan percobaan kembali atau bukan kesalahan sementara.
• Jika Azure Cosmos DB membatasi klien, azure Cosmos DB mengembalikan kesalahan HTTP 429. Periksa kode status di DocumentClientException. Jika Anda mendapatkan kesalahan 429 secara konsisten, pertimbangkan untuk meningkatkan nilai throughput koleksi.
• Aktifkan redundansi zona saat Anda bekerja dengan wilayah yang mendukung zona ketersediaan. Saat Anda menggunakan redundansi zona, Azure Cosmos DB secara sinkron mereplikasi semua penulisan di seluruh zona ketersediaan. Untuk informasi selengkapnya, lihat Mencapai ketersediaan tinggi dengan Azure Cosmos DB.
• Jika Anda merancang solusi multi-wilayah, replikasi database Azure Cosmos DB di dua wilayah atau lebih. Jika wilayah utama gagal, wilayah lain akan dipromosikan untuk menulis. Anda juga dapat memicu failover secara manual. SDK melakukan penemuan dan perutean otomatis, sehingga kode aplikasi terus berfungsi setelah failover. Selama periode failover (biasanya dalam hitungan menit), operasi tulis akan memiliki latensi yang lebih tinggi, karena SDK menemukan wilayah tulis baru. Untuk informasi selengkapnya, lihat Cara menyiapkan distribusi global di Azure Cosmos DB for NoSQL.
• Sebagai fallback, pertahankan dokumen ke antrean cadangan, dan proses antrean nanti.

Diagnostik. Catat semua kesalahan di sisi klien.

Antrean Penyimpanan

Menulis pesan ke penyimpanan Azure Queue gagal terus-menerus.

Deteksi. Setelah N upaya percobaan ulang, operasi tulis masih gagal.

Pemulihan:

• Simpan data dalam cache lokal, dan teruskan penulisan ke penyimpanan nanti, saat layanan tersedia.
• Buat antrean sekunder, dan tulis ke antrean tersebut jika antrean utama tidak tersedia.

Diagnostik. Gunakan metrik penyimpanan.

Aplikasi tidak dapat memproses pesan tertentu dari antrean.

Deteksi. Khusus aplikasi. Misalnya, pesan berisi data yang tidak valid, atau logika bisnis gagal karena alasan tertentu.

Pemulihan:

Pindahkan pesan ke antrean terpisah. Jalankan proses terpisah untuk memeriksa pesan dalam antrean tersebut.

Pertimbangkan untuk menggunakan antrean Olahpesan Azure Service Bus, yang menyediakan fungsionalitas antrean surat gagal untuk tujuan ini.

Catatan

Jika Anda menggunakan antrean Storage dengan WebJobs, SDK WebJobs menyediakan penanganan pesan racun bawaan. Lihat Cara menggunakan penyimpanan antrean Azure dengan SDK WebJobs.

Diagnostik. Gunakan pengelogan aplikasi.

Azure Cache untuk Redis

Membaca dari cache gagal.

Deteksi. Tangkap StackExchange.Redis.RedisConnectionException.

Pemulihan:

1. Coba lagi pada kegagalan sementara. Azure Cache for Redis mendukung coba ulang bawaan. Untuk informasi selengkapnya, lihat Panduan percobaan ulang Azure Cache for Redis.
2. Perlakukan kegagalan bukan sementara sebagai cache yang hilang, dan kembalikan ke sumber data asli.

Diagnostik. Gunakan diagnostik Azure Cache for Redis.

Menulis ke cache gagal.

Deteksi. Tangkap StackExchange.Redis.RedisConnectionException.

Pemulihan:

1. Coba lagi pada kegagalan sementara. Azure Cache for Redis mendukung coba ulang bawaan. Untuk informasi selengkapnya, lihat Panduan percobaan ulang Azure Cache for Redis.
2. Jika kesalahan bukan sementara, abaikan dan biarkan transaksi lain menulis ke cache nanti.

Diagnostik. Gunakan diagnostik Azure Cache for Redis.

SQL Database

Tidak dapat terhubung ke database di wilayah utama.

Deteksi. Koneksi gagal.

Pemulihan:

• Aktifkan redundansi zona. Dengan mengaktifkan redundansi zona, Azure SQL Database secara otomatis mereplikasi tulisan Anda di beberapa zona ketersediaan Azure dalam wilayah yang didukung. Untuk informasi selengkapnya, lihat Ketersediaan zona redundan.

• Aktifkan replikasi geografis. Jika Anda merancang solusi multi-wilayah, pertimbangkan untuk mengaktifkan replikasi geografis aktif SQL Database.

  Prasyarat: Database harus dikonfigurasi untuk replikasi geografis aktif. Lihat Replikasi Geografis Aktif SQL Database.

  • Untuk kueri, baca dari replika sekunder.
  • Untuk sisipan dan pembaruan, alihkan ke replika sekunder secara manual. Lihat Memulai failover yang direncanakan atau yang tidak direncanakan untuk Azure SQL Database.

  Replika menggunakan string koneksi yang berbeda, jadi Anda perlu memperbarui string koneksi di aplikasi Anda.

Klien kehabisan koneksi di kumpulan koneksi.

Deteksi. Tangkap kesalahan System.InvalidOperationException.

Pemulihan:

• Coba lagi operasi.
• Sebagai rencana mitigasi, pisahkan kumpulan koneksi untuk setiap kasus penggunaan, sehingga satu kasus penggunaan tidak dapat mendominasi semua koneksi.
• Tingkatkan kumpulan koneksi maksimum.

Diagnostik. Log aplikasi.

Batas koneksi database tercapai.

Deteksi. Azure SQL Database membatasi jumlah pekerja, login, dan sesi bersamaan. Batas tergantung pada tingkat layanan. Untuk informasi selengkapnya, lihat Batas sumber daya Azure SQL Database.

Untuk mendeteksi kesalahan ini, tangkap System.Data.SqlClient.SqlException dan periksa nilai SqlException.Number untuk kode kesalahan SQL. Untuk daftar kode kesalahan yang relevan, lihat kode kesalahan SQL untuk aplikasi klien SQL Database: Kesalahan koneksi database dan masalah lainnya.

Pemulihan. Kesalahan ini dianggap sementara, sehingga percobaan kembali dapat menyelesaikan masalah. Jika Anda terus menemukan kesalahan ini, pertimbangkan untuk menskalakan database.

Diagnostik. - Kueri sys.event_log mengembalikan koneksi database yang berhasil, kegagalan koneksi, dan kebuntuan.

• Buat aturan peringatan untuk koneksi yang gagal.
• Aktifkan audit SQL Database dan periksa login yang gagal.

Layanan Pesan Bus

Membaca pesan dari antrean Bus Layanan gagal.

Deteksi. Tangkap pengecualian dari SDK klien. Kelas dasar untuk pengecualian Bus Layanan adalah MessagingException. Jika kesalahan bersifat sementara, properti IsTransient benar.

Untuk informasi selengkapnya, lihat Pengecualian olahpesan Bus Layanan.

Pemulihan:

1. Coba lagi pada kegagalan sementara. Lihat Panduan coba ulang Bus Layanan.
2. Pesan yang tidak dapat dikirim ke penerima mana pun ditempatkan dalam antrean surat gagal. Gunakan antrean ini untuk melihat pesan mana yang tidak dapat diterima. Tidak ada pembersihan otomatis dari antrean surat gagal. Pesan tetap ada hingga Anda mengambilnya secara eksplisit. Lihat Gambaran umum antrean surat gagal Bus Layanan.

Membaca pesan ke antrean Bus Layanan gagal.

Deteksi. Tangkap pengecualian dari SDK klien. Kelas dasar untuk pengecualian Bus Layanan adalah MessagingException. Jika kesalahan bersifat sementara, properti IsTransient benar.

Untuk informasi selengkapnya, lihat Pengecualian olahpesan Bus Layanan.

Pemulihan:

• Klien Bus Layanan secara otomatis mencoba kembali setelah kesalahan sementara. Secara default, ini menggunakan back-off eksponensial. Setelah jumlah percobaan ulang maksimum atau periode batas waktu maksimum, klien memberikan pengecualian. Untuk informasi selengkapnya, lihat Pedoman coba ulang Bus Layanan.

• Jika kuota antrean terlampaui, klien akan melempar QuotaExceededException. Pesan pengecualian memberikan detail lebih lanjut. Hapus beberapa pesan dari antrean sebelum mencoba kembali, dan pertimbangkan untuk menggunakan pola Circuit Breaker untuk menghindari percobaan ulang lanjutan saat kuota terlampaui. Selain itu, pastikan properti BrokeredMessage.TimeToLive tidak diatur terlalu tinggi.

• Dalam suatu wilayah, ketahanan dapat ditingkatkan dengan menggunakan antrean atau topik yang dipartisi. Antrean atau topik yang tidak dipartisi ditetapkan ke satu penyimpanan olahpesan. Jika penyimpanan olahpesan ini tidak tersedia, semua operasi pada antrean atau topik tersebut akan gagal. Antrean atau topik yang dipartisi dibuatkan partisi di beberapa penyimpanan olahpesan.

• Gunakan redundansi zona untuk mereplikasi perubahan secara otomatis di antara beberapa zona ketersediaan. Jika satu zona ketersediaan gagal, failover terjadi secara otomatis. Untuk informasi selengkapnya, lihat Praktik terbaik untuk mengisolasi aplikasi terhadap pemadaman dan bencana Bus Layanan.

• Jika Anda merancang solusi multi-wilayah, buat dua Bus Layanan namespace layanan di wilayah yang berbeda, dan replikasi pesan. Anda dapat menggunakan replikasi aktif atau replikasi pasif.

  • Replikasi aktif: Klien mengirim setiap pesan ke kedua antrean. Penerima mendengarkan pada kedua antrean. Tandai pesan dengan pengidentifikasi unik, sehingga klien dapat membuang pesan duplikat.
  • Replikasi pasif: Klien mengirim pesan ke satu antrean. Jika ada kesalahan, klien masuk ke antrean lain. Penerima mendengarkan pada kedua antrean. Pendekatan ini mengurangi jumlah pesan duplikat yang dikirim. Namun, penerima masih harus menangani pesan duplikat.

  Untuk informasi selengkapnya, lihat sampel GeoReplication dan Praktik terbaik untuk mengisolasi aplikasi terhadap pemadaman dan bencana Bus Layanan.

Pesan duplikat.

Deteksi. Periksa properti MessageId dan DeliveryCount pesan.

Pemulihan:

• Jika memungkinkan, rancang operasi pemrosesan pesan Anda menjadi idempoten. Jika tidak, simpan ID pesan dari pesan yang sudah diproses, dan periksa ID sebelum memproses pesan.

• Aktifkan deteksi duplikat, dengan membuat antrean dengan mengatur RequiresDuplicateDetection ke true. Dengan pengaturan ini, Bus Layanan secara otomatis menghapus pesan apa pun yang dikirim dengan MessageId yang sama dengan pesan sebelumnya. Berikut hal-hal yang perlu diketahui:

  • Pengaturan ini mencegah pesan duplikat dimasukkan ke dalam antrean. Ini tidak mencegah penerima memproses pesan yang sama lebih dari sekali.
  • Deteksi duplikat memiliki jendela waktu. Jika duplikat dikirim di luar jendela ini, ini tidak akan terdeteksi.

Diagnostik. Catat pesan duplikat.

Aplikasi tidak dapat memproses pesan tertentu dari antrean.

Deteksi. Khusus aplikasi. Misalnya, pesan berisi data yang tidak valid, atau logika bisnis gagal karena alasan tertentu.

Pemulihan:

Ada dua mode kegagalan yang perlu dipertimbangkan.

• Penerima mendeteksi kegagalan. Dalam hal ini, pindahkan pesan ke antrean surat gagal. Selanjutnya, jalankan proses terpisah untuk memeriksa pesan dalam antrean surat gagal.
• Penerima gagal di tengah pemrosesan pesan — misalnya, karena pengecualian yang tidak ditangani. Untuk menangani kasus ini, gunakan mode PeekLock. Dalam mode ini, jika kunci kedaluwarsa, pesan akan tersedia untuk penerima lain. Jika pesan melebihi jumlah pengiriman maksimum atau waktu untuk aktif, pesan secara otomatis dipindahkan ke antrean surat gagal.

Untuk informasi selengkapnya, lihat Ringkasan antrean dead-letter Service Bus.

Diagnostik. Setiap kali aplikasi memindahkan pesan ke antrean surat gagal, tulis peristiwa ke log aplikasi.

Penyimpanan

Menulis data untuk Azure Storage gagal

Deteksi. Klien menerima kesalahan saat menulis.

Pemulihan:

1. Coba kembali operasi, untuk pulih dari kegagalan sementara. Kebijakan coba ulang di SDK klien menangani ini secara otomatis.

2. Terapkan pola Circuit Breaker untuk menghindari penyimpanan dalam jumlah banyak.

3. Jika N upaya percobaan ulang gagal, lakukan fallback tanpa gangguan. Contohnya:

   • Simpan data dalam cache lokal, dan teruskan penulisan ke penyimpanan nanti, saat layanan tersedia.
   • Jika tindakan tulis berada dalam cakupan transaksional, kompensasikan transaksi.

Diagnostik. Gunakan metrik penyimpanan.

Membaca data dari Azure Storage gagal.

Deteksi. Klien menerima kesalahan saat membaca.

Pemulihan:

1. Coba kembali operasi, untuk pulih dari kegagalan sementara. Kebijakan coba ulang di SDK klien menangani ini secara otomatis.
2. Untuk penyimpanan RA-GRS, jika membaca dari titik akhir utama gagal, cobalah membaca dari titik akhir sekunder. SDK klien dapat menangani ini secara otomatis. Lihat replikasi Azure Storage.
3. Jika N upaya percobaan ulang gagal, ambil fallback untuk menurunkan tanpa gangguan. Misalnya, jika gambar produk tidak dapat diambil dari penyimpanan, tampilkan gambar tempat penampung umum.

Diagnostik. Gunakan metrik penyimpanan.

Mesin virtual

Koneksi ke VM backend gagal.

Deteksi. Kesalahan koneksi jaringan.

Pemulihan:

• Sebarkan setidaknya dua VM backend dalam rangkaian ketersediaan, di belakang penyeimbang beban.
• Jika kesalahan koneksi bersifat sementara, terkadang TCP akan berhasil mencoba kembali mengirim pesan.
• Menerapkan kebijakan coba ulang dalam aplikasi.
• Untuk kesalahan persisten atau bukan transparan, terapkan pola Circuit Breaker.
• Jika VM panggilan melebihi batas keluar jaringan, antrean keluar akan terisi. Jika antrean keluar secara konsisten penuh, pertimbangkan untuk meningkatkan skala.

Diagnostik. Catat peristiwa di batas layanan.

Instans VM menjadi tidak tersedia atau tidak sehat.

Deteksi. Konfigurasikan probe kesehatan Load Balancer yang menandakan apakah instans VM sehat. Probe harus memeriksa apakah fungsi kritis merespons dengan benar.

Pemulihan. Untuk setiap tingkat aplikasi, masukkan beberapa instans VM ke kumpulan ketersediaan yang sama, dan tempatkan penyeimbang beban di depan VM. Jika probe kesehatan gagal, Load Balancer berhenti mengirim koneksi baru ke instans yang tidak sehat.

Diagnostik. - Gunakan analitik log Load Balancer.

• Konfigurasikan sistem pemantauan Anda untuk memantau semua titik akhir pemantauan kesehatan.

Operator secara tidak sengaja mematikan VM.

Deteksi. T/A

Pemulihan. Atur kunci sumber daya dengan tingkat ReadOnly. Lihat Mengunci sumber daya dengan Azure Resource Manager.

Diagnostik. Gunakan Log Aktivitas Azure.

WebJobs

Pekerjaan berkelanjutan berhenti berjalan saat host SCM idle.

Deteksi. Berikan token pembatalan ke fungsi WebJob. Untuk informasi selengkapnya, lihat Penonaktifan lancar.

Pemulihan. Aktifkan pengaturan Always On di aplikasi web. Untuk informasi selengkapnya, lihat Menjalankan Tugas latar belakang dengan WebJobs.

Desain aplikasi

Aplikasi tidak dapat menangani lonjakan permintaan masuk.

Deteksi. Tergantung pada aplikasi. Gejala khas:

• Situs web mulai mengembalikan kode kesalahan HTTP 5xx.
• Layanan dependen, seperti database atau penyimpanan, mulai membatasi permintaan. Cari kesalahan HTTP seperti HTTP 429 (Too Many Requests), tergantung pada layanan.
• Panjang antrean HTTP meningkat.

Pemulihan:

• Luaskan skalakan untuk menangani peningkatan beban.

• Mitigasi kegagalan agar kegagalan kaskade tidak mengganggu seluruh aplikasi. Strategi mitigasi termasuk:

  • Terapkan pola Pembatasan untuk menghindari sistem backend yang berlebihan.
  • Gunakan tingkatan beban berbasis antrean untuk membuat buffer permintaan dan memprosesnya dengan kecepatan yang sesuai.
  • Prioritaskan klien tertentu. Misalnya, jika aplikasi memiliki tingkat gratis dan berbayar, batasi pelanggan di tingkat gratis, tetapi bukan pelanggan berbayar. Lihat Pola antrean prioritas.

Diagnostik. Gunakan Pengelogan diagnostik App Service. Gunakan layanan seperti Azure Log Analytics, Application Insights, atau New Relic untuk membantu memahami log diagnostik.

Sampel tersedia di sini. Ini menggunakan Polly untuk pengecualian ini:

• 429 - Pembatasan
• 408 - Waktu habis
• 401 - Tidak sah
• 503 or 5xx - Layanan tidak tersedia

Salah satu operasi dalam alur kerja atau transaksi terdistribusi gagal.

Deteksi. Kegagalan masih terjadi setelah N upaya percobaan ulang.

Pemulihan:

• Sebagai rencana mitigasi, terapkan pola Pengawas Agen Penjadwal untuk mengelola seluruh alur kerja.
• Jangan coba kembali saat waktu habis. Ada tingkat keberhasilan yang rendah untuk kesalahan ini.
• Antrean bekerja, untuk mencoba kembali nanti.

Diagnostik. Catat semua operasi (berhasil dan gagal), termasuk tindakan kompensasi. Gunakan ID korelasi, sehingga Anda dapat melacak semua operasi dalam transaksi yang sama.

Panggilan ke layanan jarak jauh gagal.

Deteksi. Kode Galat HTTP.

Pemulihan:

1. Coba lagi pada kegagalan sementara.
2. Jika panggilan gagal setelah N upaya, ambil tindakan fallback. (Khusus aplikasi.)
3. Terapkan pola Circuit Breaker untuk menghindari kegagalan kaskade.

Diagnostik. Catat semua kegagalan panggilan jarak jauh.

Langkah berikutnya

Lihat Ketahanan dan dependensi dalam Azure Well-Architected Framework. Membangun pemulihan kegagalan ke dalam sistem harus menjadi bagian dari arsitektur dan fase desain dari awal untuk menghindari risiko kegagalan.