# REL 10 如何使用故障隔離來保護您的工作負載？
故障隔離界限會在工作負載內將失敗影響限制至有限數量的元件。界限外的元件不受失敗影響。使用多個故障隔離界限時，您可以限制對工作負載的影響。
**Topics**
+ [REL10-BP01 將工作負載部署至多個位置](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 為您的多位置部署選取適當位置](rel_fault_isolation_select_location.md)
+ [REL10-BP03 針對限制在單一位置的元件將復原自動化](rel_fault_isolation_single_az_system.md)
+ [REL10-BP04 使用隔板架構限制影響範圍](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 將工作負載部署至多個位置
跨多個可用區域或視需要跨 AWS 區域，分配工作負載資料和資源。這些位置可以根據需要多樣化。
AWS 服務設計的基本原則之一是避免底層實體基礎設施中出現單點故障。這樣一來，我們將能建置可使用多個可用區域且能應對單一區故障的軟體和系統。同樣地，可將系統建置為能應對單一運算節點、單一儲存磁碟區或資料庫的單一執行個體的故障。建置依賴冗餘元件的系統時，務必要確保元件能獨立運行，而對於 AWS 區域而言，應能自主運行。具有冗餘元件的理論可用性計算，其優點只有在符合此條件時才有效。
**可用區域 (AZ)**
AWS 區域由多個可用區域組成，它們設計為彼此獨立作業。每個可用區域與其他可用區域是以有意義的實體距離隔開，從而可避免因火災、洪水和龍捲風等環境危害導致相關的失敗情境。每個可用區域也都具有獨立的實體基礎設施：可用區域內部和外部的公用電源專用連接、獨立的備用電源、獨立的機械服務以及獨立的網路連線。這種設計會將任何這些系統中的錯誤僅限制在受影響的可用區域。儘管在地理位置上是分開的，但可用區域位於啟用高輸送量、低延遲聯網的同一區域。整個 AWS 區域 (跨所有可用區域，由多個實體上獨立的資料中心組成) 可以視為工作負載的單一邏輯部署目標，包括同步複寫資料的能力 (例如，在資料庫之間)。這可讓您在主動/主動或主動/待命組態中使用可用區域。
可用區域是各自獨立的，因此當工作負載架構為使用多個區域時，工作負載的可用性也會隨之提高。一些 AWS 服務 (包括 Amazon EC2 執行個體資料平面) 會部署為嚴格的區域服務，其中它們與其所在的可用區域共享命運。不過，其他 AZ 中的 Amazon EC2 執行個體將不受影響並繼續運作。同樣地，如果可用區域中的失敗導致 Amazon Aurora 資料庫失敗，則未受影響 AZ 中的讀取副本 Aurora 執行個體可以自動提升為主要執行個體。另一方面，區域 AWS 服務 (例如 Amazon DynamoDB) 可內部使用主動/主動組態中的多個可用區域，以實現該服務的可用性設計目標，無需您設定 AZ 置放。
![\[圖表：顯示跨三個可用區域部署的多層架構。請注意，Amazon S3 和 Amazon DynamoDB 一律自動採用異地同步備份策略。ELB 也會部署至全部三個區域。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/multi-tier-architecture.png)
儘管 AWS 控制平面通常有能力管理整個區域 (多個可用區域) 內的資源，但是某些控制平面 (包括 Amazon EC2 和 Amazon EBS) 能夠將結果篩選至單一可用區域。完成此操作後，僅在指定的可用區域中處理該請求，從而減少其他可用區域中的中斷風險。此 AWS CLI 範例說明僅從 us-east-2c 可用區域取得 Amazon EC2 執行個體資訊：
```
AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
```
*AWS Local Zones*
AWS Local Zones 的作用與各自 AWS 區域內的可用區域類似，它們可在其中被選取為區域 AWS 資源 (如子網路和 EC2 執行個體) 的置放位置。特別之處在於它們不是位於相關聯的 AWS 區域，而是鄰近目前沒有 AWS 區域的大型人口、產業和 IT 中心。然而，它們仍可在本機區域的本機工作負載與在 AWS 區域中執行的本機工作負載之間保持高頻寬、安全的連線。您應該使用 AWS Local Zones，針對低延遲要求部署離使用者更近的工作負載。
**Amazon Global Edge Network**
Amazon Global Edge Network 由分布在全球各城市的節點組成。Amazon CloudFront 使用此網路以較低的延遲將內容交付給最終使用者。AWS Global Accelerator 讓您可以在這些節點建立工作負載端點，以便在靠近使用者的 AWS 全球網路提供引導服務。Amazon API Gateway 使用 CloudFront 分配啟用邊緣最佳化的 API 端點，以透過最接近的節點加快用戶端存取。
*AWS 區域*
AWS 區域都設計為自主的，因此，若要使用多區域方法，您要部署專用的服務副本至每個區域。
多區域方法常用於 *災難復原* 策略，以在一次性大規模事件發生時符合復原目標。請參閱 [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) 以取得這些策略的詳細資訊。然而在此，我們反而專注於 *可用性*，尋求隨時間交付平均運行時間目標。對於高可用性目標，多區域架構通常會設計為主動/主動，其中每個服務副本 (在其各自的區域中) 都是主動的 (服務請求)。
**建議**
您可以在單一 AWS 區域 內使用異地同步備份策略，滿足大部分工作負載的可靠性目標。僅在工作負載具有極端的可用性要求或其他需要多區域架構的業務目標時，才考慮多區域架構。
AWS 可讓您跨區域操作服務。例如，AWS 使用 Amazon Simple Storage Service (Amazon S3) 複寫、Amazon RDS 讀取複本 (包括 Aurora 讀取複本) 和 Amazon DynamoDB 全域表提供資料的連續、非同步資料複寫。透過持續複寫，您的資料版本幾乎可以立即在您的每個作用中區域中使用。
使用 AWS CloudFormation，您可以定義基礎設施，並以一致方式跨 AWS 帳戶 和跨 AWS 區域 進行部署。為了擴充此功能，AWS CloudFormation StackSets 會讓您可以使用單一作業跨多個帳戶和區域建立、更新或刪除 AWS CloudFormation 堆疊。對於 Amazon EC2 部署執行個體，AMI (Amazon Machine Image) 用來提供資訊，例如硬體組態和安裝的軟體。您可以實作 Amazon EC2 Image Builder 管道，建立您需要的 AMI，並將這些 AMI 複製到作用中區域。這可確保這些 *黃金 AMI* 具備您在每個新區域中部署和橫向擴展工作負載所需的一切。
若要路由流量，Amazon Route 53 和 AWS Global Accelerator 會啟用政策的定義，而這些政策可決定哪些使用者前往哪個作用中區域端點。透過 Global Accelerator，您可以設定流量刻度盤，來控制導向到每個應用程式端點的流量百分比。Route 53 支援這種百分比方法，也支援多種其他可用政策，包括地理位置臨近性和延遲型政策。Global Accelerator 自動利用廣泛的 AWS 邊緣伺服器網路，盡快將流量上線至 AWS 網路主幹，這會導致降低請求延遲。
所有這些功能都會運作，以保留每個區域的自主權。這種方法幾乎不存在例外情況，包括我們可提供全域交付的服務 (例如 Amazon CloudFront 和 Amazon Route 53) 以及 AWS Identity and Access Management (IAM) 服務的控制平面。大部分服務完全在單一區域內運行。
**內部部署資料中心**
對於在內部部署資料中心執行的工作負載，請盡可能架構混合式體驗。AWS Direct Connect 提供從內部設施連接至 AWS 的專用網路連線，讓您可以在兩種環境中執行。
另一個選項是使用 AWS Outposts 在內部設施執行 AWS 基礎設施和服務。AWS Outposts 是一種全受管服務，可將 AWS 基礎設施、AWS 服務、API 和工具延伸到您的資料中心。AWS 雲端中使用的硬體基礎設施與資料中心安裝的硬體基礎設施相同。AWS Outposts 會接著連接至最近的 AWS 區域 區域。然後，您可以使用 AWS Outposts 來支援低延遲或有本機資料處理要求的工作負載。
**若未建立此最佳實務，暴露的風險等級為：** 高
## 實作指引
+ 使用多個可用區域和 AWS 區域。跨多個可用區域或視需要跨 AWS 區域，分配工作負載資料和資源。這些位置可以根據需要多樣化。
+ 區域服務固有地跨可用區域部署。
+ 這包括 Amazon S3、Amazon DynamoDB 和 AWS Lambda (未連線至 VPC 時)
+ 將容器、執行個體和函數中的工作負載部署到多個可用區域中。使用多區域資料存放區，包括快取。使用 EC2 Auto Scaling 的功能、ECS 任務放置、AWS Lambda 函數組態 (在 VPC 中執行時) 和 ElastiCache 叢集。
+ 部署 Auto Scaling 群組時，使用單獨的可用區域中的子網路。
+ [範例：將執行個體分散到多個可用區域](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Amazon ECS 任務置放策略](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [設定 AWS Lambda 函數以存取 Amazon VPC 中的資源](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ [選擇區域和可用區域](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ 部署 Auto Scaling 群組時，使用單獨的可用區域中的子網路。
+ [範例：將執行個體分散到多個可用區域](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ 使用 ECS 任務置放參數，指定資料庫子網路群組。
+ [Amazon ECS 任務置放策略](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ 將函數設定為在 VPC 中執行時，在多個可用區域中使用子網路。
+ [設定 AWS Lambda 函數以存取 Amazon VPC 中的資源](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ 將多個可用區域與 ElastiCache 叢集一起使用。
+ [選擇區域和可用區域](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ 如果您的工作負載必須部署至多個區域，請選擇多區域策略。大多數的可靠性需求都可透過多個可用區域策略，在單一 AWS 區域內滿足。視需要使用多區域策略，以符合您的業務需求。
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ 在另一個 AWS 區域的備份可以進一步確保資料在需要時可用。
+ 有些工作負載會有法規要求，規定要使用多區域策略。
+ 針對您的工作負載評估 AWS Outposts。如果您的工作負載需要內部部署資料中心達到低延遲要求，或有本機資料處理要求。然後使用 AWS Outposts 在內部部署執行 AWS 基礎設施和服務
+ [什麼是 AWS Outposts？](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
+ 判斷 AWS Local Zones 是否協助您為使用者提供服務。如果您有低延遲要求，請查看 AWS Local Zones 是否靠近您的使用者。如果是如此，則使用它來部署更靠近這些使用者的工作負載。
+ [AWS Local Zones 常見問答集](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
## 資源
**相關文件：**
+ [AWS 全球基礎設施](https://aws.amazon.com/about-aws/global-infrastructure)
+ [AWS Local Zones 常見問答集](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Amazon ECS 任務置放策略](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [選擇區域和可用區域](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ [範例：將執行個體分散到多個可用區域](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [全域資料表：使用 DynamoDB 進行多區域複寫](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [使用 Amazon Aurora 全球資料庫](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [使用 AWS Services 部落格系列建立多區域應用程式](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [什麼是 AWS Outposts？](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
**相關影片：**
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019：AWS 全球網路基礎設施的創新和營運 (NET339)](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 為您的多位置部署選取適當位置
## 預期成果
如需高可用性，請一律 (如果可能) 將工作負載元件部署到多個可用區域 (AZ)，如圖 10 所示。對於具有極端彈性要求的工作負載，請仔細評估多區域架構的選項。
![\[圖表：顯示備份至另一個 AWS 區域的彈性異地同步備份資料庫部署\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/multi-az-architecture.png)
## 常用的反模式
+ 當異地同步備份架構滿足要求時，選擇設計多區域架構。
+ 如果這些元件之間的彈性和多位置要求不同，則不考慮應用程式元件之間的相依性。
## 建立此最佳實務的優勢
對於彈性，您應該使用建置防禦層的方法。一層透過使用多個 AZ 建置高度可用的架構來防範更小、更常見的中斷。另一防御層旨在防範發生罕見事件，例如廣泛的自然災害和區域級中斷。這第二層涉及架構您的應用程序以跨越多個 AWS 區域。
+ 99.5% 可用性和 99.99% 可用性之間的差異每月超過 3.5 小時。如果工作負載位於多個可用區域中，則工作負載的預期可用性只能達到「四個九」。
+ 透過在多個可用區域中執行您的工作負載，您可以隔離電源、冷卻和聯網中的故障，以及火災和洪水等大多數自然災害。
+ 針對您的工作負載實作多區域策略有助於其防範影響國家一大片地理區域的廣泛自然災害，或整個區域範圍的技術失敗。請注意，實作多區域架構可能相當複雜，並且通常對於大多數工作負載而言不是必要的。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
若是基於一個可用區域之中斷或局部損失的災難事件，在單一 AWS 區域內的多個可用區域中實作高可用工作負載，可緩解自然發生的災難和技術性災難。每個 AWS 區域都是由多個可用區域構成，每個可用區域都會與其他區域中的錯誤隔離開來，而且會隔開有意義的距離。不過，災難事件若包括失去多個可用區域元件的風險，而這些元件彼此相距甚遠，您應該實作災難復原選項，以緩解整個區域範圍的失敗。對於需要極端彈性的工作負載 (關鍵基礎設施、健康相關應用程式、金融系統基礎設施等)，可能需要多區域策略。
## 實作步驟
1. 評估您的工作負載並判斷異地同步備份方法 (單一 AWS 區域) 是否可以滿足彈性需求，或者它們是否需要多區域方法。實作多區域架構來滿足這些要求將引進額外的複雜性，因此請仔細考慮您的使用案例及其要求。使用單一 AWS 區域，幾乎可以一律符合彈性要求。在判斷是否需要使用多個區域時，請考慮以下可能的要求：
1. **災難復原 (DR)**：若是基於一個可用區域之中斷或局部損失的災難事件，在單一 AWS 區域內的多個可用區域中實作高可用工作負載，可緩解自然發生的災難和技術性災難。災難事件若包括失去多個可用區域元件的風險，而這些元件彼此相距甚遠，您應該跨多個區域實作災難復原，以緩解整個區域範圍的自然災難或技術失敗。
1. **高可用性 (HA)**：多區域架構 (在每個區域中使用多個可用區域) 可以用來實現大於四個 9 (> 99.99%) 的可用性。
1. **堆疊本地化**：將工作負載部署到全球對象時，您可以在不同的 AWS 區域 中部署本地化的堆疊，為這些區域中的對象提供服務。本地化可以包括語言、貨幣及存放的資料類型。
1. **接近使用者：** 將工作負載部署到全球對象時，您可以在接近最終使用者所在位置的 AWS 區域中部署堆疊來減少延遲。
1. **資料落地**：某些工作負載受制於資料落地要求，其中來自特定使用者的資料必須保留在特定國家/地區的邊界內。根據討論中的法規，您可以選擇將整個堆疊或只將資料部署到這些邊界內的 AWS 區域。
1. 以下是 AWS 服務提供的異地同步備份功能的一些範例：
1. 若要使用 EC2 或 ECS 保護工作負載，請在運算資源前面部署 Elastic Load Balancer。然後，Elastic Load Balancing 會提供解決方案，以偵測運作狀態不佳區域中的執行個體，並將流量路由至運作良好的區域。
1. [Application Load Balancers 入門](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html)
1. [Network Load Balancer 入門](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html)
1. 如果執行商務現成軟體的 EC2 執行個體不支援負載平衡，您可以透過實作異地同步備份災難復原方法來實現某種形式的容錯。
1. [REL13-BP02 使用定義的復原策略來滿足復原目標](rel_planning_for_recovery_disaster_recovery.md)
1. 對於 Amazon ECS 任務，將您的服務平均地部署在三個可用區域之中，以實現可用性與成本的平衡。
1. [Amazon ECS 可用性最佳實務 \$1 容器](https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/)
1. 對於非 Aurora Amazon RDS，您可以選擇異地同步備份做為組態選項。在主資料庫執行個體失敗時，Amazon RDS 會自動提升備用資料庫，以接收另一個可用區域中的流量。也可以建立多區域讀取複本來改善彈性。
1. [Amazon RDS 異地同步備份部署](https://aws.amazon.com/rds/features/multi-az/)
1. [在不同的 AWS 區域 中建立讀取複本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html)
1. 以下是 AWS 服務提供的多區域功能的一些範例：
1. 對於服務自動提供異地同步備份可用性的 Amazon S3 工作負載，如果需要多區域部署，請考慮使用多區域存取點。
1. [Amazon S3 中的多區域存取點](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html)
1. 對於服務自動提供異地同步備份可用性的 DynamoDB 資料表，您可以輕鬆地將現有的資料表轉換為全域表，以利用多個區域。
1. [將您的單一區域 Amazon DynamoDB 資料表轉換為全域表](https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/)
1. 如果您的工作負載面臨 Application Load Balancers 或 Network Load Balancer，請使用 AWS Global Accelerator，透過將流量導向到多個包含運作狀態良好之端點的區域，來改善應用程式的可用性。
1. [AWS Global Accelerator - AWS Global Accelerator 中標準加速器的端點 (amazon.com)](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoints.html)
1. 對於利用 AWS EventBridge 的應用程式，請考慮跨區域匯流排，將事件轉送到您選取的其他區域。
1. [在 AWS 區域 之間傳送和接收 Amazon EventBridge 事件](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
1. 對於 Amazon Aurora 資料庫，請考慮跨越多個 AWS 區域的 Aurora 全球資料庫。您也可以修改現有的叢集來新增區域。
1. [Amazon Aurora 全球資料庫入門](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html)
1. 如果您的工作負載包括 AWS Key Management Service (AWS KMS ) 加密金鑰，請考慮多區域金鑰是否適合您的應用程式。
1. [AWS KMS 中的多區域金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
1. 如需其他 AWS 服務功能，請在下列一文參閱此部落格系列： [使用 AWS Services 系列建立多區域應用程式](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
**實作計劃的工作量： **中到高
## 資源
**相關文件：**
+ [使用 AWS Services 系列建立多區域應用程式](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [AWS 上的災難復原 (DR) 架構，第 IV 部分：多站點主動/主動](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)
+ [AWS 全球基礎設施](https://aws.amazon.com/about-aws/global-infrastructure)
+ [AWS Local Zones 常見問答集](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [AWS 上的災難復原 (DR) 架構，第 I 部分：在雲端中復原的策略](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [災難復原在雲端中有所不同](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-is-different-in-the-cloud.html)
+ [全域資料表：使用 DynamoDB 進行多區域複寫](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
**相關影片：**
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Auth0：多區域高可用架構，可擴展至 1.5B\$1搭配自動容錯移轉的一個月登入](https://www.youtube.com/watch?v=vGywoYc_sA8)
**相關範例：**
+ [AWS 上的災難復原 (DR) 架構，第 I 部分：在雲端中復原的策略](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [DTCC 所達成的彈性程度遠超乎其在內部部署所能達到的](https://aws.amazon.com/solutions/case-studies/DTCC/)
+ [Expedia Group 使用多區域、多可用區域架構，搭配專有的 DNS 服務，為應用程式提高彈性](https://aws.amazon.com/solutions/case-studies/expedia/)
+ [使用者：多區域 Kafka 的災難復原](https://eng.uber.com/kafka/)
+ [Netflix：多區域彈性的主動-主動](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b)
+ [我們如何為 Atlassian Cloud 建置資料彈性](https://www.atlassian.com/engineering/how-we-build-data-residency-for-atlassian-cloud)
+ [Intuit TurboTax 在兩個區域上執行](https://www.youtube.com/watch?v=286XyWx5xdQ)
# REL10-BP03 針對限制在單一位置的元件將復原自動化
如果工作負載的元件只能在單一可用區域或內部部署資料中心執行，您必須在定義的復原目標內實作完整重建工作負載的功能。
如果因為技術限制而無法實作將工作負載部署至多個位置的最佳實務，您必須實作彈性的替代路徑。您必須將以下能力自動化：重新建立必要基礎設施、重新部署應用程式，以及針對這些案例重新建立必要資料。
例如，Amazon EMR 會在相同可用區域中啟動指定叢集的所有節點，因為在相同區域執行叢集可以提供更高的資料存取速率，從而能提高任務流程的效能。如果為實現工作負載彈性而需要此元件，您必須要有方法重新部署叢集及其資料。此外，對於 Amazon EMR，您還應以異地同步備份以外的方式佈建冗餘。您可以佈建 [多個節點](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html)。使用 [EMR 檔案系統 (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html)時，EMR 中的資料可存放在 Amazon S3 中，然後可複寫至多個可用區域或 AWS 區域。
同樣地，對於 Amazon Redshift，它預設會將叢集佈建在您所選 AWS 區域內隨機選取的可用區域中。所有叢集節點都佈建在相同區域中。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 實作自我修復。盡可能使用 Automatic Scaling 來部署執行個體或容器。如果無法使用 Automatic Scaling，則對 EC2 執行個體使用自動復原，或者根據 Amazon EC2 或 ECS 容器生命週期事件實作自我修復自動化。
+ 對於不需要單個執行個體 IP 地址、私有 IP 地址、彈性 IP 地址和執行個體中繼資料的執行個體和容器工作負載，使用 Auto Scaling 群組。
+ [什麼是 EC2 自動擴展？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [服務自動擴展](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ 啟動組態使用者資料可用於實作自動自我修復大多數工作負載。
+ 對於需要單個執行個體 IP 地址、私有 IP 地址、彈性 IP 地址和執行個體中繼資料的工作負載，使用 EC2 執行個體的自動復原。
+ [復原您的執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ 在偵測到執行個體失敗時，自動復原會將提醒傳送到 SNS 主題。
+ 在無法使用 Auto Scaling 或 EC2 復原的情況下，使用 EC2 執行個體生命週期事件或 ECS 事件自動執行自我修復。
+ [EC2 Auto Scaling 生命週期掛鉤](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Amazon ECS 事件](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ 使用事件來叫用自動化，以根據您所需的過程邏輯來修復您的元件。
## 資源
**相關文件：**
+ [Amazon ECS 事件](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [EC2 Auto Scaling 生命週期掛鉤](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [復原您的執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [服務自動擴展](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [什麼是 EC2 自動擴展？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL10-BP04 使用隔板架構限制影響範圍
如同船舶上的隔板一樣，此模式可確保失敗限制在一小部分的請求或用戶端中，如此一來才能限制受損的請求數量，讓大部分的請求可以繼續運行，而不會發生錯誤。資料的隔板通常稱為分割區，而服務的隔板稱為儲存格。
在 *以儲存格為基礎的架構中*，每個儲存格都是完整的獨立服務執行個體，且具有固定的大小上限。隨著負載增加，工作負載會增加更多儲存格。分割區索引鍵用於傳入流量，以判斷使用哪個儲存格處理請求。任何失敗都會限制在它發生的單一儲存格之中，因此受損的請求數量會受到限制，而其他儲存格會繼續運行，且不會發生錯誤。務必要識別適當的分割區索引鍵，以最大程度地減少跨儲存格互動，並避免在每個請求中都加入複雜的對應服務。需要複雜對應的服務最終僅僅是將問題移轉到了對應服務，而需要跨儲存格互動的服務則會在儲存格之間建立相依性 (因此減低了假定的可用性改善)。
![\[圖表：顯示儲存格型架構\]](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)
除儲存格之外，分區還可用於伺服器、佇列或其他資源。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 使用隔板架構。如同船舶上的隔板一樣，此模式可確保失敗限制在一小部分的請求/使用者中，如此一來才能限制受損的請求數量，讓大部分的請求可以繼續運行，而不會發生錯誤。資料的隔板通常稱為分割區，而服務的隔板稱為儲存格。
+ [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)
## 資源
**相關文件：**
+ [隨機分片：神奇的大型故障隔離](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/)