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

實作隔板架構 (也稱為小組型架構) 將工作負載內的失敗效應限制為有限數量的元件。

 **預期成果：**小組型架構會使用工作負載的隔離執行個體，其中每個執行個體稱為小組。每個小組都是獨立的，不會與其他小組共用狀態，並且處理整體工作負載請求的子集。這會對個別小組和它處理的請求降低失敗的潛在影響，例如不良的軟體更新。如果工作負載使用 10 個小組為 100 個請求提供服務，發生失敗時，整體請求中 90% 不會受到失敗影響。 

 **常見的反模式：** 
+  允許小組成長，沒有界限。 
+  將程式碼更新或部署同時套用到所有小組。 
+  在小組之間共用狀態或元件 (路由器層例外)。 
+  將複雜商業或路由邏輯新增至路由器層。 
+  不將跨小組互動降至最低。 

 **建立此最佳實務的優勢：**使用小組型架構，許多常見類型的失敗會包含在小組本身，提供額外的故障隔離。這些故障界限可以提供對於難以包含之失敗類型的彈性，例如失敗的程式碼部署或已損毀或觸發特定失敗模式的請求 (也稱為*毒藥請求*)。 

## 實作指引
<a name="implementation-guidance"></a>

 在船上，隔板可確保船體破口包含在船體的其中一個區段內。在複雜的系統中，通常會複寫這個模式以啟用故障隔離。故障隔離界限會在工作負載內將失敗影響限制為有限數量的元件。界限外的元件不受失敗影響。使用多個故障隔離界限時，您可以限制對工作負載的影響。在 AWS 上，客戶可以使用多個可用區域或區域來提供故障隔離，但是故障隔離的概念也可以延伸為您的工作負載的架構。 

 整體工作負載是依分割區索引鍵的分割區小組。這個索引鍵需要與服務的*精細度*保持一致，否則服務的工作負載會自然地透過最小跨小組互動進行細分。分割區索引鍵的範例為客戶 ID、資源 ID 或可在大部分 API 呼叫中輕易存取的其他任何參數。小組路由層會根據分割區索引鍵將請求分散到個別小組，並且對用戶端呈現單一端點。 

![圖表顯示小組型架構](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/images/cell-based-architecture.png)


 **實作步驟** 

 設計小組型架構時，有數個設計考慮要考慮： 

1.  **分割區索引鍵**：選擇分割區索引鍵時應該考慮的特殊考慮。
   +  應該與服務的精細度保持一致，否則服務的工作負載會自然地透過最小跨小組互動進行細分。範例為 `客戶 ID` 或 `資源 ID`。 
   +  分割區索引鍵必須在所有請求中都可供使用，無論是直接或由其他參數確定性地推斷。 

1.  **持續性小組對應**：上游服務在其資源的生命週期中應該只與單一小組互動。
   +  依據工作負載而定，可能需要小組遷移策略，以便從其中一個小組將資料遷移到另一個小組。可能需要小組遷移的可能情境是，如果您的工作負載中特定使用者或資源變得太大並且要求它具備專有小組。 
   +  小組不應該在小組之間共用狀態或元件。 
   +  因此，應該避免跨小組互動或保持在最低程度，因為這些互動會建立小組之間的相依性，因而消滅故障隔離改善。 

1.  **路由器層**：路由器層會在小組之間共用元件，因此無法遵循與小組相同的區隔策略。
   +  建議路由器層以有效率運算的方式使用分割區對應演算法將請求分發到個別小組，例如結合加密雜湊函數和模組化算術以將分割區索引鍵對應至小組。 
   +  若要避免多小組影響，路由層必須保持簡單並且盡可能水平擴展，如此才能避免此層級內的複雜商業邏輯。這樣有增加的優點，隨時都容易了解其預期行為，以獲得徹底的可測試性。如同 Colm MacCárthaigh 在[可靠性、持續工作，以及咖啡時刻](https://aws.amazon.com/builders-library/reliability-and-constant-work/)中所說明，簡單設計和持續工作模式可產生可靠的系統並且降低抗脆弱性。 

1.  **小組大小**：小組應該有最大大小，而且不應該允許成長超出此大小。
   +  最大大小應該藉由執行徹底測試來識別，直到觸及中斷點並且建立安全的操作邊距。如需如何實作測試實務的詳細資訊，請參閱 [REL07-BP04 對工作負載執行負載測試](rel_adapt_to_changes_load_tested_adapt.md) 
   +  整體工作負載應該透過新增額外小組來成長，讓工作負載隨著需求的增加而擴展。 

1.  **多可用區域或多區域策略**：應該利用彈性的多個層次來保護不同的失敗網域。
   +  對於彈性，您應該使用建置防禦層的方法。一層透過使用多個 AZ 建置高度可用的架構來防範更小、更常見的中斷。另一防御層旨在防範發生罕見事件，例如廣泛的自然災害和區域級中斷。這第二層涉及架構您的應用程序以跨越多個 AWS 區域。針對您的工作負載實作多區域策略有助於其防範影響國家一大片地理區域的廣泛自然災害，或整個區域範圍的技術失敗。請注意，實作多區域架構可能相當複雜，並且通常對於大多數工作負載而言不是必要的。如需詳細資訊，請參閱 [REL10-BP02 為您的多位置部署選取適當位置](rel_fault_isolation_select_location.md)。 

1.  **程式碼部署**：應該偏向交錯程式碼部署策略，而不是將程式碼變更同時部署到所有小組。
   +  這樣可協助將多個小組由於不良部署或人為錯誤的潛在失敗降至最低。如需詳細資訊，請參閱[自動化安全、無人為介入的部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)。 

 **未建立此最佳實務時的風險暴露等級：**高 

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

 **相關的最佳實務：** 
+  [REL07-BP04 對工作負載執行負載測試](rel_adapt_to_changes_load_tested_adapt.md) 
+  [REL10-BP02 為您的多位置部署選取適當位置](rel_fault_isolation_select_location.md) 

 **相關文件：** 
+  [可靠性、持續工作，以及咖啡時刻](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 
+ [AWS 和區隔](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/)
+ [使用隨機切換分區隔離工作負載](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+  [自動化安全、無人為介入的部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) 

 **相關影片：** 
+ [AWS re:Invent 2018：閉環與開放思維：如何取得大小型系統的控制權](https://www.youtube.com/watch?v=O8xLxNje30M)
+  [AWS re:Invent 2018：AWS 如何最大程度地減小故障的影響範圍 (ARC338)](https://youtu.be/swQbA4zub20) 
+  [隨機切換分區：AWS re:Invent 2019：Amazon Builders’ Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=1373) 
+ [AWS Summit ANZ 2021 - 所有事情都一直失敗：設計彈性](https://www.youtube.com/watch?v=wUzSeSfu1XA)

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