REL 11: 如何設計工作負載以承受元件失敗？

需要高可用性和低平均復原時間 (MTTR) 的工作負載必須建立彈性架構。

資源

Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
AWS OpsWorks: Using Auto Healing to Replace Failed Instances
What Is Amazon EventBridge?
Amazon Route 53: Choosing a Routing Policy
What Is AWS Global Accelerator?
The Amazon Builders' Library: Static stability using Availability Zones
The Amazon Builders' Library: Implementing health checks
Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability
The Berkeley/Stanford Recovery-Oriented Computing (ROC) Project
Multiple data center HA network connectivity
AWS Marketplace: products that can be used for fault tolerance
APN Partner: partners that can help with automation of your fault tolerance

最佳實務:

• 監控工作負載的所有元件以偵測失敗: 持續監控工作負載的運作狀態，讓您和自動化系統在發生效能降低或完全失敗時能夠察覺。根據商業價值監控關鍵績效指標 (KPI)。

• 容錯移轉至運作良好的資源: 可確保如果發生資源故障，運作良好的資源可以繼續為請求提供服務。對於位置故障 (例如可用區域或 AWS 區域)，請確保您的系統已就位，可容錯移轉至未受影響位置中運作良好的資源。

• 將所有分層的修復自動化: 偵測到失敗時，使用自動化功能執行動作來進行修復。

• 使用靜態穩定性來防止雙模態行為: 雙模態行為是您的工作負載在正常和失敗模式下展現出不同的行為，例如，當可用區域失敗時，仰賴啟動新的執行個體。您應改為建置靜態穩定且僅以一種模式操作的工作負載。在這種情況下，如果移除一個可用區域，則在每個可用區域佈建足夠的執行個體來處理工作負載負載，然後使用 Elastic Load Balancing 或 Amazon Route 53 運作狀態檢查，將負載從受損的執行個體移出。

• 當事件影響可用性時傳送通知: 當偵測到重大事件時傳送通知，即使事件造成的問題已自動解決。

改進方案

監控工作負載的所有元件以偵測失敗

根據您的復原目標決定元件的收集間隔。

• 您的監控間隔取決於復原必須多快完成: 您的復原時間取決於所需的復原時間，因此您必須考量此時間和復原時間目標 (RTO)，藉以決定收集頻率。

設定元件的詳細監控。

• 判斷 EC2 執行個體和 Auto Scaling 是否需要詳細監控: 詳細監控提供 1 分鐘的間隔指標，預設監控則提供 5 分鐘的間隔指標。
  Enable or Disable Detailed Monitoring for Your Instance
  Monitoring Your Auto Scaling Groups and Instances Using Amazon CloudWatch
• 判斷 RDS 是否需要增強型監控: 增強型監控使用 RDS 執行個體上的代理程式，以取得 RDS 執行個體上不同處理程序或執行緒的實用資訊。
  Enhanced Monitoring

建立自訂指標測量業務關鍵績效指標 (KPI) : 工作負載會實作關鍵業務功能。這些功能應做為 KPI，以協助確定何時發生間接問題。
Publishing Custom Metrics

以使用者 Canary 監控使用者的故障體驗: 可執行和模擬客戶行為的綜合交易測試 (也稱為「Canary 測試」，但請別與 Canary 部署混淆)，是最重要的測試程序之一。針對來自不同遠端位置的工作負載端點持續執行這些測試。
Amazon CloudWatch Synthetics enables you to create user canaries

建立追蹤使用者體驗的自訂指標: 如果您可以檢測客戶的體驗，則可以判斷消費者體驗何時變差。
Publishing Custom Metrics

設定警示以偵測工作負載的任何部分何時未正常運作，並指示何時自動擴展資源。 : 警示會在儀表板上以視覺化方式顯示、透過 SNS 或電子郵件傳送提醒，以及使用 Auto Scaling 向上或向下擴展工作負載的資源。
Using Amazon CloudWatch Alarms

建立儀表板以視覺化指標: 儀表板可以讓您以視覺化方式查看趨勢、極端值和其他潛在問題的指標，或提供您可能想要調查之問題的指示。
Using CloudWatch Dashboards

容錯移轉至運作良好的資源

