Rekomendasi untuk penyembuhan diri dan pelestarian diri

  • Artikel

Berlaku untuk rekomendasi daftar periksa Keandalan Azure Well-Architected Framework ini:

RE:07 Memperkuat ketahanan dan pemulihan beban kerja Anda dengan menerapkan langkah-langkah pelestarian diri dan penyembuhan diri. Bangun kemampuan ke dalam solusi dengan menggunakan pola keandalan berbasis infrastruktur dan pola desain berbasis perangkat lunak untuk menangani kegagalan komponen dan kesalahan sementara. Bangun kemampuan ke dalam sistem untuk mendeteksi kegagalan komponen solusi dan secara otomatis memulai tindakan korektif saat beban kerja terus beroperasi dengan fungsionalitas penuh atau berkurang.

Panduan terkait:Pekerjaan latar belakang | Kesalahan sementara

Panduan ini menjelaskan rekomendasi untuk membangun kemampuan penyembuhan diri dan pelestarian diri ke dalam arsitektur aplikasi Anda untuk mengoptimalkan keandalan.

Kemampuan pelestarian mandiri menambah ketahanan pada beban kerja Anda. Mereka mengurangi kemungkinan pemadaman penuh dan memungkinkan beban kerja Anda beroperasi dalam keadaan terdegradasi saat komponen yang gagal dipulihkan. Kemampuan penyembuhan diri membantu Anda menghindari waktu henti dengan membangun deteksi kegagalan dan tindakan korektif otomatis untuk merespons berbagai jenis kegagalan.

Panduan ini menjelaskan pola desain yang berfokus pada pelestarian diri dan penyembuhan diri. Masukkan ke dalam beban kerja Anda untuk memperkuat ketahanan dan pemulihannya. Jika Anda tidak menerapkan pola, aplikasi Anda berisiko mengalami kegagalan saat masalah yang tidak dapat dihindari muncul.

Definisi

Istilah Definisi
Penyembuhan mandiri Kemampuan beban kerja Anda untuk menyelesaikan masalah secara otomatis dengan memulihkan komponen yang terpengaruh dan jika diperlukan, mengalihkan ke infrastruktur redundan.
Pelestarian mandiri Kemampuan beban kerja Anda untuk tangguh terhadap potensi masalah.

Strategi desain utama

Panduan pelestarian mandiri

Untuk merancang beban kerja Anda untuk pelestarian mandiri, ikuti pola desain arsitektur infrastruktur dan aplikasi untuk mengoptimalkan ketahanan beban kerja Anda. Untuk meminimalkan kemungkinan mengalami pemadaman aplikasi penuh, tingkatkan ketahanan solusi Anda dengan menghilangkan satu titik kegagalan dan meminimalkan radius ledakan kegagalan. Pendekatan desain dalam artikel ini menyediakan beberapa opsi untuk memperkuat ketahanan beban kerja Anda dan memenuhi target keandalan yang ditentukan beban kerja Anda.

Panduan dan pola desain infrastruktur

Pada tingkat infrastruktur, desain arsitektur yang berlebihan harus mendukung alur penting Anda, dengan sumber daya yang disebarkan di seluruh zona ketersediaan atau wilayah. Terapkan autoscaling jika memungkinkan. Penskalaan otomatis membantu melindungi beban kerja Anda dari semburan aktivitas yang tidak terduga, semakin menguatkan infrastruktur Anda.

Gunakan pola Stempel Penyebaran atau pola Bulkhead untuk meminimalkan radius ledakan saat masalah muncul. Pola-pola ini membantu menjaga beban kerja Anda tetap tersedia jika komponen individual tidak tersedia. Gunakan pola desain aplikasi berikut dalam kombinasi dengan strategi autoscaling Anda.

  • Pola Stempel Penyebaran: Menyediakan, mengelola, dan memantau berbagai grup sumber daya untuk menghosting dan mengoperasikan beberapa beban kerja atau penyewa. Setiap salinan individu disebut stempel, atau terkadang unit layanan, unit skala, atau sel.

  • Pola massal: Instans layanan partisi ke dalam grup yang berbeda, yang dikenal sebagai kumpulan, berdasarkan beban konsumen dan persyaratan ketersediaan. Desain ini membantu mengisolasi kegagalan dan memungkinkan Anda mempertahankan fungsionalitas layanan untuk beberapa konsumen, bahkan selama kegagalan.

Panduan dan pola desain aplikasi

Hindari membangun aplikasi monolitik dalam desain aplikasi Anda. Gunakan layanan atau layanan mikro yang digabungkan secara longgar yang berkomunikasi satu sama lain melalui standar yang terdefinisi dengan baik untuk mengurangi risiko masalah ekstensif ketika kerusakan terjadi pada satu komponen. Misalnya, Anda dapat menstandarkan penggunaan bus layanan untuk menangani semua komunikasi asinkron. Menstandarkan protokol komunikasi memastikan bahwa desain aplikasi konsisten dan disederhanakan, yang membuat beban kerja lebih andal dan lebih mudah untuk memecahkan masalah ketika kegagalan fungsi terjadi. Ketika praktis, lebih suka komunikasi asinkron antara komponen daripada komunikasi sinkron untuk meminimalkan masalah waktu habis, seperti dead-lettering. Pola desain berikut membantu Anda mengatur beban kerja dan menentukan komunikasi antar komponen dengan cara yang paling sesuai dengan kebutuhan bisnis Anda.

  • Pola duta: Pisahkan logika bisnis Anda dari kode jaringan dan logika ketahanan Anda. Membuat layanan pembantu yang mengirim permintaan jaringan atas nama layanan konsumen atau aplikasi. Anda dapat menggunakan pola ini untuk menerapkan mekanisme coba lagi atau pemutusan sirkuit.

  • Pola Request-Reply asinkron: Memisahkan pemrosesan back-end dari host front-end jika pemrosesan back-end perlu asinkron, tetapi ujung depan membutuhkan respons yang jelas.

  • Pola Cache-Aside: Memuat data sesuai permintaan dari penyimpanan data ke dalam cache. Pola ini dapat meningkatkan performa dan membantu menjaga konsistensi antara data yang disimpan di cache dan data yang ada di penyimpanan data yang mendasar.

  • Pola Pemutus Arus: Gunakan pemutus arus untuk secara proaktif menentukan apakah akan mengizinkan operasi untuk melanjutkan atau mengembalikan pengecualian berdasarkan jumlah kegagalan terbaru.

  • Pola Pemeriksaan Klaim: Pisahkan pesan besar menjadi pemeriksaan klaim dan payload. Kirim pemeriksaan klaim ke platform olahpesan dan simpan payload di layanan eksternal. Pola ini memungkinkan pesan besar diproses sambil melindungi bus pesan dan menjaga klien tidak kewalahan atau melambat.

  • Pola Konsumen yang Bersaing: Memungkinkan beberapa konsumen bersamaan untuk memproses pesan yang diterima di saluran olahpesan yang sama. Sistem dapat memproses beberapa pesan secara bersamaan, yang mengoptimalkan throughput, meningkatkan skalabilitas dan ketersediaan, dan menyeimbangkan beban kerja.

  • Mengonfigurasi batas waktu permintaan: Mengonfigurasi batas waktu permintaan untuk panggilan ke layanan atau database. Batas waktu koneksi database biasanya diatur ke 30 detik.

  • Pola Gatekeeper: Lindungi aplikasi dan layanan dengan menggunakan instans host khusus untuk perantara permintaan antara klien dan aplikasi atau layanan. Broker memvalidasi dan membersihkan permintaan dan dapat memberikan lapisan keamanan tambahan untuk membatasi permukaan serangan sistem.

  • Pola Load Leveling Berbasis Antrean: Memisahkan tugas dari layanan dalam solusi Anda dengan menggunakan antrean di antaranya sehingga masing-masing dapat berjalan secara asinkron. Gunakan antrean sebagai buffer antara tugas dan layanan yang dipanggilnya untuk membantu melancarkan beban berat terputus-putus yang dapat menyebabkan layanan gagal atau tugas kehabisan waktu. Pola ini dapat membantu meminimalkan efek puncak permintaan pada ketersediaan dan responsivitas untuk tugas dan layanan.

  • Pola pembatasan: Mengontrol konsumsi sumber daya yang digunakan oleh instans aplikasi, penyewa individual, atau seluruh layanan. Pola ini memungkinkan sistem untuk terus berfungsi dan memenuhi perjanjian tingkat layanan (SLA), bahkan ketika peningkatan permintaan menempatkan beban ekstrem pada sumber daya.

  • Pola Penanganan Kesalahan Sementara dan pola Coba Lagi: Terapkan strategi untuk menangani kegagalan sementara untuk memberikan ketahanan dalam beban kerja Anda. Kegagalan sementara adalah kejadian normal dan diharapkan di lingkungan cloud. Penyebab umum kesalahan sementara termasuk kehilangan konektivitas jaringan sesaat, koneksi database yang terputus, atau batas waktu saat layanan sibuk. Untuk informasi selengkapnya tentang mengembangkan strategi coba lagi, lihat panduan penanganan kesalahan sementara dalam seri ini.

