# 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/)