# Keandalan
Pilar keandalan berkenaan dengan kemampuan beban kerja untuk menjalankan fungsinya dengan benar dan konsisten sesuai ekspektasi. Anda dapat menemukan panduan preskriptif tentang implementasi di [Laporan Resmi Pilar Keandalan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp).
**Topics**
+ [Fondasi](a-foundations.md)
+ [Arsitektur beban kerja](a-workload-architecture.md)
+ [Manajemen perubahan](a-change-management.md)
+ [Manajemen kegagalan](a-failure-management.md)
# Fondasi
**Topics**
+ [REL 1. Bagaimana cara mengelola Kuota Layanan dan batasan?](rel-01.md)
+ [REL 2. Bagaimana cara merencanakan topologi jaringan Anda?](rel-02.md)
# REL 1. Bagaimana cara mengelola Kuota Layanan dan batasan?
Untuk arsitektur beban kerja berbasis cloud, ada Kuota Layanan (yang juga disebut sebagai batas layanan). Kuota ini ada untuk mencegah tanpa sengaja memberikan sumber daya lebih daripada yang Anda butuhkan dan untuk membatasi tingkat permintaan di operasi API sehingga melindungi layanan dari penyalahgunaan. Ada juga batas sumber daya, misalnya, laju Anda dapat mendorong bit di kabel serat optik, atau jumlah penyimpanan di disk secara fisik.
**Topics**
+ [REL01-BP01 Kesadaran tentang kuota dan kendala layanan](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 Mengelola kuota layanan di seluruh akun dan wilayah](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP03 Mengakomodasi kuota layanan tetap dan kendala melalui arsitektur](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP04 Memantau dan mengelola kuota](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 Mengotomatiskan manajemen kuota](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 Memastikan adanya selisih yang memadai antara kuota saat ini dan penggunaan maksimum untuk mengakomodasi failover](rel_manage_service_limits_suff_buffer_limits.md)
# REL01-BP01 Kesadaran tentang kuota dan kendala layanan
Perhatikan kuota default Anda dan kelola permintaan penambahan kuota untuk arsitektur beban kerja Anda. Ketahui kendala sumber daya cloud mana, seperti disk atau jaringan, yang berpotensi memberi dampak.
**Hasil yang diinginkan:** Pelanggan dapat mencegah penurunan kualitas atau gangguan layanan dalam Akun AWS mereka dengan mengimplementasikan pedoman yang tepat untuk memantau metrik utama, peninjauan infrastruktur, dan langkah-langkah perbaikan otomatisasi untuk memverifikasi tidak tercapainya kuota dan kendala layanan yang dapat menyebabkan penurunan kualitas dan gangguan layanan.
**Antipola umum:**
+ Melakukan deployment beban kerja tanpa memahami kuota keras dan lunak serta batasannya untuk layanan yang digunakan.
+ Melakukan deployment beban kerja pengganti tanpa menganalisis dan mengonfigurasi ulang kuota yang diperlukan atau menghubungi tim Dukungan sebelumnya.
+ Berasumsi bahwa layanan cloud tidak memiliki batasan dan layanan dapat digunakan tanpa mempertimbangkan angka permintaan, batas, hitungan, kuantitas.
+ Berasumsi bahwa kuota akan ditingkatkan secara otomatis.
+ Tidak mengetahui proses dan lini waktu permintaan kuota.
+ Berasumsi bahwa kuota layanan cloud default selalu sama untuk setiap layanan di semua wilayah.
+ Berasumsi bahwa kendala layanan dapat ditembus dan sistem akan diskalakan secara otomatis dan meningkatkan batas di luar kendala sumber daya.
+ Tidak menguji aplikasi saat lalu lintas memuncak untuk membebani pemanfaatan sumber dayanya.
+ Melakukan pengadaan sumber daya tanpa analisis ukuran sumber daya yang diperlukan.
+ Berlebihan dalam pengadaan kapasitas dengan memilih jenis sumber daya yang jauh melampaui kebutuhan riil atau perkiraan lalu lintas puncak.
+ Tidak menilai persyaratan kapasitas untuk tingkat lalu lintas baru sebelum peristiwa pelanggan baru atau deployment teknologi baru.
**Manfaat menjalankan praktik terbaik ini:** Pemantauan dan manajemen otomatis kuota layanan serta kendala sumber daya dapat mengurangi kegagalan secara proaktif. Perubahan pada pola lalu lintas untuk layanan pelanggan dapat menyebabkan gangguan atau penurunan kualitas jika praktik terbaik tidak diikuti. Dengan memantau dan mengelola nilai-nilai ini di semua wilayah dan semua akun, aplikasi dapat memiliki ketahanan yang lebih baik selama peristiwa yang tidak direncanakan atau tidak diinginkan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Service Quotas adalah sebuah layanan AWS yang membantu Anda mengelola kuota Anda untuk lebih dari 250 layanan AWS dari satu lokasi. Di samping mencari nilai kuota, Anda juga dapat meminta dan melacak peningkatan kuota dari konsol Service Quotas atau menggunakan SDK AWS. AWS Trusted Advisor menawarkan pemeriksaan kuota layanan yang menampilkan penggunaan dan kuota Anda untuk beberapa aspek dari beberapa layanan. Kuota layanan default per layanan juga ada di dalam dokumentasi AWS berdasarkan layanan masing-masing (misalnya, lihat [Kuota Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html)).
Beberapa batas layanan, seperti batas tingkat pada API yang diberikan throttling diatur di dalam Amazon API Gateway itu sendiri dengan mengonfigurasi rencana penggunaan. Batas yang diatur sebagai konfigurasi di layanannya masing-masing diantaranya adalah IOPS yang Disediakan, penyimpanan Amazon RDS yang dialokasikan, dan alokasi volume Amazon EBS. Amazon Elastic Compute Cloud memiliki dasbor batas layanannya sendiri yang dapat membantu Anda mengelola instans Anda, Amazon Elastic Block Store, dan batas alamat IP Elastis. Jika Anda memiliki kasus penggunaan di mana kuota layanan memengaruhi kinerja aplikasi Anda dan tidak dapat disesuaikan dengan kebutuhan Anda, hubungi Dukungan untuk mengetahui apakah terdapat langkah mitigasi.
Kuota layanan bisa menurut Wilayah atau bersifat global. Layanan AWS yang mencapai kuotanya tidak akan berfungsi sebagaimana mestinya dalam penggunaan normal dan dapat menyebabkan gangguan atau penurunan kualitas layanan. Misalnya, suatu kuota layanan membatasi jumlah DL Amazon EC2 yang dapat digunakan di sebuah Wilayah dan batasan tersebut dapat dicapai selama peristiwa penskalaan lalu lintas menggunakan grup Auto Scaling (ASG).
Kuota layanan untuk setiap akun harus dinilai secara rutin dalam hal penggunaan untuk menentukan batas layanan yang tepat untuk akun tersebut. Kuota layanan ini dibuat sebagai pagar pembatas operasional, agar Anda tidak melakukan pengadaan sumber daya lebih dari yang dibutuhkan tanpa disadari. Kuota layanan juga berfungsi untuk membatasi angka permintaan pada operasi API guna melindungi layanan dari penyalahgunaan.
Kendala layanan berbeda dari kuota layanan. Kendala layanan mewakili batasan sumber daya tertentu yang ditentukan oleh jenis sumber daya tersebut. Kendala tersebut dapat berupa kapasitas penyimpanan (misalnya, gp2 memiliki batas ukuran 1 GB - 16 TB) atau disk throughput (10.0000 iops). Sangat penting untuk merancang dan terus menilai kendala jenis sumber daya untuk penggunaan yang mungkin mencapai batasnya. Jika suatu kendala tercapai di luar perkiraan, aplikasi dan layanan akun dapat terganggu atau mengalami penurunan kualitas.
Jika terdapat kasus penggunaan di mana kuota layanan memengaruhi kinerja aplikasi dan tidak dapat disesuaikan dengan kebutuhan, hubungi Dukungan untuk mengetahui apakah terdapat langkah mitigasi. Untuk detail selengkapnya tentang penyesuaian kuota tetap, lihat [REL01-BP03 Mengakomodasi kuota layanan tetap dan kendala melalui arsitektur](rel_manage_service_limits_aware_fixed_limits.md).
Terdapat sejumlah layanan dan alat AWS untuk membantu memantau dan mengelola Service Quotas. Layanan dan alat harus dimanfaatkan untuk menyediakan pemeriksaan level kuota secara otomatis atau manual.
+ AWS Trusted Advisor menawarkan pemeriksaan kuota layanan yang menampilkan penggunaan dan kuota Anda untuk beberapa aspek dari beberapa layanan. Alat ini dapat membantu mengidentifikasi layanan yang mendekati kuota.
+ Konsol Manajemen AWS menyediakan metode untuk menampilkan nilai kuota layanan, mengelola, meminta kuota baru, memantau status permintaan kuota, dan menampilkan riwayat kuota.
+ AWS CLI dan CDK menawarkan metode terprogram untuk mengelola dan memantau level serta penggunaan kuota layanan secara otomatis.
**Langkah implementasi**
Untuk Service Quotas:
+ [ Pelajari AWS Service Quotas. ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ Untuk mengetahui kuota layanan Anda saat ini, tentukan layanan (seperti IAM Access Analyzer) yang digunakan. Terdapat sekitar 250 layanan AWS yang dikontrol oleh kuota layanan. Lalu, tentukan nama kuota layanan tertentu yang dapat digunakan di dalam setiap akun dan wilayah. Terdapat sekitar 3000 nama kuota layanan per wilayah.
+ Perkuat analisis kuota ini dengan AWS Config untuk menemukan semua [sumber daya AWS](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html) yang digunakan di dalam Akun AWS Anda.
+ Gunakan [data AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html) untuk menentukan sumber daya AWS Anda yang digunakan. Lihat sumber daya yang dibuat baik di Konsol Manajemen AWS maupun dengan [perintah `list-stack-resources`](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html) AWS CLI. Anda juga dapat melihat sumber daya yang dikonfigurasi untuk diterapkan di templat itu sendiri.
+ Tentukan semua layanan yang diperlukan oleh beban kerja Anda dengan melihat kode deployment.
+ Tentukan kuota layanan yang berlaku. Gunakan informasi yang dapat diakses secara terprogram dari Trusted Advisor dan Service Quotas.
+ Bangun metode pemantauan otomatis (lihat [REL01-BP02 Mengelola kuota layanan di seluruh akun dan wilayah](rel_manage_service_limits_limits_considered.md) dan [REL01-BP04 Memantau dan mengelola kuota](rel_manage_service_limits_monitor_manage_limits.md)) untuk memberi peringatan dan pemberitahuan jika kuota layanan mendekati atau sudah mencapai batas.
+ Bangun metode otomatis dan terprogram untuk memeriksa apakah kuota layanan telah diubah di satu wilayah tetapi tidak diubah di wilayah lain di dalam akun yang sama (lihat [REL01-BP02 Mengelola kuota layanan di seluruh akun dan wilayah](rel_manage_service_limits_limits_considered.md) dan [REL01-BP04 Memantau dan mengelola kuota](rel_manage_service_limits_monitor_manage_limits.md)).
+ Otomatiskan pemindaian log dan metrik aplikasi untuk menentukan apakah terdapat kesalahan kuota atau kendala layanan. Jika terdapat kesalahan, kirimkan peringatan ke sistem pemantauan.
+ Bangun prosedur rekayasa untuk menghitung perubahan yang diperlukan dalam kuota (lihat [REL01-BP05 Mengotomatiskan manajemen kuota](rel_manage_service_limits_automated_monitor_limits.md)) setelah diidentifikasi bahwa diperlukan kuota yang lebih besar untuk layanan tertentu.
+ Buat alur kerja pengadaan dan persetujuan untuk meminta perubahan dalam kuota layanan. Sertakan di dalamnya alur kerja pengecualian untuk mengantisipasi jika permintaan ditolak atau disetujui sebagian.
+ Buat metode rekayasa untuk meninjau kuota layanan sebelum pengadaan dan menggunakan layanan AWS baru sebelum digulirkan ke produksi atau lingkungan yang berisi data (misalnya akun pengujian beban).
Untuk kendala layanan:
+ Bangun metode pemantauan dan metrik untuk memberi peringatan jika pembacaan sumber daya mendekati kendala sumber dayanya. Manfaatkan CloudWatch apabila diperlukan untuk pemantauan metrik atau log.
+ Bangun ambang batas peringatan untuk setiap sumber daya yang memiliki kendala yang dapat berpengaruh pada aplikasi atau sistem.
+ Ciptakan prosedur manajemen alur kerja dan infrastruktur untuk mengubah jenis sumber daya jika pemanfaatan mendekati kendala. Alur kerja ini harus mencakup pengujian beban sebagai praktik terbaik untuk memverifikasi bahwa jenis sumber daya baru tersebut sudah tepat dengan kendala baru.
+ Migrasikan sumber daya yang diidentifikasi ke jenis sumber daya baru yang disarankan, menggunakan prosedur dan proses yang ada.
## Sumber daya
**Praktik Terbaik Terkait:**
+ [REL01-BP02 Mengelola kuota layanan di seluruh akun dan wilayah](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP03 Mengakomodasi kuota layanan tetap dan kendala melalui arsitektur](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP04 Memantau dan mengelola kuota](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 Mengotomatiskan manajemen kuota](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 Memastikan adanya selisih yang memadai antara kuota saat ini dan penggunaan maksimum untuk mengakomodasi failover](rel_manage_service_limits_suff_buffer_limits.md)
+ [REL03-BP01 Memilih cara untuk menyegmentasi beban kerja](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Melakukan deployment beban kerja ke beberapa lokasi](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Mengotomatisasi pemulihan di semua lapisan](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 Menguji ketahanan menggunakan chaos engineering](rel_testing_resiliency_failure_injection_resiliency.md)
**Dokumen terkait:**
+ [ Pilar Keandalan Kerangka Kerja AWS Well-Architected: Ketersediaan ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [AWS Service Quotas (sebelumnya disebut batas layanan)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor Pemeriksaan Praktik Terbaik (lihat bagian Batas Layanan)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Pemantau batas AWS di AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Batas Layanan Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Apa itu Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [ Cara Meminta Peningkatan Kuota ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [ Endpoint dan kuota layanan ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+ [Panduan Pengguna Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [ Pemantau Kuota untuk AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [ Batas Isolasi Kesalahan AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Ketersediaan dengan redundansi ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [AWS untuk Data ](https://aws.amazon.com/data/)
+ [ Apa itu Integrasi Berkelanjutan? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ Apa itu Pengiriman Berkelanjutan? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Partner APN: partner yang dapat membantu manajemen konfigurasi ](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Mengelola siklus hidup akun di dalam lingkungan SaaS akun per tenant di AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)
+ [ Mengelola dan memanfatau throttling API di dalam beban kerja Anda ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ Lihat rekomendasi AWS Trusted Advisor pada skala besar dengan AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)
+ [ Mengotomatiskan Peningkatan Batas Layanan dan Dukungan Korporat dengan AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)
**Video terkait:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
+ [ Melihat dan Mengelola Kuota untuk Layanan AWS Menggunakan Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc)
+ [ Demo Kuota AWS IAM ](https://www.youtube.com/watch?v=srJ4jr6M9YQ)
**Alat terkait:**
+ [ Amazon CodeGuru Reviewer ](https://aws.amazon.com/codeguru/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
# REL01-BP02 Mengelola kuota layanan di seluruh akun dan wilayah
Jika Anda menggunakan beberapa akun atau Wilayah, minta kuota yang sesuai di semua lingkungan tempat beban kerja produksi Anda dijalankan.
**Hasil yang diinginkan:** Layanan dan aplikasi tidak boleh dipengaruhi oleh habisnya kuota layanan untuk konfigurasi yang meliputi akun atau Wilayah atau yang memiliki desain ketahanan menggunakan failover zona, Wilayah, atau akun.
**Antipola umum:**
+ Membiarkan penggunaan sumber daya di satu Wilayah terisolasi bertambah, tanpa mekanisme untuk mempertahankan kapasitas di wilayah lainnya.
+ Mengatur semua kuota di Wilayah isolasi secara manual dan independen.
+ Tidak mempertimbangkan efek arsitektur ketahanan (seperti aktif atau pasif) dalam kebutuhan kuota masa depan selama penurunan kualitas di dalam Wilayah non-primer.
+ Tidak mengevaluasi kuota secara rutin dan membuat perubahan yang diperlukan di setiap Wilayah dan akun tempat beban kerja dijalankan.
+ Tidak memanfaatkan [templat pemintaan kuota](https://docs.aws.amazon.com/servicequotas/latest/userguide/organization-templates.html) untuk meminta penambahan di beberapa Wilayah dan akun.
+ Tidak memperbarui kuota layanan disebabkan pemikiran yang tidak tepat bahwa peningkatan kuota memiliki dampak biaya seperti permintaan pemesanan komputasi.
**Manfaat menjalankan praktik terbaik ini:** Memverifikasi bahwa Anda dapat menangani beban saat ini di wilayah atau akun sekunder jika layanan wilayah tidak tersedia. Hal ini dapat membantu mengurangi jumlah kesalahan atau tingkat penurunan kualitas yang terjadi selama region loss.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Kuota layanan dilacak per akun. Setiap kuota disesuaikan dengan Wilayah AWS, kecuali ditetapkan sebaliknya. Selain lingkungan produksi, kelola juga kuota di semua lingkungan non-produksi yang berlaku agar pengujian dan pengembangan tidak terhambat. Untuk mempertahankan tingkat ketahanan yang tinggi diperlukan penilaian kuota layanan secara kontinu (baik otomatis maupun manual).
Dengan makin banyaknya beban kerja yang meliputi beberapa Wilayah dikarenakan implementasi desain yang menggunakan pendekatan *Aktif/Aktif*, *Aktif/Pasif – Panas*, *Aktif/Pasif-Dingin*, dan *Aktif/Pasif-Pilot Light*, sangat penting memahami semua level kuota Wilayah dan akun. Pola lalu lintas terdahulu tidak selalu menjadi indikator yang tepat bahwa kuota layanan diatur dengan benar.
Sama pentingnya, batas nama kuota layanan tidak selalu sama untuk setiap Wilayah. Di satu Wilayah, nilainya bisa jadi lima, sedangkan di wilayah lain nilainya bisa jadi sepuluh. Manajemen kuota-kuota ini harus meliputi semua layanan, akun, dan Wilayah yang sama untuk menyediakan ketahanan yang konsisten saat beban meningkat.
Sesuaikan semua perbedaan kuota layanan di semua Wilayah yang berbeda (Wilayah Aktif atau Wilayah Pasif) dan buat proses untuk menyesuaikan semua perbedaan tersebut secara kontinu. Rencana pengujian failover Wilayah pasif sangat jarang diskalakan ke kapasitas aktif puncak, sehingga kegiatan game day atau table top bisa gagal menemukan perbedaan kuota layanan antar-Wilayah dan juga mempertahankan batas-batas yang tepat.
*Penyimpangan kuota layanan*, kondisi di mana batas kuota layanan untuk kuota bernama tertentu diubah di salah satu Wilayah tetapi tidak di semua Wilayah, sangat penting untuk dilacak dan dinilai. Mengubah kuota di Wilayah yang memiliki lalu lintas atau yang berpotensi mendatangkan lalu lintas harus dipertimbangkan.
+ Pilih Wilayah dan akun yang relevan berdasarkan persyaratan layanan, latensi, peraturan, dan pemulihan bencana (DR) Anda.
+ Identifikasikan kuota layanan di semua akun, Wilayah, dan Zona Ketersediaan yang relevan. Batasannya mencakup akun dan Wilayah. Nilai-nilai ini harus dibandingkan untuk mengetahui perbedaannya.
**Langkah implementasi**
+ Tinjau nilai Service Quotas yang mungkin telah melampaui level risiko penggunaan a. AWS Trusted Advisor menyediakan peringatan untuk pelanggaran 80% dan 90% ambang batas.
+ Tinjau nilai untuk kuota layanan di Wilayah Pasif mana pun (dalam desain Aktif/Pasif). Verifikasi bahwa muatan akan berhasil berjalan di dalam Wilayah sekunder apabila terjadi kegagalan di dalam Wilayah primer.
+ Otomatiskan penilaian jika penyelewengan kuota layanan apa pun telah terjadi antar-Wilayah di dalam akun yang sama dan lakukan tindakan yang semestinya untuk mengubah batas.
+ Jika Unit Organisasi (OU) pelanggan disusun dengan cara yang didukung, templat kuota layanan harus diperbarui agar mencerminkan perubahan pada kuota apa pun yang harus diterapkan ke beberapa Wilayah dan akun.
+ Buat templat dan kaitkan Wilayah dengan perubahan kuota.
+ Tinjau semua templat kuota layanan yang ada untuk mengetahui jika ada perubahan yang diperlukan (Wilayah, batas, dan akun).
## Sumber daya
**Praktik Terbaik Terkait:**
+ [REL01-BP01 Kesadaran tentang kuota dan kendala layanan](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP03 Mengakomodasi kuota layanan tetap dan kendala melalui arsitektur](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP04 Memantau dan mengelola kuota](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 Mengotomatiskan manajemen kuota](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 Memastikan adanya selisih yang memadai antara kuota saat ini dan penggunaan maksimum untuk mengakomodasi failover](rel_manage_service_limits_suff_buffer_limits.md)
+ [REL03-BP01 Memilih cara untuk menyegmentasi beban kerja](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Melakukan deployment beban kerja ke beberapa lokasi](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Mengotomatisasi pemulihan di semua lapisan](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 Menguji ketahanan menggunakan chaos engineering](rel_testing_resiliency_failure_injection_resiliency.md)
**Dokumen terkait:**
+ [ Pilar Keandalan Kerangka Kerja AWS Well-Architected: Ketersediaan ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [AWS Service Quotas (sebelumnya disebut batas layanan)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor Pemeriksaan Praktik Terbaik (lihat bagian Batas Layanan)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Pemantau batas AWS di AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Batas Layanan Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Apa itu Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [ Cara Meminta Peningkatan Kuota ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [ Endpoint dan kuota layanan ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+ [Panduan Pengguna Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [ Pemantau Kuota untuk AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [ Batas Isolasi Kesalahan AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Ketersediaan dengan redundansi ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [AWS untuk Data ](https://aws.amazon.com/data/)
+ [ Apa itu Integrasi Berkelanjutan? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ Apa itu Pengiriman Berkelanjutan? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Partner APN: partner yang dapat membantu manajemen konfigurasi ](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Mengelola siklus hidup akun di dalam lingkungan SaaS akun per tenant di AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)
+ [ Mengelola dan memanfatau throttling API di dalam beban kerja Anda ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ Lihat rekomendasi AWS Trusted Advisor pada skala besar dengan AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)
+ [ Mengotomatiskan Peningkatan Batas Layanan dan Dukungan Korporat dengan AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)
**Video terkait:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
+ [ Melihat dan Mengelola Kuota untuk Layanan AWS Menggunakan Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc)
+ [ Demo Kuota AWS IAM ](https://www.youtube.com/watch?v=srJ4jr6M9YQ)
**Layanan terkait:**
+ [ Amazon CodeGuru Reviewer ](https://aws.amazon.com/codeguru/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
# REL01-BP03 Mengakomodasi kuota layanan tetap dan kendala melalui arsitektur
Waspadai kuota layanan, kendala layanan, dan batas sumber daya fisik yang tidak dapat diubah. Rancang arsitektur untuk aplikasi dan layanan untuk mencegah batasan ini memengaruhi keandalan.
Contohnya antara lain bandwidth jaringan, ukuran payload invokasi fungsi nirserver, tingkat burst throttle untuk gateway API, dan sambungan pengguna serentak ke basis data.
**Hasil yang diinginkan:** Performa aplikasi atau layanan sesuai yang diharapkan dalam kondisi normal dan lalu lintas tinggi. Aplikasi dan layanan telah dirancang untuk berfungsi dengan batasan untuk kuota layanan atau kendala tetap sumber daya tersebut.
**Antipola umum:**
+ Memilih desain yang menggunakan sumber daya layanan, tidak menyadari bahwa terdapat kendala desain yang akan menyebabkan desain ini gagal begitu Anda menyesuaikan skala.
+ Melakukan tolok ukur yang tidak realistis dan akan mencapai kuota tetap layanan selama pengujian. Contohnya, menjalankan pengujian pada batas burst tetapi dalam jangka waktu yang lama.
+ Memilih desain yang tidak dapat diskalakan atau dimodifikasi jika kuota layanan tetap akan terlampaui. Contohnya, ukuran payload SQS sebesar 256 KB.
+ Observabilitas belum dirancang dan diimplementasikan untuk memantau dan memberikan peringatan tentang ambang batas kuota layanan yang mungkin berisiko selama lalu lintas sedang tinggi.
**Manfaat menjalankan praktik terbaik ini:** Verifikasi bahwa aplikasi akan beroperasi di bawah semua tingkat beban layanan yang diproyeksikan tanpa gangguan atau penurunan kualitas.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Tidak seperti sumber daya atau kuota layanan lunak yang diganti dengan unit kapasitas lebih tinggi, kuota tetap layanan AWS tidak dapat diubah. Ini berarti semua jenis layanan AWS ini harus dievaluasi untuk mengetahui potensi batas kapasitas keras ketika digunakan dalam desain aplikasi.
Batas keras ditunjukkan di konsol Service Quotas. Jika kolom menunjukkan `DAPAT DISESUAIKAN = Tidak`, layanan memiliki batas keras. Batas keras juga ditunjukkan di beberapa halaman konfigurasi sumber daya. Contohnya, Lambda memiliki batas keras spesifik yang tidak dapat disesuaikan.
Sebagai contoh, ketika mendesain aplikasi python untuk beroperasi dalam fungsi Lambda, aplikasi harus dievaluasi untuk menentukan apakah ada peluang Lambda akan beroperasi lebih lama dari 15 menit. Jika kode mungkin akan dijalankan lebih dari batas kuota layanan ini, desain atau teknologi lain harus dipertimbangkan. Jika batas ini tercapai setelah deployment produksi, aplikasi akan mengalami penurunan kualitas dan gangguan sampai dapat diperbaiki. Tidak seperti kuota lunak, tidak ada metode untuk mengubah batas-batas ini meskipun dalam kondisi darurat Keparahan 1.
Setelah aplikasi telah di-deploy ke lingkungan pengujian, strategi harus digunakan untuk menemukan apakah batas keras dapat tercapai. Pengujian stres, pengujian beban, dan pengujian kekacauan harus menjadi bagian dari rencana pengujian pendahuluan.
**Langkah implementasi**
+ Tinjau daftar lengkap layanan AWS yang dapat digunakan dalam fase desain aplikasi.
+ Tinjau batas kuota lunak dan batas kuota keras untuk semua layanan ini. Tidak semua batas ditunjukkan di konsol Service Quotas. Beberapa layanan [menjelaskan batas-batas ini di lokasi lain](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html).
+ Saat Anda mendesain aplikasi Anda, tinjau pendorong teknologi dan bisnis beban kerja Anda, seperti hasil bisnis, kasus penggunaan, sistem yang dependen, target ketersediaan, dan objek pemulihan bencana. Biarkan pendorong teknologi dan bisnis Anda memandu proses untuk mengidentifikasi sistem terdistribusi yang tepat untuk beban kerja Anda.
+ Analisis beban layanan di berbagai Wilayah dan akun. Banyak batas keras yang berbasis wilayah untuk layanan. Tetapi, beberapa batas berbasis akun.
+ Analisis arsitektur ketangguhan untuk penggunaan sumber daya selama kegagalan zona dan kegagalan Wilayah. Jika progres desain multi-Wilayah menggunakan pendekatan aktif/aktif, aktif/pasif - panas, aktif/pasif - dingin, dan aktif/pasif - pilot light, kasus-kasus kegagalan ini akan menyebabkan penggunaan yang lebih tinggi. Hal ini akan menimbulkan potensi kasus penggunaan untuk mencapai batas keras.
## Sumber daya
**Praktik Terbaik Terkait:**
+ [REL01-BP01 Kesadaran tentang kuota dan kendala layanan](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 Mengelola kuota layanan di seluruh akun dan wilayah](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP04 Memantau dan mengelola kuota](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 Mengotomatiskan manajemen kuota](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 Memastikan adanya selisih yang memadai antara kuota saat ini dan penggunaan maksimum untuk mengakomodasi failover](rel_manage_service_limits_suff_buffer_limits.md)
+ [REL03-BP01 Memilih cara untuk menyegmentasi beban kerja](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Melakukan deployment beban kerja ke beberapa lokasi](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Mengotomatisasi pemulihan di semua lapisan](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 Menguji ketahanan menggunakan chaos engineering](rel_testing_resiliency_failure_injection_resiliency.md)
**Dokumen terkait:**
+ [ Pilar Keandalan Kerangka Kerja AWS Well-Architected: Ketersediaan ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [AWS Service Quotas (sebelumnya disebut batas layanan)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor Pemeriksaan Praktik Terbaik (lihat bagian Batas Layanan)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Pemantau batas AWS di AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Batas Layanan Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Apa itu Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [ Cara Meminta Peningkatan Kuota ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [ Endpoint dan kuota layanan ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+ [Panduan Pengguna Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [ Pemantau Kuota untuk AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [ Batas Isolasi Kesalahan AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Ketersediaan dengan redundansi ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [AWS untuk Data ](https://aws.amazon.com/data/)
+ [ Apa itu Integrasi Berkelanjutan? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ Apa itu Pengiriman Berkelanjutan? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Partner APN: partner yang dapat membantu manajemen konfigurasi ](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Mengelola siklus hidup akun di dalam lingkungan SaaS akun per tenant di AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)
+ [ Mengelola dan memanfatau throttling API di dalam beban kerja Anda ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ Lihat rekomendasi AWS Trusted Advisor pada skala besar dengan AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)
+ [ Mengotomatiskan Peningkatan Batas Layanan dan Dukungan Korporat dengan AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)
+ [Tindakan, sumber daya, dan kunci kondisi untuk Service Quotas ](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html)
**Video terkait:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
+ [ Melihat dan Mengelola Kuota untuk Layanan AWS Menggunakan Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc)
+ [ Demo Kuota AWS IAM ](https://www.youtube.com/watch?v=srJ4jr6M9YQ)
+ [AWS re:Invent 2018: Menutup Lingkaran dan Membuka Pikiran: Cara Mengendalikan Sistem, Besar dan Kecil ](https://www.youtube.com/watch?v=O8xLxNje30M)
**Alat terkait:**
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
# REL01-BP04 Memantau dan mengelola kuota
Evaluasi potensi penggunaan Anda dan tingkatkan kuota dengan semestinya, sehingga terjadi pertumbuhan penggunaan sesuai rencana.
**Hasil yang diinginkan:** Sistem aktif dan otomatis yang mengelola dan memantau telah di-deploy. Solusi operasi ini memastikan ambang batas penggunaan kuota hampir dicapai. Hal ini akan secara proaktif diperbaiki oleh perubahan kuota yang diminta.
**Antipola umum:**
+ Tidak mengonfigurasi pemantauan untuk memeriksa ambang batas kuota layanan
+ Tidak mengonfigurasi pemantauan untuk batas keras, meskipun nilai-nilai tersebut tidak dapat diubah.
+ Berasumsi bahwa jumlah waktu yang diperlukan untuk meminta dan mendapatkan perubahan kuota lunak adalah segera atau singkat.
+ Mengonfigurasi alarm untuk ketika kuota layanan sudah dekat, namun tidak memiliki proses untuk merespons pemberitahuan.
+ Hanya mengonfigurasi alarm untuk layanan yang didukung oleh AWS Service Quotas dan tidak memantau layanan AWS lain.
+ Tidak mempertimbangkan manajemen kuota untuk beberapa desain ketangguhan Wilayah, seperti pendekatan aktif/aktif, aktif/pasif - panas, aktif/pasif - dingin, dan aktif/pasif - pilot light.
+ Tidak menilai perbedaan kuota antara Wilayah.
+ Tidak menilai kebutuhan di setiap Wilayah untuk permintaan peningkatan kuota spesifik.
+ Tidak memanfaatkan templat [ untuk manajemen kuota multi-Wilayah](https://docs.aws.amazon.com/servicequotas/latest/userguide/organization-templates.html).
**Manfaat menjalankan praktik terbaik ini:** Dengan melacak AWS Service Quotas secara otomatis dan memantau penggunaan Anda berdasarkan kuota tersebut, Anda dapat mengetahui ketika batas kuota hampir terpenuhi. Anda juga dapat menggunakan data pemantauan ini untuk membantu membatasi penurunan kualitas karena kehabisan kuota.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Untuk layanan yang didukung, Anda dapat memantau kuota Anda dengan mengonfigurasikan berbagai layanan yang berbeda yang dapat menilai kemudian mengirimkan pemberitahuan atau alarm. Hal ini dapat membantu memantau penggunaan dan dapat memberitahukan kuota yang akan habis kepada Anda. Alarm ini dapat dipicu dari AWS Config, fungsi Lambda, Amazon CloudWatch, atau dari AWS Trusted Advisor. Anda juga dapat menggunakan filter metrik di Log CloudWatch untuk mencari dan mengekstrak pola dalam log untuk menentukan apakah penggunaan sudah mendekati ambang batas kuota.
**Langkah implementasi**
Untuk pemantauan:
+ Catat pemakaian sumber daya saat ini (misalnya, bucket atau instans). Gunakan operasi API layanan, seperti Amazon EC2 `DescribeInstances` API, untuk mengumpulkan pemakaian sumber daya saat ini.
+ Catat kuota saat ini yang penting dan berlaku untuk layanan menggunakan:
+ AWS Service Quotas
+ AWS Trusted Advisor
+ Dokumentasi AWS
+ Halaman spesifik layanan AWS
+ AWS Command Line Interface (AWS CLI)
+ AWS Cloud Development Kit (AWS CDK)
+ Gunakan AWS Service Quotas, yakni layanan AWS yang membantu Anda mengelola kuota untuk lebih dari 250 layanan AWS dari satu lokasi.
+ Gunakan batas layanan Trusted Advisor untuk memantau batas layanan Anda saat ini di berbagai ambang batas.
+ Gunakan riwayat kuota layanan (konsol atau AWS CLI) untuk memeriksa peningkatan regional.
+ Bandingkan perubahan kuota layanan di setiap Wilayah dan setiap akun untuk membuat kesetaraan, jika diperlukan.
Untuk manajemen:
+ Otomatis: Siapkan aturan kustom AWS Config untuk memindai kuota layanan di berbagai Wilayah dan bandingkan untuk mengetahui perbedaannya.
+ Otomatis: Siapkan fungsi Lambda terjadwal untuk memindai kuota layanan di berbagai Wilayah dan bandingkan untuk mengetahui perbedaannya.
+ Manual: Pindai kuota layanan melalui AWS CLI, API, atau Konsol AWS untuk memindai kuota layanan di berbagai Wilayah dan bandingkan untuk mengetahui perbedaannya. Laporkan perbedaannya.
+ Jika perbedaan kuota diidentifikasi antara Wilayah, minta perubahan kuota, jika perlu.
+ Tinjau hasil dari semua permintaan.
## Sumber daya
**Praktik Terbaik Terkait:**
+ [REL01-BP01 Kesadaran tentang kuota dan kendala layanan](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 Mengelola kuota layanan di seluruh akun dan wilayah](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP03 Mengakomodasi kuota layanan tetap dan kendala melalui arsitektur](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP05 Mengotomatiskan manajemen kuota](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 Memastikan adanya selisih yang memadai antara kuota saat ini dan penggunaan maksimum untuk mengakomodasi failover](rel_manage_service_limits_suff_buffer_limits.md)
+ [REL03-BP01 Memilih cara untuk menyegmentasi beban kerja](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Melakukan deployment beban kerja ke beberapa lokasi](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Mengotomatisasi pemulihan di semua lapisan](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 Menguji ketahanan menggunakan chaos engineering](rel_testing_resiliency_failure_injection_resiliency.md)
**Dokumen terkait:**
+ [ Pilar Keandalan Kerangka Kerja AWS Well-Architected: Ketersediaan ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [AWS Service Quotas (sebelumnya disebut batas layanan)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor Pemeriksaan Praktik Terbaik (lihat bagian Batas Layanan)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Pemantau batas AWS di AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Batas Layanan Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Apa itu Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [ Cara Meminta Peningkatan Kuota ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [ Endpoint dan kuota layanan ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+ [Panduan Pengguna Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [ Pemantau Kuota untuk AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [ Batas Isolasi Kesalahan AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Ketersediaan dengan redundansi ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [AWS untuk Data ](https://aws.amazon.com/data/)
+ [ Apa itu Integrasi Berkelanjutan? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ Apa itu Pengiriman Berkelanjutan? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Partner APN: partner yang dapat membantu manajemen konfigurasi ](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Mengelola siklus hidup akun di dalam lingkungan SaaS akun per tenant di AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)
+ [ Mengelola dan memanfatau throttling API di dalam beban kerja Anda ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ Lihat rekomendasi AWS Trusted Advisor pada skala besar dengan AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)
+ [ Mengotomatiskan Peningkatan Batas Layanan dan Dukungan Korporat dengan AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)
+ [Tindakan, sumber daya, dan kunci kondisi untuk Service Quotas ](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html)
**Video terkait:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
+ [ Melihat dan Mengelola Kuota untuk Layanan AWS Menggunakan Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc)
+ [ Demo Kuota AWS IAM ](https://www.youtube.com/watch?v=srJ4jr6M9YQ)
+ [AWS re:Invent 2018: Menutup Lingkaran dan Membuka Pikiran: Cara Mengendalikan Sistem, Besar dan Kecil ](https://www.youtube.com/watch?v=O8xLxNje30M)
**Alat terkait:**
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
# REL01-BP05 Mengotomatiskan manajemen kuota
Implementasikan alat untuk memperingatkan Anda saat ambang batas terlampaui. Anda dapat mengotomatiskan permintaan peningkatan kuota dengan menggunakan API AWS Service Quotas, Anda dapat mengotomatiskan permintaan peningkatan kuota.
Jika Anda mengintegrasikan Basis Data Manajemen Konfigurasi (CMDB) atau sistem ticketing dengan Service Quotas, Anda dapat mengotomatiskan permintaan peningkatan kuota dan kuota saat ini. Selain SDK AWS, Service Quotas menawarkan otomatisasi menggunakan AWS Command Line Interface (AWS CLI).
**Antipola umum:**
+ Melacak kuota dan penggunaan dalam spreadsheet.
+ Menjalankan laporan pada penggunaan harian, mingguan, bulanan, lalu membandingkan penggunaan dengan kuota.
**Manfaat menerapkan praktik terbaik ini:** Dengan pelacakan kuota layanan AWS dan pemantauan terhadap penggunaan kuota, Anda dapat mengetahui ketika kuota hampir penuh. Anda dapat mengatur otomatisasi untuk membantu meminta peningkatan kuota saat diperlukan. Anda dapat mempertimbangkan pengurangan kuota saat penggunaan Anda cenderung tidak selaras untuk benar-benar mengoptimalkan manfaat dari pengurangan risiko (dalam kasus kredensial yang disusupi) dan penghematan biaya.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Atur pemantauan otomatis: Implementasikan alat dengan menggunakan SDK untuk memperingatkan saat ambang batas terlampaui.
+ Gunakan Service Quotas dan tingkatkan layanan dengan solusi pemantauan kuota otomatis, seperti AWS Limit Monitor atau penawaran dari AWS Marketplace.
+ [Apa itu Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [Monitor Kuota di AWS - Solusi AWS](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ Atur respons terpicu berdasarkan ambang batas kuota menggunakan Amazon SNS dan API AWS Service Quotas.
+ Uji otomatisasi.
+ Konfigurasikan ambang batas.
+ Integrasikan dengan peristiwa perubahan dari AWS Config, pipeline deployment, Amazon EventBridge, atau pihak ketiga.
+ Atur ambang batas kuota rendah secara artifisial untuk menguji respons.
+ Atur pemicu untuk mengambil tindakan yang sesuai berdasarkan notifikasi dan hubungi AWS Dukungan jika diperlukan.
+ Picu peristiwa perubahan secara manual.
+ Jalankan game day untuk menguji proses perubahan peningkatan kuota.
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu manajemen konfigurasi](https://aws.amazon.com/partners/find/results/?keyword=Configuration+Management)
+ [AWS Marketplace: Produk CMDB yang membantu melacak batasan](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (yang sebelumnya dikenal sebagai batas layanan)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Pemeriksaan Praktik Terbaik AWS Trusted Advisor (lihat bagian Batas Layanan)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Monitor Kuota di AWS - Solusi AWS](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Batas Layanan Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Apa itu Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Video terkait:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP06 Memastikan adanya selisih yang memadai antara kuota saat ini dan penggunaan maksimum untuk mengakomodasi failover
Ketika sumber daya gagal atau tidak dapat diakses, sumber daya tersebut mungkin masih dihitung untuk kuota sampai berhasil dihentikan. Verifikasi apakah kuota meliputi tumpang tindih sumber daya yang gagal atau tidak dapat diakses dan penggantiannya. Anda harus mempertimbangkan kasus penggunaan seperti kegagalan jaringan, kegagalan Zona Ketersediaan, atau kegagalan Wilayah ketika menghitung selisih ini.
**Hasil yang diinginkan:** Kegagalan kecil atau besar dalam sumber daya atau kemampuan akses sumber daya dapat diatasi dalam ambang batas layanan saat ini. Kegagalan zona, kegagalan jaringan, atau bahkan kegagalan Wilayah telah dipertimbangkan dalam perencanaan sumber daya.
**Antipola umum:**
+ Mengatur kuota layanan berdasarkan kebutuhan saat ini tanpa memperhitungkan skenario failover.
+ Tidak mempertimbangkan prinsipal stabilitas statis ketika menghitung kuota puncak untuk layanan.
+ Tidak mempertimbangkan potensi sumber daya yang tidak dapat diakses dalam menghitung kuota total yang diperlukan untuk setiap Wilayah.
+ Tidak mempertimbangkan batas isolasi kesalahan layanan AWS untuk beberapa layanan dan potensi pola penggunaan abnormalnya.
**Manfaat menjalankan praktik terbaik ini:** Ketika peristiwa gangguan layanan memengaruhi ketersediaan aplikasi, cloud memungkinkan Anda untuk mengimplementasikan strategi guna memitigasi atau memulihkan dari peristiwa ini. Strategi tersebut sering kali mencakup pembuatan sumber daya tambahan untuk menggantikan sumber daya yang gagal atau tidak dapat diakses. Strategi kuota Anda akan mengakomodasi kondisi failover ini dan tidak menambahkan lapisan degradasi tambahan akibat tercapainya batas layanan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Ketika mengevaluasi batas kuota, pertimbangkan kasus failover yang dapat terjadi karena degradasi. Jenis kasus failover berikut ini harus dipertimbangkan:
+ VPC yang terganggu atau tidak dapat diakses.
+ Subnet yang tidak dapat diakses.
+ Zona Ketersediaan telah cukup mengalami degradasi sehingga memengaruhi kemampuan akses banyak sumber daya.
+ Berbagai titik keluar dan masuk atau rute jaringan terblokir atau berubah.
+ Wilayah telah cukup mengalami degradasi sehingga memengaruhi kemampuan akses banyak sumber daya.
+ Ada beberapa sumber daya tetapi tidak semua terpengaruh oleh kegagalan di Wilayah atau Zona Ketersediaan.
Kegagalan seperti yang tercantum di atas dapat menjadi pemicu awal terjadinya peristiwa failover. Keputusan untuk failover bersifat unik untuk setiap situasi dan pelanggan, karena dampak bisnisnya bisa sangat berbeda. Tetapi, ketika memutuskan untuk failover aplikasi atau layanan secara operasional, perencanaan kapasitas sumber daya di lokasi failover dan kuota terkait harus ditangani sebelum peristiwa terjadi.
Tinjau kuota layanan untuk setiap layanan dengan mempertimbangkan puncak yang lebih tinggi dari normal yang mungkin terjadi. Puncak ini mungkin terkait dengan sumber daya yang dapat dicapai karena jaringan atau izin tetapi masih aktif. Sumber daya aktif yang tidak dihentikan akan masih dihitung untuk memenuhi batas kuota layanan.
**Langkah implementasi**
+ Verifikasi bahwa ada selisih yang memadai antara kuota layanan saat ini dan penggunaan maksimum untuk mengakomodasi failover atau hilangnya kemampuan akses.
+ Tentukan kuota layanan, perhitungkan pola deployment, persyaratan ketersediaan, dan peningkatan pemakaian.
+ Minta peningkatan kuota jika perlu. Rencanakan waktu yang diperlukan agar permintaan peningkatan kuota dapat terpenuhi.
+ Tentukan persyaratan keandalan (juga disebut sebagai jumlah angka sembilan Anda).
+ Tetapkan skenario kesalahan (misalnya kehilangan komponen, Zona Ketersediaan, atau Wilayah).
+ Tetapkan metodologi deployment (misalnya canary, blue/green, red/black, atau rolling).
+ Sertakan buffer yang sesuai (misalnya, 15%) ke batas saat ini.
+ Sertakan perhitungan untuk stabilitas statis (Zona dan Wilayah) apabila sesuai.
+ Rencanakan peningkatan pemakaian (misalnya, memantau tren pemakaian).
+ Pertimbangkan dampak stabilitas statis untuk beban kerja Anda yang paling penting. Nilai sumber daya yang sesuai dengan sistem stabil secara statis di semua Wilayah dan Zona Ketersediaan.
+ Pertimbangkan penggunaan Reservasi Kapasitas Sesuai Permintaan untuk menjadwalkan kapasitas sebelum failover. Hal ini dapat menjadi strategi yang bermanfaat untuk penjadwalan bisnis yang paling penting guna mengurangi potensi risiko mendapatkan kuantitas dan jenis sumber daya yang benar selama failover.
## Sumber daya
**Praktik Terbaik Terkait:**
+ [REL01-BP01 Kesadaran tentang kuota dan kendala layanan](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 Mengelola kuota layanan di seluruh akun dan wilayah](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP03 Mengakomodasi kuota layanan tetap dan kendala melalui arsitektur](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP04 Memantau dan mengelola kuota](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 Mengotomatiskan manajemen kuota](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL03-BP01 Memilih cara untuk menyegmentasi beban kerja](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Melakukan deployment beban kerja ke beberapa lokasi](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Mengotomatisasi pemulihan di semua lapisan](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 Menguji ketahanan menggunakan chaos engineering](rel_testing_resiliency_failure_injection_resiliency.md)
**Dokumen terkait:**
+ [ Pilar Keandalan Kerangka Kerja AWS Well-Architected: Ketersediaan ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [AWS Service Quotas (sebelumnya disebut batas layanan)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor Pemeriksaan Praktik Terbaik (lihat bagian Batas Layanan)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Pemantau batas AWS di AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Batas Layanan Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Apa itu Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [ Cara Meminta Peningkatan Kuota ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [ Endpoint dan kuota layanan ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+ [Panduan Pengguna Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [ Pemantau Kuota untuk AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [ Batas Isolasi Kesalahan AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Ketersediaan dengan redundansi ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [AWS untuk Data ](https://aws.amazon.com/data/)
+ [ Apa itu Integrasi Berkelanjutan? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ Apa itu Pengiriman Berkelanjutan? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Partner APN: partner yang dapat membantu manajemen konfigurasi ](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Mengelola siklus hidup akun di dalam lingkungan SaaS akun per tenant di AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)
+ [ Mengelola dan memanfatau throttling API di dalam beban kerja Anda ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ Lihat rekomendasi AWS Trusted Advisor pada skala besar dengan AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)
+ [ Mengotomatiskan Peningkatan Batas Layanan dan Dukungan Korporat dengan AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)
+ [Tindakan, sumber daya, dan kunci kondisi untuk Service Quotas ](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html)
**Video terkait:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
+ [ Melihat dan Mengelola Kuota untuk Layanan AWS Menggunakan Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc)
+ [ Demo Kuota AWS IAM ](https://www.youtube.com/watch?v=srJ4jr6M9YQ)
+ [AWS re:Invent 2018: Menutup Lingkaran dan Membuka Pikiran: Cara Mengendalikan Sistem, Besar dan Kecil ](https://www.youtube.com/watch?v=O8xLxNje30M)
**Alat terkait:**
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
# REL 2. Bagaimana cara merencanakan topologi jaringan Anda?
Sering kali beban kerja ada di beberapa lingkungan. Ini termasuk beberapa lingkungan cloud (baik yang dapat diakses publik maupun privat) dan kemungkinan infrastruktur pusat data Anda yang ada. Rencana harus mencakup pertimbangan jaringan seperti konektivitas di dalam dan antarsistem, pengelolaan alamat IP publik, pengelolaan alamat IP privat, dan resolusi nama domain.
**Topics**
+ [REL02-BP01 Menggunakan konektivitas jaringan dengan ketersediaan tinggi untuk titik akhir publik beban kerja Anda](rel_planning_network_topology_ha_conn_users.md)
+ [REL02-BP02 Menyediakan konektivitas redundan antara jaringan privat di cloud dan lingkungan on-premise](rel_planning_network_topology_ha_conn_private_networks.md)
+ [REL02-BP03 Pastikan alokasi subnet IP menjelaskan ekspansi dan ketersediaan](rel_planning_network_topology_ip_subnet_allocation.md)
+ [REL02-BP04 Mengutamakan topologi hub-and-spoke daripada mesh many-to-many](rel_planning_network_topology_prefer_hub_and_spoke.md)
+ [REL02-BP05 Terapkan rentang alamat IP privat yang tidak tumpang tindih di semua ruang alamat privat tempat semuanya terhubung](rel_planning_network_topology_non_overlap_ip.md)
# REL02-BP01 Menggunakan konektivitas jaringan dengan ketersediaan tinggi untuk titik akhir publik beban kerja Anda
Membuat konektivitas jaringan dengan ketersediaan tinggi untuk titik akhir publik beban kerja Anda dapat membantu Anda mengurangi waktu henti karena hilangnya konektivitas dan meningkatkan ketersediaan serta SLA beban kerja Anda. Untuk mencapai ini, gunakan DNS dengan ketersediaan tinggi, jaringan pengiriman konten (CDN), gateway API, penyeimbangan beban, atau proksi mundur.
**Hasil yang diinginkan:** Sangat penting untuk merencanakan, membuat, dan mengoperasikan konektivitas jaringan dengan ketersediaan tinggi untuk titik akhir publik Anda. Jika beban kerja Anda menjadi tidak terjangkau karena hilangnya konektivitas, meskipun beban kerja Anda beroperasi dan tersedia, pelanggan Anda akan menganggap sistem Anda tidak berfungsi. Dengan menggabungkan konektivitas jaringan yang tangguh dan memiliki ketersediaan tinggi untuk titik akhir publik beban kerja Anda, bersama dengan arsitektur tangguh untuk beban kerja itu sendiri, Anda dapat memberikan tingkat layanan dan ketersediaan yang sebaik mungkin untuk pelanggan Anda.
AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway, URL Fungsi AWS Lambda, AWS AppSync API, dan Elastic Load Balancing (ELB) memberikan titik akhir publik dengan ketersediaan tinggi. Amazon Route 53 memberikan layanan DNS dengan ketersediaan tinggi untuk resolusi nama domain guna memverifikasi bahwa alamat titik akhir publik Anda dapat diatur.
Anda juga dapat mengevaluasi peralatan perangkat lunak AWS Marketplace untuk penyeimbangan beban dan proksi.
**Antipola umum:**
+ Mendesain beban kerja dengan ketersediaan tinggi tanpa merencanakan konektivitas jaringan dan DNS untuk ketersediaan tinggi.
+ Menggunakan alamat internet publik di instans atau kontainer secara individu dan mengelola konektivitasnya dengan DNS.
+ Menggunakan alamat IP dan bukannya nama domain untuk mencari layanan.
+ Tidak menguji skenario di mana konektivitas ke titik akhir publik Anda hilang.
+ Tidak menganalisis pola distribusi dan kebutuhan throughput jaringan.
+ Tidak menguji dan merencanakan skenario di mana konektivitas jaringan internet ke titik akhir publik beban kerja Anda mungkin terganggu.
+ Memberikan konten (seperti halaman web, aset statis, atau file media) ke area geografis besar dan tidak menggunakan CDN.
+ Tidak membuat rencana untuk serangan penolakan layanan terdistribusi (DDoS). Serangan DDoS berisiko menghalangi lalu lintas sah dan menurunkan ketersediaan untuk pengguna Anda.
**Manfaat menjalankan praktik terbaik ini:** Mendesain konektivitas jaringan yang tangguh dan memiliki ketersediaan tinggi memastikan beban kerja Anda dapat diakses dan tersedia bagi pengguna.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Inti dari pembuatan konektivitas jaringan dengan ketersediaan tinggi untuk titik akhir publik adalah pengarahan rute lalu lintas. Untuk memverifikasi lalu lintas Anda dapat menjangkau titik akhir, DNS harus dapat mengatur nama domain ke alamat IP-nya yang bersangkutan. Gunakan [Sistem Nama Domain (DNS)](https://aws.amazon.com/route53/what-is-dns/) yang dapat diskalakan dan memiliki ketersediaan tinggi seperti Amazon Route 53 untuk mengelola data DNS domain Anda. Anda juga dapat menggunakan pemeriksaan kondisi yang disediakan oleh Amazon Route 53. Pemeriksaan kondisi memverifikasi bahwa aplikasi Anda dapat dijangkau, tersedia, dan berfungsi, dan pemeriksaan ini dapat diatur sedemikian sehingga menyerupai perilaku pengguna Anda, seperti meminta halaman web atau URL tertentu. Jika terjadi kegagalan, Amazon Route 53 merespons permintaan resolusi DNS dan mengarahkan lalu lintas ke titik akhir dengan kondisi bagus saja. Anda juga dapat mempertimbangkan penggunaan kemampuan Perutean Berbasis Latensi dan DNS Geo yang ditawarkan oleh Amazon Route 53.
Untuk memverifikasi bahwa beban kerja itu sendiri memiliki ketersediaan tinggi, gunakan Elastic Load Balancing (ELB). Amazon Route 53 dapat digunakan untuk menargetkan lalu lintas ke ELB, yang mendistribusikan lalu lintas ke instans komputasi target. Anda juga dapat menggunakan Amazon API Gateway bersama dengan AWS Lambda untuk solusi nirserver. Pelanggan juga dapat menjalankan beban kerja di beberapa Wilayah AWS. Dengan [pola aktif/aktif multi-lokasi](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/), beban kerja dapat menghadirkan lalu lintas dari beberapa Wilayah. Dengan pola aktif/pasif multi-lokasi, beban kerja menghadirkan lalu lintas dari wilayah aktif sementara data direplikasikan ke wilayah sekunder dan menjadi aktif untuk berjaga-jaga jika terjadi kegagalan di wilayah utama. Kemudian pemeriksaan kondisi Route 53 dapat digunakan untuk mengontrol failover DNS dari titik akhir mana pun di Wilayah utama ke titik akhir di Wilayah sekunder, dengan memverifikasi bahwa beban kerja Anda dapat dijangkau dan tersedia bagi pengguna Anda.
Amazon CloudFront memberikan API sederhana untuk mendistribusikan konten dengan laju transfer data tinggi dan latensi rendah dengan melayani permintaan menggunakan jaringan lokasi edge di seluruh dunia. Jaringan pengiriman konten (CDN) melayani pelanggan dengan menghadirkan konten yang berada di atau di-cache di lokasi yang dekat dengan pengguna. Hal ini juga meningkatkan ketersediaan aplikasi Anda karena beban untuk konten dialihkan dari server Anda ke CloudFront, yakni ke [lokasi edge](https://aws.amazon.com/products/networking/edge-networking/)-nya. Lokasi edge dan cache edge regional menyimpan cache salinan konten Anda dekat dengan penonton Anda sehingga konten dapat diambil dengan cepat, konten lebih mudah dijangkau, dan beban kerja memiliki ketersediaan lebih tinggi.
Untuk beban kerja dengan pengguna yang tersebar secara geografis,AWS Global Accelerator membantu Anda meningkatkan ketersediaan dan performa aplikasi. AWS Global Accelerator memberikan alamat IP statis Anycast yang berfungsi sebagai titik masuk tetap ke aplikasi Anda yang di-host di satu atau lebih Wilayah AWS. Hal ini memungkinkan lalu lintas masuk ke jaringan global AWS sedekat mungkin ke pengguna Anda, yang meningkatkan keterjangkauan dan ketersediaan beban kerja Anda. AWS Global Accelerator juga memantau kondisi titik akhir aplikasi Anda menggunakan TCP, HTTP, dan pemeriksaan kondisi HTTPS. Setiap perubahan kondisi atau konfigurasi titik akhir Anda memicu pengarahan ulang lalu lintas pengguna ke titik akhir dengan kondisi bagus yang memberikan ketersediaan dan performa terbaik bagi pengguna Anda. Selain itu, AWS Global Accelerator memiliki desain yang mengisolasi kesalahan yang menggunakan dua alamat IPv4 status yang dilayani oleh zona jaringan mandiri sehingga meningkatkan ketersediaan aplikasi Anda.
Untuk membantu melindungi pelanggan dari serangan DDoS, AWS memberikan AWS Shield Standard. Shield Standard tersedia sudah secara otomatis diaktifkan dan melindungi dari serangan infrastruktur umum (lapisan 3 dan 4) seperti SYN/UDP flood dan serangan refleksi untuk mendukung ketersediaan tinggi aplikasi Anda di AWS. Untuk perlindungan tambahan dari serangan yang lebih besar dan lebih canggih (seperti UDP flood), serangan penghentian layanan (seperti TCP SYN flood), dan untuk membantu melindungi aplikasi Anda dijalankan di Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator, dan Route 53, Anda dapat mempertimbangkan penggunaan AWS Shield Advanced. Untuk perlindungan dari serangan lapisan Aplikasi seperti HTTP POST atau GET flood, gunakan AWS WAF. AWS WAF dapat menggunakan alamat IP, header HTTP, bodi HTTP, string URI, injeksi SQL, dan kondisi skrip lintas situs untuk menentukan apakah permintaan harus diblokir atau diizinkan.
**Langkah implementasi**
1. Siapkan DNS dengan ketersediaan tinggi: Amazon Route 53 adalah layanan web [sistem nama domain (DNS)](https://aws.amazon.com/route53/what-is-dns/) yang dapat diskalakan dan memiliki ketersediaan tinggi. Route 53 menghubungkan permintaan pengguna dengan aplikasi internet yang dijalankan di AWS atau on-premise. Untuk informasi selengkapnya, lihat [mengonfigurasi Amazon Route 53 sebagai layanan DNS Anda](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring.html).
1. Siapkan pemeriksaan kondisi: Ketika menggunakan Route 53, verifikasi bahwa hanya target dengan kondisi bagus yang dapat diselesaikan. Mulai dengan [membuat pemeriksaan kondisi Route 53 dan mengonfigurasi failover DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html). Aspek-aspek berikut penting untuk dipertimbangkan ketika mempersiapkan pemeriksaan kondisi:
1. [ Bagaimana Amazon Route 53 menentukan apakah pemeriksaan kondisi bagus ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-determining-health-of-endpoints.html)
1. [ Membuat, memperbarui, dan menghapus pemeriksaan kondisi](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html)
1. [Memantau status pemeriksaan kondisi dan mendapatkan pemberitahuan ](https://docs.aws.amazon.com/)
1. [Praktik terbaik untuk Amazon Route 53 DNS ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-monitor-view-status.html)
1. [ Hubungkan layanan DNS Anda ke titik akhir Anda. ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html)
1. Ketika menggunakan Elastic Load Balancing sebagai target untuk lalu lintas Anda, buat [catatan alias](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html) menggunakan Amazon Route 53 yang menunjuk ke titik akhir wilayah penyeimbang beban Anda. Selama pembuatan catatan alias, atur opsi Evaluasi kondisi target ke Ya.
1. Untuk beban kerja nirserver atau API privat ketika API Gateway digunakan, gunakan [Route 53 untuk mengarahkan lalu lintas ke API Gateway](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html).
1. Tentukan jaringan pengiriman konten.
1. Untuk pengiriman konten menggunakan lokasi edge yang lebih dekat dengan pengguna, mulai dengan memahami [cara CloudFront memberikan konten](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowCloudFrontWorks.html).
1. Mulai dengan [distribusi CloudFront sederhana](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.SimpleDistribution.html). Kemudian CloudFront mengetahui dari mana Anda ingin konten dikirimkan, dan detail tentang cara melacak dan mengelola pengiriman konten. Aspek-aspek berikut penting untuk dipahami dan dipertimbangkan ketika mempersiapkan distribusi CloudFront:
1. [ Cara kerja caching dengan lokasi edge CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio-explained.html)
1. [ Meningkatkan proporsi permintaan yang dihadirkan secara langsung dari cache CloudFront (rasio sukses cache) ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio.html)
1. [ Menggunakan Amazon CloudFront Origin Shield ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html)
1. [ Mengoptimalkan ketersediaan tinggi dengan failover asalah CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)
1. Siapkan perlindungan lapisan aplikasi: AWS WAF membantu Anda melindungi dari bot dan eksploitasi web umum yang dapat memengaruhi ketersediaan, mengancam keamanan, atau memakai sumber daya secara berlebihan. Untuk mendapatkan pemahaman lebih mendalam, tinjau [cara kerja AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/how-aws-waf-works.html) dan kapan Anda siap untuk mengimplementasikan perlindungan dari HTTP POST DAN GET flood lapisan aplikasi, tinjau [Memulai AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html). Anda juga dapat menggunakan AWS WAF dengan CloudFront, lihat dokumentasi tentang [cara AWS WAF berfungsi dengan fitur Amazon CloudFront](https://docs.aws.amazon.com/waf/latest/developerguide/cloudfront-features.html).
1. Siapkan perlindungan DDoS tambahan: Menurut default, semua pelanggan AWS menerima perlindungan dari serangan DDoS lapisan transpor dan jaringan paling sering terjadi yang menargetkan situs web atau aplikasi Anda, dengan menggunakan AWS Shield Standard tanpa biaya tambahan. Untuk perlindungan tambahan aplikasi yang dilihat internet, dijalankan di Amazon EC2, Elastic Load Balancing, Amazon CloudFront, AWS Global Accelerator, dan Amazon Route 53, Anda dapat mempertimbangkan [AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-summary.html) dan meninjau contoh [ tentang arsitektur yang tangguh terhadap DDoS](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-resiliency.html). Untuk melindungi beban kerja dan titik akhir publik Anda dari serangan DDoS, tinjau [Memulai dengan AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-ddos.html).
## Sumber daya
**Praktik Terbaik Terkait:**
+ [REL10-BP01 Melakukan deployment beban kerja ke beberapa lokasi](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Memilih lokasi yang sesuai untuk deployment multilokasi](rel_fault_isolation_select_location.md)
+ [REL11-BP04 Mengandalkan bidang data dan bukan bidang kendali selama pemulihan](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP06 Mengirimkan notifikasi ketika peristiwa memengaruhi ketersediaan](rel_withstand_component_failures_notifications_sent_system.md)
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu merencanakan jaringan Anda](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Marketplace untuk Infrastruktur Jaringan](https://aws.amazon.com/marketplace/b/2649366011)
+ [Apa Itu AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Apa itu Amazon CloudFront?](https://docs.aws.amazon.com/Amazon/latest/DeveloperGuide/Introduction.html)
+ [Apa itu Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [Apa itu Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [ Kemampuan Konektivitas Jaringan - Menetapkan Fondasi Cloud Anda ](https://docs.aws.amazon.com/whitepapers/latest/establishing-your-cloud-foundation-on-aws/network-connectivity-capability.html)
+ [ Apa itu Amazon API Gateway? ](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)
+ [ Apa itu AWS WAF, AWS Shield, dan AWS Firewall Manager? ](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html)
+ [ Apa itu Pengontrol Pemulihan Aplikasi Amazon Route 53? ](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [ Konfigurasi pemeriksaan kondisi kustom untuk failover DNS ](https://docs.aws.amazon.com/apigateway/latest/developerguide/dns-failover.html)
**Video terkait:**
+ [AWS re:Invent 2022 - Meningkatkan performa dan ketersediaan dengan AWS Global Accelerator](https://www.youtube.com/watch?v=s5sjsdDC0Lg)
+ [AWS re:Invent 2020: Manajemen lalu lintas global dengan Amazon Route 53 ](https://www.youtube.com/watch?v=E33dA6n9O7I)
+ [AWS re:Invent 2022 - Mengoperasikan aplikasi Multi-AZ dengan ketersediaan tinggi ](https://www.youtube.com/watch?v=mwUV5skJJ0s)
+ [AWS re:Invent 2022 - Memahami infrastruktur jaringan AWS](https://www.youtube.com/watch?v=HJNR_dX8g8c)
+ [AWS re:Invent 2022 - Membangun jaringan tangguh ](https://www.youtube.com/watch?v=u-qamiNgH7Q)
**Contoh terkait:**
+ [ Pemulihan Bencana dengan Pengontrol Pemulihan Aplikasi (ARC) Amazon Route 53](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)
+ [ Lokakarya Keandalan ](https://wellarchitectedlabs.com/reliability/)
+ [ Lokakarya AWS Global Accelerator](https://catalog.us-east-1.prod.workshops.aws/workshops/effb1517-b193-4c59-8da5-ce2abdb0b656/en-US)
# REL02-BP02 Menyediakan konektivitas redundan antara jaringan privat di cloud dan lingkungan on-premise
Gunakan beberapa koneksi AWS Direct Connect atau terowongan VPN antara jaringan privat yang di-deploy secara terpisah. Gunakan beberapa lokasi Direct Connect untuk ketersediaan tinggi. Ketika menggunakan beberapa Wilayah AWS, pastikan ada redundansi setidaknya di dalam dua di antaranya. Anda dapat mengevaluasi peralatan AWS Marketplace yang menghentikan VPN. Ketika menggunakan peralatan AWS Marketplace, lakukan deployment instans redundan untuk ketersediaan tinggi di Zona Ketersediaan yang berbeda.
AWS Direct Connect adalah layanan cloud yang memudahkan Anda menetapkan koneksi jaringan khusus dari lingkungan on-premise ke AWS. Dengan menggunakan Gateway Direct Connect, pusat data on-premise dapat dihubungkan ke beberapa VPC AWS yang tersebar di seluruh Wilayah AWS.
Redundansi ini menangani kemungkinan kesalahan yang berdampak pada ketangguhan konektivitas:
+ Bagaimana cara bertahan dari kesalahan dalam topologi?
+ Apa yang terjadi jika Anda salah mengonfigurasi sesuatu dan menghapus konektivitas?
+ Apakah Anda akan mampu untuk menangani peningkatan lalu lintas atau penggunaan layanan yang tidak terduga?
+ Apakah Anda akan mampu untuk menahan percobaan serangan Distributed Denial of Service (DDoS)?
Saat menghubungkan VPC ke pusat data on-premise melalui VPN, sebaiknya pertimbangkan persyaratan ketahanan dan bandwidth yang diperlukan ketika memilih vendor dan ukuran instans yang dibutuhkan untuk menjalankan peralatan. Jika Anda menggunakan perangkat VPN yang tidak tangguh dalam implementasinya, maka Anda harus memiliki koneksi redundan melalui perangkat kedua. Untuk semua skenario ini, Anda perlu menentukan waktu yang dapat diterima untuk pemulihan dan pengujian guna memastikan bahwa Anda memenuhi persyaratan tersebut.
Jika Anda memilih untuk menghubungkan VPC ke pusat data menggunakan koneksi Direct Connect dan koneksi ini harus selalu tersedia, gunakan koneksi Direct Connect yang redundan dari setiap pusat data. Koneksi redundan harus menggunakan koneksi Direct Connect kedua yang berbeda lokasi dengan yang pertama. Jika Anda memiliki beberapa pusat data, pastikan bahwa koneksinya berakhir di lokasi yang berbeda. Gunakan [Kit Alat Ketahanan Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) untuk membantu menyiapkan ini.
Jika Anda memilih untuk melakukan failover VPN melalui internet menggunakan Site-to-Site VPN, penting untuk dipahami bahwa hal ini mendukung hingga 1,25 Gbps throughput per terowongan VPN, tetapi tidak mendukung Equal Cost Multi Path (ECMP) untuk lalu lintas keluar dalam kasus beberapa terowongan VPN Terkelola AWS yang berakhir pada VGW yang sama. Sebaiknya jangan gunakan VPN Terkelola AWS sebagai cadangan koneksi Direct Connect kecuali jika Anda dapat menoleransi kecepatan kurang dari 1 Gbps selama failover.
Anda juga dapat menggunakan titik akhir VPC agar VPC terhubung secara privat ke layanan yang didukung AWS dan layanan titik akhir VPC yang didukung oleh AWS PrivateLink tanpa melewati internet publik. Titik akhir adalah perangkat virtual. Titik akhir dapat diskalakan secara horizontal, redundan, dan merupakan komponen VPC yang selalu tersedia. Titik akhir memungkinkan komunikasi antarinstans dalam layanan dan VPC tanpa memaksakan risiko ketersediaan atau batasan bandwidth pada lalu lintas jaringan.
**Antipola umum:**
+ Hanya memiliki satu penyedia konektivitas antara jaringan on-site dan AWS.
+ Menggunakan kemampuan konektivitas dari koneksi AWS Direct Connect, tetapi hanya memiliki satu koneksi.
+ Hanya memiliki satu jalur untuk konektivitas VPN.
**Manfaat menerapkan praktik terbaik ini:** Dengan mengimplementasikan konektivitas redundan antara lingkungan cloud dan lingkungan perusahaan atau on-premise, Anda dapat memastikan bahwa layanan dependen antara dua lingkungan tersebut dapat berkomunikasi dengan andal.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Pastikan bahwa Anda memiliki konektivitas yang tersedia antara AWS dan lingkungan on-premise. Gunakan beberapa koneksi AWS Direct Connect atau terowongan VPN antara jaringan privat yang di-deploy secara terpisah. Gunakan beberapa lokasi Direct Connect untuk ketersediaan tinggi. Ketika menggunakan beberapa Wilayah AWS, pastikan ada redundansi setidaknya di dalam dua di antaranya. Anda dapat mengevaluasi peralatan AWS Marketplace yang menghentikan VPN. Ketika menggunakan peralatan AWS Marketplace, lakukan deployment instans redundan untuk ketersediaan tinggi di Zona Ketersediaan yang berbeda.
+ Pastikan bahwa Anda memiliki koneksi redundan ke lingkungan on-premise. Anda mungkin memerlukan koneksi redundan ke beberapa Wilayah AWS untuk mencapai ketersediaan yang dibutuhkan.
+ [Rekomendasi Ketangguhan AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [Menggunakan Koneksi VPN Site-to-Site Redundan untuk Menyediakan Failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ Gunakan layanan operasi API untuk mengidentifikasi penggunaan yang tepat dari sirkuit Direct Connect.
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ Jika hanya ada satu koneksi Direct Connect atau Anda tidak memilikinya sama sekali, atur terowongan VPN redundan ke gateway privat virtual Anda.
+ [Apa itu VPN Site-to-Site AWS?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ Tangkap konektivitas saat ini (misalnya, gateway pribadi virtual, peralatan AWS Marketplace).
+ Gunakan layanan operasi API untuk memasukkan konfigurasi koneksi Direct Connect.
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ Gunakan layanan operasi API untuk mengumpulkan gateway privat virtual ketika tabel rute menggunakannya.
+ [DescribeVpnGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpnGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ Gunakan layanan operasi API untuk mengumpulkan aplikasi AWS Marketplace ketika tabel rute menggunakannya.
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu merencanakan jaringan Anda](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Rekomendasi Ketangguhan AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [AWS Marketplace untuk Infrastruktur Jaringan](https://aws.amazon.com/marketplace/b/2649366011)
+ [Laporan Resmi Opsi Konektivitas Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Konektivitas jaringan ketersediaan tinggi (HA) beberapa pusat data](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Menggunakan Koneksi VPN Site-to-Site Redundan untuk Menyediakan Failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ [Menggunakan Kit Alat Ketahanan Direct Connect untuk memulai](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [Titik Akhir VPC dan Layanan Titik Akhir VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [Apa Itu Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Apa Itu Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Apa itu VPN Site-to-Site AWS?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ [Bekerja dengan Gateway Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**Video terkait:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP03 Pastikan alokasi subnet IP menjelaskan ekspansi dan ketersediaan
Rentang alamat IP Amazon VPC harus cukup besar untuk mengakomodasi persyaratan beban kerja, termasuk pertimbangan ekspansi mendatang dan alokasi alamat IP ke subnet di seluruh Zona Ketersediaan. Ini mencakup penyeimbang beban, instans EC2, dan aplikasi berbasis kontainer.
Ketika Anda merencanakan topologi jaringan Anda, langkah pertama adalah menetapkan ruang alamat IP itu sendiri. Rentang alamat IP privat (mengikuti pedoman RFC 1918) harus dialokasikan untuk setiap VPC. Akomodasikan persyaratan berikut sebagai bagian dari proses ini:
+ Berikan ruang alamat IP untuk lebih dari satu VPC per Wilayah.
+ Di dalam VPC, berikan ruang untuk beberapa subnet yang meliputi beberapa Zona Ketersediaan.
+ Selalu biarkan ruang blok CIDR yang tidak digunakan di dalam VPC untuk ekspansi mendatang.
+ Pastikan ada ruang alamat IP untuk memenuhi kebutuhan armada sementara instans EC2 yang mungkin Anda gunakan, seperti Armada Spot untuk machine learning, klaster Amazon EMR, atau klaster Amazon Redshift.
+ Perhatikan, empat alamat IP pertama dan alamat IP terakhir di setiap blok CIDR subnet disimpan dan tidak tersedia untuk Anda gunakan.
+ Anda harus merencanakan untuk melakukan deploy blok CIDR VPC besar. Perhatikan, blok CIDR VPC awal yang dialokasikan ke VPC Anda tidak dapat diubah atau dihapus, tetapi Anda dapat menambahkan tambahan blok CIDR yang tidak tumpang tindih ke VPC. CIDR IPv4 subnet tidak dapat diubah, tetapi CIDR IPv6 dapat diubah. Ingat, deployment VPC yang sebesar mungkin (/16) menghasilkan lebih dari 65.000 alamat IP. Di ruang alamat IP 10.x.x.x saja, Anda dapat menyediakan 255 VPC seperti ini. Oleh karena itu, Anda harus cenderung terlalu besar daripada terlalu kecil untuk mempermudah pengelolaan VPC Anda.
**Antipola umum:**
+ Membuat VPC yang kecil.
+ Membuat subnet kecil lalu harus menambahkan subnet ke konfigurasi seiring pertumbuhan.
+ Salah memperkirakan jumlah alamat IP yang dapat digunakan penyeimbang beban elastis.
+ Melakukan deploy banyak penyeimbang beban lalu lintas tinggi ke subnet yang sama.
**Manfaat menerapkan praktik terbaik ini:** Ini memastikan bahwa Anda dapat mengakomodasi pertumbuhan beban kerja Anda dan terus memberikan ketersediaan saat Anda menaikkan skala.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Rencanakan jaringan Anda untuk mengakomodasi pertumbuhan, kepatuhan terhadap peraturan, dan integrasi dengan yang lain. Pertumbuhan dapat lebih besar dari yang diperkirakan, kepatuhan terhadap peraturan dapat berubah, dan koneksi jaringan privat atau akuisisi dapat sulit diimplementasikan tanpa perencanaan yang baik.
+ Pilih Wilayah dan Akun AWS yang relevan berdasarkan persyaratan layanan, latensi, peraturan, dan pemulihan bencana (DR) Anda.
+ Identifikasi kebutuhan Anda untuk deployment VPC regional.
+ Identifikasi ukuran VPC.
+ Tentukan apakah Anda akan melakukan deploy konektivitas multi-VPC.
+ [Apa Itu Gateway Transit?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Konektivitas Multi-VPC Satu Wilayah](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ Tentukan apakah Anda membutuhkan jaringan terpisah untuk persyaratan peraturan.
+ Buat VPC yang sebesar mungkin. Blok CIDR VPC awal yang dialokasikan ke VPC Anda tidak dapat diubah atau dihapus, tetapi Anda dapat menambahkan tambahan blok CIDR yang tidak tumpang tindih ke VPC. Tetapi, ini dapat memotong rentang alamat Anda.
+ Buat VPC yang sebesar mungkin. Blok CIDR VPC awal yang dialokasikan ke VPC Anda tidak dapat diubah atau dihapus, tetapi Anda dapat menambahkan tambahan blok CIDR yang tidak tumpang tindih ke VPC. Tetapi, ini dapat memotong rentang alamat Anda.
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu merencanakan jaringan Anda](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Marketplace untuk Infrastruktur Jaringan](https://aws.amazon.com/marketplace/b/2649366011)
+ [Laporan Resmi Opsi Konektivitas Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Konektivitas jaringan ketersediaan tinggi (HA) beberapa pusat data](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Konektivitas Multi-VPC Satu Wilayah](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ [Apa Itu Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
**Video terkait:**
+ [AWS re:Invent 2018: Desain VPC Tingkat Lanjut dan Kemampuan Baru untuk Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Arsitektur referensi Gateway Transit untuk berbagai VPC (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP04 Mengutamakan topologi hub-and-spoke daripada mesh many-to-many
Jika ada lebih dari dua ruang alamat jaringan (misalnya, jaringan VPC dan on-premise) yang terhubung melalui peering VPC, AWS Direct Connect, atau VPN, gunakan model hub-and-spoke, seperti yang disediakan oleh AWS Transit Gateway.
Jika hanya ada dua jaringan, Anda dapat langsung menghubungkannya satu sama lain, tetapi seiring dengan bertambahnya jaringan, kompleksitas koneksi mesh ini tidak dapat dipertahankan. AWS Transit Gateway menyediakan model hub-and-spoke yang mudah dipertahankan, yang memungkinkan perutean lalu lintas ke beberapa jaringan.
![\[Diagram menampilkan penggunaan tanpa AWS Transit Gateway\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/without-transit-gateway.png)
![\[Diagram menampilkan penggunaan dengan AWS Transit Gateway\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/with-transit-gateway.png)
**Antipola umum:**
+ Menggunakan peering VPC untuk menghubungkan lebih dari dua VPC.
+ Membuat beberapa sesi BGP untuk setiap VPC guna membuat konektivitas yang memperluas penyebaran Cloud Privat Virtual (VPC) ke beberapa Wilayah AWS.
**Manfaat menerapkan praktik terbaik ini:** Seiring bertambahnya jumlah jaringan, kompleksitas koneksi mesh ini tidak dapat dipertahankan. AWS Transit Gateway menyediakan model hub-and-spoke yang mudah dipertahankan, yang memungkinkan perutean lalu lintas ke beberapa jaringan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Mengutamakan topologi hub-and-spoke daripada mesh many-to-many. Jika ada lebih dari dua ruang alamat jaringan (jaringan VPC, on-premise) yang terhubung melalui peering VPC, AWS Direct Connect, atau VPN, gunakan model hub-and-spoke, seperti yang disediakan oleh AWS Transit Gateway.
+ Jika hanya dua jaringan, Anda dapat langsung menghubungkannya satu sama lain, tetapi seiring dengan bertambahnya jaringan, kompleksitas koneksi mesh ini tidak dapat dipertahankan. AWS Transit Gateway menyediakan model hub-and-spoke yang mudah dipertahankan, yang memungkinkan perutean lalu lintas ke beberapa jaringan.
+ [Apa Itu Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu merencanakan jaringan Anda](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Marketplace untuk Infrastruktur Jaringan](https://aws.amazon.com/marketplace/b/2649366011)
+ [Konektivitas jaringan ketersediaan tinggi (HA) beberapa pusat data](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Titik Akhir VPC dan Layanan Titik Akhir VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [Apa Itu Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Apa Itu Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
**Video terkait:**
+ [AWS re:Invent 2018: Desain VPC Tingkat Lanjut dan Kemampuan Baru untukAmazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: Arsitektur referensi AWS Transit Gateway untuk banyak VPC (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP05 Terapkan rentang alamat IP privat yang tidak tumpang tindih di semua ruang alamat privat tempat semuanya terhubung
Rentang alamat IP untuk setiap VPC Anda tidak boleh tumpang tindih ketika peering atau dihubungkan lewat VPN. Anda juga harus menghindari konflik alamat IP antara lingkungan on-premise dan VPC atau dengan penyedia cloud lain yang Anda gunakan. Selain itu, Anda harus memiliki cara untuk mengalokasikan rentang alamat IP privat ketika dibutuhkan.
Sistem manajemen alamat IP (IPAM) dapat membantu hal ini. Beberapa IPAM tersedia dari AWS Marketplace.
**Antipola umum:**
+ Menggunakan rentang IP yang sama di VPC Anda seperti yang Anda miliki on-premise atau di jaringan korporasi Anda.
+ Tidak melacak rentang IP VPC yang digunakan untuk deployment beban kerja Anda.
**Manfaat menerapkan praktik terbaik ini:** Perencanaan aktif jaringan Anda akan memastikan bahwa Anda tidak memiliki beberapa kejadian alamat IP yang sama di jaringan yang saling terhubung. Ini mencegah timbulnya masalah perutean di bagian beban kerja yang menggunakan aplikasi yang berbeda.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Pantau dan kelola penggunaan CIDR Anda. Evaluasi potensi penggunaan Anda di AWS, tambahkan rentang CIDR ke VPC yang ada, dan buat VPC untuk memungkinkan pertumbuhan yang direncanakan dalam penggunaan.
+ Catat konsumsi CIDR saat ini (misalnya, VPC, subnet)
+ Gunakan operasi API layanan untuk mengumpulkan konsumsi CIDR saat ini.
+ Catat penggunaan subnet Anda saat ini.
+ Gunakan operasi API layanan untuk mengumpulkan subnet per VPC di setiap Wilayah.
+ [DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ Catat penggunaan saat ini.
+ Tentukan apakah Anda telah membuat rentang IP yang tumpang tindih.
+ Hitung kapasitas cadangan.
+ Identifikasi rentang IP yang tumpang tindih. Anda dapat memigrasikan ke rentang alamat baru atau menggunakan peralatan Network and Port Translation (NAT) dari AWS Marketplace jika Anda harus menghubungkan rentang yang tumpang tindih.
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu merencanakan jaringan Anda](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Marketplace untuk Infrastruktur Jaringan](https://aws.amazon.com/marketplace/b/2649366011)
+ [Laporan Resmi Opsi Konektivitas Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Konektivitas jaringan ketersediaan tinggi (HA) beberapa pusat data](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Apa Itu Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Apa itu IPAM?](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html)
**Video terkait:**
+ [AWS re:Invent 2018: Desain VPC Tingkat Lanjut dan Kemampuan Baru untuk Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Arsitektur referensi Gateway Transit untuk berbagai VPC (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# Arsitektur beban kerja
**Topics**
+ [REL 3. Bagaimana cara mendesain arsitektur layanan beban kerja Anda?](rel-03.md)
+ [REL 4. Bagaimana cara mendesain interaksi di sistem terdistribusi untuk mencegah kegagalan?](rel-04.md)
+ [REL 5. Bagaimana cara mendesain interaksi di sistem terdistribusi untuk memitigasi atau bertahan dari kegagalan?](rel-05.md)
# REL 3. Bagaimana cara mendesain arsitektur layanan beban kerja Anda?
Bangun beban kerja yang andal dan dapat diskalakan dengan mudah menggunakan arsitektur berorientasi layanan (SOA) atau arsitektur layanan mikro. Arsitektur berorientasi layanan (SOA) adalah praktik untuk membuat komponen perangkat lunak dapat digunakan ulang lewat antarmuka layanan. Arsitektur layanan mikro melangkah lebih jauh untuk membuat komponen menjadi lebih kecil dan lebih sederhana.
**Topics**
+ [REL03-BP01 Memilih cara untuk menyegmentasi beban kerja](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Bangun layanan yang berfokus pada domain dan fungsionalitas bisnis khusus](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Memberikan kontrak layanan per API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Memilih cara untuk menyegmentasi beban kerja
Segmentasi beban kerja penting saat menentukan persyaratan ketahanan aplikasi Anda. Arsitektur monolitik harus dihindari jika memungkinkan. Sebagai gantinya, pertimbangkan dengan cermat komponen aplikasi mana yang dapat dipecah menjadi layanan mikro. Bergantung pada persyaratan aplikasi Anda, solusinya mungkin merupakan kombinasi arsitektur berorientasi layanan (SOA) dengan layanan mikro jika memungkinkan. Beban kerja yang mampu berada dalam kondisi stateless akan lebih mampu di-deploy sebagai layanan mikro.
**Hasil yang diinginkan:** Beban kerja harus dapat didukung, dapat diskalakan, dan di-coupling selonggar mungkin.
Saat membuat pilihan tentang cara menyegmentasikan beban kerja Anda, seimbangkan manfaat dengan kerumitannya. Hal yang tepat untuk produk baru yang mengejar jadwal peluncuran pertama akan berbeda dengan hal yang dibutuhkan oleh beban kerja yang dibangun untuk diskalakan dari awal. Saat memfaktor ulang monolit yang ada, Anda perlu mempertimbangkan seberapa baik aplikasi akan mendukung dekomposisi menuju kondisi stateless. Dengan memecah layanan menjadi bagian-bagian yang lebih kecil, tim kecil yang diberi tanggung jawab khusus akan dapat mengembangkan dan mengelolanya. Namun, layanan yang lebih kecil dapat menimbulkan kompleksitas yang mencakup kemungkinan peningkatan latensi, debugging yang lebih kompleks, dan peningkatan beban operasional.
**Antipola umum:**
+ Dalam [layanan mikro, *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) adalah situasi saat komponen atomik menjadi sangat saling bergantung sehingga kegagalan salah satu komponen akan menghasilkan kegagalan yang jauh lebih besar, sehingga komponen ini pun menjadi kaku dan rapuh seperti monolit.
**Manfaat menjalankan praktik ini:**
+ Segmen yang lebih spesifik akan menghasilkan ketangkasan, fleksibilitas organisasi, dan skalabilitas yang lebih besar.
+ Dampak gangguan layanan yang berkurang.
+ Komponen-komponen aplikasi mungkin memiliki persyaratan ketersediaan yang berbeda-beda, yang dapat didukung oleh segmentasi yang lebih atomik.
+ Tanggung jawab yang ditentukan khusus untuk tim yang mendukung beban kerja.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Pilih jenis arsitektur berdasarkan cara beban kerja disegmentasikan. Pilih arsitektur SOA atau layanan mikro (atau dalam beberapa kasus yang jarang terjadi, arsitektur monolitik). Bahkan jika Anda memilih untuk memulai arsitektur monolit, Anda harus memastikan bahwa arsitektur tersebut modular dan pada akhirnya dapat berkembang menjadi SOA atau layanan mikro seiring dengan skala produk Anda dengan adopsi pengguna. SOA dan layanan mikro masing-masing menawarkan segmentasi yang lebih kecil, yang lebih disarankan sebagai arsitektur modern yang dapat diskalakan dan andal, tetapi ada tarik ulur yang perlu dipertimbangkan, terutama saat melakukan deployment arsitektur layanan mikro.
Salah satu tarik ulur utama adalah Anda sekarang memiliki arsitektur komputasi terdistribusi yang dapat mempersulit dalam memenuhi persyaratan latensi pengguna dan ada kerumitan tambahan dalam proses debugging dan penelusuran interaksi pengguna. Anda dapat menggunakan AWS X-Ray untuk membantu Anda memecahkan masalah ini. Efek lain yang perlu dipertimbangkan adalah peningkatan kompleksitas operasional seiring Anda meningkatkan jumlah aplikasi yang Anda kelola, yang memerlukan deployment banyak komponen independen.
![\[Diagram yang menunjukkan perbandingan antara arsitektur monolitik, berorientasi layanan, dan layanan mikro\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/monolith-soa-microservices-comparison.png)
## Langkah implementasi
+ Tentukan arsitektur yang sesuai untuk memfaktor ulang atau membangun aplikasi Anda. SOA dan layanan mikro masing-masing menawarkan segmentasi yang lebih kecil, serta diutamakan sebagai arsitektur modern yang dapat diskalakan dan diandalkan. SOA dapat menjadi kompensasi yang baik untuk mencapai segmentasi yang lebih kecil sembari menghindari beberapa kompleksitas dari layanan mikro. Untuk detail selengkapnya, lihat [Tarik Ulur Layanan Mikro](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Jika dapat diterima beban kerja dan didukung organisasi, Anda harus menggunakan arsitektur layanan mikro untuk mencapai ketangkasan dan keandalan terbaik. Untuk detail selengkapnya, lihat [Menerapkan Layanan Mikro di AWS.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Pertimbangkan untuk mengikuti karakteristik pohon [*Strangler Fig* , yaitu pola](https://martinfowler.com/bliki/StranglerFigApplication.html) untuk memfaktor ulang monolit menjadi komponen yang lebih kecil. Hal ini memerlukan penggantian komponen aplikasi tertentu secara bertahap dengan aplikasi dan layanan baru. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) bertindak sebagai titik awal untuk pemfaktoran ulang secara bertahap. Untuk detail selengkapnya, lihat [Memigrasikan beban kerja lama di on-premise dengan lancar menggunakan pola strangler](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ Implementasi layanan mikro mungkin memerlukan mekanisme penemuan layanan untuk memungkinkan layanan terdistribusi ini berkomunikasi satu sama lain. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) dapat digunakan dengan arsitektur berorientasi layanan untuk menyediakan penemuan dan akses layanan yang andal. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) juga dapat digunakan untuk penemuan layanan berbasis DNS yang dinamis.
+ Jika Anda bermigrasi dari monolit ke SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) dapat membantu menjembatani kesenjangan sebagai bus layanan saat mendesain ulang aplikasi lama di cloud.
+ Untuk monolit yang ada dengan satu basis data bersama, pilih cara mengatur ulang data menjadi segmen yang lebih kecil. Segmentasi ini dapat didasarkan pada unit bisnis, pola akses, atau struktur data. Pada titik ini dalam proses pemfaktoran ulang, Anda harus memilih untuk melanjutkan dengan jenis basis data relasional atau nonrelasional (NoSQL). Untuk detail selengkapnya, lihat [Dari SQL ke NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Tingkat upaya untuk rencana implementasi:** Tinggi
## Sumber daya
**Praktik terbaik terkait:**
+ [REL03-BP02 Bangun layanan yang berfokus pada domain dan fungsionalitas bisnis khusus](rel_service_architecture_business_domains.md)
**Dokumen terkait:**
+ [Amazon API Gateway: Mengonfigurasi API REST Menggunakan OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Apa itu Arsitektur Berorientasi Layanan?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Konteks Terikat (pola sentral di Desain yang Didorong Domain)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Mengimplementasikan Layanan Mikro di AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompensasi Layanan Mikro](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Layanan mikro - definisi istilah arsitektur baru ini](https://www.martinfowler.com/articles/microservices.html)
+ [Layanan mikro di AWS](https://aws.amazon.com/microservices/)
+ [Apa itu AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Contoh terkait:**
+ [Lokakarya Modernisasi Aplikasi Iteratif](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Video terkait:**
+ [Memberikan Keunggulan dengan Layanan Mikro di AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Bangun layanan yang berfokus pada domain dan fungsionalitas bisnis khusus
Arsitektur berorientasi layanan (SOA) menetapkan layanan dengan fungsi yang digambarkan dengan baik berdasarkan kebutuhan bisnis. Layanan mikro menggunakan model domain dan konteks yang dibatasi untuk menarik batas-batas layanan di sepanjang batas konteks bisnis. Berfokus pada domain dan fungsionalitas bisnis dapat membantu tim untuk menentukan persyaratan keandalan sendiri untuk layanan mereka. Konteks yang dibatasi mengisolasi dan memisahkan logika bisnis, sehingga memungkinkan tim memiliki penalaran yang lebih baik tentang bagaimana menangani kegagalan.
**Hasil yang diinginkan:** Rekayasawan dan pemangku kepentingan bisnis bersama-sama menetapkan konteks yang dibatasi dan menggunakannya untuk merancang sistem sebagai layanan yang memenuhi fungsi bisnis tertentu. Tim-tim ini menggunakan praktik yang telah lazim seperti event storming untuk menentukan persyaratan. Aplikasi baru dirancang sebagai batas layanan yang ditetapkan dengan baik dan penggabungan longgar. Monolit yang ada diurai menjadi [konteks-konteks yang dibatasi](https://martinfowler.com/bliki/BoundedContext.html) dan desain sistem beralih ke arsitektur SOA atau layanan mikro. Ketika monolit difaktorkan ulang, pendekatan lazim seperti konteks gelembung dan pola penguraian monolit diterapkan.
Layanan berorientasi domain dijalankan sebagai satu atau beberapa proses yang statusnya tidak sama. Layanan-layanan tersebut secara independen merespons fluktuasi permintaan dan menangani skenario kesalahan dengan berpatokan pada persyaratan khusus domain.
**Antipola umum:**
+ Tim dibentuk berdasarkan domain-domain teknis tertentu seperti UI dan UX, perangkat lunak perantara (middleware), atau basis data, bukan berdasarkan domain bisnis tertentu.
+ Aplikasi melibatkan tanggung jawab domain. Layanan yang mencakup konteks yang dibatasi bisa lebih sulit untuk dipelihara, memerlukan upaya pengujian yang lebih besar, dan memerlukan banyak tim domain untuk berpartisipasi dalam pembaruan perangkat lunak.
+ Dependensi domain, seperti pustaka entitas domain, dibagikan di seluruh layanan sehingga perubahan untuk satu domain layanan memerlukan perubahan pada domain layanan lainnya
+ Kontrak layanan dan logika bisnis tidak mengekspresikan entitas dalam bahasa domain yang umum dan konsisten, sehingga menghasilkan lapisan terjemahan yang merumitkan sistem dan meningkatkan upaya debugging.
**Manfaat menjalankan praktik terbaik ini:** Aplikasi dirancang sebagai layanan independen yang dibatasi oleh domain bisnis dan menggunakan bahasa bisnis umum. Layanan dapat diuji dan dapat di-deploy secara independen. Layanan memenuhi persyaratan ketahanan khusus domain untuk domain yang diterapkan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Keputusan berbasis domain (DDD) adalah pendekatan dasar perancangan dan pembangunan perangkat lunak berdasarkan domain bisnis. Bekerja dengan kerangka kerja yang ada memudahkan pembuatan layanan yang berfokus pada domain bisnis. Saat bekerja dengan aplikasi monolitik yang ada, Anda dapat memanfaatkan pola penguraian yang menyediakan teknik-teknik yang sudah lazim untuk memodernisasi aplikasi menjadi layanan.
![\[Diagram alur yang menggambarkan pendekatan keputusan berbasis domain.\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/domain-driven-decision.png)
## Langkah implementasi
+ Tim dapat menyelenggarakan lokakarya [event storming](https://serverlessland.com/event-driven-architecture/visuals/event-storming) untuk mengidentifikasi peristiwa, perintah, agregat, dan domain secara cepat dalam format catatan tempel ringan.
+ Setelah entitas dan fungsi domain dibentuk dalam konteks domain, Anda dapat membagi domain Anda ke dalam layanan-layanan menggunakan [konteks yang dibatasi](https://martinfowler.com/bliki/BoundedContext.html), dengan mengelompokkan entitas dengan fitur dan atribut yang serupa. Dengan model yang dibagi ke dalam konteks, muncul templat untuk membatasi layanan mikro.
+ Misalnya, entitas situs web Amazon.com dapat meliputi paket, pengantaran, jadwal, harga, diskon, dan mata uang.
+ Paket, pengantaran, dan jadwal dikelompokkan ke dalam konteks pengiriman, sedangkan harga, diskon, dan mata uang dikelompokkan ke dalam konteks harga.
+ [Mengurai monolit menjadi layanan mikro](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) menjelaskan pola-pola untuk pemfaktoran ulang layanan mikro. Menggunakan pola-pola penguraian berdasarkan kemampuan bisnis, subdomain, atau transaksi selaras dengan pendekatan berbasis domain.
+ Teknik-teknik taktis seperti [konteks gelembung](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) memungkinkan Anda memasukkan DDD di dalam aplikasi yang ada atau aplikasi warisan tanpa penulisan ulang di awal dan komitmen penuh terhadap DDD. Dalam pendekatan konteks gelembung, konteks terbatas yang kecil dibuat menggunakan pemetaan layanan dan koordinasi, atau [lapisan antikorupsi](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context), yang melindungi model domain yang baru ditentukan dari pengaruh eksternal.
Setelah tim melakukan analisis domain dan menentukan entitas serta kontrak layanan, mereka dapat memanfaatkan layanan AWS untuk menerapkan desain berbasis domain mereka sebagai layanan berbasis cloud.
+ Mulai pengembangan Anda dengan menentukan pengujian yang menggunakan aturan bisnis domain Anda. Pengembangan berbasis pengujian (TDD) dan pengembangan berbasis perilaku (BDD) membantu tim menjaga layanan tetap fokus pada pemecahan masalah bisnis.
+ Pilih [layanan AWS](https://aws.amazon.com/microservices/) yang paling memenuhi persyaratan domain bisnis dan [arsitektur layanan mikro Anda](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html):
+ [AWS Nirserver](https://aws.amazon.com/serverless/) memungkinkan tim Anda untuk fokus pada logika domain tertentu, bukan pada pengelolaan server dan infrastruktur.
+ [Kontainer di AWS](https://aws.amazon.com/containers/) menyederhanakan pengelolaan infrastruktur Anda, sehingga Anda dapat fokus pada persyaratan domain Anda.
+ [Basis data yang dirancang khusus](https://aws.amazon.com/products/databases/) membantu Anda mencocokkan persyaratan domain Anda dengan jenis basis data yang paling sesuai.
+ [Membangun arsitektur heksagonal di AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) menguraikan kerangka kerja untuk membangun logika bisnis menjadi layanan yang bekerja mundur dari domain bisnis untuk memenuhi persyaratan fungsional dan kemudian melampirkan adaptor integrasi. Pola-pola yang memisahkan detail antarmuka dari logika bisnis dengan layanan AWS membantu tim untuk berfokus pada fungsionalitas domain dan meningkatkan kualitas perangkat lunak.
## Sumber daya
**Praktik terbaik terkait:**
+ [REL03-BP01 Memilih cara untuk menyegmentasi beban kerja](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP03 Memberikan kontrak layanan per API](rel_service_architecture_api_contracts.md)
**Dokumen terkait:**
+ [Layanan Mikro AWS](https://aws.amazon.com/microservices/)
+ [Mengimplementasikan Layanan Mikro di AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Cara memecah Monolit menjadi Layanan-Layanan Mikro](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Mulai Menggunakan DDD di Tengah-Tengah Sistem Warisan](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [ Desain Berbasis Domain: Mengatasi Kompleksitas di Dalam Inti Perangkat Lunak ](https://www.amazon.com/gp/product/0321125215)
+ [ Membangun arsitektur heksagonal di AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [ Mengurai monolit menjadi layanan mikro ](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)
+ [ Event Storming ](https://serverlessland.com/event-driven-architecture/visuals/event-storming)
+ [ Pesan Antara Konteks-Konteks yang Dibatasi ](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [ Layanan mikro ](https://www.martinfowler.com/articles/microservices.html)
+ [ Pengembangan berbasis pengujian ](https://en.wikipedia.org/wiki/Test-driven_development)
+ [ Pengembangan berbasis perilaku ](https://en.wikipedia.org/wiki/Behavior-driven_development)
**Contoh terkait:**
+ [ Lokakarya Cloud-Native Korporat ](https://catalog.us-east-1.prod.workshops.aws/workshops/0466c70e-4216-4352-98d9-5a8af59c86b2/en-US)
+ [ Merancang Layanan Mikro Cloud-Native di AWS (dari DDD/EventStormingWorkshop) ](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)
**Alat terkait:**
+ [ Basis Data AWS Cloud](https://aws.amazon.com/products/databases/)
+ [ Nirserver di AWS](https://aws.amazon.com/serverless/)
+ [ Kontainer di AWS](https://aws.amazon.com/containers/)
# REL03-BP03 Memberikan kontrak layanan per API
Kontrak layanan adalah perjanjian terdokumentasi antara produsen dan konsumen API yang ditetapkan dalam definisi API yang dapat dibaca mesin. Strategi versioning kontrak memungkinkan konsumen untuk terus menggunakan API yang ada dan memigrasikan aplikasi mereka ke API yang lebih baru ketika mereka siap. Deployment produsen dapat terjadi kapan saja, selama kontrak dipatuhi. Tim layanan dapat menggunakan tumpukan teknologi pilihan mereka untuk memenuhi kontrak API.
**Hasil yang diinginkan:**
**Antipola umum:** Aplikasi yang dibangun dengan arsitektur berorientasi layanan atau layanan mikro dapat beroperasi secara independen sementara tetap memiliki dependensi runtime yang terintegrasi. Perubahan yang di-deploy ke konsumen atau produsen API tidak mengganggu stabilitas sistem secara keseluruhan ketika kedua belah pihak mematuhi kontrak API yang sama. Komponen yang berkomunikasi melalui API layanan dapat melakukan rilis fungsional independen, peningkatan ke dependensi runtime, atau melakukan failover ke situs pemulihan bencana (DR) dengan sedikit atau tanpa dampak terhadap satu sama lain. Selain itu, layanan diskret dapat menyesuaikan skala secara independen dengan menyerap permintaan sumber daya tanpa mengharuskan layanan lain untuk menyesuaikan skala secara serempak.
+ Membuat API layanan tanpa skema strongly-typed. Hal ini menghasilkan API yang tidak dapat digunakan untuk menghasilkan pengikatan dan muatan API yang tidak dapat divalidasi secara terprogram.
+ Tidak mengadopsi strategi versioning, yang memaksa konsumen API untuk memperbarui dan melepaskan atau gagal saat kontrak layanan berkembang.
+ Pesan kesalahan yang membocorkan detail implementasi layanan yang mendasari, bukan menggambarkan kegagalan integrasi dalam bahasa dan konteks domain.
+ Tidak menggunakan kontrak API untuk mengembangkan kasus pengujian dan implementasi API simulasi untuk memungkinkan pengujian komponen layanan secara independen.
**Manfaat menjalankan praktik terbaik ini:** Sistem terdistribusi yang terdiri dari komponen-komponen yang berkomunikasi melalui kontrak layanan API dapat meningkatkan keandalan. Developer dapat mengidentifikasi potensi masalah di awal proses pengembangan dengan pemeriksaan tipe selama kompilasi untuk memverifikasi bahwa bidang-bidang yang diperlukan ada dan permintaan serta respons mematuhi kontrak API. Kontrak API menyediakan antarmuka dokumentasi mandiri yang jelas untuk API dan menyediakan interoperabilitas yang lebih baik antara sistem dan bahasa pemrograman yang berbeda.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Setelah mengidentifikasi domain bisnis dan menentukan segmentasi beban kerja, Anda dapat mengembangkan API layanan. Pertama-tama, tentukan kontrak layanan yang dapat dibaca mesin untuk API, lalu implementasikan strategi versioning API. Setelah siap mengintegrasikan layanan melalui protokol umum seperti REST, GraphQL, atau peristiwa asinkron, Anda dapat memasukkan layanan AWS ke dalam arsitektur Anda untuk mengintegrasikan komponen Anda dengan kontrak API strongly-typed.
**Layanan AWS untuk kontrak API layanan**
Sertakan layanan AWS seperti [Amazon API Gateway](https://aws.amazon.com/api-gateway/), [AWS AppSync](https://aws.amazon.com/appsync/), dan [Amazon EventBridge](https://aws.amazon.com/eventbridge/) ke dalam arsitektur Anda untuk menggunakan kontrak layanan API dalam aplikasi Anda. Amazon API Gateway membantu Anda terintegrasi dengan layanan AWS native langsung serta layanan web lainnya. API Gateway mendukung [spesifikasi dan versioning OpenAPI.](https://github.com/OAI/OpenAPI-Specification) AWS AppSync adalah titik akhir [GraphQL](https://graphql.org/) terkelola yang Anda konfigurasikan dengan menetapkan skema GraphQL untuk menetapkan antarmuka layanan untuk kueri, mutasi, dan langganan. Amazon EventBridge menggunakan skema peristiwa untuk menetapkan peristiwa dan menghasilkan kode binding untuk peristiwa Anda.
## Langkah implementasi
+ Pertama-tama, tetapkan kontrak untuk API Anda. Kontrak akan mengekspresikan kemampuan suatu API serta menetapkan objek dan bidang data strongly-typed untuk input dan output API.
+ Saat mengonfigurasi API di API Gateway, Anda dapat mengimpor dan mengekspor OpenAPI Specification untuk titik akhir Anda.
+ [Mengimpor definisi OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) menyederhanakan pembuatan API Anda dan dapat diintegrasikan dengan infrastruktur AWS sebagai alat kode seperti [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/) dan [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/).
+ [Mengekspor definisi API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) menyederhanakan integrasi dengan alat pengujian API dan menyediakan spesifikasi integrasi untuk konsumen layanan.
+ Anda dapat menetapkan dan mengelola API GraphQL dengan AWS AppSync dengan cara [menetapkan file skema GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) untuk menghasilkan antarmuka kontrak Anda dan menyederhanakan interaksi dengan model REST kompleks, beberapa tabel basis data, atau layanan warisan.
+ [Proyek AWS Amplify](https://aws.amazon.com/amplify/) yang terintegrasi dengan AWS AppSync menghasilkan file kueri JavaScript strongly-typed untuk digunakan dalam aplikasi Anda serta pustaka klien GraphQL AWS AppSync untuk tabel [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) .
+ Saat Anda menggunakan peristiwa layanan dari Amazon EventBridge, peristiwa mematuhi skema yang sudah ada di dalam registri skema atau yang Anda definisikan dengan OpenAPI Spec. Dengan skema yang didefinisikan dalam registri, Anda juga dapat menghasilkan binding klien dari kontrak skema untuk mengintegrasikan kode Anda dengan peristiwa.
+ Memperluas atau melakukan versioning API Anda. Memperluas API adalah opsi yang lebih sederhana saat menambahkan bidang yang dapat dikonfigurasi dengan bidang opsional atau nilai default untuk bidang wajib.
+ Kontrak berbasis JSON untuk protokol seperti REST dan GraphQL bisa ideal untuk perluasan kontrak.
+ Kontrak berbasis XML untuk protokol seperti SOAP harus diuji dengan konsumen layanan untuk menentukan kelayakan perluasan kontrak.
+ Saat melakukan versioning API, pertimbangkan implementasi versioning proksi yang menggunakan facade untuk mendukung versi sehingga logika dapat dipertahankan dalam satu basis kode.
+ Dengan API Gateway Anda dapat menggunakan [pemetaan permintaan dan respons](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) untuk menyederhanakan penyerapan perubahan kontrak dengan membuat facade untuk memberikan nilai default untuk bidang baru atau untuk membuang bidang yang dihapus dari permintaan atau respons. Dengan pendekatan ini, layanan yang mendasari dapat mempertahankan basis kode tunggal.
## Sumber daya
**Praktik terbaik terkait:**
+ [REL03-BP01 Memilih cara untuk menyegmentasi beban kerja](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Bangun layanan yang berfokus pada domain dan fungsionalitas bisnis khusus](rel_service_architecture_business_domains.md)
+ [REL04-BP02 Mengimplementasikan dependensi yang digabungkan secara longgar](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP03 Mengontrol dan membatasi panggilan percobaan ulang](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP05 Mengatur batas waktu klien](rel_mitigate_interaction_failure_client_timeouts.md)
**Dokumen terkait:**
+ [ Apa itu API (Antarmuka Pemrograman Aplikasi)? ](https://aws.amazon.com/what-is/api/)
+ [ Mengimplementasikan Layanan Mikro di AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Kompensasi Layanan Mikro ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [ Layanan mikro - definisi istilah arsitektur baru ini ](https://www.martinfowler.com/articles/microservices.html)
+ [ Layanan mikro di AWS](https://aws.amazon.com/microservices/)
+ [ Bekerja dengan ekstensi API Gateway ke OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [ OpenAPI-Specification ](https://github.com/OAI/OpenAPI-Specification)
+ [ GraphQL: Skema dan Jenis ](https:/graphql.org/learn/schema)
+ [ Binding kode Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)
**Contoh terkait:**
+ [ Amazon API Gateway: Mengonfigurasi API REST Menggunakan OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [ Aplikasi CRUD Amazon API Gateway ke Amazon DynamoDB menggunakan OpenAPI ](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [ Pola integrasi aplikasi modern di era nirserver: Integrasi Layanan API Gateway ](https://catalog.us-east-1.prod.workshops.aws/workshops/be7e1ee7-b91f-493d-93b0-8f7c5b002479/en-US/labs/asynchronous-request-response-poll/api-gateway-service-integration)
+ [ Mengimplementasikan versioning API Gateway berbasis header dengan Amazon CloudFront ](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync: Membangun aplikasi klien ](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)
**Video terkait:**
+ [ Menggunakan OpenAPI di AWS SAM untuk mengelola API Gateway ](https://www.youtube.com/watch?v=fet3bh0QA80)
**Alat terkait:**
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
# REL 4. Bagaimana cara mendesain interaksi di sistem terdistribusi untuk mencegah kegagalan?
Sistem terdistribusi mengandalkan jaringan komunikasi untuk membuat interkoneksi komponen, seperti server atau layanan. Beban kerja Anda harus beroperasi secara andal terlepas latensi atau hilangnya data di jaringan-jaringan ini. Komponen dari sistem terdistribusi harus beroperasi dengan cara yang tidak secara negatif memengaruhi beban kerja atau komponen-komponen lain. Berbagai praktik terbaik ini mencegah kegagalan dan meningkatkan waktu rata-rata antara kegagalan (MTBF).
**Topics**
+ [REL04-BP01 Mengidentifikasi jenis sistem terdistribusi yang diperlukan](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Mengimplementasikan dependensi yang digabungkan secara longgar](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Melakukan tugas konstan](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Menjadikan semua respons idempoten](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Mengidentifikasi jenis sistem terdistribusi yang diperlukan
Sistem terdistribusi hard real-time memerlukan respons yang diberikan secara sinkron dan cepat, sedangkan sistem soft real-time memiliki jendela waktu yang lebih fleksibel untuk respons, dalam hitungan menit atau lebih. Sistem offline menangani respons melalui batch atau pemrosesan asinkron. Sistem terdistribusi hard real-time memiliki persyaratan keandalan yang paling ketat.
Tantangan yang paling sulit [dengan sistem terdistribusi](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) adalah sistem terdistribusi hard real-time, yang dikenal juga sebagai layanan permintaan/balasan. Hal yang membuatnya sulit adalah permintaan yang masuk tidak dapat diprediksikan dan respons yang diberikan harus cepat (misalnya, pelanggan menunggu respons dengan aktif). Contohnya mencakup server web front-end, urutan pipeline, transaksi kartu kredit, setiap API AWS, dan telefoni.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Identifikasikan jenis sistem terdistribusi yang diperlukan. Tantangan dengan sistem terdistribusi meliputi latensi, penskalaan, pemahaman atas API jaringan, mengonversi dan membatalkan konversi data, serta kompleksitas algoritme seperti Paxos. Ketika sistem tumbuh lebih besar dan lebih terdistribusi, apa yang tadinya merupakan kasus edge teoretis berubah menjadi kejadian biasa.
+ [Amazon Builders' Library: Tantangan dengan sistem terdistribusi](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ Sistem terdistribusi hard real-time memerlukan respons yang diberikan secara sinkron dan cepat.
+ Sistem soft real-time memiliki jendela waktu yang lebih fleksibel untuk respons, dalam hitungan menit atau lebih.
+ Sistem offline menangani respons melalui batch atau pemrosesan asinkron.
+ Sistem terdistribusi hard real-time memiliki persyaratan keandalan yang paling ketat.
## Sumber daya
**Dokumen terkait:**
+ [Amazon EC2: Memastikan Idempotensi](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: Tantangan dengan sistem terdistribusi](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: Keandalan, kerja konstan, dan pilihan yang tepat](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Apa Itu Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Apa Itu Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Video terkait:**
+ [AWS New York Summit 2019: Pengantar Arsitektur Berbasis Peristiwa dan Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: Cara Mengontrol Sistem, ARC337 Besar dan Kecil (mencakup penggabungan longgar, kerja konstan, stabilitas statis)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Beralih ke arsitektur berbasis peristiwa (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP02 Mengimplementasikan dependensi yang digabungkan secara longgar
Dependensi seperti sistem pengantrean, sistem streaming, alur kerja, dan penyeimbang beban digabungkan secara longgar. Penggabungan longgar membantu memisahkan perilaku suatu komponen dari komponen lainnya yang bergantung pada komponen tersebut, sehingga meningkatkan ketahanan dan ketangkasan.
Dalam sistem penggabungan erat, perubahan pada satu komponen dapat menyebabkan perubahan pada komponen lain yang bergantung padanya, yang mengakibatkan penurunan performa di semua komponen. Penggabungan longgar menghilangkan dependensi ini sehingga komponen-komponen yang bergantung hanya perlu mengetahui antarmuka versi terbaru dan yang dipublikasikan. Implementasi penggabungan longgar antar dependensi memisahkan kegagalan pada salah satu dependensi agar tidak memengaruhi dependensi lain.
Penggabungan longgar memungkinkan Anda untuk mengubah kode atau menambahkan fitur ke sebuah komponen sambil meminimalkan risiko pada komponen lain yang bergantung pada komponen tersebut. Hal ini juga memungkinkan ketahanan granular pada tingkat komponen sehingga Anda dapat menskalakan ke luar atau bahkan mengubah implementasi yang mendasari dependensi.
Agar makin meningkatkan ketahanan melalui penggabungan longgar, jadikan interaksi komponen asinkron apabila memungkinkan. Model ini cocok untuk interaksi apa pun yang tidak memerlukan respons cepat dan ketika terdaftarnya suatu permintaan cukup perlu diketahui. Ini melibatkan satu komponen yang menghasilkan peristiwa dan komponen lain yang menggunakannya. Kedua komponen tersebut tidak terintegrasi melalui interaksi titik ke titik langsung, tetapi biasanya melalui lapisan penyimpanan tahan lama perantara, seperti antrean Amazon SQS atau platform data streaming seperti Amazon Kinesis, atau AWS Step Functions.
![\[Diagram showing dependencies such as queuing systems and load balancers are loosely coupled\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/loosely-coupled-dependencies.png)
Antrean Amazon SQS dan Penyeimbang Beban Elastis hanyalah dua cara untuk menambahkan lapisan perantara untuk penggabungan longgar. Arsitektur yang didorong peristiwa juga dapat dibangun di AWS Cloud menggunakan Amazon EventBridge, yang dapat mengabstraksi klien (penghasil peristiwa) dari layanan yang mereka andalkan (pemakai peristiwa). Amazon Simple Notification Service (Amazon SNS) adalah solusi efektif ketika Anda memerlukan olah pesan dari banyak ke banyak dengan throughput tinggi dan berbasis push. Menggunakan topik Amazon SNS, sistem penerbit Anda dapat menyebarkan pesan ke titik akhir pelanggan dalam jumlah besar untuk pemrosesan paralel.
Meskipun antrean menawarkan sejumlah manfaat, di sebagian besar sistem waktu nyata yang keras, permintaan yang lebih lama dari waktu ambang batas (sering kali dalam hitungan detik) harus dianggap basi (klien telah menyerah dan sudah tidak menunggu respons), dan tidak diproses. Dengan begitu, permintaan yang lebih baru (dan kemungkinan masih valid) dapat diproses sebagai gantinya.
**Hasil yang diinginkan:** Menerapkan dependensi penggabungan longgar memungkinkan Anda untuk meminimalkan area kegagalan ke tingkat komponen, yang membantu mendiagnosis dan menyelesaikan masalah. Cara ini juga dapat menyederhanakan siklus pengembangan, sehingga memungkinkan tim untuk menerapkan perubahan pada tingkat modular tanpa memengaruhi performa komponen lain yang bergantung padanya. Pendekatan ini memberikan kemampuan untuk menskalakan ke luar pada tingkat komponen berdasarkan kebutuhan sumber daya, serta pemanfaatan komponen yang berkontribusi terhadap efektivitas biaya.
**Antipola umum:**
+ Melakukan deployment beban kerja monolitik.
+ Memanggil API antar tingkatan beban kerja secara langsung tanpa kemampuan failover atau pemrosesan permintaan secara asinkron.
+ Penggabungan erat menggunakan data bersama. Sistem yang digabungkan secara longgar sebaiknya tidak berbagi data melalui basis data bersama atau bentuk penyimpanan data yang digabungkan secara erat, yang dapat menimbulkan kembali penggabungan erat dan menghambat skalabilitas.
+ Mengabaikan tekanan balik. Beban kerja Anda harus memiliki kemampuan untuk memperlambat atau menghentikan data yang masuk ketika komponen tidak dapat memprosesnya pada kecepatan yang sama.
**Manfaat menetapkan praktik terbaik ini:** Penggabungan longgar membantu mengisolasi perilaku komponen dari komponen lain yang bergantung padanya, sehingga meningkatkan ketahanan dan ketangkasan. Kegagalan di salah satu komponen dipisahkan dari komponen lain.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Implementasikan dependensi yang digabungkan secara longgar. Ada berbagai solusi yang memungkinkan Anda membangun aplikasi yang digabungkan secara longgar. Ini meliputi, beberapa di antaranya, layanan untuk mengimplementasikan antrean yang dikelola sepenuhnya, alur kerja otomatis, reaksi terhadap peristiwa, dan API yang dapat membantu mengisolasi perilaku komponen dari komponen lain, dan dengan demikian meningkatkan ketahanan dan ketangkasan.
+ **Membangun arsitektur yang didorong peristiwa:** [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) membantu Anda membangun arsitektur berbasis peristiwa yang digabungkan secara longgar dan terdistribusi.
+ **Menerapkan antrean dalam sistem terdistribusi:** Anda dapat menggunakan [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) untuk mengintegrasikan dan memisahkan sistem terdistribusi.
+ **Kontainerisasi komponen sebagai layanan mikro:** [Layanan mikro](https://aws.amazon.com/microservices/) memungkinkan tim untuk membangun aplikasi yang terdiri dari komponen independen kecil yang berkomunikasi melalui API yang ditentukan dengan jelas. [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html), dan [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) dapat membantu Anda memulai lebih cepat dengan kontainer.
+ **Kelola alur kerja dengan Step Functions:** [ Step Functions](https://aws.amazon.com/step-functions/getting-started/) membantu Anda mengoordinasikan beberapa layanan AWS menjadi alur kerja yang fleksibel.
+ **Manfaatkan arsitektur olah pesan publikasi-berlangganan (pub/sub):** [Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) menyediakan pengiriman pesan dari penerbit ke pelanggan (juga dikenal sebagai produsen dan konsumen).
### Langkah implementasi
+ Komponen dalam arsitektur yang didorong peristiwa dimulai oleh peristiwa. Peristiwa adalah tindakan yang terjadi dalam sistem, seperti pengguna menambahkan item ke keranjang. Ketika suatu tindakan berhasil, sebuah peristiwa dihasilkan, yang menggerakkan komponen berikutnya dari sistem.
+ [ Building Event-driven Applications with Amazon EventBridge ](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
+ [AWS re:Invent 2022 - Designing Event-Driven Integrations using Amazon EventBridge ](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ Sistem olah pesan terdistribusi memiliki tiga bagian utama yang perlu diimplementasikan untuk arsitektur berbasis antrean. Bagian-bagian tersebut meliputi komponen sistem terdistribusi, antrean yang digunakan untuk pemisahan (didistribusikan di server Amazon SQS), dan pesan dalam antrean. Sistem tipikal memiliki produsen yang memulai pesan ke dalam antrean, dan konsumen yang menerima pesan dari antrean tersebut. Antrean menyimpan pesan di beberapa server Amazon SQS untuk redundansi.
+ [ Basic Amazon SQS architecture ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [ Send Messages Between Distributed Applications with Amazon Simple Queue Service ](https://aws.amazon.com/getting-started/hands-on/send-messages-distributed-applications/)
+ Layanan mikro, jika dimanfaatkan dengan baik, akan meningkatkan pemeliharaan dan mendongkrak skalabilitas, karena komponen yang digabungkan secara longgar dikelola oleh tim independen. Hal ini juga memungkinkan isolasi perilaku ke satu komponen jika terjadi perubahan.
+ [ Mengimplementasikan Layanan Mikro di AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Let's Architect\$1 Architecting microservices with containers ](https://aws.amazon.com/blogs/architecture/lets-architect-architecting-microservices-with-containers/)
+ Dengan AWS Step Functions Anda dapat membangun aplikasi terdistribusi, mengotomatiskan proses, mengorkestrasi layanan mikro, serta berbagai hal lainnya. Orkestrasi beberapa komponen ke dalam alur kerja otomatis memungkinkan Anda untuk memisahkan dependensi dalam aplikasi Anda.
+ [ Create a Serverless Workflow with AWS Step Functions and AWS Lambda](https://aws.amazon.com/tutorials/create-a-serverless-workflow-step-functions-lambda/)
+ [ Mulai menggunakan AWS Step Functions](https://aws.amazon.com/step-functions/getting-started/)
## Sumber daya
**Dokumen terkait:**
+ [Amazon EC2: Ensuring Idempotency](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: Tantangan dengan sistem terdistribusi](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: Keandalan, tugas konstan, dan pilihan yang tepat](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Apa Itu Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Apa Itu Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ [ Break up with your monolith ](https://pages.awscloud.com/break-up-your-monolith.html)
+ [ Orchestrate Queue-based Microservices with AWS Step Functions and Amazon SQS ](https://aws.amazon.com/tutorials/orchestrate-microservices-with-message-queues-on-step-functions/)
+ [ Basic Amazon SQS architecture ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [ Queue-Based Architecture ](https://docs.aws.amazon.com/wellarchitected/latest/high-performance-computing-lens/queue-based-architecture.html)
**Video terkait:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes loose coupling, constant work, static stability)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda ](https://www.youtube.com/watch?v=2rikdPIFc_Q)
+ [AWS re:Invent 2022 - Designing event-driven integrations using Amazon EventBridge ](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ [AWS re:Invent 2017: Elastic Load Balancing Deep Dive and Best Practices ](https://www.youtube.com/watch?v=9TwkMMogojY)
# REL04-BP03 Melakukan tugas konstan
Sistem dapat gagal mengalami kegagalan saat ada perubahan besar dan cepat pada beban. Misalnya, jika beban kerja Anda sedang melakukan pemeriksaan kondisi yang memantau kondisi dari ribuan server, beban kerja Anda harus mengirimkan payload berukuran sama (snapshot penuh berisi status saat ini) setiap saat. Saat tidak ada server yang gagal, atau semuanya gagal, sistem pemeriksaan kondisi melakukan tugas konstan tanpa perubahan besar dan cepat.
Misalnya, jika sistem pemeriksaan kondisi sedang memantau 100.000 server, beban di dalamnya kecil, dengan tingkat kegagalan server normal yang ringan. Namun, jika sebuah peristiwa besar menjadikan separuh server tidak sehat, sistem pemeriksaan kondisi akan kewalahan untuk memperbarui sistem notifikasi dan menyampaikan status ke kliennya. Jadi sebagai gantinya, sistem pemeriksaan kondisi harus mengirimkan snapshot penuh berisi status saat ini setiap saat. 100.000 status sehat server, masing-masing diwakili satu bit, hanyalah satu payload berukuran 12,5 KB. Saat tidak ada server yang gagal, atau semuanya gagal, sistem pemeriksaan kondisi melakukan tugas konstan, dan perubahan yang besar dan cepat bukanlah ancaman untuk stabilitas sistem. Seperti inilah Amazon Route 53 menangani pemeriksaan kondisi untuk titik akhir (seperti alamat IP) untuk menentukan bagaimana pengguna akhir dirutekan ke sana.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Rendah
## Panduan implementasi
+ Lakukan tugas konstan sehingga sistem tidak gagal saat terdapat perubahan beban yang besar dan cepat.
+ Implementasikan dependensi yang digabungkan secara longgar. Dependensi seperti sistem pengantrean, sistem streaming, alur kerja, dan penyeimbang beban digabungkan secara longgar. Penggabungan longgar membantu memisahkan perilaku suatu komponen dari komponen lainnya yang bergantung pada komponen tersebut, sehingga meningkatkan ketahanan dan ketangkasan.
+ [Amazon Builders' Library: Keandalan, kerja konstan, dan secangkir kopi yang enak](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (mencakup tugas konstan)](https://youtu.be/O8xLxNje30M?t=2482)
+ Untuk contoh sistem pemeriksaan kondisi yang memantau 100.000 server, rekayasa beban kerja sehingga ukuran payload tetap sama berapa pun jumlah keberhasilan atau kegagalan.
## Sumber daya
**Dokumen terkait:**
+ [Amazon EC2: Memastikan Idempotensi](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: Tantangan dengan sistem terdistribusi](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: Keandalan, kerja konstan, dan secangkir kopi yang enak](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Video terkait:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (mencakup tugas konstan)](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (mencakup penggabungan longgar, kerja konstan, stabilitas statis)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Menjadikan semua respons idempoten
Layanan idempoten menjanjikan setiap permintaan diselesaikan tepat satu kali, sehingga pembuatan beberapa permintaan yang sama memiliki efek yang sama seperti membuat satu permintaan. Layanan idempoten memudahkan klien untuk mengimplementasikan percobaan ulang tanpa takut permintaan akan salah diproses beberapa kali. Untuk melakukan ini, klien dapat mengeluarkan permintaan API dengan token idempotensi—token yang sama digunakan setiap permintaan diulang. API layanan idempoten menggunakan token untuk mengembalikan respons yang identik dengan respons yang dikembalikan saat pertama kali permintaan diselesaikan.
Dalam sistem terdistribusi, mudah untuk melakukan tindakan paling banyak satu kali (klien hanya membuat satu permintaan), atau setidaknya satu kali (tetap meminta sampai klien mendapat konfirmasi berhasil). Namun, sulit untuk menjamin suatu tindakan bersifat idempoten, yang berarti tindakan dilakukan *tepat* satu kali, sehingga pembuatan beberapa permintaan identik memiliki efek yang sama seperti membuat satu permintaan. Menggunakan token idempotensi di API, layanan dapat menerima permintaan yang bermutasi satu kali atau lebih tanpa membuat rekaman ganda atau efek samping.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Menjadikan semua respons idempoten. Layanan idempoten menjanjikan setiap permintaan diselesaikan tepat satu kali, sehingga pembuatan beberapa permintaan yang sama memiliki efek yang sama seperti membuat satu permintaan.
+ Klien dapat mengeluarkan permintaan API dengan token idempotensi—token yang sama digunakan setiap permintaan diulang. API layanan idempoten menggunakan token untuk mengembalikan respons yang identik dengan respons yang dikembalikan saat pertama kali permintaan diselesaikan.
+ [Amazon EC2: Memastikan Idempotensi](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
## Sumber daya
**Dokumen terkait:**
+ [Amazon EC2: Memastikan Idempotensi](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: Tantangan dengan sistem terdistribusi](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: Keandalan, kerja konstan, dan secangkir kopi yang enak](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Video terkait:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (mencakup penggabungan longgar, kerja konstan, stabilitas statis)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL 5. Bagaimana cara mendesain interaksi di sistem terdistribusi untuk memitigasi atau bertahan dari kegagalan?
Sistem terdistribusi mengandalkan jaringan komunikasi untuk membuat interkoneksi komponen (seperti server atau layanan). Beban kerja Anda harus beroperasi secara andal terlepas latensi atau hilangnya data di jaringan-jaringan ini. Komponen dari sistem terdistribusi harus beroperasi dengan cara yang tidak secara negatif memengaruhi beban kerja atau komponen-komponen lain. Berbagai praktik terbaik ini memungkinkan beban kerja bertahan dari stres atau kegagalan, lebih cepat pulih darinya, dan memitigasi dampak gangguan tersebut. Hasilnya yakni peningkatan dalam waktu rata-rata untuk pemulihan (MTTR).
**Topics**
+ [REL05-BP01 Mengimplementasikan degradasi yang tepat (graceful degradation) untuk mengubah dependensi keras yang berlaku menjadi dependensi lunak](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Membatasi (throttling) permintaan](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Mengontrol dan membatasi panggilan percobaan ulang](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Melakukan gagal cepat (fail fast) dan membatasi antrean](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Mengatur batas waktu klien](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Menjadikan layanan stateless jika memungkinkan](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Mengimplementasikan tuas darurat](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Mengimplementasikan degradasi yang tepat (graceful degradation) untuk mengubah dependensi keras yang berlaku menjadi dependensi lunak
Komponen aplikasi harus terus menjalankan fungsi intinya bahkan jika dependensi menjadi tidak tersedia. Komponen mungkin menyajikan data yang sedikit basi, data alternatif, atau bahkan tidak menyajikan data sama sekali. Hal ini memastikan fungsi sistem secara keseluruhan hanya terhambat secara minimum oleh kegagalan lokal sekaligus memberikan nilai bisnis utama.
**Hasil yang diinginkan:** Saat dependensi komponen tidak optimum, komponen tersebut masih dapat berfungsi, meskipun terbatas atau terdegradasi. Mode-mode kegagalan komponen harus dipandang sebagai operasi normal. Alur kerja harus dirancang sedemikian rupa sehingga kegagalan tersebut tidak menyebabkan kegagalan total atau setidaknya hanya menyebabkan keadaan yang dapat diprediksi dan dapat dipulihkan.
**Antipola umum:**
+ Tidak mengidentifikasi fungsi bisnis inti yang dibutuhkan. Tidak menguji bahwa komponen berfungsi bahkan selama kegagalan dependensi.
+ Tidak menyajikan data jika terjadi kesalahan atau ketika hanya ada satu dari beberapa dependensi yang tidak tersedia dan hasil parsial masih dapat dikembalikan.
+ Menciptakan keadaan yang tidak konsisten ketika transaksi gagal sebagian.
+ Tidak memiliki cara alternatif untuk mengakses tempat penyimpanan parameter pusat.
+ Membatalkan atau mengosongkan status lokal sebagai akibat dari penyegaran yang gagal tanpa mempertimbangkan konsekuensi tindakan tersebut.
**Manfaat menjalankan praktik terbaik ini:** Degradasi bertahap (graceful degradation) meningkatkan ketersediaan sistem secara keseluruhan dan mempertahankan fungsionalitas fungsi-fungsi yang paling penting, bahkan selama kegagalan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Menerapkan degradasi yang tepat membantu meminimalkan dampak kegagalan dependensi pada fungsi komponen. Idealnya, sebuah komponen mendeteksi kegagalan dependensi dan menanganinya dengan cara yang berdampak minim pada pelanggan atau komponen lain.
Merancang untuk degradasi yang tepat berarti mempertimbangkan potensi mode kegagalan selama desain dependensi. Untuk setiap mode kegagalan, miliki cara untuk menghadirkan sebagian besar atau setidaknya fungsionalitas paling penting dari komponen kepada pemanggil atau pelanggan. Pertimbangan ini dapat menjadi persyaratan tambahan yang dapat diuji dan diverifikasi. Idealnya, sebuah komponen mampu menjalankan fungsi intinya dengan cara yang dapat diterima bahkan ketika satu atau beberapa dependensi gagal.
Ini bukan hanya pembahasan teknis, melainkan juga pembahasan bisnis. Semua persyaratan bisnis penting dan harus dipenuhi jika memungkinkan. Namun, menanyakan apa yang seharusnya terjadi ketika tidak semua persyaratan tersebut dapat dipenuhi adalah hal yang wajar. Suatu sistem dapat dirancang agar tersedia dan konsisten, tetapi dalam keadaan yang mengharuskan satu persyaratan untuk dikorbankan, mana yang lebih penting? Untuk pemrosesan pembayaran, jawabannya mungkin adalah konsistensi. Untuk aplikasi waktu nyata, jawabannya mungkin adalah ketersediaan. Untuk situs web yang digunakan langsung oleh pelanggan, jawabannya mungkin tergantung pada ekspektasi pelanggan.
Seberapa pentingnya, ini tergantung persyaratan komponen dan apa yang seharusnya dianggap sebagai fungsi intinya. Misalnya:
+ Situs web ecommerce mungkin menampilkan data dari berbagai sistem seperti rekomendasi yang dipersonalisasi, produk dengan peringkat tertinggi, dan status pesanan pelanggan di halaman arahan. Ketika salah satu sistem hulu gagal, masih masuk akal untuk menampilkan semua daripada halaman kesalahan kepada pelanggan.
+ Sebuah komponen yang menjalankan penulisan batch masih dapat melanjutkan pemrosesan batch jika salah satu operasi gagal. Implementasi mekanisme percobaan ulang harus sederhana. Hal ini dapat dilakukan dengan mengembalikan informasi tentang operasi yang berhasil, yang telah gagal, dan mengapa operasi tersebut gagal ke pemanggil, atau dengan menempatkan permintaan yang gagal ke dalam antrean surat mati untuk mengimplementasikan percobaan ulang asinkron. Informasi tentang operasi yang gagal juga harus dibuat log.
+ Sistem yang memproses transaksi harus memverifikasi bahwa semua pembaruan individual dijalankan atau tidak sama sekali. Untuk transaksi terdistribusi, pola saga dapat digunakan untuk kembali ke operasi sebelumnya jika operasi selanjutnya dari transaksi yang sama gagal. Di sini, fungsi intinya adalah menjaga konsistensi.
+ Sistem-sistem time-critical harus mampu menangani dependensi yang tidak merespons secara tepat waktu. Dalam kasus-kasus ini, pola pemutus sirkuit dapat digunakan. Ketika respons dari dependensi mulai mencapai batas waktu, sistem dapat beralih ke keadaan ditutup di mana tidak ada panggilan tambahan yang dibuat.
+ Sebuah aplikasi dapat membaca parameter dari tempat penyimpanan parameter. Membuat image kontainer dengan serangkaian parameter default akan membantu agar apabila tempat penyimpanan parameter tidak tersedia image tersebut dapat digunakan.
Perhatikan bahwa jalur yang diambil jika terjadi kegagalan komponen perlu diuji dan harus jauh lebih sederhana daripada jalur utama. Umumnya, [strategi fallback harus dihindari](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/).
## Langkah implementasi
Identifikasi dependensi eksternal dan internal. Pertimbangkan jenis-jenis kegagalan yang bisa terjadi di dalamnya. Pikirkan tentang cara-cara yang meminimalkan dampak negatif pada pelanggan serta sistem hulu dan hilir selama kegagalan-kegagalan tersebut.
Berikut ini adalah daftar dependensi dan cara melakukan degradasi yang tepat ketika dependensi gagal:
1. **Kegagalan dependensi sebagian:** Sebuah komponen dapat melakukan beberapa permintaan ke sistem-sistem hilir, baik beberapa permintaan ke satu sistem atau satu permintaan ke beberapa sistem. Tergantung konteks bisnis, mungkin ada berbagai cara penanganan yang sesuai (untuk detail lebih lanjut, lihat contoh-contoh sebelumnya dalam Panduan implementasi).
1. **Sistem hilir tidak dapat memproses permintaan karena beban tinggi:** Jika permintaan ke sistem hilir terus-menerus gagal, percobaan ulang tidak perlu dilanjutkan. Tindakan ini dapat menciptakan beban tambahan pada sistem yang sudah kelebihan beban dan mempersulit pemulihan. Pola pemutus sirkuit dapat digunakan di sini, yang memantau kegagalan panggilan ke sistem hilir. Jika ada banyak panggilan yang gagal, permintaan akan berhenti dikirimkan ke sistem hilir dan hanya sesekali panggilan dibiarkan masuk untuk menguji apakah sistem hilir sudah tersedia kembali.
1. **Tempat penyimpanan parameter tidak tersedia:** Untuk mengubah tempat penyimpanan parameter, caching dependensi lunak atau sane default yang disertakan di dalam image kontainer atau mesin dapat digunakan. Perhatikan bahwa default ini harus selalu diperbarui dan disertakan dalam rangkaian pengujian.
1. **Layanan pemantauan atau dependensi non-fungsional lainnya tidak tersedia:** Jika sebuah komponen sebentar-sebentar tidak dapat mengirim log, metrik, atau jejak ke layanan pemantauan pusat, langkah terbaiknya sering kali adalah tetap menjalankan fungsi-fungsi bisnis seperti biasa. Diam-diam tidak membuat log atau mendorong metrik dalam waktu yang lama sering kali tidak dapat diterima. Selain itu, beberapa kasus penggunaan mungkin memerlukan entri audit lengkap untuk memenuhi persyaratan kepatuhan.
1. **Sebuah instans utama dari basis data relasional mungkin tidak tersedia:** Amazon Relational Database Service, seperti hampir semua basis data relasional, hanya dapat memiliki satu instans penulis utama. Hal ini menciptakan satu titik kegagalan untuk beban kerja tulis dan menjadikan penskalaan lebih sulit. Hal ini dapat diatasi sebagiannya dengan menggunakan konfigurasi Multi-AZ untuk ketersediaan tinggi atau Nirserver Amazon Aurora untuk penskalaan yang lebih baik. Untuk persyaratan ketersediaan yang sangat tinggi, ada baiknya untuk tidak bergantung pada penulis utama sama sekali. Untuk kueri yang hanya membaca, replika baca dapat digunakan, yang memberikan redundansi dan kemampuan untuk melakukan scale-out, bukan hanya scale-up. Tulis dapat di-buffer, misalnya dalam antrean Amazon Simple Queue Service, sehingga permintaan tulis dari pelanggan masih dapat diterima bahkan jika penulis utama tidak tersedia untuk sementara.
## Sumber daya
**Dokumen terkait:**
+ [Amazon API Gateway: Membatasi Permintaan API untuk Peningkatan Throughput ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (rangkuman Pemutus Sirkuit dari buku “Release It\$1”)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Kesalahan Percobaan Ulang dan Mundur Eksponensial di AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard “Release It\$1 Design and Deploy Production-Ready Software” (Rancang dan Lakukan Deployment Perangkat Lunak yang Siap Diproduksi)](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [Pustaka Pengembang Amazon: Menghindari fallback dalam sistem terdistribusi](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Pustaka Pengembang Amazon: Menghindari backlog antrean yang tidak dapat diatasi](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Pustaka Pengembang Amazon: Tantangan dan strategi caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Pustaka Pengembang Amazon: Batas waktu, percobaan ulang, dan mundur (backoff) dengan jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video terkait:**
+ [Percobaan ulang, mundur, dan jitter: AWS re:Invent 2019: Memperkenalkan Pustaka Pengembang Amazon (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**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)
# REL05-BP02 Membatasi (throttling) permintaan
Batasi permintaan untuk mengurangi keletihan sumber daya karena peningkatan permintaan yang tidak terduga. Permintaan di bawah tingkat throttling akan diproses, sedangkan permintaan di atas batas yang ditentukan akan ditolak dengan memunculkan pesan bahwa permintaan telah dibatasi.
**Hasil yang diinginkan:** Lonjakan volume besar baik dari peningkatan lalu lintas pelanggan yang tiba-tiba, serangan membanjir, atau banjir percobaan ulang akan diminimalkan dengan throttling permintaan, sehingga beban kerja dapat melanjutkan pemrosesan volume permintaan normal yang didukung.
**Antipola umum:**
+ Throttle titik akhir API tidak diimplementasikan atau dibiarkan pada nilai default tanpa mempertimbangkan volume yang diharapkan.
+ Titik akhir API tidak diberi uji beban atau batas throttling tidak diuji.
+ Membatasi angka permintaan tanpa mempertimbangkan ukuran atau kompleksitas permintaan.
+ Menguji laju permintaan maksimum atau ukuran permintaan maksimum, tetapi tidak menguji keduanya bersama-sama.
+ Sumber daya tidak disediakan untuk batas yang sama yang ditetapkan dalam pengujian.
+ Rencana penggunaan belum dikonfigurasi atau dipertimbangkan untuk konsumen API aplikasi ke aplikasi (A2A).
+ Tidak ada konfigurasi pengaturan konkurensi maksimum pada konsumen antrean yang diskalakan secara horizontal.
+ Pembatasan tingkat per alamat IP belum diimplementasikan.
**Manfaat menjalankan praktik terbaik ini:** Beban kerja yang menetapkan batas throttle dapat beroperasi secara normal dan berhasil memproses beban permintaan yang diterima selama lonjakan volume yang tidak terduga. Lonjakan permintaan yang tiba-tiba atau terus menerus pada API dan antrean dibatasi dan tidak menghabiskan sumber daya pemrosesan permintaan. Batas angka permintaan membatasi setiap peminta sehingga volume lalu lintas yang tinggi dari satu alamat IP atau konsumen API tidak akan menghabiskan sumber daya atau berimbas pada konsumen lain.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Layanan harus dirancang untuk memproses kapasitas permintaan yang diketahui; kapasitas ini dapat ditetapkan melalui pengujian beban. Jika laju kedatangan permintaan melampaui batas, respons yang tepat menandakan bahwa permintaan telah dibatasi. Hal ini memungkinkan konsumen untuk menangani kesalahan dan mencoba ulang di lain waktu.
Saat layanan Anda memerlukan implementasi throttling, pertimbangkan mengimplementasikan algoritme bucket token, yang menghitung satu token sebagai satu permintaan. Token diisi ulang dengan laju throttle per detik dan dikosongkan secara asinkron oleh satu token per permintaan.
![\[Diagram yang menggambarkan algoritme bucket token.\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/token-bucket-algorithm.png)
[Amazon API Gateway](https://aws.amazon.com/api-gateway/) mengimplementasikan algoritme bucket token sesuai dengan batas yang dimiliki akun dan wilayah dan dapat dikonfigurasi per klien dengan rencana penggunaan. Selain itu, [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) dan [Amazon Kinesis](https://aws.amazon.com/kinesis/) dapat melakukan buffer permintaan untuk memuluskan laju permintaan, dan memungkinkan tingkat throttling yang lebih tinggi untuk permintaan yang dapat diatasi. Terakhir, Anda dapat menerapkan pembatasan laju dengan [AWS WAF](https://aws.amazon.com/waf/) untuk membatasi konsumen API tertentu yang menghasilkan beban yang terlalu tinggi.
## Langkah implementasi
Anda dapat mengonfigurasi API Gateway dengan batas throttling untuk API dan mengembalikan pesan kesalahan `429 Terlalu Banyak Permintaan` ketika batas terlampaui. Anda dapat menggunakan AWS WAF dengan titik akhir AWS AppSync dan API Gateway Anda untuk mengaktifkan pembatasan laju per alamat IP. Selain itu, apabila sistem Anda dapat mentoleransi pemrosesan asinkron, Anda dapat memasukkan pesan ke dalam antrean atau aliran guna mempercepat respons terhadap klien layanan, yang memungkinkan Anda melakukan lonjakan ke tingkat throttle yang lebih tinggi.
Dengan pemrosesan asinkron, ketika Anda telah mengonfigurasi Amazon SQS sebagai sumber peristiwa untuk AWS Lambda, Anda dapat [mengonfigurasi konkurensi maksimum](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) untuk mencegah angka peristiwa yang tinggi memakai kuota eksekusi serentak akun yang tersedia yang diperlukan untuk layanan lain dalam beban kerja atau akun Anda.
Meskipun API Gateway menyediakan implementasi bucket token yang dikelola, apabila Anda tidak dapat menggunakan API Gateway, Anda dapat memanfaatkan implementasi sumber terbuka bahasa khusus (lihat contoh terkait di Sumber Daya) bucket token untuk layanan Anda.
+ Pahami dan konfigurasi [batas throttling API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) di tingkat akun per wilayah, API per tahap, dan kunci API per tingkat paket penggunaan.
+ Terapkan [aturan pembatas laju AWS WAF](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) ke titik akhir API Gateway dan AWS AppSync untuk melindungi dari permintaan yang membanjir dan memblokir IP berbahaya. Aturan pembatas laju juga dapat dikonfigurasi pada kunci API AWS AppSync untuk konsumen A2A.
+ Pertimbangkan apakah Anda memerlukan kontrol throttling yang lebih besar daripada pembatasan laju untuk API AWS AppSync, dan jika demikian, konfigurasikan API Gateway di depan titik akhir AWS AppSync Anda.
+ Ketika antrean Amazon SQS diatur sebagai pemicu untuk konsumen antrean Lambda, tetapkan [konkurensi maksimum](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) ke nilai yang memproses cukup banyak untuk memenuhi tujuan tingkat layanan Anda tetapi tidak menggunakan batas konkurensi yang memengaruhi fungsi Lambda lain. Pertimbangkan untuk menetapkan konkurensi cadangan pada fungsi Lambda lain di akun dan wilayah yang sama saat Anda menggunakan antrean dengan Lambda.
+ Gunakan API Gateway dengan integrasi layanan native ke Amazon SQS atau Kinesis untuk melakukan buffer permintaan.
+ Jika Anda tidak dapat menggunakan API Gateway, lihat pustaka bahasa khusus untuk mengimplementasikan algoritme bucket token untuk beban kerja Anda. Periksa bagian contoh dan lakukan riset sendiri untuk menemukan pustaka yang cocok.
+ Uji batas yang ingin Anda tetapkan, atau yang ingin Anda izinkan untuk ditingkatkan, dan dokumentasikan batas yang diuji.
+ Jangan tingkatkan batas melebihi apa yang Anda tetapkan dalam pengujian. Saat meningkatkan batas, verifikasi bahwa sumber daya yang disediakan sudah setara atau lebih besar daripada yang ada dalam skenario pengujian sebelum menerapkan peningkatan.
## Sumber daya
**Praktik terbaik terkait:**
+ [REL04-BP03 Melakukan tugas konstan](rel_prevent_interaction_failure_constant_work.md)
+ [REL05-BP03 Mengontrol dan membatasi panggilan percobaan ulang](rel_mitigate_interaction_failure_limit_retries.md)
**Dokumen terkait:**
+ [Amazon API Gateway: Membatasi Permintaan API untuk Peningkatan Throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS WAF: Pernyataan aturan berbasis laju ](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
+ [ Memperkenalkan konkurensi maksimum AWS Lambda saat menggunakan Amazon SQS sebagai sumber peristiwa ](https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/)
+ [AWS Lambda: Konkurensi Maksimum ](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)
**Contoh terkait:**
+ [ Tiga aturan berbasis laju AWS WAF yang paling penting ](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)
+ [ Java Bucket4j ](https://github.com/bucket4j/bucket4j)
+ [ Bucket token Python ](https://pypi.org/project/token-bucket/)
+ [ Bucket token Node ](https://www.npmjs.com/package/tokenbucket)
+ [ Pembatasan Tingkat Threading Sistem .NET ](https://www.nuget.org/packages/System.Threading.RateLimiting)
**Video terkait:**
+ [ Mengimplementasikan praktik terbaik keamanan API GraphQL dengan AWS AppSync](https://www.youtube.com/watch?v=1ASMLeJ_15U)
**Alat terkait:**
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon Kinesis ](https://aws.amazon.com/kinesis/)
+ [AWS WAF](https://aws.amazon.com/waf/)
# REL05-BP03 Mengontrol dan membatasi panggilan percobaan ulang
Gunakan mundur eksponensial untuk mencoba ulang permintaan dengan interval yang makin lama antara setiap percobaan ulang. Terapkan jitter antara percobaan ulang untuk mengacak interval percobaan ulang. Batasi jumlah percobaan ulang maksimum.
**Hasil yang diinginkan:** Komponen di sistem perangkat lunak terdistribusi biasanya mencakup server, penyeimbang beban, basis data, dan server DNS. Selama operasi normal, komponen-komponen ini dapat merespons permintaan dengan kesalahan yang bersifat sementara atau terbatas, dan juga kesalahan yang persisten terlepas dari percobaan ulang. Ketika klien membuat permintaan ke layanan, permintaan tersebut mengonsumsi sumber daya termasuk memori, thread, koneksi, port, atau sumber daya terbatas lainnya. Mengontrol dan membatasi percobaan ulang adalah strategi untuk melepaskan dan meminimalkan konsumsi sumber daya sehingga komponen sistem yang ada di bawah tekanan tidak kewalahan.
Ketika permintaan klien mengalami batas waktu atau menerima respons kesalahan, mereka harus menentukan apakah akan mencoba lagi atau tidak. Jika mereka mencoba lagi, mereka melakukannya dengan mundur eksponensial dengan jitter dan nilai coba ulang maksimum. Karena itu, layanan dan proses backend mendapat kelonggaran beban dan waktu untuk pulih secara mandiri, sehingga menghasilkan pemulihan yang lebih cepat dan pelayanan permintaan yang berhasil.
**Antipola umum:**
+ Mengimplementasikan percobaan ulang tanpa menambahkan mundur eksponensial, jitter, dan nilai coba ulang maksimum. Mundur dan jitter membantu menghindari lonjakan lalu lintas semu yang disebabkan percobaan ulang yang dikoordinasikan secara tidak sengaja pada interval umum.
+ Mengimplementasikan percobaan ulang tanpa menguji efeknya atau berasumsi bahwa percobaan ulang sudah terintegrasi ke dalam SDK tanpa menguji skenario percobaan ulang.
+ Tidak memahami kode kesalahan yang dipublikasikan dari dependensi, yang menyebabkan percobaan ulang semua kesalahan, termasuk kesalahan dengan penyebab jelas yang menunjukkan tidak adanya izin, kesalahan konfigurasi, atau kondisi lain yang jelas tidak akan terselesaikan tanpa intervensi manual.
+ Tidak menangani praktik observabilitas, termasuk pemantauan dan peringatan tentang kegagalan layanan berulang sehingga masalah yang mendasari dapat diketahui dan diatasi.
+ Mengembangkan mekanisme percobaan ulang kustom saat kemampuan coba ulang bawaan atau pihak ketiga sudah mencukupi.
+ Mencoba ulang pada beberapa lapisan tumpukan aplikasi dengan cara yang makin memperparah upaya-upaya percobaan ulang sehingga makin menyita sumber daya dalam badai percobaan ulang. Pastikan Anda memahami bagaimana kesalahan-kesalahan ini memengaruhi aplikasi Anda dan dependensi yang Anda andalkan, lalu terapkan percobaan ulang hanya pada satu tingkat.
+ Mencoba ulang panggilan layanan yang tidak idempoten, sehingga menyebabkan efek samping yang tidak terduga seperti hasil-hasil ganda.
**Manfaat menjalankan praktik terbaik ini:** Percobaan ulang membantu klien memperoleh hasil yang diinginkan ketika permintaan gagal tetapi juga menyita lebih banyak waktu server untuk mendapatkan respons berhasil yang mereka inginkan. Ketika kegagalan jarang terjadi atau sementara, percobaan ulang dapat berfungsi dengan baik. Ketika kegagalan disebabkan oleh kelebihan beban sumber daya, percobaan ulang dapat memperburuk keadaan. Menambahkan mundur eksponensial dengan jitter ke percobaan ulang klien memungkinkan server pulih ketika kegagalan disebabkan oleh kelebihan beban sumber daya. Jitter menghindarkan penyelarasan permintaan menjadi lonjakan, dan mundur dapat mengurangi eskalasi beban yang disebabkan oleh penambahan percobaan ulang ke beban permintaan normal. Terakhir, penting untuk mengonfigurasi jumlah coba ulang maksimum atau waktu yang telah berlalu untuk menghindari terciptanya backlog yang menghasilkan kegagalan yang metastabil.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Mengontrol dan membatasi panggilan percobaan ulang. Gunakan mundur eksponensial untuk percobaan ulang setelah interval yang makin lama. Masukkan jitter untuk mengacak interval percobaan ulang dan batasi jumlah percobaan ulang maksimum.
Beberapa SDK AWS mengimplementasikan percobaan ulang dan mundur eksponensial secara default. Gunakan implementasi AWS bawaan ini jika diperlukan untuk beban kerja Anda. Implementasikan logika serupa dalam beban kerja Anda saat memanggil layanan yang idempoten dan apabila percobaan ulang meningkatkan ketersediaan klien Anda. Tentukan batas waktu dan kapan harus berhenti mencoba ulang berdasarkan kasus penggunaan Anda. Buat dan latih skenario pengujian untuk kasus penggunaan percobaan ulang tersebut.
## Langkah implementasi
+ Tentukan lapisan optimal dalam tumpukan aplikasi Anda untuk mengimplementasikan percobaan ulang untuk layanan yang diandalkan aplikasi Anda.
+ Waspadai SDK yang ada yang menerapkan strategi percobaan ulang yang telah terbukti dengan mundur eksponensial dan jitter untuk bahasa pilihan Anda, dan pilih opsi ini daripada menulis implementasi percobaan ulang Anda sendiri.
+ Verifikasikan bahwa [layanan bersifat idempoten](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) sebelum menerapkan percobaan ulang. Setelah percobaan ulang diterapkan, pastikan keduanya diuji dan latihlah secara rutin dalam produksi.
+ Saat memanggil API layanan AWS, gunakan [SDK AWS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) dan [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html) dan pahami opsi-opsi konfigurasi percobaan ulang. Tentukan apakah konfigurasi default cocok untuk kasus penggunaan Anda, uji, dan sesuaikan sesuai kebutuhan.
## Sumber daya
**Praktik terbaik terkait:**
+ [REL04-BP04 Menjadikan semua respons idempoten](rel_prevent_interaction_failure_idempotent.md)
+ [REL05-BP02 Membatasi (throttling) permintaan](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP04 Melakukan gagal cepat (fail fast) dan membatasi antrean](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Mengatur batas waktu klien](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](rel_withstand_component_failures_monitoring_health.md)
**Dokumen terkait:**
+ [Kesalahan Percobaan Ulang dan Mundur Eksponensial di AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library: Batas waktu, percobaan ulang, dan mundur (backoff) dengan jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [ Mundur Eksponensial dan Jitter ](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)
+ [ Menjadikan percobaan ulang aman dengan API idempoten ](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
**Contoh terkait:**
+ [ Spring Retry ](https://github.com/spring-projects/spring-retry)
+ [ Resilience4j Retry ](https://resilience4j.readme.io/docs/retry)
**Video terkait:**
+ [Percobaan ulang, mundur, dan jitter: AWS re:Invent 2019: Memperkenalkan Pustaka Pengembang Amazon (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**Alat terkait:**
+ [ SDK dan Alat-Alat AWS: Perilaku percobaan ulang ](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)
+ [AWS Command Line Interface: Percobaan ulang AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)
# REL05-BP04 Melakukan gagal cepat (fail fast) dan membatasi antrean
Ketika layanan tidak berhasil merespons permintaan, lakukanlah gagal cepat (fail fast). Hal ini memungkinkan pelepasan sumber daya yang terkait dengan permintaan, dan mengizinkan layanan untuk melakukan pemulihan jika kehabisan sumber daya. Gagal cepat adalah pola desain perangkat lunak mapan yang dapat dimanfaatkan untuk membangun beban kerja yang sangat andal di cloud. Antrean juga merupakan pola integrasi korporat yang mapan yang dapat memperlancar beban dan memungkinkan klien untuk melepaskan sumber daya ketika pemrosesan asinkron dapat ditoleransi. Ketika layanan berhasil merespons dalam kondisi normal tetapi gagal ketika laju permintaan terlalu tinggi, gunakan antrean untuk melakukan buffer permintaan. Namun, jangan sampai ada penumpukan backlog antrean panjang yang dapat mengakibatkan diprosesnya permintaan yang telah kedaluwarsa dan telah ditinggalkan klien.
**Hasil yang diinginkan:** Ketika sistem berebut sumber daya, mengalami waktu habis, pengecualian, atau grey failure (kegagalan samar-samar) yang menyebabkan target tingkat layanan tidak dapat dicapai, strategi gagal cepat memungkinkan pemulihan sistem yang lebih cepat. Sistem yang harus menyerap lonjakan lalu lintas dan dapat mengakomodasi pemrosesan asinkron dapat meningkatkan keandalan dengan memungkinkan klien untuk secara cepat melepaskan permintaan dengan menggunakan antrean untuk melakukan buffer permintaan ke layanan backend. Ketika melakukan buffer permintaan ke antrean, strategi manajemen antrean diimplementasikan untuk menghindari backlog yang terlalu membebani.
**Antipola umum:**
+ Mengimplementasikan antrean pesan tetapi tidak mengonfigurasi antrean surat mati (DLQ) atau alarm pada volume DLQ untuk mendeteksi kegagalan sistem.
+ Tidak mengukur usia pesan dalam antrean, yaitu ukuran latensi untuk mengetahui kapan konsumen antrean tertinggal atau mengalami kesalahan yang menyebabkan percobaan ulang.
+ Tidak menghapus pesan-pesan yang menumpuk dari antrean, padahal tidak ada gunanya memproses pesan-pesan tersebut jika kebutuhan bisnis sudah tidak ada.
+ Mengonfigurasi antrean first in first out (FIFO), padahal antrean last in first out (LIFO) lebih memenuhi kebutuhan klien, misalnya ketika pengurutan yang ketat tidak diperlukan dan pemrosesan backlog menunda semua permintaan baru dan sensitif waktu sehingga semua klien merasa tingkat layanan gagal dipenuhi.
+ Mengekspos antrean internal ke klien, bukan mengekspos API yang mengelola masuknya pekerjaan dan menempatkan permintaan ke dalam antrean internal.
+ Menggabungkan terlalu banyak jenis permintaan kerja ke dalam satu antrean yang dapat memperburuk kondisi backlog dengan menyebarkan permintaan sumber daya di seluruh jenis permintaan.
+ Memproses permintaan yang kompleks dan sederhana dalam antrean yang sama, sehingga mengabaikan perbedaan kebutuhan pemantauan, batas waktu, dan alokasi sumber daya.
+ Tidak memvalidasi input atau menggunakan pernyataan untuk mengimplementasikan mekanisme gagal cepat dalam perangkat lunak yang menaikkan pengecualian ke komponen dengan level lebih tinggi yang dapat menangani kesalahan secara mulus.
+ Tidak menghapus sumber daya yang rusak dari perutean permintaan, terutama ketika kegagalan samar-samar yang menunjukkan keberhasilan sekaligus kegagalan akibat crash dan mulai ulang, kegagalan dependensi intermiten, kapasitas yang menurun, atau hilangnya paket jaringan.
**Manfaat menjalankan praktik terbaik ini:** Sistem yang gagal cepat lebih mudah untuk di-debug dan diperbaiki, dan sering mengekspos masalah dalam pengodean dan konfigurasi sebelum rilis dipublikasikan ke tahap produksi. Sistem yang menggabungkan strategi antrean yang efektif memberikan ketahanan dan keandalan yang lebih baik terhadap lonjakan lalu lintas dan kondisi gangguan sistem intermiten.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Strategi gagal cepat dapat dikodekan ke dalam solusi perangkat lunak serta dikonfigurasi ke dalam infrastruktur. Selain gagal cepat, antrean adalah teknik arsitektur yang sederhana namun ampuh untuk memisahkan komponen-komponen sistem dan memperlancar beban. [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) menyediakan kemampuan untuk memantau dan memberikan alarm kegagalan. Setelah sistem diketahui mengalami kegagalan, strategi mitigasi dapat dipanggil, termasuk gagal dan menjauh (fail away) dari sumber daya yang terdampak. Ketika sistem mengimplementasikan antrean dengan [Amazon SQS](https://aws.amazon.com/sqs/) dan teknologi antrean lainnya untuk melancarkan beban, sistem harus mempertimbangkan bagaimana mengelola backlog antrean, serta kegagalan konsumsi pesan.
## Langkah implementasi
+ Implementasikan pernyataan terprogram atau metrik tertentu dalam perangkat lunak Anda dan gunakan untuk memperingatkan secara eksplisit tentang masalah sistem. Amazon CloudWatch membantu Anda membuat metrik dan alarm berdasarkan pola log aplikasi dan instrumentasi SDK.
+ Gunakan metrik dan alarm CloudWatch untuk gagal dan menjauh dari sumber daya terdampak yang menambahkan latensi ke pemrosesan atau berulang kali gagal memproses permintaan.
+ Gunakan pemrosesan asinkron dengan merancang API untuk menerima permintaan dan menambahkan permintaan ke antrean internal menggunakan Amazon SQS kemudian menanggapi klien penghasil pesan dengan pesan keberhasilan sehingga klien dapat melepaskan sumber daya dan beralih dengan pekerjaan lain sementara konsumen antrean backend memproses permintaan.
+ Ukur dan pantau latensi pemrosesan antrean dengan menghasilkan metrik CloudWatch setiap kali Anda melepaskan sebuah pesan dari antrean dengan membandingkan sekarang dengan stempel waktu pesan.
+ Ketika kegagalan menghambat keberhasilan pemrosesan pesan atau volume lalu lintas melonjak sehingga tidak dapat diproses dalam batas perjanjian tingkat layanan, sisihkan lalu lintas yang lebih lama atau berlebih ke antrean spillover. Hal ini memungkinkan pemrosesan prioritas pada pekerjaan baru, dan pekerjaan yang lebih lama ketika kapasitas tersedia. Teknik ini mirip dengan pemrosesan LIFO dan memungkinkan pemrosesan sistem yang normal untuk semua pekerjaan baru.
+ Gunakan antrean surat mati atau redrive untuk memindahkan pesan yang tidak dapat diproses dari backlog ke lokasi yang dapat dicari ulang dan diselesaikan lain waktu
+ Coba lagi atau, apabila dapat ditoleransi, singkirkan pesan lama dengan membandingkan sekarang dengan stempel waktu pesan dan membuang pesan yang sudah tidak relevan dengan klien yang melakukan permintaan.
## Sumber daya
**Praktik terbaik terkait:**
+ [REL04-BP02 Mengimplementasikan dependensi yang digabungkan secara longgar](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP02 Membatasi (throttling) permintaan](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Mengontrol dan membatasi panggilan percobaan ulang](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL06-BP02 Menetapkan dan menghitung metrik (Agregasi)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP07 Memantau pelacakan permintaan menyeluruh melalui sistem Anda](rel_monitor_aws_resources_end_to_end.md)
**Dokumen terkait:**
+ [ Menghindari backlog antrian yang terlalu membebani ](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs/)
+ [Gagal Cepat (Fail Fast)](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [ Bagaimana cara mencegah peningkatan backlog pesan dalam antrean Amazon SQS saya? ](https://repost.aws/knowledge-center/sqs-message-backlog)
+ [ Elastic Load Balancing: Peralihan Zona ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/zonal-shift.html)
+ [ Pengontrol Pemulihan Aplikasi Amazon Route 53: Kontrol perutean untuk failover lalu lintas ](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-routing-controls.html)
**Contoh terkait:**
+ [ Pola Integrasi Korporat: Saluran Surat Mati ](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html)
**Video terkait:**
+ [AWS re:Invent 2022 - Mengoperasikan aplikasi Multi-AZ dengan ketersediaan tinggi](https://www.youtube.com/watch?v=mwUV5skJJ0s)
**Alat terkait:**
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon MQ ](https://aws.amazon.com/amazon-mq/)
+ [AWS IoT Core](https://aws.amazon.com/iot-core/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
# REL05-BP05 Mengatur batas waktu klien
Atur batas waktu secara tepat pada koneksi dan permintaan, verifikasikan waktu tersebut secara sistematis, dan jangan selalu bergantung pada nilai default karena nilai tersebut mengabaikan hal-hal spesifik tentang beban kerja.
**Hasil yang diinginkan:** Batas waktu klien harus mempertimbangkan biaya untuk klien, server, dan beban kerja yang berkaitan dengan proses tunggu permintaan yang memerlukan waktu sangat lama untuk diselesaikan. Karena penyebab batas waktu tidak mungkin diketahui secara pasti, klien harus menggunakan pengetahuan tentang layanan untuk membangun ekspektasi tentang kemungkinan penyebab dan batas waktu yang tepat
Koneksi klien mengalami waktu habis berdasarkan nilai yang dikonfigurasi. Setelah mengalami batas waktu, klien mengambil keputusan untuk mundur dan mencobanya lagi atau membuka [pemutus sirkuit](https://martinfowler.com/bliki/CircuitBreaker.html). Pola-pola ini mencegah mengeluarkan permintaan yang dapat memperburuk kondisi kesalahan yang menyebabkannya.
**Antipola umum:**
+ Tidak menyadari batas waktu sistem atau batas waktu default.
+ Tidak menyadari waktu penyelesaian permintaan normal.
+ Tidak menyadari kemungkinan penyebab permintaan membutuhkan waktu yang terlalu lama untuk diselesaikan, atau biaya untuk klien, layanan, atau kinerja beban kerja yang berkaitan dengan proses tunggu penyelesaian ini.
+ Tidak menyadari kemungkinan jaringan rusak yang menyebabkan permintaan gagal hanya setelah batas waktu tercapai, dan biaya untuk klien dan kinerja beban kerja karena tidak mengadopsi batas waktu yang lebih singkat.
+ Tidak menguji skenario batas waktu baik untuk koneksi maupun permintaan.
+ Mengatur batas waktu terlalu tinggi, yang berimbas pada waktu tunggu yang lama dan meningkatkan pemanfaatan sumber daya.
+ Mengatur batas waktu terlalu rendah, sehingga mengakibatkan kegagalan buatan.
+ Mengabaikan pola-pola untuk menangani kesalahan batas waktu untuk panggilan jarak jauh seperti pemutus sirkuit dan percobaan ulang.
+ Tidak mempertimbangkan pemantauan untuk angka kesalahan panggilan layanan, target latensi di tingkat layanan, dan outlier latensi. Metrik-metrik ini dapat memberikan wawasan tentang batas waktu yang agresif atau permisif
**Manfaat menjalankan praktik terbaik ini:** Waktu tunggu panggilan jarak jauh dikonfigurasi dan sistem dirancang untuk menangani batas waktu secara perlahan sehingga sumber daya dihemat ketika panggilan jarak jauh merespons terlalu lambat dan kesalahan batas waktu ditangani secara perlahan oleh klien layanan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Atur batas waktu koneksi dan batas waktu permintaan untuk panggilan dependensi layanan apa pun, serta secara umum untuk panggilan apa pun di seluruh proses. Banyak kerangka kerja yang menawarkan kemampuan batas waktu bawaan, tetapi Anda harus tetap memperhatikan bahwa nilai default bawaan bisa saja tidak terbatas atau lebih tinggi dari yang dapat diterima untuk sasaran layanan Anda. Nilai yang terlalu tinggi mengurangi kegunaan batas waktu karena sumber daya terus terpakai saat klien menunggu terjadinya batas waktu. Nilai yang terlalu rendah akan menyebabkan lalu lintas yang tinggi di backend serta meningkatkan latensi karena terlalu banyak permintaan yang dicoba ulang. Dalam beberapa kasus, hal ini dapat menyebabkan penghentian total karena semua permintaan dicoba ulang.
Pertimbangkan hal berikut saat menentukan strategi batas waktu:
+ Permintaan mungkin membutuhkan waktu pemrosesan yang lebih lama dari biasanya dikarenakan kontennya, gangguan pada layanan target, atau kegagalan partisi jaringan.
+ Permintaan dengan konten yang terlalu mahal dapat mengonsumsi sumber daya server dan klien yang tidak perlu. Dalam hal ini, membatasi waktu dan tidak mencoba ulang permintaan tersebut dapat menghemat sumber daya. Layanan juga harus melindungi diri dari konten yang terlalu mahal dengan throttle dan batas waktu sisi server.
+ Permintaan yang memakan waktu terlalu lama karena gangguan layanan dapat diberikan batas waktu dan dicoba ulang. Pertimbangan harus diberikan pada biaya layanan untuk permintaan dan percobaan ulang, tetapi jika penyebabnya adalah gangguan yang terbatas di suatu tempat, percobaan ulang kemungkinan tidak mahal dan akan mengurangi konsumsi sumber daya klien. Batas waktu juga dapat melepaskan sumber daya server, tergantung sifat gangguan tersebut.
+ Permintaan yang membutuhkan waktu penyelesaian yang lama karena permintaan atau respons gagal dikirimkan oleh jaringan dapat diberikan batas waktu dan dicoba ulang. Karena permintaan atau respons tidak dikirimkan, kegagalan akan terjadi, terlepas dari lamanya batas waktu. Memberikan batas waktu pada kasus ini tidak akan melepaskan sumber daya server, tetapi akan melepaskan sumber daya klien dan meningkatkan kinerja beban kerja.
Manfaatkan pola desain yang mapan seperti percobaan ulang dan pemutus sirkuit untuk menangani batas waktu dengan lancar dan mendukung pendekatan gagal cepat. [SDK AWS](https://docs.aws.amazon.com/index.html#sdks) dan [AWS CLI](https://aws.amazon.com/cli/) memungkinkan konfigurasi batas waktu koneksi dan permintaan serta percobaan ulang dengan mundur eksponensial dan jitter. [Fungsi AWS Lambda](https://aws.amazon.com/lambda/) mendukung konfigurasi batas waktu, dan dengan [AWS Step Functions](https://aws.amazon.com/step-functions/), Anda dapat membangun pemutus sirkuit rendah kode yang memanfaatkan integrasi siap pakai dengan layanan dan SDK AWS. [AWS App Mesh](https://aws.amazon.com/app-mesh/) Envoy memberikan kemampuan batas waktu dan pemutus sirkuit.
## Langkah implementasi
+ Konfigurasikan batas waktu pada panggilan layanan jarak jauh dan manfaatkan fitur batas waktu bahasa bawaan atau pustaka batas waktu sumber terbuka.
+ Saat beban kerja Anda melakukan panggilan dengan SDK AWS, tinjau dokumentasi untuk konfigurasi batas waktu untuk bahasa khusus.
+ [ Python ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html)
+ [ PHP ](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.DefaultsMode.Configuration.html)
+ [ .NET ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [ Ruby ](https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/timeout-duration.html)
+ [ Java ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [ Go ](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/retries-timeouts/#timeouts)
+ [ Node.js ](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Config.html)
+ [ C\$1\$1 ](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/client-config.html)
+ Saat menggunakan SDK AWS atau perintah AWS CLI dalam beban kerja Anda, konfigurasikan nilai batas waktu default dengan mengatur konfigurasi AWS [default](https://docs.aws.amazon.com/sdkref/latest/guide/feature-smart-config-defaults.html) untuk `connectTimeoutInMillis` dan `tlsNegotiationTimeoutInMillis`.
+ Terapkan [opsi baris perintah](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html) `cli-connect-timeout` dan `cli-read-timeout` untuk mengontrol perintah AWS CLI satu kali ke layanan AWS.
+ Pantau panggilan layanan jarak jauh untuk batas waktu, dan atur alarm pada kesalahan persisten sehingga Anda dapat menangani skenario kesalahan secara proaktif.
+ Implementasikan [Metrik CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) dan [deteksi anomali CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) pada angka kesalahan panggilan, target latensi di tingkat layanan, dan outlier latensi untuk memberikan wawasan tentang pengelolaan batas waktu yang terlalu agresif atau permisif.
+ Konfigurasikan batas waktu pada [fungsi Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-timeout-console).
+ Klien API Gateway harus mengimplementasikan percobaan ulang mereka sendiri saat menangani batas waktu. API Gateway mendukung [batas waktu integrasi 50 milidetik hingga 29 detik](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#api-gateway-execution-service-limits-table) untuk integrasi hilir dan tidak mencoba ulang saat integrasi meminta batas waktu.
+ Implementasikan pola [pemutus sirkuit](https://martinfowler.com/bliki/CircuitBreaker.html) untuk menghindari pembuatan panggilan jarak jauh ketika waktu habis. Buka sirkuit untuk menghindari kegagalan panggilan dan tutup sirkuit saat panggilan merespons secara normal.
+ Untuk beban kerja berbasis kontainer, pelajari fitur [App Mesh Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html) untuk memanfaatkan batas waktu dan pemutus sirkuit bawaan.
+ Gunakan AWS Step Functions untuk membuat pemutus sirkuit rendah kode untuk panggilan layanan jarak jauh, terutama saat memanggil SDK native AWS dan integrasi Step Functions yang didukung untuk menyederhanakan beban kerja Anda.
## Sumber daya
**Praktik terbaik terkait:**
+ [REL05-BP03 Mengontrol dan membatasi panggilan percobaan ulang](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Melakukan gagal cepat (fail fast) dan membatasi antrean](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL06-BP07 Memantau pelacakan permintaan menyeluruh melalui sistem Anda](rel_monitor_aws_resources_end_to_end.md)
**Dokumen terkait:**
+ [SDK AWS: Percobaan Ulang dan Batas Waktu](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon Builders' Library: Batas waktu, percobaan ulang, dan mundur (backoff) dengan jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [ Kuota Amazon API Gateway dan catatan penting ](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html)
+ [AWS Command Line Interface: Opsi baris perintah ](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html)
+ [AWS SDK for Java 2.x: Mengonfigurasi Batas Waktu API ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [AWS Botocore menggunakan objek konfigurasi dan Config Reference ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#using-the-config-object)
+ [AWS SDK untuk .NET: Percobaan Ulang dan Batas Waktu ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [AWS Lambda: Mengonfigurasi opsi fungsi Lambda ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html)
**Contoh terkait:**
+ [ Menggunakan pola pemutus sirkuit dengan AWS Step Functions dan Amazon DynamoDB ](https://aws.amazon.com/blogs/compute/using-the-circuit-breaker-pattern-with-aws-step-functions-and-amazon-dynamodb/)
+ [ Martin Fowler: CircuitBreaker ](https://martinfowler.com/bliki/CircuitBreaker.html?ref=wellarchitected)
**Alat terkait:**
+ [ SDK AWS](https://docs.aws.amazon.com/index.html#sdks)
+ [ Fungsi AWS Lambda](https://aws.amazon.com/lambda/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/)
+ [AWS Command Line Interface](https://aws.amazon.com/cli/)
# REL05-BP06 Menjadikan layanan stateless jika memungkinkan
Layanan seharusnya tidak memerlukan state, atau seharusnya mengalihkan state sedemikian rupa sehingga di antara permintaan klien yang berbeda, tidak ada dependensi di penyimpanan data lokal di disk dan memori. Ini memungkinkan server diganti sesuka hati tanpa menyebabkan dampak ketersediaan. Amazon ElastiCache atau Amazon DynamoDB merupakan tujuan yang baik untuk state yang dialihkan.
![\[Pada aplikasi web stateless ini, state sesi dialihkan ke Amazon ElastiCache.\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/stateless-webapp.png)
Ketika pengguna atau layanan berinteraksi dengan aplikasi, mereka sering melakukan serangkaian interaksi yang membentuk sesi. Sesi adalah data unik bagi pengguna yang lama berada di antara permintaan ketika mereka menggunakan aplikasi. Aplikasi stateless adalah aplikasi yang tidak memerlukan pengetahuan tentang interaksi sebelumnya dan tidak menyimpan informasi sesi.
Setelah dirancang menjadi stateless, Anda dapat menggunakan layanan komputasi nirserver, seperti AWS Lambda atau AWS Fargate.
Selain penggantian server, manfaat lain aplikasi stateless adalah kemampuannya untuk menyesuaikan skala secara horizontal karena sumber daya komputasi yang tersedia (seperti instans EC2 dan fungsi AWS Lambda) dapat melayani permintaan apa pun.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
+ Menjadikan aplikasi Anda stateless. Aplikasi stateless memungkinkan penskalaan horizontal dan toleran terhadap kegagalan simpul individual.
+ Hapus state yang sebenarnya dapat disimpan di parameter permintaan.
+ Setelah memeriksa apakah state diperlukan, pindahkan pelacakan state apa pun ke cache multi-zona yang tangguh atau penyimpanan data seperti Amazon ElastiCache, Amazon RDS, Amazon DynamoDB atau solusi data terdistribusi pihak ketiga. Simpan state yang tidak dapat dipindah ke penyimpanan data tangguh.
+ Beberapa data (seperti cookie) dapat diteruskan di header atau parameter kueri.
+ Lakukan pemfaktoran ulang untuk menghapus state yang dapat dengan cepat diteruskan di permintaan.
+ Beberapa data mungkin tidak terlalu diperlukan per permintaan dan dapat diambil sesuai permintaan.
+ Hapus data yang dapat diambil secara asinkron.
+ Tentukan penyimpanan data yang memenuhi kebutuhan state yang diperlukan.
+ Pertimbangkan basis data NoSQL untuk data non-rasional.
## Sumber daya
**Dokumen terkait:**
+ [Amazon Builders' Library: Menghindari fallback dalam sistem terdistribusi](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: Menghindari backlog antrean yang tidak dapat diatasi](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: Tantangan dan strategi caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 Mengimplementasikan tuas darurat
Tuas darurat adalah proses cepat yang dapat memitigasi dampak ketersediaan pada beban kerja.
Tuas darurat bekerja dengan cara menonaktifkan, melakukan throttling, atau mengubah perilaku komponen atau dependensi menggunakan mekanisme yang diketahui dan diuji. Hal ini dapat mengurangi gangguan beban kerja yang disebabkan oleh kelelahan sumber daya karena permintaan yang meningkat secara tidak terduga dan mengurangi dampak kegagalan pada komponen non-kritis dalam beban kerja Anda.
**Hasil yang diinginkan:** Dengan mengimplementasikan tuas darurat, Anda dapat membuat proses yang telah diketahui dengan baik untuk menjaga ketersediaan komponen kritis dalam beban kerja Anda. Beban kerja akan mengalami degradasi perlahan (graceful degradation) dan terus menjalankan fungsi-fungsi kritis bisnisnya selama aktivasi tuas darurat. Untuk detail lebih lanjut tentang degradasi perlahan, lihat [REL05-BP01 Mengimplementasikan degradasi perlahan untuk mengubah dependensi keras yang berlaku menjadi dependensi lunak](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html).
**Antipola umum:**
+ Kegagalan dependensi non-kritis berdampak pada ketersediaan beban kerja inti Anda.
+ Tidak menguji atau memverifikasi perilaku komponen kritis selama gangguan komponen non-kritis.
+ Tidak ada kriteria yang jelas dan deterministik yang ditentukan untuk pengaktifan atau penonaktifan tuas darurat.
**Manfaat menetapkan praktik terbaik ini:** Mengimplementasikan tuas darurat dapat meningkatkan ketersediaan komponen kritis dalam beban kerja Anda dengan menyediakan proses yang telah ditetapkan kepada penyedia resolusi untuk merespons lonjakan permintaan yang tidak terduga atau kegagalan dependensi non-kritis.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
+ Identifikasi komponen kritis dalam beban kerja Anda.
+ Buat agar rancangan dan arsitek komponen kritis dalam beban kerja Anda dapat menahan kegagalan komponen non-kritis.
+ Lakukan pengujian untuk memvalidasi perilaku komponen kritis Anda selama kegagalan komponen non-kritis.
+ Tentukan dan pantau metrik atau pemicu yang relevan untuk memulai prosedur tuas darurat.
+ Tentukan prosedur (manual atau otomatis) yang mencakup tuas darurat.
### Langkah implementasi
+ Identifikasi komponen kritis bagi bisnis dalam beban kerja Anda.
+ Setiap komponen teknis dalam beban kerja Anda harus dipetakan ke fungsi bisnisnya yang relevan dan diberi peringkat sebagai kritis atau non-kritis. Contoh-contoh fungsionalitas kritis dan non-kritis di Amazon dapat dilihat di [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering).
+ Ini adalah keputusan teknis sekaligus bisnis, dan bervariasi berdasarkan organisasi dan beban kerja.
+ Buat agar rancangan dan arsitek komponen kritis dalam beban kerja Anda dapat menahan kegagalan komponen non-kritis.
+ Selama analisis dependensi, pertimbangkan semua mode kegagalan yang dapat terjadi, dan verifikasikan bahwa mekanisme tuas darurat Anda memberikan fungsionalitas kritis pada komponen hilir.
+ Lakukan pengujian untuk memvalidasi perilaku komponen kritis Anda saat tuas darurat Anda diaktifkan.
+ Hindari perilaku bimodal. Untuk detail lebih lanjut, lihat [REL11-BP05 Menggunakan stabilitas statis untuk mencegah perilaku bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html).
+ Tentukan, pantau, dan munculkan peringatan pada metrik yang relevan untuk memulai prosedur tuas darurat.
+ Beban kerja Anda menentukan metrik yang tepat untuk dipantau. Beberapa contoh metrik adalah latensi atau jumlah permintaan yang gagal ke sebuah dependensi.
+ Tentukan prosedur, manual atau otomatis, yang mencakup tuas darurat.
+ Prosedur bisa meliputi mekanisme seperti [pelepasan beban](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/), [permintaan throttling](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html), atau implementasi [degradasi perlahan](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html).
## Sumber daya
**Praktik Terbaik Terkait:**
+ [REL05-BP01 Mengimplementasikan degradasi yang tepat (graceful degradation) untuk mengubah dependensi keras yang berlaku menjadi dependensi lunak](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html)
+ [REL05-BP02 Membatasi (throttling) permintaan](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)
+ [REL11-BP05 Menggunakan stabilitas statis untuk mencegah perilaku bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
**Dokumen terkait:**
+ [Mengotomatiskan deployment aman tanpa campur tangan](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering)
**Video terkait:**
+ [AWS re:Invent 2020: Reliability, consistency, and confidence through immutability](https://www.youtube.com/watch?v=jUSYnRztttY)
# Manajemen perubahan
**Topics**
+ [REL 6. Bagaimana cara memantau sumber daya beban kerja Anda?](rel-06.md)
+ [REL 7. Bagaimana cara mendesain beban kerja Anda untuk beradaptasi dengan perubahan dalam permintaan?](rel-07.md)
+ [REL 8. Bagaimana cara mengimplementasikan perubahan?](rel-08.md)
# REL 6. Bagaimana cara memantau sumber daya beban kerja Anda?
Log dan metrik merupakan alat yang luar biasa untuk mendapatkan wawasan tentang kondisi beban kerja Anda. Anda dapat mengonfigurasikan beban kerja Anda untuk memantau log dan metrik serta mengirimkan notifikasi ketika ambang batas terlampaui atau peristiwa signifikan terjadi. Pemantauan memungkinkan beban kerja Anda mengenali ketika ambang batas kinerja rendah terlampaui atau kegagalan terjadi, sehingga pemulihan dapat terjadi secara otomatis untuk menanggapinya.
**Topics**
+ [REL06-BP01 Memantau semua komponen untuk beban kerja (Pembuatan)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 Menetapkan dan menghitung metrik (Agregasi)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 Mengirimkan notifikasi (Pemrosesan dan pembuatan alarm waktu nyata)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL06-BP04 Mengotomatiskan respons (Peringatan dan pemrosesan waktu nyata)](rel_monitor_aws_resources_automate_response_monitor.md)
+ [REL06-BP05 Analitik](rel_monitor_aws_resources_storage_analytics.md)
+ [REL06-BP06 Lakukan peninjauan secara teratur](rel_monitor_aws_resources_review_monitoring.md)
+ [REL06-BP07 Memantau pelacakan permintaan menyeluruh melalui sistem Anda](rel_monitor_aws_resources_end_to_end.md)
# REL06-BP01 Memantau semua komponen untuk beban kerja (Pembuatan)
Pantau komponen beban kerja dengan Amazon CloudWatch atau alat pihak ketiga. Pantau layanan AWS dengan Dasbor AWS Health.
Semua komponen beban kerja Anda harus dipantau, mencakup front-end, logika bisnis, dan tingkat penyimpanan. Tetapkan metrik utama, jelaskan cara mengekstraknya dari log (jika diperlukan), dan tetapkan ambang batas untuk memicu peristiwa alarm yang sesuai. Pastikan metrik relevan dengan indikator kinerja utama (KPI) beban kerja Anda, dan gunakan metrik dan log untuk mengidentifikasi tanda-tanda peringatan dini penurunan layanan. Contohnya, metrik yang terkait dengan hasil bisnis seperti jumlah pesanan yang berhasil diproses per menit, dapat menunjukkan masalah beban kerja lebih cepat dari metrik teknis, seperti Pemanfaatan CPU. Gunakan Dasbor AWS Health untuk tampilan yang dipersonalisasi tentang kinerja dan ketersediaan layanan AWS yang mendasari sumber daya AWS Anda.
Pemantauan di cloud menawarkan peluang baru. Sebagian besar penyedia cloud telah mengembangkan hook yang dapat disesuaikan dan dapat menghadirkan wawasan untuk membantu Anda memantau beberapa lapisan beban kerja Anda. Layanan AWS seperti Amazon CloudWatch menerapkan algoritme statis dan machine learning untuk terus menganalisis metrik sistem dan aplikasi, menentukan garis dasar normal dan anomali permukaan dengan sedikit campur tangan pengguna. Algoritme deteksi anomali memperhitungkan perubahan musiman dan tren metrik.
AWS menyediakan banyak informasi pemantauan dan log untuk digunakan untuk menentukan metrik khusus beban kerja, proses perubahan permintaan, dan mengadopsi teknik machine learning, terlepas dari keahlian ML.
Selain itu, pantau semua titik akhir eksternal Anda untuk memastikan independensinya dari implementasi dasar Anda. Pemantauan aktif ini dapat dilakukan dengan transaksi sintetis (kadang disebut sebagai *canary pengguna*, tetapi bedakan dengan deployment canary) yang secara berkala menjalankan sejumlah tugas umum yang sesuai dengan tindakan yang dilakukan oleh klien beban kerja. Buat tugas-tugas ini berdurasi singkat dan pastikan untuk tidak membebani beban kerja Anda saat pengujian. Amazon CloudWatch Synthetics memungkinkan Anda untuk [membuat canary sintesis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) untuk memantau titik akhir dan API Anda. Anda juga dapat menggabungkan simpul klien canary sintetis dengan konsol AWS X-Ray untuk mengidentifikasi canary sintetis mana yang mengalami masalah berupa error, fault, atau tingkat throttling untuk jangka waktu yang dipilih.
**Hasil yang Diharapkan:**
Kumpulkan dan gunakan metrik kritis dari semua komponen beban kerja untuk memastikan keandalan beban kerja dan pengalaman pengguna yang optimal. Dengan mendeteksi bahwa beban kerja tidak mencapai hasil bisnis, Anda dapat dengan cepat mengumumkan bencana dan pulih dari insiden.
**Antipola umum:**
+ Hanya memantau antarmuka eksternal beban kerja Anda.
+ Tidak menghasilkan metrik khusus beban kerja dan hanya bergantung pada metrik yang diberikan kepada Anda oleh layanan AWS yang digunakan oleh beban kerja Anda.
+ Hanya menggunakan metrik teknis di beban kerja Anda dan tidak memantau metrik apa pun yang terkait dengan KPI non-teknis yang menerima kontribusi dari beban kerja Anda.
+ Mengandalkan lalu lintas produksi dan pemeriksaan kondisi sederhana untuk memantau dan mengevaluasi state beban kerja.
**Manfaat menjalankan praktik terbaik ini:** Dengan memantau semua tingkatan di beban kerja Anda, Anda dapat lebih cepat mengantisipasi dan menyelesaikan masalah di komponen dalam beban kerja.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
1. **Mengaktifkan pencatatan log jika tersedia.** Data pemantauan harus diperoleh dari semua komponen beban kerja. Aktifkan pencatatan log tambahan, seperti S3 Access Logs, dan aktifkan beban kerja Anda untuk mencatat log data spesifik beban kerja. Kumpulkan metrik rata-rata CPU, I/O jaringan, dan I/O disk dari layanan seperti Amazon ECS, Amazon EKS, Amazon EC2, Elastic Load Balancing, AWS Auto Scaling, dan Amazon EMR. Lihat [Layanan AWS yang Memublikasikan Metrik CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) untuk daftar layanan AWS yang memublikasikan metrik ke CloudWatch.
1. **Tinjau semua metrik default dan telusuri celah pengumpulan data apa pun.** Setiap layanan menghasilkan metrik default. Dengan mengumpulkan metrik default, Anda dapat lebih memahami dependensi antar komponen beban kerja dan bagaimana keandalan dan kinerja komponen memengaruhi beban kerja. Anda juga dapat membuat dan [memublikasikan metrik Anda sendiri](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) ke CloudWatch menggunakan AWS CLI atau API. Ini
1. **Evaluasi semua metrik untuk menentukan mana yang harus dibuatkan peringatan untuk setiap layanan AWS di beban kerja Anda.** Anda dapat memilih subset metrik yang memiliki dampak besar dalam keandalan beban kerja. Berfokus pada metrik dan ambang batas memungkinkan Anda untuk menyempurnakan jumlah [pemberitahuan](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) dan dapat membantu meminimalkan positif palsu.
1. **Tetapkan peringatan dan proses pemulihan beban kerja Anda setelah peringatan dipicu.** Dengan menetapkan peringatan, Anda dapat dengan cepat memberi tahu, mengeskalasi, dan mengikuti langkah-langkah yang diperlukan untuk pemulihan dari insiden dan memenuhi Sasaran Waktu Pemulihan (RTO) yang Anda tentukan. Anda dapat menggunakan [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) untuk memanggil alur kerja otomatis dan memulai prosedur pemulihan berdasarkan ambang batas yang ditentukan.
1. **Jelajahi penggunaan transaksi sintetis untuk mengumpulkan data yang relevan tentang state beban kerja.** Pemantauan sintetis mengikuti rute yang sama dan menjalankan tindakan yang sama seperti pelanggan, sehingga memungkinkan Anda untuk terus memverifikasi pengalaman pelanggan Anda bahkan saat Anda tidak memiliki lalu lintas pelanggan apa pun pada beban kerja Anda. Dengan menggunakan [transaksi sintetis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html), Anda dapat menemukan masalah sebelum pelanggan Anda menemukannya.
## Sumber daya
**Praktik Terbaik Terkait:**
+ [REL11-BP03 Mengotomatisasi pemulihan di semua lapisan](rel_withstand_component_failures_auto_healing_system.md)
**Dokumen terkait:**
+ [Memulai Dasbor AWS Health Anda – Kondisi akun Anda](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)
+ [Layanan AWS yang Memublikasikan Metrik CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Mengakses Log untuk Penyeimbang Beban Jaringan Anda](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html)
+ [Akes log untuk penyeimbang beban aplikasi Anda](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)
+ [Mengakses Amazon CloudWatch Logs untuk AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html)
+ [Pencatatan Log Akses Server S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)
+ [Mengaktifkan Log Akses untuk Penyeimbang Beban Klasik Anda](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html)
+ [Mengekspor data log ke Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Menginstal agen CloudWatch di instans Amazon EC2](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)
+ [Memublikasikan Metrik Kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Menggunakan Dasbor Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Menggunakan Metrik Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Menggunakan Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Apa itu Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
**Panduan pengguna:**
+ [Membuat trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)
+ [Memantau metrik memori dan disk untuk instans Linux Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)
+ [Menggunakan CloudWatch Logs dengan instans kontainer](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [VPC Flow Logs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html)
+ [Apa itu Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [Apa itu AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**Blog terkait:**
+ [Melakukan debug dengan Amazon CloudWatch Synthetics dan AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
**Contoh dan lokakarya terkait:**
+ [AWS Well-Architected Labs: Keunggulan Operasional - Pemantauan Dependensi](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/)
+ [Amazon Builders' Library: Instrumentasi sistem terdistribusi untuk visibilitas operasional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Lokakarya observabilitas](https://catalog.workshops.aws/observability/en-US)
# REL06-BP02 Menetapkan dan menghitung metrik (Agregasi)
Simpan data log dan terapkan filter saat diperlukan untuk menghitung metrik, seperti jumlah log peristiwa tertentu, atau latensi yang dihitung dari stempel waktu log peristiwa.
Amazon CloudWatch dan Amazon S3 berfungsi sebagai lapisan agregasi dan penyimpanan utama. Untuk beberapa layanan, seperti AWS Auto Scaling dan Elastic Load Balancing, metrik default disediakan secara default untuk beban CPU atau latensi permintaan rata-rata di seluruh klaster atau instans. Untuk layanan streaming, seperti VPC Flow Logs dan AWS CloudTrail, data peristiwa diteruskan ke CloudWatch Logs dan Anda perlu menetapkan dan menerapkan filter metrik untuk mengekstrak metrik dari data peristiwa. Ini memberi Anda data rangkaian waktu, yang dapat berfungsi sebagai input ke alarm CloudWatch yang Anda tetapkan untuk memicu peringatan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Tetapkan dan hitung metrik (Agregasi). Simpan data log dan terapkan filter saat diperlukan untuk menghitung metrik, seperti jumlah log peristiwa tertentu, atau latensi yang dihitung dari stempel waktu log peristiwa.
+ Filter metrik menetapkan ketentuan dan pola yang harus dicari di data log saat dikirim ke CloudWatch Logs. CloudWatch Logs menggunakan filter metrik untuk mengubah data log menjadi metrik CloudWatch numerik yang dapat Anda buatkan grafik atau aktifkan alarm.
+ [Mencari dan Menyaring Data Log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ Gunakan pihak ketiga tepercaya untuk mengagregasi log.
+ Ikuti instruksi pihak ketiga. Sebagian besar produk pihak ketiga terintegrasi dengan CloudWatch dan Amazon S3.
+ Beberapa layanan AWS dapat memublikasikan log langsung ke Amazon S3. Jika kebutuhan utama Anda untuk log adalah penyimpanan di Amazon S3, Anda dapat dengan mudah meminta layanan yang memproduksi log untuk mengirimnya langsung ke Amazon S3 tanpa mengatur infrastruktur tambahan.
+ [Mengirim Log Langsung ke Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
## Sumber daya
**Dokumen terkait:**
+ [Contoh Kueri Amazon CloudWatch Logs Insight](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Melakukan debug dengan Amazon CloudWatch Synthetics dan AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [Mencari dan Menyaring Data Log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Mengirim Log Langsung ke Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
+ [Amazon Builders' Library: Menginstrumentasi sistem terdistribusi untuk visibilitas operasional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP03 Mengirimkan notifikasi (Pemrosesan dan pembuatan alarm waktu nyata)
Ketika organisasi mendeteksi potensi masalah, mereka mengirimkan notifikasi dan peringatan waktu nyata kepada personel dan sistem yang sesuai untuk merespons masalah ini dengan cepat dan efektif.
**Hasil yang diinginkan:** Respons cepat terhadap event operasional dapat terjadi melalui konfigurasi alarm yang relevan berdasarkan metrik layanan dan aplikasi. Ketika ambang batas alarm dilanggar, personel dan sistem yang sesuai diberitahu sehingga mereka dapat mengatasi masalah mendasar.
**Antipola umum:**
+ Mengonfigurasi alarm dengan ambang batas yang terlalu tinggi, sehingga mengakibatkan kegagalan untuk mengirim notifikasi penting.
+ Mengonfigurasi alarm dengan ambang batas yang terlalu rendah, yang menyebabkan tidak adanya tindakan atas pemberitahuan penting karena kebisingan notifikasi yang berlebihan.
+ Tidak memperbarui alarm dan ambang batasnya saat penggunaan berubah.
+ Untuk alarm yang paling sesuai untuk ditangani melalui tindakan otomatis, mengirim notifikasi ke personel alih-alih menghasilkan tindakan otomatis, menyebabkan terkirimnya notifikasi yang berlebihan.
**Manfaat menjalankan praktik terbaik ini:** Mengirimkan notifikasi dan pemberitahuan waktu nyata kepada personel dan sistem yang sesuai memungkinkan deteksi dini masalah dan respons cepat terhadap insiden operasional.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Beban kerja harus dilengkapi dengan pemrosesan dan pembuatan alarm waktu nyata untuk meningkatkan pendeteksian masalah yang dapat memengaruhi ketersediaan aplikasi dan berfungsi sebagai pemicu respons otomatis. Organisasi dapat melakukan pemrosesan dan pembuatan alarm waktu nyata dengan menciptakan peringatan dengan metrik yang ditentukan untuk menerima notifikasi setiap kali peristiwa signifikan terjadi atau sebuah metrik melebihi ambang batas.
[Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) memungkinkan Anda untuk membuat [metrik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) dan alarm komposit menggunakan alarm CloudWatch berdasarkan ambang batas statis, deteksi anomali, dan kriteria lainnya. Untuk detail selengkapnya tentang jenis alarm yang dapat Anda konfigurasikan menggunakan CloudWatch, lihat [bagian alarm dalam dokumentasi CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
Anda dapat membuat tampilan metrik dan pemberitahuan yang disesuaikan dari sumber daya AWS Anda untuk tim Anda menggunakan [dasbor CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). Halaman beranda yang dapat disesuaikan di konsol CloudWatch memungkinkan Anda memantau sumber daya dalam satu tampilan di beberapa Region.
Alarm dapat melakukan satu atau beberapa tindakan, seperti mengirimkan notifikasi ke [topik Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html), melakukan tindakan [Amazon EC2](https://aws.amazon.com/ec2/) atau tindakan [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) , atau [membuat OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) atau [insiden](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) di AWS Systems Manager.
Amazon CloudWatch menggunakan [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) untuk mengirimkan notifikasi ketika alarm berubah status, sehingga memberikan pengiriman pesan dari penerbit (produsen) ke pelanggan (konsumen). Untuk detail selengkapnya tentang pengaturan notifikasi Amazon SNS, lihat [Mengonfigurasi Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html).
CloudWatch mengirim event [EventBridge](https://aws.amazon.com/eventrbridge/) [setiap kali](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html) alarm CloudWatch dibuat, diperbarui, dihapus, atau statusnya berubah. Anda dapat menggunakan EventBridge dengan event ini untuk membuat aturan yang melakukan tindakan, seperti memberi tahu Anda setiap kali status alarm berubah atau secara otomatis memicu event di akun Anda menggunakan [Otomatisasi Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html).
** Kapan Anda harus menggunakan EventBridge atau Amazon SNS? **
Baik EventBridge maupun Amazon SNS dapat digunakan untuk mengembangkan aplikasi berbasis event, dan pilihan Anda akan tergantung pada kebutuhan spesifik Anda.
Amazon EventBridge direkomendasikan ketika Anda ingin membangun aplikasi yang bereaksi terhadap event dari aplikasi Anda sendiri, aplikasi SaaS, dan layanan AWS. EventBridge adalah satu-satunya layanan berbasis event yang terintegrasi langsung dengan partner SaaS pihak ketiga. EventBridge juga secara otomatis menyerap peristiwa dari lebih dari 200 layanan AWS tanpa mengharuskan developer untuk membuat sumber daya apa pun di akun mereka.
EventBridge menggunakan struktur berbasis JSON yang ditentukan untuk event, dan membantu Anda membuat aturan yang diterapkan di seluruh badan event untuk memilih event untuk diteruskan ke [target](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html). EventBridge saat ini mendukung lebih dari 20 layanan AWS sebagai target, termasuk [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html), [Amazon SQS](https://aws.amazon.com/sqs/), Amazon SNS, [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/), dan [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/).
Amazon SNS direkomendasikan untuk aplikasi yang membutuhkan fan out tinggi (ribuan atau jutaan titik akhir). Pola umum yang kita lihat adalah bahwa pelanggan menggunakan Amazon SNS sebagai target aturan mereka untuk memfilter event yang mereka butuhkan dan fan out ke beberapa titik akhir.
Pesan memiliki sifat yang tidak terstruktur dan bisa dalam format apa pun. Amazon SNS mendukung penerusan pesan ke enam jenis target yang berbeda, termasuk Lambda, Amazon SQS, titik akhir HTTP/S, SMS, push seluler, dan email. Amazon SNS [latensi tipikal di bawah 30 milidetik](https://aws.amazon.com/sns/faqs/). Berbagai layanan AWS mengirimkan pesan Amazon SNS dengan mengonfigurasi layanan untuk melakukannya (lebih dari 30, termasuk Amazon EC2, [Amazon S3](https://aws.amazon.com/s3/), dan [Amazon RDS](https://aws.amazon.com/rds/)).
### Langkah implementasi
1. Buat alarm menggunakan [alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
1. Alarm metrik memonitor metrik CloudWatch tunggal atau ekspresi yang bergantung pada metrik CloudWatch. Alarm memulai satu atau beberapa tindakan berdasarkan nilai metrik atau ekspresi dibandingkan dengan ambang batas selama interval waktu tertentu. Tindakan tersebut dapat terdiri dari pengiriman notifikasi ke [topik Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html), melakukan tindakan [Amazon EC2](https://aws.amazon.com/ec2/) atau tindakan [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) , atau [membuat OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) atau [acara](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) di AWS Systems Manager.
1. Alarm komposit terdiri dari ekspresi aturan yang mempertimbangkan kondisi alarm dari alarm-alarm lain yang telah Anda buat. Alarm komposit hanya memasuki status alarm jika semua kondisi aturan terpenuhi. Alarm yang ditentukan dalam ekspresi aturan suatu alarm komposit dapat mencakup alarm metrik dan alarm komposit tambahan. Alarm komposit dapat mengirim notifikasi Amazon SNS ketika statusnya berubah dan dapat membuat Systems Manager [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) atau [insiden](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) ketika memasuki keadaan alarm, tetapi tidak dapat melakukan tindakan Amazon EC2 atau Auto Scaling.
1. Siapkan [notifikasi Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html). Saat membuat alarm CloudWatch, Anda dapat menyertakan sebuah topik Amazon SNS untuk mengirimkan notifikasi saat status alarm berubah.
1. [Buat aturan di EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) yang cocok dengan alarm CloudWatch yang ditentukan. Setiap aturan mendukung beberapa target, termasuk fungsi Lambda. Misalnya, Anda dapat menentukan alarm yang dimulai saat ruang disk yang tersedia hampir habis, yang memicu sebuah fungsi Lambda melalui aturan EventBridge, untuk mengosongkan ruang. Untuk detail selengkapnya tentang target EventBridge, lihat [Target EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html).
## Sumber daya
**Praktik terbaik Well-Architected terkait:**
+ [REL06-BP01 Memantau semua komponen untuk beban kerja (Pembuatan)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 Menetapkan dan menghitung metrik (Agregasi)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL12-BP01 Menggunakan buku pedoman untuk menyelidiki kegagalan](rel_testing_resiliency_playbook_resiliency.md)
**Dokumen terkait:**
+ [ Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [ Wawasan CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [Menggunakan alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Menggunakan dasbor Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Menggunakan metrik Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [ Menyiapkan notifikasi Amazon SNS ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
+ [ deteksi anomali CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [ Perlindungan data CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/protect-sensitive-log-data-types.html)
+ [ Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [ Amazon Simple Notification Service ](https://aws.amazon.com/sns/)
**Video terkait:**
+ [ video observabilitas reinvent 2022 ](https://www.youtube.com/results?search_query=reinvent+2022+observability)
+ [AWS re:Invent 2022 - Praktik terbaik observabilitas di Amazon ](https://www.youtube.com/watch?v=zZPzXEBW4P8)
**Contoh terkait:**
+ [Lokakarya One Observability](https://observability.workshop.aws/)
+ [ Amazon EventBridge ke AWS Lambda dengan kontrol umpan balik oleh Alarm Amazon CloudWatch ](https://serverlessland.com/patterns/cdk-closed-loop-serverless-control-pattern)
# REL06-BP04 Mengotomatiskan respons (Peringatan dan pemrosesan waktu nyata)
Gunakan otomatisasi untuk melakukan tindakan ketika peristiwa terdeteksi, misalnya, mengganti komponen yang rusak.
Pemrosesan alarm waktu nyata secara otomatis diimplementasikan agar sistem dapat mengambil tindakan korektif yang cepat dan berupaya mencegah kegagalan atau penurunan layanan ketika alarm terpicu. Respons otomatis terhadap alarm dapat mencakup penggantian komponen yang gagal, penyesuaian kapasitas komputasi, pengalihan lalu lintas ke host yang sehat, zona ketersediaan, atau wilayah lain, dan pemberitahuan operator.
**Hasil yang diinginkan:** Alarm waktu nyata diidentifikasi, dan pemrosesan alarm secara otomatis diatur untuk menginvokasi tindakan yang tepat yang diambil untuk mempertahankan tujuan tingkat layanan dan perjanjian tingkat layanan (SLA). Otomatisasi dapat berupa berbagai hal, dari aktivitas pemulihan diri sebuah komponen hingga failover seluruh situs.
**Antipola umum:**
+ Tidak memiliki inventaris atau katalog alarm waktu nyata utama yang jelas.
+ Tidak ada respons otomatis terhadap alarm kritis (misalnya, penskalaan otomatis berjalan ketika komputasi hampir habis).
+ Tindakan respons alarm yang kontradiktif.
+ Tidak ada prosedur operasi standar (SOP) untuk diikuti operator ketika mereka menerima pemberitahuan peringatan.
+ Tidak memantau perubahan konfigurasi, padahal perubahan konfigurasi yang tidak terdeteksi dapat menyebabkan waktu henti untuk beban kerja.
+ Tidak memiliki strategi untuk membatalkan perubahan konfigurasi yang tidak diinginkan.
**Manfaat menetapkan praktik terbaik ini:** Mengotomatiskan pemrosesan alarm dapat meningkatkan ketahanan sistem. Sistem mengambil tindakan korektif secara otomatis, sehingga mengurangi aktivitas manual yang memberi peluang adanya intervensi manusia yang rawan kesalahan. Operasi beban kerja memenuhi tujuan ketersediaan, dan mengurangi gangguan layanan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Untuk mengelola peringatan secara efektif dan mengotomatiskan responsnya, kategorikan peringatan berdasarkan tingkat kekritisan dan dampaknya, dokumentasikan prosedur respons, dan rencanakan respons sebelum menentukan peringkat tugas.
Identifikasi tugas yang membutuhkan tindakan tertentu (sering kali diperinci dalam runbook), dan periksa semua runbook dan playbook untuk menentukan tugas mana yang dapat diotomatisasi. Jika tindakan dapat digambarkan dengan jelas, tindakan tersebut sering kali dapat diotomatisasi. Jika tindakan tidak dapat diotomatisasi, dokumentasikan langkah-langkah manual dalam SOP dan latih operator untuk melakukannya. Terus cari peluang otomatisasi pada proses manual agar Anda dapat membuat dan menerapkan rencana untuk mengotomatiskan respons peringatan.
### Langkah implementasi
1. **Buat inventaris alarm:** Untuk mendapatkan daftar semua alarm, Anda dapat memanfaatkan [AWS CLI](https://aws.amazon.com/cli/) menggunakan perintah [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)`[describe-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html)`. Bergantung pada berapa banyak alarm yang telah Anda siapkan, Anda mungkin harus menggunakan paginasi untuk mengambil subset alarm untuk setiap panggilan, atau menggunakan SDK AWS untuk mendapatkan alarm [menggunakan panggilan API](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-describing-alarms.html).
1. **Dokumentasikan semua tindakan alarm:** Perbarui runbook dengan semua alarm dan tindakannya, baik itu manual maupun otomatis. [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/APIReference/Welcome.html) menyediakan runbook yang sudah ditetapkan sebelumnya. Untuk informasi selengkapnya tentang runbook, lihat [Working with runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html). Untuk detail tentang cara melihat konten runbook, lihat [View runbook content](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html#view-automation-json).
1. **Menyiapkan dan mengelola tindakan alarm:** Untuk alarm apa pun yang memerlukan tindakan, tentukan [tindakan otomatis menggunakan SDK CloudWatch](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html). Misalnya, Anda dapat mengubah status instans Amazon EC2 secara otomatis berdasarkan alarm CloudWatch dengan membuat dan mengaktifkan tindakan pada alarm atau menonaktifkan tindakan pada alarm.
Anda juga dapat menggunakan [Amazon EventBridge](https://aws.amazon.com/eventbridge/) untuk merespons peristiwa sistem secara otomatis, seperti masalah ketersediaan aplikasi atau perubahan sumber daya. Anda dapat membuat aturan untuk menunjukkan peristiwa mana yang perlu diperhatikan, dan tindakan yang harus diambil apabila peristiwa cocok dengan sebuah aturan. Tindakan yang dapat dimulai secara otomatis termasuk menginvokasi fungsi [AWS Lambda](https://aws.amazon.com/lambda/), menginvokasi [Amazon EC2](https://aws.amazon.com/ec2/) `Run Command`, merelai peristiwa tersebut ke [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/), dan melihat [Otomatiskan Amazon EC2 menggunakan EventBridge](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/automating_with_eventbridge.html).
1. **Prosedur Operasi Standar (SOP):** Berdasarkan komponen aplikasi Anda, [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) merekomendasikan beberapa [templat SOP](https://docs.aws.amazon.com/resilience-hub/latest/userguide/sops.html). Anda dapat menggunakan SOP ini untuk mendokumentasikan semua proses yang harus diikuti operator jika peringatan muncul. Anda juga dapat [menyusun SOP](https://docs.aws.amazon.com/resilience-hub/latest/userguide/building-sops.html) berdasarkan rekomendasi Resilience Hub, dan untuk ini Anda memerlukan aplikasi Resilience Hub dengan kebijakan ketahanan terkait, serta penilaian ketahanan historis terhadap aplikasi tersebut. Rekomendasi untuk SOP Anda berasal dari penilaian ketahanan.
Resilience Hub bekerja dengan Systems Manager untuk mengotomatiskan langkah-langkah dalam SOP Anda dengan menyediakan sejumlah [dokumen SSM](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-custom-ssm-doc.html) yang dapat Anda gunakan sebagai dasar untuk SOP tersebut. Misalnya, Resilience Hub mungkin merekomendasikan SOP untuk menambahkan ruang disk berdasarkan dokumen otomatisasi SSM yang sudah ada.
1. **Lakukan tindakan otomatis menggunakan Amazon DevOps Guru:** Anda dapat menggunakan [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) untuk secara otomatis memantau perilaku anomali pada sumber daya aplikasi, serta memberikan rekomendasi terarah untuk mempercepat waktu perbaikan serta identifikasi masalah. DenganDevOps Guru, Anda dapat memantau aliran data operasional hampir secara waktu nyata dari berbagai sumber termasuk metrik Amazon CloudWatch, [AWS Config](https://aws.amazon.com/config/), [AWS CloudFormation](https://aws.amazon.com/cloudformation/), dan [AWS X-Ray](https://aws.amazon.com/xray/). Anda juga dapat menggunakan DevOps Guru untuk secara otomatis membuat [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) di OpsCenter dan mengirim peristiwa ke [EventBridge untuk otomatisasi tambahan](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-eventbridge.html).
## Sumber daya
**Praktik Terbaik Terkait:**
+ [REL06-BP01 Memantau semua komponen untuk beban kerja (Pembuatan)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 Menetapkan dan menghitung metrik (Agregasi)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 Mengirimkan notifikasi (Pemrosesan dan pembuatan alarm waktu nyata)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL08-BP01 Menggunakan runbook untuk aktivitas standar seperti deployment](rel_tracking_change_management_planned_changemgmt.md)
**Dokumen terkait:**
+ [Otomatisasi AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Membuat Aturan EventBridge yang Memicu Peristiwa dari Sumber Daya AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ [Lokakarya One Observability](https://observability.workshop.aws/)
+ [Amazon Builders' Library: Instrumentasi sistem terdistribusi untuk visibilitas operasional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Apa itu Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [Bekerja dengan Dokumen Otomatisasi (Buku Pedoman)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
**Video terkait:**
+ [AWS re:Invent 2022 - Praktik terbaik observabilitas di Amazon ](https://www.youtube.com/watch?v=zZPzXEBW4P8)
+ [AWS re:Invent 2020: Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [ Introduction to AWS Resilience Hub](https://www.youtube.com/watch?v=_OTTCOjWqPo)
+ [ Create Custom Ticket Systems for Amazon DevOps Guru Notifications ](https://www.youtube.com/watch?v=Mu8IqWVGUfg)
+ [ Enable Multi-Account Insight Aggregation with Amazon DevOps Guru ](https://www.youtube.com/watch?v=MHezNcTSTbI)
**Contoh terkait:**
+ [ Lokakarya Keandalan ](https://wellarchitectedlabs.com/reliability/)
+ [ Amazon CloudWatch and Systems Manager Workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/a8e9c6a6-0ba9-48a7-a90d-378a440ab8ba/en-US)
# REL06-BP05 Analitik
Kumpulkan riwayat metrik dan file log dan analisis ini untuk mendapatkan wawasan beban kerja dan tren lebih luas.
Wawasan Amazon CloudWatch Logs mendukung [bahasa kueri sederhana tapi luar biasa](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) yang dapat Anda gunakan untuk menganalisis data log. Amazon CloudWatch Logs juga mendukung langganan yang memungkinkan data mengalir dengan lancar ke Amazon S3 di mana Anda dapat menggunakannya atau Amazon Athena untuk kueri data. Amazon CloudWatch Logs juga mendukung kueri dengan berbagai macam format. Lihat [Format Data dan SerDes yang didukung](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) di Panduan Pengguna Amazon Athena untuk informasi selengkapnya. Untuk analisis set file log yang sangat besar, Anda dapat menjalankan klaster Amazon EMR untuk melakukan analisis skala petabita.
Ada sejumlah alat yang disediakan oleh Partner AWS dan pihak ketiga yang memungkinkan agregasi, pemrosesan, penyimpanan, dan analitik. Alat ini antara lain yakni New Relic, Splunk, Loggly, Logstash, CloudHealth, dan Nagios. Tetapi, generasi luar sistem dan log aplikasi bersifat unik untuk setiap penyedia cloud, dan sering kali unik untuk setiap layanan.
Bagian proses pemantauan yang sering kali tidak diperhatikan adalah manajemen data. Anda harus menentukan persyaratan retensi untuk memantau data, kemudian terapkan kebijakan siklus hidup yang sesuai. Amazon S3 mendukung manajemen siklus hidup di tingkat bucket S3. Manajemen siklus hidup ini dapat diterapkan secara berbeda ke jalur yang berbeda di bucket. Menjelang akhir siklus hidup, Anda dapat melakukan transisi data ke Amazon Glacier untuk penyimpanan jangka panjang, kemudian kedaluwarsa setelah akhir jangka waktu retensi tercapai. Kelas penyimpanan Bertingkat Cerdas S3 didesain untuk mengoptimalkan biaya dengan secara otomatis memindahkan data ke tingkat akses yang paling hemat biaya, tanpa memengaruhi performa atau tambahan biaya operasional.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Wawasan CloudWatch Logs memampukan Anda untuk secara interaktif mencari dan menganalisis data log Anda di Amazon CloudWatch Logs.
+ [Menganalisis Data Log dengan Wawasan CloudWatch Logs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Kueri Sampel Wawasan Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ Gunakan Amazon CloudWatch Logs untuk mengirimkan log ke Amazon S3 di mana Anda dapat menggunakannya atau Amazon Athena untuk kueri data.
+ [Bagaimana cara menganalisis log akses server Amazon S3 menggunakan Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ Buat kebijakan siklus hidup S3 untuk bucket log akses server Anda. Konfigurasikan kebijakan siklus hidup untuk secara berkala menghapus file log. Dengan melakukan tindakan ini, maka jumlah data yang dianalisis Athena untuk setiap kueri akan berkurang.
+ [Bagaimana Cara Membuat Kebijakan Siklus Hidup untuk Bucket S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
## Sumber daya
**Dokumen terkait:**
+ [Kueri Sampel Wawasan Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Menganalisis Data Log dengan Wawasan CloudWatch Logs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Debugging dengan Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Bagaimana Cara Membuat Kebijakan Siklus Hidup untuk Bucket S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
+ [Bagaimana cara menganalisis log akses server Amazon S3 menggunakan Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ [Satu Lokakarya Pengamatan](https://observability.workshop.aws/)
+ [Amazon Builders' Library: Menginstrumentasi sistem terdistribusi untuk visibilitas operasional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP06 Lakukan peninjauan secara teratur
Sering kali tinjau bagaimana pemantauan beban kerja diimplementasikan dan perbarui berdasarkan perubahan dan peristiwa yang signifikan.
Pemantauan yang efektif didorong oleh metrik bisnis utama. Pastikan metrik-metrik ini diakomodasi di beban kerja Anda seiring dengan perubahan prioritas bisnis.
Mengaudit pemantauan Anda akan membantu memastikan Anda tahu kapan aplikasi memenuhi sasaran ketersediaannya. Analisis akar masalah memerlukan kemampuan untuk menemukan apa yang telah terjadi ketika ada kegagalan. AWS memberikan layanan yang memungkinkan Anda untuk melacak keadaan layanan Anda selama insiden:
+ **Amazon CloudWatch Logs:** Anda dapat menyimpan log Anda di dalam layanan ini dan memeriksa kontennya.
+ **Wawasan Amazon CloudWatch Logs**: Adalah layanan terkelola penuh yang memampukan Anda untuk menganalisis log yang sangat besar dalam hitungan detik. Layanan ini memberikan kepada Anda visualisasi dan kueri cepat dan interaktif.
+ **AWS Config:** Anda dapat melihat infrastruktur AWS apa yang digunakan di berbagai titik waktu.
+ **AWS CloudTrail:** Anda dapat melihat API AWS mana yang dipanggil pada waktu apa dan oleh prinsipal apa.
Di AWS, kami mengadakan rapat mingguan untuk [meninjau performa operasional](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) dan untuk berbagi pembelajaran antara tim. Karena ada begitu banyak tim di AWS, kami menciptakan [Roda (The Wheel)](https://aws.amazon.com/blogs/opensource/the-wheel/) untuk secara acak memilih beban kerja yang akan ditinjau. Menetapkan irama yang teratur untuk peninjauan performa operasional dan berbagi pengetahuan meningkatkan kemampuan Anda untuk mencapai performa lebih tinggi dari tim operasional Anda.
**Antipola umum:**
+ Hanya mengumpulkan metrik default.
+ Menetapkan strategi pemantauan dan tidak pernah meninjaunya.
+ Tidak membahas pemantauan ketika ada deployment perubahan besar.
**Manfaat menerapkan praktik terbaik ini:** Secara teratur meninjau pemantauan Anda memampukan antisipasi potensi masalah, dan bukannya bereaksi terhadap notifikasi ketika masalah yang diantisipasi sesungguhnya terjadi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Buat beberapa dasbor untuk beban kerja. Anda harus memiliki dasbor tingkat teratas yang berisi metrik bisnis utama, serta metrik teknis yang telah Anda identifikasi sebagai paling relevan untuk kondisi beban kerja yang diproyeksikan sesuai penggunaan yang bervariasi. Anda juga harus memiliki dasbor yang dapat diinspeksi untuk berbagai tingkat aplikasi dan ketergantungan.
+ [Menggunakan Dasbor Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ Jadwalkan dan lakukan peninjauan dasbor beban kerja secara teratur. Lakukan inspeksi dasbor secara teratur. Anda mungkin memiliki irama yang berbeda untuk kedalaman inspeksi Anda.
+ Inspeksi apakah ada tren dalam metrik. Bandingkan nilai metrik dengan nilai historis untuk melihat apakah ada tren yang mungkin menandakan bahwa sesuatu perlu diselidiki. Contohnya antara lain: meningkatkan latensi, menurunkan fungsi bisnis utama, dan meningkatkan respons kegagalan.
+ Inspeksi apakah ada penyimpangan/anomali dalam metrik Anda. Rerata atau median dapat menutupi penyimpangan dan anomali. Lihat nilai tertinggi dan nilai terendah dalam kerangka waktu dan selidiki penyebab skor yang ekstrem. Saat Anda terus mengeliminasi penyebab-penyebab ini, menurunkan definisi ekstrem akan memungkinkan Anda untuk terus meningkatkan konsistensi performa beban kerja Anda.
+ Cari perubahan mendadak dalam perilaku. Perubahan cepat dalam jumlah atau arah metrik dapat menandakan telah ada perubahan dalam aplikasi, atau ada faktor eksternal yang mungkin perlu Anda tambahkan metrik tambahan untuk dilacak.
## Sumber daya
**Dokumen terkait:**
+ [Kueri Sampel Wawasan Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Debugging dengan Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Satu Lokakarya Pengamatan](https://observability.workshop.aws/)
+ [Amazon Builders' Library: Menginstrumentasi sistem terdistribusi untuk visibilitas operasional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Menggunakan Dasbor Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
# REL06-BP07 Memantau pelacakan permintaan menyeluruh melalui sistem Anda
Lacak permintaan yang sedang diproses melalui komponen layanan agar tim produk dapat lebih mudah menganalisis dan menemukan serta memperbaiki masalah dan meningkatkan kinerja.
**Hasil yang diinginkan:** Beban kerja dengan penelusuran yang komprehensif di semua komponen memudahkan pencarian dan perbaikan masalah, sehingga meningkatkan [rata-rata waktu penyelesaian](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html) (MTTR) kesalahan dan latensi dengan menyederhanakan penemuan akar masalah. Penelusuran yang menyeluruh akan mempersingkat waktu yang diperlukan untuk menemukan komponen yang terdampak dan mencari tahu akar masalah kesalahan atau latensi secara mendetail.
**Antipola umum:**
+ Penelusuran digunakan untuk beberapa komponen, tidak semuanya. Misalnya, tanpa penelusuran untuk AWS Lambda, tim mungkin tidak memahami dengan jelas latensi yang disebabkan oleh cold start dalam beban kerja fluktuatif.
+ Canary sintetis atau pemantauan pengguna nyata (RUM) tidak dikonfigurasi dengan penelusuran. Tanpa canary atau RUM, telemetri interaksi klien dihilangkan dari analisis jejak yang berimbas pada profil kinerja yang tidak lengkap.
+ Beban kerja hybrid mencakup alat penelusuran cloud native dan pihak ketiga, tetapi langkah-langkah belum dilakukan untuk memilih dan sepenuhnya mengintegrasikan solusi penelusuran tunggal. Berdasarkan solusi penelusuran yang dipilih, SDK penelusuran cloud-native harus digunakan untuk melengkapi instrumen yang bukan cloud-native, atau alat pihak ketiga harus dikonfigurasi untuk menyerap telemetri pelacakan cloud-native.
**Manfaat menjalankan praktik terbaik ini:** Saat tim pengembangan menerima peringatan masalah, mereka dapat melihat gambaran utuh tentang interaksi komponen sistem, termasuk korelasi tiap komponen dengan pembuatan log, kinerja, dan kegagalan. Karena penelusuran memudahkan identifikasi akar masalah secara visual, waktu penyelidikan akar masalah menjadi lebih singkat. Tim yang memahami interaksi komponen secara detail mengambil keputusan yang lebih baik dan lebih cepat saat menyelesaikan masalah. Keputusan seperti kapan harus memanggil failover pemulihan bencana (DR) atau lokasi terbaik untuk menerapkan strategi penyembuhan mandiri dapat ditingkatkan dengan menganalisis jejak sistem, dan pada akhirnya meningkatkan kepuasan pelanggan terhadap layanan Anda.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Tim yang mengoperasikan aplikasi yang terdistribusi dapat menggunakan alat penelusuran untuk membuat pengidentifikasi korelasi, mengumpulkan jejak permintaan, dan membuat peta layanan komponen-komponen yang terhubung. Semua komponen aplikasi harus disertakan dalam jejak permintaan termasuk klien layanan, gateway perangkat lunak perantara (middleware) dan bus peristiwa, komponen komputasi, dan penyimpanan, termasuk penyimpanan nilai kunci dan basis data. Sertakan canary sintetis dan pemantauan pengguna nyata dalam konfigurasi penelusuran menyeluruh Anda untuk mengukur interaksi dan latensi klien jarak jauh sehingga Anda dapat secara akurat mengevaluasi kinerja sistem Anda berdasarkan perjanjian dan tujuan tingkat layanan Anda.
Anda dapat menggunakan layanan instrumentasi [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) dan [Pemantauan Aplikasi Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html) untuk memberikan tampilan utuh permintaan yang diproses melalui aplikasi Anda. X-Ray mengumpulkan telemetri aplikasi dan memungkinkan Anda untuk memvisualisasikan dan menyaringnya di seluruh muatan, fungsi, jejak, layanan, API, dan dapat diaktifkan untuk komponen sistem, dengan rendah kode atau tanpa kode. Pemantauan aplikasi CloudWatch mencakup ServiceLens untuk mengintegrasikan jejak Anda dengan metrik, log, dan alarm. Pemantauan aplikasi CloudWatch juga mencakup Syntethics untuk memantau titik akhir dan API Anda, serta pemantauan pengguna nyata untuk melengkapi klien aplikasi web Anda.
## Langkah implementasi
+ Gunakan AWS X-Ray pada semua layanan native yang didukung seperti [Amazon S3, AWS Lambda, dan Amazon API Gateway](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html). Semua layanan AWS ini mengaktifkan X-Ray dengan tombol konfigurasi menggunakan infrastruktur sebagai kode, SDK AWS, atau Konsol Manajemen AWS.
+ Aplikasi instrumen [AWS Distro for Open Telemetry dan X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html) atau agen pengumpulan pihak ketiga.
+ Tinjau [Panduan AWS X-Ray untuk Pengembang](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) untuk implementasi bahasa pemrograman khusus. Bagian dokumentasi ini menjelaskan cara menginstrumentasi permintaan HTTP, kueri SQL, dan proses lain yang spesifik untuk bahasa pemrograman aplikasi Anda.
+ Gunakan penelusuran X-Ray untuk [Amazon CloudWatch Synthetic Canaries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) dan [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) untuk menganalisis jalur permintaan dari klien pengguna akhir Anda melalui infrastruktur AWS hilir Anda.
+ Konfigurasikan metrik dan alarm CloudWatch berdasarkan telemetri canary dan kesehatan sumber daya sehingga tim menerima peringatan masalah dengan cepat, kemudian dapat mempelajari jejak dan peta layanan dengan ServiceLens.
+ Aktifkan integrasi X-Ray untuk alat penelusuran pihak ketiga seperti [Datadog](https://docs.datadoghq.com/tracing/guide/serverless_enable_aws_xray/), [New Relic](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-x-ray-monitoring-integration/), atau [Dynatrace](https://www.dynatrace.com/support/help/setup-and-configuration/setup-on-cloud-platforms/amazon-web-services/amazon-web-services-integrations/aws-service-metrics) jika Anda menggunakan alat pihak ketiga untuk solusi penelusuran utama Anda.
## Sumber daya
**Praktik terbaik terkait:**
+ [REL06-BP01 Memantau semua komponen untuk beban kerja (Pembuatan)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](rel_withstand_component_failures_monitoring_health.md)
**Dokumen terkait:**
+ [Apa itu AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [ Amazon CloudWatch: Pemantauan Aplikasi ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)
+ [Melakukan debug dengan Amazon CloudWatch Synthetics dan AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Amazon Builders' Library: Instrumentasi sistem terdistribusi untuk visibilitas operasional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [ Mengintegrasikan AWS X-Ray dengan layanan AWS lain ](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html)
+ [AWS Distro for OpenTelemetry dan AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html)
+ [ Amazon CloudWatch: Menggunakan pemantauan sintetis ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [ Amazon CloudWatch: Gunakan CloudWatch RUM ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [ Mengatur canary sintetis Amazon CloudWatch dan alarm Amazon CloudWatch ](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/set-up-amazon-cloudwatch-synthetics-canary-and-amazon-cloudwatch-alarm.html)
+ [ Ketersediaan dan Lainnya: Memahami dan Meningkatkan Ketangguhan Sistem Terdistribusi di AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)
**Contoh terkait:**
+ [ Lokakarya One Observability ](https://catalog.workshops.aws/observability/en-US)
**Video terkait:**
+ [AWS re:Invent 2022 - Cara memantau aplikasi di beberapa akun ](https://www.youtube.com/watch?v=kFGOkywu-rw)
+ [ Cara Memantau Aplikasi AWS Anda ](https://www.youtube.com/watch?v=UxWU9mrSbmA)
**Alat terkait:**
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/pm/cloudwatch/)
+ [ Amazon Route 53 ](https://aws.amazon.com/route53/)
# REL 7. Bagaimana cara mendesain beban kerja Anda untuk beradaptasi dengan perubahan dalam permintaan?
Beban kerja yang dapat diskalakan memberikan elastisitas untuk menambahkan atau mengeluarkan sumber daya secara otomatis sehingga sangat sesuai dengan permintaan saat ini pada titik waktu tertentu.
**Topics**
+ [REL07-BP01 Menggunakan otomatisasi ketika mendapatkan atau menskalakan sumber daya](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 Mendapatkan sumber daya setelah deteksi gangguan pada beban kerja](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 Menambah sumber daya berdasarkan deteksi bahwa beban kerja memerlukan lebih banyak sumber daya](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 Menguji beban untuk beban kerja Anda](rel_adapt_to_changes_load_tested_adapt.md)
# REL07-BP01 Menggunakan otomatisasi ketika mendapatkan atau menskalakan sumber daya
Ketika mengganti sumber daya yang terganggu atau menskalakan beban kerja Anda, otomatiskan proses menggunakan AWS Managed Services (AMS), seperti Amazon S3 dan AWS Auto Scaling. Anda juga dapat menggunakan alat pihak ketiga dan SDK AWS untuk mengotomatiskan penskalaan.
AWS Managed Services mencakup Amazon S3, Amazon CloudFront, AWS Auto Scaling, AWS Lambda, Amazon DynamoDB, AWS Fargate, dan Amazon Route 53.
Dengan AWS Auto Scaling, Anda dapat mendeteksi dan mengganti instans yang terganggu. Dengan ini, Anda juga dapat membuat rencana penskalaan untuk sumber daya, termasuk instans [Amazon EC2](https://aws.amazon.com/ec2/) dan Armada Spot, tugas [Amazon ECS](https://aws.amazon.com/ecs/) , tabel dan indeks [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) , serta Replika [Amazon Aurora](https://aws.amazon.com/aurora/) .
Saat menskalakan instans EC2, pastikan bahwa Anda menggunakan Zona Ketersediaan (disarankan minimal tiga) serta menambahkan atau menghapus kapasitas untuk menjaga keseimbangan di seluruh Zona Ketersediaan ini. Tugas ECS atau pod Kubernetes (saat menggunakan Amazon Elastic Kubernetes Service) juga harus didistribusikan ke beberapa Zona Ketersediaan.
Ketika menggunakan AWS Lambda, instans menskalakan secara otomatis. Setiap kali notifikasi diterima untuk fungsi Anda, AWS Lambda langsung mencari kapasitas bebas di dalam armada komputasinya, serta menjalankan kode Anda sesuai konkurensi yang dialokasikan. Anda harus memastikan bahwa konkurensi yang diperlukan telah dikonfigurasikan di Lambda tertentu, dan di dalam Service Quotas.
Amazon S3 diskalakan secara otomatis untuk menangani tingkat permintaan tinggi. Misalnya, aplikasi Anda dapat memenuhi minimum 3.500 permintaan PUT/COPY/POST/DELETE atau 5.500 permintaan GET/HEAD per detik per prefiks dalam bucket. Tidak ada batasan jumlah prefiks dalam bucket. Anda dapat meningkatkan kinerja baca atau tulis Anda dengan memparalelkan pembacaan. Misalnya, jika Anda membuat 10 prefiks dalam sebuah bucket Amazon S3 untuk memparalelkan pembacaan, Anda dapat menskalakan kinerja baca Anda hingga 55.000 permintaan baca per detik.
Konfigurasikan dan gunakan Amazon CloudFront atau jaringan pengiriman konten (CDN) tepercaya. CDN dapat memberikan waktu respons pengguna akhir yang lebih cepat untuk konten dari cache, sehingga mengurangi kebutuhan untuk menskalakan beban kerja Anda.
**Antipola umum:**
+ Mengimplementasikan grup Auto Scaling untuk pemulihan otomatis, tetapi tidak mengimplementasikan elastisitas.
+ Menggunakan penskalaan otomatis untuk merespons peningkatan yang signifikan di lalu lintas.
+ Melakukan deployment aplikasi yang sangat stateful, menghilangkan opsi elastisitas.
**Manfaat menerapkan praktik terbaik ini:** Otomatisasi menghilangkan potensi kesalahan manual dalam melakukan deployment dan penonaktifan sumber daya. Otomatisasi menghilangkan risiko pembengkakan biaya dan penolakan layanan akibat lambatnya respons saat dibutuhkan untuk melakukan deployment atau penonaktifan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Konfigurasikan dan gunakan AWS Auto Scaling. Ini memantau aplikasi Anda dan secara otomatis menyesuaikan kapasitas untuk mempertahankan kinerja yang stabil dan dapat diprediksi dengan biaya serendah mungkin. Menggunakan AWS Auto Scaling, Anda dapat mengonfigurasi penskalaan aplikasi untuk beberapa sumber daya di beberapa layanan.
+ [Apa itu AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ Konfigurasikan Penskalaan Otomatis dalam instans Amazon EC2 dan Armada Spot, tugas Amazon ECS, tabel dan indeks Amazon DynamoDB, Replika Amazon Aurora, serta perangkat AWS Marketplace Anda sebagai dapat diterapkan.
+ [Mengelola kapasitas throughput secara otomatis dengan Penskalaan Otomatis DynamoDB.](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ Gunakan operasi API layanan untuk menentukan peringatan, kebijakan penskalaan, waktu warm up, dan waktu cool down.
+ Gunakan Elastic Load Balancing. Penyeimbang beban dapat mendistribusikan beban berdasarkan jalur atau berdasarkan konektivitas jaringan.
+ [Apa itu Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ Application Load Balancers dapat mendistribusikan beban berdasarkan jalur.
+ [Apa itu Application Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ Konfigurasikan Application Load Balancer untuk mendistribusikan lalu lintas ke berbagai beban kerja berdasarkan nama domain.
+ Application Load Balancers dapat digunakan untuk mendistribusikan beban dengan cara yang terintegrasi dengan AWS Auto Scaling untuk mengelola permintaan.
+ [Menggunakan penyeimbang beban dengan grup Auto Scaling.](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ Penyeimbang Beban Jaringan dapat mendistribusikan beban berdasarkan koneksi.
+ [Apa itu Penyeimbang Beban Jaringan?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ Konfigurasikan Penyeimbang Beban Jaringan untuk mendistribusikan lalu lintas ke berbagai beban kerja menggunakan TCP, atau untuk mendapatkan set konstan alamat IP untuk beban kerja Anda.
+ Penyeimbang Beban Jaringan dapat digunakan untuk mendistribusikan beban yang terintegrasi dengan AWS Auto Scaling untuk mengelola permintaan.
+ Gunakan penyedia DNS dengan ketersediaan tinggi. Nama DNS memungkinkan pengguna Anda untuk memasukkan nama tanpa perlu memasukkan alamat IP guna mengakses beban kerja Anda dan mendistribusikan informasi ini ke cakupan yang ditentukan, biasanya untuk pengguna beban kerja secara global.
+ Gunakan Amazon Route 53 atau penyedia DNS tepercaya.
+ [Apa itu Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ Gunakan Route 53 untuk mengelola penyeimbang beban dan distribusi CloudFront Anda.
+ Tentukan domain dan subdomain yang akan Anda kelola.
+ Buat set catatan yang sesuai menggunakan catatan ALIAS atau CNAME.
+ [Bekerja dengan catatan](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
+ Gunakan jaringan global AWS untuk optimasi jalur pengguna Anda ke aplikasi. AWS Global Accelerator memantau kondisi titik akhir aplikasi Anda secara terus-menerus dan mengalihkan lalu lintas ke titik akhir yang sehat dalam kurang dari 30 detik.
+ AWS Global Accelerator adalah layanan yang meningkatkan ketersediaan dan kinerja aplikasi Anda untuk pengguna global atau lokal. Ini menyediakan alamat IP statis yang berperan sebagai titik entri tetap ke titik akhir aplikasi Anda dalam satu atau beberapa Wilayah AWS, seperti Application Load Balancers, Penyeimbang Beban Jaringan, atau instans Amazon EC2 Anda.
+ [Apa Itu AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ Konfigurasikan dan gunakan Amazon CloudFront atau jaringan pengiriman konten (CDN) tepercaya. Jaringan pengiriman konten dapat memberikan waktu respons pengguna akhir yang lebih cepat serta memenuhi permintaan konten yang dapat mengakibatkan penskalaan yang tidak perlu dari beban kerja Anda.
+ [Apa itu Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ Konfigurasikan distribusi Amazon CloudFront untuk beban kerja Anda, atau gunakan CDN pihak ketiga.
+ Anda dapat membatasi akses ke beban kerja Anda agar hanya dapat diakses dari CloudFront menggunakan rentang IP untuk CloudFront dalam grup keamanan titik akhir atau kebijakan akses Anda.
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu Anda membuat solusi komputasi yang diotomatiskan.](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling: Cara Kerja Rencana Penskalaan](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: produk yang dapat digunakan dengan penskalaan otomatis](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Mengelola Kapasitas Throughput Secara Otomatis dengan Penskalaan Otomatis DynamoDB.](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Menggunakan penyeimbang beban dengan grup Auto Scaling.](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ [Apa Itu AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Apa Itu Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Apa itu AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ [Apa itu Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected)
+ [Apa itu Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [Apa itu Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [Apa itu Penyeimbang Beban Jaringan?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [Apa itu Application Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Bekerja dengan catatan](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
# REL07-BP02 Mendapatkan sumber daya setelah deteksi gangguan pada beban kerja
Skalakan sumber daya secara reaktif saat diperlukan jika ketersediaan terganggu, guna memulihkan ketersediaan beban kerja.
Anda terlebih dahulu harus mengonfigurasi pemeriksaan kondisi dan kriteria pada pemeriksaan ini agar memberikan penanda saat ketersediaan terganggu oleh kurangnya sumber daya. Lalu, beri tahu personel yang bersangkutan untuk menskalakan sumber daya secara manual, atau mulai otomatisasi untuk menskalakannya secara otomatis.
Skala dapat disesuaikan secara manual untuk beban kerja Anda (misalnya, mengubah jumlah instans EC2 di grup Auto Scaling atau modifikasi throughput tabel DynamoDB melalui Konsol Manajemen AWS atau AWS CLI). Namun, otomatisasi harus digunakan apabila memungkinkan (lihat **Menggunakan otomatisasi ketika mendapatkan atau menskalakan sumber daya**).
**Hasil yang diinginkan:** Aktivitas penskalaan (baik secara otomatis maupun manual) diinisiasi untuk memulihkan ketersediaan setelah terdeteksinya kegagalan atau menurunnya pengalaman pelanggan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Terapkan observabilitas dan pemantauan di semua komponen dalam beban kerja Anda untuk memantau pengalaman pelanggan dan mendeteksi kegagalan. Tentukan prosedur, manual atau otomatis, yang menskalakan sumber daya yang diperlukan. Untuk informasi lebih lanjut, lihat [ REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html).
### Langkah implementasi
+ Tentukan prosedur, manual atau otomatis, yang menskalakan sumber daya yang dibutuhkan.
+ Prosedur penskalaan tergantung pada bagaimana rancangan berbagai komponen dalam beban kerja Anda.
+ Prosedur penskalaan juga bervariasi, tergantung teknologi dasar yang digunakan.
+ Komponen yang menggunakan AWS Auto Scaling dapat menggunakan rencana penskalaan untuk mengonfigurasi serangkaian instruksi guna menskalakan sumber daya Anda. Jika Anda bekerja dengan AWS CloudFormation atau menambahkan tag ke sumber daya AWS, Anda dapat menyiapkan rencana penskalaan untuk berbagai set sumber daya per aplikasi. Auto Scaling menyediakan saran strategi penskalaan yang disesuaikan untuk tiap-tiap sumber daya. Setelah Anda membuat rencana penskalaan, Auto Scaling menggabungkan metode penskalaan dinamis dan penskalaan prediktif untuk mendukung strategi penskalaan Anda. Untuk detail selengkapnya, lihat [Cara kerja rencana penskalaan](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html).
+ Amazon EC2 Auto Scaling memverifikasi bahwa jumlah instans Amazon EC2 Anda yang tersedia sudah tepat untuk menangani beban aplikasi Anda. Anda membuat koleksi instans EC2, yang disebut grup Auto Scaling. Anda dapat menentukan jumlah instans minimum dan maksimum di setiap grup Auto Scaling, dan Amazon EC2 Auto Scaling memastikan bahwa grup Anda tidak pernah berada di bawah atau di atas batas ini. Untuk lebih jelasnya, lihat [Apa itu Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ Penskalaan otomatis Amazon DynamoDB menggunakan layanan Application Auto Scaling untuk menyesuaikan secara dinamis kapasitas throughput yang disediakan atas nama Anda, sebagai respons terhadap pola lalu lintas aktual. Ini memungkinkan tabel atau indeks sekunder global untuk meningkatkan kapasitas baca dan tulis yang disediakan untuk menangani peningkatan lalu lintas yang mendadak, tanpa throttling. Untuk detail selengkapnya, lihat [Mengelola kapasitas throughput secara otomatis dengan penskalaan otomatis DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html).
## Sumber daya
**Praktik Terbaik Terkait:**
+ [REL07-BP01 Menggunakan otomatisasi ketika mendapatkan atau menskalakan sumber daya](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html)
**Dokumen terkait:**
+ [AWS Auto Scaling: Cara Kerja Rencana Penskalaan](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Mengelola Kapasitas Throughput Secara Otomatis dengan Penskalaan Otomatis DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Apa Itu Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP03 Menambah sumber daya berdasarkan deteksi bahwa beban kerja memerlukan lebih banyak sumber daya
Skalakan sumber daya secara proaktif untuk memenuhi permintaan dan menghindari dampak ketersediaan.
Banyak layanan AWS yang melakukan penskalaan secara otomatis untuk memenuhi permintaan. Dengan menggunakan instans Amazon EC2 atau klaster Amazon ECS, Anda dapat mengonfigurasikan penskalaan otomatis ini agar muncul berdasarkan penggunaan metrik yang sesuai dengan permintaan untuk beban kerja Anda. Untuk Amazon EC2, rata-rata pemanfaatan CPU, jumlah permintaan penyeimbang beban, atau bandwidth jaringan dapat digunakan untuk menskalakan ke luar (atau menskalakan ke dalam) instans EC2. Untuk Amazon ECS, rata-rata pemanfaatan CPU, jumlah permintaan penyeimbang beban, dan pemanfaatan memori dapat digunakan untuk menskalakan ke luar (atau menskalakan ke dalam) tugas ECS. Menggunakan Penskalaan Otomatis Target di AWS, penskala otomatis berperan seperti termostat, yang menambahkan atau menghapus sumber daya untuk mempertahankan nilai target (misalnya, 70% pemanfaatan CPU) yang Anda tentukan.
AWS Auto Scaling juga dapat melakukan [Penskalaan Otomatis Prediktif](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/), yang menggunakan machine learning untuk menganalisis setiap beban kerja historis sumber daya dan memperkirakan beban untuk dua hari mendatang secara rutin.
Little’s Law membantu menghitung banyaknya instans komputasi (instans EC2, fungsi Lambda bersamaan, dll.) yang Anda butuhkan.
*L* = *λW*
L = jumlah instans (atau konkurensi nilai tengah dalam sistem)
λ = rasio rata-rata permintaan yang diterima (permintaan/detik)
W = waktu rata-rata yang diperlukan setiap permintaan di dalam sistem (detik)
Misalnya, dengan laju 100 rps (permintaan per detik), jika setiap permintaan memerlukan 0,5 detik untuk diproses, Anda akan memerlukan 50 instans untuk memenuhi permintaan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Tambahkan sumber daya berdasarkan deteksi bahwa beban kerja memerlukan lebih banyak sumber daya. Skalakan sumber daya secara proaktif untuk memenuhi permintaan dan menghindari dampak ketersediaan.
+ Hitung banyaknya sumber daya komputasi yang akan Anda butuhkan (konkurensi komputasi) untuk menangani rasio permintaan tertentu.
+ [Seputar Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ Jika Anda memiliki pola historis untuk penggunaan, atur penskalaan terjadwal untuk penskalaan otomatis Amazon EC2.
+ [Penskalaan Terjadwal untuk Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ Gunakan penskalaan prediktif AWS.
+ [Penskalaan Prediktif untuk EC2, Didukung oleh Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
## Sumber daya
**Dokumen terkait:**
+ [AWS Auto Scaling: Cara Kerja Rencana Penskalaan](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: produk yang dapat digunakan dengan penskalaan otomatis](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Mengelola Kapasitas Throughput Secara Otomatis dengan Penskalaan Otomatis DynamoDB.](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Penskalaan Prediktif untuk EC2, Didukung oleh Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Penskalaan Terjadwal untuk Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [Seputar Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ [Apa Itu Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP04 Menguji beban untuk beban kerja Anda
Adopsi metodologi pengujian beban untuk mengukur apakah aktivitas penskalaan memenuhi persyaratan beban kerja.
Pengujian beban yang berkelanjutan penting untuk dilakukan. Pengujian beban harus menemukan titik nadir dan menguji kinerja beban kerja Anda. AWS memudahkan penyiapan lingkungan pengujian sementara yang memodelkan skala beban kerja produksi Anda. Di cloud, Anda dapat membuat lingkungan pengujian berskala produksi sesuai permintaan, menyelesaikan pengujian, kemudian menonaktifkan sumber dayanya. Karena Anda hanya membayar lingkungan pengujian saat sedang berjalan, Anda dapat menyimulasikan lingkungan langsung Anda dengan biaya yang lebih murah daripada pengujian on-premise.
Pengujian beban di produksi juga harus dipertimbangkan sebagai bagian dari aktivitas game day di mana sistem produksi diberikan tekanan, selama jam-jam penggunaan pelanggan yang lebih rendah, dengan semua personel siap menerjemahkan hasilnya dan menangani masalah yang muncul.
**Antipola umum:**
+ Melakukan pengujian beban di lingkungan deployment yang tidak memiliki konfigurasi yang sama dengan produksi Anda.
+ Melakukan pengujian beban hanya pada beban kerja Anda secara terpisah-pisah, bukan pada keseluruhan beban kerja.
+ Melakukan pengujian beban dengan subset permintaan, bukan set permintaan riil yang representatif.
+ Melakukan pengujian beban ke faktor keselamatan kecil di atas beban yang diharapkan.
**Manfaat menjalankan praktik terbaik ini:** Anda mengetahui komponen apa saja di dalam arsitektur Anda yang gagal saat menerima beban, dan mampu mengidentifikasi metrik apa saja yang perlu diamati sebagai indikator bahwa Anda mendekati beban tersebut tepat waktu untuk mengatasi masalah dan mencegah dampak kegagalan tersebut.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
+ Lakukan pengujian beban untuk mengidentifikasi aspek dalam beban kerja Anda yang menunjukkan bahwa Anda harus menambah atau menghapus kapasitas. Pengujian beban harus memiliki lalu lintas representatif yang serupa dengan yang Anda terima di lingkungan produksi. Tingkatkan beban sambil mengamati metrik yang telah Anda instrumentasi untuk menentukan metrik mana yang menunjukkan kapan Anda harus menambah atau menghapus sumber daya.
+ [Pengujian Beban Terdistribusi di AWS: simulasikan ribuan pengguna terhubung](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ Identifikasi gabungan permintaan. Anda mungkin memiliki gabungan permintaan yang beragam, sehingga Anda harus melihat berbagai kerangka waktu saat mengidentifikasi gabungan lalu lintas.
+ Implementasikan pendorong beban. Anda dapat menggunakan aplikasi kode kustom, sumber terbuka, atau komersial untuk mengimplementasikan pendorong beban.
+ Lakukan uji beban di awal menggunakan kapasitas kecil. Anda melihat beberapa dampak langsung dengan mendorong beban ke kapasitas yang lebih kecil, kemungkinan seukuran satu instans atau kontainer.
+ Uji beban dengan kapasitas yang lebih besar. Efek akan berbeda di beban yang terdistribusi, sehingga Anda harus menguji di lingkungan yang semirip mungkin dengan lingkungan produksi.
## Sumber daya
**Dokumen terkait:**
+ [Pengujian Beban Terdistribusi di AWS: simulasikan ribuan pengguna terhubung](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
# REL 8. Bagaimana cara mengimplementasikan perubahan?
Perubahan terkontrol diperlukan untuk melakukan deployment fungsionalitas baru, dan untuk memverifikasi bahwa beban kerja dan lingkungan operasi menjalankan perangkat lunak yang dikenal dan dapat di-patch atau diganti dengan cara yang dapat diprediksi. Jika perubahan-perubahan ini tidak terkontrol, maka akan sulit untuk memprediksi efek dari perubahan-perubahan tersebut, atau untuk mengatasi masalah yang timbul sebagai akibatnya.
**Topics**
+ [REL08-BP01 Menggunakan runbook untuk aktivitas standar seperti deployment](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 Integrasikan pengujian fungsional sebagai bagian dari deployment Anda](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 Mengintegrasikan pengujian ketahanan sebagai bagian dari deployment Anda](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 Melakukan deployment menggunakan infrastruktur tetap](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 Melakukan deployment perubahan dengan otomatisasi](rel_tracking_change_management_automated_changemgmt.md)
# REL08-BP01 Menggunakan runbook untuk aktivitas standar seperti deployment
Runbook adalah prosedur terdokumentasi untuk mencapai hasil tertentu. Gunakan runbook untuk melakukan aktivitas standar, baik yang dilakukan secara manual maupun otomatis. Contohnya adalah men-deploy beban kerja, mem-patch beban kerja, atau membuat modifikasi DNS.
Misalnya, terapkan proses untuk [memastikan keamanan pembatalan selama deployment](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments). Memastikan bahwa Anda dapat membatalkan deployment tanpa gangguan terhadap pelanggan adalah sesuatu yang penting dalam menciptakan keandalan layanan.
Untuk prosedur runbook, mulailah dengan proses manual efektif yang valid, implementasikan dalam kode, dan picu agar berjalan secara otomatis saat diperlukan.
Bahkan untuk beban kerja canggih yang diotomatiskan dalam tingkat tinggi, runbook tetap bermanfaat untuk [menjalankan aktivitas game day](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) atau memenuhi persyaratan pelaporan dan audit yang ketat.
Ingat bahwa buku pedoman digunakan untuk merespons insiden tertentu, sedangkan runbook digunakan untuk mencapai hasil tertentu. Sering kali, runbook ditujukan untuk aktivitas rutin, sedangkan buku pedoman digunakan untuk merespons peristiwa nonrutin.
**Antipola umum:**
+ Melakukan perubahan tidak terencana pada konfigurasi di lingkungan produksi.
+ Melewatkan langkah-langkah dalam rencana Anda untuk men-deploy lebih cepat, sehingga mengakibatkan kegagalan deployment.
+ Membuat perubahan tanpa menguji pembatalan perubahan.
**Manfaat menjalankan praktik terbaik ini:** Perencanaan perubahan yang efektif meningkatkan kemampuan Anda untuk berhasil mengeksekusi perubahan karena Anda mengetahui semua sistem yang terpengaruh. Validasi perubahan di lingkungan pengujian meningkatkan kepercayaan diri Anda.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Aktifkan respons yang cepat dan konsisten terhadap peristiwa yang dipahami dengan baik dengan cara mendokumentasikan prosedur di dalam runbook.
+ [AWS Well-Architected Framework: Konsep: Runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ Gunakan prinsip infrastruktur sebagai kode untuk menetapkan infrastruktur Anda. Dengan menggunakan AWS CloudFormation (atau pihak ketiga tepercaya) untuk menetapkan infrastruktur Anda, Anda dapat menggunakan perangkat lunak kontrol versi untuk membuat versi baru dan melacak perubahan.
+ Gunakan AWS CloudFormation (atau penyedia pihak ketiga tepercaya) untuk menetapkan infrastruktur Anda.
+ [Apa itu AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ Buat templat singular dan terpisah-pisah, menggunakan prinsip desain perangkat lunak yang baik.
+ Tentukan izin, templat, dan pihak-pihak yang bertanggung jawab untuk implementasi.
+ [ Mengontrol akses dengan AWS Identity and Access Management. ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
+ Gunakan kontrol sumber, seperti AWS CodeCommit atau alat pihak ketiga tepercaya, untuk kontrol versi.
+ [Apa Itu AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu Anda membuat solusi deployment yang diotomatisasi](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace: produk yang dapat digunakan untuk mengotomatisasi deployment Anda](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [AWS Well-Architected Framework: Konsep: Runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ [Apa itu AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [Apa Itu AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
**Contoh terkait:**
+ [Mengotomatiskan operasi dengan Buku Pedoman dan Runbook](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL08-BP02 Integrasikan pengujian fungsional sebagai bagian dari deployment Anda
Uji fungsional dijalankan sebagai bagian dari deployment otomatis. Jika kriteria untuk sukses tidak terpenuhi, maka alur akan dihentikan atau dikembalikan.
Pengujian ini dijalankan dalam lingkungan praproduksi, yang dilaksanakan sebelum perkembangan produksi. Idealnya, ini dilakukan sebagai bagian dari alur deployment.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Integrasikan pengujian fungsional sebagai bagian dari deployment Anda. Uji fungsional dijalankan sebagai bagian dari deployment otomatis. Jika kriteria untuk sukses tidak terpenuhi, maka alur akan dihentikan atau dikembalikan.
+ Panggil AWS CodeBuild selama ‘Tindakan Pengujian’ dari alur rilis perangkat lunak Anda yang dimodelkan di AWS CodePipeline. Kemampuan ini memungkinkan Anda untuk dengan mudah menjalankan berbagai macam pengujian terhadap kode Anda, seperti uji unit, analisis kode statis, dan uji integrasi.
+ [AWS CodePipeline Menambahkan Dukungan untuk Unit dan Pengujian Integrasi Kustom dengan AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ Gunakan solusi AWS Marketplace untuk melaksanakan pengujian otomatis sebagai bagian dari alur hasil pengiriman perangkat lunak Anda.
+ [Otomatisasi uji perangkat lunak](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## Sumber daya
**Dokumen terkait:**
+ [AWS CodePipeline Menambahkan Dukungan untuk Unit dan Pengujian Integrasi Kustom dengan AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Otomatisasi uji perangkat lunak](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [Apa Itu AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
# REL08-BP03 Mengintegrasikan pengujian ketahanan sebagai bagian dari deployment Anda
Pengujian ketahanan (menggunakan [prinsip-prinsip chaos engineering](https://principlesofchaos.org/)) dijalankan sebagai bagian dari pipeline deployment otomatis dalam lingkungan praproduksi.
Pengujian tersebut dilaksanakan dan dijalankan di lingkungan praproduksi. Pengujian harus dijalankan dalam produksi sebagai bagian dari [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays).
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Integrasikan pengujian ketahanan sebagai bagian dari deployment Anda. Gunakan Chaos Engineering, bidang ilmu yang bereksperimen pada sistem guna membangun kepercayaan pada kemampuan beban kerja untuk menahan kondisi turbulen dalam produksi.
+ Pengujian ketahanan memasukkan kesalahan atau degradasi sumber daya untuk menilai apakah beban kerja merespons dengan desain ketahanannya.
+ [Lab Well-Architected: Level 300: Pengujian Ketahanan EC2, RDS, dan S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
+ Pengujian ini dapat dijalankan secara rutin di lingkungan praproduksi dalam pipeline deployment otomatis.
+ Pengujian harus dijalankan dalam produksi sebagai bagian dari game day terjadwal.
+ Dengan menggunakan prinsip-prinsip Chaos Engineering, ajukan hipotesis tentang cara beban kerja bekerja di berbagai gangguan, kemudian uji hipotesis dengan menggunakan pengujian ketahanan.
+ [Prinsip-prinsip Chaos Engineering](https://principlesofchaos.org/)
## Sumber daya
**Dokumen terkait:**
+ [Prinsip-prinsip Chaos Engineering](https://principlesofchaos.org/)
+ [Apa itu Simulator Injeksi Kesalahan AWS?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Contoh terkait:**
+ [Lab Well-Architected: Level 300: Pengujian Ketahanan EC2, RDS, dan S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
# REL08-BP04 Melakukan deployment menggunakan infrastruktur tetap
Infrastruktur tetap adalah model yang menuntut bahwa tidak ada pembaruan, patch keamanan, atau perubahan konfigurasi yang terjadi di tempat pada beban kerja produksi. Saat perubahan diperlukan, arsitektur dibangun ke infrastruktur baru dan di-deploy ke dalam produksi.
Ikuti strategi penerapan infrastruktur tetap untuk meningkatkan keandalan, konsistensi, dan keterulangan dalam deployment beban kerja Anda.
**Hasil yang diinginkan:** Dengan infrastruktur tetap, tidak ada [modifikasi di tempat](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/in-place-deployments.html) yang diizinkan untuk menjalankan sumber daya infrastruktur dalam beban kerja. Sebaliknya, ketika perubahan diperlukan, kumpulan sumber daya infrastruktur baru yang diperbarui, yang berisi semua perubahan yang diperlukan, di-deploy secara paralel dengan sumber daya Anda yang ada. Deployment ini divalidasi secara otomatis, dan jika berhasil, lalu lintas dialihkan secara bertahap ke kumpulan sumber daya baru.
Strategi deployment ini berlaku di antaranya untuk pembaruan perangkat lunak, patch keamanan, perubahan infrastruktur, pembaruan konfigurasi, dan pembaruan aplikasi.
**Antipola umum:**
+ Menerapkan perubahan di tempat untuk menjalankan sumber daya infrastruktur.
**Manfaat menjalankan praktik terbaik ini:**
+ **Meningkatnya konsistensi di seluruh lingkungan:** Karena tidak ada perbedaan sumber daya infrastruktur di seluruh lingkungan, konsistensi meningkat dan pengujian menjadi lebih sederhana.
+ **Berkurangnya penyimpangan konfigurasi:** Dengan mengganti sumber daya infrastruktur dengan konfigurasi yang diketahui dan dikontrol versinya, infrastruktur diatur ke status yang diketahui, diuji, dan tepercaya, sehingga menghindari penyimpangan konfigurasi.
+ **Deployment atomik yang dapat diandalkan:** Deployment hanya berujung pada dua hal: berhasil diselesaikan atau tidak ada perubahan, sehingga konsistensi dan keandalan dalam proses deployment meningkat.
+ **Deployment yang disederhanakan:** Deployment disederhanakan karena tidak memerlukan pembaruan dukungan. Pembaruan hanyalah deployment baru.
+ **Deployment yang lebih aman dengan proses rollback dan pemulihan yang cepat:** Deployment lebih aman karena versi kerja sebelumnya tidak berubah. Anda dapat melakukan rollback jika kesalahan terdeteksi.
+ **Postur keamanan yang lebih baik:** Karena perubahan pada infrastruktur tidak diizinkan, mekanisme akses jarak jauh (seperti SSH) dapat dinonaktifkan. Hal ini mengurangi vektor serangan, sehingga meningkatkan postur keamanan organisasi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
**Automasi**
Saat menentukan strategi penyebaran infrastruktur tetap, sebaiknya gunakan [otomatisasi](https://aws.amazon.com/iam/) sebanyak mungkin untuk meningkatkan keterulangan dan meminimalkan potensi kesalahan manusia. Untuk detail selengkapnya, lihat [REL08-BP05 Melakukan deployment perubahan dengan otomatisasi ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html) dan [Mengotomatiskan deployment aman tanpa campur tangan](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/).
Dengan [Infrastructure sebagai Kode (IaC)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html), langkah-langkah penyediaan infrastruktur, orkestrasi, dan deployment ditentukan dalam cara yang terprogram, deskriptif, dan deklaratif dan disimpan dalam sistem kontrol sumber. Memanfaatkan infrastruktur sebagai kode makin memudahkan otomatisasi deployment infrastruktur dan membantu mewujudkan ketetapan infrastruktur.
**Pola deployment**
Ketika perubahan dalam beban kerja diperlukan, strategi deployment tetap mengharuskan deployment sumber daya infrastruktur yang baru, termasuk semua perubahan yang diperlukan. Penting agar kumpulan sumber daya baru ini mengikuti pola rollout yang meminimalkan dampak pengguna. Ada dua strategi utama untuk deployment ini:
[https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html): Praktik mengarahkan sejumlah kecil pelanggan ke versi baru, yang biasanya dijalankan di instans layanan tunggal (canary). Lalu, Anda meneliti secara mendalam setiap perubahan perilaku atau kesalahan yang dihasilkan. Anda dapat menghapus lalu lintas dari canary jika menemui masalah kritis dan mengembalikan pengguna ke versi sebelumnya. Jika deployment berhasil, Anda dapat melanjutkan melakukan deployment pada kecepatan yang diinginkan, sambil memantau perubahan kesalahan, hingga deployment sudah dilakukan sepenuhnya. AWS CodeDeploy dapat dikonfigurasi dengan [konfigurasi deployment](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) yang memungkinkan deployment canary.
[https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html): Serupa dengan deployment canary, tetapi di sini deployment armada penuh aplikasi dilakukan secara paralel. Anda mengubah deployment di dua tumpukan (blue dan green). Sekali lagi, Anda mengirimkan lalu lintas ke versi baru, dan kembali ke versi lama jika Anda melihat masalah dengan deployment. Biasanya semua lalu lintas dialihkan sekaligus, tetapi Anda juga dapat menggunakan sebagian lalu lintas ke setiap versi untuk meningkatkan adopsi versi baru menggunakan kemampuan perutean DNS tertimbang dari Amazon Route 53. AWS CodeDeploy dan [AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2020-05-18-ts-deploy.html) dapat dikonfigurasikan dengan konfigurasi deployment yang memungkinkan deployment blue/green.
![\[Diagram showing blue/green deployment with AWS Elastic Beanstalk and Amazon Route 53\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/blue-green-deployment.png)
**Deteksi penyimpangan**
*Penyimpangan* didefinisikan sebagai perubahan apa pun yang menyebabkan sumber daya infrastruktur memiliki status atau konfigurasi yang berbeda dengan apa yang diharapkan. Setiap jenis perubahan konfigurasi yang tidak dikelola bertentangan dengan gagasan infrastruktur tetap, dan harus dideteksi dan diperbaiki agar infrastruktur tetap berhasil diimplementasikan.
### Langkah implementasi
+ Larang modifikasi di tempat pada sumber daya infrastruktur yang sedang berjalan.
+ Anda dapat menggunakan [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) untuk menentukan siapa atau apa yang dapat mengakses layanan dan sumber daya di AWS, mengelola izin dengan ketat secara terpusat, dan menganalisis akses untuk menyempurnakan izin di AWS.
+ Otomatiskan deployment sumber daya infrastruktur untuk meningkatkan keterulangan dan meminimalkan potensi kesalahan manusia.
+ Seperti yang dijelaskan dalam [laporan resmi Pengantar DevOps di AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html), otomatisasi merupakan landasan dalam layanan AWS dan didukung secara internal di semua layanan, fitur, dan penawaran.
+ *[Melakukan prapembuatan](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/prebaking-vs.-bootstrapping-amis.html)* Amazon Machine Image (AMI) Anda dapat mempercepat waktu peluncurannya. [EC2 Image Builder](https://aws.amazon.com/image-builder/) adalah layanan AWS yang dikelola sepenuhnya yang membantu Anda mengotomatiskan pembuatan, pemeliharaan, validasi, berbagi, dan deployment AMI kustom Linux atau Windows yang disesuaikan, aman, dan terbaru.
+ Beberapa layanan yang mendukung otomatisasi adalah:
+ [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) adalah layanan yang digunakan untuk dengan cepat melakukan deployment dan menskalakan aplikasi web yang dikembangkan dengan Java, .NET, PHP, Node.js, Python, Ruby, Go, dan Docker pada server yang sudah dikenal seperti Apache, NGINX, Passenger, dan IIS.
+ [AWS Proton](https://aws.amazon.com/proton/) membantu tim platform menghubungkan dan mengoordinasikan semua alat berbeda yang dibutuhkan tim pengembangan Anda untuk penyediaan infrastruktur, deployment kode, pemantauan, dan pembaruan. AWS Proton memungkinkan penyediaan infrastruktur sebagai kode dan deployment aplikasi nirserver dan berbasis kontainer secara otomatis.
+ Memanfaatkan infrastruktur sebagai kode memudahkan otomatisasi deployment infrastruktur, dan membantu mewujudkan ketetapan infrastruktur. AWS menyediakan layanan yang memungkinkan pembuatan, deployment, dan pemeliharaan infrastruktur dengan cara yang terprogram, deskriptif, dan deklaratif.
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/) membantu developer membuat sumber daya AWS dengan cara yang teratur dan dapat diprediksi. Sumber daya ditulis dalam file teks menggunakan format JSON atau YAML. Templat memerlukan sintaks dan struktur tertentu yang bergantung pada jenis sumber daya yang dibuat dan dikelola. Anda menulis sumber daya Anda di JSON atau YAML dengan editor kode apa pun seperti AWS Cloud9, memeriksanya ke dalam sistem kontrol versi, dan kemudian CloudFormation membangun layanan yang ditentukan dengan cara yang aman dan dapat diulang.
+ [AWS Serverless Application Model(AWS SAM)](https://aws.amazon.com/serverless/sam/) adalah kerangka kerja sumber terbuka yang dapat Anda gunakan untuk membangun aplikasi nirserver di AWS. AWS SAM terintegrasi dengan layanan AWS lainnya, dan merupakan pengembangan dari CloudFormation.
+ [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/) adalah kerangka pengembangan perangkat lunak sumber terbuka untuk membuat model dan menyediakan sumber daya aplikasi cloud Anda menggunakan bahasa pemrograman yang sudah dipahami. Anda dapat menggunakan AWS CDK untuk membuat model infrastruktur aplikasi menggunakan TypeScript, Python, Java, dan .NET. AWS CDK menggunakan CloudFormation di latar belakang untuk menyediakan sumber daya dengan cara yang aman dan dapat diulang.
+ [AWS Cloud Control API](https://aws.amazon.com/cloudcontrolapi/) memperkenalkan seperangkat API yang umum yaitu Membuat, Membaca, Memperbarui, Menghapus, dan Mencantumkan (CRUDL) untuk membantu developer mengelola infrastruktur cloud dengan mudah dan konsisten. API umum Cloud Control API memungkinkan developer untuk mengelola siklus hidup layanan AWS dan pihak ketiga secara seragam.
+ Implementasikan pola deployment yang meminimalkan dampak pengguna.
+ Deployment canary:
+ [ Set up an API Gateway canary release deployment ](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [ Create a pipeline with canary deployments for Amazon ECS using AWS App Mesh](https://aws.amazon.com/blogs/containers/create-a-pipeline-with-canary-deployments-for-amazon-ecs-using-aws-app-mesh/)
+ Deployment blue/green: [laporan resmi Deployment Blue/Green di AWS](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html) menjelaskan [contoh teknik](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/implementation-techniques.html) dalam mengimplementasikan strategi deployment blue/green.
+ Deteksi konfigurasi atau penyimpangan status. Untuk detail selengkapnya, lihat [Detecting unmanaged configuration changes to stacks and resources](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html).
## Sumber daya
**Praktik Terbaik Terkait:**
+ [REL08-BP05 Melakukan deployment perubahan dengan otomatisasi](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html)
**Dokumen terkait:**
+ [Mengotomatiskan deployment aman tanpa campur tangan](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [ Leveraging AWS CloudFormation to create an immutable infrastructure at Nubank ](https://aws.amazon.com/blogs/mt/leveraging-immutable-infrastructure-nubank/)
+ [ Infrastruktur sebagai kode ](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)
+ [ Implementing an alarm to automatically detect drift in AWS CloudFormation stacks ](https://docs.aws.amazon.com/blogs/mt/implementing-an-alarm-to-automatically-detect-drift-in-aws-cloudformation-stacks/)
**Video terkait:**
+ [AWS re:Invent 2020: Reliability, consistency, and confidence through immutability ](https://www.youtube.com/watch?v=jUSYnRztttY)
# REL08-BP05 Melakukan deployment perubahan dengan otomatisasi
Deployment dan patching diotomatisasi untuk menyingkirkan dampak negatif.
Membuat perubahan pada sistem produksi adalah salah satu area risiko terbesar untuk banyak organisasi. Kami menganggap deployment sebagai masalah kelas pertama untuk diatasi bersamaan dengan masalah-masalah bisnis yang ditangani oleh perangkat lunak. Saat ini, ini berarti penggunaan otomatisasi kapan saja memungkinkan dalam operasi, termasuk untuk menguji dan melakukan deployment perubahan, menambah atau menghapus kapasitas, dan memigrasikan data. AWS CodePipeline memungkinkan Anda mengelola langkah-langkah yang diperlukan untuk merilis beban kerja Anda. Ini mencakup status deployment menggunakan AWS CodeDeploy untuk mengotomatisasi deployment kode aplikasi ke instans Amazon EC2, instans on-premise, fungsi Lambda nirserver, atau layanan Amazon ECS.
**Rekomendasi**
Meskipun kebijaksanaan konvensional menyarankan Anda untuk melibatkan manusia untuk prosedur operasional paling sulit, kami justru menyarankan Anda mengotomatisasi prosedur paling sulit untuk alasan tersebut.
**Antipola umum:**
+ Melakukan perubahan secara manual.
+ Melewatkan langkah-langkah dalam otomatisasi Anda melalui alur kerja darurat.
+ Tidak mengikuti rencana Anda.
**Manfaat menjalankan praktik terbaik ini:** Penggunaan otomatisasi untuk melakukan deployment semua perubahan dapat menyingkirkan potensi munculnya kesalahan manusia dan menghadirkan kemampuan untuk menguji sebelum mengubah produksi guna memastikan rencana Anda sudah lengkap.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
+ Otomatiskan pipeline deployment Anda. Pipeline deployment memungkinkan Anda untuk memanggil pengujian dan deteksi anomali secara otomatis, serta memberi Anda pilihan untuk menghentikan pipeline pada langkah tertentu sebelum deployment produksi atau membatalkan perubahan secara otomatis.
+ [Amazon Builders' Library: Memastikan keamanan pembatalan selama deployment](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [Amazon Builders' Library: Melaju lebih cepat dengan pengiriman berkelanjutan](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ Gunakan AWS CodePipeline (atau produk pihak ketiga tepercaya) untuk menetapkan dan menjalankan pipeline Anda.
+ Konfigurasikan pipeline untuk mulai saat ada perubahan yang dimasukkan ke repositori kode Anda.
+ [Apa Itu AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ Gunakan Amazon Simple Notification Service (Amazon SNS) dan Amazon Simple Email Service (Amazon SES) untuk mengirimkan notifikasi tentang masalah di dalam pipeline atau integrasikan dengan alat obrolan tim, seperti Amazon Chime.
+ [Apa Itu Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [Apa Itu Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Apa itu Amazon Chime?](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html)
+ [Otomatiskan pesan obrolan dengan webhooks.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu Anda membuat solusi deployment yang diotomatisasi](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace: produk yang dapat digunakan untuk mengotomatisasi deployment Anda](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [Otomatiskan pesan obrolan dengan webhooks.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
+ [Amazon Builders' Library: Memastikan keamanan pembatalan selama deployment](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [Amazon Builders' Library: Melaju lebih cepat dengan pengiriman berkelanjutan](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ [Apa Itu AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ [Apa Itu CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [Apa Itu Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Apa Itu Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
**Video terkait:**
+ [AWS Summit 2019: CI/CD di AWS](https://youtu.be/tQcF6SqWCoY)
# Manajemen kegagalan
**Topics**
+ [REL 9. Bagaimana cara mencadangkan data?](rel-09.md)
+ [REL 10. Bagaimana cara menggunakan isolasi kesalahan untuk melindungi beban kerja?](rel-10.md)
+ [REL 11. Bagaimana Anda mendesain beban kerja agar dapat bertahan jika terjadi kegagalan komponen?](rel-11.md)
+ [REL 12. Bagaimana cara menguji keandalan?](rel-12.md)
+ [REL 13. Bagaimana cara Anda mempersiapkan pemulihan bencana (DR)?](rel-13.md)
# REL 9. Bagaimana cara mencadangkan data?
Cadangkan data, aplikasi, dan konfigurasi untuk memenuhi persyaratan Anda untuk sasaran waktu pemulihan (RTO) dan sasaran titik pemulihan (RPO).
**Topics**
+ [REL09-BP01 Mengidentifikasi dan mencadangkan data yang perlu dicadangkan, atau memproduksi ulang data dari sumber](rel_backing_up_data_identified_backups_data.md)
+ [REL09-BP02 Mengamankan dan mengenkripsikan cadangan](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 Melakukan pencadangan data secara otomatis.](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 Melakukan pemulihan data secara berkala untuk memverifikasi integritas dan proses pencadangan](rel_backing_up_data_periodic_recovery_testing_data.md)
# REL09-BP01 Mengidentifikasi dan mencadangkan data yang perlu dicadangkan, atau memproduksi ulang data dari sumber
Pahami dan gunakan kemampuan pencadangan sumber daya dan layanan data yang digunakan oleh beban kerja. Sebagian besar layanan menyediakan kemampuan untuk mencadangkan data beban kerja.
**Hasil yang diinginkan:** Sumber data telah diidentifikasi dan diklasifikasikan berdasarkan tingkat kekritisan. Lalu, bangun strategi untuk pemulihan data berdasarkan RPO. Strategi ini melibatkan pencadangan sumber-sumber data, atau memiliki kemampuan untuk memproduksi ulang data dari sumber lain. Untuk kasus kehilangan data, strategi yang diimplementasikan memungkinkan pemulihan atau produksi ulang data dalam RPO dan RTO yang ditetapkan.
**Fase kemapanan cloud:** Fondasi
**Antipola umum:**
+ Tidak mengetahui semua sumber data untuk beban kerja serta tingkat kekritisannya.
+ Tidak melakukan pencadangan sumber data kritis.
+ Melakukan pencadangan hanya beberapa sumber data tanpa menggunakan tingkat kekritisan sebagai kriteria.
+ Tidak ada RPO yang ditetapkan, atau frekuensi pencadangan tidak memenuhi RPO.
+ Tidak mengevaluasi apakah cadangan diperlukan atau apakah data dapat diproduksi ulang dari sumber lain.
**Manfaat menjalankan praktik terbaik ini:** Mengidentifikasi tempat-tempat yang memerlukan pencadangan dan mengimplementasikan mekanisme untuk membuat cadangan, atau mampu memproduksi ulang data dari sumber eksternal, semuanya dapat meningkatkan kemampuan untuk memulihkan dan mengembalikan data selama penghentian.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Semua penyimpanan data AWS menawarkan kemampuan pencadangan. Layanan seperti Amazon RDS dan Amazon DynamoDB memberikan dukungan tambahan pada pencadangan otomatis yang memungkinkan pemulihan titik waktu (PITR), yang memungkinkan Anda untuk memulihkan cadangan ke waktu kapan pun hingga lima menit atau kurang sebelum waktu saat ini. Banyak layanan AWS yang menawarkan kemampuan untuk menyalin cadangan ke Wilayah AWS lain. AWS Backup adalah alat yang memberikan kepada Anda kemampuan untuk memusatkan dan mengotomatiskan perlindungan data di layanan AWS. [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) memungkinkan Anda menyalin beban kerja server penuh dan mempertahankan perlindungan data berkelanjutan dari on-premise, lintas AZ, atau lintas Wilayah, dengan Sasaran Titik Pemulihan (RPO) yang diukur dalam detik.
Amazon S3 dapat digunakan sebagai tujuan pencadangan untuk sumber daya yang dikelola mandiri dan yang dikelola oleh AWS. Layanan AWS seperti Amazon EBS, Amazon RDS, dan Amazon DynamoDB memiliki kemampuan bawaan untuk membuat cadangan. Perangkat lunak pencadangan pihak ketiga juga dapat digunakan.
Data on-premise dapat dicadangkan ke AWS Cloud menggunakan [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) atau [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html). Bucket Amazon S3 dapat digunakan untuk menyimpan data ini di AWS. Amazon S3 menawarkan beberapa tingkat penyimpanan seperti [Amazon Glacier atau Amazon Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) untuk mengurangi biaya penyimpanan data.
Anda mungkin dapat memenuhi kebutuhan pemulihan data dengan memproduksi ulang data dari sumber lain. Contohnya, [simpul replika Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) atau [replika baca Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) dapat digunakan untuk memproduksi ulang data jika yang data utama hilang. Jika sumber seperti ini dapat digunakan untuk memenuhi [Sasaran Titik Pemulihan (RPO) dan Sasaran Waktu Pemulihan (RTO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html), Anda mungkin tidak memerlukan cadangan. Contoh lainnya, jika bekerja dengan Amazon EMR, pencadangan penyimpanan data HDFS Anda mungkin tidak diperlukan, selama Anda dapat [memproduksi ulang data ke Amazon EMR dari Amazon S3](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/).
Ketika menyeleksi strategi pencadangan, pertimbangkan waktu yang diperlukan untuk memulihkan data. Waktu yang diperlukan untuk memulihkan data tergantung pada tipe cadangan (untuk kasus strategi pencadangan), atau kompleksitas mekanisme produksi ulang data. Waktu ini termasuk dalam RTO untuk beban kerja.
**Langkah implementasi**
1. **Mengidentifikasi semua sumber data untuk beban kerja**. Data dapat disimpan di sejumlah sumber daya seperti [basis data](https://aws.amazon.com/products/databases/), [volume](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html), [sistem file](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html), [sistem pencatatan log](https://docs.aws.amazon.com/Amazon/latest/logs/WhatIsLogs.html), dan [penyimpanan objek](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html). Lihat bagian **Sumber Daya** untuk menemukan **Dokumen terkait** tentang berbagai layanan AWS tempat data disimpan, dan kemampuan pencadangan yang disediakan oleh layanan-layanan ini.
1. **Klasifikasikan sumber data berdasarkan tingkat kekritisan**. Set data yang berbeda akan memiliki tingkat kekritisan yang berbeda untuk suatu beban kerja, sehingga memiliki persyaratan untuk ketahanan yang berbeda-beda. Misalnya, beberapa data mungkin kritis dan memerlukan RPO hampir nol, sedangkan data lain mungkin tidak terlalu kritis dan dapat mentoleransi RPO yang lebih tinggi dan beberapa hilang data. Demikian juga, set data yang berbeda mungkin memiliki persyaratan RTO yang berbeda.
1. **Gunakan AWS atau layanan pihak ketiga untuk membuat cadangan data**. [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) adalah layanan terkelola yang memungkinkan pembuatan cadangan berbagai sumber data di AWS. [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) menangani replikasi data otomatis sub-detik ke Wilayah AWS. Sebagian besar layanan AWS juga memiliki kemampuan native untuk membuat cadangan. AWS Marketplace juga memiliki banyak solusi untuk menyediakan kemampuan-kemampuan ini. Lihat **Sumber Daya** yang disebutkan di bawah ini untuk mendapatkan informasi tentang cara membuat cadangan data dari berbagai layanan AWS.
1. **Untuk data yang tidak dicadangkan, buat mekanisme produksi ulang data**. Anda mungkin memilih untuk tidak mencadangkan data yang dapat diproduksi ulang dari sumber lain karena berbagai alasan. Mungkin terdapat situasi di mana produksi ulang data dari sumber lain saat diperlukan lebih murah daripada membuat cadangan, karena mungkin ada biaya terkait penyimpanan cadangan. Contoh lainnya adalah ketika pemulihan dari cadangan memerlukan waktu lebih lama daripada produksi ulang data dari sumber lain, sehingga mengakibatkan pelanggaran RTO. Pada situasi-situasi demikian, pertimbangkan semua kompromi dan bangun proses yang ditetapkan dengan baik terkait bagaimana data dapat diproduksi ulang dari sumber-sumber ini saat pemulihan data diperlukan. Misalnya, jika Anda telah memuat data dari Amazon S3 ke gudang data (seperti Amazon Redshift), atau klaster MapReduce (seperti Amazon EMR) untuk melakukan analisis pada data tersebut, ini mungkin adalah contoh data yang dapat diproduksi ulang dari sumber lain. Selama hasil dari semua analisis ini disimpan di suatu tempat atau dapat diproduksi ulang, Anda tidak akan mengalami kehilangan data akibat kegagalan pada gudang data atau klaster MapReduce. Contoh lain data yang dapat diproduksi ulang dari sumber lain adalah cache (seperti Amazon ElastiCache) atau replika baca RDS.
1. **Buat jadwal rutin pencadangan data**. Membuat cadangan sumber data adalah proses berkala dan frekuensinya tergantung pada RPO.
**Tingkat upaya untuk rencana implementasi:** Sedang
## Sumber daya
**Praktik Terbaik Terkait:**
[REL13-BP01 Tetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md)
[REL13-BP02 Menggunakan strategi pemulihan yang ditentukan untuk memenuhi sasaran pemulihan](rel_planning_for_recovery_disaster_recovery.md)
**Dokumen terkait:**
+ [Apa Itu AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Apa itu AWS DataSync?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)
+ [Apa itu Gateway Volume?](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html)
+ [Partner APN: partner yang dapat membantu terkait pencadangan](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: produk yang dapat digunakan untuk pencadangan](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Amazon EBS Snapshots](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Mencadangkan Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [Mencadangkan Amazon FSx untuk Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [Pencadangan dan Pemulihan untuk ElastiCache for Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
+ [Membuat Snapshot Klaster DB di Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html)
+ [Membuat Snapshot DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)
+ [Membuat Aturan EventBridge yang Memicu Berdasarkan Jadwal](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Replika Lintas-Wilayah](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) dengan Amazon S3
+ [EFS-ke-EFS AWS Backup](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/)
+ [Mengekspor Data Log ke Amazon S3](https://docs.aws.amazon.com/Amazon/latest/logs/S3Export.html)
+ [Manajemen siklus hidup objek](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [Pemulihan dan Pencadangan Sesuai Permintaan untuk DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html)
+ [Pemulihan titik waktu untuk DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [Bekerja dengan Snapshot Indeks Amazon OpenSearch Service](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html)
+ [ Apa itu AWS Elastic Disaster Recovery? ](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
**Video terkait:**
+ [AWS re:Invent 2021 - Pencadangan, pemulihan bencana, dan perlindungan ransomware dengan AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [Demo AWS Backup: Pencadangan Lintas Akun dan Lintas Wilayah](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019: Memahami AWS Backup, dengan Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**Contoh terkait:**
+ [Well-Architected Lab - Mengimplementasikan Replikasi Lintas Wilayah (CRR) Dua Arah untuk Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
+ [Well-Architected Lab - Pengujian Pencadangan dan Pemulihan Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [Well-Architected Lab: Pencadangan dan Pemulihan dengan Failback untuk Beban Kerja Analitik](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [Well-Architected Lab: Pemulihan Bencana - Pencadangan dan Pemulihan](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)
# REL09-BP02 Mengamankan dan mengenkripsikan cadangan
Kontrol dan deteksi akses ke cadangan menggunakan autentikasi dan otorisasi. Gunakan enkripsi untuk mencegah dan mendeteksi jika integritas data cadangan terancam.
**Antipola umum:**
+ Memiliki akses yang sama ke cadangan dan otomatisasi pemulihan seperti yang dilakukan pada data.
+ Tidak mengenkripsi cadangan.
**Manfaat menjalankan praktik terbaik ini:** Mengamankan cadangan Anda akan mencegah gangguan terhadap data, dan enkripsi data mencegah akses ke data tersebut jika tidak sengaja terekspos.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Kontrol dan deteksi akses ke cadangan menggunakan autentikasi dan otorisasi seperti AWS Identity and Access Management (IAM). Gunakan enkripsi untuk mencegah dan mendeteksi jika integritas data cadangan terancam.
Amazon S3 mendukung beberapa metode enkripsi data diam. Dengan menggunakan enkripsi di sisi server, Amazon S3 menerima objek sebagai data yang tidak terenkripsi dan mengenkripsinya saat disimpan. Dengan menggunakan enkripsi di sisi klien, aplikasi beban kerja bertanggung jawab untuk mengenkripsi data sebelum mengirimkannya ke Amazon S3. Kedua metode tersebut memungkinkan Anda untuk menggunakan AWS Key Management Service (AWS KMS) guna menciptakan dan menyimpan kunci data. Anda dapat menyediakan kunci Anda sendiri dan bertanggung jawab atas kunci tersebut. Dengan menggunakan AWS KMS, Anda dapat menetapkan kebijakan menggunakan IAM terkait siapa yang dapat dan tidak dapat mengakses kunci data dan data terdekripsi.
Untuk Amazon RDS, cadangan juga akan dienkripsi jika Anda memilih untuk mengenkripsikan basis data. Cadangan DynamoDB selalu terenkripsi. Ketika menggunakan AWS Elastic Disaster Recovery, semua data bergerak dan data diam dienkripsi. Dengan Elastic Disaster Recovery, data diam dapat dienkripsi menggunakan Kunci Enkripsi Volume enkripsi Amazon EBS atau kunci kustom yang dikelola pelanggan.
**Langkah implementasi**
1. Gunakan enkripsi untuk setiap penyimpanan data. Jika sumber data terenkripsi, maka cadangannya juga akan terenkripsi.
+ [Gunakan enkripsi di Amazon RDS.](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html). Anda dapat mengonfigurasi enkripsi diam menggunakan AWS Key Management Service saat membuat instans RDS.
+ [Gunakan enkripsi di volume Amazon EBS.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html). Anda dapat mengonfigurasi enkripsi default atau menentukan kunci unik saat pembuatan volume.
+ Gunakan [enkripsi Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html) yang diperlukan. DynamoDB mengenkripsi semua data diam. Anda dapat menggunakan kunci AWS KMS yang dimiliki AWS atau kunci KMS yang dikelola AWS, menentukan kunci yang disimpan di akun Anda.
+ [Enkripsikan data yang disimpan di Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html). Konfigurasikan enkripsi saat Anda membuat sistem file.
+ Konfigurasikan enkripsi di Wilayah sumber dan tujuan. Anda dapat mengonfigurasi enkripsi diam di Amazon S3 menggunakan kunci yang disimpan di KMS, tetapi kuncinya bersifat spesifik Wilayah. Anda dapat menentukan kunci tujuan saat mengonfigurasi replikasi.
+ Pilih apakah akan menggunakan [enkripsi Amazon EBS default atau kustom untuk Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/volumes-drs.html#ebs-encryption). Opsi ini akan mengenkripsi data diam yang direplikasi di disk Subnet Area Staging dan disk yang direplikasi.
1. Implementasikan izin hak akses paling rendah untuk mengakses cadangan. Ikuti praktik terbaik untuk membatasi akses ke cadangan, snapshot, dan replika sesuai dengan [praktik terbaik keamanan](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html).
## Sumber daya
**Dokumen terkait:**
+ [AWS Marketplace: produk yang dapat digunakan untuk pencadangan](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Enkripsi Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ [Amazon S3: Melindungi Data Menggunakan Enkripsi](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html)
+ [Konfigurasi Tambahan CRR: Mereplikasi Objek yang Dibuat dengan Enkripsi di Sisi Server (SSE) Menggunakan Kunci Enkripsi yang disimpan di AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ [Enkripsi Diam DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Mengenkripsi Sumber Daya Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ [Mengenkripsi Data dan Metadata di Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ [Enkripsi untuk Cadangan di AWS](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)
+ [Mengelola Tabel Terenkripsi](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ [Pilar Keamanan - AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)
+ [ Apa itu AWS Elastic Disaster Recovery? ](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
**Contoh terkait:**
+ [Well-Architected Lab - Mengimplementasikan Replikasi Lintas Wilayah (CRR) Dua Arah untuk Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
# REL09-BP03 Melakukan pencadangan data secara otomatis.
Konfigurasikan pencadangan untuk dilakukan secara otomatis berdasarkan jadwal berkala mengacu pada Sasaran Titik Pemulihan (RPO), atau berdasarkan perubahan dalam set data. Set data kritis dengan persyaratan data hilang yang rendah perlu dicadangkan otomatis secara rutin, sedangkan data yang tidak terlalu kritis di mana beberapa data hilang masih dapat diterima dapat dicadangkan tidak terlalu sering.
**Hasil yang diinginkan:** Proses otomatis yang membuat cadangan sumber data dengan jadwal yang ditetapkan.
**Antipola umum:**
+ Melakukan pencadangan secara manual.
+ Menggunakan sumber daya yang memiliki kemampuan pencadangan, tetapi tidak termasuk pencadangan dalam otomatisasi Anda.
**Manfaat menjalankan praktik terbaik ini:** Otomatisasi pencadangan memverifikasi pencadangan dilakukan secara teratur berdasarkan RPO Anda dan memberi tahu Anda jika pencadangan tidak dilakukan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
AWS Backup dapat digunakan untuk membuat cadangan data otomatis untuk berbagai sumber data AWS. Instans Amazon RDS dapat dicadangkan hampir secara berkelanjutan setiap lima menit dan objek Amazon S3 dapat dicadangkan hampir secara berkelanjutan setiap lima belas menit, dan memungkinkan pemulihan titik waktu (PITR) ke titik waktu tertentu di dalam riwayat pencadangan. Untuk sumber data AWS lainnya, seperti volume Amazon EBS, tabel Amazon DynamoDB, atau sistem file Amazon FSx, AWS Backup dapat menjalankan pencadangan otomatis setiap satu jam. Layanan ini juga menawarkan kemampuan pencadangan native. Layanan AWS yang menawarkan pencadangan otomatis dengan pemulihan titik waktu antara lain [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html), [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html), dan [Amazon Keyspaces (untuk Apache Cassandra)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html) - ini dapat dipulihkan ke titik waktu tertentu dalam riwayat pencadangan. Sebagian besar layanan penyimpanan data AWS lainnya menawarkan kemampuan untuk menjadwalkan pencadangan berkala, dengan frekuensi setiap satu jam.
Amazon RDS dan Amazon DynamoDB menawarkan pencadangan berkelanjutan dengan pemulihan titik waktu. Versioning Amazon S3, setelah diaktifkan, bersifat otomatis. [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) dapat digunakan untuk mengotomatiskan pembuatan, penyalinan, dan penghapusan snapshot Amazon EBS. Layanan ini juga dapat mengotomatiskan pembuatan, penyalinan, penghentian, dan pembatalan registrasi Amazon Machine Images (AMI) yang dicadangkan Amazon EBS dan snapshot Amazon EBS yang melandasinya.
AWS Elastic Disaster Recovery memberikan replikasi tingkat blok yang berkelanjutan dari lingkungan sumber (on-premise atau AWS) ke wilayah pemulihan target. Snapshot Amazon EBS titik waktu dibuat dan dikelola secara otomatis oleh layanan.
Untuk tampilan otomatisasi dan riwayat pencadangan terpusat, AWS Backup menyediakan solusi pencadangan berbasis kebijakan yang terkelola penuh. Layanan ini memusatkan dan mengotomatiskan pencadangan data di beberapa layanan AWS di cloud serta on-premise menggunakan AWS Storage Gateway.
Selain versioning, Amazon S3 dilengkapi dengan replikasi. Seluruh bucket S3 dapat direplikasi secara otomatis ke bucket lain di Wilayah AWS yang sama atau berbeda.
**Langkah implementasi**
1. **Identifikasi sumber data** yang saat ini dicadangkan secara manual. Untuk detail selengkapnya, lihat [REL09-BP01 Mengidentifikasi dan mencadangkan data yang perlu dicadangkan, atau memproduksi ulang data dari sumber](rel_backing_up_data_identified_backups_data.md).
1. **Tentukan RPO** untuk beban kerja. Untuk detail selengkapnya, lihat [REL13-BP01 Tetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md).
1. **Gunakan solusi cadangan otomatis atau layanan terkelola**. AWS Backup adalah layanan terkelola penuh yang mempermudah [pemusatan dan pengotomatisan perlindungan data di seluruh layanan AWS, di cloud, dan on-premise](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups). Dengan menggunakan rencana cadangan di AWS Backup, buat aturan yang menetapkan sumber daya yang akan dicadangkan, dan frekuensi pembuatan cadangan ini. Frekuensi ini harus mengacu pada RPO yang ditetapkan pada Langkah 2. Untuk panduan praktik langsung tentang cara membuat cadangan otomatis menggunakan AWS Backup, lihat [Pengujian Pencadangan dan Pemulihan Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/). Kemampuan pencadangan native ditawarkan oleh sebagian besar layanan AWS yang menyimpan data. Misalnya, RDS dapat dimanfaatkan untuk pencadangan otomatis dengan pemulihan titik waktu (PITR).
1. **Untuk sumber daya yang tidak didukung** oleh solusi pencadangan otomatis atau layanan terkelola seperti sumber data on-premise atau antrean pesan, pertimbangkan penggunaan solusi pihak ketiga tepercaya untuk membuat cadangan otomatis. Pilihan lainnya, Anda dapat membuat otomatisasi untuk melakukannya menggunakan AWS CLI atau SDK. Anda dapat menggunakan Fungsi AWS Lambda atau AWS Step Functions untuk menetapkan logika yang terlibat dalam pembuatan cadangan data, dan gunakan Amazon EventBridge untuk melaksanakannya dengan frekuensi yang didasarkan pada RPO Anda.
**Tingkat upaya untuk Rencana Implementasi:** Rendah
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu terkait pencadangan](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: produk yang dapat digunakan untuk pencadangan](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Membuat Aturan EventBridge yang Memicu Berdasarkan Jadwal](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Apa Itu AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Apa Itu AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [ Apa itu AWS Elastic Disaster Recovery? ](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
**Video terkait:**
+ [AWS re:Invent 2019: Memahami AWS Backup, dengan Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**Contoh terkait:**
+ [Well-Architected Lab - Pengujian Pencadangan dan Pemulihan Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL09-BP04 Melakukan pemulihan data secara berkala untuk memverifikasi integritas dan proses pencadangan
Validasikan bahwa implementasi proses pencadangan Anda memenuhi Sasaran Waktu Pemulihan (RTO) dan Sasaran Titik Pemulihan (RPO) dengan melakukan uji pemulihan.
**Hasil yang diinginkan:** Data dari cadangan dipulihkan secara berkala menggunakan mekanisme yang ditentukan dengan baik untuk memverifikasi bahwa pemulihan tersebut dapat dilakukan dalam sasaran waktu pemulihan (RTO) yang ditetapkan untuk beban kerja. Verifikasikan bahwa pemulihan dari pencadangan menghasilkan sumber daya yang berisi data asli tanpa ada data yang rusak atau tidak dapat diakses, serta dengan kehilangan data dalam sasaran titik pemulihan (RPO).
**Antipola umum:**
+ Memulihkan cadangan, tetapi tidak mengambil data atau membuat kueri data apa pun untuk memastikan pemulihan dapat digunakan.
+ Dengan anggapan bahwa cadangan sudah ada.
+ Dengan anggapan bahwa cadangan sistem dapat dioperasikan sepenuhnya dan data dapat dipulihkan dari sistem.
+ Dengan anggapan bahwa waktu untuk memulihkan data dari cadangan termasuk dalam RTO untuk beban kerja.
+ Dengan anggapan bahwa data dalam cadangan termasuk dalam RPO untuk beban kerja.
+ Memulihkan apabila diperlukan, tanpa menggunakan runbook, atau di luar prosedur otomatis yang ditetapkan.
**Manfaat menjalankan praktik terbaik ini:** Pengujian pemulihan cadangan memastikan data dapat dipulihkan saat dibutuhkan tanpa perlu khawatir data akan hilang atau rusak, bahwa restorasi dan pemulihan dapat dilakukan dalam batas RTO untuk beban kerja, dan kehilangan data apa pun termasuk dalam RPO untuk beban kerja.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Pengujian kemampuan pencadangan dan pemulihan meningkatkan keyakinan pada kemampuan untuk menjalankan tindakan ini selama pemadaman. Pulihkan cadangan ke lokasi baru secara berkala dan lakukan pengujian untuk memverifikasi integritas data. Beberapa pengujian umum yang harus dilakukan yakni, memeriksa apakah semua data tersedia, tidak rusak, dapat diakses, dan setiap kehilangan data termasuk dalam RPO untuk beban kerja. Pengujian tersebut dapat juga membantu memastikan apakah mekanisme pemulihan cukup cepat untuk mengakomodasi RTO beban kerja.
Dengan menggunakan AWS, Anda dapat mempertahankan lingkungan pengujian dan memulihkan cadangan untuk menilai kemampuan RTO dan RPO, serta menjalankan pengujian pada konten dan integritas data.
Selain itu, Amazon RDS dan Amazon DynamoDB memungkinkan pemulihan titik waktu (PITR). Dengan menggunakan pencadangan berkelanjutan, Anda dapat memulihkan set data ke statusnya pada waktu dan tanggal yang ditentukan.
apakah semua data tersedia, tidak rusak, dapat diakses, dan kehilangan data apa pun termasuk dalam RPO untuk beban kerja. Pengujian tersebut dapat juga membantu memastikan apakah mekanisme pemulihan cukup cepat untuk mengakomodasi RTO beban kerja.
AWS Elastic Disaster Recovery menawarkan snapshot pemulihan titik waktu volume Amazon EBS secara berkelanjutan. Saat server sumber direplikasi, status titik waktu dicatat seiring waktu berdasarkan kebijakan yang dikonfigurasi. Elastic Disaster Recovery membantu Anda memverifikasi integritas snapshot ini dengan meluncurkan instans untuk tujuan pengujian dan latihan tanpa mengarahkan ulang lalu lintas.
**Langkah implementasi**
1. **Identifikasi sumber data** yang dicadangkan saat ini dan lokasi penyimpanan cadangan tersebut. Untuk panduan implementasi, lihat [REL09-BP01 Mengidentifikasi dan mencadangkan data yang perlu dicadangkan, atau memproduksi ulang data dari sumber](rel_backing_up_data_identified_backups_data.md).
1. **Tetapkan kriteria validasi data** untuk setiap sumber data. Jenis data yang berbeda akan memiliki properti data yang berbeda, yang dapat memerlukan mekanisme validasi yang berbeda. Pertimbangkan bagaimana data ini dapat divalidasi sebelum Anda yakin untuk menggunakannya dalam produksi. Beberapa cara umum untuk memvalidasi adalah dengan menggunakan data dan properti pencadangan seperti jenis data, format, checksum, ukuran, atau kombinasi darinya dengan logika validasi kustom. Misalnya, hal ini dapat dilakukan dengan perbandingan nilai checksum antara sumber daya yang dipulihkan dan sumber data pada waktu cadangan dibuat.
1. **Tetapkan RTO dan RPO** untuk memulihkan data berdasarkan kekritisan data. Untuk panduan implementasi, lihat [REL13-BP01 Tetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md).
1. **Nilai kemampuan pemulihan Anda**. Tinjau strategi pencadangan dan pemulihan untuk memahami apakah hal tersebut memenuhi RTO dan RPO, serta sesuaikan strategi yang dibutuhkan. Dengan menggunakan [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html), Anda dapat menjalankan penilaian beban kerja. Penilaian tersebut mengevaluasi konfigurasi aplikasi terhadap kebijakan dan pelaporan ketahanan jika target RTO dan RPO dapat dipenuhi.
1. **Lakukan pemulihan pengujian** dengan menggunakan proses yang ditetapkan saat ini yang digunakan dalam produksi untuk pemulihan data. Proses ini bergantung pada cara sumber data asli dicadangkan, format dan lokasi penyimpanan cadangan tersebut, atau apakah data direproduksi dari sumber lainnya. Contohnya, jika Anda menggunakan layanan terkelola seperti [AWS Backup, hal ini bisa sederhana seperti memulihkan cadangan ke sumber daya baru](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html). Jika Anda menggunakan AWS Elastic Disaster Recovery, Anda dapat [meluncurkan latihan pemulihan](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html).
1. **Validasikan pemulihan data** dari sumber daya yang dipulihkan berdasarkan kriteria yang ditetapkan sebelumnya untuk validasi data. Apakah data yang direstorasi dan dipulihkan memiliki sebagian besar catatan atau item terbaru pada waktu pencadangan? Apakah data ini termasuk dalam RPO untuk beban kerja?
1. **Ukur waktu yang diperlukan** untuk restorasi dan pemulihan dan bandingkan dengan RTO yang telah Anda tetapkan. Apakah data ini termasuk dalam RTO untuk beban kerja? Misalnya, bandingkan stempel waktu dari kapan proses pemulihan dimulai dan kapan validasi pemulihan selesai untuk menghitung waktu yang diperlukan proses ini. Semua panggilan API AWS diberi cap waktu dan informasi ini tersedia di [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Ketika informasi ini dapat menyediakan detail waktu kapan proses pemulihan dimulai, stempel waktu akhir untuk kapan validasi diselesaikan harus dicatat melalui logika validasi. Jika menggunakan proses otomatis, maka layanan seperti [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) dapat digunakan untuk menyimpan informasi ini. Selain itu, banyak layanan AWS yang menyediakan riwayat peristiwa berisi informasi dengan stempel waktu tentang kapan tindakan diambil. Di dalam AWS Backup, tindakan pencadangan dan pemulihan disebut sebagai *tugas*, dan tugas tersebut berisi informasi cap waktu sebagai bagian dari metadata yang dapat digunakan untuk mengukur waktu yang diperlukan untuk restorasi dan pemulihan.
1. **Beri notifikasi kepada para pemangku kepentingan** jika validasi data gagal, atau jika waktu yang diperlukan untuk restorasi dan pemulihan melebihi RTO yang ditetapkan untuk beban kerja. Ketika mengimplementasikan otomatisasi untuk melakukan tindakan ini, [seperti dalam lab ini](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/), layanan seperti Amazon Simple Notification Service (Amazon SNS) dapat digunakan untuk mengirimkan notifikasi push seperti email atau SMS kepada para pemangku kepentingan. [Pesan ini juga dapat dipublikasikan di aplikasi olahpesan seperti Amazon Chime, Slack, atau Microsoft Teams](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) atau digunakan untuk [membuat tugas sebagai OpsItems menggunakan AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html).
1. **Otomatiskan proses ini untuk menjalankannya secara berkala**. Misalnya, layanan seperti AWS Lambda atau State Machine di AWS Step Functions dapat digunakan untuk mengotomatiskan proses pemulihan, dan Amazon EventBridge dapat digunakan untuk memicu alur kerja otomatisasi ini secara berkala seperti yang ditampilkan dalam diagram arsitektur di bawah ini. Pelajar cara untuk [Mengotomatiskan validasi pemulihan data dengan AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/). Selain itu, [Well-Architected lab ini](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) memberikan pengalaman praktik langsung mengenai salah satu cara untuk melakukan otomatisasi untuk beberapa langkah di sini.
![\[Diagram menampilkan proses pencadangan dan pemulihan otomatis\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/automated-backup-restore-process.png)
**Tingkat upaya untuk Rencana Implementasi:** Sedang hingga tinggi, bergantung pada kompleksitas kriteria validasi.
## Sumber daya
**Dokumen terkait:**
+ [Mengotomatiskan validasi pemulihan data dengan AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)
+ [Partner APN: partner yang dapat membantu terkait pencadangan](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: produk yang dapat digunakan untuk pencadangan](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Membuat Aturan EventBridge yang Memicu Berdasarkan Jadwal](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Pemulihan dan pencadangan sesuai permintaan untuk DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html)
+ [Apa Itu AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Apa Itu AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Apa itu AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
**Contoh terkait:**
+ [Well-Architected Lab: Pengujian Pencadangan dan Pemulihan Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL 10. Bagaimana cara menggunakan isolasi kesalahan untuk melindungi beban kerja?
Batas isolasi kesalahan membatasi efek kegagalan di dalam beban kerja hingga jumlah komponen yang terbatas. Komponen di luar batas ini tidak terpengaruh oleh kegagalan tersebut. Menggunakan beberapa batas isolasi kesalahan, Anda dapat membatasi dampak pada beban kerja Anda.
**Topics**
+ [REL10-BP01 Melakukan deployment beban kerja ke beberapa lokasi](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Memilih lokasi yang sesuai untuk deployment multilokasi](rel_fault_isolation_select_location.md)
+ [REL10-BP03 Mengotomatiskan pemulihan untuk komponen yang dibatasi dalam satu lokasi](rel_fault_isolation_single_az_system.md)
+ [REL10-BP04 Menggunakan arsitektur bulkhead untuk membatasi cakupan dampak](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 Melakukan deployment beban kerja ke beberapa lokasi
Distribusikan sumber daya dan data beban kerja ke beberapa Zona Ketersediaan atau, jika diperlukan, ke beberapa Wilayah AWS. Lokasi tersebut dapat beragam sesuai kebutuhan.
Salah satu prinsip dasar untuk desain layanan di AWS adalah menghindari titik kegagalan tunggal dalam infrastruktur fisik yang mendasarinya. Hal ini memotivasi kami untuk membangun sistem dan perangkat lunak yang menggunakan beberapa Zona Ketersediaan dan tahan terhadap kegagalan dari satu zona. Dengan cara yang serupa, sistem dibangun agar tahan terhadap kegagalan dari satu simpul komputasi, satu volume penyimpanan, atau satu instans basis data. Ketika membangun sistem yang mengandalkan komponen redundan, penting untuk memastikan bahwa komponen dapat beroperasi secara independen, dan dalam kasus Wilayah AWS, secara otomatis. Manfaat yang diperoleh dari kalkulasi ketersediaan teoretis dengan komponen redundan hanya valid jika dapat dibuktikan kebenarannya.
**Zona Ketersediaan (AZ)**
Wilayah AWS terdiri atas beberapa Zona Ketersediaan yang dirancang agar menjadi independen satu sama lain. Setiap Zona Ketersediaan dipisahkan oleh jarak fisik yang cukup dari zona lain untuk menghindari skenario kegagalan terkait karena bahaya lingkungan seperti kebakaran, banjir, dan tornado. Setiap Zona Ketersediaan juga memiliki infrastruktur fisik independen: koneksi khusus ke daya utilitas, sumber daya cadangan mandiri, layanan mekanis independen, dan konektivitas jaringan independen di dalam dan di luar Zona Ketersediaan. Desain ini membatasi kesalahan dalam satu sistem hingga hanya satu AZ yang terdampak. Meskipun terpisah secara geografis, Zona Ketersediaan berada di wilayah yang sama yang memungkinkan jaringan dengan latensi rendah dan throughput tinggi. Seluruh Wilayah AWS (di semua Zona Ketersediaan, terdiri atas beberapa pusat data yang independen secara fisik) dapat dibuat menjadi target deployment logika tunggal untuk beban kerja, termasuk kemampuan untuk mereplikasi data secara sinkron (misalnya antarbasis data). Hal ini memungkinkan Anda untuk menggunakan Zona Ketersediaan dalam konfigurasi aktif/aktif atau aktif/siaga.
Zona Ketersediaan bersifat independen, dan oleh karena itu ketersediaan beban kerja meningkat saat beban kerja dirancang untuk menggunakan beberapa zona. Beberapa layanan AWS (termasuk bidang data instans Amazon EC2) di-deploy sebagai layanan zonal yang ketat dan memiliki sifat yang sama dengan Zona Ketersediaan tempatnya berada. Instans Amazon EC2 di AZ lainnya tidak akan terdampak dan tetap berfungsi. Dengan cara yang serupa, jika kesalahan di Zona Ketersediaan menyebabkan basis data Amazon Aurora gagal, instans Aurora replika baca di AZ yang tidak terdampak dapat dipindahkan ke AZ utama secara otomatis. Sebaliknya, layanan AWS regional seperti Amazon DynamoDB secara internal menggunakan beberapa Zona Ketersediaan dalam konfigurasi aktif/aktif guna mencapai tujuan desain ketersediaan untuk layanan tersebut, tanpa perlu mengonfigurasi penempatan AZ.
![\[Diagram yang menampilkan arsitektur multi-tingkat di-deploy di tiga Zona Ketersediaan. Perhatikan bahwa Amazon S3 dan Amazon DynamoDB selalu Multi-AZ secara otomatis. ELB juga di-deploy ke tiga zona.\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/multi-tier-architecture.png)
Ketika umumnya bidang kendali AWS memberikan kemampuan untuk mengelola sumber daya di seluruh Wilayah (beberapa Zona Ketersediaan), bidang kendali tertentu (termasuk Amazon EC2 dan Amazon EBS) memiliki kemampuan untuk memfilter hasil hingga satu Zona Ketersediaan. Saat ini sudah dilakukan, permintaan hanya diproses di Zona Ketersediaan tertentu, mengurangi eksposur gangguan di Zona Ketersediaan lainnya. Contoh AWS CLI ini menggambarkan cara mendapatkan informasi instans Amazon EC2 hanya dari Zona Ketersediaan us-east-2c:
```
AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
```
*AWS Local Zones*
AWS Local Zones bertindak serupa dengan Zona Ketersediaan dalam Wilayah AWS masing-masing sehingga dapat dipilih sebagai lokasi penempatan untuk sumber daya AWS zonal seperti subnet dan instans EC2. Hal yang membuatnya istimewa adalah mereka tidak berada di Wilayah AWS terkait, tetapi dekat dengan populasi yang besar, industri, dan pusat IT ketika tidak ada lagi Wilayah AWS. Namun zona-zona ini tetap mampu mempertahankan bandwidth tinggi, koneksi yang aman di antara beban kerja di zona lokal dan yang dijalankan di Wilayah AWS. Anda harus menggunakan AWS Local Zones untuk melakukan deployment beban kerja secara lebih dekat dengan pengguna untuk persyaratan latensi rendah.
**Amazon Global Edge Network**
Amazon Global Edge Network terdiri atas lokasi edge di kota seluruh dunia. Amazon CloudFront menggunakan jaringan ini untuk mengirimkan konten kepada pengguna akhir dengan latensi lebih rendah. AWS Global Accelerator memungkinkan Anda membuat titik akhir beban kerja di lokasi edge tersebut untuk memberikan onboarding ke jaringan global AWS yang dekat dengan pengguna. Amazon API Gateway memungkinkan titik akhir API yang dioptimasi edge menggunakan distribusi CloudFront agar klien mendapatkan akses melalui lokasi edge terdekat.
*Wilayah AWS*
Wilayah AWS dirancang agar menjadi otonom, akan tetapi, untuk menggunakan pendekatan multi-Wilayah, Anda perlu melakukan deployment salinan layanan yang dikhususkan untuk masing-masing Wilayah.
Pendekatan multi-Wilayah biasa digunakan untuk strategi *pemulihan bencana* yang memenuhi tujuan pemulihan saat satu peristiwa berskala besar terjadi. Lihat [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) untuk informasi lebih lanjut tentang strategi ini. Namun, di sini kami lebih fokus pada *ketersediaan*, yang berupaya memberikan tujuan waktu aktif rata-rata dari waktu ke waktu. Untuk tujuan ketersediaan tinggi, arsitektur multi-wilayah umumnya akan dirancang menjadi aktif/aktif, dengan setiap salinan layanan (di wilayah masing-masing) yang aktif (permintaan layanan).
**Rekomendasi**
Tujuan ketersediaan untuk sebagian besar beban kerja dapat dipenuhi menggunakan strategi Multi-AZ dalam satu Wilayah AWS. Pertimbangkan arsitektur multi-Wilayah hanya saat beban kerja memiliki persyaratan ketersediaan yang sangat tinggi, atau tujuan bisnis lain yang memerlukan arsitektur multi-Wilayah.
AWS memberikan kemampuan untuk mengoperasikan layanan lintas wilayah. Misalnya, AWS menyediakan replikasi data asinkron yang berkelanjutan menggunakan Replikasi Amazon Simple Storage Service (Amazon S3), Replika Baca Amazon RDS (termasuk Replika Baca Aurora), dan Tabel Global Amazon DynamoDB. Dengan replikasi berkelanjutan, versi data tersedia untuk penggunaan segera di setiap Wilayah aktif.
Dengan menggunakan AWS CloudFormation, Anda dapat menentukan infrastruktur dan melakukan deployment secara konsisten di seluruh Akun AWS dan seluruh Wilayah AWS. AWS CloudFormation StackSets meningkatkan fungsionalitas ini dengan memungkinkan Anda untuk membuat, memperbarui, atau menghapus tumpukan AWS CloudFormation di seluruh akun atau wilayah dalam satu kali operasi. Untuk deployment instans Amazon EC2, AMI (Amazon Machine Image) digunakan untuk memasok informasi seperti konfigurasi perangkat keras dan perangkat lunak yang diinstal. Anda dapat mengimplementasikan pipeline Amazon EC2 Image Builder yang membuat AMI yang diperlukan dan menyalinnya ke wilayah aktif. Hal ini memastikan *AMI Emas* memiliki segala yang dibutuhkan untuk melakukan deployment dan menskalakan beban kerja di setiap wilayah baru.
Untuk merutekan lalu lintas, Amazon Route 53 dan AWS Global Accelerator mengaktifkan definisi kebijakan yang menentukan titik akhir wilayah aktif yang dituju pengguna. Dengan Global Accelerator, Anda dapat mengatur panggilan lalu lintas untuk mengontrol persentase lalu lintas yang diarahkan ke setiap titik akhir aplikasi. Route 53 mendukung pendekatan persentase ini, dan juga beberapa kebijakan lain yang tersedia, termasuk kebijakan berdasarkan latensi dan geoproksimitas. Global Accelerator secara otomatis memanfaatkan jaringan server edge AWS yang luas, untuk mengarahkan lalu lintas ke pusat jaringan AWS secepatnya, sehingga menghasilkan latensi permintaan yang lebih rendah.
Semua kemampuan ini dioperasikan untuk menjaga setiap otonomi Wilayah. Ada beberapa pengecualian untuk pendekatan ini, termasuk layanan yang menyediakan pengiriman edge global, (seperti Amazon CloudFront dan Amazon Route 53), serta dengan bidang kendali untuk layanan AWS Identity and Access Management (IAM). Sebagian besar layanan dioperasikan sepenuhnya dalam satu Wilayah.
**Pusat data on-premise**
Rancang pengalaman hybrid jika memungkinkan, untuk beban kerja yang dijalankan di pusat data on-premise. AWS Direct Connect menyediakan koneksi jaringan khusus dari premise Anda ke AWS sehingga Anda dapat menjalankan beban kerja di kedua sistem.
Opsi lainnya adalah menjalankan layanan dan infrastruktur AWS on-premise dengan menggunakan AWS Outposts. AWS Outposts adalah layanan terkelola penuh yang memperluas infrastruktur AWS, layanan AWS, API, dan alat untuk pusat data. Infrastruktur perangkat keras yang sama yang digunakan di AWS Cloud juga diinstal di pusat data. Selanjutnya, AWS Outposts dihubungkan ke Wilayah AWS yang terdekat. Anda dapat menggunakan AWS Outposts untuk mendukung beban kerja yang memiliki latensi rendah atau persyaratan pemrosesan data lokal.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Gunakan beberapa Zona Ketersediaan dan Wilayah AWS. Distribusikan sumber daya dan data beban kerja ke beberapa Zona Ketersediaan atau, jika diperlukan, ke beberapa Wilayah AWS. Lokasi tersebut dapat beragam sesuai kebutuhan.
+ Layanan regional di-deploy secara permanen di seluruh Zona Ketersediaan.
+ Ini termasuk Amazon S3, Amazon DynamoDB, dan AWS Lambda (saat tidak terhubung ke VPC)
+ Lakukan deployment kontainer, instans, dan beban kerja berdasarkan fungsi ke dalam beberapa Zona Ketersediaan. Gunakan penyimpanan data multi-zona, termasuk cache. Gunakan fitur EC2 Auto Scaling, penempatan tugas ECS, dan konfigurasi fungsi AWS Lambda saat menjalankan VPC dan klaster ElastiCache.
+ Gunakan subnet yang berada di Zona Ketersediaan terpisah saat melakukan deployment grup Auto Scaling.
+ [Misalnya: Mendistribusikan instans di seluruh Zona Ketersediaan](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Strategi penempatan tugas Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Mengonfigurasi fungsi AWS Lambda untuk mengakses sumber daya di Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ [Memilih Zona Ketersediaan dan Wilayah](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Gunakan subnet di Zona Ketersediaan terpisah saat melakukan deployment grup Auto Scaling.
+ [Misalnya: Mendistribusikan instans di seluruh Zona Ketersediaan](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ Gunakan parameter penempatan tugas ECS, yang menentukan grup subnet DB.
+ [Strategi penempatan tugas Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ Gunakan subnet di beberapa Zona Ketersediaan saat mengonfigurasi fungsi untuk dijalankan di VPC.
+ [Mengonfigurasi fungsi AWS Lambda untuk mengakses sumber daya di Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ Gunakan beberapa Zona Ketersediaan dengan klaster ElastiCache.
+ [Memilih Zona Ketersediaan dan Wilayah](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Jika beban kerja harus di-deploy di beberapa Wilayah, pilih strategi multi-Wilayah. Sebagian besar kebutuhan keandalan dapat dipenuhi dalam satu Wilayah AWS menggunakan strategi multi-Zona Ketersediaan. Gunakan strategi multi-Wilayah jika diperlukan untuk memenuhi kebutuhan bisnis.
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ Mencadangkan ke Wilayah AWS lain dapat menambah lapisan jaminan lain bahwa data akan tersedia saat dibutuhkan.
+ Beberapa beban kerja memiliki persyaratan regulasi yang memerlukan penggunaan strategi multi-Wilayah.
+ Evaluasi AWS Outposts untuk beban kerja. Jika beban kerja memerlukan latensi rendah ke pusat data on-premise atau memiliki persyaratan pemrosesan data lokal. Jalankan layanan dan infrastruktur AWS on premise menggunakan AWS Outposts
+ [Apa itu AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
+ Tentukan apakah AWS Local Zones membantu menyediakan layanan untuk pengguna. Jika Anda memiliki persyaratan latensi rendah, periksa apakah AWS Local Zones berada dekat dengan pengguna. Jika iya, manfaatkan hal tersebut untuk melakukan deployment beban kerja dengan lebih dekat ke pengguna tersebut.
+ [Pertanyaan Umum AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
## Sumber daya
**Dokumen terkait:**
+ [Infrastruktur Global AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [Pertanyaan Umum AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Strategi penempatan tugas Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Memilih Zona Ketersediaan dan Wilayah](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ [Misalnya: Mendistribusikan instans di seluruh Zona Ketersediaan](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Tabel Global: Replikasi Multi-Wilayah dengan DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Menggunakan basis data Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [Membuat Aplikasi Multi-Wilayah dengan seri blog Layanan AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [Apa itu AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
**Video terkait:**
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Inovasi dan operasi infrastruktur jaringan global AWS (NET339)](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 Memilih lokasi yang sesuai untuk deployment multilokasi
## Hasil yang diinginkan:
Untuk ketersediaan tinggi, selalu (jika memungkinkan) lakukan deployment komponen beban kerja ke beberapa Zona Ketersediaan (AZ), seperti yang ditampilkan dalam Gambar 10. Untuk beban kerja dengan persyaratan ketahanan yang sangat tinggi, evaluasikan dengan cermat opsi untuk arsitektur multi-Wilayah.
![\[Diagram yang menampilkan deployment basis data multi-AZ yang tangguh dengan pencadangan ke Wilayah AWS lainnya\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/multi-az-architecture.png)
## Antipola umum:
+ Memilih untuk merancang arsitektur multi-Wilayah saat arsitektur multi-AZ dapat memenuhi persyaratan.
+ Tidak memperhitungkan dependensi antarkomponen aplikasi jika ketahanan dan persyaratan multilokasi antarkomponen tersebut berbeda.
## Manfaat menerapkan praktik terbaik ini:
Untuk ketahanan, Anda harus menggunakan pendekatan yang membangun lapisan pertahanan. Satu lapisan melindungi terhadap gangguan yang lebih kecil dan lebih umum dengan membangun arsitektur yang memiliki ketersediaan tinggi menggunakan beberapa AZ. Lapisan pertahanan lainnya ditujukan untuk memberikan perlindungan terhadap peristiwa langka seperti bencana alam yang meluas dan gangguan tingkat Wilayah. Lapisan kedua ini melibatkan perancangan aplikasi agar menjangkau beberapa Wilayah AWS.
+ Perbedaan antara ketersediaan 99,5% dan ketersediaan 99,99% adalah lebih dari 3,5 jam per bulan. Ketersediaan beban kerja yang diharapkan hanya dapat mencapai “empat angka sembilan” jika berada dalam beberapa AZ.
+ Dengan menjalankan beban kerja di beberapa AZ, Anda dapat mengisolasi kesalahan dalam daya, pendinginan, dan jaringan, serta sebagian besar bencana alam seperti kebakaran dan banjir.
+ Mengimplementasikan strategi multi-Wilayah untuk beban kerja membantu melindunginya dari bencana alam yang menjangkau dan memengaruhi wilayah geografis yang luas di suatu negara, atau kesalahan teknis yang mencakup seluruh Wilayah. Perhatikan bahwa mengimplementasikan arsitektur multi-Wilayah dapat menjadi sangat kompleks, dan biasanya tidak diperlukan untuk sebagian besar beban kerja.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Untuk peristiwa bencana yang didasarkan pada gangguan atau hilangnya sebagian dari satu Zona Ketersediaan, mengimplementasikan beban kerja yang memiliki ketersediaan tinggi di beberapa Zona Ketersediaan dalam satu Wilayah AWS dapat membantu mitigasi bencana alam dan teknis. Setiap Wilayah AWS terdiri atas beberapa Zona Ketersediaan, masing-masing diisolasi dari kesalahan di zona lain dan dipisahkan oleh jarak yang cukup. Namun, untuk peristiwa bencana yang menyertakan risiko hilangnya beberapa komponen Zona Ketersediaan, yang jaraknya cukup jauh satu sama lain, Anda harus mengimplementasikan opsi pemulihan bencana untuk memitigasi kesalahan dalam cakupan Wilayah. Untuk beban kerja yang memerlukan ketahanan sangat tinggi (infrastruktur yang sangat penting, aplikasi terkait kesehatan, infrastruktur sistem keuangan, dll.), strategi multi-Wilayah mungkin diperlukan.
## Langkah Implementasi
1. Evaluasikan beban kerja dan tentukan apakah ketahanan yang diperlukan dapat dipenuhi oleh pendekatan multi-AZ (satu Wilayah AWS), atau apakah pendekatan multi-Wilayah diperlukan. Mengimplementasikan arsitektur multi-Wilayah untuk memenuhi persyaratan tersebut akan menimbulkan kompleksitas tambahan, dengan demikian pertimbangkan secara cermat kasus penggunaan Anda dan persyaratannya. Persyaratan ketahanan dapat hampir selalu dipenuhi menggunakan satu Wilayah AWS. Pertimbangkan persyaratan yang memungkinkan berikut saat menentukan apakah Anda perlu menggunakan beberapa Wilayah:
1. **Pemulihan Bencana (DR)**: Untuk peristiwa bencana yang didasarkan pada gangguan atau kehilangan sebagian dari satu Zona Ketersediaan, mengimplementasikan beban kerja yang memiliki ketersediaan tinggi di beberapa Zona Ketersediaan dalam satu Wilayah AWS dapat membantu mitigasi bencana alam dan teknis. Untuk peristiwa bencana yang menyertakan risiko kehilangan beberapa komponen Zona Ketersediaan, yang jaraknya cukup jauh satu sama lain, Anda harus mengimplementasikan pemulihan bencana di seluruh Wilayah untuk memitigasi bencana alam atau kesalahan teknis dalam cakupan Wilayah.
1. **Ketersediaan tinggi (HA)**: Arsitektur multi-Wilayah (menggunakan beberapa AZ di setiap Wilayah) dapat digunakan untuk mencapai ketersediaan yang lebih tinggi dari empat angka 9 (> 99,99%).
1. **Pelokalan tumpukan**: Saat melakukan deployment beban kerja ke audiens global, Anda dapat melakukan deployment tumpukan yang dilokalkan di Wilayah AWS yang berbeda untuk melayani audiens di Wilayah tersebut. Pelokalan dapat mencakup bahasa, mata uang, dan jenis data yang disimpan.
1. **Proksimitas kepada pengguna:** Saat melakukan deployment beban kerja ke audiens global, Anda dapat mengurangi latensi dengan melakukan deployment tumpukan di Wilayah AWS yang dekat dengan tempat pengguna akhir.
1. **Residensi data**: Beberapa beban kerja bergantung pada persyaratan residensi data, ketika data dari pengguna tertentu harus tetap berada dalam batasan negara tertentu. Berdasarkan regulasi dalam pertanyaan, Anda dapat memilih untuk melakukan deployment seluruh tumpukan, atau datanya saja, ke Wilayah AWS dalam batas tersebut.
1. Berikut beberapa contoh fungsionalitas multi-AZ yang disediakan oleh layanan AWS:
1. Untuk melindungi beban kerja menggunakan EC2 atau ECS, lakukan deployment Elastic Load Balancer di depan sumber daya komputasi. Selanjutnya, Elastic Load Balancing menyediakan solusi untuk mendeteksi instans di zona yang kondisinya tidak baik dan merutekan lalu lintas ke zona yang kondisinya baik.
1. [Mulai menggunakan Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html)
1. [Mulai menggunakan Penyeimbang Beban Jaringan](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html)
1. Dalam kasus instans EC2 yang menjalankan perangkat lunak komersial siap pakai yang tidak mendukung penyeimbangan beban, Anda dapat mencapai bentuk toleransi kesalahan dengan mengimplementasikan metodologi pemulihan bencana multi-AZ.
1. [REL13-BP02 Menggunakan strategi pemulihan yang ditentukan untuk memenuhi sasaran pemulihan](rel_planning_for_recovery_disaster_recovery.md)
1. Untuk tugas Amazon ECS, lakukan deployment secara merata di tiga AZ untuk mencapai keseimbangan ketersediaan dan biaya.
1. [Praktik terbaik ketersediaan Amazon ECS \$1 Kontainer](https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/)
1. Untuk non-Aurora Amazon RDS, Anda dapat memilih Multi-AZ sebagai opsi konfigurasi. Saat instans basis data utama mengalami kegagalan, Amazon RDS secara otomatis mendorong basis data standby untuk menerima lalu lintas di zona ketersediaan lainnya. Replika baca multi-Wilayah juga dapat dibuat untuk meningkatkan ketahanan.
1. [Deployment Multi AZ Amazon RDS](https://aws.amazon.com/rds/features/multi-az/)
1. [Membuat replika baca di Wilayah AWS yang berbeda](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html)
1. Berikut beberapa contoh fungsionalitas multi-Wilayah yang disediakan oleh layanan AWS:
1. Untuk beban kerja Amazon S3, ketika ketersediaan multi-AZ disediakan secara otomatis oleh layanan, pertimbangkan Poin Akses Multi-Wilayah jika deployment multi-Wilayah diperlukan.
1. [Poin Akses Multi-Wilayah di Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html)
1. Untuk tabel DynamoDB, ketika ketersediaan multi-AZ disediakan secara otomatis oleh layanan, Anda dapat mengonversi tabel yang ada ke tabel global dengan mudah untuk memperoleh manfaat dari beberapa wilayah.
1. [Konversi Tabel Amazon DynamoDB Wilayah Tunggal menjadi Tabel Global](https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/)
1. Jika beban kerja didahului oleh Application Load Balancers atau Penyeimbang Beban Jaringan, gunakan AWS Global Accelerator untuk meningkatkan ketersediaan aplikasi dengan mengarahkan lalu lintas ke beberapa wilayah yang memiliki titik akhir dengan kondisi baik.
1. [Titik akhir untuk akselerator standar di AWS Global Accelerator - AWS Global Accelerator (amazon.com)](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoints.html)
1. Untuk aplikasi yang memanfaatkan AWS EventBridge, pertimbangkan bus lintas Wilayah untuk meneruskan peristiwa ke Wilayah lain yang dipilih.
1. [Mengirim dan menerima peristiwa Amazon EventBridge di antara beberapa Wilayah AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
1. Untuk basis data Amazon Aurora, pertimbangkan basis data global Aurora, yang menjangkau beberapa wilayah AWS. Klaster yang sudah ada juga dapat diubah untuk menambahkan Wilayah baru.
1. [Mulai menggunakan basis data global Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html)
1. Jika beban kerja mencakup kunci enkripsi AWS Key Management Service (AWS KMS), pertimbangkan apakah kunci multi-Wilayah sesuai untuk aplikasi.
1. [Kunci Multi-Wilayah di AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
1. Untuk fitur layanan AWS lainnya, lihat seri blog ini di [Seri Membuat Aplikasi Multi-Wilayah dengan Layanan AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
**Tingkat upaya untuk Rencana Implementasi: **Sedang hingga Tinggi
## Sumber daya
**Dokumen terkait:**
+ [Seri Membuat Aplikasi Multi-Wilayah dengan Layanan AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian IV: Multi-situs Aktif/Aktif)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)
+ [Infrastruktur Global AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [Pertanyaan Umum AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian I: Strategi untuk Pemulihan di Cloud](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [Pemulihan bencana di cloud tidak sama dengan biasanya](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-is-different-in-the-cloud.html)
+ [Tabel Global: Replikasi Multi-Wilayah dengan DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
**Video terkait: **
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Auth0: Arsitektur Ketersediaan Tinggi Multi-Wilayah yang Menskalakan hingga 1,5B\$1 Login Sebulan dengan failover otomatis](https://www.youtube.com/watch?v=vGywoYc_sA8)
**Contoh terkait:**
+ [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian I: Strategi untuk Pemulihan di Cloud](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [DTCC mencapai ketangguhan yang lebih tinggi dari yang dapat dilakukan di on-premise](https://aws.amazon.com/solutions/case-studies/DTCC/)
+ [Expedia Group menggunakan arsitektur multi-Wilayah dan multi-Zona Ketersediaan dengan layanan DNS eksklusif untuk menambah ketangguhan pada aplikasi ](https://aws.amazon.com/solutions/case-studies/expedia/)
+ [Uber: Pemulihan Bencana untuk Kafka Multi-Wilayah](https://eng.uber.com/kafka/)
+ [Netflix: Aktif-Aktif untuk Ketahanan Multi-Wilayah](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b)
+ [Cara kami membangun Residensi Data untuk Atlassian Cloud](https://www.atlassian.com/engineering/how-we-build-data-residency-for-atlassian-cloud)
+ [Intuit TurboTax dijalankan di dua Wilayah](https://www.youtube.com/watch?v=286XyWx5xdQ)
# REL10-BP03 Mengotomatiskan pemulihan untuk komponen yang dibatasi dalam satu lokasi
Jika komponen beban kerja hanya dapat dijalankan di satu Zona Ketersediaan atau di pusat data on-premise, implementasikan kemampuan untuk membangun kembali beban kerja sepenuhnya dalam lingkup tujuan pemulihan yang telah ditetapkan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Jika praktik terbaik untuk melakukan deployment beban kerja ke beberapa lokasi tidak memungkinkan karena pembatasan teknologi, Anda harus mengimplementasikan jalur alternatif menuju ketahanan. Anda harus mengotomatiskan kemampuan untuk membuat ulang infrastruktur yang dibutuhkan, melakukan deployment ulang aplikasi, dan membuat ulang data yang diperlukan untuk kasus ini.
Misalnya, Amazon EMR meluncurkan semua simpul untuk klaster tertentu yang tersedia dalam Zona Ketersediaan yang sama karena menjalankan klaster di zona yang sama dapat meningkatkan kinerja aliran tugas berkat tingkat akses data yang lebih tinggi. Jika komponen ini tidak dibutuhkan untuk ketahanan beban kerja, Anda harus mencari cara lain untuk melakukan deployment klaster dan datanya. Selain itu, untuk Amazon EMR, Anda harus menyediakan redundansi selain dengan menggunakan Multi-AZ. Anda dapat menyediakan [beberapa simpul](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html). Dengan menggunakan [Sistem File EMR (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html), data di EMR dapat dipulihkan di Amazon S3, yang kemudian dapat direplikasi di beberapa Zona Ketersediaan atau Wilayah AWS.
Dengan cara yang serupa, Amazon Redshift secara default menyediakan klaster dalam Zona Ketersediaan yang dipilih secara acak dalam Wilayah AWS yang Anda pilih. Semua simpul klaster disediakan dalam zona yang sama.
Untuk beban kerja stateful berbasis server yang di-deploy ke pusat data on-premise, Anda dapat menggunakan AWS Elastic Disaster Recovery untuk melindungi beban kerja Anda di AWS. Jika Anda sudah di-host di AWS, Anda dapat menggunakan Elastic Disaster Recovery untuk melindungi beban kerja Anda di Wilayah atau Zona Ketersediaan alternatif. Elastic Disaster Recovery menggunakan replikasi tingkat blok secara berkelanjutan ke area staging ringan untuk memberikan pemulihan aplikasi on-premise dan aplikasi berbasis cloud secara cepat dan andal.
**Langkah implementasi**
1. Implementasikan pemulihan mandiri. Lakukan deployment instans atau kontainer dengan menggunakan penskalaan otomatis jika memungkinkan. Jika penskalaan otomatis tidak dapat digunakan, gunakan pemulihan otomatis untuk instans EC2 atau implementasikan otomatisasi pemulihan mandiri berdasarkan Amazon EC2 atau peristiwa siklus hidup kontainer ECS.
+ Gunakan [grup Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) untuk instans atau beban kerja kontainer yang tidak memiliki persyaratan untuk alamat IP instans tunggal, alamat IP pribadi, alamat IP Elastis, dan metadata instans.
+ Data pengguna templat peluncuran dapat digunakan untuk mengimplementasikan otomatisasi yang dapat memulihkan sebagian besar beban kerja secara mandiri.
+ Gunakan [pemulihan otomatis instans Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)untuk beban kerja yang memerlukan instans tunggal alamat ID, alamat IP pribadi, alamat IP elastis, dan instans metadata.
+ Pemulihan Otomatis akan mengirimkan peringatan status pemulihan kepada topik SNS saat kegagalan instans terdeteksi.
+ Gunakan [peristiwa siklus hidup instans Amazon EC2](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) atau [peristiwa Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) untuk mengotomatiskan pemulihan mandiri jika penskalaan otomatis atau pemulihan EC2 tidak dapat digunakan.
+ Gunakan peristiwa untuk memicu otomatisasi yang akan memulihkan komponen Anda berdasarkan proses logika yang diperlukan.
+ Lindungi beban kerja stateful yang dibatasi di satu lokasi menggunakan [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html).
## Sumber daya
**Dokumen terkait:**
+ [Peristiwa Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [Pengait siklus hidup Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Pulihkan instans Anda.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Penskalaan otomatis layanan](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [Apa Itu Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
# REL10-BP04 Menggunakan arsitektur bulkhead untuk membatasi cakupan dampak
Implementasikan arsitektur bulkhead (juga disebut sebagai arsitektur berbasis sel) untuk membatasi efek kegagalan dalam beban kerja hingga jumlah komponen yang terbatas.
**Hasil yang diinginkan:** Arsitektur berbasis sel menggunakan beberapa instans terisolasi beban kerja, di mana setiap instans disebut sebagai sel. Setiap sel bersifat mandiri, tidak berbagi status dengan sel lain, dan menangani subset permintaan beban kerja secara keseluruhan. Hal ini mengurangi potensi dampak kegagalan, seperti pembaruan perangkat lunak yang buruk, ke satu sel individu dan permintaan yang diprosesnya. Jika beban kerja menggunakan 10 sel untuk melayani 100 permintaan, ketika kegagalan terjadi, 90% dari seluruh permintaan akan tidak dipengaruhi oleh kegagalan.
**Antipola umum:**
+ Membiarkan sel bertumbuh tanpa batas.
+ Menerapkan pembaruan kode atau deployment ke semua sel pada waktu yang sama.
+ Berbagi status atau komponen antara sel (dengan pengecualian lapisan router).
+ Menambahkan bisnis yang kompleks atau mengarahkan rute logika ke lapisan router.
+ Tidak meminimalkan interaksi lintas sel.
**Manfaat menjalankan praktik terbaik ini:** Dengan arsitektur berbasis sel, banyak jenis kegagalan umum dibatasi dalam lingkup sel itu sendiri, yang memberikan isolasi kesalahan tambahan. Batas kesalahan ini dapat memberikan ketangguhan terhadap jenis kegagalan yang sulit dibatasi, seperti deployment kode yang gagal atau permintaan yang rusak atau memicu mode kegagalan tertentu (juga disebut sebagai *permintaan poison pill*).
## Panduan implementasi
Di kapal, bulkhead memastikan kebocoran lambung kapal hanya dibatasi dalam satu bagian lambung kapal saja. Di sistem yang kompleks, pola ini sering kali direplikasi untuk memungkinkan isolasi kesalahan. Batas isolasi kesalahan membatasi efek kegagalan di dalam beban kerja hingga jumlah komponen yang terbatas. Komponen di luar batas ini tidak terpengaruh oleh kegagalan tersebut. Menggunakan beberapa batas isolasi kesalahan, Anda dapat membatasi dampak pada beban kerja Anda. Di AWS, pelanggan dapat menggunakan beberapa Zona Ketersediaan dan Wilayah untuk memberikan isolasi kesalahan, tetapi konsep isolasi kesalahan dapat diperluas ke arsitektur beban kerja juga.
Beban kerja secara keseluruhan adalah sel-sel yang dipartisi oleh kunci partisi. Kunci ini harus sesuai dengan *grain* layanan, atau cara alami beban kerja layanan dapat dibagi lebih lanjut dengan interaksi lintas sel yang minim. Contoh kunci partisi yakni ID pelanggan, ID sumber daya, atau parameter lainnya yang dapat diakses dengan mudah dalam sebagian besar panggilan API. Lapisan perutean sel mendistribusikan permintaan ke masing-masing sel berdasarkan kunci partisi dan menyampaikan satu titik akhir ke klien.
![\[Diagram menampilkan Arsitektur berbasis sel\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/cell-based-architecture.png)
**Langkah implementasi**
Ketika mendesain arsitektur berbasis sel, ada beberapa pertimbangan desain untuk dipikirkan:
1. **Kunci partisi**: Pemilihan kunci partisi harus dipertimbangkan baik-baik.
+ Kunci ini harus sesuai dengan grain layanan, atau cara alami beban kerja layanan dapat dibagi lebih lanjut dengan interaksi lintas sel yang minim. Contohnya, `ID pelanggan` atau `ID sumber daya`.
+ Kunci partisi harus tersedia dalam semua permintaan, baik secara langsung atau dengan cara yang dapat disimpulkan dengan pasti dan mudah oleh parameter lain.
1. **Pemetaan sel persisten**: Layanan sebelumnya dalam proses hanya boleh berinteraksi dengan satu sel selama siklus hidup sumber dayanya.
+ Bergantung pada beban kerjanya, strategi migrasi sel mungkin diperlukan untuk memigrasikan data dari satu sel ke yang lain. Kemungkinan skenario ketika migrasi sel mungkin diperlukan yakni jika sumber daya atau pengguna tertentu di beban kerja Anda menjadi terlalu besar dan memerlukan sel khusus.
+ Sel tidak boleh berbagi status atau komponen antara sel.
+ Oleh karena itu, interaksi lintas sel harus dihindari atau dijaga agar tetap minim, karena interaksi tersebut menimbulkan dependensi antara sel, sehingga mengurangi peningkatan isolasi kesalahan.
1. **Lapisan router**: Lapisan router adalah komponen bersama antara sel, oleh karena itu tidak dapat mengikuti strategi kompartementalisasi yang sama seperti sel.
+ Sebaiknya lapisan router mendistribusikan permintaan ke sel secara individu menggunakan algoritme pemetaan partisi dengan cara yang efisien secara komputasi, seperti menggabungkan fungsi hash kriptografi dan aritmetika modul untuk memetakan kunci partisi ke sel.
+ Untuk menghindari dampak multi-sel, lapisan perutean harus tetap sesederhana mungkin dan dapat diskalakan sehorizontal mungkin, yang memerlukan penghindaran logika bisnis kompleks di dalam lapisan ini. Hal ini memiliki manfaat tambahan mempermudah pemahaman ekspektasi perilakunya di setiap waktu, yang memberikan kemampuan untuk diuji secara menyeluruh. Sebagaimana dijelaskan oleh Colm MacCárthaigh dalam [Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/), desain sederhana dan pola kerja konstan menghasilkan sistem yang andal dan mengurangi anti-kerentanan.
1. **Ukuran sel**: Sel harus memiliki ukuran maksimum dan tidak boleh diizinkan untuk bertumbuh melampauinya.
+ Ukuran maksimum harus diidentifikasi dengan melakukan pengujian yang menyeluruh, sampai titik rusak tercapai dan margin pengoperasian yang aman ditetapkan. Untuk detail selengkapnya tentang cara mengimplementasikan praktik pengujian, lihat [REL07-BP04 Menguji beban untuk beban kerja Anda](rel_adapt_to_changes_load_tested_adapt.md)
+ Beban kerja secara keseluruhan harus bertumbuh dengan menambahkan sel tambahan, sehingga beban kerja dapat diskalakan seiring peningkatan permintaan.
1. **Strategi Multi-AZ atau Multi-Wilayah**: Beberapa lapisan ketangguhan harus dimanfaatkan untuk melindungi dari berbagai macam domain kegagalan.
+ Untuk ketahanan, Anda harus menggunakan pendekatan yang membangun lapisan pertahanan. Satu lapisan melindungi dari gangguan yang lebih kecil dan lebih umum dengan membangun arsitektur yang memiliki ketersediaan tinggi menggunakan beberapa AZ. Lapisan pertahanan lainnya ditujukan untuk memberikan perlindungan terhadap peristiwa langka seperti bencana alam yang meluas dan gangguan tingkat Wilayah. Lapisan kedua ini melibatkan perancangan aplikasi agar menjangkau beberapa Wilayah AWS. Mengimplementasikan strategi multi-Wilayah untuk beban kerja membantu melindunginya dari bencana alam yang menjangkau dan memengaruhi wilayah geografis yang luas di suatu negara, atau kesalahan teknis yang mencakup seluruh Wilayah. Perhatikan bahwa mengimplementasikan arsitektur multi-Wilayah dapat menjadi sangat kompleks, dan biasanya tidak diperlukan untuk sebagian besar beban kerja. untuk detail selengkapnya, lihat [REL10-BP02 Memilih lokasi yang sesuai untuk deployment multilokasi](rel_fault_isolation_select_location.md).
1. **Deployment kode**: Strategi deployment kode bergiliran harus didahulukan dibandingkan deployment perubahan kode ke semua sel pada waktu yang sama.
+ Hal ini akan membantu meminimalkan potensi kegagalan pada beberapa sel karena deployment yang buruk atau kesalahan manusia. Untuk detail selengkapnya, lihat [Mengotomatiskan deployment aman tanpa campur tangan](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/).
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Sumber daya
**Praktik Terbaik Terkait:**
+ [REL07-BP04 Menguji beban untuk beban kerja Anda](rel_adapt_to_changes_load_tested_adapt.md)
+ [REL10-BP02 Memilih lokasi yang sesuai untuk deployment multilokasi](rel_fault_isolation_select_location.md)
**Dokumen terkait:**
+ [Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS dan Kompartementalisasi ](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/)
+ [ Isolasi beban kerja menggunakan shuffle-sharding ](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+ [Mengotomatiskan deployment aman tanpa campur tangan](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
**Video terkait:**
+ [AWS re:Invent 2018: Menutup Lingkaran dan Membuka Pikiran: Cara Mengendalikan Sistem, Besar dan Kecil ](https://www.youtube.com/watch?v=O8xLxNje30M)
+ [AWS re:Invent 2018: Cara AWS Meminimalkan Radius Dampak Kegagalan (ARC338)](https://youtu.be/swQbA4zub20)
+ [Shuffle-sharding: AWS re:Invent 2019: Memperkenalkan Pustaka Pengembang Amazon (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS Summit ANZ 2021 - Segala sesuatu gagal, setiap waktu: Mendesain agar memiliki ketangguhan ](https://www.youtube.com/watch?v=wUzSeSfu1XA)
**Contoh terkait:**
+ [Well-Architected Lab - Isolasi kesalahan dengan shuffle sharding](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
# REL 11. Bagaimana Anda mendesain beban kerja agar dapat bertahan jika terjadi 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 Mengandalkan bidang data dan bukan bidang kendali selama pemulihan](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 Menggunakan 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-BP07 Merancang produk Anda agar memenuhi target ketersediaan dan perjanjian tingkat layanan (SLA) waktu aktif](rel_withstand_component_failures_service_level_agreements.md)
# REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan
Terus pantau kondisi beban kerja agar Anda dan sistem otomatis Anda langsung mengetahui penurunan kualitas atau kegagalan ketika 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.
**Hasil yang diinginkan:** Komponen penting dari suatu beban kerja dipantau secara independen untuk mendeteksi dan memperingatkan adanya kegagalan pada saat dan di bagian mana kegagalan tersebut terjadi.
**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 antarmuka beban kerja yang terlihat oleh pelanggan yang aktif dipantau.
+ Hanya mengumpulkan metrik teknis, dan mengabaikan metrik fungsi bisnis.
+ Tidak ada metrik yang mengukur pengalaman pengguna beban kerja.
+ Terlalu banyak pemantau yang dibuat.
**Manfaat menjalankan praktik terbaik ini:** Pemantauan yang sesuai di semua lapisan memungkinkan Anda menghemat waktu pemulihan karena berkurangnya waktu deteksi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Identifikasikan semua beban kerja yang akan ditinjau untuk pemantauan. Setelah Anda mengidentifikasi semua komponen beban kerja yang perlu dipantau, selanjutnya Anda perlu menentukan interval pemantauan. Interval pemantauan akan berdampak langsung pada seberapa cepat pemulihan dapat dimulai berdasarkan waktu yang diperlukan untuk mendeteksi kegagalan. Rata-rata waktu deteksi (MTTD) adalah lamanya waktu antara terjadinya kegagalan dan ketika operasi perbaikan dimulai. Daftar layanan harus luas dan lengkap.
Pemantauan harus mencakup semua lapisan tumpukan aplikasi termasuk aplikasi, platform, infrastruktur, dan jaringan.
Strategi pemantauan Anda harus mempertimbangkan dampak *kegagalan abu-abu*. Untuk detail lebih lanjut tentang kegagalan abu-abu, lihat [ Kegagalan abu-abu](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) di laporan resmi Pola Ketangguhan Multi-AZ Lanjutan.
### Langkah implementasi
+ 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 dan layanan terkelola.
+ Tentukan apakah [pemantauan mendetail untuk instans EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) dan [Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) diperlukan. Pemantauan mendetail menyediakan metrik interval satu menit, sedangkan pemantauan default menyediakan metrik interval lima menit.
+ Tentukan apakah [pemantauan yang ditingkatkan](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) untuk RDS diperlukan. Pemantauan yang ditingkatkan menggunakan agen di instans RDS untuk memperoleh informasi bermanfaat tentang berbagai alur atau proses.
+ Tentukan persyaratan pemantauan komponen nirserver penting untuk [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html), [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring_automated_manual.html), [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html), [Amazon ECS](https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ecs), dan semua jenis [penyeimbang beban](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html).
+ Tentukan persyaratan pemantauan komponen penyimpanan untuk [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html), [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring_overview.html), [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/monitoring_overview.html), dan [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html).
+ Buat [metrik kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) untuk mengukur indikator kinerja kunci (KPI) bisnis. Beban kerja mengimplementasikan fungsi-fungsi bisnis utama, yang harus digunakan sebagai KPI yang membantu mengidentifikasi kapan terjadinya masalah tidak langsung.
+ Pantau pengalaman pengguna untuk mendeteksi kegagalan menggunakan canary pengguna. [Pengujian transaksi sintetis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (juga disebut pengujian canary, tetapi tidak sama 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.
+ Buat [metrik kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) yang melacak pengalaman pengguna. Jika Anda dapat menginstrumentasi pengalaman pelanggan, Anda dapat menentukan saat pengalaman pelanggan mengalami degradasi.
+ [Atur alarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) untuk mendeteksi saat ada bagian dari beban kerja Anda yang tidak berfungsi dengan baik, dan untuk menunjukkan kapan harus menskalakan sumber daya secara otomatis. Alarm dapat ditampilkan secara visual di dasbor, mengirimkan peringatan melalui Amazon SNS atau email, dan menggunakan Auto Scaling untuk menaikkan atau menurunkan skala sumber daya beban kerja.
+ Buat [dasbor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) untuk memvisualisasikan metrik Anda. Dasbor dapat digunakan untuk melihat tren, penyimpangan, dan indikator potensi masalah lainnya, atau menyediakan penanda untuk masalah yang ingin Anda selidiki.
+ Buat [pemantauan penelusuran terdistribusi](https://aws.amazon.com/xray/faqs/) untuk layanan Anda. Dengan pemantauan terdistribusi, Anda dapat memahami cara kerja aplikasi Anda dan layanan dasar dalam mengidentifikasi dan memecahkan akar masalah dan galat kinerja.
+ Buat dasbor sistem pemantauan (menggunakan [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) atau [X-Ray](https://aws.amazon.com/xray/faqs/)) dan pengumpulan data di Wilayah dan akun terpisah.
+ Buat integrasi untuk pemantauan [Amazon Health Aware](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) untuk memungkinkan visibilitas pemantauan ke sumber daya AWS yang mungkin mengalami degradasi. Untuk beban kerja yang penting untuk bisnis, solusi ini menyediakan akses ke peringatan proaktif dan waktu nyata untuk layanan AWS.
## Sumber daya
**Praktik terbaik terkait:**
+ [Definisi Ketersediaan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP06 Mengirimkan Notifikasi ketika peristiwa memengaruhi ketersediaan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**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 dan Instans Auto Scaling 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)
+ [Menggunakan Dasbor CloudWatch Lintas Akun dan Lintas Wilayah](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html)
+ [Menggunakan Penelusuran X-Ray Lintas Akun dan Lintas Wilayah](https://aws.amazon.com/xray/faqs/)
+ [Memahami ketersediaan](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html)
+ [Mengimplementasikan Amazon Health Aware (AHA)](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/)
**Video terkait:**
+ [Memitigasi kegagalan abu-abu](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.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)
+ [Lokakarya One Observability: Menjelajahi X-Ray](https://catalog.workshops.aws/observability/en-US/aws-native/xray/explore-xray)
**Alat terkait:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# 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](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) dan [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html), 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:**
+ [REL13 - Merencanakan DR](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html)
+ [REL10 - Menggunakan isolasi kesalahan untuk melindungi beban kerja Anda](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)
**Dokumen terkait:**
+ [Menetapkan Target RTO dan RPO](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/)
+ [Menyiapkan ARC dengan penyeimbang beban aplikasi](https://www.wellarchitectedlabs.com/reliability/disaster-recovery/workshop_5/)
+ [Failover menggunakan perutean Tertimbang Route 53](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)
+ [DR dengan ARC](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)
+ [EC2 dengan penskalaan otomatis](https://github.com/adriaanbd/aws-asg-ecs-starter)
+ [Deployment EC2 - Multi-AZ](https://github.com/awsdocs/amazon-ec2-auto-scaling-user-)
+ [Deployment ECS - Multi-AZ](https://github.com/aws-samples/ecs-refarch-cloudformation)
+ [Mengalihkan lalu lintas menggunakan ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.failover-different-accounts.html)
+ [Lambda dengan Application Load Balancer dan Failover](https://docs.aws.amazon.com/lambda/latest/dg/services-alb.html)
+ [Replikasi ACM dan Failover](https://github.com/aws-samples/amazon-ecr-cross-region-replication)
+ [Replikasi Penyimpanan Parameter dan Failover](https://medium.com/devops-techable/how-to-design-an-ssm-parameter-store-for-multi-region-replication-support-aws-infrastructure-db7388be454d)
+ [Replikasi lintas wilayah ECR dan Failover](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-configure.html)
+ [Konfigurasi replikasi lintas wilayah manajer rahasia](https://disaster-recovery.workshop.aws/en/labs/basics/secrets-manager.html)
+ [Mengaktifkan replikasi lintas wilayah untuk EFS dan Failover](https://aws.amazon.com/blogs/aws/new-replication-for-amazon-elastic-file-system-efs/)
+ [Replikasi Lintas Wilayah EFS dan Failover](https://aws.amazon.com/blogs/storage/transferring-file-data-across-aws-regions-and-accounts-using-aws-datasync/)
+ [Failover Jaringan](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.html)
+ [Failover titik akhir S3 menggunakan MRAP](https://catalog.workshops.aws/s3multiregionaccesspoints/en-US/0-setup/1-review-mrap)
+ [Membuat replikasi lintas wilayah untuk S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Failover API Gateway Wilayah dengan ARC](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjat_TNvev_AhVLlokEHaUeDSUQFnoECAYQAQ&url=https%3A%2F%2Fd1.awsstatic.com%2Fsolutions%2Fguidance%2Farchitecture-diagrams%2Fcross-region-failover-and-graceful-failback-on-aws.pdf&usg=AOvVaw0czthdzWiGlN9I-Dt0lAu3&opi=89978449)
+ [Failover menggunakan akselerator global multiwilayah](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/)
+ [Failover dengan DRS](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html)
+ [Membuat Mekanisme Pemulihan Bencana Menggunakan Amazon Route 53](https://amazon.awsapps.com/workdocs/index.html#/document/2501b1ab648225c2d50ab420c4626ef143834fd0d646978629e5ea4e9b8f014b)
**Contoh terkait:**
+ [Pemulihan Bencana di AWS](https://disaster-recovery.workshop.aws/en/)
+ [Pemulihan Bencana Elastis di AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/080af3a5-623d-4147-934d-c8d17daba346/en-US)
# REL11-BP03 Mengotomatisasi pemulihan di 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](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/).
Kemampuan untuk memulai ulang atau menghapus sumber daya adalah alat yang penting untuk meremediasi kegagalan. Salah satu praktik terbaik adalah membuat layanan stateless jika memungkinkan. Praktik ini mencegah hilangnya data atau ketersediaan pada saat mulai ulang sumber daya. Di cloud, Anda dapat (dan umumnya harus) mengganti seluruh sumber daya (misalnya, instans komputasi atau fungsi nirserver) 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.
Memulai ulang atau mencoba ulang juga berlaku untuk 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.
**Hasil yang diinginkan:** Tindakan otomatis dilakukan untuk meremediasi deteksi kegagalan.
**Antipola 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 menjalankan praktik terbaik ini:** Pemulihan otomatis dapat mengurangi waktu rata-rata pemulihan dan meningkatkan ketersediaan Anda.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Desain untuk Amazon EKS atau layanan Kubernetes lainnya harus mencakup replika minimum dan maksimum atau set stateful dan penyesuaian ukuran klaster dan grup simpul minimum. Mekanisme ini menyediakan jumlah minimum sumber daya pemrosesan yang tersedia secara terus-menerus sambil secara otomatis memulihkan kegagalan apa pun menggunakan bidang kendali Kubernetes.
Pola desain yang diakses melalui penyeimbang beban menggunakan klaster komputasi harus memanfaatkan grup Auto Scaling. Elastic Load Balancing (ELB) secara otomatis mendistribusikan lalu lintas aplikasi yang masuk di beberapa target dan perangkat virtual di satu atau beberapa Zona Ketersediaan (AZ).
Desain berbasis komputasi klaster 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 memulihkan simpul baru. Contoh layanannya adalah Mongo, DynamoDB Accelerator, Amazon Redshift, Amazon EMR, Cassandra, Kafka, MSK-EC2, Couchbase, ELK, dan Amazon OpenSearch Service. Banyak dari layanan ini dapat dirancang dengan fitur pemulihan otomatis tambahan. Beberapa teknologi klaster harus menghasilkan peringatan atas hilangnya simpul yang memicu alur kerja otomatis atau manual untuk membuat ulang simpul baru. Alur kerja ini dapat diotomatisasi menggunakan AWS Systems Manager untuk meremediasi masalah dengan cepat.
Amazon EventBridge dapat digunakan untuk memantau dan memfilter peristiwa seperti alarm CloudWatch atau perubahan status pada layanan AWS lain. Berdasarkan informasi peristiwa, layanan ini kemudian dapat memanggil AWS Lambda, Otomatisasi Systems Manager, atau target lain untuk menjalankan logika remediasi 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. Untuk penggantian skala besar (seperti hilangnya seluruh Zona Ketersediaan), stabilitas statis lebih disarankan untuk ketersediaan tinggi.
### Langkah implementasi
+ Gunakan grup Auto Scaling untuk men-deploy tingkatan dalam beban kerja. [Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) dapat melakukan pemulihan mandiri untuk aplikasi stateless serta menambahkan dan menghapus kapasitas.
+ Untuk instans komputasi yang disebutkan sebelumnya, gunakan [penyeimbangan beban](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) dan pilih jenis penyeimbang beban yang sesuai.
+ Pertimbangkan pemulihan untuk Amazon RDS. Dengan instans siaga, konfigurasikan untuk [failover otomatis](https://repost.aws/questions/QU4DYhqh2yQGGmjE_x0ylBYg/what-happens-after-failover-in-rds) ke instans siaga. Untuk Amazon RDS Read Replica, alur kerja otomatis diperlukan untuk membuat replika baca primer.
+ Implementasikan [pemulihan otomatis pada instans EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) yang telah melakukan deployment aplikasi yang tidak dapat di-deploy di beberapa lokasi, dan dapat menoleransi 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 disimpan, serta [volume EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) dan pasang poin ke [Amazon Elastic File System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) atau [File Systems for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) dan [Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html). Jika menggunakan [AWS OpsWorks](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html), Anda dapat mengonfigurasi pemulihan otomatis instans EC2 pada tingkat lapisan.
+ Implementasikan pemulihan otomatis menggunakan [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) dan [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 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.
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) dapat digunakan untuk memantau dan memfilter peristiwa seperti [alarm CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) atau perubahan status di layanan AWS lain. Berdasarkan informasi peristiwa, layanan ini kemudian dapat menginvokasi AWS Lambda (atau target lainnya) untuk menjalankan logika remediasi kustom pada beban kerja Anda.
## Sumber daya
**Praktik terbaik terkait:**
+ [Definisi Ketersediaan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**Dokumen terkait:**
+ [Cara Kerja AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.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)
+ [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)
+ [AWS OpsWorks: Menggunakan Auto Healing untuk Mengganti Instans yang Gagal](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [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)
+ [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)
+ [Failover Amazon RDS](https://d1.awsstatic.com/rdsImages/IG1_RDS1_AvailabilityDurability_Final.pdf)
+ [SSM - Otomatisasi Systems Manager](https://docs.aws.amazon.com/resilience-hub/latest/userguide/integrate-ssm.html)
+ [Praktik Terbaik Arsitektur Tangguh](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)
**Video terkait:**
+ [Penyediaan dan Penskalaan OpenSearch Service Secara Otomatis](https://www.youtube.com/watch?v=GPQKetORzmE)
+ [Failover Amazon RDS Secara Otomatis](https://www.youtube.com/watch?v=Mu7fgHOzOn0)
**Contoh terkait:**
+ [Lokakarya di Auto Scaling](https://catalog.workshops.aws/general-immersionday/en-US/advanced-modules/compute/auto-scaling)
+ [Lokakarya Failover Amazon RDS](https://catalog.workshops.aws/resilient-apps/en-US/rds-multi-availability-zone/failover-db-instance)
**Alat terkait:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# 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%.](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 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](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/).
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](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/) adalah metode yang lebih disukai untuk membatasi tindakan bidang kendali
Pertimbangkan pendekatan alternatif yang memungkinkan tindakan bidang data untuk memengaruhi remediasi yang sama.
+ Route 53 Rekam perubahan (bidang kendali) atau ARC (bidang data)
+ [ Route 53 Pemeriksaan kondisi untuk pembaruan yang lebih otomatis ](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
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:**
+ [Definisi Ketersediaan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**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)
+ [ Bidang Kendali dan bidang data Kubernetes ](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/)
**Video terkait:**
+ [ Kembali ke Dasar - Menggunakan Stabilitas Statis ](https://www.youtube.com/watch?v=gy1RITZ7N7s)
+ [ Membangun beban kerja multi-lokasi yang tangguh menggunakan layanan global AWS](https://www.youtube.com/watch?v=62ZQHTruBnk)
**Contoh terkait:**
+ [Memperkenalkan Pengontrol Pemulihan Aplikasi Amazon Route 53](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
+ [ 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/)
+ [ 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/)
+ [ Stabilitas statis menggunakan Zona Ketersediaan ](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
**Alat terkait:**
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP05 Menggunakan stabilitas statis untuk mencegah perilaku bimodal
Beban kerja harus stabil secara statis dan hanya beroperasi dalam mode normal tunggal. Perilaku bimodal adalah ketika beban kerja Anda menunjukkan perilaku yang berbeda dalam mode normal dan mode kegagalan.
Misalnya, Anda mungkin mencoba pulih dari kegagalan Zona Ketersediaan dengan meluncurkan instans baru di Zona Ketersediaan yang berbeda. Hal ini dapat menyebabkan respons bimodal selama mode kegagalan. Sebagai gantinya, Anda harus membangun beban kerja yang stabil secara statis dan beroperasi dalam satu mode saja. Dalam contoh ini, instans-instans tersebut seharusnya telah disediakan di Zona Ketersediaan kedua sebelum terjadinya kegagalan. Desain stabilitas statis ini memastikan beban kerja hanya beroperasi dalam satu mode.
**Hasil yang diinginkan:** Beban kerja tidak menunjukkan perilaku bimodal selama mode normal dan mode kegagalan.
**Antipola umum:**
+ Berasumsi bahwa sumber daya selalu dapat disediakan terlepas dari ruang lingkup kegagalannya.
+ Mencoba memperoleh sumber daya secara dinamis selama kegagalan.
+ Tidak menyediakan sumber daya yang memadai di seluruh zona atau Wilayah sampai terjadi kegagalan.
+ Mempertimbangkan desain stabil statis hanya untuk sumber daya komputasi.
**Manfaat menjalankan praktik terbaik ini:** Beban kerja yang berjalan dengan desain yang stabil secara statis mampu memiliki hasil yang dapat diprediksi selama peristiwa normal dan kegagalan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Perilaku bimodal terjadi ketika beban kerja Anda menunjukkan perilaku yang berbeda dalam mode normal dan mode gagal, (misalnya, mengandalkan peluncuran instans baru jika Zona Ketersediaan gagal). Contoh perilaku bimodal adalah ketika Amazon EC2 yang stabil menyediakan instans yang cukup di setiap Zona Ketersediaan untuk menangani beban dari beban kerja jika satu AZ disingkirkan. Elastic Load Balancing atau Amazon Route 53 akan melakukan pemeriksaan kondisi untuk memindahkan beban dari instans yang terganggu. Setelah lalu lintas dipindahkan, gunakan AWS Auto Scaling untuk mengganti instans secara asinkron dari zona yang gagal dan luncurkan di zona sehat. Stabilitas statis untuk deployment komputasi (seperti kontainer atau instans EC2) akan menghasilkan keandalan tertinggi.
![\[Diagram yang menunjukkan stabilitas statis instans EC2 di seluruh Zona Ketersediaan\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/static-stability.png)
Ini harus ditimbang berdasarkan biaya untuk model ini serta nilai bisnis untuk memelihara beban kerja di bawah semua kasus ketahanan. Menyediakan kapasitas komputasi yang lebih sedikit dan mengandalkan peluncuran instans baru apabila terjadi kegagalan memang lebih murah, tetapi untuk kegagalan berskala besar (seperti gangguan pada Zona Ketersediaan atau Regional), pendekatan ini kurang efektif karena bergantung pada bidang operasional serta sumber daya yang tersedia di zona atau Wilayah yang tidak terdampak.
Solusi Anda harus mengukur keandalan berdasarkan kebutuhan biaya untuk beban kerja Anda. Arsitektur stabilitas statis berlaku untuk berbagai arsitektur termasuk instans komputasi yang tersebar di Zona Ketersediaan, desain replika baca basis data, desain klaster Kubernetes (Amazon EKS), dan arsitektur failover multi-Wilayah.
Anda juga dapat menerapkan desain yang lebih stabil secara statis dengan menggunakan lebih banyak sumber daya di setiap zona. Dengan menggunakan lebih banyak zona, Anda mengurangi jumlah komputasi tambahan yang Anda perlukan untuk stabilitas statis.
Contoh perilaku bimodal adalah batas waktu jaringan yang dapat menyebabkan sistem mencoba melakukan refresh status konfigurasi seluruh sistem. Ini akan menambahkan beban yang tak terduga ke komponen lain, dan dapat menyebabkan komponen tersebut gagal, sehingga berimbas pada konsekuensi lain yang tak terduga. Putaran umpan balik negatif ini memengaruhi ketersediaan beban kerja Anda. Sebagai gantinya, Anda dapat membangun sistem yang stabil secara statis dan beroperasi dalam satu mode saja. Desain yang stabil secara statis akan melakukan tugas yang konstan, dan selalu menyegarkan status konfigurasi dengan irama yang teratur. Ketika panggilan gagal, beban kerja akan menggunakan nilai yang sebelumnya di-cache, dan memulai alarm.
Contoh perilaku bimodal lainnya adalah memperbolehkan klien untuk melewati cache beban kerja Anda ketika kegagalan terjadi. Ini mungkin terlihat seperti solusi yang mengakomodasi kebutuhan klien, tetapi hal ini secara signifikan dapat mengubah permintaan di beban kerja Anda dan kemungkinan akan mengakibatkan kegagalan.
Lakukan penilaian beban kerja kritis untuk menentukan beban kerja apa yang memerlukan jenis desain ketahanan ini. Untuk beban kerja yang dianggap kritis, setiap komponen aplikasi harus ditinjau. Contoh jenis layanan yang memerlukan evaluasi stabilitas statis adalah:
+ **Komputasi**: Amazon EC2, EKS-EC2, ECS-EC2, EMR-EC2
+ **Basis Data**: Amazon Redshift, Amazon RDS, Amazon Aurora
+ **Penyimpanan**: Amazon S3 (Zona Tunggal), Amazon EFS (mount), Amazon FSx (mount)
+ **Penyeimbang beban:** Di bawah desain tertentu
### Langkah implementasi
+ Bangun sistem yang stabil secara statis dan hanya beroperasi dalam satu mode. Dalam hal ini, sediakan cukup instans di setiap Zona Ketersediaan atau Wilayah untuk menangani kapasitas beban kerja jika satu Zona Ketersediaan atau Wilayah dihapus. Berbagai layanan dapat digunakan untuk perutean ke sumber daya yang sehat, seperti:
+ [Perutean DNS Lintas Wilayah](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [Perutean Multiwilayah Amazon S3 MRAP](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ Konfigurasikan [replika baca basis data](https://aws.amazon.com/rds/features/multi-az/) untuk memperhitungkan hilangnya satu instans utama atau replika baca. Jika lalu lintas dilayani oleh replika baca, kuantitas di setiap Zona Ketersediaan dan setiap Wilayah harus sama dengan kebutuhan keseluruhan jika terjadi kegagalan zona atau Wilayah.
+ Konfigurasikan data kritis di dalam penyimpanan Amazon S3 yang dirancang agar stabil secara statis untuk data yang disimpan jika terjadi kegagalan Zona Ketersediaan. Jika [kelas penyimpanan Amazon S3 One Zone-IA](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) digunakan, ini tidak boleh dianggap stabil secara statis, karena hilangnya zona tersebut akan meminimalkan akses ke data yang disimpan.
+ [Penyeimbang beban](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) terkadang dikonfigurasi secara salah atau secara bawaan untuk melayani satu Zona Ketersediaan tertentu. Dalam hal ini, desain yang stabil secara statis mungkin adalah menyebarkan beban kerja di beberapa AZ dalam desain yang lebih kompleks. Desain asli dapat digunakan untuk mengurangi lalu lintas antarzona untuk alasan keamanan, latensi, atau biaya.
## Sumber daya
**Praktik terbaik Well-Architected terkait:**
+ [Definisi Ketersediaan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
+ [REL11-BP04 Mengandalkan bidang data dan bukan bidang kendali selama pemulihan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html)
**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)
+ [Batas Isolasi Kesalahan](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/appendix-a---partitional-service-guidance.html)
+ [Stabilitas statis menggunakan Zona Ketersediaan](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [RDS Multi-Zona](https://aws.amazon.com/rds/features/multi-az/)
+ [Meminimalkan Ketergantungan dalam Rencana Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Perutean DNS Lintas Wilayah](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [Perutean Multiwilayah Amazon S3 MRAP](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Amazon S3 Zona Tunggal](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/)
+ [Penyeimbangan Beban Lintas Zona](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html)
**Video terkait:**
+ [Stabilitas statis di AWS: AWS re:Invent 2019: Memperkenalkan Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
**Contoh terkait:**
+ [Amazon Builders' Library: Stabilitas statis menggunakan Zona Ketersediaan](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
# REL11-BP06 Mengirimkan notifikasi ketika peristiwa memengaruhi ketersediaan
Notifikasi dikirimkan setelah pelanggaran ambang batas terdeteksi, bahkan apabila peristiwa yang menyebabkan masalah tersebut sudah 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.
Sistem yang tangguh dirancang sedemikian rupa sehingga peristiwa degradasi langsung dikomunikasikan kepada tim yang tepat. Notifikasi ini harus dikirim melalui satu atau banyak saluran komunikasi.
**Hasil yang diinginkan: **Pemberitahuan langsung dikirim ke tim operasi ketika ambang batas dilanggar, seperti tingkat kesalahan, latensi, atau metrik indikator kinerja utama (KPI) penting lainnya, sehingga masalah ini diselesaikan sesegera mungkin dan dampak terhadap pengguna dapat dicegah atau diminimalkan.
**Antipola umum:**
+ Mengirimkan terlalu banyak alarm.
+ Mengirimkan alarm yang tidak dapat ditindaklanjuti.
+ Mengatur ambang alarm terlalu tinggi (terlalu sensitif) atau terlalu rendah (kurang sensitif).
+ Tidak mengirimkan alarm untuk dependensi eksternal.
+ Tidak mempertimbangkan [kegagalan abu-abu](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) saat merancang pemantauan dan alarm.
+ Melakukan otomatisasi pemulihan, tetapi tidak memberikan notifikasi kepada tim yang tepat bahwa pemulihan diperlukan.
**Manfaat menjalankan praktik terbaik ini:** Notifikasi pemulihan membuat tim operasional dan bisnis menyadari adanya degradasi layanan sehingga mereka dapat segera bereaksi untuk meminimalkan waktu deteksi rata-rata (MTTD) dan waktu perbaikan rata-rata (MTTR). Notifikasi peristiwa pemulihan juga menjamin bahwa Anda tidak mengabaikan masalah yang jarang terjadi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang. Kegagalan mengimplementasikan mekanisme pemantauan dan notifikasi peristiwa secara tepat dapat mengakibatkan kegagalan dalam mendeteksi pola masalah, termasuk masalah yang ditangani oleh pemulihan otomatis. Sebuah tim hanya akan menyadari adanya degradasi sistem ketika pengguna menghubungi layanan pelanggan atau secara kebetulan.
## Panduan implementasi
Saat menetapkan strategi pemantauan, alarm yang dipicu adalah peristiwa umum. Peristiwa ini kemungkinan berisi pengidentifikasi untuk alarm, status alarm (seperti `IN ALARM` atau `OK`), dan detail mengenai pemicunya. Dalam banyak kasus, peristiwa alarm seharusnya dideteksi dan email notifikasi dikirimkan. Ini adalah contoh tindakan pada alarm. Notifikasi alarm sangat penting dalam hal observabilitas karena memberi tahu orang yang tepat bahwa terdapat sebuah masalah. Namun, ketika tindakan terhadap peristiwa sudah matang di dalam solusi observabilitas Anda, tindakan tersebut dapat secara otomatis memperbaiki masalah tanpa memerlukan campur tangan manusia.
Setelah alarm pemantauan KPI ditetapkan, peringatan seharusnya dikirimkan ke tim yang tepat ketika ambang batas terlampaui. Peringatan tersebut juga dapat digunakan untuk memicu proses otomatis yang akan mencoba memperbaiki degradasi.
Untuk pemantauan ambang batas yang lebih kompleks, alarm komposit harus dipertimbangkan. Alarm komposit menggunakan sejumlah alarm pemantauan KPI untuk membuat peringatan berdasarkan logika bisnis operasional. CloudWatch Alarm dapat dikonfigurasi untuk mengirimkan email, atau untuk mencatatkan insiden di dalam sistem pelacakan insiden pihak ketiga menggunakan integrasi Amazon SNS atau Amazon EventBridge.
### Langkah implementasi
Buat berbagai jenis alarm berdasarkan bagaimana beban kerja dipantau, seperti:
+ Alarm aplikasi digunakan untuk mendeteksi apabila ada bagian dari beban kerja Anda yang tidak berfungsi dengan baik.
+ [Alarm infrastruktur](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) menunjukkan kapan sumber daya perlu diskalakan. Alarm dapat ditampilkan secara visual di dasbor, mengirimkan peringatan melalui Amazon SNS atau email, dan bekerja sama dengan Auto Scaling untuk mengecilkan atau memperluas skala sumber daya beban kerja.
+ Alarm [statis sederhana](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) dapat dibuat untuk memantau apabila metrik melanggar ambang batas statis selama periode evaluasi tertentu.
+ [Alarm komposit](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) dapat memperhitungkan alarm-alarm kompleks dari berbagai sumber.
+ Setelah alarm dibuat, buat peristiwa notifikasi yang sesuai. Anda dapat langsung menginvokasi [API Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) untuk mengirimkan notifikasi dan menautkan otomatisasi apa pun untuk perbaikan atau komunikasi.
+ Integrasikan [Amazon Health Aware](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) untuk memungkinkan visibilitas pemantauan ke sumber daya AWS yang mungkin mengalami degradasi. Untuk beban kerja yang penting untuk bisnis, solusi ini menyediakan akses ke peringatan proaktif dan waktu nyata untuk layanan AWS.
## Sumber daya
**Praktik terbaik Well-Architected terkait:**
+ [Definisi Ketersediaan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
**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)
+ [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)
+ [Amazon Health Aware (AHA)](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/)
+ [Menyiapkan Alarm komposit CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)
+ [Apa yang baru di Observabilitas AWS pada re:Invent 2022](https://aws.amazon.com/blogs/mt/whats-new-in-aws-observability-at-reinvent-2022/)
**Alat terkait:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP07 Merancang produk Anda agar memenuhi target ketersediaan dan perjanjian tingkat layanan (SLA) waktu aktif
Rancang produk Anda agar memenuhi target ketersediaan dan perjanjian tingkat layanan (SLA) waktu aktif. Jika Anda memublikasi atau secara pribadi menyetujui target ketersediaan atau SLA yang berlaku, verifikasikan bahwa proses operasional dan arsitektur Anda didesain untuk mendukungnya.
**Hasil yang diinginkan:** Setiap aplikasi memiliki target yang ditetapkan untuk ketersediaan dan SLA untuk metrik performa, yang dapat dipantau dan dipertahankan untuk memenuhi hasil bisnis.
**Antipola umum:**
+ Mendesain dan melakukan deployment beban kerja tanpa menetapkan SLA apa pun.
+ Metrik SLA ditetapkan ke tingkat tinggi tanpa rasional atau persyaratan bisnis.
+ Menetapkan SLA tanpa memperhitungkan dependensi dan SLA yang mendasarinya.
+ Desain aplikasi dibuat tanpa mempertimbangkan Model Tanggung Jawab Bersama untuk Ketangguhan.
**Manfaat menjalankan praktik terbaik ini:** Mendesain aplikasi berdasarkan target ketangguhan utama membantu Anda memenuhi tujuan bisnis dan ekspektasi pelanggan. Tujuan ini membantu mendorong proses desain aplikasi yang mengevaluasi berbagai macam teknologi dan mempertimbangkan beragam kompromi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Desain aplikasi harus memperhitungkan berbagai rangkaian persyaratan yang didapatkan dari tujuan bisnis, operasional, dan finansial. Dalam persyaratan operasional, beban kerja harus memiliki target metrik ketangguhan tertentu sehingga dapat dipantau dan dukung dengan sesuai. Metrik ketangguhan tidak boleh ditetapkan atau didapatkan setelah melakukan deployment beban kerja. Metrik ketangguhan harus ditetapkan selama fase desain dan membantu memandu berbagai keputusan dan kompromi.
+ Setiap beban kerja harus memiliki rangkaian metrik ketangguhannya sendiri. Metrik-metrik tersebut mungkin berbeda dari aplikasi bisnis yang lain.
+ Mengurangi dependensi dapat memiliki dampak positif pada ketersediaan. Setiap beban kerja harus mempertimbangkan dependensinya serta SLA-nya. Secara umum, pilih dependensi dengan target ketersediaan yang setara dengan atau lebih besar dari target beban kerja Anda.
+ Pertimbangkan desain yang dipasangkan secara longgar sehingga beban kerja Anda dapat beroperasi dengan benar meskipun ada gangguan dependensi, apabila mungkin.
+ Kurangi dependensi bidang kendali, terutama selama pemulihan atau degradasi. Evaluasi desain yang secara statis stabil untuk beban kerja yang penting bagi misi. Gunakan penghematan sumber daya untuk meningkatkan ketersediaan dependensi tersebut di beban kerja.
+ Observabilitas dan instrumentasi sangat penting untuk mencapai SLA dengan mengurangi Waktu Rata-Rata ke Deteksi (MTTD) dan Waktu Rata-Rata ke Perbaikan (MTTR).
+ Kegagalan lebih jarang (MTBF lebih lama), waktu deteksi kegagalan lebih pendek (MTTD lebih singkat), dan waktu perbaikan lebih singkat (MTTR lebih singkat) adalah tiga faktor yang digunakan untuk meningkatkan ketersediaan di sistem terdistribusi.
+ Menetapkan dan memenuhi metrik ketangguhan untuk beban kerja merupakan fondasi dari desain yang efektif. Desain tersebut harus memperhitungkan kompromi terkait kompleksitas desain, dependensi layanan, performa, penskalaan, dan biaya.
**Langkah implementasi**
+ Tinjau dan dokumentasikan desain beban kerja sambil mempertimbangkan pertanyaan berikut:
+ Di mana bidang kendali digunakan di beban kerja?
+ Bagaimana beban kerja mengimplementasikan toleransi kesalahan?
+ Apa saja pola desain untuk penskalaan, penskalaan otomatis, redundansi, dan komponen dengan ketersediaan tinggi?
+ Apa saja persyaratan untuk ketersediaan dan konsistensi data?
+ Apakah ada pertimbangan untuk penghematan sumber daya atau stabilitas statis sumber daya?
+ Apa saja dependensi layanan?
+ Tetapkan metrik SLA berdasarkan arsitektur beban kerja sambil bekerja sama dengan para pemangku kepentingan. Pertimbangkan SLA semua dependensi yang digunakan oleh beban kerja.
+ Setelah target SLA ditetapkan, optimalkan arsitektur untuk memenuhi SLA.
+ Setelah desain yang akan memenuhi SLA dibuat, implementasikan perubahan operasional, otomatisasi proses, dan runbook yang juga akan memiliki fokus pada pengurangan MTTD dan MTTR.
+ Setelah di-deploy, pantau dan laporkan SLA.
## Sumber daya
**Praktik Terbaik Terkait:**
+ [REL03-BP01 Memilih cara untuk menyegmentasi beban kerja](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Melakukan deployment beban kerja ke beberapa lokasi](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Mengotomatisasi pemulihan di semua lapisan](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 Menguji ketahanan menggunakan chaos engineering](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL13-BP01 Tetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md)
+ [Memahami kesehatan beban kerja](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)
**Dokumen terkait:**
+ [ Ketersediaan dengan redundansi ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [ Pilar keandalan - Ketersediaan ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [ Mengukur ketersediaan ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html)
+ [ Batas Isolasi Kesalahan AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Model Tanggung Jawab Bersama untuk Ketangguhan ](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/shared-responsibility-model-for-resiliency.html)
+ [ Stabilitas statis menggunakan Zona Ketersediaan](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [ Perjanjian Tingkat Layanan (SLA) AWS](https://aws.amazon.com/legal/service-level-agreements/)
+ [ Panduan untuk Arsitektur Berbasis Sel di AWS](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/)
+ [ Infrastruktur AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html)
+ [ Laporan resmi Pola Ketangguhan Multi-AZ Lanjutan ](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html)
**Layanan terkait:**
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
# REL 12. Bagaimana cara menguji keandalan?
Setelah Anda mendesain beban kerja Anda agar tangguh terhadap tekanan produksi, pengujian adalah satu-satunya cara untuk memverifikasi bahwa beban kerja akan beroperasi sesuai desain, dan memberikan ketangguhan yang Anda harapkan.
**Topics**
+ [REL12-BP01 Menggunakan buku pedoman untuk menyelidiki kegagalan](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 Menjalankan analisis setelah insiden](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 Menguji persyaratan fungsional](rel_testing_resiliency_test_functional.md)
+ [REL12-BP04 Menguji persyaratan penskalaan dan kinerja](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP05 Menguji ketahanan menggunakan chaos engineering](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP06 Mengadakan game day secara rutin](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 Menggunakan buku pedoman untuk menyelidiki kegagalan
Dokumentasikan proses penyelidikan di buku pedoman agar dapat memberikan respons yang cepat dan konsisten terhadap skenario kegagalan yang tidak benar-benar dipahami. Buku pedoman adalah langkah-langkah yang telah ditetapkan di awal untuk mengidentifikasi faktor yang menyebabkan skenario kegagalan. Hasil dari langkah proses apa pun digunakan untuk menentukan langkah berikutnya yang akan dilakukan sampai masalah diidentifikasi atau dieskalasi.
Buku pedoman adalah perencanaan proaktif yang harus Anda lakukan, agar Anda dapat mengambil tindakan reaktif secara efektif. Ketika skenario kegagalan yang tidak tercakup dalam buku pedoman dialami di lingkungan produksi, tangani masalah terlebih dahulu (padamkan api). Lalu lihat kembali langkah-langkah yang telah Anda ambil untuk mengatasi masalah tersebut dan gunakan untuk menambahkan entri baru dalam buku pedoman.
Ingat bahwa buku pedoman digunakan untuk merespons insiden tertentu, sedangkan runbook digunakan untuk mencapai hasil tertentu. Sering kali, runbook digunakan untuk untuk aktivitas rutin, dan buku pedoman digunakan untuk merespons peristiwa nonrutin.
**Antipola umum:**
+ Berencana untuk melakukan deployment beban kerja tanpa mengetahui proses untuk mendiagnosis masalah atau merespons insiden.
+ Keputusan yang tidak direncanakan tentang sistem mana saja yang dikumpulkan log dan metriknya saat menyelidiki peristiwa.
+ Tidak mempertahankan metrik dan peristiwa cukup lama agar dapat mengambil data.
**Manfaat menjalankan praktik terbaik ini:** Pencatatan runbook memastikan prosedur dapat diikuti secara konsisten. Kodifikasi runbook membatasi munculnya kesalahan dari aktivitas manual. Buku pedoman otomatis dapat menghemat waktu respons peristiwa dengan menghilangkan keharusan campur tangan anggota tim atau memberikan informasi tambahan ketika campur tangan mereka dimulai.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Gunakan buku pedoman untuk mengidentifikasi masalah. Buku pedoman adalah proses yang didokumentasikan untuk menyelidiki masalah. Dokumentasikan proses penyelidikan di buku pedoman agar dapat memberikan respons yang cepat dan konsisten terhadap skenario kegagalan. Buku pedoman harus memuat informasi dan panduan yang dapat digunakan oleh orang yang cukup terampil untuk mengumpulkan informasi, mengidentifikasi potensi sumber kegagalan, mengisolasi kesalahan, dan menentukan faktor penyebabnya (lakukan analisis pascainsiden).
+ Implementasikan buku pedoman sebagai kode. Jalankan operasi sebagai kode dengan membuat skrip buku pedoman Anda untuk memastikan konsistensi dan mengurangi kesalahan yang disebabkan proses manual. Buku pedoman dapat terdiri dari beberapa skrip sesuai dengan banyaknya langkah yang diperlukan untuk mengidentifikasi faktor penyebab masalah. Aktivitas runbook dapat dipicu atau dijalankan sebagai bagian dari aktivitas buku pedoman, atau mempercepat eksekusi buku pedoman untuk merespons peristiwa yang teridentifikasi.
+ [Otomatiskan buku pedoman operasional Anda dengan AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Apa itu AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [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:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [Otomatiskan buku pedoman operasional Anda dengan AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Menggunakan Alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Menggunakan Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.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)
**Contoh terkait:**
+ [Mengotomatiskan operasi dengan Buku Pedoman dan Runbook](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL12-BP02 Menjalankan analisis setelah insiden
Tinjau peristiwa yang memengaruhi pelanggan, dan identifikasi faktor yang berkontribusi serta tindakan pencegahannya. Gunakan informasi ini untuk mengembangkan mitigasi guna meminimalkan atau mencegah kemungkinan terjadi lagi. Kembangkan prosedur untuk respons efektif dan cepat. Komunikasikan faktor yang berkontribusi dan tindakan koreksi yang diperlukan, yang disesuaikan dengan audiens target. Miliki metode untuk mengomunikasikan penyebab ini ke lainnya seperti yang diperlukan.
Menilai alasan mengapa pengujian yang ada tidak dapat menemukan masalahnya. Menambahkan pengujian untuk kasus ini jika pengujian belum ada.
**Hasil yang diinginkan:** Tim Anda memiliki pendekatan yang konsisten dan disepakati untuk menangani analisis pascainsiden. Salah satu mekanismenya adalah [proses koreksi kesalahan (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/). Proses COE membantu tim Anda mengidentifikasi, memahami, dan mengatasi akar penyebab insiden, sekaligus membangun mekanisme dan pagar pembatas untuk membatasi kemungkinan insiden yang sama terjadi lagi.
**Antipola umum:**
+ Menemukan faktor-faktor yang berkontribusi, tetapi tidak terus-menerus mencari lebih dalam untuk masalah potensial dan pendekatan lainnya untuk memitigasi.
+ Hanya mengidentifikasi penyebab kesalahan manusia, dan tidak memberikan pelatihan atau otomatisasi apa pun yang dapat mencegah kesalahan manusia.
+ Fokus menyalahkan, bukan memahami akar penyebabnya, sehingga tercipta budaya ketakutan dan menghambat komunikasi terbuka
+ Tidak berbagi wawasan, yang membuat temuan analisis insiden hanya diketahui kelompok kecil saja, sehingga orang lain tidak dapat belajar dari pengalaman tersebut
+ Tidak ada mekanisme untuk mencatat pengetahuan institusional, sehingga wawasan yang berharga hilang karena pelajaran yang didapat tidak diabadikan dalam bentuk praktik terbaik yang diperbarui dan mengakibatkan insiden berulang dengan akar penyebab yang sama atau serupa
**Manfaat menyusun praktik terbaik ini:** Dengan melakukan analisis setelah insiden dan membagikan hasilnya, beban kerja lain akan dapat memitigasi risiko jika beban kerja sudah mengimplementasikan faktor penyumbang yang sama, sehingga mitigasi atau pemulihan otomatis dapat diimplementasikan sebelum insiden terjadi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Analisis setelah insiden yang baik memberikan peluang untuk mengusulkan solusi umum terhadap masalah dengan pola arsitektur yang digunakan di tempat lainnya dalam sistem.
Dokumentasi dan penanganan masalah merupakan landasan proses COE. Sebaiknya tentukan cara standar untuk mendokumentasikan akar penyebab kritis, dan memastikan penyebab tersebut ditinjau dan ditangani. Tetapkan kepemilikan yang jelas untuk proses analisis setelah insiden. Tunjuk individu atau tim penanggung jawab yang akan mengawasi penyelidikan dan tindak lanjut insiden.
Dorong budaya yang berfokus pada pembelajaran dan peningkatan, bukan menyalahkan. Tekankan bahwa tujuannya adalah untuk mencegah insiden di kemudian hari, bukan untuk menghukum individu.
Kembangkan prosedur yang jelas untuk melakukan analisis setelah insiden. Prosedur ini harus menguraikan langkah-langkah yang harus diambil, informasi yang akan dikumpulkan, dan pertanyaan-pertanyaan penting yang harus dicari jawabannya selama analisis. Selidiki insiden secara menyeluruh, tidak hanya pada penyebab langsung guna mengidentifikasi akar penyebab dan faktor penyumbangnya. Gunakan teknik seperti *[Analisis Lima Mengapa](https://en.wikipedia.org/wiki/Five_whys)* untuk menggali lebih dalam masalah yang mendasarinya.
Simpan repositori pelajaran yang didapat dari analisis insiden. Pengetahuan institusional ini dapat digunakan sebagai referensi untuk insiden dan upaya pencegahan ke depannya. Bagikan temuan dan wawasan dari analisis setelah insiden, dan pertimbangkan untuk mengadakan pertemuan tinjauan setelah insiden terbuka untuk membahas pelajaran yang didapatkan.
### Langkah implementasi
+ Saat melakukan analisis setelah insiden, pastikan tidak menyalahkan siapa pun dalam proses tersebut. Dengan begitu, orang-orang yang terlibat dalam insiden tersebut bersikap rasional terhadap tindakan korektif yang diusulkan dan mendorong penilaian mandiri yang jujur serta kolaborasi di seluruh tim.
+ Tentukan cara standar untuk mendokumentasikan masalah kritis. Contoh struktur untuk dokumen tersebut:
+ Apa yang terjadi?
+ Apa dampaknya terhadap pelanggan dan bisnis Anda?
+ Apa akar penyebabnya?
+ Data apa yang Anda miliki untuk mendukung hal ini?
+ Misalnya, metrik dan grafik
+ Apa implikasi pilar kritis, terutama keamanan?
+ Saat merancang beban kerja, Anda memilah pilar-pilar sesuai dengan konteks bisnis Anda. Keputusan bisnis ini dapat menentukan prioritas rekayasa Anda. Anda dapat mengoptimalkan untuk mengurangi biaya dengan mengorbankan keandalan dalam lingkungan pengembangan, atau, untuk solusi yang sangat penting, Anda dapat mengoptimalkan keandalan dengan biaya yang lebih tinggi. Keamanan selalu menjadi hal yang didahulukan dan diutamakan, karena Anda harus melindungi pelanggan Anda.
+ Pelajaran apa hal yang Anda dapatkan?
+ Tindakan korektif apa yang Anda ambil?
+ Item tindakan
+ Item terkait
+ Buat prosedur operasi standar yang jelas untuk melakukan analisis setelah insiden.
+ Siapkan proses pelaporan insiden standar. Dokumentasikan semua insiden secara komprehensif, termasuk laporan insiden awal, log, komunikasi, dan tindakan yang diambil selama insiden.
+ Ingatlah bahwa insiden tidak harus berupa terhentinya sistem. Insiden juga bisa berupa near-miss, atau performa sistem yang tidak sesuai harapan meski tetap memenuhi fungsi bisnisnya.
+ Terus tingkatkan proses analisis setelah insiden Anda berdasarkan umpan balik dan pelajaran yang dipetik.
+ Tangkap temuan utama dalam sistem manajemen pengetahuan, dan pertimbangkan pola apa pun yang perlu ditambahkan ke dalam panduan developer atau daftar periksa sebelum deployment.
## Sumber daya
**Dokumen terkait:**
+ [Mengapa Anda harus mengembangkan koreksi kesalahan (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
**Video terkait:**
+ [ Amazon’s approach to failing successfully ](https://aws.amazon.com/builders-library/amazon-approach-to-failing-successfully/)
+ [AWS re:Invent 2021 - Amazon Builders’ Library: Operational Excellence at Amazon ](https://www.youtube.com/watch?v=7MrD4VSLC_w)
# REL12-BP03 Menguji persyaratan fungsional
Gunakan teknik seperti pengujian unit dan pengujian integrasi yang memvalidasi fungsionalitas.
Anda akan meraih hasil terbaik saat pengujian ini dijalankan secara otomatis sebagai bagian dari tindakan deployment dan build. Misalnya, dengan menggunakan AWS CodePipeline, developer melakukan perubahan ke repositori sumber tempat CodePipeline mendeteksi perubahan secara otomatis. Perubahan tersebut dibangun, dan pengujian dijalankan. Setelah pengujian selesai, kode yang dibangun di-deploy ke server penahapan untuk pengujian. Dari server penahapan, CodePipeline menjalankan lebih banyak pengujian, seperti integrasi atau pengujian beban. Setelah berhasil menyelesaikan pengujian tersebut, CodePipeline melakukan deployment kode yang telah diuji dan disetujui ke instans produksi.
Selain itu, pengalaman menunjukkan bahwa pengujian transaksi sintetis (juga disebut sebagai *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 dari berbagai lokasi jarak jauh. Amazon CloudWatch Synthetics memungkinkan Anda untuk [membuat canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) untuk memantau titik akhir dan API.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Uji persyaratan fungsional. Hal ini termasuk pengujian unit dan pengujian integrasi yang memvalidasi fungsionalitas yang disyaratkan.
+ [Gunakan CodePipeline dengan AWS CodeBuild untuk menguji kode dan menjalankan build](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [AWS CodePipeline Menambahkan Dukungan untuk Unit dan Pengujian Integrasi Kustom dengan AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Pengiriman Berkelanjutan dan Integrasi Berkelanjutan](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Menggunakan Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Otomatisasi uji perangkat lunak](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu implementasi pipeline integrasi berkelanjutan](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration)
+ [AWS CodePipeline Menambahkan Dukungan untuk Unit dan Pengujian Integrasi Kustom dengan AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [AWS Marketplace: produk yang dapat digunakan untuk integrasi berkelanjutan](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration)
+ [Pengiriman Berkelanjutan dan Integrasi Berkelanjutan](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Otomatisasi uji perangkat lunak](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [Gunakan CodePipeline dengan AWS CodeBuild untuk menguji kode dan menjalankan build](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [Menggunakan Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
# REL12-BP04 Menguji persyaratan penskalaan dan kinerja
Gunakan teknik-teknik seperti pengujian beban untuk memvalidasi bahwa beban kerja memenuhi persyaratan kinerja dan penskalaan.
Di dalam cloud, Anda dapat membuat lingkungan pengujian dalam skala produksi sesuai permintaan untuk beban kerja Anda. Jika Anda menjalankan pengujian ini di infrastruktur yang skalanya diturunkan, Anda harus menskalakan hasil observasi Anda menurut apa yang Anda perkirakan terjadi di dalam produksi. Pengujian kinerja dan beban juga dapat dilakukan dalam produksi jika Anda ingin berhati-hati agar tidak berdampak pada pengguna aktual. Tandai data pengujian Anda agar tidak tercampur dengan data pengguna nyata dan mengubah laporan statistik atau produksi.
Dengan pengujian, Anda dapat memastikan bahwa sumber daya dasar, pengaturan penskalaan, kuota layanan, dan desain ketahanan Anda beroperasi sebagaimana mestinya saat menerima beban.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Uji persyaratan penskalaan dan kinerja. Jalankan pengujian beban untuk memvalidasi bahwa beban kerja memenuhi persyaratan kinerja dan penskalaan.
+ [Pengujian Beban Terdistribusi di AWS: simulasikan ribuan pengguna terhubung](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
+ Lakukan deployment aplikasi ke lingkungan yang menyerupai lingkungan produksi Anda, lalu eksekusi pengujian beban.
+ Gunakan infrastruktur sebagai konsep kode untuk membuat lingkungan semirip mungkin dengan lingkungan produksi Anda.
## Sumber daya
**Dokumen terkait:**
+ [Pengujian Beban Terdistribusi di AWS: simulasikan ribuan pengguna terhubung](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
# REL12-BP05 Menguji ketahanan menggunakan chaos engineering
Jalankan eksperimen chaos secara rutin di lingkungan yang berada dalam atau sedekat mungkin dengan produksi untuk memahami bagaimana sistem Anda merespons kondisi yang merugikan.
** Hasil yang diinginkan: **
Ketahanan beban kerja diverifikasi secara rutin dengan menerapkan chaos engineering dalam bentuk eksperimen injeksi kesalahan atau injeksi beban tak terduga. Selain itu, terdapat pengujian ketahanan yang memvalidasi perilaku sesuai ekspektasi yang diketahui dari beban kerja Anda selama berlangsungnya sebuah peristiwa. Gabungkan chaos engineering dan pengujian ketahanan agar Anda percaya bahwa beban kerja dapat bertahan dari kegagalan komponen dan dapat pulih dari gangguan tak terduga dengan dampak minimal atau tanpa dampak.
** Antipola umum: **
+ Menentukan desain untuk mendapatkan ketahanan, tetapi tidak memverifikasi bagaimana beban kerja berfungsi secara keseluruhan saat terjadi kesalahan.
+ Tidak pernah bereksperimen dalam kondisi dunia nyata dan dengan beban yang diharapkan.
+ Tidak memperlakukan eksperimen Anda sebagai kode atau memeliharanya melalui siklus pengembangan.
+ Tidak menjalankan eksperimen chaos baik sebagai bagian dari alur CI/CD Anda maupun di luar deployment.
+ Tidak menggunakan analisis pascainsiden terdahulu saat menentukan kesalahan mana yang akan digunakan dalam eksperimen.
** Manfaat menjalankan praktik terbaik ini:** Injeksi kesalahan untuk memverifikasi ketahanan beban kerja Anda akan membuat Anda percaya bahwa prosedur pemulihan dari desain Anda yang tangguh akan efektif jika terjadi kesalahan nyata.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Chaos engineering memberi tim Anda kemampuan untuk terus menginjeksi gangguan (simulasi) dunia nyata dengan cara yang terkontrol di tingkat penyedia layanan, infrastruktur, beban kerja, dan komponen, dengan dampak minimal atau tanpa dampak bagi pelanggan Anda. Hal ini memungkinkan tim Anda belajar dari kesalahan serta mengamati, mengukur, dan meningkatkan ketahanan beban kerja Anda, serta memvalidasi bahwa peringatan akan diluncurkan dan tim mendapatkan notifikasi jika terjadi suatu peristiwa.
Jika dilakukan terus-menerus, chaos engineering dapat menunjukkan kekurangan dalam beban kerja Anda yang, jika dibiarkan tidak ditangani, dapat berdampak negatif pada ketersediaan dan pengoperasian.
**catatan**
Chaos engineering adalah bidang ilmu yang bereksperimen pada sistem guna membangun kepercayaan pada kemampuan sistem untuk bertahan dari kondisi gangguan dalam produksi. – [Prinsip-prinsip Chaos Engineering](https://principlesofchaos.org/)
Jika sistem mampu bertahan dari gangguan ini, eksperimen chaos harus dipertahankan sebagai pengujian regresi otomatis. Dengan demikian, eksperimen chaos harus dilakukan sebagai bagian dari siklus hidup pengembangan sistem (SDLC) Anda dan sebagai bagian dari alur CI/CD Anda.
Untuk memastikan bahwa beban kerja Anda dapat bertahan dari kegagalan komponen, lakukan injeksi peristiwa dunia nyata sebagai bagian dari eksperimen Anda. Misalnya, lakukan eksperimen dengan kehilangan instans Amazon EC2 atau failover instans basis data Amazon RDS utama, lalu verifikasi bahwa beban kerja Anda tidak terpengaruh (atau hanya sedikit terpengaruh). Gunakan kombinasi kesalahan komponen untuk menyimulasikan peristiwa yang mungkin disebabkan oleh gangguan di Zona Ketersediaan.
Untuk kesalahan tingkat aplikasi (seperti crash), Anda dapat memulai dengan stressor seperti kehabisan memori dan daya CPU.
Untuk memvalidasi [mekanisme fallback atau failover](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) untuk dependensi eksternal karena gangguan jaringan yang terputus-putus, komponen Anda harus menyimulasikan peristiwa tersebut dengan memblokir akses ke penyedia pihak ketiga selama durasi tertentu yang dapat berlangsung dari hitungan detik hingga jam.
Mode degradasi lainnya dapat menyebabkan berkurangnya fungsionalitas dan respons yang lambat, sehingga sering kali mengakibatkan gangguan pada layanan Anda. Degradasi ini umumnya disebabkan oleh peningkatan latensi pada layanan yang sangat penting dan komunikasi jaringan yang tidak dapat diandalkan (paket yang tidak dikirim). Eksperimen dengan kesalahan ini, termasuk efek jaringan seperti latensi, pesan yang tidak terkirim, dan kegagalan DNS, dapat mencakup ketidakmampuan untuk meresolusi nama, menjangkau layanan DNS, atau membuat koneksi ke layanan yang dependen.
**Alat chaos engineering:**
AWS Fault Injection Service (AWS FIS) adalah layanan terkelola penuh untuk menjalankan eksperimen injeksi kesalahan yang dapat digunakan sebagai bagian dari alur CD Anda, atau di luar alur. AWS FIS adalah pilihan yang baik untuk digunakan selama game day chaos engineering. Layanan ini mendukung penerapan kesalahan secara bersamaan di berbagai jenis sumber daya, termasuk Amazon EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), dan Amazon RDS. Kesalahan ini termasuk menghentikan sumber daya, memaksa failover, membebani CPU atau memori, throttling, latensi, dan kehilangan paket. Karena layanan ini terintegrasi dengan Amazon CloudWatch Alarms, Anda dapat mengatur kondisi berhenti sebagai pagar pembatas untuk melakukan rollback jika eksperimen menyebabkan dampak tak terduga.
![\[Diagram yang menunjukkan AWS Fault Injection Service terintegrasi dengan sumber daya AWS untuk memungkinkan Anda menjalankan eksperimen injeksi kesalahan untuk beban kerja Anda.\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/fault-injection-simulator.png)
Ada juga beberapa opsi pihak ketiga untuk eksperimen injeksi kesalahan. Opsi ini mencakup alat sumber terbuka seperti [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/), dan [Litmus Chaos](https://litmuschaos.io/), serta opsi komersial seperti Gremlin. Untuk memperluas cakupan kesalahan yang dapat diinjeksikan di AWS, AWS FIS [terintegrasi dengan Chaos Mesh dan Litmus Chaos](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/), sehingga Anda dapat mengoordinasikan alur kerja injeksi kesalahan di antara beberapa alat. Misalnya, Anda dapat menjalankan pengujian pada CPU sebuah pod menggunakan kesalahan Chaos Mesh atau Litmus sambil menghentikan sebagian simpul klaster yang dipilih secara acak menggunakan tindakan kesalahan AWS FIS.
## Langkah implementasi
+ Tentukan kesalahan mana yang akan digunakan untuk eksperimen.
Lakukan penilaian desain beban kerja Anda untuk mengetahui ketahanannya. Desain tersebut (yang dibuat menggunakan praktik terbaik dari [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)) memperhitungkan risiko berdasarkan dependensi krusial, peristiwa terdahulu, masalah yang diketahui, dan persyaratan kepatuhan. Buat daftar yang berisi setiap elemen desain yang dimaksudkan untuk menjaga ketahanan dan kesalahan yang akan dimitigasi oleh elemen desain tersebut. Untuk informasi lebih lanjut tentang cara membuat daftar tersebut, lihat [laporan resmi Operational Readiness Review](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) yang memandu Anda tentang cara membuat proses untuk mencegah pengulangan insiden sebelumnya. Proses Analisis Mode dan Efek Kegagalan (FMEA) memberi Anda kerangka kerja untuk melakukan analisis tingkat komponen terhadap kegagalan dan bagaimana dampaknya terhadap beban kerja Anda. FMEA diuraikan secara lebih mendetail oleh Adrian Cockcroft dalam [Failure Modes and Continuous Resilience](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5).
+ Tetapkan prioritas untuk setiap kesalahan.
Mulailah dengan kategorisasi yang umum seperti tinggi, sedang, atau rendah. Untuk menilai prioritas, pertimbangkan frekuensi kesalahan dan dampak kegagalan terhadap beban kerja secara keseluruhan.
Saat mempertimbangkan frekuensi kesalahan tertentu, lakukan analisis pada data terdahulu untuk beban kerja ini jika tersedia. Jika tidak tersedia, gunakan data dari beban kerja lain yang berjalan di lingkungan yang serupa.
Ketika mempertimbangkan dampak dari kesalahan tertentu, makin besar cakupan kesalahan, biasanya makin besar dampaknya. Pertimbangkan juga desain dan tujuan beban kerja. Misalnya, kemampuan untuk mengakses penyimpanan data sumber sangat krusial untuk beban kerja yang melakukan transformasi dan analisis data. Dalam hal ini, Anda akan memprioritaskan eksperimen untuk kesalahan akses, serta akses yang di-throttling dan penyisipan latensi.
Analisis pascainsiden adalah sumber data yang baik untuk memahami frekuensi dan dampak mode kegagalan.
Gunakan prioritas yang ditetapkan untuk menentukan kesalahan mana yang akan digunakan terlebih dahulu dalam eksperimen beserta urutannya agar dapat mengembangkan eksperimen injeksi kesalahan baru.
+ Untuk setiap eksperimen yang Anda lakukan, gunakan roda chaos engineering dan ketahanan berkelanjutan.
![\[Diagram roda chaos engineering dan ketahanan berkelanjutan, yang menunjukkan fase Peningkatan, Kondisi stabil, Hipotesis, Pelaksanaan eksperimen, dan Verifikasi.\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/chaos-engineering-flywheel.png)
+ Definisikan kondisi stabil sebagai output terukur dari beban kerja yang menunjukkan perilaku normal.
Beban kerja Anda menunjukkan kondisi stabil jika beroperasi dengan andal dan seperti yang diharapkan. Oleh karena itu, validasikan bahwa beban kerja Anda berkondisi baik sebelum menentukan kondisi stabil. Dalam kondisi stabil, bukan berarti tidak akan ada dampak pada beban kerja saat terjadi kesalahan, karena sejumlah kesalahan tertentu mungkin berada dalam batas yang dapat diterima. Kondisi stabil adalah acuan dasar yang akan Anda amati selama eksperimen, yang akan menunjukkan anomali jika hipotesis yang Anda tentukan pada langkah berikutnya tidak berjalan seperti yang diharapkan.
Misalnya, kondisi stabil sistem pembayaran dapat didefinisikan sebagai pemrosesan 300 TPS dengan tingkat keberhasilan 99% dan waktu round-trip 500 md.
+ Bentuk hipotesis tentang bagaimana beban kerja akan bereaksi terhadap kesalahan.
Hipotesis yang baik didasarkan pada bagaimana beban kerja diharapkan akan memitigasi kesalahan untuk mempertahankan kondisi stabil. Hipotesis menyatakan bahwa dengan kesalahan jenis tertentu, sistem atau beban kerja akan terus berkondisi stabil karena beban kerja ini dirancang dengan mitigasi tertentu. Jenis spesifik kesalahan dan mitigasi harus ditentukan dalam hipotesis.
Templat berikut dapat digunakan untuk hipotesis (tetapi pernyataan lain juga dapat diterima):
**catatan**
Jika *[kesalahan tertentu]* terjadi, beban kerja *[nama beban kerja]* akan *[deskripsikan kontrol mitigasi]* untuk mempertahankan *[dampak metrik bisnis atau teknis]*.
Misalnya:
+ Jika 20% dari total simpul dalam grup simpul Amazon EKS dihapus, Transaction Create API akan terus melayani persentil ke-99 dari permintaan dalam waktu kurang dari 100 md (kondisi stabil). Simpul Amazon EKS akan pulih dalam waktu lima menit, dan pod akan dijadwalkan dan memproses lalu lintas dalam waktu delapan menit setelah dimulainya eksperimen. Peringatan akan diaktifkan dalam waktu tiga menit.
+ Jika terjadi kegagalan instans Amazon EC2 tunggal, pemeriksaan kondisi Elastic Load Balancing untuk sistem pemesanan akan membuat Elastic Load Balancing hanya mengirim permintaan ke instans berkondisi baik yang tersisa, sedangkan Amazon EC2 Auto Scaling mengganti instans yang gagal, sehingga mempertahankan peningkatan kesalahan sisi server (5xx) sebanyak kurang dari 0,01% (kondisi stabil).
+ Jika instans basis data Amazon RDS utama gagal, beban kerja pengumpulan data Rantai Pasokan akan melakukan failover dan terhubung ke instans basis data Amazon RDS yang siaga untuk mempertahankan kesalahan baca atau tulis basis data selama kurang dari 1 menit (kondisi stabil).
+ Jalankan eksperimen dengan menginjeksikan kesalahan.
Eksperimen secara default harus memiliki kemampuan fail-safe dan ditoleransi oleh beban kerja. Jika Anda tahu bahwa beban kerja akan gagal, jangan jalankan eksperimen. Chaos engineering harus digunakan untuk menemukan “known-unknown” atau “unknown-unknown”. *“Known-unknown”* adalah hal-hal yang Anda ketahui, tetapi tidak sepenuhnya dipahami, dan *“unknown-unknown”* adalah hal-hal yang tidak Anda ketahui atau pahami sepenuhnya. Bereksperimen dengan beban kerja yang Anda tahu dalam kondisi rusak tidak akan memberi Anda wawasan baru. Eksperimen Anda harus direncanakan dengan cermat, memiliki cakupan dampak yang jelas, dan menyediakan mekanisme rollback yang dapat diterapkan jika terjadi gangguan tak terduga. Jika uji tuntas Anda menunjukkan bahwa beban kerja Anda dapat bertahan dalam eksperimen, lanjutkan eksperimen. Ada beberapa opsi untuk menginjeksikan kesalahan. Untuk beban kerja di AWS, [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) menyediakan banyak simulasi kesalahan standar yang disebut [tindakan](https://docs.aws.amazon.com/fis/latest/userguide/actions.html). Anda juga dapat menentukan tindakan kustom yang berjalan di AWS FIS menggunakan [dokumen AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html).
Kami tidak menyarankan penggunaan skrip kustom untuk eksperimen chaos, kecuali jika skrip tersebut memiliki kemampuan untuk memahami status terkini beban kerja, mampu menghasilkan log, dan menyediakan mekanisme untuk rollback dan kondisi berhenti jika memungkinkan.
Kerangka kerja atau kumpulan alat efektif yang mendukung chaos engineering harus melacak kondisi terkini eksperimen, menghasilkan log, dan menyediakan mekanisme rollback untuk mendukung pelaksanaan eksperimen yang terkontrol. Mulailah dengan layanan andal seperti AWS FIS yang memungkinkan Anda melakukan eksperimen dengan cakupan yang jelas dan mekanisme keamanan yang melakukan rollback jika eksperimen menimbulkan gangguan tak terduga. Untuk mempelajari tentang beragam variasi eksperimen menggunakan AWS FIS, lihat juga [lab Aplikasi Tangguh dan Well-Architected dengan Chaos Engineering](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US). Selain itu, [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) akan menganalisis beban kerja Anda dan membuat eksperimen yang dapat Anda pilih untuk diterapkan dan dijalankan di AWS FIS.
**catatan**
Untuk setiap eksperimen, pahami dengan jelas cakupan dan dampaknya. Kami merekomendasikan bahwa kesalahan harus disimulasikan terlebih dahulu di lingkungan nonproduksi sebelum dijalankan dalam produksi.
Eksperimen harus dijalankan dalam produksi dengan beban dunia nyata menggunakan [deployment canary](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) yang melakukan deployment sistem kontrol dan eksperimental, jika memungkinkan. Menjalankan eksperimen selama waktu sepi adalah praktik yang baik untuk mengurangi potensi dampak saat pertama kali bereksperimen dalam produksi. Selain itu, jika menggunakan lalu lintas pelanggan yang sebenarnya akan menimbulkan terlalu banyak risiko, Anda dapat menjalankan eksperimen menggunakan lalu lintas sintetis di infrastruktur produksi terhadap deployment kontrol dan eksperimental. Jika tidak dapat menggunakan produksi, jalankan eksperimen di lingkungan praproduksi yang semirip mungkin dengan produksi.
Anda harus membuat dan memantau pagar pembatas untuk memastikan eksperimen tidak memengaruhi lalu lintas produksi atau sistem lain di luar batas yang dapat diterima. Tetapkan kondisi berhenti untuk menghentikan eksperimen jika mencapai ambang batas pada metrik pagar pembatas yang Anda tentukan. Hal ini harus mencakup metrik untuk kondisi stabil beban kerja, serta metrik berdasarkan komponen yang diinjeksi dengan kesalahan. Sebuah [pemantauan sintetis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (juga dikenal sebagai user canary) adalah salah satu metrik yang biasanya harus Anda sertakan sebagai proksi pengguna. [Kondisi berhenti untuk AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) didukung sebagai bagian dari templat eksperimen, sehingga memungkinkan maksimal lima kondisi berhenti per templat.
Salah satu prinsip chaos adalah meminimalkan cakupan eksperimen dan dampaknya:
Meskipun harus ada kelonggaran untuk beberapa dampak negatif dalam jangka pendek, Chaos Engineer bertanggung jawab dan berkewajiban untuk memastikan gangguan dari eksperimen diminimalkan dan dikendalikan.
Metode untuk memverifikasi cakupan dan dampak potensial adalah dengan melakukan eksperimen di lingkungan nonproduksi terlebih dahulu, memverifikasi bahwa ambang batas untuk kondisi berhenti diaktifkan seperti yang diharapkan selama eksperimen dan kemampuan pengamatan diterapkan untuk menemukan pengecualian, bukan langsung bereksperimen dalam produksi.
Saat menjalankan eksperimen injeksi kesalahan, verifikasikan bahwa semua pihak yang bertanggung jawab sudah mengetahui informasi yang jelas. Berkomunikasilah dengan tim yang sesuai seperti tim operasi, tim keandalan layanan, dan dukungan pelanggan untuk memberi tahu mereka kapan eksperimen akan dijalankan dan apa yang diharapkan. Berikan alat komunikasi kepada berbagai tim ini untuk memberi tahu tim tertentu yang menjalankan eksperimen jika muncul efek yang merugikan.
Anda harus memulihkan beban kerja dan sistem yang mendasarinya kembali ke kondisi awal yang diketahui berfungsi baik. Sering kali, desain beban kerja yang tangguh akan pulih sendiri. Namun, beberapa desain yang salah atau eksperimen yang gagal dapat membuat beban kerja Anda berada dalam kondisi kegagalan yang tidak terduga. Pada akhir eksperimen, Anda harus menyadari hal ini dan memulihkan beban kerja dan sistem. Dengan AWS FIS, Anda dapat mengatur konfigurasi rollback (juga disebut post action) dalam parameter tindakan. Post action mengembalikan target ke keadaan sebelum tindakan dijalankan. Baik diotomatiskan (seperti menggunakan AWS FIS) maupun manual, post action ini harus menjadi bagian dari playbook yang menjelaskan cara mendeteksi dan menangani kegagalan.
+ Verifikasikan hipotesisnya.
[Prinsip-prinsip Chaos Engineering](https://principlesofchaos.org/) memberikan panduan tentang cara memverifikasi kondisi stabil beban kerja Anda:
Fokus pada output terukur dari suatu sistem, bukan atribut internal sistem. Pengukuran output tersebut selama periode waktu yang singkat merupakan proksi untuk kondisi stabil sistem. Throughput sistem secara keseluruhan, tingkat kesalahan, dan persentil latensi semuanya dapat menjadi metrik penting yang merepresentasikan perilaku kondisi stabil. Dengan berfokus pada pola perilaku sistemik selama eksperimen, chaos engineering memverifikasi bahwa sistem berfungsi, bukan mencoba memvalidasi cara kerjanya.
Dalam dua contoh sebelumnya, kami menyertakan metrik kondisi stabil dengan peningkatan kesalahan sisi server (5xx) sebanyak kurang dari 0,01% serta kesalahan baca dan tulis basis data selama kurang dari satu menit.
Kesalahan 5xx adalah metrik yang baik karena merupakan konsekuensi dari mode kegagalan yang akan dialami langsung oleh klien yang menggunakan beban kerja. Pengukuran kesalahan basis data cocok digunakan sebagai konsekuensi langsung dari kesalahan, tetapi juga harus dilengkapi dengan pengukuran dampak klien seperti permintaan pelanggan yang gagal atau kesalahan yang muncul bagi klien. Selain itu, sertakan pemantauan sintetis (juga dikenal sebagai user canary) pada API atau URI apa pun yang diakses langsung oleh klien yang menggunakan beban kerja Anda.
+ Tingkatkan desain beban kerja agar memiliki ketahanan.
Jika kondisi stabil tidak dipertahankan, selidiki cara desain beban kerja dapat ditingkatkan untuk mengurangi kesalahan, dengan menerapkan praktik terbaik dari [pilar Keandalan AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). Panduan dan sumber daya tambahan dapat ditemukan di [AWS Builder’s Library](https://aws.amazon.com/builders-library/), yang berisi artikel tentang cara [meningkatkan pemeriksaan kondisi Anda](https://aws.amazon.com/builders-library/implementing-health-checks/) atau [menerapkan percobaan ulang dengan backoff dalam kode aplikasi Anda](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/), dll.
Setelah perubahan ini diterapkan, jalankan eksperimen lagi (ditunjukkan dengan garis putus-putus pada roda chaos engineering) untuk mengetahui keefektifannya. Jika langkah verifikasi menunjukkan bahwa hipotesisnya benar, beban kerja akan berada dalam kondisi stabil, dan siklusnya berlanjut.
+ Jalankan eksperimen secara rutin.
Eksperimen chaos adalah sebuah siklus, dan eksperimen harus dijalankan secara rutin sebagai bagian dari chaos engineering. Setelah beban kerja memenuhi hipotesis eksperimen, eksperimen harus diotomatiskan untuk terus berjalan sebagai bagian regresi dalam alur CI/CD Anda. Untuk mempelajari cara melakukannya, lihat blog tentang [cara menjalankan eksperimen AWS FIS menggunakan AWS CodePipeline](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/). Lab tentang [eksperimen AWS FIS berulang dalam alur CI/CD](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) memungkinkan Anda melakukan praktik langsung.
Eksperimen injeksi kesalahan juga merupakan bagian dari game day (lihat [REL12-BP06 Mengadakan game day secara rutin](rel_testing_resiliency_game_days_resiliency.md)). Game day mensimulasikan kegagalan atau peristiwa untuk memverifikasi sistem, proses, dan respons tim. Tujuannya adalah untuk benar-benar menerapkan tindakan yang perlu dilakukan oleh tim seolah memang terjadi peristiwa yang tidak diharapkan.
+ Catat dan simpan hasil eksperimen.
Hasil eksperimen injeksi kesalahan harus dicatat dan dijadikan persisten. Sertakan semua data yang diperlukan (seperti waktu, beban kerja, dan kondisi) agar dapat menganalisis hasil dan tren eksperimen nantinya. Contoh hasilnya dapat mencakup tangkapan layar dasbor, dump CSV dari basis data metrik Anda, atau catatan ketik manual yang berisi peristiwa dan pengamatan dari eksperimen. [Pencatatan log eksperimen dengan AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) dapat menjadi bagian dari pencatatan data ini.
## Sumber daya
**Praktik terbaik terkait:**
+ [REL08-BP03 Mengintegrasikan pengujian ketahanan sebagai bagian dari deployment Anda](rel_tracking_change_management_resiliency_testing.md)
+ [REL13-BP03 Menguji implementasi pemulihan bencana untuk memvalidasi implementasi](rel_planning_for_recovery_dr_tested.md)
**Dokumen terkait:**
+ [Apa itu AWS Fault Injection Service?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
+ [Apa itu AWS Resilience Hub?](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
+ [Prinsip-prinsip Chaos Engineering](https://principlesofchaos.org/)
+ [Chaos Engineering: Merencanakan eksperimen pertama Anda](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde)
+ [Rekayasa Ketahanan: Belajar untuk Mengatasi Kegagalan](https://queue.acm.org/detail.cfm?id=2371297)
+ [Kisah Chaos Engineering](https://github.com/ldomb/ChaosEngineeringPublicStories)
+ [Menghindari fallback dalam sistem terdistribusi](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)
+ [Deployment Canary untuk Eksperimen Chaos](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)
**Video terkait:**
+ [AWS re:Invent 2020: Menguji ketahanan menggunakan chaos engineering (ARC316)](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [AWS re:Invent 2019: Meningkatkan ketahanan dengan chaos engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
+ [AWS re:Invent 2019: Melakukan chaos engineering di dunia nirserver (CMY301)](https://www.youtube.com/watch?v=vbyjpMeYitA)
**Contoh terkait:**
+ [Lab Well-Architected: Level 300: Pengujian Ketahanan Amazon EC2, Amazon RDS, dan Amazon S3](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
+ [Lab Chaos Engineering di AWS](https://chaos-engineering.workshop.aws/en/)
+ [lab Aplikasi Tangguh dan Well-Architected dengan Chaos Engineering](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)
+ [Lab Chaos Nirserver](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless)
+ [Lab Ukur dan Tingkatkan Ketahanan Aplikasi Anda dengan AWS Resilience Hub](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab)
** Alat terkait: **
+ [AWS Fault Injection Service](https://aws.amazon.com/fis/)
+ AWS Marketplace: [Platform Chaos Engineering Gremlin](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney)
+ [Chaos Toolkit](https://chaostoolkit.org/)
+ [Chaos Mesh](https://chaos-mesh.org/)
+ [Litmus](https://litmuschaos.io/)
# REL12-BP06 Mengadakan game day secara rutin
Manfaatkan game day untuk secara rutin melatih prosedur Anda dalam merespons peristiwa dan kegagalan. Buat game day semirip mungkin dengan produksi (termasuk lingkungan produksi) bersama orang-orang yang akan terlibat dalam skenario kegagalan aktual. Game day menerapkan tindakan yang diperlukan guna memastikan peristiwa produksi tidak berdampak pada pengguna.
Game day menyimulasikan kegagalan atau peristiwa untuk menguji respons tim, sistem, dan proses. Tujuannya adalah untuk benar-benar menerapkan tindakan yang perlu dilakukan oleh tim seolah memang terjadi peristiwa yang tidak diharapkan. Hal ini akan membantu Anda memahami sisi mana yang perlu ditingkatkan dan membantu mengembangkan pengalaman organisasi dalam menangani peristiwa. Aktivitas ini harus dilakukan secara rutin untuk memperkuat *memori otot* dalam merespons kejadian tersebut.
Setelah desain ketangguhan Anda diterapkan dan diuji dalam lingkungan nonproduksi, game day dapat menjadi cara untuk memastikan bahwa segala sesuatu akan berjalan sesuai rencana ketika produksi. Game day, terutama yang dilakukan untuk pertama kali, merupakan aktivitas “wajib untuk semua tim”. Rekayasawan dan operasi akan diberitahu kapan ini dilakukan, dan apa yang akan terjadi. Runbook telah diterapkan. Simulasi peristiwa, termasuk peristiwa kegagalan yang mungkin terjadi, dieksekusi di sistem produksi dengan cara yang sudah ditentukan, dan dampaknya dievaluasi. Jika sistem beroperasi sesuai rancangan, deteksi dan pemulihan mandiri akan berlangsung dengan sedikit atau tanpa dampak. Namun, jika timbul dampak negatif, pengujian akan diulang dan masalah beban kerja diperbaiki, secara manual jika perlu (menggunakan runbook). Karena game day biasanya berlangsung di dalam produksi, semua pencegahan harus dilakukan guna memastikan bahwa ketersediaan untuk pelanggan tidak terganggu.
**Antipola umum:**
+ Mendokumentasikan prosedur Anda, tetapi tidak pernah melatihnya.
+ Tidak melibatkan pembuat keputusan bisnis dalam pengujian pelatihan.
**Manfaat menerapkan praktik terbaik ini:** Mengadakan game day secara rutin memastikan bahwa staf mengikuti kebijakan dan prosedur ketika insiden aktual terjadi, dan memvalidasi bahwa kebijakan dan prosedur tersebut sudah sesuai.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Jadwalkan game day untuk menggunakan runbook dan buku pedoman Anda secara rutin. Game day harus mengikutsertakan semua orang yang akan terlibat dalam kejadian produksi: pemilik bisnis, staf pengembangan, staf operasional, dan tim respons insiden.
+ Jalankan pengujian beban atau kinerja Anda, kemudian jalankan injeksi kegagalan.
+ Cari anomali dalam runbook Anda dan peluang untuk menggunakan buku pedoman Anda.
+ Jika Anda tidak mengikuti runbook, perbaiki runbook atau koreksi perilakunya. Jika Anda menggunakan buku pedoman, identifikasi buku pedoman yang seharusnya digunakan atau buat yang baru.
## Sumber daya
**Dokumen terkait:**
+ [Apa itu AWS GameDay?](https://aws.amazon.com/gameday/)
**Video terkait:**
+ [AWS re:Invent 2019: Meningkatkan ketahanan dengan chaos engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
**Contoh terkait:**
+ [Lab AWS Well-Architected - Pengujian Ketangguhan](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL 13. Bagaimana cara Anda mempersiapkan pemulihan bencana (DR)?
Memiliki cadangan dan komponen beban kerja berlebih adalah permulaan dari strategi DR Anda. [RTO dan RPO merupakan tujuan Anda](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) untuk pemulihan beban kerja Anda. Tetapkan ini berdasarkan kebutuhan bisnis. Implementasikan strategi untuk memenuhi tujuan-tujuan ini, sambil mempertimbangkan lokasi dan fungsi data dan sumber daya beban kerja. Probabilitas gangguan dan biaya pemulihan juga merupakan faktor penting yang membantu menginformasikan nilai bisnis dari penyediaan pemulihan bencana untuk beban kerja.
**Topics**
+ [REL13-BP01 Tetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 Menggunakan strategi pemulihan yang ditentukan untuk memenuhi sasaran pemulihan](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Menguji implementasi pemulihan bencana untuk memvalidasi implementasi](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Mengelola penyimpangan konfigurasi di lokasi atau Wilayah Pemulihan Bencana (DR)](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 Mengotomatiskan pemulihan](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 Tetapkan sasaran pemulihan untuk waktu henti dan kehilangan data
Beban kerja memiliki sasaran waktu pemulihan (RTO) dan sasaran titik pemulihan (RPO).
*Sasaran Waktu Pemulihan (RTO)* adalah penundaan maksimum yang dapat diterima antara gangguan layanan dan pemulihan layanan. Ini menentukan apa yang dianggap sebagai jendela waktu yang dapat diterima ketika layanan tidak tersedia.
*Sasaran Titik Pemulihan (RPO)* adalah jumlah waktu maksimum yang dapat diterima sejak titik pemulihan data terakhir. Ini menentukan apa yang dianggap sebagai kehilangan data yang dapat diterima antara titik pemulihan terakhir dan gangguan layanan.
Nilai RTO dan RPO merupakan pertimbangan penting ketika memilih strategi Pemulihan Bencana (DR) yang sesuai untuk beban kerja Anda. Sasaran-sasaran ini ditentukan oleh bisnis, kemudian digunakan oleh tim teknis untuk memilih dan mengimplementasikan strategi DR.
**Hasil yang Diinginkan:**
Setiap beban kerja memiliki penetapan RTO dan RPO, yang ditetapkan berdasarkan dampak bisnis. Beban kerja ditetapkan ke tingkat yang telah ditetapkan sebelumnya, yang menetapkan ketersediaan layanan dan kehilangan data yang dapat diterima, dengan RTO dan RPO terkait. Jika penetapan tingkat tersebut tidak dapat dilakukan, maka ini dapat diberi tingkat khusus yang disesuaikan per beban kerja, dengan maksud untuk membuat tingkat di lain waktu. RTO dan RPO digunakan sebagai salah satu pertimbangan utama untuk pemilihan implementasi strategi pemulihan bencana untuk beban kerja. Pertimbangan tambahan dalam memilih strategi DR yakni kendala biaya, ketergantungan beban kerja, dan persyaratan operasional.
Untuk RTO, pahami dampak berdasarkan durasi pemadaman. Apakah implikasinya linier, atau adakah implikasi non-linier? (contohnya, setelah empat jam, Anda mematikan jalur produksi sampai dimulainya giliran kerja berikutnya).
Matriks pemulihan bencana, seperti berikut ini, dapat membantu Anda memahami bagaimana kritikalitas beban kerja berkaitan dengan sasaran pemulihan. (Perhatikan, nilai aktual untuk sumbu X dan Y harus disesuaikan dengan kebutuhan organisasi Anda).
![\[Bagan yang memperlihatkan matriks pemulihan bencana\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/disaster-recovery-matrix.png)
**Antipola umum:**
+ Tidak ditetapkan sasaran pemulihan.
+ Memilih sasaran pemulihan semaunya.
+ Memilih sasaran pemulihan yang terlalu longgar dan tidak memenuhi tujuan bisnis.
+ Tidak memahami dampak waktu henti dan kehilangan data.
+ Memilih sasaran pemulihan yang tidak realistis, seperti tanpa adanya waktu untuk pemulihan dan tanpa adanya kehilangan data, yang mungkin tidak dapat dicapai untuk konfigurasi beban kerja Anda.
+ Memilih sasaran pemulihan yang lebih ketat daripada tujuan bisnis yang sesungguhnya. Ini memaksakan implementasi DR yang lebih mahal dan lebih rumit dibandingkan yang dibutuhkan beban kerja.
+ Memilih sasaran pemulihan yang tidak kompatibel dengan sasaran beban kerja yang bergantung.
+ Sasaran pemulihan Anda tidak mempertimbangkan persyaratan kepatuhan terhadap peraturan.
+ RTO dan RPO ditetapkan untuk beban kerja, tetapi tidak pernah diuji.
**Manfaat menerapkan praktik terbaik ini:** Sasaran pemulihan Anda untuk waktu dan kehilangan data diperlukan untuk memandu implementasi DR Anda.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Untuk beban kerja tertentu, Anda harus memahami dampak waktu henti dan kehilangan data pada bisnis Anda. Umumnya, dampak akan semakin meningkat jika waktu henti atau kehilangan data semakin besar, tetapi bentuk peningkatan ini bisa berbeda, tergantung pada jenis beban kerjanya. Contohnya, Anda mungkin dapat menoleransi waktu henti hingga satu jam dengan dampak kecil, tetapi setelah itu dampaknya meningkat dengan cepat. Ada banyak bentuk dampak pada bisnis, termasuk kerugian moneter (seperti hilangnya pendapatan), hilangnya kepercayaan pelanggan (dan dampak pada reputasi), masalah operasional (seperti penurunan produktivitas atau gaji tidak terbayarkan), dan risiko yang terkait dengan peraturan. Gunakan langkah-langkah berikut untuk memahami dampak-dampak ini, dan tetapkan RTO dan RPO untuk beban kerja Anda.
**Langkah Implementasi**
1. Tentukan pemangku kepentingan bisnis Anda untuk beban kerja ini, dan libatkan mereka untuk mengimplementasikan langkah-langkah ini. Sasaran pemulihan untuk beban kerja merupakan keputusan bisnis. Kemudian tim teknis bekerja dengan pemangku kepentingan bisnis untuk menggunakan sasaran-sasaran ini untuk memilih strategi DR.
**catatan**
Untuk langkah 2 dan 3, Anda dapat menggunakan [Lembar kerja implementasi](#implementation-worksheet).
1. Kumpulkan informasi yang diperlukan untuk mengambil keputusan dengan menjawab pertanyaan-pertanyaan di bawah ini.
1. Apakah Anda memiliki kategori atau tingkat kritikalitas untuk dampak beban kerja di organisasi Anda?
1. Jika ya, tetapkan beban kerja ini ke salah satu kategori
1. Jika tidak, maka tetapkan kategori-kategori ini. Buat lima kategori atau lebih sedikit dan sempurnakan rentang sasaran waktu pemulihan Anda untuk setiap kategori. Contoh kategori antara lain: kritis, tinggi, sedang, rendah. Untuk memahami cara pemetaan beban kerja ke kategori, pertimbangkan apakah beban kerja itu kritis untuk misi perusahaan, penting bagi bisnis, atau tidak mendorong bisnis.
1. Tetapkan RTO dan RPO beban kerja berdasarkan kategori. Selalu pilih kategori yang lebih ketat (RTO dan RPO lebih rendah) daripada nilai mentah yang dihitung saat memasuki langkah ini. Jika ini menghasilkan perubahan nilai yang besar dan tidak sesuai, maka pertimbangkan untuk membuat kategori baru.
1. Berdasarkan jawaban-jawaban ini, tetapkan nilai RTO dan RPO ke beban kerja. Ini dapat dilakukan secara langsung, atau dengan menetapkan beban kerja ke tingkat layanan yang ditetapkan sebelumnya.
1. Dokumentasikan rencana pemulihan bencana (DRP) untuk beban kerja ini, yang merupakan bagian dari [rencana keberlangsungan bisnis (BCP) organisasi Anda](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html), di lokasi yang dapat diakses oleh pemangku kepentingan dan tim beban kerja
1. Catat RTO dan RPO, dan informasi yang digunakan untuk menentukan nilai-nilai ini. Sertakan strategi yang digunakan untuk mengevaluasi dampak beban kerja pada bisnis
1. Catat metrik lain selain RTO dan RPO yang Anda lacak, atau rencanakan untuk melacak sasaran pemulihan bencana
1. Anda akan menambahkan detail strategi DR Anda dan runbook pada rencana ini ketika Anda membuat ini.
1. Dengan mencari kritikalitas beban kerja di dalam matriks seperti yang ada dalam Gambar 15, Anda dapat mulai menetapkan tingkat layanan yang ditetapkan di muka untuk organisasi Anda.
1. Setelah Anda mengimplementasikan strategi DR (atau bukti konsep untuk strategi DR) sesuai [REL13-BP02 Menggunakan strategi pemulihan yang ditentukan untuk memenuhi sasaran pemulihan](rel_planning_for_recovery_disaster_recovery.md), uji strategi ini untuk menentukan RPC (Kemampuan Titik Pemulihan) dan RTC (Kemampuan Waktu Pemulihan) aktual beban kerja. Jika ini tidak memenuhi sasaran pemulihan target, maka bekerjalah dengan pemangku kepentingan bisnis Anda untuk menyesuaikan sasaran-sasaran tersebut, atau buat perubahan pada strategi DR yang memungkinkan untuk memenuhi sasaran target.
**Pertanyaan utama**
1. Berapakah waktu henti maksimum untuk beban kerja sebelum timbul dampak serius pada bisnis?
1. Tentukan kerugian moneter (dampak finansial langsung) pada bisnis per menit jika beban kerja terganggu.
1. Pertimbangkan bahwa dampak tidak selalu linier. Pada awalnya, dampak bisa terbatas, tetapi kemudian meningkat dengan cepat melampaui titik kritis dalam waktu.
1. Berapakah jumlah data maksimum yang bisa hilang sebelum timbul dampak serius pada bisnis?
1. Pertimbangkan nilai ini untuk penyimpanan data Anda yang paling kritis. Identifikasi kritikalitas masing-masing untuk penyimpanan data lainnya.
1. Dapatkah data beban kerja dibuat jika hilang? Jika hal ini secara operasional lebih mudah daripada mencadangkan dan memulihkan, maka pilih RPO berdasarkan kritikalitas data sumber yang digunakan untuk membuat ulang data beban kerja.
1. Apa saja sasaran pemulihan dan harapan ketersediaan beban kerja yang hal ini andalkan (hilir), atau beban kerja yang mengandalkan hal ini (hulu)?
1. Pilih sasaran pemulihan yang memampukan beban kerja ini untuk memenuhi persyaratan ketergantungan hulu
1. Pilih sasaran pemulihan yang dapat dicapai mengingat kemampuan pemulihan ketergantungan hilir. Ketergantungan hilir non-kritis (yang dapat Anda “tangani”) dapat dikecualikan. Atau, bekerjalah dengan ketergantungan hilir kritis atau tingkatkan kemampuan pemulihannya apabila perlu.
**Pertanyaan tambahan**
Pertimbangkan pertanyaan-pertanyaan ini, dan bagaimana pertanyaan tersebut mungkin berlaku pada beban kerja ini:
1. Apakah Anda memiliki RTO dan RPO yang berbeda, tergantung pada jenis pemadaman (Wilayah vs. AZ, dll.)?
1. Apakah ada waktu spesifik (musim, acara penjualan, peluncuran produk) ketika RTO/RPO Anda mungkin berubah? Jika ya, apakah batas waktu dan pengukurannya yang berbeda?
1. Berapa jumlah pelanggan yang akan terkena dampak jika beban kerja terganggu?
1. Apakah dampak pada reputasi jika beban kerja terganggu?
1. Dampak operasional lain apakah yang dapat timbul jika beban kerja terganggu? Contohnya, dampak pada produktivitas karyawan jika sistem email tidak tersedia, atau jika sistem Gaji tidak dapat mengirimkan transaksi.
1. Bagaimanakah RTO dan RPO beban kerja sesuai dengan Strategi DR Organisasi dan Bidang Bisnis?
1. Apakah ada kewajiban kontrak internal untuk memberikan layanan? Apakah ada penalti jika tidak memenuhinya?
1. Apa saja kendala kepatuhan atau peraturan terkait data?
## Lembar kerja implementasi
Anda dapat menggunakan lembar kerja ini untuk langkah implementasi 2 dan 3. Anda dapat menyesuaikan lembar kerja ini agar cocok dengan kebutuhan spesifik Anda, seperti menambahkan pertanyaan tambahan.
![\[Lembar kerja\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/worksheet.png)
**Tingkat upaya untuk Rencana Implementasi: **Rendah
## Sumber daya
**Praktik Terbaik Terkait:**
+ [REL09-BP04 Melakukan pemulihan data secara berkala untuk memverifikasi integritas dan proses pencadangan](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 Menggunakan strategi pemulihan yang ditentukan untuk memenuhi sasaran pemulihan](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Menguji implementasi pemulihan bencana untuk memvalidasi implementasi](rel_planning_for_recovery_dr_tested.md)
**Dokumen terkait:**
+ [Blog Arsitektur AWS: Seri Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Pemulihan Bencana Beban Kerja di AWS: Pemulihan di Cloud (Laporan Resmi AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Mengelola kebijakan ketangguhan dengan Pusat Ketangguhan AWS](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [Partner APN: partner yang dapat membantu pemulihan bencana](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: produk yang dapat digunakan untuk pemulihan bencana](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Video terkait:**
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Pemulihan Bencana Beban Kerja di AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 Menggunakan strategi pemulihan yang ditentukan untuk memenuhi sasaran pemulihan
Tentukan strategi pemulihan bencana (DR) yang memenuhi sasaran pemulihan beban kerja. Pilih strategi seperti pencadangan dan pemulihan, standby (aktif/pasif), atau aktif/aktif.
**Hasil yang diinginkan:** Strategi DR ditentukan dan diimplementasikan untuk setiap beban kerja agar beban kerja dapat mencapai sasaran DR. Strategi DR antara beban kerja menggunakan pola yang dapat digunakan kembali (seperti strategi yang telah dijelaskan sebelumnya),
**Antipola umum:**
+ Mengimplementasikan prosedur pemulihan yang tidak konsisten untuk beban kerja dengan sasaran DR yang serupa.
+ Membiarkan strategi DR diimplementasikan secara ad-hoc saat bencana terjadi.
+ Tidak memiliki rencana untuk pemulihan bencana.
+ Dependensi pada operasi bidang kendali selama pemulihan.
**Manfaat menjalankan praktik terbaik ini:**
+ Dengan strategi pemulihan yang ditentukan, Anda dapat menggunakan prosedur tes dan peralatan umum.
+ Menggunakan strategi pemulihan yang ditentukan akan meningkatkan penyebaran pengetahuan antara tim dan implementasi DR pada beban kerja milik mereka.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi. Tanpa strategi DR yang direncanakan, diimplementasikan, dan diuji, Anda akan kesulitan mencapai sasaran pemulihan ketika bencana terjadi.
## Panduan implementasi
Strategi DR mengandalkan kemampuan untuk mempertahankan beban kerja di situs pemulihan jika lokasi utama tidak dapat menjalankan beban kerja. Sasaran pemulihan yang paling umum adalah RTO dan RPO, seperti yang didiskusikan dalam [REL13-BP01 Tetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md).
Strategi DR di beberapa Zona Ketersediaan (AZ) dalam Wilayah AWS tunggal, dapat menyediakan mitigasi bencana seperti kebakaran, banjir, dan pemadaman listrik besar-besaran. Anda dapat menggunakan strategi DR yang menggunakan beberapa Wilayah jika memang perlu mengimplementasikan perlindungan terhadap peristiwa yang membuat beban kerja tidak dapat dijalankan di Wilayah AWS.
Anda harus memilih salah satu dari strategi berikut saat merancang strategi DR di beberapa Wilayah. Strategi didaftar dan diurutkan berdasarkan biaya dan kompleksitas dari kecil ke besar, serta diurutkan berdasarkan RTO dan RPO dari besar ke kecil. *Wilayah Pemulihan* berarti Wilayah AWS selain dari yang utama yang digunakan untuk beban kerja Anda.
![\[Diagram menampilkan strategi DR\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/disaster-recovery-strategies.png)
+ **Pencadangan dan pemulihan** (RPO dalam jam, RTO dalam 24 jam atau kurang): Cadangkan data dan aplikasi ke dalam Wilayah pemulihan. Menggunakan pencadangan otomatis atau berkelanjutan dapat mengaktifkan pemulihan titik waktu, yang dalam beberapa kasus dapat menurunkan RPO hingga 5 menit. Saat terjadi bencana, Anda akan melakukan deployment infrastruktur (menggunakan infrastruktur sebagai kode untuk mengurangi RTO), melakukan deploymennt kode, dan memulihkan data yang dicadangkan untuk memulihkan dari bencana di Wilayah pemulihan.
+ **Pilot light** (RPO dalam menit, RTO dalam kelipatan sepuluh menit): Sediakan salinan infrastruktur beban kerja inti di Wilayah pemulihan. Replikasikan data ke Wilayah pemulihan dan buat cadangan di sana. Sumber daya yang diperlukan untuk mendukung replikasi dan pencadangan data, misalnya basis data dan penyimpanan objek, selalu aktif. Elemen lainnya seperti server aplikasi atau komputasi nirserver tidak di-deploy, tetapi dapat dibuat saat dibutuhkan dengan kode aplikasi dan konfigurasi yang diperlukan.
+ **Warm standby** (RPO dalam detik, RTO dalam menit): Pertahankan beban kerja dalam versi yang diturunkan skalanya tetapi berfungsi sepenuhnya yang selalu dijalankan di Wilayah pemulihan. Sistem bisnis kritis sepenuhnya digandakan dan selalu diaktifkan, tetapi dengan armada yang diturunkan skalanya. Data direplikasi dan berada dalam Wilayah pemulihan. Saat memasuki waktu pemulihan, sistem dinaikkan skalanya dengan cepat untuk menangani beban produksi. Semakin warm standby dinaikkan skalanya, akan semakin rendah pengandalan RTO dan bidang kendali. Ketika diskalakan sepenuhnya, ini disebut sebagai *hot standby*.
+ **Multi-Wilayah (multi-situs) aktif-aktif** (RPO mendekati nol, RTO berpotensi nol): Beban kerja di-deploy ke, dan aktif menangani lalu lintas dari, beberapa Wilayah AWS. Strategi ini perlu menyinkronkan data di seluruh Wilayah. Konflik potensial yang disebabkan oleh menulis catatan yang sama di dua replika wilayah yang berbeda harus dihindari atau ditangani, karena bisa menjadi kompleks. Replikasi data bermanfaat untuk sinkronisasi data dan akan melindungi Anda terhadap beberapa jenis bencana, tetapi tidak melindungi terhadap kerusakan atau kehilangan data kecuali solusi juga disertai opsi untuk pemulihan titik waktu.
**catatan**
Perbedaan antara pilot light dan warm standby terkadang sulit dimengerti. Keduanya menyertakan lingkungan di Wilayah pemulihan dengan salinan aset wilayah utama. Perbedaannya adalah pilot light tidak dapat memproses permintaan tanpa lebih dulu melakukan tindakan tambahan, sedangkan warm standby dapat menangani lalu lintas (pada kapasitas yang dikurangi) dengan cepat. Pilot light mengharuskan Anda mengaktifkan server, menaikkan skala, dan mungkin mengharuskan Anda melakukan deployment infrastruktur tambahan (bukan inti). Sementara itu, warm standby hanya meminta Anda untuk menaikkan skala (semuanya sudah di-deploy dan dijalankan). Pilih berdasarkan kebutuhan RTO dan RPO Anda.
Apabila ada kekhawatiran tentang biaya, dan Anda ingin mencapai sasaran RPO dan RTO yang serupa dengan yang ditetapkan dalam strategi warm standby, Anda dapat mempertimbangkan solusi cloud native, seperti AWS Elastic Disaster Recovery, yang mengambil pendekatan pilot light dan menawarkan target RPO dan RTO lebih baik.
**Langkah implementasi**
1. **Tentukan strategi DR yang akan memenuhi persyaratan pemulihan untuk beban kerja ini.**
Saat memilih strategi DR, Anda harus memilih antara mengurangi waktu henti dan kehilangan data (RTO dan RPO) dan meningkatkan biaya dan kompleksitas untuk mengimplementasikan strategi, atau sebaliknya. Sebaiknya hindari strategi yang lebih sulit dari yang dibutuhkan, karena hal ini akan menambah biaya yang tidak perlu.
Misalnya, dalam diagram berikut, bisnis telah menentukan RTO maksimum yang diizinkan serta batas yang dapat digunakan pada strategi pemulihan layanan. Berdasarkan sasaran bisnis, strategi DR pilot light atau warm standby akan memenuhi kriteria biaya dan RTO.
![\[Grafik yang menampilkan pemilihan strategi DR berdasarkan RTO dan biaya\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/choosing-a-dr-strategy.png)
Untuk mempelajari selengkapnya, lihat [Rencana Keberlangsungan Bisnis (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html).
1. **Tinjau pola tentang bagaimana strategi DR yang dipilih dapat diimplementasikan.**
Langkah ini digunakan untuk memahami cara Anda mengimplementasikan strategi yang dipilih. Strategi dijelaskan menggunakan Wilayah AWS sebagai situs utama dan pemulihan. Namun, Anda juga dapat memilih untuk menggunakan Zona Ketersediaan dalam Wilayah tunggal sebagai strategi DR, yang menggunakan beberapa elemen dari berbagai strategi tersebut.
Dalam langkah berikut ini, Anda dapat menerapkan strategi pada beban kerja spesifik Anda.
**Pencadangan dan pemulihan**
*Pencadangan dan pemulihan* adalah strategi yang tidak terlalu kompleks untuk diimplementasikan, tetapi akan memerlukan waktu dan usaha lebih untuk mengembalikan beban kerja, sehingga RTO dan RPO menjadi lebih tinggi. Sebaiknya selalu buat cadangan data, dan salin cadangan tersebut ke situs lain (misalnya Wilayah AWS lain).
![\[Diagram menampilkan arsitektur cadangan dan pemulihan\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/backup-restore-architecture.png)
Untuk detail selengkapnya tentang strategi ini, lihat [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian II: Pencadangan dan Pemulihan dengan Pemulihan Cepat](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**Pilot light**
Dengan pendekatan *pilot light*, Anda mereplikasi data dari Wilayah utama ke Wilayah pemulihan. Sumber daya inti yang digunakan untuk infrastruktur beban kerja di-deploy di Wilayah pemulihan. Namun, sumber daya tambahan dan dependensi lainnya masih diperlukan untuk membuat tumpukan fungsional ini. Misalnya, dalam gambar 20, tidak ada instans komputasi yang di-deploy.
![\[Diagram menampilkan arsitektur pilot light\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/pilot-light-architecture.png)
Untuk detail selengkapnya tentang strategi ini, lihat [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian III: Pilot Light dan Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Warm standby**
Pendekatan *warm standby* memastikan ada salinan lingkungan produksi yang skalanya diturunkan tetapi berfungsi sepenuhnya di Wilayah lainnya. Pendekatan ini memperpanjang konsep pilot light dan mempercepat waktu pemulihan karena beban kerja selalu aktif di Wilayah lainnya. Jika Wilayah pemulihan di-deploy pada kapasitas penuh, hal ini disebut dengan *hot standby*.
![\[Diagram menampilkan Gambar 21: Arsitektur warm standby\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/warm-standby-architecture.png)
Saat menggunakan warm standby atau pilot light, Anda perlu menaikkan skala sumber daya di Wilayah pemulihan. Untuk memverifikasi kapasitas tersedia ketika diperlukan, pertimbangkan penggunaan [reservasi kapasitas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) untuk instans EC2. Jika menggunakan AWS Lambda, maka [konkurensi yang disediakan](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) dapat menyediakan lingkungan pelaksanaan sehingga siap untuk merespons dengan segera ke panggilan fungsi Anda.
Untuk detail selengkapnya tentang strategi ini, lihat [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian III: Pilot Light dan Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Multi-situs aktif/aktif**
Anda dapat menjalankan beban kerja secara bersamaan di beberapa Wilayah sebagai bagian dari strategi *multi-situs aktif/aktif*. Multi-situs aktif/aktif menjalankan lalu lintas dari semua wilayah ke wilayah tempatnya di-deploy. Pelanggan dapat memilih strategi ini untuk alasan selain DR. Strategi ini dapat digunakan untuk meningkatkan ketersediaan, atau saat melakukan deployment beban kerja ke audiens global (untuk menempatkan titik akhir lebih dekat dengan pengguna dan/atau melakukan deployment tumpukan yang dilokalkan untuk audiens di wilayah tersebut). Sebagai strategi DR, jika beban kerja tidak dapat didukung di salah satu dari Wilayah AWS tempatnya di-deploy, Wilayah tersebut dievakuasi, dan Wilayah sisanya digunakan untuk mempertahankan ketersediaan. Multi-situs aktif/aktif adalah strategi DR yang paling sulit dioperasikan, dan sebaiknya hanya dipilih saat persyaratan bisnis mengharuskannya.
![\[Diagram menampilkan arsitektur multi-situs aktif/aktif\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/multi-site-active-active-architecture.png)
Untuk detail selengkapnya tentang strategi ini, lihat [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian IV: Multi-situs Aktif/Aktif](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**AWS Elastic Disaster Recovery**
Jika Anda mempertimbangkan strategi pilot light atau warm standby untuk pemulihan bencana, AWS Elastic Disaster Recovery dapat memberikan pendekatan alternatif dengan peningkatan manfaat. Elastic Disaster Recovery dapat menawarkan target RPO dan RTO yang serupa dengan warm standby, tetapi mempertahankan pendekatan pilot light dengan biaya rendah. Elastic Disaster Recovery mereplikasi data Anda dari wilayah utama ke Wilayah pemulihan, menggunakan perlindungan data berkelanjutan untuk mencapai RPO yang diukur dalam detik dan RTO yang dapat diukur dalam menit. Hanya sumber daya yang diperlukan untuk mereplikasi data yang di-deploy di wilayah pemulihan, yang menekan biaya tetap rendah, serupa dengan strategi pilot light. Ketika menggunakan Elastic Disaster Recovery, layanan mengoordinasi dan mengatur pemulihan sumber daya komputasi ketika dimulai sebagai bagian dari failover atau latihan.
![\[Diagram arsitektur yang menjelaskan cara AWS Elastic Disaster Recovery beroperasi.\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/drs-architecture.png)
**Praktik tambahan untuk melindungi data**
Dengan semua strategi, Anda juga harus melakukan mitigasi terhadap bencana data. Replikasi data berkelanjutan melindungi Anda terhadap beberapa jenis bencana, tetapi tidak melindungi terhadap kerusakan atau kehilangan data kecuali strategi juga disertai versioning data yang disimpan atau opsi pemulihan titik waktu. Selain replika, Anda juga harus mencadangkan data yang direplikasi di situs pemulihan untuk membuat pencadangan titik waktu.
**Menggunakan beberapa Zona Ketersediaan (AZ) dalam Wilayah AWS tunggal**
Saat menggunakan beberapa AZ dalam Wilayah tunggal, implementasi DR Anda menggunakan beberapa elemen dari strategi di atas. Anda harus terlebih dahulu membuat arsitektur ketersediaan tinggi (HA) menggunakan beberapa AZ yang ditampilkan dalam Gambar 23. Arsitektur ini memanfaatkan pendekatan multi-situs aktif/aktif, karena [instans Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) dan [Penyeimbang Beban Elastis](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) memiliki sumber daya yang di-deploy di beberapa AZ, yang secara aktif menangani permintaan. Arsitektur ini juga mendemonstrasikan hot standby, di mana jika instans [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) utama gagal (atau AZ itu sendiri gagal), maka instans standby dipromosikan ke utama.
![\[Diagram menampilkan Gambar 24: Arsitektur Multi-AZ\]](http://docs.aws.amazon.com/id_id/wellarchitected/2023-10-03/framework/images/multi-az-architecture2.png)
Selain arsitektur HA ini, Anda perlu menambahkan cadangan data yang dibutuhkan untuk menjalankan beban kerja. Hal ini sangat penting untuk data yang dibatasi ke zona tunggal seperti [volume Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) atau [klaster Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Jika sebuah AZ gagal, Anda perlu memulihkan data ini ke AZ lainnya. Jika memungkinkan, Anda perlu menyalin cadangan data ke Wilayah AWS sebagai lapisan perlindungan tambahan.
Pendekatan alternatif yang kurang umum untuk DR multi-AZ Wilayah tunggal diilustrasikan di posting blog ini, [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/). Strategi yang digunakan di sini adalah mempertahankan isolasi sebanyak mungkin di antara AZ, seperti bagaimana Wilayah dioperasikan. Dengan menggunakan strategi alternatif ini, Anda dapat memilih pendekatan aktif/aktif atau aktif/pasif.
**catatan**
Beberapa beban kerja memiliki persyaratan residensi data peraturan. Jika ini diterapkan untuk beban kerja di lokalitas yang saat ini hanya memiliki satu Wilayah AWS, maka multi-Wilayah tidak akan sesuai untuk kebutuhan bisnis. Strategi multi-AZ memberikan perlindungan yang baik terhadap sebagian besar bencana.
1. **Evaluasikan sumber daya beban kerja, dan seperti apa konfigurasinya di Wilayah pemulihan sebelum failover (selama operasi normal).**
Untuk infrastruktur dan sumber daya AWS, gunakan infrastruktur sebagai kode seperti [AWS CloudFormation](https://aws.amazon.com/cloudformation) atau alat pihak ketiga seperti Hashicorp Terraform. Untuk melakukan deployment di beberapa akun dan Wilayah dengan operasi tunggal, Anda dapat menggunakan [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). Untuk strategi Multi-situs aktif/aktif dan Hot Standby, infrastruktur yang di-deploy di Wilayah pemulihan memiliki sumber daya yang sama seperti Wilayah utama. Untuk strategi Pilot Light dan Warm Standby, infrastruktur yang di-deploy memerlukan tindakan tambahan agar berubah menjadi siap produksi. Dengan menggunakan [parameter](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) dan [logika bersyarat](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html) CloudFormation, Anda dapat mengontrol tumpukan yang di-deploy agar aktif atau standby dengan [templat tunggal](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/). Ketika menggunakan Elastic Disaster Recovery, layanan akan mereplikasi dan mengatur pemulihan konfigurasi aplikasi dan sumber daya komputasi.
Semua strategi DR memerlukan sumber data yang dicadangkan dalam Wilayah AWS, dan cadangan tersebut disalin ke Wilayah pemulihan. [AWS Backup](https://aws.amazon.com/backup/) memberikan tampilan terpusat tempat Anda dapat mengonfigurasi, menjadwalkan, dan memantau cadangan untuk sumber daya ini. Untuk Pilot Light, Warm Standby, dan Multi-situs aktif/aktif, Anda juga harus mereplikasi data dari Wilayah utama ke sumber daya data di Wilayah pemulihan, seperti instans DB [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) atau tabel [Amazon DynamoDB](https://aws.amazon.com/dynamodb). Dengan demikian, sumber data ini aktif dan siap menangani permintaan di Wilayah pemulihan.
Untuk mempelajari lebih lanjut tentang cara layanan AWS beroperasi di seluruh Wilayah, lihat seri blog ini di [Membuat Aplikasi Multi-Wilayah dengan Layanan AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **Tentukan dan implementasikan cara Anda mempersiapkan Wilayah untuk failover saat dibutuhkan (selama peristiwa bencana).**
Untuk multi-situs aktif/aktif, failover berarti mengevakuasi Wilayah dan mengandalkan Wilayah aktif yang tersisa. Secara umum, Wilayah tersebut siap menerima lalu lintas. Untuk strategi Pilot Light dan Warm Standby, tindakan pemulihan perlu mencakup deployment sumber daya yang hilang, seperti instans EC2 dalam Gambar 20, juga sumber daya yang hilang lainnya.
Untuk semua strategi di atas, Anda mungkin perlu mengubah instans hanya-baca basis data menjadi instans baca/tulis.
Untuk pencadangan dan pemulihan, pemulihan data dari cadangan menghasilkan sumber daya untuk data tersebut seperti volume EBS, instans RDS DB, dan tabel DynamoDB. Anda juga perlu memulihkan infrastruktur dan melakukan deployment kode. Anda dapat menggunakan AWS Backup untuk memulihkan data di Wilayah pemulihan. Lihat [REL09-BP01 Mengidentifikasi dan mencadangkan data yang perlu dicadangkan, atau memproduksi ulang data dari sumber](rel_backing_up_data_identified_backups_data.md) untuk detail lebih lanjut. Saat membangun kembali infrastruktur, Anda juga membuat sumber daya seperti instans EC2 sebagai tambahan untuk [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), subnet, dan grup keamanan yang diperlukan. Anda dapat mengotomatiskan banyak proses pemulihan. Untuk mempelajari caranya, lihat [posting blog ini](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **Tentukan dan implementasikan cara Anda merutekan kembali lalu lintas ke failover saat dibutuhkan (selama peristiwa bencana).**
Operasi failover ini dapat dimulai secara otomatis dan manual. Failover yang dimulai secara otomatis berdasarkan pemeriksaan kondisi atau alarm harus digunakan dengan hati-hati karena failover yang tidak perlu (alarm palsu) dapat dikenakan biaya seperti ketidaktersediaan dan kehilangan data. Oleh karena itu, Failover yang dimulai secara manual sering digunakan. Dalam kasus ini, Anda masih harus mengotomatiskan langkah failover, sehingga inisiasi manual akan seperti menekan tombol.
Ada beberapa opsi manajemen lalu lintas yang perlu dipertimbangkan saat menggunakan layanan AWS. Salah satu opsinya adalah menggunakan [Amazon Route 53](https://aws.amazon.com/route53). Dengan menggunakan Amazon Route 53, Anda dapat mengaitkan beberapa titik akhir IP di satu Wilayah AWS atau lebih dengan nama domain Route 53. Untuk mengimplementasikan failover yang dimulai secara manual, Anda dapat menggunakan [Pengontrol Pemulihan Aplikasi Amazon Route 53](https://aws.amazon.com/route53/application-recovery-controller/), yang memberikan API bidang data dengan ketersediaan tinggi untuk merutekan kembali lalu lintas ke Wilayah pemulihan. Saat mengimplementasikan failover, gunakan operasi bidang data dan hindari bidang kendali yang dideskripsikan di [REL11-BP04 Mengandalkan bidang data dan bukan bidang kendali selama pemulihan](rel_withstand_component_failures_avoid_control_plane.md).
Untuk mempelajari selengkapnya tentang hal ini dan opsi lainnya, lihat [bagian ini di Laporan Resmi Pemulihan Bencana](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light).
1. **Rancang rencana terkait bagaimana beban kerja akan failback.**
Failback adalah saat Anda mengembalikan operasi beban kerja ke Wilayah utama, setelah bencana berakhir. Penyediaan infrastruktur dan kode untuk Wilayah utama umumnya mengikuti langkah yang sama yang digunakan saat memulai, dengan mengandalkan infrastruktur sebagai kode dan pipeline deployment kode. Tantangan failback adalah mengembalikan penyimpanan data, dan memastikan konsistensi dengan Wilayah pemulihan dalam operasi.
Dalam status failed over, basis data dalam Wilayah pemulihan bersifat waktu nyata dan memiliki data terbaru. Tujuannya adalah untuk menyinkronkan kembali dari Wilayah pemulihan ke Wilayah utama, memastikannya tetap terbaru.
Hal ini dilakukan secara otomatis untuk beberapa layanan AWS. Jika menggunakan [tabel global Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/), meskipun tabel di Wilayah utama menjadi tidak tersedia, saat kembali online, DynamoDB akan melanjutkan penulisan yang tertunda. Jika menggunakan [Basis Data Global Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/) dan menggunakan [failover terencana dan terkelola](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover), maka topologi replikasi yang ada untuk basis data global Aurora dipertahankan. Dengan demikian, instans baca/tulis sebelumnya di Wilayah utama akan menjadi replika dan menerima pembaruan dari Wilayah pemulihan.
Dalam kasus saat ini tidak dibuat otomatis, Anda perlu menetapkan ulang basis data di Wilayah utama sebagai replika dari basis data di Wilayah pemulihan. Dalam banyak kasus, ini akan melibatkan penghapusan basis data utama yang lama dan membuat replika yang baru. Misalnya, untuk instruksi tentang cara melakukan ini dengan Basis Data Global Amazon Aurora yang mengasumsikan failover *tak terencana*, lihat lab ini: [Fail Back Basis Data Global](https://awsauroralabsmy.com/global/failback/).
Setelah failover, jika Anda dapat tetap menjalankannya di Wilayah pemulihan, pertimbangkan untuk membuat ini menjadi Wilayah utama yang baru. Anda masih harus melakukan semua langkah di atas untuk membuat Wilayah utama sebelumnya menjadi Wilayah pemulihan. Beberapa organisasi melakukan rotasi terjadwal, menukar Wilayah utama dan pemulihan secara berkala (misalnya setiap tiga bulan).
Semua langkah yang diperlukan untuk failover dan failback harus diperiksa di buku pedoman yang tersedia untuk semua anggota tim dan ditinjau secara berkala.
Ketika menggunakan Elastic Disaster Recovery, layanan akan membantu mengatur dan mengotomatiskan proses failback. Untuk detail selengkapnya, lihat [Melakukan failback](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html).
**Tingkat upaya untuk rencana implementasi:** Tinggi
## Sumber daya
**Praktik Terbaik Terkait:**
+ [REL09-BP01 Mengidentifikasi dan mencadangkan data yang perlu dicadangkan, atau memproduksi ulang data dari sumber](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 Mengandalkan bidang data dan bukan bidang kendali selama pemulihan](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 Tetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md)
**Dokumen terkait:**
+ [Blog Arsitektur AWS: Seri Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Pemulihan Bencana Beban Kerja di AWS: Pemulihan di Cloud (Laporan Resmi AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Opsi pemulihan bencana di cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [Bangun solusi backend aktif-aktif nirserver multi-wilayah dalam satu jam](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Backend nirserver multi-wilayah — dimuat ulang](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS: Mereplikasi Replika Baca di Seluruh Wilayah](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53: Mengonfigurasi Failover DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3: Replika Lintas-Wilayah](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [Apa Itu AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Apa itu Pengontrol Pemulihan Aplikasi Route 53?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: Memulai - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [Partner APN: partner yang dapat membantu pemulihan bencana](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: produk yang dapat digunakan untuk pemulihan bencana](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Video terkait:**
+ [Pemulihan Bencana Beban Kerja di AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Memulai AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**Contoh terkait:**
+ [Well-Architected Lab - Pemulihan Bencana](https://wellarchitectedlabs.com/reliability/disaster-recovery/) - Seri lokakarya yang mengilustrasikan strategi DR
# REL13-BP03 Menguji implementasi pemulihan bencana untuk memvalidasi implementasi
Secara rutin uji failover ke situs pemulihan Anda untuk memastikan operasi yang baik dan RTO serta RPO terpenuhi.
**Antipola umum:**
+ Tidak pernah melakukan failover di lingkungan produksi.
**Manfaat menjalankan praktik terbaik ini:** Pengujian rencana pemulihan bencana secara rutin memverifikasi bahwa rencana tersebut akan berfungsi saat diperlukan, dan tim Anda tahu cara menjalankan strategi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Pola untuk dihindari adalah mengembangkan jalur pemulihan yang sangat jarang dilakukan. Misalnya, Anda mungkin memiliki penyimpanan data sekunder yang digunakan untuk kueri hanya-baca. Saat Anda menulis ke penyimpanan data dan penyimpanan primer gagal, Anda mungkin ingin melakukan failover ke penyimpanan data sekunder. Jika Anda tidak sering menguji failover ini, Anda mungkin akan mendapati bahwa asumsi Anda tentang kemampuan penyimpanan data sekunder ternyata salah. Kapasitas sekunder, yang selama ini mungkin mencukupi saat terakhir Anda uji, mungkin sudah tidak mampu mentoleransi beban di bawah skenario ini. Pengalaman kami menunjukkan bahwa satu-satunya pemulihan kesalahan yang berfungsi adalah jalur yang Anda uji secara sering. Inilah alasan memiliki sedikit jalur pemulihan adalah yang terbaik. Anda dapat membuat pola pemulihan dan mengujinya secara rutin. Jika Anda memiliki jalur pemulihan yang kompleks atau kritis, Anda tetap perlu secara rutin melatih kegagalan tersebut dalam lingkungan produksi agar Anda yakin bahwa jalur pemulihan tersebut berfungsi. Pada contoh yang baru saja kita bahas, Anda harus melakukan failover ke penyimpanan siaga secara rutin, terlepas ada tidaknya kebutuhan.
**Langkah implementasi**
1. Rekayasa beban kerja Anda untuk pemulihan. Uji jalur pemulihan Anda secara rutin. Komputasi yang berorientasi pada pemulihan mengidentifikasi karakteristik dalam sistem yang meningkatkan pemulihan: isolasi dan redundansi, kemampuan di seluruh sistem untuk membatalkan perubahan, kemampuan untuk memantau dan menentukan kondisi, kemampuan untuk menyediakan diagnostik, pemulihan otomatis, desain modular, dan kemampuan untuk memulai ulang. Latih jalur pemulihan untuk memverifikasi bahwa Anda dapat menyelesaikan pemulihan dalam waktu yang ditentukan ke status yang ditentukan. Gunakan runbook selama pemulihan ini untuk mendokumentasikan masalah dan menemukan solusinya sebelum pengujian berikutnya.
1. Untuk beban kerja berbasis Amazon EC2, gunakan [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) untuk mengimplementasikan dan meluncurkan instans latihan untuk strategi DR Anda. AWS Elastic Disaster Recovery menyediakan kemampuan untuk menjalankan latihan secara efisien, yang membantu Anda bersiap untuk peristiwa failover. Anda juga dapat sering-sering meluncurkan instans menggunakan Elastic Disaster Recovery untuk tujuan pengujian dan latihan tanpa mengarahkan ulang lalu lintas.
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu pemulihan bencana](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog Arsitektur AWS: Seri Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: produk yang dapat digunakan untuk pemulihan bencana](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [Pemulihan Bencana Beban Kerja di AWS: Pemulihan di Cloud (Laporan Resmi AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Bersiap untuk Failover AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)
+ [Proyek Berkeley/Stanford komputasi berorientasi pemulihan](http://roc.cs.berkeley.edu/)
+ [Apa itu Simulator Injeksi Kesalahan AWS?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Video terkait:**
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Pencadangan dan pemulihan serta solusi pemulihan bencana dengan AWS](https://youtu.be/7gNXfo5HZN8)
**Contoh terkait:**
+ [Well-Architected Lab - Pengujian Ketangguhan](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL13-BP04 Mengelola penyimpangan konfigurasi di lokasi atau Wilayah Pemulihan Bencana (DR)
Pastikan infrastruktur, data, dan konfigurasi diperlukan di lokasi atau Wilayah DR. Misalnya, periksa apakah AMI dan kuota layanan sudah mutakhir.
AWS Config terus memantau dan merekam konfigurasi sumber daya AWS Anda. Layanan ini dapat mendeteksi penyimpangan dan memicu [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) untuk memperbaikinya dan memunculkan alarm. AWS CloudFormation juga dapat mendeteksi penyimpangan dalam tumpukan yang telah Anda deploy.
**Antipola umum:**
+ Gagal melakukan pembaruan pada lokasi pemulihan Anda, saat Anda membuat perubahan konfigurasi atau infrastruktur pada lokasi primer.
+ Tidak mempertimbangkan potensi pembatasan (seperti perbedaan layanan) di lokasi primer dan pemulihan Anda.
**Manfaat menjalankan praktik terbaik ini:** Lingkungan DR yang sesuai dengan lingkungan Anda saat ini menjamin pemulihan yang lengkap.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
+ Pastikan pipeline pengiriman Anda menjangkau lokasi primer dan cadangan Anda. Pipeline pengiriman untuk men-deploy aplikasi ke lingkungan produksi harus menyebarkan ke semua lokasi strategi pemulihan bencana yang ditentukan, termasuk lingkungan pengembangan dan pengujian.
+ Aktifkan AWS Config untuk melacak lokasi dengan potensi penyimpangan. Gunakan aturan AWS Config untuk membuat sistem yang menerapkan strategi pemulihan bencana Anda dan menghasilkan pemberitahuan saat mendeteksi penyimpangan.
+ [Mengatasi Sumber Daya AWS yang Tidak Patuh dengan Aturan AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Gunakan AWS CloudFormation untuk men-deploy infrastruktur Anda. AWS CloudFormation dapat mendeteksi penyimpangan antara yang ditentukan oleh templat CloudFormation Anda dan apa yang sebenarnya di-deploy.
+ [AWS CloudFormation: Mendeteksi Penyimpangan di Seluruh Tumpukan CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu pemulihan bencana](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog Arsitektur AWS: Seri Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation: Mendeteksi Penyimpangan di Seluruh Tumpukan CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Marketplace: produk yang dapat digunakan untuk pemulihan bencana](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Pemulihan Bencana Beban Kerja di AWS: Pemulihan di Cloud (Laporan Resmi AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Bagaimana cara mengimplementasikan solusi Manajemen Konfigurasi Infrastruktur di AWS?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [Mengatasi Sumber Daya AWS yang Tidak Patuh dengan Aturan AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**Video terkait:**
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Multi-Wilayah Aktif-Aktif (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
# REL13-BP05 Mengotomatiskan pemulihan
Gunakan AWS atau alat pihak ketiga untuk mengotomatiskan pemulihan sistem dan merutekan lalu lintas ke situs DR atau Wilayah.
Berdasarkan pemeriksaan kondisi yang dikonfigurasi, layanan AWS, seperti Elastic Load Balancing dan AWS Auto Scaling, dapat mendistribusikan beban ke Zona Ketersediaan yang kondisinya baik, sedangkan layanan seperti Amazon Route 53 dan AWS Global Accelerator, dapat merutekan beban ke Wilayah AWS yang kondisinya baik. Pengontrol Pemulihan Aplikasi Amazon Route 53 membantu Anda mengelola dan mengoordinasikan failover menggunakan fitur pemeriksaan kesiapan dan kontrol perutean. Fitur tersebut terus memantau kemampuan aplikasi untuk pulih dari kegagalan, sehingga Anda dapat mengontrol pemulihan aplikasi di beberapa Wilayah AWS, Zona Ketersediaan, dan on-premise.
Untuk beban kerja yang ada di pusat data fisik atau virtual atau cloud pribadi, [AWS Elastic Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/), tersedia melalui AWS Marketplace, memungkinkan organisasi untuk mengatur strategi pemulihan bencana otomatis ke AWS. CloudEndure juga mendukung pemulihan bencana lintas Wilayah/lintas AZ di AWS.
**Antipola umum:**
+ Mengimplementasikan failover dan failback otomatis yang serupa dapat menyebabkan flapping saat kesalahan terjadi.
**Manfaat menerapkan praktik terbaik ini:** Pemulihan otomatis mengurangi waktu pemulihan dengan menghilangkan peluang untuk kesalahan manual.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Otomatiskan jalur pemulihan. Untuk pemulihan pendek, tindakan dan penilaian manusia tidak dapat digunakan untuk skenario ketersediaan tinggi. Sistem harus pulih secara otomatis dalam setiap situasi.
+ Gunakan CloudEndure Disaster Recovery untuk Failback dan Failover otomatis. CloudEndure Disaster Recovery terus mereplikasi mesin (termasuk sistem operasi, konfigurasi status sistem, basis data, aplikasi, dan file) ke dalam area penahapan rendah biaya di Akun AWS target dan Wilayah utama. Dalam kasus bencana, Anda dapat menginstruksikan CloudEndure Disaster Recovery untuk meluncurkan mesin dalam status yang tersedia sepenuhnya dalam hitungan menit secara otomatis.
+ [Menjalankan Failover dan Failback Pemulihan Bencana](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu pemulihan bencana](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog Arsitektur AWS: Seri Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: produk yang dapat digunakan untuk pemulihan bencana](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [CloudEndure Disaster Recovery ke AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [Pemulihan Bencana Beban Kerja di AWS: Pemulihan di Cloud (Laporan Resmi AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
**Video terkait:**
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah (ARC209-R2)](https://youtu.be/2e29I3dA8o4)