REL11-BP04 Mengandalkan bidang data dan bukan bidang kendali selama pemulihan - Pilar Keandalan

REL11-BP04 Mengandalkan bidang data dan bukan bidang kendali selama pemulihan

Bidang kendali menyediakan API administratif yang digunakan untuk membuat, membaca, dan mendeskripsikan, memperbarui, menghapus, dan mencantumkan (CRUDL) sumber daya, sedangkan bidang data menangani lalu lintas layanan sehari-hari. Saat mengimplementasikan respons pemulihan atau mitigasi terhadap peristiwa yang berpotensi berdampak pada ketahanan, fokuslah pada penggunaan operasi bidang kontrol dalam jumlah minim untuk memulihkan, mengubah skala, mengembalikan, memperbaiki, atau melakukan failover layanan. Tindakan bidang data harus menggantikan aktivitas apa pun selama peristiwa degradasi ini.

Misalnya, berikut ini adalah semua tindakan bidang kendali: meluncurkan instans komputasi baru, membuat penyimpanan blok, dan mendeskripsikan layanan antrean. Saat Anda meluncurkan instans komputasi, bidang kendali harus melakukan beberapa tugas seperti menemukan host fisik dengan kapasitas, mengalokasikan antarmuka jaringan, menyiapkan volume penyimpanan blok lokal, menghasilkan kredensial, dan menambahkan aturan keamanan. Orkestrasi bidang kendali cenderung rumit.

Hasil yang diinginkan: Ketika sumber daya memasuki keadaan terganggu, sistem mampu pulih secara otomatis atau manual dengan mengalihkan lalu lintas dari sumber daya yang terganggu ke sumber daya yang sehat.

Antipola umum:

  • Ketergantungan pada pengubahan catatan DNS untuk mengalihkan lalu lintas.

  • Ketergantungan pada operasi penskalaan bidang kendali untuk menggantikan komponen yang terganggu karena sumber daya yang disediakan tidak memadai.

  • Mengandalkan tindakan bidang kendali ekstensif multi-API dan multi layanan untuk meremediasi kategori gangguan apa pun.

Manfaat menjalankan praktik terbaik ini: Peningkatan tingkat keberhasilan untuk remediasi otomatis dapat mengurangi waktu rata-rata Anda untuk pemulihan dan meningkatkan ketersediaan beban kerja.

Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan: Sedang: Untuk jenis degradasi layanan tertentu, bidang kendali terkena pengaruh. Ketergantungan pada penggunaan bidang kendali secara ekstensif untuk remediasi dapat meningkatkan waktu pemulihan (RTO) dan rata-rata waktu untuk pulih (MTTR).

Panduan implementasi

Untuk membatasi tindakan bidang data, nilai setiap layanan untuk menemukan tindakan yang diperlukan untuk memulihkan layanan.

Manfaatkan Amazon Application Recovery Controller (ARC) untuk mengalihkan lalu lintas DNS. Fitur-fitur ini terus-menerus memantau kemampuan aplikasi Anda untuk pulih dari kegagalan, dan memampukan Anda untuk mengontrol pemulihan aplikasi di beberapa Wilayah AWS, Zona Ketersediaan, dan on-premise.

Kebijakan perutean Route 53 menggunakan bidang kendali, jadi jangan mengandalkannya untuk pemulihan. Bidang data Route 53 menjawab kueri DNS dan melakukan serta mengevaluasi pemeriksaan kondisi. Bidang data ini terdistribusi secara global dan didesain untuk perjanjian tingkat layanan (SLA) dengan ketersediaan 100%..

