View a markdown version of this page

REL11-BP02 Melakukan failover ke sumber daya yang sehat - AWS Well-Architected Framework
Panduan implementasi Sumber daya

REL11-BP02 Melakukan failover ke sumber daya yang sehat

Jika terjadi kegagalan sumber daya, sumber daya yang sehat harus terus melayani permintaan. Untuk kerusakan lokasi (seperti Zona Ketersediaan atau Wilayah AWS) pastikan Anda memiliki sistem untuk melakukan failover ke sumber daya yang sehat di lokasi yang tidak terkena gangguan.

Saat merancang layanan, distribusikan beban di seluruh sumber daya, Zona Ketersediaan, atau Wilayah. Oleh karena itu, kegagalan sumber daya individu atau gangguan dapat dimitigasi dengan mengalihkan lalu lintas ke sumber daya sehat yang masih ada. Pertimbangkan bagaimana layanan ditemukan dan dirutekan jika terjadi kegagalan.

Rancang layanan Anda dengan mempertimbangkan pemulihan kesalahan. Di AWS, kami merancang layanan untuk meminimalkan waktu untuk pulih dari kegagalan dan dampak terhadap data. 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 operasional kami. Kami juga mengoptimalkan fungsionalitas “ganti dan mulai ulang” kami untuk pulih secara cepat dari gangguan.

Pola dan desain yang memungkinkan failover bervariasi untuk setiap layanan platform AWS. Banyak layanan terkelola native AWS adalah layanan yang secara native multi-Zona Ketersediaan (seperti Lambda atau API Gateway). Layanan AWS lain (seperti EC2 dan EKS) memerlukan desain praktik terbaik khusus untuk mendukung failover sumber daya atau penyimpanan data di seluruh AZ.

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.

Antipola umum:

  • Perencanaan kegagalan bukan bagian dari fase perencanaan dan desain.

  • RTO dan RPO tidak ditetapkan.

  • Pemantauan yang tidak memadai untuk mendeteksi sumber daya yang gagal.

  • Pemisahan 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 gagal kembali yang terlalu cepat.

Manfaat menjalankan praktik terbaik ini: Anda dapat membangun 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 dijalankan: Tinggi

Panduan implementasi

Layanan AWS, seperti Elastic Load Balancing dan Amazon EC2 Auto Scaling, membantu mendistribusikan beban di seluruh sumber daya dan Zona Ketersediaan. Oleh karena itu, kegagalan sumber daya individu (seperti instans EC2) atau gangguan pada Zona Ketersediaan dapat dimitigasi dengan mengalihkan lalu lintas ke sumber daya sehat yang masih ada.

Untuk beban kerja multi-Wilayah, desainnya lebih rumit. Misalnya, replika baca lintas Wilayah memungkinkan Anda untuk melakukan deployment 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, Route 53 ARC, CloudFront, dan AWS Global Accelerator dapat membantu merutekan lalu lintas di seluruh Wilayah AWS.

Layanan AWS, seperti Amazon S3, Lambda, API Gateway, Amazon SQS, Amazon SNS, Amazon SES, Amazon Pinpoint, Amazon ECR, AWS Certificate Manager, EventBridge, atau Amazon DynamoDB, secara otomatis di-deploy ke beberapa Zona Ketersediaan oleh AWS. Jika terjadi kegagalan, layanan-layanan AWS ini secara otomatis merutekan lalu lintas ke lokasi yang sehat. Data disimpan secara redundan di beberapa Zona Ketersediaan dan tetap tersedia.

Untuk Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon EKS, atau Amazon ECS, Multi-AZ adalah opsi konfigurasi. AWS dapat mengarahkan lalu lintas ke instans sehat jika failover dimulai. Tindakan failover ini dapat diambil oleh AWS atau sebagaimana diperlukan oleh pelanggan

Untuk instans Amazon EC2, Amazon Redshift, tugas Amazon ECS, atau pod Amazon EKS, Anda memilih Zona Ketersediaan mana untuk deployment. Untuk beberapa desain, Elastic Load Balancing memberikan solusi untuk mendeteksi instans di zona yang tidak sehat dan merutekan lalu lintas ke zona yang sehat. Elastic Load Balancing juga 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, ARC, AWS Global Accelerator, Route 53 Private DNS for VPCs, atau CloudFront untuk menyediakan cara untuk menentukan domain internet dan menetapkan kebijakan perutean, termasuk pemeriksaan kondisi, 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 merutekan ke titik akhir di Wilayah AWS yang Anda pilih, menggunakan jaringan global AWS, bukan internet, demi performa dan keandalan yang lebih baik.

Langkah implementasi

  • Buat desain failover untuk semua aplikasi dan layanan yang sesuai. Isolasi setiap komponen arsitektur dan buat desain failover yang memenuhi RTO dan RPO untuk setiap komponen.

  • Konfigurasikan lingkungan yang lebih rendah (seperti pengembangan atau pengujian) dengan semua layanan yang diharuskan memiliki rencana failover. Deploy solusi menggunakan infrastruktur sebagai kode (IaC) untuk memastikan kemampuan pengulangan.

  • Konfigurasikan lokasi pemulihan seperti Wilayah kedua untuk mengimplementasikan dan menguji desain failover. Jika perlu, sumber daya untuk pengujian dapat dikonfigurasi secara sementara untuk membatasi biaya tambahan.

  • Tentukan rencana failover mana yang diotomatisasi olehAWS, yang dapat diotomatisasi oleh proses DevOps, dan mana yang mungkin dilakukan secara manual. Dokumentasikan dan ukur RTO dan RPO setiap layanan.

  • Buat playbook failover dan sertakan semua langkah untuk melakukan failover setiap sumber daya, aplikasi, dan layanan.

  • Buat playbook failback dan sertakan semua langkah untuk melakukan failback (dengan pengaturan waktu) setiap sumber daya, aplikasi, dan layanan

  • Buat rencana untuk memulai dan melatih playbook. Gunakan simulasi dan pengujian kekacauan untuk menguji langkah-langkah dan otomatisasi playbook.

  • Untuk gangguan lokasi (seperti Zona Ketersediaan atau Wilayah AWS), pastikan Anda memiliki sistem untuk melakukan failover ke sumber daya yang sehat di lokasi yang tidak terkena gangguan. Periksa kuota, tingkat penskalaan otomatis, dan sumber daya yang berjalan sebelum pengujian failover.

Sumber daya

Praktik terbaik Well-Architected terkait:

Dokumen terkait:

Contoh terkait: