# REL10-BP04 使用隔板架構限制影響範圍
<a name="rel_fault_isolation_use_bulkhead"></a>

 如同船舶上的隔板一樣，此模式可確保失敗限制在一小部分的請求或用戶端中，如此一來才能限制受損的請求數量，讓大部分的請求可以繼續運行，而不會發生錯誤。資料的隔板通常稱為分割區，而服務的隔板稱為儲存格。 

 在 *以儲存格為基礎的架構中*，每個儲存格都是完整的獨立服務執行個體，且具有固定的大小上限。隨著負載增加，工作負載會增加更多儲存格。分割區索引鍵用於傳入流量，以判斷使用哪個儲存格處理請求。任何失敗都會限制在它發生的單一儲存格之中，因此受損的請求數量會受到限制，而其他儲存格會繼續運行，且不會發生錯誤。務必要識別適當的分割區索引鍵，以最大程度地減少跨儲存格互動，並避免在每個請求中都加入複雜的對應服務。需要複雜對應的服務最終僅僅是將問題移轉到了對應服務，而需要跨儲存格互動的服務則會在儲存格之間建立相依性 (因此減低了假定的可用性改善)。 

![\[圖表：顯示儲存格型架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)


 Colm MacCarthaigh 在他的 AWS 部落格文章中說明 Amazon Route 53 如何使用 [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/) 將客戶請求隔離為分區。此案例中的分區包含兩個或更多個儲存格。根據分割區索引鍵，來自客戶 (或資源，或任何您想要隔離的項目) 的流量會路由至其指派的分區。如果有八個儲存格，每個分區為兩個儲存格，客戶會分割成四個分區，有 25% 的客戶會在發生問題時受到影響。 

![\[圖表：顯示分為傳統分區的服務\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)


 透過隨機切換分區，您可以建立每個都含有兩個儲存格的虛擬分區，並將您的客戶指派至其中一個虛擬分區。發生問題時，您仍可能會失去整個服務的四分之一，但透過此方式來指派客戶或資源，隨機切換分區的影響範圍遠小於 25%。若有八個儲存格，則會有 28 個含有兩個儲存格的獨特組合，這表示可能會有 28 個隨機切換分區 (虛擬分區)。如果您有數百或數千位客戶，並將每位客戶指派至一個隨機切換分區，則問題造成的影響範圍只有 1/28。這比一般分區好七倍。 

![\[圖表：顯示分為切換分區的服務。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)


 除儲存格之外，分區還可用於伺服器、佇列或其他資源。 

 **若未建立此最佳實務，暴露的風險等級：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  使用隔板架構。如同船舶上的隔板一樣，此模式可確保失敗限制在一小部分的請求/使用者中，如此一來才能限制受損的請求數量，讓大部分的請求可以繼續運行，而不會發生錯誤。資料的隔板通常稱為分割區，而服務的隔板稱為儲存格。 
  +  [Well-Architected 實驗室：搭配隨機分片的故障隔離](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/) 
  +  [隨機切換分區：AWS re:Invent 2019：Amazon Builders’ Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=1373) 
  +  [AWS re:Invent 2018：AWS 如何最大程度地減小故障的影響範圍 (ARC338)](https://youtu.be/swQbA4zub20) 
+  評估小組型架構是否適用於您的工作負載。在以儲存格為基礎的架構中，每個儲存格都是完整的獨立服務執行個體，且具有固定的大小上限。隨著負載增加，工作負載會增加更多儲存格。分割區索引鍵用於傳入流量，以判斷使用哪個儲存格處理請求。任何失敗都會限制在它發生的單一儲存格之中，因此受損的請求數量會受到限制，而其他儲存格會繼續運行，且不會發生錯誤。務必要識別適當的分割區索引鍵，以最大程度地減少跨儲存格互動，並避免在每個請求中都加入複雜的對應服務。需要複雜對應的服務最終僅僅是將問題移轉到了對應服務，而需要跨儲存格互動的服務則會降低儲存格的自主性 (因此提高了假定的可用性)。 
  +  Colm MacCarthaigh 在他的 AWS 部落格文章中說明 Amazon Route 53 如何使用隨機切換分區的概念，將客戶請求隔離為分區 
    +  [隨機分片：神奇的大型故障隔離](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation) 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [隨機分片：神奇的大型故障隔離](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation) 
+  [Amazon Builders' Library：使用隨機切換分區隔離工作負載](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/) 

 **相關影片：** 
+  [AWS re:Invent 2018：AWS 如何最大程度地減小故障的影響範圍 (ARC338)](https://youtu.be/swQbA4zub20) 
+  [隨機切換分區：AWS re:Invent 2019：Amazon Builders’ Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=1373) 

 **相關範例：** 
+  [Well-Architected 實驗室：搭配隨機分片的故障隔離](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)