Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
REL11-BP02 Gagal ke sumber daya yang sehat
Jika terjadi kegagalan sumber daya, sumber daya yang sehat harus terus melayani permintaan. Untuk gangguan lokasi (seperti Availability Zone atau Wilayah AWS), pastikan bahwa Anda memiliki sistem di tempat untuk gagal ke sumber daya yang sehat di lokasi yang tidak terganggu.
Saat merancang sebuah layanan, distribusikan beban di seluruh sumber daya, Zona Ketersediaan, atau Wilayah. Oleh karena itu, kegagalan atau gangguan yang terjadi pada satu sumber daya individu dapat dimitigasi dengan mengalihkan lalu lintas ke sumber daya sehat yang masih ada. Pertimbangkan bagaimana layanan ditemukan dan dirutekan jika ada suatu kegagalan yang terjadi.
Rancang layanan Anda dengan mempertimbangkan pemulihan kesalahan. Di AWS, kami merancang layanan untuk meminimalkan waktu pemulihan dari kegagalan dan dampak pada data. Layanan-layanan kami utamanya menggunakan penyimpanan data yang mengenali permintaan hanya setelah disimpan dalam waktu lama di beberapa replika di dalam suatu Wilayah. Layanan dan sumber daya ini dibangun untuk menggunakan isolasi berbasis sel dan menggunakan isolasi kesalahan yang disediakan oleh Zona Ketersediaan. Kami banyak menggunakan otomatisasi di dalam prosedur-prosedur operasional kami. Kami juga mengoptimalkan replace-and-restart fungsionalitas kami untuk pulih dengan cepat dari gangguan.
Pola dan desain yang memungkinkan failover berbeda-beda untuk setiap layanan platform AWS . Banyak layanan terkelola AWS asli adalah beberapa Availability Zone (seperti Lambda API atau Gateway). AWS Layanan lain (seperti EC2 danEKS) memerlukan desain praktik terbaik khusus untuk mendukung failover sumber daya atau penyimpanan data secara keseluruhanAZs.
Pemantauan harus disiapkan untuk memeriksa apakah sumber daya failover sehat, melacak kemajuan sumber daya yang melakukan failover, dan memantau pemulihan proses bisnis.
Hasil yang diinginkan: Sistem mampu secara otomatis atau manual menggunakan sumber daya baru untuk pulih dari degradasi.
Anti-pola umum:
-
Perencanaan kegagalan bukan bagian dari fase perencanaan dan desain.
-
RTOdan RPO tidak didirikan.
-
Pemantauan yang tidak memadai untuk mendeteksi sumber daya yang gagal.
-
Isolasi domain kegagalan yang layak.
-
Kegagalan Multi-Wilayah tidak dipertimbangkan.
-
Deteksi kegagalan terlalu sensitif atau agresif saat memutuskan untuk melakukan failover.
-
Tidak menguji atau memvalidasi desain failover.
-
Melakukan otomatisasi pemulihan otomatis, tetapi tidak memberikan notifikasi bahwa pemulihan diperlukan.
-
Kurangnya periode peredaman untuk menghindari kegagalan berulang yang terlalu cepat.
Manfaat menerapkan praktik terbaik ini: Anda dapat membangun sistem-sistem yang lebih tangguh yang mempertahankan keandalan saat mengalami kegagalan dengan melakukan degradasi secara mulus dan pulih dengan cepat.
Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan: Tinggi
Panduan implementasi
AWS layanan, seperti Elastic Load Balancing dan Amazon Auto EC2 Scaling, membantu mendistribusikan beban di seluruh sumber daya dan Availability Zone. Oleh karena itu, kegagalan sumber daya individu (seperti EC2 contoh) atau penurunan Zona Ketersediaan dapat dikurangi dengan mengalihkan lalu lintas ke sumber daya yang sehat yang tersisa.
Untuk beban kerja multi-Wilayah, desainnya lebih rumit. Misalnya, replika baca lintas wilayah memungkinkan Anda menyebarkan data ke beberapa. Wilayah AWS Namun, failover masih diperlukan untuk mempromosikan replika baca ke primer kemudian mengarahkan lalu lintas Anda ke titik akhir baru. Amazon Route 53, Amazon Application Recovery Controller (ARC)
AWS layanan, seperti Amazon S3, LambdaAPI, Gateway, Amazon, Amazon, Amazon, SQS Amazon SES Pinpoint, SNS Amazon,,,,, AWS Certificate Manager atau EventBridge Amazon DynamoDBECR, secara otomatis digunakan ke beberapa Availability Zone oleh. AWS Jika terjadi kegagalan, AWS layanan ini secara otomatis mengarahkan lalu lintas ke lokasi yang sehat. Data disimpan secara redundan di beberapa Zona Ketersediaan dan tetap tersedia.
Untuk AmazonRDS, Amazon Aurora, Amazon Redshift, Amazon, atau EKS ECS Amazon, Multi-AZ adalah opsi konfigurasi. AWS dapat mengarahkan lalu lintas ke instance sehat jika failover dimulai. Tindakan failover ini dapat diambil oleh AWS atau sebagaimana disyaratkan oleh pelanggan
Untuk EC2 instans Amazon, Amazon Redshift, tugas ECS Amazon, atau pod EKS Amazon, Anda memilih Availability Zone yang akan digunakan. Untuk beberapa desain, Elastic Load Balancing menyediakan solusi untuk mendeteksi instans yang ada di zona yang tidak sehat, dan kemudian merutekan lalu lintas ke zona yang sehat. Penyeimbang Beban Elastis dapat merutekan lalu lintas ke komponen di pusat data on-premise Anda.
Untuk failover lalu lintas Multi-Wilayah, pengalihan rute dapat memanfaatkan Amazon Route 53, Amazon Application Recovery Controller, AWS Global Accelerator, Route 53 Private DNS untukVPCs, atau CloudFront untuk menyediakan cara untuk menentukan domain internet dan menetapkan kebijakan perutean, termasuk pemeriksaan kesehatan, untuk merutekan lalu lintas ke Wilayah yang sehat. AWS Global Accelerator menyediakan alamat IP statis yang bertindak sebagai titik masuk tetap ke aplikasi Anda, lalu rute ke titik akhir yang Anda pilih, menggunakan jaringan AWS global alih-alih internet untuk kinerja dan keandalan yang lebih baik. Wilayah AWS
Langkah-langkah implementasi
-
Buat desain failover untuk semua aplikasi dan layanan yang sesuai. Isolasi setiap komponen arsitektur dan buat rapat desain failover RTO dan RPO untuk setiap komponen.
-
Konfigurasikan lingkungan yang lebih rendah (seperti pengembangan atau pengujian) dengan semua layanan yang diharuskan memiliki rencana failover. Lakukan deployment solusi dengan menggunakan infrastruktur sebagai kode (IaC) untuk memastikan kemampuan pengulangan.
-
Konfigurasikan lokasi pemulihan, misalnya Wilayah kedua, untuk mengimplementasikan dan menguji desain failover. Jika perlu, sumber daya untuk pengujian dapat dikonfigurasi secara sementara untuk membatasi biaya-biaya tambahan.
-
Tentukan rencana failover mana yang diotomatisasi oleh AWS, yang dapat diotomatisasi oleh suatu DevOps proses, dan mana yang mungkin manual. Dokumentasikan dan ukur setiap layanan RTO danRPO.
-
Buatlah sebuah playbook failover dan sertakan semua langkah untuk melakukan failover pada setiap sumber daya, aplikasi, dan layanan.
-
Buatlah sebuah playbook failback dan sertakan semua langkah untuk melakukan failback (dengan pengaturan waktu) pada setiap sumber daya, aplikasi, dan layanan
-
Buatlah sebuah rencana untuk memulai dan melatih playbook. Gunakan simulasi dan pengujian kekacauan untuk menguji langkah-langkah dan otomatisasi playbook.
-
Untuk kerusakan lokasi (seperti Availability Zone atau Wilayah AWS), pastikan Anda memiliki sistem di tempat untuk gagal ke sumber daya yang sehat di lokasi yang tidak terganggu. Periksa kuota, tingkat penskalaan otomatis, dan sumber daya yang berjalan sebelum pengujian failover.
Sumber daya
Praktik terbaik Well-Architected terkait:
Dokumen terkait:
Contoh terkait:
