REL11-BP03 Mengotomatiskan penyembuhan pada semua lapisan - AWS Kerangka Well-Architected

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

REL11-BP03 Mengotomatiskan penyembuhan pada semua lapisan

Setelah kegagalan dideteksi, gunakan kemampuan otomatis untuk melakukan tindakan perbaikan. Degradasi dapat dipulihkan secara otomatis melalui mekanisme servis internal atau memerlukan sumber daya untuk dimulai ulang atau dihapus melalui tindakan remediasi.

Untuk aplikasi yang dikelola secara mandiri dan perbaikan lintas-Wilayah, desain pemulihan dan proses perbaikan otomatis dapat ditarik dari praktik terbaik yang ada sekarang.

Kemampuan untuk memulai ulang atau menghapus sumber daya adalah alat yang penting untuk melakukan remediasi kegagalan. Salah satu praktik terbaiknya adalah membuat layanan menjadi stateless, jika memungkinkan. Praktik ini mencegah hilangnya data atau ketersediaan pada saat sumber daya dimulai ulang. Di cloud, Anda dapat (dan umumnya harus) mengganti seluruh sumber daya (misalnya, instans komputasi atau fungsi nirserver) sebagai bagian dari proses mulai ulang. Tindakan memulai ulang itu sendiri adalah cara yang mudah dan andal untuk pulih dari kegagalan. Ada berbagai jenis kegagalan yang terjadi di dalam beban kerja. Kegagalan dapat terjadi di perangkat keras, perangkat lunak, komunikasi, dan operasi.

Memulai ulang atau mencoba ulang juga berlaku untuk permintaan-permintaan jaringan. Terapkan pendekatan pemulihan yang sama terhadap peristiwa waktu habis jaringan maupun kegagalan dependensi di mana dependensi menunjukkan kesalahan. Kedua peristiwa tersebut memiliki efek yang serupa terhadap sistem, sehingga alih-alih berupaya untuk menjadikan masing-masing sebagai kasus spesial, terapkan strategi serupa berupa coba ulang terbatas dengan penundaan eksponensial dan jitter. Kemampuan untuk memulai ulang sebuah adalah mekanisme pemulihan yang disertakan dalam komputasi berorientasi pemulihan dan arsitektur klaster ketersediaan tinggi.

Hasil yang diinginkan: Tindakan otomatis dilakukan untuk meremediasi deteksi kegagalan.

Anti-pola umum:

  • Menyediakan sumber daya tanpa penskalaan otomatis.

  • Melakukan deployment aplikasi di instans atau kontainer secara terpisah.

  • Melakukan deployment aplikasi yang tidak dapat dilakukan ke beberapa lokasi tanpa menggunakan pemulihan otomatis.

  • Memulihkan secara manual aplikasi yang gagal dipulihkan oleh penskalaan otomatis dan pemulihan otomatis.

  • Tidak ada otomatisasi untuk failover basis data.

  • Tidak ada metode otomatis untuk mengalihkan rute lalu lintas ke titik akhir baru.

  • Tidak ada replikasi penyimpanan.

Manfaat menerapkan praktik terbaik ini: Pemulihan otomatis dapat mengurangi waktu rata-rata pemulihan dan meningkatkan ketersediaan Anda.

Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan: Tinggi

Panduan implementasi

Desain untuk Amazon EKS atau layanan Kubernetes lainnya harus mencakup replika minimum dan maksimum atau set stateful serta ukuran cluster dan grup node minimum. Mekanisme ini menyediakan jumlah minimum sumber daya pemrosesan yang tersedia secara terus-menerus sambil secara otomatis memulihkan kegagalan apa pun menggunakan bidang kontrol Kubernetes.

Pola desain yang diakses melalui penyeimbang beban menggunakan klaster komputasi harus memanfaatkan grup Auto Scaling (penskalaan otomatis). Elastic Load Balancing (ELB) secara otomatis mendistribusikan lalu lintas aplikasi yang masuk ke beberapa target dan peralatan virtual dalam satu atau beberapa Availability Zones (). AZs

