本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
REL10-BP01 將工作負載部署至多個位置
跨多個可用區域或視需要跨 AWS 區域,分配工作負載資料和資源。
AWS 中服務設計的基本原則是避免單一故障點,包括基礎實體基礎設施。AWS 在全球多個地理位置 (稱為區域) 提供雲端運算資源和服務。每個區域實際上和邏輯上都各自獨立,並且由三個以上的可用區域 (AZ) 所組成。可用區域在地理位置上彼此接近,但實際上是分開且隔離的。若您將工作負載分配到不同的可用區域和區域,就可降低發生火災、洪水、天災、地震和人為錯誤等威脅的風險。
建立位置策略來提供適合您工作負載的高可用性。
預期成果:實際執行工作負載會分散到多個可用區域 (AZ) 或區域,以實現容錯能力和高可用性。
常見的反模式:
-
您的實際行工作負載只存在單一可用區域中。
-
當多可用區域架構可滿足業務需求時,您卻實作多區域架構。
-
您的部署或資料變得不同步,進而導致組態偏離或資料複寫不足。
-
您未考量在這些元件之間的彈性和多位置需求不同的情況下,應用程式元件之間的相依性。
建立此最佳實務的優勢:
-
您的工作負載對於影響 AZ 或整個區域的事件較有彈性,例如電力或環境控制故障、天災、上游服務故障或網路問題。
-
您可以存取更廣泛的 Amazon EC2 執行個體庫存,並降低啟動特定 EC2 執行個體類型時發生 InsufficientCapacityExceptions (ICE) 的可能性。
未建立此最佳實務時的曝險等級:高
實作指引
至少在區域中的兩個可用區域 (AZ) 中部署和操作所有實際執行工作負載。
使用多個可用區域
可用區域是託管資源的位置,這些位置實際上彼此分隔,以避免因火災、洪水和龍捲風等風險而導致相互關聯失敗。每個可用區域都有單獨的實體基礎設施,包括公用電源連接、備用電源、機械服務,以及網路連線。此配置可將上述任一元件中的故障限制在只有受影響的可用區域。例如,若 AZ 範圍的事件使得受影響的可用區域中的 EC2 執行個體無法使用,您在其他可用區域中的執行個體仍然可用。
雖然實際上彼此分隔,但相同 AWS 區域 中的可用區域彼此接近,因此能提供高輸送量、低延遲 (僅幾毫秒) 聯網。您可以在可用區域之間同步複寫大多數工作負載的資料,而不會顯著影響使用者體驗。這表示,您可以在主動/主動或主動/待命組態中,與區域中使用可用區域。
所有與工作負載相關聯的運算都應分散到多個可用區域。這包括 Amazon EC2
您也應該複寫工作負載的資料,並且在多個可用區域中提供。有些 AWS 受管資料服務預設會在多個可用區域中複寫資料,例如 Amazon S3
如果您使用的是自我管理儲存體,例如 Amazon Elastic Block Store (EBS)
使用多個 AWS 區域
如果您的工作負載需要相當大的彈性 (例如,關鍵基礎設施、運作狀態相關應用程式,或是有嚴格的客戶或強制性可用性需求的服務),則您可能需要額外的可用性,而這並非單一 AWS 區域 能夠提供。在此情況下,您應該至少在兩個 AWS 區域 (假設您的資料落地要求允許) 中部署和操作工作負載。
AWS 區域 位於全球不同的地理區域和多個不同的大陸上。單是 AWS 區域 的實際分隔和隔離距離甚至就比可用區域還大。AWS 服務 (除了少數例外) 利用此設計在不同區域 (也稱為區域服務) 之間完全獨立運作。AWS 區域 服務的故障設計為,不會影響不同區域中的服務。
當您在多個區域中操作工作負載時,應考慮其他需求。由於不同區域中的資源彼此分隔且獨立,因此您必須在每個區域中複寫工作負載的元件。除了運算和資料服務之外,還包括基本的基礎設施,例如 VPC。
注意:當您考慮多區域設計時,務必確認您的工作負載能夠在單一區域中執行。如果您在區域之間建立相依性,讓某一個區域中的元件依賴另一個區域中的服務或元件,則可能會使得失敗的風險升高,並顯著降低可靠性狀態。
為了簡化多區域部署並維持一致性,AWS CloudFormation StackSets 可將整個 AWS 基礎設施複寫到多個區域。AWS CloudFormation
您也必須將資料複寫到您選擇的每一個區域。有許多 AWS 受管資料服務都提供跨區域複寫功能,包括 Amazon S3、Amazon DynamoDB、Amazon RDS、Amazon Aurora、Amazon Redshift、Amazon Elasticache 和 Amazon EFS。Amazon DynamoDB 全域資料表
AWS 還提供了將請求流量路由至區域部署的能力,帶來了極大的靈活度。例如,您可以使用 Amazon Route 53
即使您選擇不在多個區域中操作以實現高可用性,仍務必將多個區域納入您的災難復原 (DR) 策略中。如果可能,請在次要區域中,於暖待命或指示燈組態中複寫工作負載的基礎設施元件和資料。在此設計中,您會從主要區域複寫基準基礎設施,例如 VPC、Auto Scaling 群組、容器協調器和其他元件,但您會將待命區域中的可變大小的元件 (例如 EC2 執行個體和資料庫複本的數量) 設定為最小可操作大小。您也可以安排從主要區域持續複寫資料至待命區域。如果有事件發生,您可以橫向擴充或擴大待命區域中的資源,然後將其提升為主要區域。
實作步驟
-
與業務利害關係人和資料落地專家合作,確定哪些 AWS 區域 可以用來託管您的資源和資料。
-
與業務和技術利害關係人合作,評估您的工作負載,並判斷多可用區域方法 (單一 AWS 區域) 是否可滿足其彈性需求,或者需要多區域方法 (若允許多個區域)。使用多個區域可以實現更高的可用性,但可能也會帶來額外的複雜性和成本。評估時,請考慮下列因素:
-
業務目標和客戶需求:在可用區域或區域中發生影響工作負載的事件時,允許多久的停機時間? 如 REL13-BP01 定義停機時間和資料遺失的復原目標中所述,評估復原點目標。
-
災難復原 (DR) 需求:您希望確實防範哪種可能的災難? 請考慮從單一可用區域到整個區域的不同影響範圍下,資料遺失或長期無法使用的可能性。如果您將資料和資源複寫到不同的可用區域,而某一個可用區域發生持續故障,您可以在另一個可用區域中復原服務。如果您將資料和資源複寫到不同的區域,就可以在另一個區域中復原服務。
-
-
將運算資源部署到多個可用區域中。
-
在 VPC 中,於不同可用區域建立多個子網路。設定每個子網路,使其足以容納處理工作負載所需的資源,即使在發生事件時也一樣。如需詳細資訊,請參閱 REL02-BP03 確保 IP 子網路配置帳戶具有擴展性和可用性。
-
如果您使用 Amazon EC2 執行個體,請使用 EC2 Auto Scaling
來管理執行個體。建立 Auto Scaling 群組時,請指定您在上一個步驟中選擇的子網路。 -
如果您針對 Amazon ECS 或 Amazon EKS 使用 AWS Fargate 運算,請在建立 ECS Service、啟動 ECS 任務,或是為 EKS 建立 Fargate 設定檔時,選取您在第一個步驟中選擇的子網路。
-
如果您使用的是需要在 VPC 中執行的 AWS Lambda 函數,請在建立 Lambda 函數時選取您在第一個步驟中選擇的子網路。對於沒有 VPC 組態的任何函數,AWS Lambda 會自動為您管理可用性。
-
將負載平衡器等流量導向器放在運算資源前面。如果啟用跨區域負載平衡,AWS Application Load Balancer 和 Network Load Balancer 會偵測 EC2 執行個體和容器等目標何時因可用區域受損而無法連線,並將流量重新路由至運作狀態良好的可用區域中的目標。如果您停用跨區域負載平衡,請使用 Amazon Application Recovery Controller (ARC) 來提供區域轉移功能。如果您使用第三方負載平衡器,或已實作自己的負載平衡器,請在不同的可用區域中為它們設定多個前端。
-
-
在多個可用區域中複寫工作負載的資料。
-
如果您使用 AWS 受管資料服務,例如 Amazon RDS、Amazon ElastiCache 或 Amazon FSx,請詳讀其使用者指南,以了解其資料複寫和復原功能。視需要啟用跨可用區複寫和容錯移轉。
-
如果您使用 AWS 受管儲存服務,例如 Amazon S3、Amazon EFS 和 Amazon FSx,請避免針對需要高耐久性的資料使用單一可用區域或單一區域組態。針對這些服務使用多可用區域組態。詳閱個別服務的使用者指南,判斷多可用區域複寫為預設啟用,或是您必須啟用它。
-
如果您執行自我管理的資料庫、佇列或其他儲存服務,請根據應用程式的說明或最佳實務安排多可用區域複寫。熟悉應用程式的容錯移轉程序。
-
-
設定您的 DNS 服務,使其偵測 AZ 受損情形,並將流量重新路由至運作狀態良好的可用區域。Amazon Route 53 與 Elastic Load Balancer 搭配使用時,可以自動執行此操作。Route 53 也可以設定為擁有容錯移轉記錄,這些記錄使用運作狀態檢查來回應查詢,並且只提供運作狀態良好的 IP 位址。對於用於容錯移轉的任何 DNS 記錄,請指定短存留時間 (TTL) 值 (例如 60 秒或更短),這樣做有助於防止記錄快取阻礙復原 (Route 53 別名記錄會為您提供適當的 TTL)。
使用多個 AWS 區域 時的其他步驟
-
複寫工作負載在所選區域中使用的所有作業系統 (OS) 和應用程式程式碼。視需要使用 Amazon EC2 Image Builder 等解決方案複寫 EC2 執行個體所使用的 Amazon Machine Image (AMI)。使用 Amazon ECR 跨區域複寫等解決方案複寫存放在登錄檔中的容器映像。為任何用於儲存應用程式資源的 Amazon S3 儲存貯體啟用區域複寫。
-
將運算資源和組態中繼資料 (例如存放在 AWS Systems Manager 參數存放區的參數) 部署到多個區域。使用先前步驟所述的相同程序,但是複寫您用於工作負載的每個區域的組態。使用基礎設施即程式碼解決方案 (例如 AWS CloudFormation),在區域之間統一重複產生組態。如果您在災難復原的指示燈組態中使用次要區域,您可以將運算資源的數量減少到最小值以節省成本,並相應地增加復原時間。
-
將您的資料從主要區域複寫到次要區域。
-
Amazon DynamoDB 全域資料表提供可從任何支援的區域寫入的全域資料複本。使用其他 AWS 受管資料服務時 (例如 Amazon RDS、Amazon Aurora 和 Amazon Elasticache),您可以指定主要 (讀取/寫入) 區域和複本 (唯讀) 區域。如需區域複寫的詳細資訊,請參閱個別服務的使用者指南和開發人員指南。
-
如果您執行自我管理的資料庫,請根據應用程式的說明或最佳實務安排多區域複寫。熟悉應用程式的容錯移轉程序。
-
如果您的工作負載使用 AWS EventBridge,您可能需要將所選事件從主要區域轉送至次要區域。若要這麼做,請將次要區域中的事件匯流排指定為主要區域中相符事件的目標。
-
-
考慮是否要在不同區域使用相同的加密金鑰,以及使用的程度。在安全性和易用性之間取得平衡的典型方法,是針對區域本機資料和身分驗證使用區域範圍金鑰,以及使用全域範圍金鑰來加密在不同區域之間複寫的資料。AWS Key Management Service(KMS)
支援多區域金鑰,它可安全地分配和保護在區域之間共用的金鑰。 -
考慮使用 AWS Global Accelerator,透過將流量導向包含運作狀態良好之端點的區域來改善應用程式的可用性。
資源
相關的最佳實務:
相關文件:
相關影片: