REL10-BP01 將工作負載部署至多個位置 - 可靠性支柱
實作指引資源

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 也會部署至全部三個區域。

圖 9：跨三個可用區域部署的多層架構。請注意，Amazon S3 和 Amazon DynamoDB 一律自動採用異地同步備份策略。ELB 也會部署至全部三個區域。

儘管 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 區域都設計為自主的，因此，若要使用多區域方法，您要部署專用的服務副本至每個區域。

多區域方法常用於 災難復原 策略，以在一次性大規模事件發生時符合復原目標。請參閱 災難復原 (DR) 計畫 以取得這些策略的詳細資訊。然而在此，我們反而專注於 可用性，尋求隨時間交付平均運行時間目標。對於高可用性目標，多區域架構通常會設計為主動/主動，其中每個服務副本 (在其各自的區域中) 都是主動的 (服務請求)。

建議

您可以在單一 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 來支援低延遲或有本機資料處理要求的工作負載。

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

實作指引

資源

相關文件：

相關影片：