Pekerjaan latar belakang

Pekerjaan latar belakang adalah cara yang efektif untuk meningkatkan keandalan sistem dengan memisahkan tugas dari antarmuka pengguna (UI). Terapkan tugas sebagai pekerjaan latar belakang jika tidak memerlukan input atau umpan balik pengguna dan jika tidak memengaruhi respons UI.

Contoh umum pekerjaan latar belakang adalah:

  • Pekerjaan intensif CPU, seperti melakukan perhitungan kompleks atau menganalisis model struktural.
  • Pekerjaan intensif I/O, seperti menjalankan beberapa operasi penyimpanan atau mengindeks file besar.
  • Pekerjaan batch, seperti memperbarui data secara teratur atau memproses tugas pada waktu tertentu.
  • Alur kerja yang berjalan lama, seperti menyelesaikan pesanan atau layanan dan sistem provisi.

Untuk informasi selengkapnya, lihat Rekomendasi untuk pekerjaan latar belakang.

Panduan penyembuhan diri

Untuk merancang beban kerja Anda untuk penyembuhan diri, terapkan deteksi kegagalan sehingga respons otomatis dipicu dan alur kritis pulih dengan baik. Aktifkan pengelogan untuk memberikan wawasan operasional tentang sifat kegagalan dan keberhasilan pemulihan. Pendekatan yang Anda ambil untuk mencapai penyembuhan diri untuk aliran kritis bergantung pada target keandalan yang ditentukan untuk aliran tersebut dan komponen dan dependensi alur.

Panduan desain infrastruktur

Pada tingkat infrastruktur, alur penting Anda harus didukung oleh desain arsitektur redundan dengan failover otomatis diaktifkan untuk komponen yang mendukungnya. Anda dapat mengaktifkan failover otomatis untuk jenis layanan berikut:

  • Sumber daya komputasi: Azure Virtual Machine Scale Sets dan sebagian besar layanan komputasi platform as a service (PaaS) dapat dikonfigurasi untuk failover otomatis.

  • Database: Database relasional dapat dikonfigurasi untuk failover otomatis dengan solusi seperti Azure SQL kluster failover, grup ketersediaan AlwaysOn, atau kemampuan bawaan dengan layanan PaaS. Database NoSQL memiliki kemampuan pengklusteran yang serupa dan kemampuan bawaan untuk layanan PaaS.

  • Penyimpanan: Gunakan opsi penyimpanan redundan dengan failover otomatis.

Panduan dan pola desain aplikasi

  • Memblokir aktor jahat: Jika Anda membatasi klien, itu tidak berarti bahwa klien bertindak berbahaya. Ini mungkin berarti bahwa klien melebihi kuota layanan mereka. Tetapi jika klien secara konsisten melebihi kuota mereka atau bertingkah buruk, Anda dapat memblokirnya. Tentukan proses di luar band bagi klien untuk meminta pemblokiran.

  • Pola Circuit Breaker: Jika kegagalan berlanjut setelah mekanisme coba lagi dimulai, Anda berisiko mengalami kegagalan kaskading yang diakibatkan oleh backlog panggilan yang berkembang. Pemutus arus yang dirancang untuk bekerja dengan mekanisme coba lagi membatasi risiko kegagalan kaskade dengan mencegah aplikasi berulang kali mencoba menjalankan operasi yang kemungkinan gagal.

  • Pola Kompensasi Transaksi: Jika Anda menggunakan operasi konsisten pada akhirnya yang terdiri dari serangkaian langkah, terapkan pola Compensating Transaction. Jika satu atau beberapa langkah gagal, Anda dapat menggunakan pola ini untuk membatalkan pekerjaan yang dilakukan langkah-langkah.

  • Menurun dengan baik: Terkadang Anda tidak dapat mengatasi masalah, tetapi Anda dapat memberikan fungsionalitas yang berkurang. Pertimbangkan sebuah aplikasi yang menampilkan katalog buku. Jika aplikasi tidak dapat mengambil gambar mini untuk sampul, aplikasi mungkin menampilkan gambar tempat penampung. Seluruh subsistem mungkin nonkritis untuk aplikasi tersebut. Misalnya, untuk situs web e-niaga, menunjukkan rekomendasi produk mungkin kurang penting daripada memproses pesanan. Degradasi yang anggun juga dapat mencakup operasi failover otomatis. Ketika database secara otomatis melakukan failover ke replika karena masalah dengan instans utama, performa diturunkan untuk waktu yang singkat.

  • Pola Pemilihan Pemimpin: Ketika Anda perlu mengoordinasikan tugas, gunakan pemilihan pemimpin untuk memilih koordinator sehingga satu koordinator bukan satu titik kegagalan. Jika koordinator gagal, yang baru akan dipilih. Daripada menerapkan algoritma pemilihan pemimpin dari awal, pertimbangkan solusi di luar rak, seperti ZooKeeper.

  • Pola pengujian: Sertakan pengujian pola yang Anda terapkan sebagai bagian dari prosedur pengujian standar Anda.

  • Gunakan titik pemeriksaan untuk transaksi jangka panjang: Titik pemeriksaan dapat memberikan ketahanan jika operasi yang berjalan lama gagal. Ketika operasi dimulai ulang, misalnya jika diambil oleh komputer virtual lain, operasi dapat dilanjutkan dari titik pemeriksaan terakhir. Pertimbangkan untuk menerapkan mekanisme yang merekam informasi status tentang tugas secara berkala. Simpan status ini dalam penyimpanan tahan lama yang dapat diakses oleh instans apa pun dari proses yang menjalankan tugas. Jika proses dimatikan, pekerjaan yang dilakukannya dapat dilanjutkan dari titik pemeriksaan terakhir dengan menggunakan instans lain. Ada pustaka yang menyediakan fungsionalitas ini, seperti NServiceBus dan MassTransit. Mereka secara transparan mempertahankan status, di mana interval selaras dengan pemrosesan pesan dari antrean dalam Azure Service Bus.

Tindakan penyembuhan mandiri otomatis

Pendekatan lain untuk penyembuhan diri adalah penggunaan tindakan otomatis yang dipicu oleh solusi pemantauan Anda ketika perubahan status kesehatan yang telah ditentukan sebelumnya terdeteksi. Misalnya, jika pemantauan Mendeteksi bahwa aplikasi web tidak merespons permintaan, Anda dapat membangun otomatisasi melalui skrip PowerShell untuk memulai ulang layanan aplikasi. Bergantung pada set keterampilan dan teknologi pengembangan pilihan tim Anda, gunakan webhook atau fungsi untuk membangun tindakan otomatisasi yang lebih kompleks. Lihat Arsitektur referensi otomatisasi cloud berbasis peristiwa untuk contoh penggunaan fungsi untuk merespons pembatasan database. Menggunakan tindakan otomatis dapat membantu Anda pulih dengan cepat dan meminimalkan kebutuhan intervensi manusia.

Fasilitasi Azure

Sebagian besar layanan Azure dan SDK klien menyertakan mekanisme percobaan kembali. Tetapi mereka berbeda karena setiap layanan memiliki karakteristik dan persyaratan yang berbeda, sehingga setiap mekanisme coba lagi disetel ke layanan tertentu. Untuk informasi selengkapnya, lihat Rekomendasi untuk penanganan kesalahan sementara.

Gunakan grup tindakan Azure Monitor untuk pemberitahuan, seperti email, suara atau SMS, dan untuk memicu tindakan otomatis. Saat Anda diberi tahu tentang kegagalan, picu runbook Azure Automation, Azure Event Hubs, fungsi Azure, aplikasi logika, atau webhook untuk melakukan tindakan penyembuhan otomatis.

Pertimbangan

Biasakan diri Anda dengan pertimbangan untuk setiap pola. Pastikan pola tersebut cocok untuk beban kerja dan persyaratan bisnis Anda sebelum implementasi.

Contoh

Misalnya kasus penggunaan beberapa pola, lihat pola aplikasi web yang andal untuk .NET. Ikuti langkah-langkah ini untuk menyebarkan implementasi referensi.

Daftar periksa keandalan

Lihat kumpulan rekomendasi lengkap.

Daftar periksa keandalan