# REL10-BP04 Menggunakan arsitektur bulkhead untuk membatasi cakupan dampak
<a name="rel_fault_isolation_use_bulkhead"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

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