容錯移轉至運作良好的資源: 可確保如果發生資源故障，運作良好的資源可以繼續為請求提供服務。對於位置故障 (例如可用區域或 AWS 區域)，請確保您的系統已就位，可容錯移轉至未受影響位置中運作良好的資源。

• 如果您的工作負載使用 Amazon S3 或 Amazon DynamoDB 等 AWS 服務，則它們會自動部署至多個可用區域。如果發生失敗，AWS 控制平面會自動為您路由流量至運作良好的位置。
• 對於 Amazon RDS，您必須選擇異地同步備份做為組態選項，然後在發生失敗時，AWS 會自動將流量導向至運作良好的執行個體。
  High Availability (Multi-AZ) for Amazon RDS
• 對於 Amazon EC2 執行個體或 Amazon ECS 任務，您可以選擇要部署的可用區域。然後，Elastic Load Balancing 會提供解決方案，以偵測運作狀態不佳區域中的執行個體，並將流量路由至運作良好的區域。Elastic Load Balancing 甚至可將流量路由至內部部署資料中心內的元件。
• TRANSLATION REQUIRED
  • TRANSLATION REQUIRED
    Overview of Amazon RDS Read Replicas
  • TRANSLATION REQUIRED
    Amazon Route 53: Choosing a Routing Policy
    What Is AWS Global Accelerator?

將所有分層的修復自動化

使用 Auto Scaling 群組在應用程式中部署分層: Auto Scaling 可以對無狀態應用程式進行自我修復，並新增和移除容量。
How AWS Auto Scaling Works

對已部署無法在多個位置中部署之應用程式，且可以容忍失敗後重新開機的 EC2 執行個體，實作自動復原。 : 在應用程式無法部署於多個位置時，自動復原可以用來取代失敗硬體並重新啟動執行個體。 執行個體中繼資料和相關聯的 IP 地址，以及 Amazon EBS 磁碟區和 Lustre 及 Windows 的彈性檔案系統或檔案系統的掛載點皆會保留。
Amazon EC2 Automatic Recovery
Amazon Elastic Block Store (Amazon EBS)
Amazon Elastic File System (Amazon EFS)
What is Amazon FSx for Lustre?
What is Amazon FSx for Windows File Server?

• 您可以使用 AWS OpsWorks 在層級中設定 EC2 執行個體的自動修復
  AWS OpsWorks: Using Auto Healing to Replace Failed Instances

當您無法使用自動擴展或自動復原，或自動復原失敗時，則使用 AWS Step Functions 和 AWS Lambda 實作自動復原。 : 當您無法使用自動擴展，且無法使用自動復原或自動復原失敗時，則可以使用 AWS Step Functions 和 AWS Lambda 將修復作業自動化。
What is AWS Step Functions?
What is AWS Lambda?

• Amazon EventBridge 可用來監控並篩選事件，例如 CloudWatch 警示或其他 AWS 服務的狀態變更。根據事件資訊，它可以觸發 AWS Lambda (或其他目標)，在您的工作負載上執行自訂修復邏輯。
  What Is Amazon EventBridge?
  Using Amazon CloudWatch Alarms

使用靜態穩定性來防止雙模態行為

使用靜態穩定性來防止雙模態行為: 雙模態行為是您的工作負載在正常和失敗模式下展現出不同的行為，例如，當可用區域失敗時，仰賴啟動新的執行個體。
The Amazon Builders' Library: Static stability using Availability Zones
Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)

• 您應改為建置靜態穩定且僅以一種模式操作的系統。在這種情況下，如果移除一個可用區域，則在每個區域佈建足夠的執行個體來處理工作負載，然後使用 Elastic Load Balancing 或 Amazon Route 53 運作狀態檢查，將負載從受損的執行個體移出。
• 另一個雙模態行為範例是允許用戶端在發生失敗時繞過您的工作負載快取。這看起來可滿足用戶端需求的解決方案，但不應允許，因為這會大幅變更工作負載的需求，且可能導致失敗。

當事件影響可用性時傳送通知

當業務關鍵績效指標超過臨界值下限時，發出該指標的警示: 對業務 KPI 制定臨界值下限警示，有助於您知道何時無法使用工作負載或工作負載無法運作。
Creating a CloudWatch Alarm Based on a Static Threshold

叫用修復自動化的事件警示: 您可以直接叫用 SNS API，以透過您建立的任何自動化來傳送通知。
What is Amazon Simple Notification Service?