# REL 11 Bagaimana cara mendesain beban kerja Anda untuk bertahan dari kegagalan komponen?
Beban kerja dengan persyaratan untuk ketersediaan tinggi dan waktu rata-rata untuk pemulihan (MTTR) rendah harus didesain dan dikonfigurasi agar tangguh.
**Topics**
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Melakukan failover ke sumber daya yang sehat](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Mengotomatisasi pemulihan di semua lapisan](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 Andalkan bidang data dan bukan bidang kendali selama pemulihan](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 Gunakan stabilitas statis untuk mencegah perilaku bimodal](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Mengirimkan notifikasi ketika peristiwa memengaruhi ketersediaan](rel_withstand_component_failures_notifications_sent_system.md)
# REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan
Terus pantau kondisi beban kerja agar Anda dan sistem otomatis Anda mengetahui penurunan kualitas atau kegagalan langsung setelah muncul. Pantau indikator kinerja utama (KPI) berdasarkan nilai bisnis.
Semua mekanisme pemulihan dan penyembuhan harus dimulai dengan kemampuan untuk mendeteksi masalah secara cepat. Kegagalan teknis harus dideteksi terlebih dahulu sehingga dapat diatasi. Namun, ketersediaan didasarkan pada kemampuan beban kerja Anda untuk menghadirkan nilai bisnis, sehingga indikator kinerja utama (KPI) yang mengukurnya perlu menjadi bagian dari strategi deteksi dan perbaikan Anda.
**Antipola umum:**
+ Tidak ada alarm yang dikonfigurasi, sehingga pemadaman terjadi tanpa notifikasi.
+ Alarm tersedia, tetapi pada ambang batas yang tidak menyediakan waktu yang cukup untuk bereaksi.
+ Metrik tidak dikumpulkan cukup sering untuk memenuhi sasaran waktu pemulihan (RTO).
+ Hanya tingkatan beban kerja di sisi pelanggan yang aktif dipantau.
+ Hanya mengumpulkan metrik teknis, dan tidak ada metrik fungsi bisnis.
+ Tidak ada metrik yang mengukur pengalaman pengguna beban kerja.
**Manfaat menjalankan praktik terbaik ini:** Adanya pemantauan yang baik di semua lapisan memungkinkan Anda menghemat waktu pemulihan dengan mengurangi waktu deteksi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Tentukan interval pengumpulan untuk komponen Anda berdasarkan tujuan pemulihan.
+ Interval pemantauan Anda bergantung pada seberapa cepat Anda harus pulih. Waktu pemulihan Anda didorong oleh waktu yang diperlukan untuk pulih, sehingga Anda harus menentukan frekuensi pengumpulan dengan cara menghitung waktu ini serta sasaran waktu pemulihan (RTO) Anda.
+ Konfigurasikan pemantauan mendetail untuk komponen.
+ Tentukan apakah diperlukan pemantauan mendetail untuk instans EC2 dan Auto Scaling. Pemantauan mendetail menyediakan metrik interval 1 menit, sedangkan pemantauan default menyediakan metrik interval 5 menit.
+ [Aktifkan atau Nonaktifkan Pemantauan Mendetail untuk Instans Anda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Memantau Grup Auto Scaling dan Instans Anda Menggunakan Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ Tentukan apakah diperlukan pemantauan yang ditingkatkan untuk RDS. Pemantauan yang ditingkatkan menggunakan agen di instans RDS untuk mendapatkan informasi yang bermanfaat tentang proses atau thread berbeda di sebuah instans RDS.
+ [Pemantauan yang Ditingkatkan](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ Buat metrik kustom untuk mengukur indikator kinerja utama (KPI) bisnis. Beban kerja mengimplementasikan fungsi-fungsi bisnis utama. Fungsi-fungsi tersebut harus digunakan sebagai KPI yang membantu mengidentifikasi saat terjadi masalah tidak langsung.
+ [Memublikasikan Metrik Kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Pantau pengalaman pengguna untuk mendeteksi kegagalan menggunakan canary pengguna. Pengujian transaksi sintetis (juga disebut pengujian canary, tetapi bedakan dengan deployment canary) yang dapat menjalankan dan menyimulasikan perilaku pelanggan adalah salah satu proses pengujian yang paling penting. Jalankan pengujian ini secara konstan terhadap titik akhir beban kerja Anda dari beragam lokasi jarak jauh.
+ [Amazon CloudWatch Synthetics memungkinkan Anda untuk membuat canary pengguna](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ Buat metrik kustom yang melacak pengalaman pengguna. Jika Anda dapat menginstrumentasi pengalaman pelanggan, Anda dapat menentukan saat pengalaman pelanggan mengalami penurunan kualitas.
+ [Memublikasikan Metrik Kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Atur alarm untuk mendeteksi saat ada bagian dari beban kerja Anda yang tidak berfungsi dengan baik, dan untuk menunjukkan kapan harus menerapkan Auto Scale pada sumber daya. Alarm dapat ditampilkan secara visual di dasbor, mengirimkan pemberitahuan melalui Amazon SNS atau email, dan bekerja dengan Auto Scaling untuk menaikkan atau menurunkan skala sumber daya untuk beban kerja.
+ [Menggunakan Alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ Buat dasbor untuk memvisualisasikan metrik Anda. Dasbor dapat digunakan untuk melihat tren, penyimpangan, dan indikator potensi masalah lainnya, atau untuk menyediakan penanda masalah yang ingin Anda selidiki.
+ [Menggunakan dasbor CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
## Sumber daya
**Dokumen terkait:**
+ [Amazon CloudWatch Synthetics memungkinkan Anda untuk membuat canary pengguna](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Aktifkan atau Nonaktifkan Pemantauan Mendetail untuk Instans Anda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Pemantauan yang Ditingkatkan](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Memantau Grup Auto Scaling dan Instans Anda Menggunakan Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [Memublikasikan Metrik Kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Menggunakan Alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Menggunakan dasbor CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**Contoh terkait:**
+ [Lab Well-Architected: Level 300: Mengimplementasikan Pemeriksaan Kondisi dan Mengelola Dependensi untuk Meningkatkan Keandalan](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP02 Melakukan failover ke sumber daya yang sehat
Pastikan jika terjadi kegagalan sumber daya, sumber daya yang sehat dapat terus melayani permintaan. Untuk kegagalan 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.
Layanan AWS, seperti Elastic Load Balancing dan AWS 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 multiwilayah, ini lebih rumit. Misalnya, replika baca lintas wilayah memungkinkan Anda men-deploy data Anda ke beberapa Wilayah AWS, tetapi Anda tetap harus menaikkan replika baca ke wilayah primer dan arahkan lalu lintas Anda ke sana apabila terjadi failover. Amazon Route 53 dan AWS Global Accelerator dapat membantu merutekan lalu lintas di seluruh Wilayah AWS.
Jika beban kerja Anda menggunakan layanan AWS, seperti Amazon S3 atau Amazon DynamoDB, lalu di-deploy secara otomatis ke beberapa Zona Ketersediaan. Apabila terjadi kegagalan, bidang kendali AWS secara otomatis merutekan lalu lintas ke lokasi yang sehat untuk Anda. Data disimpan secara redundan di beberapa Zona Ketersediaan, dan tetap tersedia. Untuk Amazon RDS, Anda harus memilih Multi-AZ sebagai opsi konfigurasi, lalu pada saat kegagalan, AWS mengarahkan lalu lintas secara otomatis ke instans yang sehat. Untuk instans Amazon EC2, tugas Amazon ECS, atau pod Amazon EKS, Anda memilih Zona Ketersediaan sebagai target deployment. Elastic Load Balancing lalu menyediakan solusi untuk mendeteksi instans di zona tidak sehat dan merutekan lalu lintas ke zona yang sehat. Elastic Load Balancing bahkan dapat merutekan lalu lintas ke komponen di pusat data on-premise Anda.
Untuk pendekatan Multi-Wilayah (yang mungkin juga termasuk pusat data on-premise), Amazon Route 53 menyediakan cara untuk menetapkan domain internet, dan menerapkan kebijakan perutean yang dapat mencakup pemeriksaan kondisi untuk memastikan bahwa lalu lintas dirutekan ke wilayah yang sehat. Alternatifnya, AWS Global Accelerator menyediakan alamat IP statis yang bertindak sebagai titik masuk tetap untuk aplikasi Anda, lalu rute ke titik akhir di Wilayah AWS yang Anda pilih menggunakan jaringan global AWS, bukan internet, untuk kinerja dan keandalan yang lebih baik.
AWS melakukan pendekatan desain layanan dengan mempertimbangkan pemulihan kesalahan. 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 repliksa di dalam suatu Wilayah. Di antara layanan dan sumber daya ini adalah Amazon Aurora, instans Multi-AZ DB Amazon Relational Database Service (Amazon RDS), Amazon S3, Amazon DynamoDB, Amazon Simple Queue Service (Amazon SQS), dan Amazon Elastic File System (Amazon EFS). 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.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Lakukan failover ke sumber daya yang sehat. Pastikan jika terjadi kegagalan sumber daya, sumber daya yang sehat dapat terus melayani permintaan. Untuk kegagalan 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.
+ Jika beban kerja Anda menggunakan layanan AWS, seperti Amazon S3 atau Amazon DynamoDB, lalu di-deploy secara otomatis ke beberapa Zona Ketersediaan. Apabila terjadi kegagalan, bidang kendali AWS secara otomatis merutekan lalu lintas ke lokasi yang sehat untuk Anda.
+ Untuk Amazon RDS, Anda harus memilih Multi-AZ sebagai opsi konfigurasi, lalu pada saat kegagalan, AWS mengarahkan lalu lintas secara otomatis ke instans yang sehat.
+ [Ketersediaan Tinggi (Multi-AZ) untuk Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ Untuk instans Amazon EC2 atau tugas Amazon ECS, Anda memilih Zona Ketersediaan sebagai target deployment. Elastic Load Balancing lalu menyediakan solusi untuk mendeteksi instans di zona tidak sehat dan merutekan lalu lintas ke zona yang sehat. Elastic Load Balancing bahkan dapat merutekan lalu lintas ke komponen di pusat data on-premise Anda.
+ Untuk pendekatan multi-wilayah (yang mungkin juga mencakup pusat data on-premise), pastikan data dan sumber daya dari lokasi yang sehat dapat terus melayani permintaan
+ Misalnya, replika baca lintas wilayah memungkinkan Anda men-deploy data Anda ke beberapa Wilayah AWS, tetapi Anda tetap harus menaikkan replika baca ke wilayah utama dan arahkan lalu lintas Anda ke sana apabila terjadi kegagalan lokasi primer.
+ [Gambaran umum Replika Baca Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ Amazon Route 53 menyediakan cara untuk menetapkan domain internet, dan menerapkan kebijakan perutean, yang mungkin mencakup pemeriksaan kondisi, untuk memastikan lalu lintas dirutekan ke Wilayah yang sehat. Alternatifnya, AWS Global Accelerator menyediakan alamat IP statis yang bertindak sebagai titik masuk tetap untuk aplikasi Anda, lalu rute ke titik akhir di Wilayah AWS yang Anda pilih menggunakan jaringan global AWS, bukan internet publik, untuk kinerja dan keandalan yang lebih baik.
+ [Amazon Route 53: Memilih Kebijakan Perutean](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Apa Itu AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu dengan otomatisasi toleransi kesalahan Anda](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: produk yang dapat digunakan untuk toleransi kesalahan](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Menggunakan Auto Healing untuk Mengganti Instans yang Gagal](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon Route 53: Memilih Kebijakan Perutean](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Ketersediaan Tinggi (Multi-AZ) untuk Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ [Gambaran umum Replika Baca Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ [Strategi penempatan tugas Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Membuat Grup Auto Scaling Kubernetes untuk Beberapa Zona Ketersediaan](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/)
+ [Apa Itu AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
**Contoh terkait:**
+ [Lab Well-Architected: Level 300: Mengimplementasikan Pemeriksaan Kondisi dan Mengelola Dependensi untuk Meningkatkan Keandalan](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP03 Mengotomatisasi pemulihan di semua lapisan
Setelah kegagalan dideteksi, gunakan kemampuan otomatis untuk melakukan tindakan perbaikan.
*Kemampuan untuk memulai ulang* adalah alat penting untuk memperbaiki kegagalan. Seperti yang telah dibahas sebelumnya untuk sistem terdistribusi, salah satu praktik terbaik adalah menjadikan layanan bersifat tanpa status apabila memungkinkan. Hal ini mencegah hilangnya data atau ketersediaan pada saat mulai ulang. Di cloud, Anda dapat (dan umumnya harus) mengganti seluruh sumber daya (misalnya, instans EC2, atau fungsi Lambda) sebagai bagian dari mulai ulang. Mulai 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. Alih-alih membangun mekanisme baru untuk menjebak, mengidentifikasi, dan memperbaiki tiap-tiap jenis kegagalan yang berbeda-beda, petakan banyak kategori kegagalan yang berbeda ke strategi pemulihan yang sama. Sebuah instans mungkin gagal disebabkan kegagalan perangkat keras, bug sistem operasi, kebocoran memori, atau penyebab lainnya. Alih-alih membangun perbaikan kustom untuk tiap-tiap situasi, perlakukan semua situasi sebagai kegagalan instans. Akhiri instans, dan biarkan AWS Auto Scaling menggantinya. Setelahnya, Anda dapat menjalankan analisis terhadap sumber daya yang gagal tersebut di luar jaringan.
Contoh lainnya adalah kemampuan untuk memulai ulang permintaan jaringan. Terapkan pendekatan pemulihan yang sama ke waktu habis jaringan serta kegagalan dependensi yakni ketika 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 mundur eksponensial dan jitter.
*Kemampuan untuk memulai ulang* adalah mekanisme pemulihan yang disertakan dalam Komputasi Berorientasi Pemulihan dan arsitektur klaster ketersediaan tinggi.
Amazon EventBridge dapat digunakan untuk memantau dan memfilter peristiwa seperti Alarm CloudWatch atau perubahan pada layanan AWS lain. Berdasarkan informasi peristiwa, layanan ini kemudian dapat memicu AWS Lambda, AWS Systems Manager Automation, atau target lainnya untuk mengeksekusi logika perbaikan kustom pada beban kerja Anda.
Amazon EC2 Auto Scaling dapat dikonfigurasi untuk memeriksa kondisi instans EC2. Jika instans sedang dalam status apa pun selain running (berjalan), atau jika status sistem terganggu, Amazon EC2 Auto Scaling menganggap instans tersebut tidak sehat dan meluncurkan instans pengganti. Jika menggunakan AWS OpsWorks, Anda dapat mengonfigurasi Auto Healing instans EC2 pada tingkat lapisan OpsWorks.
Untuk penggantian skala besar (seperti hilangnya seluruh Zona Ketersediaan), stabilitas statis lebih disarankan untuk ketersediaan tinggi daripada mencoba memperoleh beberapa sumber daya baru sekaligus.
**Antipola umum:**
+ 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.
**Manfaat menjalankan praktik terbaik ini:** Pemulihan otomatis, bahkan jika beban kerja hanya dapat diterapkan ke dalam satu lokasi pada satu waktu, akan memangkas waktu rata-rata pemulihan Anda dan memastikan ketersediaan beban kerja.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Gunakan grup Auto Scaling untuk melakukan deployment tingkatan di sebuah beban kerja. Penskalaan otomatis dapat melakukan pemulihan mandiri pada aplikasi tanpa status, dan menambahkan serta menghapus kapasitas.
+ [Cara kerja AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Implementasikan pemulihan otomatis pada instans EC2 dengan aplikasi ter-deploy yang tidak dapat di-deploy di beberapa lokasi, dan dapat mentoleransi boot ulang 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 akan disimpan, begitu juga dengan volume Amazon EBS dan titik mount ke Elastic File Systems atau File Systems untuk Lustre dan Windows.
+ [Pemulihan Otomatis Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Apa itu Amazon FSx for Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Apa itu Amazon FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ Menggunakan AWS OpsWorks, Anda dapat mengonfigurasi Auto Healing instans EC2 pada tingkat lapisan
+ [AWS OpsWorks: Menggunakan Auto Healing untuk Mengganti Instans yang Gagal](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ Implementasikan pemulihan otomatis 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 pemulihan menggunakan AWS Step Functions dan AWS Lambda.
+ [Apa itu AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Apa itu AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ Amazon EventBridge dapat digunakan untuk memantau dan memfilter peristiwa seperti Alarm CloudWatch atau perubahan pada layanan AWS lain. Berdasarkan informasi peristiwa, layanan ini kemudian dapat memicu AWS Lambda (atau target lainnya) untuk menjalankan logika perbaikan kustom pada beban kerja Anda.
+ [Apa Itu Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Menggunakan Alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu dengan otomatisasi toleransi kesalahan Anda](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: produk yang dapat digunakan untuk toleransi kesalahan](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Menggunakan Auto Healing untuk Mengganti Instans yang Gagal](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Pemulihan Otomatis Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Cara kerja AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Menggunakan Alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Apa Itu Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Apa itu AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Apa itu AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Apa itu Amazon FSx for Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Apa itu Amazon FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
**Video terkait:**
+ [Stabilitas statis dalam AWS: AWS re:Invent 2019: Memperkenalkan Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
**Contoh terkait:**
+ [Lab Well-Architected: Level 300: Mengimplementasikan Pemeriksaan Kondisi dan Mengelola Dependensi untuk Meningkatkan Keandalan](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP04 Andalkan bidang data dan bukan bidang kendali selama pemulihan
Bidang kendali digunakan untuk mengonfigurasikan sumber daya, dan bidang data memberikan layanan. Bidang data biasanya memiliki sasaran desain dengan ketersediaan lebih tinggi daripada bidang kendali, dan biasanya lebih sederhana. Ketika mengimplementasikan respons mitigasi atau pemulihan terhadap peristiwa yang berpotensi memengaruhi ketangguhan, menggunakan operasi bidang kendali dapat menurunkan ketangguhan arsitektur Anda secara keseluruhan. Contohnya, Anda dapat mengandalkan bidang data Amazon Route 53 untuk merutekan kueri DNS secara andal berdasarkan pemeriksaan kondisi, tetapi memperbarui kebijakan perutean Route 53 menggunakan bidang kendali, jadi jangan mengandalkannya untuk pemulihan.
Bidang data Route 53 menjawab kueri DNS, dan melakukan dan mengevaluasi pemeriksaan kondisi. Bidang data ini terdistribusi secara global dan didesain untuk [perjanjian tingkat layanan (SLA) dengan ketersediaan 100%.](https://aws.amazon.com/route53/sla/) 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 ini, bidang kendali terletak 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 informasi selengkapnya tentang bidang data, bidang kendali, dan bagaimana AWS membangun layanan untuk memenuhi target ketersediaan tinggi, lihat [laporan Stabilitas statis menggunakan Zona Ketersediaan](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) dan [Amazon Builders' Library.](https://aws.amazon.com/builders-library/)
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Andalkan bidang data dan bukan bidang kendali ketika menggunakan Amazon Route 53 untuk pemulihan bencana. Pengontrol Pemulihan Aplikasi Route 53 membantu Anda mengelola dan mengoordinasikan failover menggunakan pemeriksaan kesiapan dan kontrol perutean. 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.
+ [Apa itu Pengontrol Pemulihan Aplikasi Route 53?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Membuat Mekanisme Pemulihan Bencana Menggunakan Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Membangun aplikasi yang sangat tangguh menggunakan Pengontrol Pemulihan Aplikasi Amazon Route 53, Bagian 1: Tumpukan Wilayah Tunggal](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Membangun aplikasi yang sangat tangguh menggunakan Pengontrol Pemulihan Aplikasi Amazon Route 53, Bagian 2: Tumpukan Multi-Wilayah](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ Pahami operasi mana yang ada di bidang data dan mana yang ada di bidang kendali.
+ [Amazon Builders’ Library: Menghindari kelebihan beban dalam sistem terdistribusi dengan mengontrol layanan lebih kecil](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API Amazon DynamoDB (bidang kendali dan bidang data)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [Pelaksanaan AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (dibagi menjadi bidang kendali dan bidang data)
+ [Pelaksanaan AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (dibagi menjadi bidang kendali dan bidang data)
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu dengan otomatisasi toleransi kesalahan Anda](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: produk yang dapat digunakan untuk toleransi kesalahan](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [Amazon Builders’ Library: Menghindari kelebihan beban dalam sistem terdistribusi dengan mengontrol layanan lebih kecil](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API Amazon DynamoDB (bidang kendali dan bidang data)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [Pelaksanaan AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (dibagi menjadi bidang kendali dan bidang data)
+ [Bidang Data AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Membangun aplikasi yang sangat tangguh menggunakan Pengontrol Pemulihan Aplikasi Amazon Route 53, Bagian 1: Tumpukan Wilayah Tunggal](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Membangun aplikasi yang sangat tangguh menggunakan Pengontrol Pemulihan Aplikasi Amazon Route 53, Bagian 2: Tumpukan Multi-Wilayah](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Membuat Mekanisme Pemulihan Bencana Menggunakan Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Apa itu Pengontrol Pemulihan Aplikasi Route 53?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
**Contoh terkait:**
+ [Memperkenalkan Pengontrol Pemulihan Aplikasi Amazon Route 53](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
# REL11-BP05 Gunakan stabilitas statis untuk mencegah perilaku bimodal
Perilaku bimodal terjadi ketika beban kerja Anda menunjukkan perilaku yang berbeda dalam mode normal dan mode kegagalan, contohnya, mengandalkan peluncuran instans baru jika Zona Ketersediaan gagal. Sebagai gantinya, Anda harus membangun beban kerja yang stabil secara statis dan dioperasikan dalam satu mode saja. Dalam hal ini, penyediaan instans yang cukup di setiap Zona Ketersediaan untuk menangani beban dari beban kerja jika satu AZ disingkirkan kemudian menggunakan pemeriksaan kondisi Elastic Load Balancing atau Amazon Route 53 untuk memindahkan beban dari instans yang terganggu.
Stabilitas statis untuk deployment komputasi (seperti kontainer atau instans EC2) akan menghasilkan keandalan tertinggi. Ini harus dibandingkan dengan masalah biaya. Memberikan lebih sedikit kapasitas komputasi dan mengandalkan peluncuran instans baru jika ada kegagalan akan lebih murah. Tetapi untuk kegagalan dalam skala besar (seperti kegagalan Zona Ketersediaan), pendekatan ini kurang efektif karena mengandalkan reaksi terhadap gangguan saat terjadi, dan bukannya siap menangani gangguan tersebut sebelum terjadi. Solusi Anda harus membandingkan keandalan dengan biaya yang diperlukan untuk beban kerja Anda. Dengan menggunakan lebih banyak Zona Ketersediaan, jumlah komputasi tambahan yang Anda perlukan untuk stabilitas statis akan berkurang.
![\[Diagram yang menunjukkan stabilitas statis instans EC2 di seluruh Zona Ketersediaan\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/static-stability.png)
Setelah lalu lintas dipindahkan, gunakan AWS Auto Scaling untuk mengganti instans secara asinkron dari zona yang gagal dan luncurkan di zona sehat.
Contoh lain dari perilaku bimodal adalah waktu habis jaringan yang dapat menyebabkan sistem mencoba untuk melakukan refresh status konfigurasi seluruh sistem. Ini akan menambahkan beban yang tak terduga ke komponen lain, dan dapat menyebabkannya gagal, sehingga memicu konsekuensi lain yang tak terduga. Lingkaran umpan balik negatif ini memengaruhi ketersediaan beban kerja Anda. Sebagai gantinya, Anda harus membangun sistem yang stabil secara statis dan dioperasikan dalam satu mode saja. Desain yang stabil secara statis akan melakukan pekerjaan secara terus-menerus, dan selalu refresh status konfigurasi dengan irama tetap. Ketika panggilan gagal, beban kerja menggunakan nilai yang sebelumnya di-cache, dan memicu alarm.
Contoh lain dari perilaku bimodal adalah memperbolehkan klien untuk melewatkan cache beban kerja Anda ketika kegagalan terjadi. Ini mungkin terlihat seperti solusi yang mengakomodasi kebutuhan klien, tetapi tidak boleh diizinkan karena secara signifikan mengubah permintaan di beban kerja Anda dan kemungkinan akan mengakibatkan kegagalan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Gunakan stabilitas statis untuk mencegah perilaku bimodal. Perilaku bimodal terjadi ketika beban kerja Anda menunjukkan perilaku yang berbeda dalam mode normal dan mode kegagalan, contohnya, mengandalkan peluncuran instans baru jika Zona Ketersediaan gagal.
+ [Meminimalkan Ketergantungan dalam Rencana Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Amazon Builders' Library: Stabilitas statis menggunakan Zona Ketersediaan](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [Stabilitas statis dalam AWS: AWS re:Invent 2019: Memperkenalkan Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
+ Sebagai gantinya, Anda harus membangun sistem yang stabil secara statis dan dioperasikan dalam satu mode saja. Dalam hal ini, penyediaan instans yang cukup di setiap zona untuk menangani beban dari beban kerja jika satu AZ disingkirkan kemudian menggunakan pemeriksaan kondisi Elastic Load Balancing atau Amazon Route 53 untuk memindahkan beban dari instans yang terganggu.
+ Contoh lain dari perilaku bimodal adalah memperbolehkan klien untuk melewatkan cache beban kerja Anda ketika kegagalan terjadi. Ini mungkin terlihat seperti solusi yang akan mengakomodasi kebutuhan klien, tetapi tidak boleh diizinkan karena secara signifikan mengubah permintaan di beban kerja Anda dan kemungkinan akan mengakibatkan kegagalan.
## Sumber daya
**Dokumen terkait:**
+ [Meminimalkan Ketergantungan dalam Rencana Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Amazon Builders' Library: Stabilitas statis menggunakan Zona Ketersediaan](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
**Video terkait:**
+ [Stabilitas statis dalam AWS: AWS re:Invent 2019: Memperkenalkan Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 Mengirimkan notifikasi ketika peristiwa memengaruhi ketersediaan
Notifikasi dikirimkan setelah peristiwa besar terdeteksi, bahkan jika masalah yang disebabkan oleh peristiwa tersebut diatasi secara otomatis.
Pemulihan otomatis menjadikan beban kerja Anda andal. Namun, kemampuan ini juga menyembunyikan masalah dasar yang perlu diatasi. Implementasikan pemantauan peristiwa yang baik agar Anda dapat mendeteksi pola masalah, termasuk masalah yang ditangani oleh pemulihan otomatis, sehingga Anda dapat mengatasi akar masalahnya. Alarm Amazon CloudWatch dapat dipicu berdasarkan kegagalan yang terjadi. Alarm ini juga dapat dipicu berdasarkan tindakan pemulihan otomatis yang dijalankan. Alarm CloudWatch dapat dikonfigurasi untuk mengirimkan email, atau untuk mencatatkan insiden di dalam sistem pelacakan insiden pihak ketiga menggunakan integrasi Amazon SNS.
**Antipola umum:**
+ Mengirimkan alarm yang tidak dapat ditindaklanjuti siapa pun.
+ Melakukan otomatisasi pemulihan otomatis, tetapi tidak memberikan notifikasi bahwa pemulihan diperlukan.
**Manfaat menjalankan praktik terbaik ini:** Notifikasi peristiwa pemulihan akan memastikan Anda tidak mengabaikan masalah yang tidak sering terjadi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
+ Alarm untuk Indikator Kinerja Utama bisnis saat melampaui ambang batas rendah. Dengan alarm ambang batas rendah pada KPI bisnis, Anda dapat mengetahui saat beban kerja Anda tidak tersedia atau tidak berfungsi.
+ [Membuat Alarm CloudWatch Berdasarkan Ambang Batas Statis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ Alarm untuk peristiwa yang memanggil otomatisasi pemulihan. Anda dapat langsung memanggil API SNS untuk mengirimkan notifikasi dengan otomatisasi apa pun yang Anda buat.
+ [Apa Itu Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
## Sumber daya
**Dokumen terkait:**
+ [Membuat Alarm CloudWatch Berdasarkan Ambang Batas Statis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [Apa Itu Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Apa Itu Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)