# Keandalan
**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 batas?](w2aac19b9b5b5.md)
+ [REL 2 Bagaimana cara merencanakan topologi jaringan Anda?](w2aac19b9b5b7.md)
# REL 1 Bagaimana cara mengelola kuota layanan dan batas?
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
Anda menyadari kuota default dan permintaan peningkatan kuota untuk arsitektur beban kerja Anda. Sebagai tambahan, Anda mengetahui kendala sumber daya mana, seperti disk atau jaringan, yang berpotensi memberi dampak.
Service Quotas adalah sebuah layanan AWS yang membantu Anda mengelola kuota Anda untuk lebih dari 100 layanan AWS dari satu lokasi. Di samping mencari nilai kuota, Anda juga dapat meminta dan melacak peningkatan kuota dari konsol Service Quotas atau melalui 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). Batas tingkat pada API yang diberikan throttling diatur di dalam API Gateway itu sendiri dengan mengonfigurasi rencana penggunaan. Batas lain yang diatur sebagai konfigurasi di layanannya masing-masing antara lain IOPS yang Tersedia, penyimpanan RDS yang dialokasikan, dan alokasi volume EBS. Amazon Elastic Compute Cloud (Amazon EC2) memiliki dasbor batas layanannya sendiri yang dapat membantu Anda mengelola instans Anda, Amazon Elastic Block Store (Amazon EBS), 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 AWS Dukungan untuk mengetahui apakah terdapat langkah mitigasi.
**Antipola umum:**
+ Melakukan deployment beban kerja tanpa mempertimbangkan kuota layanan pada layanan AWS yang digunakan.
+ Merancang beban kerja tanpa menyelidiki dan mengakomodasi kendala desain layanan AWS.
+ Melakukan deployment beban kerja dengan kegunaan signifikan yang menggantikan beban kerja yang ada tanpa mengonfigurasi kuota yang diperlukan atau menghubungi AWS Dukungan sebelumnya.
+ Merencanakan peristiwa untuk mendorong lalu lintas ke beban kerja Anda, tetapi tidak mengonfigurasi kuota yang diperlukan atau menghubungi AWS Dukungan sebelumnya.
**Manfaat menjalankan praktik terbaik ini:** Dengan memahami kuota layanan, batas throttling API, dan kendala desain, Anda dapat mempertimbangkan semua hal ini di dalam desain, implementasi, dan operasi beban kerja Anda.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Tinjau kuota layanan AWS di dokumentasi yang dipublikasikan dan Service Quotas
+ [AWS Service Quotas (sebelumnya disebut batas)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ Tentukan semua layanan yang diperlukan oleh beban kerja Anda dengan melihat kode deployment.
+ Gunakan AWS Config untuk menemukan semua sumber daya AWS yang digunakan di Akun AWS Anda.
+ [AWS Config Mendukung Tipe Sumber Daya dan Hubungan Sumber Daya AWS](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)
+ Anda juga dapat menggunakan AWS CloudFormation Anda untuk menentukan sumber daya AWS Anda yang digunakan. Lihat sumber daya yang dibuat baik di Konsol Manajemen AWS maupun melalui perintah CLI list-stack-resources. Anda juga dapat melihat sumber daya yang dikonfigurasi untuk diterapkan di templat itu sendiri.
+ [Melihat Data Tumpukan dan Sumber Daya AWS CloudFormation di Konsol Manajemen AWS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html)
+ [AWS CLI untuk CloudFormation: list-stack-resources](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html)
+ Tentukan kuota layanan yang berlaku. Gunakan informasi yang dapat diakses secara terprogram melalui Trusted Advisor dan Service Quotas.
## Sumber daya
**Dokumen terkait:**
+ [AWS Marketplace: Produk CMDB yang membantu melacak batasan](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (sebelumnya disebut 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/)
+ [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)
**Video terkait:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP02 Mengelola kuota layanan di seluruh akun dan wilayah
Jika Anda menggunakan beberapa Akun AWS atau Wilayah AWS, pastikan Anda meminta kuota yang sesuai di semua lingkungan tempat beban kerja produksi Anda dijalankan.
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.
**Antipola umum:**
+ Memungkinkan pemanfaatan sumber daya di satu zona terisolasi untuk berkembang, tanpa mekanisme untuk mempertahankan kapasitas di zona lainnya.
+ Mengatur semua kuota di zona isolasi secara manual dan independen.
+ Deployment terisolasi berdasarkan Wilayah tidak dipastikan agar ukurannya sesuai untuk mengakomodasi peningkatan lalu lintas dari Wilayah lain jika deployment hilang.
**Manfaat menerapkan praktik terbaik ini:** Dengan memastikan bahwa Anda dapat menangani beban yang sedang berjalan meskipun zona isolasi tidak tersedia, Anda dapat membantu mengurangi jumlah kesalahan yang terjadi selama failover, sehingga tidak menimbulkan penolakan layanan terhadap pelanggan Anda.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ 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.
+ [Apa itu Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
## Sumber daya
**Dokumen terkait:**
+ [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/)
+ [Pemantau batas AWS di Jawaban 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-BP03 Mengakomodasi kuota layanan tetap dan kendala melalui arsitektur
Sadari kuota layanan dan sumber daya fisik yang tidak dapat diubah, dan buat arsitektur untuk mencegah hal-hal ini mengganggu keandalan.
Contohnya adalah bandwidth jaringan, ukuran payload AWS Lambda, tingkat burst throttle untuk API Gateway, dan koneksi pengguna serentak ke sebuah klaster Amazon Redshift.
**Antipola umum:**
+ Melakukan tolok ukur untuk waktu yang terlalu singkat, memanfaatkan batas burst, tetapi kemudian mengharapkan layanan untuk menunjukkan kinerja pada kapasitas tersebut untuk jangka waktu yang berkelanjutan.
+ Memilih desain yang menggunakan sumber daya layanan per pengguna atau pelanggan, tidak menyadari bahwa terdapat kendala desain yang akan menyebabkan desain ini gagal begitu Anda menyesuaikan skala.
**Manfaat menjalankan praktik terbaik ini:** Dengan melacak kuota tetap di layanan AWS dan kendala di bagian lain beban kerja Anda, seperti kendala konektivitas, kendala alamat IP, dan kendala di layanan pihak ketiga, Anda dapat mendeteksi kecenderungan Anda ke sebuah kuota dan Anda mampu menangani kuota tersebut sebelum terlampaui.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
+ Sadari tentang kuota layanan tetap serta kendala, dan buat arsitektur untuk menanganinya.
+ [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
## Sumber daya
**Dokumen terkait:**
+ [AWS Marketplace: Produk CMDB yang membantu melacak batasan](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (sebelumnya disebut 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/)
+ [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)
**Video terkait:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP04 Memantau dan mengelola kuota
Evaluasi potensi penggunaan Anda dan tingkatkan kuota dengan semestinya, sehingga terjadi pertumbuhan penggunaan yang terencana.
Untuk layanan yang didukung, Anda dapat mengelola kuota dengan mengonfigurasi alarm CloudWatch untuk memantau penggunaan dan memberi tahu Anda tentang kuota yang hampir terpenuhi. Alarm tersebut dapat dipicu dari Service Quotas atau dari Trusted Advisor. Anda juga dapat menggunakan filter metrik di CloudWatch Logs untuk mencari dan mengekstrak pola dalam log untuk menentukan apakah penggunaan sudah mendekati ambang batas kuota.
**Antipola umum:**
+ Mengonfigurasi alarm untuk Service Quotas yang sudah dekat, namun tidak memiliki proses untuk merespons pemberitahuan.
+ Hanya mengonfigurasi alarm untuk layanan yang didukung oleh Service Quotas dan tidak memantau layanan lain.
**Manfaat menjalankan praktik terbaik ini:** Dengan melacak kuota layanan AWS 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 menilai kapan Anda dapat menurunkan kuota untuk menekan biaya.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
+ Pantau dan kelola kuota Anda, evaluasi potensi penggunaan Anda di AWS, tingkatkan kuota layanan wilayah Anda dengan semestinya, dan mungkinkan pertumbuhan penggunaan yang terencana.
+ Rekam konsumsi sumber daya saat ini (misalnya, bucket, instans). Gunakan operasi API layanan, seperti API DescribeInstances Amazon EC2, untuk mengumpulkan data pemakaian sumber daya saat ini.
+ Rekam kuota Anda saat ini. Gunakan AWS Service Quotas, AWS Trusted Advisor, dan dokumentasi AWS.
+ Gunakan AWS Service Quotas, sebuah layanan AWS yang membantu Anda mengelola kuota untuk lebih dari 100 layanan AWS dari satu lokasi.
+ Gunakan batas layanan Trusted Advisor untuk menentukan batas layanan Anda saat ini.
+ Gunakan operasi API layanan untuk menentukan kuota layanan saat ini jika didukung.
+ Catat peningkatan kuota yang telah diminta serta statusnya. Setelah peningkatan kuota disetujui, pastikan Anda memperbarui catatan Anda agar mencerminkan perubahan kuota tersebut.
## Sumber daya
**Dokumen terkait:**
+ [AWS Marketplace: Produk CMDB yang membantu melacak batasan](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (sebelumnya disebut batas layanan)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Pemeriksaan Praktik Terbaik AWS Trusted Advisor untuk Batas Layanan](https://docs.aws.amazon.com/awssupport/latest/user/service-limits.html)
+ [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)
+ [Pantau Service Quotas menggunakan alarm Amazon CloudWatch](https://docs.aws.amazon.com/servicequotas/latest/userguide/configure-cloudwatch.html)
**Video terkait:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# 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
Sumber daya yang gagal masih dapat dihitung terhadap kuota hingga berhasil dihentikan. Pastikan kuota Anda mencakup tumpang tindih semua sumber daya yang gagal dengan penggantian sebelum sumber daya yang gagal dihentikan. Anda harus mempertimbangkan kegagalan Zona Ketersediaan saat menghitung selisih ini.
**Antipola umum:**
+ Mengatur kuota layanan berdasarkan kebutuhan saat ini tanpa memperhitungkan skenario failover.
**Manfaat menerapkan praktik terbaik ini:** Ketika peristiwa berpotensi berdampak pada ketersediaan, cloud membuat Anda dapat mengimplementasikan strategi untuk memitigasi atau memulihkan dari peristiwa ini. Strategi tersebut sering menyertakan pembuatan sumber daya tambahan untuk menggantikan sumber daya yang gagal. Strategi kuota harus mengakomodasi sumber daya tambahan ini.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Pastikan bahwa ada selisih yang memadai antara kuota saat ini dan penggunaan maksimum untuk mengakomodasi failover.
+ 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 dikenal sebagai jumlah angka 9 dalam persentase).
+ 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.
+ Rencanakan peningkatan pemakaian (misalnya, memantau tren pemakaian).
## Sumber daya
**Dokumen terkait:**
+ [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/)
+ [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)
# 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 Gunakan 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 Gunakan konektivitas jaringan dengan ketersediaan tinggi untuk titik akhir publik beban kerja Anda
Titik akhir ini dan perutean ke titik akhir harus memiliki ketersediaan tinggi. Untuk mencapai ini, gunakan DNS dengan ketersediaan tinggi, jaringan penyampaian konten (CDN), API Gateway, penyeimbangan beban, atau proksi mundur.
Amazon Route 53, AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway, dan Elastic Load Balancing (ELB) semuanya memberikan titik akhir publik dengan ketersediaan tinggi. Anda juga dapat memilih untuk mengevaluasi peralatan perangkat lunak AWS Marketplace untuk penyeimbangan beban dan proksi.
Konsumen layanan yang diberikan beban kerja Anda, baik mereka pengguna akhir maupun layanan lainnya, mengajukan permintaan di titik akhir layanan ini. Beberapa sumber daya AWS tersedia untuk memampukan Anda memberikan titik akhir dengan ketersediaan tinggi.
Elastic Load Balancing memberikan penyeimbangan beban di seluruh Zona Ketersediaan, melakukan perutean Lapisan 4 (TCP) atau Lapisan 7 (http/https), mengintegrasikan dengan AWS WAF, dan mengintegrasikan dengan AWS Auto Scaling untuk membantu menciptakan infrastruktur pemulihan mandiri dan menyerap peningkatan lalu lintas sekaligus melepaskan sumber daya ketika lalu lintas menurun.
Amazon Route 53 adalah layanan Sistem Nama Domain (DNS) yang dapat diskalakan dan memiliki ketersediaan tinggi yang menghubungkan permintaan pengguna dengan infrastruktur yang dijalankan di AWS seperti instans Amazon EC2, penyeimbang beban Elastic Load Balancing, atau bucket Amazon S3, dan dapat juga digunakan untuk merutekan pengguna ke infrastruktur di luar AWS.
AWS Global Accelerator adalah layanan lapisan jaringan yang dapat Anda gunakan untuk mengarahkan lalu lintas ke titik akhir optimal lewat jaringan global AWS.
Serangan terhadap Penolakan Layanan Secara Terdistribusi (DDoS) berisiko menutup lalu lintas sah dan menurunkan ketersediaan bagi pengguna Anda. AWS Shield memberikan perlindungan otomatis dari serangan ini tanpa biaya ekstra untuk titik akhir layanan AWS di beban kerja Anda. Anda dapat melengkapi fitur ini dengan peralatan virtual dari Partner APN dan AWS Marketplace untuk memenuhi kebutuhan Anda.
**Antipola umum:**
+ Menggunakan alamat internet publik di instans atau kontainer dan mengelola konektivitasnya lewat DNS.
+ Menggunakan alamat Protokol Internet dan bukannya nama domain untuk mencari layanan.
+ Memberikan konten (halaman web, aset statis, file media) ke area geografis besar dan tidak menggunakan CDN.
**Manfaat menerapkan praktik terbaik ini:** Dengan mengimplementasikan layanan dengan ketersediaan tinggi di beban kerja Anda, Anda tahu bahwa beban kerja Anda akan tersedia bagi pengguna Anda.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Pastikan Anda memiliki konektivitas dengan ketersediaan tinggi untuk pengguna beban kerja Amazon Route 53, AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway, dan Elastic Load Balancing (ELB) semuanya memberikan titik akhir dengan ketersediaan tinggi yang dilihat publik. Anda juga dapat memilih untuk mengevaluasi peralatan perangkat lunak AWS Marketplace untuk penyeimbangan beban dan proksi.
+ Pastikan Anda memiliki koneksi dengan ketersediaan tinggi ke pengguna Anda.
+ Pastikan Anda menggunakan DNS dengan ketersediaan tinggi untuk mengelola nama domain titik akhir aplikasi Anda.
+ Jika pengguna Anda mengakses aplikasi Anda lewat internet, gunakan operasi API layanan untuk mengonfirmasi penggunaan Gateway Internet secara benar. Juga konfirmasikan bahwa entri tabel rute untuk hosting subnet titik akhir aplikasi Anda sudah benar.
+ [DescribeInternetGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInternetGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ Pastikan Anda menggunakan penyeimbang beban atau proksi mundur dengan ketersediaan tinggi di depan aplikasi Anda.
+ Jika pengguna Anda mengakses aplikasi Anda lewat lingkungan on-premise, pastikan konektivitas Anda antara AWS dan lingkungan on-premise Anda memiliki ketersediaan tinggi.
+ Gunakan Route 53 untuk mengelola nama domain Anda.
+ [Apa itu Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ Gunakan penyedia DNS pihak ketiga yang memenuhi persyaratan Anda.
+ Gunakan Elastic Load Balancing.
+ [Apa itu Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ Gunakan peralatan AWS Marketplace yang memenuhi persyaratan Anda.
## 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 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 AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Apa Itu Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Apa Itu Gateway Transit?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Apa itu Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/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)
+ [Bekerja dengan Gateway Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.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-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/2022-03-31/framework/images/without-transit-gateway.png)
![\[Diagram menampilkan penggunaan dengan AWS Transit Gateway\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/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?](w2aac19b9b7b5.md)
+ [REL 4 Bagaimana cara mendesain interaksi di sistem terdistribusi untuk mencegah kegagalan?](w2aac19b9b7b7.md)
+ [REL 5 Bagaimana cara mendesain interaksi di sistem terdistribusi untuk memitigasi atau bertahan dari kegagalan?](w2aac19b9b7b9.md)
# REL 3 Bagaimana cara mendesain arsitektur layanan beban kerja Anda?
Bangun beban kerja yang mudah diskalakan dan andal 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 Berikan 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/2022-03-31/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) membangun layanan dengan fungsi yang digambarkan dengan baik berdasarkan kebutuhan bisnis. Layanan mikro menggunakan model domain dan konteks terbatas untuk membatasinya lebih lanjut sehingga tiap-tiap layanan hanya melakukan satu hal. Dengan berfokus pada fungsionalitas tertentu, Anda dapat memilah-milah persyaratan keandalan berbagai layanan, dan menargetkan investasi dengan lebih spesifik. Masalah bisnis yang ringkas dan adanya tim kecil terkait tiap-tiap layanan juga memungkinkan penskalaan organisasi yang lebih mudah.
Dalam merancang arsitektur layanan mikro, penggunaan Desain yang Didorong Domain (DDD) bermanfaat untuk memodelkan masalah bisnis menggunakan entitas. Misalnya, untuk situs web Amazon.com, entitas dapat meliputi paket, pengantaran, jadwal, harga, diskon, dan mata uang. Model ini kemudian dibagi lebih lanjut ke dalam model-model yang lebih kecil menggunakan [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html), di mana entitas dengan fitur dan atribut yang serupa dikelompokkan masing-masing. Jadi, menggunakan untuk kasus Amazon.com, paket, pengantaran, dan jadwal adalah bagian dari konteks pengiriman, sedangkan harga, diskon, dan mata uang adalah bagian dari konteks harga. Dengan model yang dibagi ke dalam konteks, muncul templat untuk membatasi layanan mikro.
![\[Memodelkan templat untuk cara membatasi layanan mikro\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/building-services.png)
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Rancang beban kerja Anda berdasarkan domain bisnis Anda serta fungsionalitasnya masing-masing. Dengan berfokus pada fungsionalitas tertentu, Anda dapat memilah-milah persyaratan keandalan berbagai layanan, dan menargetkan investasi dengan lebih spesifik. Masalah bisnis yang ringkas dan adanya tim kecil terkait tiap-tiap layanan juga memungkinkan penskalaan organisasi yang lebih mudah.
+ Lakukan Analisis Domain untuk memetakan desain yang didorong domain (DDD) untuk beban kerja Anda. Lalu, Anda dapat memilih tipe arsitektur untuk memenuhi kebutuhan beban kerja Anda.
+ [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)
+ [Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software”](https://www.amazon.com/gp/product/0321125215)
+ [Implementasi Layanan Mikro di AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Urai layanan Anda menjadi komponen-komponen sekecil mungkin. Dengan arsitektur layanan mikro, Anda dapat memisahkan beban kerja Anda menjadi komponen-komponen dengan fungsionalitas minimal guna memungkinkan skalabilitas dan ketangkasan organisasi.
+ Tetapkan API untuk beban kerja serta tujuan desainnya, batas, dan pertimbangan lainnya untuk penggunaan.
+ Tetapkan API.
+ Penetapan API harus memungkinkan pertumbuhan dan parameter tambahan.
+ Tetapkan ketersediaan yang dirancang.
+ API Anda mungkin memiliki beberapa tujuan desain untuk berbagai fitur.
+ Buat batasan
+ Gunakan pengujian untuk menetapkan batasan kemampuan beban kerja Anda.
## Sumber daya
**Dokumen terkait:**
+ [Amazon API Gateway: Mengonfigurasi API REST Menggunakan OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Konteks Terbatas (pola sentral dalam Desain yang Didorong Domain)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software”](https://www.amazon.com/gp/product/0321125215)
+ [Mulai Menggunakan DDD di Tengah-Tengah Sistem Warisan](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Cara memecah Monolit menjadi Layanan-Layanan Mikro](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implementasi Layanan Mikro di AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompromi 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/)
# REL03-BP03 Berikan kontrak layanan per API
Kontrak layanan merupakan perjanjian yang didokumentasikan antara tim terkait integrasi layanan dan ini meliputi definisi API yang dapat dibaca mesin, batas tingkat, dan harapan akan performa. Strategi versioning memungkinkan klien Anda untuk terus menggunakan API yang ada dan memigrasikan aplikasi mereka ke API yang lebih baru ketika mereka siap. Deployment dapat terjadi kapan saja, selama kontrak tidak dilanggar. Tim penyedia layanan dapat menggunakan tumpukan teknologi pilihan mereka untuk memenuhi kontrak API. Demikian juga, konsumen layanan dapat menggunakan teknologi mereka sendiri.
Layanan mikro mengambil konsep arsitektur yang berorientasi pada layanan (SOA) sampai pada titik membuat layanan yang memiliki serangkaian fungsionalitas minimal. Setiap layanan mempublikasikan sasaran dan batas desain dan API, serta pertimbangan lainnya untuk menggunakan layanan. Ini menetapkan *kontrak* dengan aplikasi yang memanggil. Hal ini akan mencapai tiga manfaat utama:
+ Layanan memiliki masalah bisnis yang ringkas untuk dilayani dan tim kecil yang memiliki masalah bisnis tersebut. Ini memungkinkan penskalaan organisasi yang lebih baik.
+ Tim dapat melakukan deploy kapan saja selama mereka memenuhi persyaratan API mereka dan persyaratan kontrak lainnya.
+ Tim dapat menggunakan tumpulkan teknologi apa pun yang mereka inginkan selama mereka memenuhi persyaratan API mereka dan persyaratan kontrak lainnya.
Amazon API Gateway adalah layanan terkelola penuh yang memudahkan developer membuat, mempublikasikan, memelihara, memantau, dan mengamankan API dalam skala apa pun. Amazon API Gateway menangani semua tugas yang terlibat dalam menerima dan memproses hingga ratusan ribu panggilan API bersamaan, termasuk manajemen lalu lintas, otorisasi dan kontrol akses, pemantauan, dan manajemen versi API. Menggunakan OpenAPI Specification (OAS), yang sebelumnya disebut sebagai Swagger Specification, Anda dapat menetapkan kontrak API Anda dan mengimpornya ke API Gateway. Dengan API Gateway, kemudian Anda dapat memversikan dan melakukan deploy API.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Rendah
## Panduan implementasi
+ Berikan kontrak layanan per API Kontrak layanan merupakan perjanjian yang didokumentasikan antara tim terkait integrasi layanan dan ini meliputi definisi API yang dapat dibaca mesin, batas tingkat, dan harapan akan performa.
+ [Amazon API Gateway: Mengonfigurasi API REST Menggunakan OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Strategi versioning memungkinkan klien untuk terus menggunakan API yang ada dan memigrasikan aplikasi mereka ke API yang lebih baru ketika mereka siap.
+ Amazon API Gateway adalah layanan terkelola penuh yang memudahkan developer membuat API dalam skala apa pun. Menggunakan OpenAPI Specification (OAS), yang sebelumnya disebut sebagai Swagger Specification, Anda dapat menetapkan kontrak API Anda dan mengimpornya ke API Gateway. Dengan API Gateway, kemudian Anda dapat memversikan dan melakukan deploy API.
## Sumber daya
**Dokumen terkait:**
+ [Amazon API Gateway: Mengonfigurasi API REST Menggunakan OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Konteks Terikat (pola sentral di Desain yang Didorong Domain)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementasi Layanan Mikro di AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompromi 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/)
# 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.
Jika perubahan pada satu komponen memaksa komponen lain yang bergantung padanya untuk turut berubah, berarti komponen-komponen tersebut *digabungkan* secara ketat. *Penggabungan* longgar memecah 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 menambahkan kode atau fitur tambahan ke sebuah komponen sambil meminimalkan risiko pada komponen-komponen yang bergantung pada komponen tersebut. Selain itu, skalabilitas juga meningkat karena Anda dapat melakukan penskalaan ke luar atau bahkan menubah implementasi dasar dari 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 SQS atau platform data streaming seperti Amazon Kinesis, atau AWS Step Functions.
![\[Diagram yang menunjukkan dependensi seperti sistem pengantrean dan penyeimbang beban digabungkan secara longgar\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/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.
**Antipola umum:**
+ Men-deploy satu komponen tunggal sebagai bagian dari beban kerja.
+ Memanggil API secara langsung antar tingkatan beban kerja tanpa kemampuan failover atau pemrosesan permintaan secara asinkron.
**Manfaat menjalankan praktik terbaik ini:** Penggabungan longgar membantu memisahkan perilaku suatu komponen dari komponen lainnya yang bergantung pada komponen tersebut, 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. 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.
+ [AWS re:Invent 2019: Beralih ke arsitektur berbasis peristiwa (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [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)
+ Amazon EventBridge memungkinkan Anda membangun arsitektur yang didorong peristiwa, yang digabungkan dan didistribusikan secara longgar.
+ [AWS New York Summit 2019: Pengantar Arsitektur Berbasis Peristiwa dan Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ Jika perubahan pada satu komponen memaksa komponen lain yang bergantung padanya untuk turut berubah, berarti komponen-komponen tersebut digabungkan secara ketat. Penggabungan longgar memecah dependensi ini sehingga komponen-komponen dependensi hanya perlu mengetahui antarmuka versi terbaru dan yang dipublikasikan.
+ 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.
+ [AWS re:Invent 2019: Aplikasi berbasis peristiwa nirserver yang dapat diskalakan menggunakan Amazon SQS dan Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
## Sumber daya
**Dokumen terkait:**
+ [AWS re:Invent 2019: Beralih ke arsitektur berbasis peristiwa (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [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/)
+ [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)
+ [AWS re:Invent 2019: Aplikasi berbasis peristiwa nirserver yang dapat diskalakan menggunakan Amazon SQS dan Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
# 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 waktu habis 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
Saat dependensi komponen tidak optimum, komponen tersebut masih dapat berfungsi, meskipun terbatas atau terdegradasi. Misalnya, saat panggilan dependensi gagal, lakukan failover ke respons statis yang telah ditentukan sebelumnya.
Misalkan layanan B dipanggil oleh layanan A dan kemudian memanggil layanan C.
![\[Diagram menampilkan Layanan C gagal saat dipanggil dari layanan B. Layanan B mengembalikan respons terdegradasi ke layanan A\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
Saat layanan B memanggil layanan C, yang diterima adalah pesan kesalahan atau waktu habis. Karena tidak mendapatkan respons yang mencukupi dari layanan C (dan data di dalamnya), layanan B mengembalikan respons seadanya. Respons ini dapat berupa nilai baik ter-cache paling akhir, atau layanan B dapat menggantikan respons yang seharusnya diterima dari layanan C dengan respons statis yang ditentukan sebelumnya. Layanan tersebut kemudian mengembalikan respons terbatas ke layanan A sebagai pemanggilnya. Tanpa respons statis, kegagalan di layanan C akan mengalir melalui layanan B ke layanan A, yang mengakibatkan hilangnya ketersediaan.
Sebagai faktor multiplikatif dalam persamaan ketersediaan untuk dependensi keras (lihat [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)), penurunan apa pun dalam ketersediaan layanan C dapat berdampak signifikan terhadap ketersediaan efektif layanan B. Dengan mengembalikan respons statis, layanan B memitigasi kegagalan layanan C, meskipun terbatas, sehingga ketersediaan layanan C tampak seperti 100% (dengan asumsi layanan C mengembalikan respons statis karena kesalahan). Perhatikan bahwa respons statis adalah alternatif sederhana untuk mengembalikan kesalahan, dan bukan upaya untuk mengkomputasi ulang respons menggunakan cara yang berbeda. Upaya semacam itu, dalam mekanisme yang benar-benar berbeda untuk mencoba meraih hasil yang sama, disebut perilaku fallback, dan merupakan antipola yang harus dihindari.
Contoh lain degradasi yang tepat (graceful degradation) adalah *pola pemutus sirkuit*. Strategi percobaan ulang harus digunakan saat kegagalan bersifat sementara. Saat hal tersebut tidak terjadi, dan operasi berpotensi gagal, pola pemutus sirkuit mencegah klien menjalankan permintaan yang berpotensi gagal. Saat permintaan diproses secara normal, pemutus sirkuit ditutup dan permintaan mengalir masuk. Saat sistem jarak jauh mengembalikan kesalahan atau menunjukkan latensi tinggi, pemutus sirkuit terbuka dan dependensi diabaikan atau hasilnya digantikan dengan respons yang lebih mudah didapatkan meskipun kurang komprehensif (atau disebut juga cache respons). Secara berkala, sistem mencoba memanggil dependensi untuk menentukan apakah dependensi sudah dipulihkan. Saat hal tersebut terjadi, pemutus sirkuit ditutup.
![\[Diagram menampilkan status pemutus sirkuit terbuka dan tertutup.\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
Selain status terbuka dan tertutup yang ditampilkan dalam diagram, pemutus sirkuit dapat beralih ke status setengah terbuka setelah berada dalam status terbuka selama periode waktu yang dapat dikonfigurasikan. Dalam status ini, pemutus sirkuit secara berkala mencoba memanggil layanan dengan tingkat yang lebih rendah daripada keadaan normal. Pengujian ini digunakan untuk memeriksa kondisi layanan. Setelah beberapa kali berhasil dalam status setengah terbuka, pemutus sirkuit beralih ke tertutup, dan permintaan normal dilanjutkan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Implementasikan degradasi yang tepat (graceful degradation) untuk mengubah dependensi keras yang berlaku menjadi dependensi lunak. Saat dependensi komponen tidak optimum, komponen tersebut masih dapat berfungsi, meskipun terbatas atau terdegradasi. Misalnya, saat panggilan dependensi gagal, lakukan failover ke respons statis yang telah ditentukan sebelumnya.
+ Dengan mengembalikan respons statis, beban kerja memitigasi kegagalan yang terjadi di dependensinya.
+ [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)
+ Deteksi saat operasi coba ulang berpotensi gagal, dan cegah klien membuat panggilan gagal dengan pola pemutus sirkuit.
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html)
## Sumber daya
**Dokumen terkait:**
+ [Amazon API Gateway: Permintaan API Throttle 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/)
+ [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/)
+ [Amazon Builders' Library: Waktu habis, percobaan ulang, dan mundur (backoff) dengan gangguan](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video terkait:**
+ [Percobaan ulang, mundur, dan gangguan: AWS re:Invent 2019: Memperkenalkan Amazon Builders' Library (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
Pembatasan permintaan adalah pola mitigasi untuk menanggapi peningkatan permintaan yang tidak terduga. Beberapa permintaan diutamakan tetapi permintaan yang melebihi batas yang ditetapkan akan ditolak dan akan muncul pesan yang menunjukkan adanya pembatasan. Yang kemungkinan akan terjadi adalah klien mundur dan mengabaikan permintaan atau mencoba lagi dengan kecepatan lebih rendah.
Layanan Anda harus dirancang untuk menangani kapasitas permintaan yang diketahui yang dapat diproses oleh setiap simpul atau sel. Kapasitas dapat ditetapkan melalui pengujian beban. Anda kemudian perlu melacak tingkat kedatangan permintaan dan jika tingkat kedatangan sementara melebihi batas ini, respons yang tepat adalah memberi sinyal bahwa permintaan telah dibatasi. Ini memungkinkan pengguna untuk mencoba lagi, kemungkinan ke simpul atau sel berbeda yang mungkin memiliki kapasitas yang tersedia. Amazon API Gateway menyediakan metode untuk membatasi permintaan. Amazon SQS dan Amazon Kinesis dapat menahan permintaan, memperlancar tingkat permintaan, dan mengurangi kebutuhan untuk membatasi permintaan yang dapat ditangani secara asinkron.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Membatasi (throttling) permintaan Ini adalah pola mitigasi untuk merespons peningkatan permintaan yang tidak terduga. Beberapa permintaan diutamakan tetapi permintaan yang melebihi batas yang ditetapkan akan ditolak dan akan muncul pesan yang menunjukkan adanya pembatasan. Yang kemungkinan akan terjadi adalah klien mundur dan mengabaikan permintaan atau mencoba lagi dengan kecepatan lebih rendah.
+ Menggunakan Amazon API Gateway
+ [Membatasi Permintaan API untuk Peningkatan Throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## 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)
+ [Percobaan Ulang Kesalahan dan Mundur Eksponensial di AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [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: Waktu habis, percobaan ulang, dan mundur dengan jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [Membatasi Permintaan API untuk Peningkatan Throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**Video terkait:**
+ [Percobaan ulang, mundur, dan jitter: AWS re:Invent 2019: Memperkenalkan Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 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.
Komponen khas di sistem perangkat lunak terdistribusi mencakup server, penyeimbang beban, basis data, dan server DNS. Dalam operasi, dan dapat mengalami kegagalan, semua ini dapat mulai menghasilkan kesalahan. Teknik default untuk menangani kesalahan adalah dengan menerapkan percobaan ulang di sisi klien. Teknik ini meningkatkan keandalan dan ketersediaan aplikasi. Namun, pada skala besar—dan jika klien berupaya untuk mencoba ulang operasi yang gagal langsung setelah terjadi kesalahan—jaringan dengan cepat menjadi penuh dengan permintaan baru dan percobaan ulang, masing-masing memperebutkan bandwidth jaringan. Ini dapat mengakibatkan *badai percobaan ulang,* yang akan mengurangi ketersediaan layanan. Pola ini mungkin berlanjut sampai terjadi kegagalan sistem penuh.
Untuk menghindari skenario seperti itu, algoritme mundur (backoff) seperti *mundur eksponensial* umum harus digunakan. Algoritme mundur eksponensial secara bertahap mengurangi tingkat di mana percobaan ulang dilakukan, sehingga menghindari kemacetan jaringan.
Banyak SDK dan pustaka perangkat lunak, termasuk dari AWS, menerapkan versi dari algoritme ini. Namun, **jangan pernah berasumsi bahwa algoritme mundur ada—selalu uji dan verifikasi bahwa ini adalah masalahnya.**
Mundur sederhana saja tidak cukup karena pada sistem terdistribusi semua klien dapat mundur bersamaan, dan memunculkan klaster-klaster panggilan percobaan ulang. Marc Brooker dalam postingan blognya [Mundur Eksponensial dan Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/), menjelaskan cara mengubah fungsi wait() di mundur eksponensial untuk mencegah klaster-klaster panggilan percobaan ulang. Solusinya adalah menambahkan *jitter* di fungsi wait(). Untuk menghindari percobaan ulang terlalu lama, implementasi harus membatasi mundur ke nilai maksimum.
Terakhir, penting untuk mengonfigurasi *jumlah maksimum percobaan ulang* atau waktu yang telah berlalu, dan setelahnya percobaan ulang akan gagal. SDK AWS mengimplementasikannya secara default, dan dapat dikonfigurasi. Untuk layanan yang lebih rendah di tumpukan, batas percobaan ulang maksimum nol atau satu dapat membatasi risiko namun masih efektif karena percobaan ulang dilimpahkan ke layanan yang lebih tinggi di tumpukan.
**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.
+ [Percobaan Ulang Kesalahan dan Mundur Eksponensial di AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ SDK Amazon mengimplementasikan percobaan ulang dan mundur eksponensial secara default. Implementasikan logika yang sama di lapisan dependensi Anda saat memanggil layanan dependen Anda sendiri. Tentukan berapa batas waktu dan kapan harus berhenti mencoba ulang berdasarkan kasus penggunaan Anda.
## 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)
+ [Percobaan Ulang Kesalahan dan Mundur Eksponensial di AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [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/)
+ [Amazon Builders' Library: Waktu habis, percobaan ulang, dan mundur 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 Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 Melakukan gagal cepat (fail fast) dan membatasi antrean
Jika beban kerja tidak berhasil merespons permintaan, maka lakukan gagal cepat (fail fast). Ini memungkinkan pelepasan sumber daya yang terkait dengan permintaan, dan mengizinkan layanan untuk melakukan pemulihan jika kehabisan sumber daya. Jika beban kerja berhasil merespons tetapi tingkat permintaan terlalu tinggi, maka gunakan antrean untuk menahan permintaan. Namun, jangan izinkan antrean panjang yang dapat mengakibatkan pelayanan permintaan basi yang telah ditinggalkan klien.
Praktik terbaik ini berlaku untuk sisi server, atau penerima permintaan.
Ketahuilah bahwa antrean dapat dibuat di berbagai tingkat sistem, dan dapat sangat menghambat kemampuan untuk melakukan pemulihan dengan cepat saat permintaan lama dan basi (yang tidak lagi memerlukan respons) diproses sebelum permintaan baru. Waspadai tempat-tempat di mana terdapat antrean. Antrean sering bersembunyi di alur kerja atau di dalam pekerjaan yang direkam di basis data.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Lakukan gagal cepat (fail fast) dan batasi antrean Jika beban kerja tidak berhasil merespons permintaan, maka lakukan gagal cepat (fail fast). Ini memungkinkan pelepasan sumber daya yang terkait dengan permintaan, dan mengizinkan layanan untuk melakukan pemulihan jika kehabisan sumber daya. Jika beban kerja berhasil merespons tetapi tingkat permintaan terlalu tinggi, maka gunakan antrean untuk menahan permintaan. Namun, jangan izinkan antrean panjang yang dapat mengakibatkan pelayanan permintaan basi yang telah ditinggalkan klien.
+ Implementasikan gagal cepat (fail fast) saat layanan berada di bawah tekanan.
+ [Gagal Cepat (fail Fast)](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ Batasi antrean dalam sistem berbasis antrean, saat pemrosesan berhenti tetapi pesan tetap datang, utang pesan dapat terakumulasi menjadi backlog yang besar, sehingga meningkatkan waktu pemrosesan. Pekerjaan dapat diselesaikan lebih lama supaya hasilnya berguna, yang pada dasarnya menyebabkan ketersediaan hit yang seharusnya dijaga antreannya.
+ [Amazon Builders' Library: Menghindari backlog antrean yang tidak dapat diatasi](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## Sumber daya
**Dokumen terkait:**
+ [Percobaan Ulang Kesalahan dan Mundur Eksponensial di AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Gagal Cepat (fail Fast)](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [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/)
+ [Amazon Builders' Library: Waktu habis, percobaan ulang, dan mundur 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 Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 Mengatur waktu habis klien
Atur waktu habis dengan sesuai, verifikasikan waktu tersebut dengan sistematis, dan jangan selalu bergantung pada nilai default karena biasanya nilai tersebut ditetapkan terlalu tinggi.
Praktik terbaik ini berlaku untuk sisi klien, atau pengirim, permintaan.
Atur waktu habis koneksi dan waktu habis permintaan untuk panggilan jarak jauh apa pun, serta umumnya untuk panggilan apa pun di seluruh proses. Banyak kerangka kerja yang menawarkan kemampuan waktu habis bawaan, tetapi Anda harus tetap memperhatikan bahwa nilai default bawaan bisa saja terlalu tinggi atau tak terbatas. Nilai yang terlalu tinggi mengurangi kegunaan waktu habis karena sumber daya terus terpakai saat klien menunggu terjadinya waktu habis. 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.
Untuk mempelajari lebih lanjut tentang bagaimana Amazon menggunakan waktu habis, percobaan ulang, dan mundur dengan jitter, lihat [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Atur waktu habis koneksi dan waktu habis permintaan untuk panggilan jarak jauh apa pun, serta umumnya untuk panggilan apa pun di seluruh proses. Banyak kerangka kerja yang menawarkan kemampuan waktu habis bawaan, tetapi Anda harus tetap memperhatikan bahwa nilai default bawaan bisa saja terlalu tinggi atau tak terbatas. Nilai yang terlalu tinggi mengurangi kegunaan waktu habis karena sumber daya terus terpakai saat klien menunggu terjadinya waktu habis. 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.
+ [SDK AWS: Percobaan Ulang dan Waktu Habis](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## Sumber daya
**Dokumen terkait:**
+ [SDK AWS: Percobaan Ulang dan Waktu Habis](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway: Permintaan API Throttle untuk Peningkatan Throughput ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Kesalahan Percobaan Ulang dan Mundur Eksponensial di AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library: Waktu habis, percobaan ulang, dan mundur (backoff) dengan gangguan](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video terkait:**
+ [Percobaan ulang, mundur, dan gangguan: AWS re:Invent 2019: Memperkenalkan Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# 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/2022-03-31/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.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Implementasikan tuas darurat. Ini adalah proses cepat yang dapat memitigasi dampak ketersediaan pada beban kerja. Tuas dapat dioperasikan tanpa adanya akar masalah. Tuas darurat idealnya mengurangi beban kognitif pada pemberi solusi (resolver) hingga nol dengan menyediakan kriteria aktivasi dan deaktivasi yang sepenuhnya deterministik. Tuas biasanya bersifat manual, tetapi dapat juga diotomatiskan.
+ Contoh tuas termasuk
+ Blok semua lalu lintas robot
+ Menyediakan halaman statis, bukan dinamis
+ Mengurangi frekuensi panggilan ke dependensi
+ Membatasi panggilan dari dependensi
+ Tips untuk mengimplementasikan dan menggunakan tuas darurat
+ Saat tuas diaktifkan, lakukan LEBIH SEDIKIT, tidak lebih banyak
+ Tetap sederhana, hindari perilaku bimodal
+ Uji tuas secara berkala
+ Ini adalah contoh yang BUKAN untuk tuas darurat
+ Menambah kapasitas
+ Memanggil pemilik layanan dari klien yang bergantung pada layanan Anda dan meminta mereka untuk mengurangi panggilan
+ Membuat perubahan pada kode dan merilisnya
# Manajemen perubahan
**Topics**
+ [REL 6 Bagaimana cara memantau sumber daya beban kerja Anda?](w2aac19b9b9b5.md)
+ [REL 7 Bagaimana cara mendesain beban kerja Anda untuk beradaptasi dengan perubahan dalam permintaan?](w2aac19b9b9b7.md)
+ [REL 8 Bagaimana cara mengimplementasikan perubahan?](w2aac19b9b9b9.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 performa 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)
Organisasi menerima notifikasi saat terjadi peristiwa yang signifikan apabila mereka perlu mengetahuinya.
Pemberitahuan dapat dikirimkan ke topik Amazon Simple Notification Service (Amazon SNS), lalu didorong ke pelanggan dalam jumlah berapa pun. Misalnya, Amazon SNS dapat meneruskan pemberitahuan ke email alias sehingga dapat direspons oleh staf teknis.
**Antipola umum:**
+ Mengonfigurasi alarm pada ambang batas terlalu rendah, sehingga ada terlalu banyak notifikasi yang harus dikirimkan.
+ Tidak mengarsipkan alarm untuk penelusuran mendatang.
**Manfaat menjalankan praktik terbaik ini:** Notifikasi peristiwa (bahkan peristiwa yang dapat direspons dan diatasi secara otomatis) memungkinkan Anda untuk memiliki catatan peristiwa dan memiliki peluang untuk mengatasinya dengan cara yang berbeda di masa mendatang.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Lakukan pemrosesan dan pembuatan alarm waktu nyata. Organisasi menerima notifikasi saat terjadi peristiwa yang signifikan apabila mereka perlu mengetahuinya
+ Dasbor Amazon CloudWatch adalah halaman beranda yang dapat dikustomisasi di konsol CloudWatch yang dapat Anda gunakan untuk memantau sumber daya dalam satu tampilan, bahkan sumber daya yang disebarkan lintas Wilayah.
+ [Menggunakan Dasbor Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ Buat alarm ketika metrik melampaui batas.
+ [Menggunakan Alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Sumber daya
**Dokumen terkait:**
+ [Satu Lokakarya Observabilitas](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 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)
# REL06-BP04 Mengotomatiskan respons (Peringatan dan pemrosesan waktu nyata)
Gunakan otomatisasi untuk melakukan tindakan ketika peristiwa terdeteksi, misalnya, mengganti komponen yang rusak.
Peringatan dapat memicu peristiwa AWS Auto Scaling, agar klaster bereaksi terhadap perubahan dalam permintaan. Peringatan dapat dikirimkan kepada Amazon Simple Queue Service (Amazon SQS), yang merupakan titik integrasi untuk sistem tiket pihak ketiga. AWS Lambda juga dapat berlangganan peringatan, menyediakan kepada pengguna model nirserver asinkron yang bereaksi terhadap perubahan secara dinamis. AWS Config memantau dan mencatat konfigurasi sumber daya AWS Anda secara terus-menerus, serta dapat memicu [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) untuk menyelesaikan masalah.
Amazon DevOps Guru dapat secara otomatis memantau sumber daya aplikasi untuk perilaku anomali dan memberikan rekomendasi terarah untuk mempercepat waktu perbaikan serta identifikasi masalah.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Gunakan Amazon DevOps Guru untuk menjalankan tindakan otomatis. Amazon DevOps Guru dapat secara otomatis memantau sumber daya aplikasi untuk perilaku anomali, serta memberikan rekomendasi terarah untuk mempercepat waktu perbaikan serta identifikasi masalah.
+ [Apa itu Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ Gunakan AWS Systems Manager untuk menjalankan tindakan otomatis. AWS Config memantau dan mencatat konfigurasi sumber daya AWS Anda secara terus-menerus, serta dapat memicu AWS Systems Manager Automation untuk memperbaiki masalah.
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Buat dan gunakan dokumen Systems Manager Automation. Ini menentukan tindakan yang dijalankan oleh Systems Manager terhadap instans terkelola dan sumber daya AWS lain milik Anda ketika proses otomatisasi dijalankan.
+ [Bekerja dengan Dokumen Otomatisasi (Playbooks)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ Amazon CloudWatch mengirimkan peristiwa perubahan status peringatan kepada Amazon EventBridge. Buat aturan EventBridge untuk otomatisasi respons.
+ [Membuat Aturan EventBridge yang Memicu Peristiwa dari Sumber Daya AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ Buat dan eksekusi rencana untuk mengotomatiskan respons.
+ Inventarisasikan semua prosedur respons peringatan Anda. Anda harus merencanakan respons peringatan Anda sebelum memberi peringkat tugas.
+ Inventarisasikan semua tugas dengan tindakan tertentu yang harus dilakukan. Sebagian besar tindakan ini dimuat di dalam runbook. Anda juga harus memiliki buku pedoman untuk peringatan peristiwa yang tidak diharapkan.
+ Periksa runbook dan buku pedoman untuk semua tindakan yang dapat diotomatiskan. Secara umum, tindakan yang dapat ditentukan biasanya dapat diotomatiskan.
+ Prioritaskan aktivitas yang rentan kesalahan dan menghabiskan waktu. Menghilangkan sumber kesalahan dan mengurangi waktu untuk pemecahan masalah merupakan hal yang sangat penting.
+ Tetapkan rencana untuk menyelesaikan otomatisasi. Pertahankan rencana aktif untuk mengotomatiskan dan memperbarui otomatisasi.
+ Periksa kebutuhan yang dilakukan secara manual untuk menemukan peluang otomatisasi. Uji proses manual Anda untuk peluang otomatisasi.
## Sumber daya
**Dokumen terkait:**
+ [AWS Systems Manager Automation](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)
+ [One Observability Workshop](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 (Playbooks)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
# 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
Gunakan AWS X-Ray atau alat pihak ketiga sehingga pengembang dapat menganalisis dan men-debug sistem terdistribusi secara lebih mudah guna memahami kinerja aplikasi mereka serta layanan-layanan yang mendasarinya.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
+ Pantau pelacakan permintaan menyeluruh melalui sistem Anda. AWS X-Ray adalah layanan yang mengumpulkan data tentang permintaan yang dilayani oleh aplikasi Anda, dan menyediakan alat yang dapat digunakan untuk melihat, memfilter, dan mendapatkan wawasan tentang data tersebut untuk mengidentifikasi masalah dan peluang optimalisasi. Untuk permintaan terlacak apa pun ke aplikasi Anda, Anda dapat melihat informasi yang mendetail bukan hanya tentang permintaan dan responsnya, melainkan juga tentang panggilan yang dibuat aplikasi Anda ke sumber daya AWS hilir, layanan mikro, basis data, dan API web.
+ [Apa itu AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Debugging dengan Amazon CloudWatch Synthetics dan AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
## Sumber daya
**Dokumen terkait:**
+ [Debugging dengan Amazon CloudWatch Synthetics dan AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Satu Lokakarya Observabilitas](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 Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Apa itu AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
# 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 amat 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 sesuai untuk menskalakan sumber daya secara manual, atau picu otomatisasi untuk menskalakannya secara otomatis.
Skala dapat disesuaikan secara manual untuk beban kerja Anda, misalnya, penggantian jumlah instans EC2 di grup Auto Scaling atau modifikasi throughput tabel DynamoDB dapat dilakukan melalui Konsol Manajemen AWS atau AWS CLI. Namun, otomatisasi harus digunakan apabila memungkinkan (lihat **REL07-BP01 Menggunakan otomatisasi ketika mendapatkan atau menskalakan sumber daya**).
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Dapatkan sumber daya setelah deteksi gangguan pada beban kerja. Skalakan sumber daya secara reaktif saat diperlukan jika ketersediaan terganggu, guna memulihkan ketersediaan beban kerja.
+ Gunakan rencana penskalaan, yang merupakan komponen inti AWS Auto Scaling, untuk mengonfigurasi serangkaian instruksi untuk 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. AWS Auto Scaling menyediakan saran strategi penskalaan yang disesuaikan untuk tiap-tiap sumber daya. Setelah Anda membuat rencana penskalaan, AWS Auto Scaling menggabungkan metode penskalaan dinamis dan penskalaan prediktif untuk mendukung strategi penskalaan Anda.
+ [AWS Auto Scaling: Cara Kerja Rencana Penskalaan](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Amazon EC2 Auto Scaling membantu memastikan bahwa Anda memiliki jumlah instans Amazon EC2 yang tepat yang tersedia untuk menangani beban aplikasi Anda. Anda membuat kumpulan instans EC2, yang disebut grup Auto Scaling. Anda dapat menentukan jumlah instans minimum di tiap-tiap grup Auto Scaling, dan Amazon EC2 Auto Scaling memastikan bahwa grup Anda tidak pernah berada di bawah ukuran ini. Anda dapat menentukan jumlah instans maksimum di tiap-tiap grup Auto Scaling, dan memastikan bahwa grup Anda tidak pernah melebihi ukuran ini.
+ [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 AWS 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.
+ [Mengelola Kapasitas Throughput Secara Otomatis dengan Penskalaan Otomatis DynamoDB.](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu Anda membuat solusi komputasi yang diotomatisasi](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)
+ [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 memastikan 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.
Implementasi yang paling umum dari paradigma infrastruktur tetap adalah ***server tetap***. Ini artinya, jika server memerlukan pembaruan atau perbaikan, server baru akan di-deploy, bukannya memperbarui server yang sudah digunakan. Jadi, daripada masuk ke server melalui SSH dan memperbarui versi perangkat lunak, setiap perubahan dalam aplikasi dimulai dengan push perangkat lunak ke repositori kode, misalnya, git push. Karena perubahan tidak diizinkan dalam infrastruktur tetap, Anda dapat yakin tentang status sistem yang di-deploy. Secara permanen, infrastruktur tetap lebih konsisten, dapat diandalkan, dan diprediksikan, selain itu juga mampu menyederhanakan banyak aspek dari pengembangan dan operasi perangkat lunak.
Gunakan deployment blue/green atau canary saat melakukan deployment aplikasi dalam infrastruktur tetap.
[https://martinfowler.com/bliki/CanaryRelease.html](https://martinfowler.com/bliki/CanaryRelease.html) adalah praktik mengarahkan sejumlah kecil pelanggan kepada 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 Anda di-deploy sepenuhnya. AWS CodeDeploy dapat dikonfigurasi dengan konfigurasi deployment yang akan mengaktifkan deployment canary.
[https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html) bersifat serupa dengan deployment canary, kecuali armada penuh aplikasi di-deploy 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 dapat dikonfigurasikan dengan konfigurasi deployment yang akan mengaktifkan deployment blue/green.
![\[Diagram yang menampilkan deployment blue/green dengan AWS Elastic Beanstalk dan Amazon Route 53\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/blue-green-deployment.png)
Manfaat infrastruktur tetap:
+ **Pengurangan dalam penyimpangan konfigurasi:** Dengan sering mengganti server dari konfigurasi dasar, yang dikenal dan dikontrol versinya, infrastruktur **diatur ulang** ke status yang diketahui, menghindari penyimpangan konfigurasi.
+ **Penyederhanaan deployment**: Deployment disederhanakan karena tidak memerlukan pembaruan dukungan. Pembaruan hanyalah deployment baru.
+ **Deployment atom yang andal:** Deployment sepenuhnya berhasil, atau tidak ada yang berubah. Hal ini memberikan lebih banyak kepercayaan pada proses deployment.
+ **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.
+ **Pengujian yang konsisten dan debugging lingkungan:** Karena semua server menggunakan gambar yang sama, tidak ada perbedaan antara lingkungan. Satu build di-deploy ke beberapa lingkungan. Hal itu juga mencegah lingkungan yang tidak konsisten dan menyederhanakan pengujian dan debugging.
+ **Peningkatan skalabilitas:** Karena sistem menggunakan gambar dasar yang konsisten dan berulang, penskalaan otomatis menjadi lebih sederhana.
+ **Penyederhanaan rantai alat**: Rantai alat disederhanakan karena Anda dapat menyingkirkan alat manajemen konfigurasi yang mengelola peningkatan perangkat lunak produksi. Tidak ada alat tambahan atau agen yang diinstal pada server. Perubahan dilakukan pada gambar dasar, diuji, dan diluncurkan.
+ **Peningkatan keamanan:** Dengan menolak semua perubahan ke server, Anda dapat menonaktifkan SSH pada instans dan menghapus kunci. Hal ini mengurangi vektor serangan, meningkatkan postur keamanan organisasi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Lakukan deployment menggunakan infrastruktur tetap. Infrastruktur tetap adalah model yang di dalamnya tidak ada pembaruan, patch keamanan, atau perubahan konfigurasi yang terjadi *di tempat* pada sistem produksi. Jika ada perubahan yang diperlukan, arsitektur versi baru dibangun dan di-deploy ke dalam produksi.
+ [Ikhtisar Deployment Blue/Green](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [Melakukan Deployment Aplikasi Nirserver Secara Bertahap](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [Infrastruktur Tetap: Keandalan, konsistensi, dan kepercayaan melalui ketetapan](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
## Sumber daya
**Dokumen terkait:**
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
+ [Melakukan Deployment Aplikasi Nirserver Secara Bertahap](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [Infrastruktur Tetap: Keandalan, konsistensi, dan kepercayaan melalui ketetapan](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [Ikhtisar Deployment Blue/Green](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [Amazon Builders' Library: Memastikan keamanan rollback selama deployment](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
# 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?](w2aac19b9c11b5.md)
+ [REL 10 Bagaimana cara menggunakan isolasi kesalahan untuk melindungi beban kerja Anda?](w2aac19b9c11b7.md)
+ [REL 11 Bagaimana cara mendesain beban kerja Anda untuk bertahan dari kegagalan komponen?](w2aac19b9c11b9.md)
+ [REL 12 Bagaimana cara menguji keandalan?](w2aac19b9c11c11.md)
+ [REL 13 Bagaimana cara merencanakan pemulihan bencana (DR)?](w2aac19b9c11c13.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
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 menawarkan kemampuan untuk menyalin cadangan ke Wilayah AWS lain. AWS Backup adalah alat yang memberi Anda kemampuan untuk memusatkan dan mengotomatiskan perlindungan data di seluruh layanan AWS.
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 tingkatan penyimpanan seperti [Amazon Glacier atau S3 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. Sebagai contoh, [Simpul replika Amazon Elasticache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) atau [Replika baca RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) dapat digunakan untuk memproduksi ulang data jika data primer hilang. Apabila 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, 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 dalam EMR dari 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.
**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:** Foundational
**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 pemadaman.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Pahami dan gunakan kemampuan pencadangan layanan dan sumber daya AWS yang digunakan oleh beban kerja. Sebagian besar layanan AWS menyediakan kemampuan untuk mencadangkan data beban kerja.
**Langkah Implementasi:**
1. **Mengidentifikasi semua sumber daya 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/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.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. Sebagian besar layanan ini juga memiliki kemampuan native untuk membuat cadangan. AWS Marketplace juga memiliki banyak solusi untuk menyediakan kemampuan-kemampuan ini. Lihat bagian **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, bangun 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 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 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)
+ [Snapshot Amazon EBS](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 for 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
+ [AWS Backup EFS ke EFS](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/)
+ [Mengekspor Data Log ke Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Manajemen siklus hidup objek](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [Pencadangan dan Pemulihan 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)
**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: Mendalami AWS Backup, bersama Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**Contoh terkait:**
+ [Lab Well-Architected: Mengimplementasikan Replikasi Lintas-Wilayah (CRR) Dua Arah untuk Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
+ [Lab Well-Architected: Pengujian Pencadangan dan Pemulihan Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [Lab Well-Architected: Pencadangan dan Pemulihan dengan Failback untuk Beban Kerja Analitik](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [Lab Well-Architected: 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 seperti AWS 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.
**Antipola umum:**
+ Memiliki akses yang sama ke cadangan dan otomatisasi pemulihan seperti yang dilakukan pada data.
+ Tidak mengenkripsi cadangan.
**Manfaat menerapkan praktik terbaik ini:** Mengamankan data 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 diterapkan:** Tinggi
## Panduan implementasi
+ Gunakan enkripsi untuk setiap penyimpanan data. Jika sumber data terenkripsi, maka cadangannya juga akan terenkripsi.
+ Aktifkan enkripsi di RDS. Anda dapat mengonfigurasi enkripsi diam menggunakan AWS Key Management Service saat membuat instans RDS.
+ [Mengenkripsi Sumber Daya Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ Aktifkan enkripsi di volume EBS. Anda dapat mengonfigurasi enkripsi default atau menentukan kunci unik saat pembuatan volume.
+ [Enkripsi Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ Gunakan enkripsi Amazon DynamoDB 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.
+ [Enkripsi Diam DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Mengelola Tabel Terenkripsi](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ Enkripsikan data yang disimpan di Amazon EFS. Konfigurasikan enkripsi saat Anda membuat sistem file.
+ [Enkripsikan Data dan Metadata di EFS.](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ 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.
+ [Konfigurasi Tambahan CRR: Mereplika 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)
+ 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.
+ [Pilar Keamanan: AWS Well-Architected](./wat.pillar.security.en.html)
## Sumber daya
**Dokumen terkait:**
+ [AWS Marketplace: produk yang dapat digunakan untuk cadangan](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: Mereplika 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)
+ [Enkripsikan Data dan Metadata di 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](./wat.pillar.security.en.html)
**Contoh terkait:**
+ [Lab Well-Architected: 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.
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-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) – semuanya dapat dipulihkan ke titik waktu tertentu di 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, berjalan secara 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.
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.
**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 menerapkan praktik terbaik ini:** Otomatisasi pencadangan memastikan pencadangan dilakukan secara teratur berdasarkan RPO Anda dan memberi tahu Anda jika pencadangan tidak dilakukan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
1. **Identifikasi sumber data** yang sedang dicadangkan secara manual. 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 mendapatkan panduan tentang hal ini.
1. **Tentukan RPO** untuk beban kerja. Lihat [REL13-BP01 Tetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md) untuk mendapatkan panduan tentang hal ini.
1. **Gunakan solusi pencadangan otomatis atau layanan terkelola**. AWS Backup adalah layanan terkelola penuh yang memudahkannya untuk [memusatkan dan mengotomatiskan 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). Rencana pencadangan adalah fitur AWS Backup yang memungkinkan pembuatan aturan yang menetapkan sumber daya ke pencadangan, dan frekuensi pembuatan cadangan tersebut. Frekuensi ini harus mengacu pada RPO yang ditetapkan pada Langkah 2. [Lab WA ini](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) menyediakan panduan praktis cara membuat cadangan otomatis menggunakan AWS Backup. 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 data 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 mengeksekusinya pada frekuensi yang didasarkan pada RPO Anda (sebagaimana dijelaskan di Langkah 2).
**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)
**Video terkait:**
+ [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**Contoh terkait:**
+ [Lab Well-Architected: 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 memenuhi sasaran waktu pemulihan (RTO) dan sasaran titik pemulihan (RPO) dengan melakukan uji pemulihan.
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.
**Hasil yang Diinginkan:** Data dari cadangan dipulihkan secara berkala menggunakan mekanisme yang ditentukan dengan baik untuk memastikan 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 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 ad hoc, tanpa menggunakan runbook, atau di luar prosedur otomatis yang ditetapkan.
**Manfaat menerapkan praktik terbaik ini:** Pengujian pemulihan cadangan memastikan data dapat dipulihkan saat dibutuhkan tanpa perlu khawatir data akan hilang atau rusak, bahwa pemulihan dapat dilakukan dalam RTO untuk beban kerja, dan kehilangan data apa pun termasuk dalam RPO untuk beban kerja.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** 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 seharusnya dilakukan adalah memeriksa
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.
1. **Identifikasikan sumber data** yang dicadangkan saat ini dan lokasi penyimpanan cadangan tersebut. Lihat [REL09-BP01 Mengidentifikasi dan mencadangkan data yang perlu dicadangkan, atau memproduksi ulang data dari sumber](rel_backing_up_data_identified_backups_data.md) panduan tentang cara mengimplementasikan ini.
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. Lihat [REL13-BP01 Tetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md) panduan tentang cara mengimplementasikan ini.
1. **Menilai kemampuan pemulihan**. Tinjau strategi pencadangan dan pemulihan untuk memahami apakah hal tersebut memenuhi RTO dan RPO, serta sesuaikan strategi yang dibutuhkan. Jika 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 uji pemulihan** 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. Misalnya, jika Anda menggunakan layanan terkelola seperti [AWS Backup, hal ini dapat sesederhana memulihkan data ke dalam 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 drill pemulihan](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html).
1. **Validasikan pemulihan data** dari sumber daya yang dipulihkan (dari langkah sebelumnya) berdasarkan kriteria yang ditetapkan sebelumnya untuk validasi data pada langkah 2. Apakah data yang dipulihkan memiliki sebagian besar catatan/item terbaru pada waktu pencadangan? Apakah data ini termasuk dalam RPO untuk beban kerja?
1. **Pengukuran waktu diperlukan** untuk memulihkan dan membandingkannya dengan RTO yang telah ditetapkan pada langkah 3. 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 stempel waktu dan informasi ini tersedia dalam [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, 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. Dalam AWS Backup, pencadangan dan pemulihan disebut sebagai *Tugas*, dan Tugas tersebut berisi informasi stempel waktu sebagai bagian dari metadata yang dapat digunakan untuk mengukur waktu yang diperlukan untuk pemulihan.
1. **Beri tahu pemangku kepentingan** jika validasi data gagal, atau jika waktu yang diperlukan untuk pemulihan melebihi RTO yang ditetapkan untuk beban kerja. Saat mengimplementasikan otomatisasi untuk melakukan ini, [misalnya 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 mengirim notifikasi push seperti email atau SMS kepada pemangku kepentingan. [Pesan tersebut dapat dipublikasikan aplikasi pesan 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 dengan menggunakan Pusat Operasional AWS Systems Manager](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. Pelajari cara [Mengotomatiskan validasi pemulihan data dengan AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/). Selain itu, [lab Well-Architected ini](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) memberikan pengalaman langsung tentang 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/2022-03-31/framework/images/automated-backup-restore-process.png)
**Tingkat usaha untuk Rencana Implementasi:** Sedang hingga tinggi tergantung 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 cadangan](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Membuat Aturan EventBridge yang Memicu menurut 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://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
**Contoh terkait:**
+ [Lab Well-Architected: Pengujian Pemulihan dan Pencadangan 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 Anda?
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/2022-03-31/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/2022-03-31/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 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 pusat data on-premise, Anda harus mengimplementasikan kemampuan untuk membangun kembali beban kerja sepenuhnya dalam tujuan pemulihan yang telah ditetapkan.
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). Jika menggunakan [EMR File System (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html), data dalam EMR dapat disimpan dalam Amazon S3, yang nantinya dapat direplikasi di seluruh 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.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ 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 Auto Scaling untuk instans atau beban kerja kontainer yang tidak memiliki persyaratan untuk alamat IP instans tunggal, alamat IP pribadi, alamat IP Elastis, dan metadata instans.
+ [Apa Itu EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Penskalaan otomatis layanan](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ Data pengguna konfigurasi peluncuran dapat digunakan untuk mengimplementasikan otomatisasi yang dapat memulihkan sebagian besar beban kerja secara mandiri.
+ Gunakan pemulihan otomatis instans EC2 untuk beban kerja yang memerlukan instans tunggal alamat ID, alamat IP pribadi, alamat IP Elastis, dan instans metadata.
+ [Pulihkan instans Anda.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ Pemulihan Otomatis akan mengirimkan peringatan status pemulihan kepada topik SNS saat kegagalan instans terdeteksi.
+ Gunakan peristiwa siklus hidup instans EC2 atau peristiwa ECS untuk mengotomatiskan pemulihan mandiri jika penskalaan otomatis atau pemulihan EC2 tidak dapat digunakan.
+ [Pengait siklus hidup EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Peristiwa Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ Gunakan peristiwa untuk memicu otomatisasi yang akan memulihkan komponen Anda berdasarkan proses logika yang diperlukan.
## Sumber daya
**Dokumen terkait:**
+ [Peristiwa Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [Pengait siklus hidup 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 EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL10-BP04 Menggunakan arsitektur bulkhead untuk membatasi cakupan dampak
Seperti bulkhead pada kapal, pola ini memastikan kegagalan dibatasi pada subset kecil permintaan atau klien saja, sehingga jumlah permintaan terganggu terbatas, dan sebagian besar dapat dilanjutkan tanpa kesalahan. Bulkhead untuk data sering disebut sebagai partisi, sedangkan bulkhead untuk layanan disebut sel.
Dalam *arsitektur berbasis sel*, setiap sel merupakan instans independen dan lengkap dari layanan, dan memiliki ukuran maksimum tetap. Seiring beban yang meningkat, beban kerja bertambah dengan menambahkan lebih banyak sel. Kunci partisi digunakan pada lalu lintas yang akan datang untuk menentukan sel mana yang akan memproses permintaan. Kegagalan apa pun dibatasi pada sel tunggal tempatnya muncul, sehingga jumlah permintaan terganggu terbatas, dan sebagian besar dapat dilanjutkan tanpa kesalahan. Kunci partisi harus diidentifikasi dengan tepat agar interaksi lintas sel minimal dan tidak perlu melibatkan layanan pemetaan kompleks dalam setiap permintaan. Layanan yang memerlukan pemetaan kompleks akhirnya hanya mengalihkan masalah ke layanan pemetaan, sementara layanan yang memerlukan interaksi lintas sel menimbulkan ketergantungan antarsel (dan dengan demikian mengurangi peningkatan ketersediaan yang diasumsikan jika hal tersebut dilakukan).
![\[Diagram menampilkan Arsitektur berbasis sel\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)
Dalam posting blog AWS, Colm MacCarthaigh menjelaskan cara Amazon Route 53 menggunakan konsep [https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/) untuk mengisolasi permintaan pelanggan ke dalam serpihan. Dalam kasus ini, serpihan terdiri atas dua sel atau lebih. Berdasarkan kunci partisi, lalu lintas dari pelanggan (atau sumber daya, atau apa pun yang ingin diisolasi) dirutekan ke serpihan yang sudah ditetapkan. Saat ada delapan sel dan setiap serpihan berisi dua sel, pelanggan dibagi menjadi empat serpihan dan 25% pelanggan akan mengalami dampak dari masalah.
![\[Diagram menampilkan layanan yang dibagi menjadi serpihan tradisional\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)
Dengan shuffle sharding, Anda membuat beberapa serpihan virtual yang masing-masing berisi dua sel, dan menetapkan pelanggan ke salah satu dari serpihan virtual tersebut. Saat masalah terjadi, Anda masih dapat kehilangan seperempat dari keseluruhan layanan. Namun, dengan cara penetapan pelanggan atau sumber daya yang demikian, cakupan dampak shuffle sharding jauh lebih kecil dari 25%. Ada 28 kombinasi unik dari dua sel yang dapat dibuat dari delapan sel. Artinya, ada 28 kemungkinan shuffle shard (serpihan virtual). Jika Anda memiliki ratusan atau ribuan pelanggan, dan menetapkan setiap pelanggan ke shuffle shard, maka cakupan dampak dari masalah hanya 1/28. Itu tujuh kali lebih baik daripada sharding biasa.
![\[Diagram menampilkan layanan yang dibagi menjadi shuffle shard.\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)
Serpihan dapat digunakan untuk layanan, antrean, atau sumber daya lain selain sel.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Gunakan arsitektur bulkhead. Seperti bulkhead pada kapal, pola ini memastikan kegagalan dibatasi pada subset kecil permintaan atau klien saja, sehingga jumlah permintaan terganggu terbatas, dan sebagian besar dapat dilanjutkan tanpa kesalahan. Bulkhead untuk data sering disebut sebagai partisi, sedangkan bulkhead untuk layanan disebut sel.
+ [Lab Well-Architected: Isolasi kesalahan dengan shuffle sharding](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
+ [Shuffle-sharding: AWS re:Invent 2019: Memperkenalkan Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS re:Invent 2018: Cara AWS Meminimalkan Radius Dampak Kesalahan (ARC338)](https://youtu.be/swQbA4zub20)
+ Evaluasikan arsitektur berbasis sel untuk beban kerja. Dalam arsitektur berbasis sel, setiap sel merupakan instans independen dan lengkap dari layanan, dan memiliki ukuran maksimum tetap. Seiring beban yang meningkat, beban kerja bertambah dengan menambahkan lebih banyak sel. Kunci partisi digunakan pada lalu lintas yang akan datang untuk menentukan sel mana yang akan memproses permintaan. Kegagalan apa pun dibatasi pada sel tunggal tempatnya muncul, sehingga jumlah permintaan terganggu terbatas, dan sebagian besar dapat dilanjutkan tanpa kesalahan. Kunci partisi harus diidentifikasi dengan tepat agar interaksi lintas sel minimal dan tidak perlu melibatkan layanan pemetaan kompleks dalam setiap permintaan. Layanan yang memerlukan pemetaan kompleks akhirnya hanya mengalihkan masalah ke layanan pemetaan, sementara layanan yang memerlukan interaksi lintas sel akan mengurangi otonomi sel (dan dengan demikian mengurangi peningkatan ketersediaan yang diasumsikan jika hal tersebut dilakukan).
+ Dalam posting blog AWS, Colm MacCarthaigh menjelaskan cara Amazon Route 53 menggunakan konsep shuffle sharding untuk mengisolasi permintaan pelanggan ke dalam serpihan
+ [Shuffle Sharding: Isolasi Kesalahan Besar](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
## Sumber daya
**Dokumen terkait:**
+ [Shuffle Sharding: Isolasi Kesalahan Besar](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
+ [Amazon Builders' Library: Isolasi beban kerja menggunakan shuffle-sharding](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
**Video terkait:**
+ [AWS re:Invent 2018: Cara AWS Meminimalkan Radius Dampak Kesalahan (ARC338)](https://youtu.be/swQbA4zub20)
+ [Shuffle-sharding: AWS re:Invent 2019: Memperkenalkan Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
**Contoh terkait:**
+ [Lab Well-Architected: Isolasi kesalahan dengan shuffle sharding](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
# REL 11 Bagaimana cara mendesain beban kerja Anda untuk bertahan dari kegagalan komponen?
Beban kerja dengan persyaratan untuk ketersediaan tinggi dan waktu rata-rata untuk pemulihan (MTTR) rendah harus didesain dan dikonfigurasi agar tangguh.
**Topics**
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Melakukan failover ke sumber daya yang sehat](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Mengotomatisasi pemulihan di semua lapisan](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 Andalkan bidang data dan bukan bidang kendali selama pemulihan](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 Gunakan stabilitas statis untuk mencegah perilaku bimodal](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Mengirimkan notifikasi ketika peristiwa memengaruhi ketersediaan](rel_withstand_component_failures_notifications_sent_system.md)
# REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan
Terus pantau kondisi beban kerja agar Anda dan sistem otomatis Anda mengetahui penurunan kualitas atau kegagalan langsung setelah muncul. Pantau indikator kinerja utama (KPI) berdasarkan nilai bisnis.
Semua mekanisme pemulihan dan penyembuhan harus dimulai dengan kemampuan untuk mendeteksi masalah secara cepat. Kegagalan teknis harus dideteksi terlebih dahulu sehingga dapat diatasi. Namun, ketersediaan didasarkan pada kemampuan beban kerja Anda untuk menghadirkan nilai bisnis, sehingga indikator kinerja utama (KPI) yang mengukurnya perlu menjadi bagian dari strategi deteksi dan perbaikan Anda.
**Antipola umum:**
+ Tidak ada alarm yang dikonfigurasi, sehingga pemadaman terjadi tanpa notifikasi.
+ Alarm tersedia, tetapi pada ambang batas yang tidak menyediakan waktu yang cukup untuk bereaksi.
+ Metrik tidak dikumpulkan cukup sering untuk memenuhi sasaran waktu pemulihan (RTO).
+ Hanya tingkatan beban kerja di sisi pelanggan yang aktif dipantau.
+ Hanya mengumpulkan metrik teknis, dan tidak ada metrik fungsi bisnis.
+ Tidak ada metrik yang mengukur pengalaman pengguna beban kerja.
**Manfaat menjalankan praktik terbaik ini:** Adanya pemantauan yang baik di semua lapisan memungkinkan Anda menghemat waktu pemulihan dengan mengurangi waktu deteksi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Tentukan interval pengumpulan untuk komponen Anda berdasarkan tujuan pemulihan.
+ Interval pemantauan Anda bergantung pada seberapa cepat Anda harus pulih. Waktu pemulihan Anda didorong oleh waktu yang diperlukan untuk pulih, sehingga Anda harus menentukan frekuensi pengumpulan dengan cara menghitung waktu ini serta sasaran waktu pemulihan (RTO) Anda.
+ Konfigurasikan pemantauan mendetail untuk komponen.
+ Tentukan apakah diperlukan pemantauan mendetail untuk instans EC2 dan Auto Scaling. Pemantauan mendetail menyediakan metrik interval 1 menit, sedangkan pemantauan default menyediakan metrik interval 5 menit.
+ [Aktifkan atau Nonaktifkan Pemantauan Mendetail untuk Instans Anda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Memantau Grup Auto Scaling dan Instans Anda Menggunakan Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ Tentukan apakah diperlukan pemantauan yang ditingkatkan untuk RDS. Pemantauan yang ditingkatkan menggunakan agen di instans RDS untuk mendapatkan informasi yang bermanfaat tentang proses atau thread berbeda di sebuah instans RDS.
+ [Pemantauan yang Ditingkatkan](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ Buat metrik kustom untuk mengukur indikator kinerja utama (KPI) bisnis. Beban kerja mengimplementasikan fungsi-fungsi bisnis utama. Fungsi-fungsi tersebut harus digunakan sebagai KPI yang membantu mengidentifikasi saat terjadi masalah tidak langsung.
+ [Memublikasikan Metrik Kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Pantau pengalaman pengguna untuk mendeteksi kegagalan menggunakan canary pengguna. Pengujian transaksi sintetis (juga disebut pengujian canary, tetapi bedakan dengan deployment canary) yang dapat menjalankan dan menyimulasikan perilaku pelanggan adalah salah satu proses pengujian yang paling penting. Jalankan pengujian ini secara konstan terhadap titik akhir beban kerja Anda dari beragam lokasi jarak jauh.
+ [Amazon CloudWatch Synthetics memungkinkan Anda untuk membuat canary pengguna](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ Buat metrik kustom yang melacak pengalaman pengguna. Jika Anda dapat menginstrumentasi pengalaman pelanggan, Anda dapat menentukan saat pengalaman pelanggan mengalami penurunan kualitas.
+ [Memublikasikan Metrik Kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Atur alarm untuk mendeteksi saat ada bagian dari beban kerja Anda yang tidak berfungsi dengan baik, dan untuk menunjukkan kapan harus menerapkan Auto Scale pada sumber daya. Alarm dapat ditampilkan secara visual di dasbor, mengirimkan pemberitahuan melalui Amazon SNS atau email, dan bekerja dengan Auto Scaling untuk menaikkan atau menurunkan skala sumber daya untuk beban kerja.
+ [Menggunakan Alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ Buat dasbor untuk memvisualisasikan metrik Anda. Dasbor dapat digunakan untuk melihat tren, penyimpangan, dan indikator potensi masalah lainnya, atau untuk menyediakan penanda masalah yang ingin Anda selidiki.
+ [Menggunakan dasbor CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
## Sumber daya
**Dokumen terkait:**
+ [Amazon CloudWatch Synthetics memungkinkan Anda untuk membuat canary pengguna](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Aktifkan atau Nonaktifkan Pemantauan Mendetail untuk Instans Anda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Pemantauan yang Ditingkatkan](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Memantau Grup Auto Scaling dan Instans Anda Menggunakan Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [Memublikasikan Metrik Kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Menggunakan Alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Menggunakan dasbor CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**Contoh terkait:**
+ [Lab Well-Architected: Level 300: Mengimplementasikan Pemeriksaan Kondisi dan Mengelola Dependensi untuk Meningkatkan Keandalan](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP02 Melakukan failover ke sumber daya yang sehat
Pastikan jika terjadi kegagalan sumber daya, sumber daya yang sehat dapat terus melayani permintaan. Untuk kegagalan lokasi (seperti Zona Ketersediaan atau Wilayah AWS) pastikan Anda memiliki sistem untuk melakukan failover ke sumber daya yang sehat di lokasi yang tidak terkena gangguan.
Layanan AWS, seperti Elastic Load Balancing dan AWS Auto Scaling, membantu mendistribusikan beban di seluruh sumber daya dan Zona Ketersediaan. Oleh karena itu, kegagalan sumber daya individu (seperti instans EC2) atau gangguan pada Zona Ketersediaan dapat dimitigasi dengan mengalihkan lalu lintas ke sumber daya sehat yang masih ada. Untuk beban kerja multiwilayah, ini lebih rumit. Misalnya, replika baca lintas wilayah memungkinkan Anda men-deploy data Anda ke beberapa Wilayah AWS, tetapi Anda tetap harus menaikkan replika baca ke wilayah primer dan arahkan lalu lintas Anda ke sana apabila terjadi failover. Amazon Route 53 dan AWS Global Accelerator dapat membantu merutekan lalu lintas di seluruh Wilayah AWS.
Jika beban kerja Anda menggunakan layanan AWS, seperti Amazon S3 atau Amazon DynamoDB, lalu di-deploy secara otomatis ke beberapa Zona Ketersediaan. Apabila terjadi kegagalan, bidang kendali AWS secara otomatis merutekan lalu lintas ke lokasi yang sehat untuk Anda. Data disimpan secara redundan di beberapa Zona Ketersediaan, dan tetap tersedia. Untuk Amazon RDS, Anda harus memilih Multi-AZ sebagai opsi konfigurasi, lalu pada saat kegagalan, AWS mengarahkan lalu lintas secara otomatis ke instans yang sehat. Untuk instans Amazon EC2, tugas Amazon ECS, atau pod Amazon EKS, Anda memilih Zona Ketersediaan sebagai target deployment. Elastic Load Balancing lalu menyediakan solusi untuk mendeteksi instans di zona tidak sehat dan merutekan lalu lintas ke zona yang sehat. Elastic Load Balancing bahkan dapat merutekan lalu lintas ke komponen di pusat data on-premise Anda.
Untuk pendekatan Multi-Wilayah (yang mungkin juga termasuk pusat data on-premise), Amazon Route 53 menyediakan cara untuk menetapkan domain internet, dan menerapkan kebijakan perutean yang dapat mencakup pemeriksaan kondisi untuk memastikan bahwa lalu lintas dirutekan ke wilayah yang sehat. Alternatifnya, AWS Global Accelerator menyediakan alamat IP statis yang bertindak sebagai titik masuk tetap untuk aplikasi Anda, lalu rute ke titik akhir di Wilayah AWS yang Anda pilih menggunakan jaringan global AWS, bukan internet, untuk kinerja dan keandalan yang lebih baik.
AWS melakukan pendekatan desain layanan dengan mempertimbangkan pemulihan kesalahan. Kami merancang layanan untuk meminimalkan waktu untuk pulih dari kegagalan dan dampak terhadap data. Layanan kami utamanya menggunakan penyimpanan data yang mengenali permintaan hanya setelah disimpan dalam waktu lama di beberapa repliksa di dalam suatu Wilayah. Di antara layanan dan sumber daya ini adalah Amazon Aurora, instans Multi-AZ DB Amazon Relational Database Service (Amazon RDS), Amazon S3, Amazon DynamoDB, Amazon Simple Queue Service (Amazon SQS), dan Amazon Elastic File System (Amazon EFS). Layanan dan sumber daya ini dibangun untuk menggunakan isolasi berbasis sel dan menggunakan isolasi kesalahan yang disediakan oleh Zona Ketersediaan. Kami banyak menggunakan otomatisasi di dalam prosedur operasional kami. Kami juga mengoptimalkan fungsionalitas “ganti dan mulai ulang” kami untuk pulih secara cepat dari gangguan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Lakukan failover ke sumber daya yang sehat. Pastikan jika terjadi kegagalan sumber daya, sumber daya yang sehat dapat terus melayani permintaan. Untuk kegagalan lokasi (seperti Zona Ketersediaan atau Wilayah AWS) pastikan Anda memiliki sistem untuk melakukan failover ke sumber daya yang sehat di lokasi yang tidak terkena gangguan.
+ Jika beban kerja Anda menggunakan layanan AWS, seperti Amazon S3 atau Amazon DynamoDB, lalu di-deploy secara otomatis ke beberapa Zona Ketersediaan. Apabila terjadi kegagalan, bidang kendali AWS secara otomatis merutekan lalu lintas ke lokasi yang sehat untuk Anda.
+ Untuk Amazon RDS, Anda harus memilih Multi-AZ sebagai opsi konfigurasi, lalu pada saat kegagalan, AWS mengarahkan lalu lintas secara otomatis ke instans yang sehat.
+ [Ketersediaan Tinggi (Multi-AZ) untuk Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ Untuk instans Amazon EC2 atau tugas Amazon ECS, Anda memilih Zona Ketersediaan sebagai target deployment. Elastic Load Balancing lalu menyediakan solusi untuk mendeteksi instans di zona tidak sehat dan merutekan lalu lintas ke zona yang sehat. Elastic Load Balancing bahkan dapat merutekan lalu lintas ke komponen di pusat data on-premise Anda.
+ Untuk pendekatan multi-wilayah (yang mungkin juga mencakup pusat data on-premise), pastikan data dan sumber daya dari lokasi yang sehat dapat terus melayani permintaan
+ Misalnya, replika baca lintas wilayah memungkinkan Anda men-deploy data Anda ke beberapa Wilayah AWS, tetapi Anda tetap harus menaikkan replika baca ke wilayah utama dan arahkan lalu lintas Anda ke sana apabila terjadi kegagalan lokasi primer.
+ [Gambaran umum Replika Baca Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ Amazon Route 53 menyediakan cara untuk menetapkan domain internet, dan menerapkan kebijakan perutean, yang mungkin mencakup pemeriksaan kondisi, untuk memastikan lalu lintas dirutekan ke Wilayah yang sehat. Alternatifnya, AWS Global Accelerator menyediakan alamat IP statis yang bertindak sebagai titik masuk tetap untuk aplikasi Anda, lalu rute ke titik akhir di Wilayah AWS yang Anda pilih menggunakan jaringan global AWS, bukan internet publik, untuk kinerja dan keandalan yang lebih baik.
+ [Amazon Route 53: Memilih Kebijakan Perutean](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Apa Itu AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu dengan otomatisasi toleransi kesalahan Anda](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: produk yang dapat digunakan untuk toleransi kesalahan](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Menggunakan Auto Healing untuk Mengganti Instans yang Gagal](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon Route 53: Memilih Kebijakan Perutean](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Ketersediaan Tinggi (Multi-AZ) untuk Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ [Gambaran umum Replika Baca Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ [Strategi penempatan tugas Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Membuat Grup Auto Scaling Kubernetes untuk Beberapa Zona Ketersediaan](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/)
+ [Apa Itu AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
**Contoh terkait:**
+ [Lab Well-Architected: Level 300: Mengimplementasikan Pemeriksaan Kondisi dan Mengelola Dependensi untuk Meningkatkan Keandalan](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP03 Mengotomatisasi pemulihan di semua lapisan
Setelah kegagalan dideteksi, gunakan kemampuan otomatis untuk melakukan tindakan perbaikan.
*Kemampuan untuk memulai ulang* adalah alat penting untuk memperbaiki kegagalan. Seperti yang telah dibahas sebelumnya untuk sistem terdistribusi, salah satu praktik terbaik adalah menjadikan layanan bersifat tanpa status apabila memungkinkan. Hal ini mencegah hilangnya data atau ketersediaan pada saat mulai ulang. Di cloud, Anda dapat (dan umumnya harus) mengganti seluruh sumber daya (misalnya, instans EC2, atau fungsi Lambda) sebagai bagian dari mulai ulang. Mulai ulang itu sendiri adalah cara yang mudah dan andal untuk pulih dari kegagalan. Ada berbagai jenis kegagalan yang terjadi di dalam beban kerja. Kegagalan dapat terjadi di perangkat keras, perangkat lunak, komunikasi, dan operasi. Alih-alih membangun mekanisme baru untuk menjebak, mengidentifikasi, dan memperbaiki tiap-tiap jenis kegagalan yang berbeda-beda, petakan banyak kategori kegagalan yang berbeda ke strategi pemulihan yang sama. Sebuah instans mungkin gagal disebabkan kegagalan perangkat keras, bug sistem operasi, kebocoran memori, atau penyebab lainnya. Alih-alih membangun perbaikan kustom untuk tiap-tiap situasi, perlakukan semua situasi sebagai kegagalan instans. Akhiri instans, dan biarkan AWS Auto Scaling menggantinya. Setelahnya, Anda dapat menjalankan analisis terhadap sumber daya yang gagal tersebut di luar jaringan.
Contoh lainnya adalah kemampuan untuk memulai ulang permintaan jaringan. Terapkan pendekatan pemulihan yang sama ke waktu habis jaringan serta kegagalan dependensi yakni ketika dependensi menunjukkan kesalahan. Kedua peristiwa tersebut memiliki efek yang serupa terhadap sistem, sehingga alih-alih berupaya untuk menjadikan masing-masing sebagai “kasus spesial”, terapkan strategi serupa berupa coba ulang terbatas dengan mundur eksponensial dan jitter.
*Kemampuan untuk memulai ulang* adalah mekanisme pemulihan yang disertakan dalam Komputasi Berorientasi Pemulihan dan arsitektur klaster ketersediaan tinggi.
Amazon EventBridge dapat digunakan untuk memantau dan memfilter peristiwa seperti Alarm CloudWatch atau perubahan pada layanan AWS lain. Berdasarkan informasi peristiwa, layanan ini kemudian dapat memicu AWS Lambda, AWS Systems Manager Automation, atau target lainnya untuk mengeksekusi logika perbaikan kustom pada beban kerja Anda.
Amazon EC2 Auto Scaling dapat dikonfigurasi untuk memeriksa kondisi instans EC2. Jika instans sedang dalam status apa pun selain running (berjalan), atau jika status sistem terganggu, Amazon EC2 Auto Scaling menganggap instans tersebut tidak sehat dan meluncurkan instans pengganti. Jika menggunakan AWS OpsWorks, Anda dapat mengonfigurasi Auto Healing instans EC2 pada tingkat lapisan OpsWorks.
Untuk penggantian skala besar (seperti hilangnya seluruh Zona Ketersediaan), stabilitas statis lebih disarankan untuk ketersediaan tinggi daripada mencoba memperoleh beberapa sumber daya baru sekaligus.
**Antipola umum:**
+ Melakukan deployment aplikasi di instans atau kontainer secara terpisah.
+ Melakukan deployment aplikasi yang tidak dapat dilakukan ke beberapa lokasi tanpa menggunakan pemulihan otomatis.
+ Memulihkan secara manual aplikasi yang gagal dipulihkan oleh penskalaan otomatis dan pemulihan otomatis.
**Manfaat menjalankan praktik terbaik ini:** Pemulihan otomatis, bahkan jika beban kerja hanya dapat diterapkan ke dalam satu lokasi pada satu waktu, akan memangkas waktu rata-rata pemulihan Anda dan memastikan ketersediaan beban kerja.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Gunakan grup Auto Scaling untuk melakukan deployment tingkatan di sebuah beban kerja. Penskalaan otomatis dapat melakukan pemulihan mandiri pada aplikasi tanpa status, dan menambahkan serta menghapus kapasitas.
+ [Cara kerja AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Implementasikan pemulihan otomatis pada instans EC2 dengan aplikasi ter-deploy yang tidak dapat di-deploy di beberapa lokasi, dan dapat mentoleransi boot ulang setelah kegagalan. Pemulihan otomatis dapat digunakan untuk mengganti perangkat keras yang mengalami kegagalan dan memulai ulang instans ketika aplikasi tidak dapat diterapkan di beberapa lokasi. Metadata instans dan alamat IP terkait akan disimpan, begitu juga dengan volume Amazon EBS dan titik mount ke Elastic File Systems atau File Systems untuk Lustre dan Windows.
+ [Pemulihan Otomatis Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Apa itu Amazon FSx for Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Apa itu Amazon FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ Menggunakan AWS OpsWorks, Anda dapat mengonfigurasi Auto Healing instans EC2 pada tingkat lapisan
+ [AWS OpsWorks: Menggunakan Auto Healing untuk Mengganti Instans yang Gagal](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ Implementasikan pemulihan otomatis menggunakan AWS Step Functions dan AWS Lambda ketika Anda tidak dapat menggunakan penskalaan otomatis atau pemulihan otomatis, atau ketika pemulihan otomatis gagal. Ketika Anda tidak dapat menggunakan penskalaan otomatis, dan tidak dapat menggunakan pemulihan otomatis atau pemulihan otomatis gagal, Anda dapat mengotomatiskan pemulihan menggunakan AWS Step Functions dan AWS Lambda.
+ [Apa itu AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Apa itu AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ Amazon EventBridge dapat digunakan untuk memantau dan memfilter peristiwa seperti Alarm CloudWatch atau perubahan pada layanan AWS lain. Berdasarkan informasi peristiwa, layanan ini kemudian dapat memicu AWS Lambda (atau target lainnya) untuk menjalankan logika perbaikan kustom pada beban kerja Anda.
+ [Apa Itu Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Menggunakan Alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu dengan otomatisasi toleransi kesalahan Anda](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: produk yang dapat digunakan untuk toleransi kesalahan](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Menggunakan Auto Healing untuk Mengganti Instans yang Gagal](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Pemulihan Otomatis Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Cara kerja AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Menggunakan Alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Apa Itu Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Apa itu AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Apa itu AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Apa itu Amazon FSx for Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Apa itu Amazon FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
**Video terkait:**
+ [Stabilitas statis dalam AWS: AWS re:Invent 2019: Memperkenalkan Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
**Contoh terkait:**
+ [Lab Well-Architected: Level 300: Mengimplementasikan Pemeriksaan Kondisi dan Mengelola Dependensi untuk Meningkatkan Keandalan](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP04 Andalkan bidang data dan bukan bidang kendali selama pemulihan
Bidang kendali digunakan untuk mengonfigurasikan sumber daya, dan bidang data memberikan layanan. Bidang data biasanya memiliki sasaran desain dengan ketersediaan lebih tinggi daripada bidang kendali, dan biasanya lebih sederhana. Ketika mengimplementasikan respons mitigasi atau pemulihan terhadap peristiwa yang berpotensi memengaruhi ketangguhan, menggunakan operasi bidang kendali dapat menurunkan ketangguhan arsitektur Anda secara keseluruhan. Contohnya, Anda dapat mengandalkan bidang data Amazon Route 53 untuk merutekan kueri DNS secara andal berdasarkan pemeriksaan kondisi, tetapi memperbarui kebijakan perutean Route 53 menggunakan bidang kendali, jadi jangan mengandalkannya untuk pemulihan.
Bidang data Route 53 menjawab kueri DNS, dan melakukan dan mengevaluasi pemeriksaan kondisi. Bidang data ini terdistribusi secara global dan didesain untuk [perjanjian tingkat layanan (SLA) dengan ketersediaan 100%.](https://aws.amazon.com/route53/sla/) Konsol dan API manajemen Route 53 di mana Anda membuat, memperbarui, dan menghapus sumber daya Route 53 dijalankan di bidang kendali yang didesain untuk memprioritaskan durabilitas dan konsistensi tinggi yang Anda perlukan ketika mengelola DNS. Untuk mencapai ini, bidang kendali terletak di satu Wilayah, US East (N. Virginia). Walaupun kedua sistem dibangun agar sangat andal, bidang kendali tidak disertakan dalam SLA. Mungkin ada peristiwa langka di mana desain tangguh bidang data memungkinkannya untuk mempertahankan ketersediaan sedangkan bidang kendali tidak. Untuk mekanisme failover dan pemulihan bencana, gunakan fungsi bidang data untuk memberikan keandalan yang sebaik mungkin.
Untuk informasi selengkapnya tentang bidang data, bidang kendali, dan bagaimana AWS membangun layanan untuk memenuhi target ketersediaan tinggi, lihat [laporan Stabilitas statis menggunakan Zona Ketersediaan](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) dan [Amazon Builders' Library.](https://aws.amazon.com/builders-library/)
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Andalkan bidang data dan bukan bidang kendali ketika menggunakan Amazon Route 53 untuk pemulihan bencana. Pengontrol Pemulihan Aplikasi Route 53 membantu Anda mengelola dan mengoordinasikan failover menggunakan pemeriksaan kesiapan dan kontrol perutean. Fitur-fitur ini terus-menerus memantau kemampuan aplikasi Anda untuk pulih dari kegagalan, dan memampukan Anda untuk mengontrol pemulihan aplikasi di beberapa Wilayah AWS, Zona Ketersediaan, dan on-premise.
+ [Apa itu Pengontrol Pemulihan Aplikasi Route 53?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Membuat Mekanisme Pemulihan Bencana Menggunakan Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Membangun aplikasi yang sangat tangguh menggunakan Pengontrol Pemulihan Aplikasi Amazon Route 53, Bagian 1: Tumpukan Wilayah Tunggal](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Membangun aplikasi yang sangat tangguh menggunakan Pengontrol Pemulihan Aplikasi Amazon Route 53, Bagian 2: Tumpukan Multi-Wilayah](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ Pahami operasi mana yang ada di bidang data dan mana yang ada di bidang kendali.
+ [Amazon Builders’ Library: Menghindari kelebihan beban dalam sistem terdistribusi dengan mengontrol layanan lebih kecil](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API Amazon DynamoDB (bidang kendali dan bidang data)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [Pelaksanaan AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (dibagi menjadi bidang kendali dan bidang data)
+ [Pelaksanaan AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (dibagi menjadi bidang kendali dan bidang data)
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu dengan otomatisasi toleransi kesalahan Anda](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: produk yang dapat digunakan untuk toleransi kesalahan](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [Amazon Builders’ Library: Menghindari kelebihan beban dalam sistem terdistribusi dengan mengontrol layanan lebih kecil](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API Amazon DynamoDB (bidang kendali dan bidang data)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [Pelaksanaan AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (dibagi menjadi bidang kendali dan bidang data)
+ [Bidang Data AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Membangun aplikasi yang sangat tangguh menggunakan Pengontrol Pemulihan Aplikasi Amazon Route 53, Bagian 1: Tumpukan Wilayah Tunggal](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Membangun aplikasi yang sangat tangguh menggunakan Pengontrol Pemulihan Aplikasi Amazon Route 53, Bagian 2: Tumpukan Multi-Wilayah](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Membuat Mekanisme Pemulihan Bencana Menggunakan Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Apa itu Pengontrol Pemulihan Aplikasi Route 53?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
**Contoh terkait:**
+ [Memperkenalkan Pengontrol Pemulihan Aplikasi Amazon Route 53](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
# REL11-BP05 Gunakan stabilitas statis untuk mencegah perilaku bimodal
Perilaku bimodal terjadi ketika beban kerja Anda menunjukkan perilaku yang berbeda dalam mode normal dan mode kegagalan, contohnya, mengandalkan peluncuran instans baru jika Zona Ketersediaan gagal. Sebagai gantinya, Anda harus membangun beban kerja yang stabil secara statis dan dioperasikan dalam satu mode saja. Dalam hal ini, penyediaan instans yang cukup di setiap Zona Ketersediaan untuk menangani beban dari beban kerja jika satu AZ disingkirkan kemudian menggunakan pemeriksaan kondisi Elastic Load Balancing atau Amazon Route 53 untuk memindahkan beban dari instans yang terganggu.
Stabilitas statis untuk deployment komputasi (seperti kontainer atau instans EC2) akan menghasilkan keandalan tertinggi. Ini harus dibandingkan dengan masalah biaya. Memberikan lebih sedikit kapasitas komputasi dan mengandalkan peluncuran instans baru jika ada kegagalan akan lebih murah. Tetapi untuk kegagalan dalam skala besar (seperti kegagalan Zona Ketersediaan), pendekatan ini kurang efektif karena mengandalkan reaksi terhadap gangguan saat terjadi, dan bukannya siap menangani gangguan tersebut sebelum terjadi. Solusi Anda harus membandingkan keandalan dengan biaya yang diperlukan untuk beban kerja Anda. Dengan menggunakan lebih banyak Zona Ketersediaan, jumlah komputasi tambahan yang Anda perlukan untuk stabilitas statis akan berkurang.
![\[Diagram yang menunjukkan stabilitas statis instans EC2 di seluruh Zona Ketersediaan\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/static-stability.png)
Setelah lalu lintas dipindahkan, gunakan AWS Auto Scaling untuk mengganti instans secara asinkron dari zona yang gagal dan luncurkan di zona sehat.
Contoh lain dari perilaku bimodal adalah waktu habis jaringan yang dapat menyebabkan sistem mencoba untuk melakukan refresh status konfigurasi seluruh sistem. Ini akan menambahkan beban yang tak terduga ke komponen lain, dan dapat menyebabkannya gagal, sehingga memicu konsekuensi lain yang tak terduga. Lingkaran umpan balik negatif ini memengaruhi ketersediaan beban kerja Anda. Sebagai gantinya, Anda harus membangun sistem yang stabil secara statis dan dioperasikan dalam satu mode saja. Desain yang stabil secara statis akan melakukan pekerjaan secara terus-menerus, dan selalu refresh status konfigurasi dengan irama tetap. Ketika panggilan gagal, beban kerja menggunakan nilai yang sebelumnya di-cache, dan memicu alarm.
Contoh lain dari perilaku bimodal adalah memperbolehkan klien untuk melewatkan cache beban kerja Anda ketika kegagalan terjadi. Ini mungkin terlihat seperti solusi yang mengakomodasi kebutuhan klien, tetapi tidak boleh diizinkan karena secara signifikan mengubah permintaan di beban kerja Anda dan kemungkinan akan mengakibatkan kegagalan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Gunakan stabilitas statis untuk mencegah perilaku bimodal. Perilaku bimodal terjadi ketika beban kerja Anda menunjukkan perilaku yang berbeda dalam mode normal dan mode kegagalan, contohnya, mengandalkan peluncuran instans baru jika Zona Ketersediaan gagal.
+ [Meminimalkan Ketergantungan dalam Rencana Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Amazon Builders' Library: Stabilitas statis menggunakan Zona Ketersediaan](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [Stabilitas statis dalam AWS: AWS re:Invent 2019: Memperkenalkan Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
+ Sebagai gantinya, Anda harus membangun sistem yang stabil secara statis dan dioperasikan dalam satu mode saja. Dalam hal ini, penyediaan instans yang cukup di setiap zona untuk menangani beban dari beban kerja jika satu AZ disingkirkan kemudian menggunakan pemeriksaan kondisi Elastic Load Balancing atau Amazon Route 53 untuk memindahkan beban dari instans yang terganggu.
+ Contoh lain dari perilaku bimodal adalah memperbolehkan klien untuk melewatkan cache beban kerja Anda ketika kegagalan terjadi. Ini mungkin terlihat seperti solusi yang akan mengakomodasi kebutuhan klien, tetapi tidak boleh diizinkan karena secara signifikan mengubah permintaan di beban kerja Anda dan kemungkinan akan mengakibatkan kegagalan.
## Sumber daya
**Dokumen terkait:**
+ [Meminimalkan Ketergantungan dalam Rencana Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Amazon Builders' Library: Stabilitas statis menggunakan Zona Ketersediaan](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
**Video terkait:**
+ [Stabilitas statis dalam AWS: AWS re:Invent 2019: Memperkenalkan Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 Mengirimkan notifikasi ketika peristiwa memengaruhi ketersediaan
Notifikasi dikirimkan setelah peristiwa besar terdeteksi, bahkan jika masalah yang disebabkan oleh peristiwa tersebut diatasi secara otomatis.
Pemulihan otomatis menjadikan beban kerja Anda andal. Namun, kemampuan ini juga menyembunyikan masalah dasar yang perlu diatasi. Implementasikan pemantauan peristiwa yang baik agar Anda dapat mendeteksi pola masalah, termasuk masalah yang ditangani oleh pemulihan otomatis, sehingga Anda dapat mengatasi akar masalahnya. Alarm Amazon CloudWatch dapat dipicu berdasarkan kegagalan yang terjadi. Alarm ini juga dapat dipicu berdasarkan tindakan pemulihan otomatis yang dijalankan. Alarm CloudWatch dapat dikonfigurasi untuk mengirimkan email, atau untuk mencatatkan insiden di dalam sistem pelacakan insiden pihak ketiga menggunakan integrasi Amazon SNS.
**Antipola umum:**
+ Mengirimkan alarm yang tidak dapat ditindaklanjuti siapa pun.
+ Melakukan otomatisasi pemulihan otomatis, tetapi tidak memberikan notifikasi bahwa pemulihan diperlukan.
**Manfaat menjalankan praktik terbaik ini:** Notifikasi peristiwa pemulihan akan memastikan Anda tidak mengabaikan masalah yang tidak sering terjadi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
+ Alarm untuk Indikator Kinerja Utama bisnis saat melampaui ambang batas rendah. Dengan alarm ambang batas rendah pada KPI bisnis, Anda dapat mengetahui saat beban kerja Anda tidak tersedia atau tidak berfungsi.
+ [Membuat Alarm CloudWatch Berdasarkan Ambang Batas Statis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ Alarm untuk peristiwa yang memanggil otomatisasi pemulihan. Anda dapat langsung memanggil API SNS untuk mengirimkan notifikasi dengan otomatisasi apa pun yang Anda buat.
+ [Apa Itu Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
## Sumber daya
**Dokumen terkait:**
+ [Membuat Alarm CloudWatch Berdasarkan Ambang Batas Statis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [Apa Itu Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Apa Itu Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
# REL 12 Bagaimana cara menguji keandalan?
Setelah Anda mendesain beban kerja Anda agar tangguh terhadap tekanan produksi, pengujian adalah satu-satunya cara untuk memastikannya 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 personel lain sebagaimana yang diperlukan.
Menilai alasan mengapa pengujian yang ada tidak dapat menemukan masalahnya. Menambahkan pengujian untuk kasus ini jika pengujian belum ada.
**Antipola umum:**
+ Menemukan faktor-faktor yang berkontribusi, tetapi tidak terus 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.
**Manfaat menerapkan praktik terbaik ini:** Dengan melakukan analisis setelah insiden dan membagikan hasilnya, beban kerja lain akan dapat memitigasi risiko jika beban kerja sudah mengimplementasikan faktor yang berkontribusi yang sama, sehingga mitigasi atau pemulihan otomatis dapat diimplementasikan sebelum insiden terjadi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Tetapkan standar untuk analisis setelah insiden. Analisis setelah insiden yang baik memberikan peluang untuk mengusulkan solusi umum terhadap masalah dengan pola arsitektur yang digunakan di tempat lainnya dalam sistem.
+ Pastikan bahwa faktor yang berkontribusi bersifat jujur dan tidak menyalahkan.
+ Jika Anda tidak mendokumentasikan masalah, Anda tidak dapat mengoreksinya.
+ Pastikan analisis setelah insiden bebas dari kesalahan sehingga Anda bersikap rasional terhadap tindakan korektif yang diusulkan dan mendorong penilaian mandiri yang jujur serta kolaborasi pada tim aplikasi.
+ Gunakan proses untuk menentukan faktor yang berkontribusi. Buat sebuah proses untuk mengidentifikasi dan mendokumentasi faktor yang berkontribusi terhadap peristiwa agar Anda dapat mengembangkan mitigasi untuk membatasi atau mencegah kejadian serupa serta mengembangkan prosedur untuk respons efektif dan cepat. Mengomunikasikan faktor yang berkontribusi dan disesuaikan dengan audiens target.
+ [Apa itu analitik log?](https://aws.amazon.com/log-analytics/)
## Sumber daya
**Dokumen terkait:**
+ [Apa itu analitik log?](https://aws.amazon.com/log-analytics/)
+ [Mengapa Anda harus mengembangkan koreksi kesalahan (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
# 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/2022-03-31/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/2022-03-31/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 merencanakan 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 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/2022-03-31/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 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/2022-03-31/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 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 untuk memenuhi sasaran pemulihan
Tentukan strategi pemulihan bencana (DR) yang memenuhi sasaran pemulihan beban kerja. Pilih strategi seperti: pencadangan dan pemulihan; siaga (aktif/pasif); atau aktif/aktif.
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* mengacu pada Wilayah AWS selain yang digunakan untuk beban kerja.
![\[Diagram menampilkan strategi DR\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/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): Mengaktifkan versi yang diturunkan tetapi berfungsi sepenuhnya dari beban kerja 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. Saat skala sesuai 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.
**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 DR.
+ Dependensi pada operasi bidang kendali selama pemulihan.
**Manfaat menerapkan praktik terbaik ini:**
+ Dengan strategi pemulihan yang ditentukan, Anda dapat menggunakan prosedur tes dan peralatan umum.
+ Dengan strategi pemulihan, berbagi pengetahuan antartim dapat dilakukan dengan lebih efisien dan implementasi DR pada beban kerja milik mereka menjadi lebih mudah.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
+ Tanpa strategi DR yang direncanakan, diimplementasikan, dan diuji, Anda akan kesulitan mencapai sasaran pemulihan ketika bencana terjadi.
## Panduan implementasi
Lihat detail di bawah untuk masing-masing langkah.
1. Tentukan strategi DR yang akan memenuhi persyaratan pemulihan untuk beban kerja ini.
1. Tinjau pola tentang bagaimana strategi DR yang dipilih dapat diimplementasikan.
1. Evaluasikan sumber daya beban kerja, dan seperti apa konfigurasinya di Wilayah pemulihan sebelum failover (selama operasi normal).
1. Tentukan dan implementasikan cara Anda mempersiapkan Wilayah untuk failover saat dibutuhkan (selama peristiwa bencana).
1. Tentukan dan implementasikan cara Anda merutekan kembali lalu lintas ke failover saat dibutuhkan (selama peristiwa bencana).
1. Rancang rencana terkait bagaimana beban kerja akan failback.
**Langkah Implementasi**
1. **Tentukan strategi DR yang akan memenuhi persyaratan pemulihan untuk beban kerja ini.**
Saat memilih strategi DR, Anda harus memilih antara meminimalkan waktu henti dan kehilangan data (RTO dan RPO) tetapi 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/2022-03-31/framework/images/choosing-a-dr-strategy.png)
Untuk mempelajari lebih lanjut, 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 berikutnya setelah ini, strategi akan diterapkan ke beban kerja tertentu.
**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/2022-03-31/framework/images/backup-restore-architecture.png)
Untuk detail lebih lanjut 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/2022-03-31/framework/images/pilot-light-architecture.png)
Untuk detail lebih lanjut 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/2022-03-31/framework/images/warm-standby-architecture.png)
Saat menggunakan warm standby atau pilot light, Anda perlu menaikkan skala sumber daya di Wilayah pemulihan. Untuk memastikan kapasitas tersedia saat dibutuhkan, 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 memastikan lingkungan eksekusi sehingga dapat dipersiapkan untuk merespons invokasi fungsi dengan cepat.
Untuk detail lebih lanjut 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 berkelanjutan 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 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/2022-03-31/framework/images/multi-site-active-active-architecture.png)
Untuk detail lebih lanjut 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/).
**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 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 menggunakan 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 sumber daya dari [Penyeimbang Beban Elastis](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) di-deploy di beberapa AZ, yang aktif menangani permintaan. Arsitektur ini juga menerapkan hot standby, yaitu jika instans [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) utama gagal (atau AZ tersebut juga gagal), instans standby akan dibuat menjadi utama.
![\[Diagram menampilkan Gambar 23: Arsitektur Multi-AZ\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png)
Selain arsitektur HA ini, Anda perlu menambahkan cadangan data yang dibutuhkan untuk menjalankan beban kerja. Ini sangat penting untuk data yang dimasukkan ke dalam satu 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 berdaya tahan tinggi 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 sumber daya dan infrastruktur 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 [StackSets AWS CloudFormation](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 [parameter](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) CloudFormation dan [logika bersyarat](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html), Anda dapat mengontrol tumpukan yang di-deploy agar aktif atau standby dengan templat tunggal. Contoh templat CloudFormation terdapat dalam [posting blog ini](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
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 yang membuat Anda dapat mengonfigurasi, menjadwalkan, dan memantau cadangan untuk sumber daya ini. Untuk Pilot Light, Warm Standby, dan Multi-situs aktif/aktif, Anda 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 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 satunya 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 secara manual, Anda dapat menggunakan [Pengontrol Pemulihan Aplikasi Amazon Route 53](https://aws.amazon.com/route53/application-recovery-controller/), yang menyediakan 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 Andalkan bidang data dan bukan bidang kendali selama pemulihan](rel_withstand_component_failures_avoid_control_plane.md).
Untuk mempelajari lebih lanjut tentang ini dan topik lainnya, lihat [bagian ini dalam 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 terkelola](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover), topologi replika basis data global Aurora yang sudah ada akan 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.
**Tingkat usaha 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 Andalkan 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:**
+ [Lab AWS Well-Architected - 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, serta terpenuhinya RTO dan RPO.
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.
**Antipola umum:**
+ Tidak pernah melakukan failover di lingkungan produksi.
**Manfaat menjalankan praktik terbaik ini:** Pengujian rencana pemulihan bencana secara rutin memastikan bahwa rencana tersebut akan berfungsi saat diperlukan, dan tim Anda tahu cara mengeksekusi strategi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Rekayasa beban kerja Anda untuk pemulihan. Secara rutin uji jalur pemulihan Anda. Komputasi Berorientasi Pemulihan mengidentifikasi karakteristik dalam sistem yang dapat menyempurnakan pemulihan. Karakteristik ini adalah: 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 memastikan 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.
+ [Proyek Berkeley/Stanford komputasi berorientasi pemulihan](http://roc.cs.berkeley.edu/)
+ Gunakan CloudEndure Disaster Recovery untuk mengimplementasikan dan menguji strategi pemulihan bencana (DR) Anda.
+ [Menguji Solusi Pemulihan Bencana dengan CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [CloudEndure Disaster Recovery ke AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## 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)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-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)
+ [Menguji Solusi Pemulihan Bencana dengan CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [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 Multi-Wilayah Aktif-Aktif (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Pencadangan dan pemulihan serta solusi pemulihan bencana dengan AWS (STG208)](https://youtu.be/7gNXfo5HZN8)
**Contoh terkait:**
+ [Lab AWS Well-Architected - 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)