# 可靠性 可靠性支柱包括工作負載如預期般正確、一致地執行其預期功能的能力。包括在整個生命週期中執行及測試工作負載。本白皮書深入說明在 AWS 上實作可靠工作負載的相關事項，提供最佳實務指引。 **Topics** + [彈性的共同責任模型](shared-responsibility-model-for-resiliency.md) + [設計原則](design-principles.md) + [定義](definitions.md) + [了解可用性需求](understanding-availability-needs.md) # 彈性的共同責任模型 彈性是 AWS 與您之間的共同責任。您了解在此共用模型之下，做為彈性一部分的災難復原 (DR) 和可用性如何操作相當重要。 **AWS 責任 - 雲端的彈性** AWS 會負責基礎設施的彈性，以執行 AWS 雲端 提供的所有服務。此基礎設施包含執行 AWS 雲端 服務的硬體、軟體、聯網以及設施。AWS 會採取商業上合理的努力來讓這些 AWS 雲端服務可供使用，以確保服務可用性符合或超過 [AWS 服務水準協議 (SLA)](https://aws.amazon.com/legal/service-level-agreements/)。 [AWS 全球雲端基礎設施](https://aws.amazon.com/about-aws/global-infrastructure/)旨在可讓客戶建置高彈性的工作負載架構。每個 AWS 區域 區域都是完全隔離的，由多個[可用區域](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/#Availability_Zones)組成，這些區域是基礎設施的實體隔離分區。可用區域會隔離可能影響工作負載彈性的故障，防止這些故障影響區域中的其他區域。但是於此同時 AWS 區域中的所有區域都是使用完全備援的專用都會光纖 (在區域之間提供高輸送量、低延遲網路)，搭配高頻寬、低延遲聯網來互連。區域之間的所有流量都會加密。網路效能足以完成區域之間的同步複寫。應用程式跨 AZ 分割時，公司可以獲得更好的隔離和保護，讓您免於停電、雷擊、龍捲風、颶風等問題。 **客戶責任 - 雲端中的彈性** 您的責任是由您選取的 AWS 雲端服務來決定的。這決定您在履行彈性責任過程中必須執行的設定工作量。例如，Amazon Elastic Compute Cloud (Amazon EC2) 之類的服務需要客戶執行所有必要的彈性組態和管理任務。部署 Amazon EC2 執行個體的客戶要負責[在多個位置部署 Amazon EC2 執行個體](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) (例如 AWS 可用區域)、[實作自我修復](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html)，使用例如 Auto Scaling 的服務，並且針對安裝在執行個體上的應用程式使用[彈性工作負載架構最佳實務](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html)。對於 Amazon S3 和 Amazon DynamoDB 等受管服務，AWS 會操作基礎設施層、作業系統和平台，而且客戶會存取端點以儲存和擷取資料。您負責管理您的資料的彈性，包括備份、版本控制和複寫策略。 在 AWS 區域中的多個可用區域之間部署您的工作負載，是高可用性策略的一部分，該策略的設計目的是藉由將問題隔離到其中一個可用區域來保護工作負載，使用其他可用區域的備援持續為請求提供服務。多可用區域架構也是 DR 策略的一部分，其設計目的是讓工作負載更好地隔離，並且防範例如停電、雷擊、龍捲風、地震等問題。DR 策略也會使用多個 AWS 區域。例如，在主動/被動組態中，如果主動區域再也無法為請求提供服務，則工作負載的服務會從其主動區域容錯移轉到其 DR 區域。 ![\[圖表說明共用彈性模型。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/shared-model-resiliency.png) 您可以使用 AWS 服務來達成您的彈性目標。身為客戶，您負責管理系統的下列層面，達成雲端中的彈性。如需具體各個服務的詳細資訊，請參閱 [AWS 文件](https://docs.aws.amazon.com/index.html)。 **聯網、配額和限制** + 此區域的共同責任模式最佳實務在[基礎](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/foundations.html)底下詳細說明。 + 根據適用情況下的預期負載請求增加，使用足夠的空間規劃您的架構，以便擴展和了解您所包含服務的[服務配額](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/manage-service-quotas-and-constraints.html)和限制。 + 將您的[網路拓撲](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html)設計成高度可用、備援和可擴展。 **變更管理和營運彈性** + [變更管理](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/change-management.html)包括如何在您的環境中引入和管理變更。[實作變更](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/implement-change.html)需要建置執行手冊並且保持最新狀態，以及您的應用程式和基礎設施的部署策略。 + [監控工作負載資源](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/monitor-workload-resources.html)的彈性策略會考慮所有元件，包括技術和商業指標、通知、自動化和分析。 + 雲端中的工作負載必須[適應需求變更](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-adapt-to-changes-in-demand.html)擴展，以因應損害或用量波動。 **可觀測性和失敗管理** + 需要透過監控觀察失敗才能自動化修復，讓您的工作負載可以[承受元件失敗](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html)。 + [失敗管理](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/failure-management.html)需要[備份資料](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/back-up-data.html)、套用最佳實務以便讓您的工作負載承受元件失敗，以及[規劃災難復原](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html)。 **工作負載架構** + 您的[工作負載架構](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html)包括您如何設計商業網域的服務、套用 SOA 和分散式系統設計來防止失敗，以及建置限流、重試、佇列管理、逾時和緊急控制桿之類的功能。 + 仰賴經實證的 [AWS 解決方案](https://aws.amazon.com/solutions/)，[Amazon 建置者資料中心](https://aws.amazon.com/builders-library/)和[無伺服器模式](https://serverlessland.com/patterns)可以與最佳實務保持一致，並且立即開始實作。 + 使用持續改善將您的系統分解成分散式服務，更快擴展和創新。使用 [AWS 微型服務](https://aws.amazon.com/microservices/)指引和受管服務選項，簡化及加速您引入變更和創新的能力。 **持續測試關鍵基礎設施** + [測試可靠性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html)是指測試功能、效能和混沌層級，以及採用事件分析和演練日實務來建置專業知識，解決尚未充分了解的問題。 + 對於全面雲端和混合應用程式，了解發生問題或元件停機時的應用程式行為方式，可讓您快速且可靠地從中斷復原。 + 建立和記載可重複的試驗，了解事情未如預期般運作時，您的系統的行為方式。這些測試會證明您的整體彈性的有效性，並且在您的操作程序面臨實際失敗情境時，提供意見回饋循環。 # 設計原則 在雲端，有很多原則可協助您提高可靠性。討論最佳實務時，請謹記以下幾點： + **自動從故障中復原：**透過監控工作負載的關鍵績效指標 (KPI)，您可在達到臨界值時執行自動化。這些 KPI 應為業務價值的衡量指標，而非服務營運的技術方面。如此一來，即可自動通知和追蹤失敗，以及自動化可解決或修復失敗的復原程序。藉助更複雜的自動化功能，您可以在發生失敗前進行預測和修補。 + **測試復原程序：**在內部部署環境中，經常執行測試以證明工作負載可在特定情況下正常工作。測試通常不可用於驗證復原策略。在雲端，您可測試工作負載會發生哪些失敗情境，同時可驗證復原程序。您可使用自動化來模擬不同的失敗情境或重新建立會導致之前失敗的情境。此方法會在實際的失敗情境發生*前*公開您可以測試和修復的失敗路徑，從而降低風險。 + **水平擴展，以增加彙總工作負載的可用性：**使用多個小資源取代一個大資源，以降低整體工作負載上發生單一失敗時造成的影響。將請求分散到多個較小的資源，以確保它們不會有共同的失敗點。 + **停止猜測容量：**內部部署工作負載失敗的一個常見原因是資源飽和，即當對工作負載的需求超出該工作負載的容量時發生的情況 (這通常為阻斷服務攻擊的目標)。在雲端，您可以監控需求和工作負載利用率，並自動新增或刪除資源，以保持可滿足需求的最佳水平，而不會過度佈建或佈建不足。仍然存在限制，但是某些配額可以控制，而其他限制則可管理 (請參閱[管理 Service Quotas 和限制](manage-service-quotas-and-constraints.md))。 + **透過自動化管理變更：**應透過自動化來執行對基礎架構的變更。需要管理的變更包括之後可以追蹤和審查的自動化變更。 # 定義 本白皮書涵蓋雲端可靠性，並介紹以下四大領域的最佳實務： + 基礎 + 工作負載架構 + 變更管理 + 失敗管理 若要實現可靠性，您必須先從基礎開始，即服務配額和網路拓撲能適應工作負載的環境。分散式系統的工作負載架構在設計上必須能防止失敗並減輕失敗的影響。工作負載必須處理需求或要求的變更，且在設計上須能偵測失敗並自動進行自我修復。 **Topics** + [彈性和可靠性的組成部分](resiliency-and-the-components-of-reliability.md) + [可用性](availability.md) + [災難復原 (DR) 目標](disaster-recovery-dr-objectives.md) # 彈性和可靠性的組成部分 雲端中的工作負載可靠性取決於數項因素，其中主要的因素是*彈性*： + **彈性**是工作負載在以下方面的能力：從基礎架構或服務中斷恢復、動態取得運算資源以符合需求，以及緩解中斷狀況 (例如，設定錯誤或暫時性網路問題)。 影響工作負載可靠性的其他因素如下所述： + 卓越營運，包括變更自動化、使用程序手冊回應失敗，以及營運準備度審查 (ORR)，以確認應用程式已準備好用於生產營運。 + 安全性，包括防止惡意動作項目損毀資料或基礎架構，進而影響可用性。例如，加密備份以確保資料安全無虞。 + 效能達成效率，包括實現工作負載最大請求率和最小延遲的設計。 + 成本最佳化，包括是否在 EC2 執行個體上投入更多資源，以實現靜態穩定性，或是否在需要更多容量時仰賴自動調整規模等方面的權衡。 彈性是本白皮書的重點。 其他四個方面也很重要，並都有各自的 [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) 支柱白皮書說明。這裡的許多最佳實務也會處理可靠性的這些層面，但重點是在彈性上。 # 可用性 *可用性* (也稱為*服務可用性*) 既是定量衡量彈性的常用指標，也是目標彈性目標。 + **可用性**是工作負載可供使用的時間百分比。 *可供使用*是指工作負載在需要時成功執行其議定的功能。 該百分比根據一段時間 (例如，一個月、一年或過去三年) 計算得出。套用最嚴格的解釋，只要應用程式無法正常運行 (包括計劃和非計劃中的中斷)，可用性就會降低。我們將*可用性*定義如下： ![\[\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/availability-formula.png) + 可用性是一段時間 (通常為一個月或一年) 內運行時間的百分比 (例如 99.9%) + 常見的簡寫僅以「九的數量」表示；例如，「五個九」可轉化為 99.999% 的可用率 + 一些客戶選擇從公式中的*總時間*中排除計劃的服務停機時間 (例如，計劃的維護)。不過，不建議這樣做，因為您的使用者可能想要在這些時間使用您的服務。 下表為通用應用程式可用性設計目標及在保證仍可達到目標的情況下，一年內發生的最大中斷時長。該表格包含我們通常會在每個可用性層看到的應用程式類型範例。在本文件中，我們將引用這些值。 | 可用性 | 最高的無法使用程度 (每年) | 應用程式類別 | | --- | --- | --- | | 99% | 3 天 15 小時 | 批次處理、資料擷取、傳輸和載入任務 | | 99.9% | 8 小時 45 分鐘 | 知識管理、專案追蹤等內部工具 | | 99.95% | 4 小時 22 分鐘 | 線上商務、銷售點 | | 99.99% | 52 分鐘 | 影片交付、廣播工作負載 | | 99.999% | 5 分鐘 | ATM 交易、電信工作負載 | **根據請求衡量可用性。**對於您的服務，計算成功和失敗的請求數可能比計算「可用時間」更容易。在此情況下，可以使用下列計算： ![\[Mathematical formula for calculating availability using successful responses divided by valid requests.\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/availability-formula-requests.png) 這通常以一分鐘或五分鐘期間進行測量。然後可以根據這些期間的平均值計算每月運行時間百分比 (時間型可用性測量)。如果在給定期間未收到任何請求，則該時間的可用率為 100%。 **使用硬相依性計算可用性。**許多系統對其他系統存有硬相依性，其中相依系統中的中斷會直接轉化為調用系統的中斷。這與軟相依性相反，後者在應用程式中補償了相依系統的故障。若發生這種硬相依性，調用系統的可用性是相依系統的可用性的乘積。例如，如果您有一個設計為 99.99% 可用性的系統，並且與其他兩個設計為 99.99% 可用性的獨立系統存在硬相依性，則該工作負載理論上可以實現 99.97% 的可用性： Availinvok × Avail*dep1* × Avail*dep2* = Availworkload 99.99% × 99.99% × 99.99% = 99.97% 因此，在計算您自己的相依性及其可用性設計目標時，務必要對其有一定的了解。 **使用冗餘元件計算可用性。**當系統涉及使用獨立的備援元件 (例如，不同可用區域中的備援資源) 時，理論可用性的計算方式為 100% 減去元件故障率的乘積。例如，如果系統使用兩個獨立的元件，每個元件的可用性為 99.9%，則此相依性的有效可用性為 99.9999%： ![\[Diagram showing calculation of availability with redundant components in a system.\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/image2.png) Availeffective = *Avail*MAX − ((100%−Availdependency)×(100%−Availdependency)) 99.9999% = 100% − (0.1%×0.1%) *捷徑計算*：如果您的計算中所有元件的可用性僅由數字 9 組成，則您可以將 9 數字的計數相加來得到您的答案。在上面範例中，兩個具有三個 9 可用性的備援獨立組件造成六個 9。 **計算相依系統可用性。**某些相依系統提供了有關其可用性的指引，包括許多 AWS 服務的可用性設計目標。但是，在無法使用此功能的情況下 (例如，製造商未發布可用性訊息的元件)，其中一種估算方法是確定**平均故障間隔時間 (MTBF)** 和**平均復原時間 (MTTR)**。可透過以下方式確定可用性估算值： ![\[\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/avail-est-formula.png) 例如，如果 MTBF 為 150 天，MTTR 為 1 小時，則可用性估算值為 99.97%。 如需詳細資訊，請參閱 [Availability and Beyond: Understanding and improving the resilience of distributed systems on AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-and-beyond-improving-resilience.html)，該文件可協助您計算可用性。 **可用性成本。**設計具有較高可用性的應用程式通常會導致成本增加，因此在著手進行應用程式設計之前，有必要識別出真正的可用性需求。對於在詳盡的失敗情境下進行測試和驗證，高可用性會實施更嚴格的要求。他們需要自動化以從各種失敗中復原，並且要求系統營運的所有方面均以相似的方式進行建置和測試，已達到相同的標準。例如，必須進行容量的新增或刪除，更新軟體或組態變更的部署或還原，或者系統資料的移轉，以達到所需的可用性目標。在非常高的可用性水平上，軟體開發成本增加了，但由於在部署系統中需要更緩慢地移動，創新將會受到影響。因此，該指南詳述了如何套用標準，以及考慮操作系統的整個生命週期中的適當可用性目標。 在具有較高可用性設計目標的系統中，成本不斷攀升的另一種方式是選擇相依系統。在這些較高的目標下，可以選擇哪些軟體或服務作為相依系統，取決於這些服務中的哪一項具有我們前面所述的大量投資。隨著可用性設計目標的提高，通常會發現更少的多功能服務 (如關聯式資料庫) 和更多的專用服務。這是因為後者更易於評估、測試和自動化，並且可減少與包含但未使用的功能進行意外互動的可能性。 # 災難復原 (DR) 目標 除了可用性目標之外，您的彈性策略還應包括基於策略的災難復原 (DR) 目標，以在發生災難事件時復原您的工作負載。災難復原專注於回應自然災難、大規模技術故障，或攻擊或錯誤等人為威脅的一次性復原目標。這與可用性不同，其會測量一段時間內回應元件失敗、負載峰值或軟體錯誤的平均彈性。 **復原時間點目標 (RTO)** 由組織定義。RTO 是服務中斷與恢復服務之間的最大可接受延遲。這會決定可接受的服務無法使用之時間長度。 **復原點目標 (RPO)** 由組織定義。RPO 是自上次資料復原點之後的最大可接受時間長度。這會決定最後一個復原點與服務中斷之間可接受的資料遺失。 ![\[Business continuity timeline showing RPO, disaster event, and RTO with data loss and downtime periods.\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/business-continuity.png) *RPO (復原點目標)、RTO (復原時間點目標) 和災難事件的關係。* RTO 與 MTTR (平均復原時間) 相似，兩者都會測量從中斷開始到工作負載復原的這段時間。不過，MTTR 是從一段時間內的多項影響可用性事件取得的平均值，而 RTO 則是*單一*影響可用性事件允許的目標或最大值。 # 了解可用性需求 通常最開始會將應用程式的可用性視為整個應用程式的單一目標。但是，在仔細檢查後，我們經常會發現應用程式或服務的某些方面具有不同的可用性要求。例如，某些系統可能會優先考慮在擷取現有資料之前接收和儲存新資料的能力。其他系統優先於即時營運，而不是變更系統組態或環境的營運。服務可能在一天中的某些時段有很高的可用性要求，但可以忍受非這些時段內更長的中斷時間。您可以透過下列幾種方法將單一應用程式分解為若干個組成部分，並評估每個部分的可用性要求。這樣做的好處是可以根據特定需求，將您的工作 (和費用) 聚焦於可用性上，而不是按照最嚴格的要求設計整個系統。 | 建議 | | --- | | 嚴格評估應用程式的獨特方面，並在適當時區分可用性和災難復原設計目標，以反映您的業務需求。 | 在 AWS 內，我們通常將服務分為「資料平面」和「控制平面」。資料平面負責提供即時服務，而控制平面則用於設定環境。例如，Amazon EC2 執行個體、Amazon RDS 資料庫和 Amazon DynamoDB 資料表讀取/寫入操作均為資料平面操作。相反，啟動新的 EC2 執行個體或 RDS 資料庫，或在 DynamoDB 中新增或變更資料表中繼資料則均會被視為控制平面操作。儘管高可用性對於所有這些功能都很重要，但資料平面通常具有比控制平面更高的可用性設計目標。因此，具有高可用性要求的工作負載應避免控制平面操作上的執行時間相依性。 許多 AWS 客戶都採用類似的方法來嚴格評估其應用程式，並識別具有不同可用性需求的子元件。然後，針對不同方面客製化可用性設計目標，並執行適當的工作以對系統進行設計。AWS 擁有豐富的工程應用經驗，並且具有一系列的可用性設計目標，包括達到 99.999% 或更高可用性的服務。AWS解決方案架構師 (SA) 可協助您針對可用性目標進行適當的設計。在設計程序的早期階段引入 AWS 可以提高我們協助您實現可用性目標的能力。規劃可用性不僅是在工作負載啟動之前進行。在您獲得營運經驗、從實際事件中獲得經驗以及經受各種類型的失敗後，也需持續執行此項工作以完善您的設計。然後，您可以進行適當的工作以改善您的實作。 工作負載所需的可用性需求必須與業務需求和關鍵性一致。先以定義的 RTO、RPO 和可用性定義業務關鍵性框架後，您之後便可評估各工作負載。諸如此類的方法規定，參與工作負載實作的人員需精通該架構，及其工作負載對業務需求的影響。