Konsol dan API manajemen Route 53 di mana Anda membuat, memperbarui, dan menghapus sumber daya Route 53 dijalankan di bidang kendali yang didesain untuk memprioritaskan durabilitas dan konsistensi tinggi yang Anda perlukan ketika mengelola DNS. Untuk mencapai hal ini, bidang kendali ditempatkan di satu Wilayah: US East (N. Virginia). Walaupun kedua sistem dibangun agar sangat andal, bidang kendali tidak disertakan dalam SLA. Mungkin ada peristiwa langka di mana desain tangguh bidang data memungkinkannya untuk mempertahankan ketersediaan sedangkan bidang kendali tidak. Untuk mekanisme failover dan pemulihan bencana, gunakan fungsi bidang data untuk memberikan keandalan yang sebaik mungkin.

Untuk Amazon EC2, gunakan desain stabilitas statis untuk membatasi tindakan bidang kendali. Tindakan bidang kendali mencakup peningkatan skala sumber daya secara individu atau menggunakan grup Auto Scaling (ASG). Untuk tingkat ketahanan tertinggi, berikan kapasitas yang cukup di klaster yang digunakan untuk failover. Jika ambang kapasitas ini harus dibatasi, tetapkan throttle pada keseluruhan sistem menyeluruh untuk membatasi lalu lintas total yang mencapai set sumber daya terbatas.

Untuk layanan seperti Amazon DynamoDB, Amazon API Gateway, penyeimbang beban, dan nirserver AWS Lambda, penggunaan layanan-layanan tersebut memanfaatkan bidang data. Namun, pembuatan fungsi baru, penyeimbang beban, gateway API, atau tabel DynamoDB adalah tindakan bidang kendali dan harus diselesaikan sebelum degradasi sebagai persiapan peristiwa dan latihan tindakan failover. Untuk Amazon RDS, tindakan bidang data memungkinkan akses ke data.

Untuk informasi selengkapnya tentang bidang data, bidang kendali, dan bagaimana AWS membangun layanan untuk memenuhi target ketersediaan tinggi, lihat Stabilitas statis menggunakan Zona Ketersediaan.

Pahami operasi mana yang ada di bidang data dan mana yang ada di bidang kendali.

Langkah implementasi

Untuk setiap beban kerja yang perlu dipulihkan setelah peristiwa degradasi, evaluasi runbook failover, desain ketersediaan tinggi, desain perbaikan otomatis, atau rencana pemulihan sumber daya HA. Identifikasikan setiap tindakan yang mungkin dianggap sebagai tindakan bidang kendali.

Pertimbangkan mengubah tindakan kendali ke tindakan bidang data:

  • Auto Scaling (bidang kendali) dibandingkan dengan sumber daya Amazon EC2 yang telah diskalakan sebelumnya (bidang data)

  • Migrasikan ke Lambda dan metode penskalaannya (bidang data) atau Amazon EC2 dan ASG (bidang kendali)

  • Nilai desain apa pun menggunakan Kubernetes dan sifat tindakan bidang kendali. Menambahkan pod adalah tindakan bidang data di Kubernetes. Tindakan harus dibatasi ke penambahan pod dan bukan ke penambahan simpul. Jika menggunakan simpul yang disediakan secara berlebihan adalah metode yang lebih disukai untuk membatasi tindakan bidang kendali

Pertimbangkan pendekatan alternatif yang memungkinkan tindakan bidang data untuk memengaruhi remediasi yang sama.

Pertimbangkan beberapa layanan di Wilayah sekunder, jika layanan sangat penting, untuk memungkinkan lebih banyak tindakan bidang kendali dan bidang data di Wilayah yang tidak terdampak.

  • Amazon EC2 Auto Scaling atau Amazon EKS di Wilayah primer dibandingkan dengan Amazon EC2 Auto Scaling atau Amazon EKS di Wilayah sekunder dan merutekan lalu lintas ke Wilayah sekunder (tindakan bidang kendali)

  • Membuat replika baca di primer sekunder atau mencoba tindakan yang sama di Wilayah primer (tindakan bidang kendali)

Sumber daya

Praktik terbaik terkait:

Dokumen terkait:

Video terkait:

Contoh terkait:

Alat terkait: