可靠性
可靠性支柱包含工作負載如預期般正確、一致地執行其預期功能的能力,這包括在其整個生命週期中操作和測試工作負載的能力。
可靠性支柱概述了設計原則、最佳實務和相關問題。您可以在可靠性支柱白皮書中找到實作的指引。
設計原則
有 five 項雲端可靠性設計原則:
-
自動從失敗中復原: 透過監控工作負載的關鍵績效指標 (KPI),您可在達到臨界值時觸發自動化。這些 KPI 應為業務價值的衡量指標,而非服務營運的技術方面。如此一來,即可自動通知和追蹤失敗,以及自動化可解決或修復失敗的復原程序。藉助更複雜的自動化功能,您可以在發生失敗前進行預測和修補。
-
測試復原程序: 在內部部署環境中,經常執行測試以證明工作負載可在特定情況下正常工作。測試通常不可用於驗證復原策略。在雲端,您可測試工作負載會發生哪些失敗情境,同時您可驗證復原程序。您可使用自動化來模擬不同的失敗情境或重新建立會導致之前失敗的情境。此方法會在實際的失敗情境發生前公開您可以測試和修復的失敗路徑,從而降低風險。
-
水平擴展以提高總體工作負載可用性: 使用多個小資源取代一個大資源,以降低整體工作負載上發生單一失敗時造成的影響。將請求分散在多個較小的資源中,以確保它們不會共享常見失敗點。
-
停止猜測容量: 內部部署工作負載失敗的一個常見原因是資源飽和,即當對工作負載的需求超出該工作負載的容量時發生的情況 (這通常為阻斷服務攻擊的目標)。在雲端,您可以監控需求和工作負載利用率,並自動新增或刪除資源,以保持可滿足需求的最佳水平,而不會過度佈建或佈建不足。仍然存在限制,但是某些配額可以控制,而其他限制則可管理 (請參閱管理服務配額和限制)。
-
管理自動化變更: 應使用自動化來執行對基礎設施的變更。需要管理的變更包括之後可以追蹤和審查的自動化變更。
定義
有 four 個雲端可靠性最佳實務方面:
若要實現可靠性,您必須先從基礎開始,即服務配額和網路拓撲能適應工作負載的環境。分散式系統的工作負載架構在設計上必須能防止失敗並減輕失敗的影響。工作負載必須處理需求或要求的變更,且在設計上須能偵測失敗並自動進行自我修復。
最佳實務
基礎
基礎要求是其範圍超過單一工作負載或專案的要求。在建立任何系統架構之前,應確立會影響可靠性的基本要求。例如,您必須為資料中心提供足夠的網路頻寬。
藉助 AWS,這些基礎需求中的大多數已予以納入或可以按需要進行處理。設計的雲端近乎無限,因此 AWS 有責任滿足足夠的聯網和運算容量的要求,讓您可以根據需要自由變更資源大小和分配。
下列問題著重於可靠性方面的這些考量。
REL 1: 您如何管理服務配額和限制? |
REL 2: 如何規劃您的網路拓撲? |
雲端型工作負載架構會有服務配額 (也稱為服務限制)。這些配額旨在用於防止不慎佈建超過您所需的資源,並限制 API 操作上的請求率,以防止服務遭到濫用。工作負載經常存在於多個環境中。您必須監控和管理這些適用於所有工作負載環境的配額。這些環境包括多個 (可公開存取和私有的) 雲端環境,且可能包含您現有的資料中心基礎設施。計畫必須包括系統內和系統間連接、公有 IP 地址管理、私有 IP 地址管理和網域名稱解析等網路考量因素。
工作負載架構
可靠的工作負載始自於軟體和基礎設施的前期設計決策。您的架構選擇會對所有五大 Well-Architected 支柱的工作負載行為產生影響。為求可靠性,您必須依循特定模式。
藉助 AWS,工作負載開發人員可以選擇要使用的語言和技術。AWS 開發套件為 AWS 服務提供特定語言 API,讓編碼不再如此複雜。這些開發套件加上各種語言選項,可讓開發人員實作本文列出的可靠性最佳實務。開發人員也可在 The Amazon Builders' Library 中閱讀和了解 Amazon 如何建置和操作軟體。
下列問題著重於可靠性方面的這些考量。
REL 3: 如何設計您的工作負載服務架構? |
REL 4: 如何在分散式系統中設計防止失敗的互動? |
REL 5: 如何設計分散式系統中的互動以緩解或承受故障? |
分散式系統倚賴通訊網路來互連元件,例如伺服器或服務。即使這些網路上的資料遺失或延遲,您的工作負載仍必須可靠運作。分散式系統的元件必須以不會對其他元件或工作負載造成負面影響的方式運作。
變更管理
必須預期並因應工作負載或其環境的變更,才能實現可靠的工作負載操作。變更包括對工作負載強加的變更,例如需求峰值,以及內部的變更,例如功能部署和安全性修補程式。
您可以使用 AWS 監控工作負載的行為,並自動化對 KPI 的回應。例如,隨著工作負載的使用者增加,您的工作負載可能會新增其他伺服器。您可以控制有權作出工作負載變更的人員,並稽核這些變更的歷史紀錄。
下列問題著重於可靠性方面的這些考量。
REL 6: 如何監控工作負載資源? |
REL 7: 如何設計工作負載以適應需求變更? |
REL 8: 您如何實作變更? |
當您建立工作負載架構以根據需求的變更自動新增和刪除資源時,其不僅可以提高可靠性,而且還能確保企業成功不會成為負擔。在適當監控下,當 KPI 偏離預期規範時,您的團隊將會自動收到提醒。自動記錄對環境的變更,讓您可進行稽核並快速識別可能影響可靠性的動作。對變更管理的控制將確保您能執行交付所需可靠性的規則。
失敗管理
在任何合理複雜的系統中,均有可能會發生失敗。為達可靠性要求,您的工作負載應在發生失敗時察覺失敗,並採取行動以免影響可用性響。工作負載必須能夠承受失敗並自動修復問題。
藉助 AWS,您可以利用自動化對監控資料作出反應。例如,當特定指標超過臨界值時,您可以觸發可修補問題的自動化動作。此外,您無需嘗試診斷和修正生產環境中的失敗資源,而是可以用新的資源取代它,並對失敗的頻外資源執行分析。由於雲端可讓您以低成本建立整個系統的臨時版本,因此您可以使用自動化測試來驗證完整的復原程序。
下列問題著重於可靠性方面的這些考量。
REL 9: 您如何備份資料? |
REL 10: 如何使用故障隔離來保護您的工作負載? |
REL 11: 如何設計工作負載以承受元件失敗? |
REL 12: 如何測試可靠性? |
REL 13: 您如何規劃災難復原 (DR)? |
定期備份資料並測試備份檔案,從而確保您可以從邏輯和物理錯誤中復原。管理失敗的關鍵是對導致失敗的工作負載頻繁進行自動化測試,然後觀察它們可如何復原。定期執行此操作,並確保在出現重大工作負載變更後也能觸發此類測試。主動追蹤 KPI,例如復原時間目標 (RTO) 和復原點目標 (RPO),以評估工作負載的彈性 (尤其是在失敗測試情境下)。追蹤 KPI 將能助您識別和減輕單一失敗點。其目標是徹底測試您的工作負載復原程序,以便您確信即使面對持續問題,您也可以復原所有資料並繼續為客戶提供服務。應與執行正常生產程序一樣執行復原程序。
資源
請參閱以下資源,進一步了解我們的可靠性最佳實務:
Reliability Pillar: AWS Well-ArchitectedAWS Well-Architected Reliability Labs
The Amazon Builders' Library: How Amazon builds and operates software
AWS Documentation
AWS Global Infrastructure
AWS Auto Scaling: How Scaling Plans Work
Implementing Microservices on AWS
What Is AWS Backup?