Desain berbasis komputasi terklaster yang tidak menggunakan penyeimbangan beban harus dirancang ukurannya untuk kehilangan setidaknya satu simpul. Dengan begitu, layanan dapat terus berjalan dalam kapasitas yang kemungkinan lebih rendah saat layanan memulihkan simpul baru. Contoh layanan adalah Mongo, DynamoDB Accelerator, Amazon Redshift, Amazon, Cassandra, KafkaMSK, EMR -, Couchbase,, dan Amazon Service. EC2 ELK OpenSearch Banyak dari layanan-layanan ini dapat dirancang dengan fitur pemulihan otomatis tambahan. Beberapa teknologi klaster harus menghasilkan peringatan atas hilangnya sebuah simpul yang memicu alur kerja otomatis atau manual untuk membuat ulang simpul baru. Alur kerja ini dapat diotomatisasi menggunakan AWS Systems Manager untuk memulihkan masalah dengan cepat.

Amazon EventBridge dapat digunakan untuk memantau dan memfilter peristiwa seperti CloudWatch alarm atau perubahan status di AWS layanan lain. Berdasarkan informasi peristiwa, kemudian dapat memanggil, Systems Manager Automation AWS Lambda, atau target lain untuk menjalankan logika remediasi khusus pada beban kerja Anda. EC2Auto Scaling Amazon dapat dikonfigurasi untuk memeriksa kesehatan EC2 misalnya. Jika instance dalam status apa pun selain berjalan, atau jika status sistem terganggu, Amazon EC2 Auto Scaling menganggap instance tersebut tidak sehat dan meluncurkan instance pengganti. Untuk penggantian skala besar (seperti hilangnya seluruh Zona Ketersediaan), sebaiknya gunakan stabilitas statis karena ketersediaannya yang tinggi.

Langkah-langkah implementasi

  • Gunakan grup Auto Scaling (penskalaan otomatis) untuk melakukan deployment tingkatan di sebuah beban kerja. Penskalaan otomatis dapat melakukan pemulihan mandiri pada aplikasi tanpa status, dan menambahkan atau menghapus kapasitas.

  • Untuk instans komputasi yang disebutkan sebelumnya, gunakan penyeimbangan beban dan pilih jenis penyeimbang beban yang sesuai.

  • Pertimbangkan penyembuhan untuk AmazonRDS. Dengan instans siaga, konfigurasikan untuk failover otomatis ke instans siaga tersebut. Untuk Amazon RDS Read Replica, alur kerja otomatis diperlukan untuk membuat replika baca utama.

  • Menerapkan pemulihan otomatis pada EC2 instance yang memiliki aplikasi yang digunakan yang tidak dapat digunakan di beberapa lokasi, dan dapat mentolerir reboot setelah kegagalan. Pemulihan otomatis dapat digunakan untuk mengganti perangkat keras yang mengalami kegagalan dan memulai ulang instans ketika aplikasi tidak dapat diterapkan di beberapa lokasi. Metadata instans dan alamat IP terkait disimpan, serta EBSvolume dan titik mount ke Amazon Elastic File System atau FileSystems untuk Lustre dan Windows. Dengan menggunakan AWS OpsWorks, Anda dapat mengonfigurasi penyembuhan otomatis EC2 instance di tingkat lapisan.

  • Implementasikan pemulihan otomatis dengan menggunakan AWS Step Functions dan AWS Lambda ketika Anda tidak dapat menggunakan penskalaan otomatis atau pemulihan otomatis, atau ketika pemulihan otomatis gagal. Ketika Anda tidak dapat menggunakan penskalaan otomatis, dan tidak dapat menggunakan pemulihan otomatis atau pemulihan otomatis gagal, Anda dapat mengotomatiskan penyembuhan menggunakan AWS Step Functions dan. AWS Lambda

  • Amazon EventBridge dapat digunakan untuk memantau dan memfilter peristiwa seperti CloudWatchalarm atau perubahan status di AWS layanan lain. Berdasarkan informasi peristiwa, layanan ini kemudian dapat menginvokasi AWS Lambda (atau target-target lainnya) untuk menjalankan logika remediasi kustom pada beban kerja Anda.

Sumber daya

Praktik-praktik terbaik terkait:

Dokumen terkait:

Video terkait:

Contoh terkait:

Alat terkait: