# 設計工作負載以適應需求變更
可擴展的**工作負載**提供可自動新增或移除資源的彈性，讓資源能夠在任何特定時間點充分滿足目前的需求。
**Topics**
+ [REL07-BP01 取得或擴展資源時使用自動化](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 在偵測到工作負載受損時取得資源](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 偵測到工作負載需要更多資源時取得資源](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 Load 測試您的工作負載](rel_adapt_to_changes_load_tested_adapt.md)
# REL07-BP01 取得或擴展資源時使用自動化
雲端可靠性的基石，是基礎設施和資源的程式設計定義、佈建和管理。自動化可協助您簡化資源佈建、促進一致且安全的部署，以及在整個基礎設施中擴展資源。
**預期成果：**您管理自己的基礎設施即程式碼 (IaC)。您可以在版本控制系統 (VCS) 中定義和維護自己的基礎設施程式碼。您可以將佈建 AWS 資源的工作委派給自動化機制，並利用 Application Load Balancer (ALB)、Network Load Balancer (NLB) 和 Auto Scaling 群組等受管服務。您使用持續整合/持續交付 (CI/CD) 管道來佈建資源，以讓程式碼變更自動初始化資源更新，包括 Auto Scaling 組態的更新。
**常見的反模式：**
+ 您使用命令列或在 AWS 管理主控台 (也稱為 *click-ops*) 手動部署資源。
+ 您緊密耦合應用程式元件或資源，因而建立了缺乏彈性的架構。
+ 您實作缺乏彈性的擴展政策，因而無法適應不斷變化的業務需求、流量模式或新的資源類型。
+ 您手動預估容量來應付預測的需求。
**建立此最佳實務的優勢**：基礎設施即程式碼 (IaC) 可讓您以程式設計方式定義基礎設施。這可協助您透過與應用程式變更相同的軟體開發生命週期來管理基礎設施變更，進而提高一致性和可重複性，並降低手動易出錯任務的風險。您可以使用自動化交付管道實作 IaC，以進一步簡化佈建和更新資源的程序。您採取可靠且有效率的方式部署基礎設施更新，而無需手動介入。在擴展資源以應付不斷變化的需求時，這種敏捷性尤其重要。
您可以結合 IaC 和交付管道來實現動態的自動化資源擴展。透過監控關鍵指標並套用預先定義的擴展政策，Auto Scaling 就可視需要自動佈建或取消佈建資源，進而改善效能和成本效益。這可降低手動錯誤或延遲的可能性，以回應應用程式或工作負載需求的改變。
IaC、自動化交付管道與 Auto Scaling 相互結合之下，可協助組織安心佈建、更新和擴展其環境。這種自動化對於維護反應靈敏、具彈性且高效管理的雲端基礎設施至關重要。
**未建立此最佳實務時的風險暴露等級**：高
## 實作指引
若要為您的 AWS 架構設定具有 CI/CD 管道和基礎設施即程式碼 (IaC) 的自動化，請選擇 Git 這類版本控制系統來儲存您的 IaC 範本和組態。這些範本可以使用 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 等工具撰寫。請從在這些範本內定義您的基礎設施元件開始 (例如 AWS VPC、Amazon EC2 Auto Scaling 群組和 Amazon RDS 資料庫)。
接著將這些 IaC 範本與 CI/CD 管道整合，以自動化部署程序。[AWS CodePipeline](https://aws.amazon.com/codepipeline/) 提供了順暢的 AWS 原生解決方案，您也可以使用其他第三方 CI/CD 解決方案。建立管道，當您的版本控制儲存庫發生變更時，就會啟用該管道。設定管道以包含檢查和驗證 IaC 範本的階段、將基礎設施部署到預備環境、執行自動化測試，最後再部署到正式作業環境。必要時納入核准步驟，以維持對變更的控制。此自動化管道不僅能加快部署速度，還能促進環境之間的一致性和可靠性。
在 IaC 中設定 Amazon EC2 執行個體、Amazon ECS 任務和資料庫複本等資源的 Auto Scaling，以視需要提供自動橫向擴充和縮減。此方法可增強應用程式可用性和效能，並根據需求動態調整資源來最佳化成本。如需支援的資源清單，請參閱 [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 和 [AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html)。
### 實作步驟
1. 建立並使用原始程式碼儲存庫來存放控制基礎設施組態的程式碼。對此儲存庫執行變更，以反映您要進行的任何持續變更。
1. 選取基礎設施即程式碼解決方案 (例如 AWS CloudFormation) 讓您的基礎設施保持最新狀態，並偵測與您預期狀態不一致 (偏離) 的情況。
1. 將 IaC 平台與您的 CI/CD 管道整合，以自動化部署。
1. 確定並收集適當的指標，以自動擴展資源。
1. 使用適合您工作負載元件的橫向擴充和縮減政策來設定自動擴展資源。考慮針對可預測的用量模式使用排程擴展。
1. 監控部署以偵測失敗和迴歸。在 CI/CD 平台內實作回復機制，以在必要時還原變更。
## 資源
**相關文件：**
+ [AWS Auto Scaling：擴展計畫的運作方式](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace：可與 Auto Scaling 結合使用的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [使用 DynamoDB Auto Scaling 功能自動管理輸送容量](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [將負載平衡器與 Auto Scaling 群組配合使用](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ [什麼是 AWS Global Accelerator？](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [什麼是 Amazon EC2 Auto Scaling？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [什麼是 AWS Auto Scaling？](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ [什麼是 Amazon CloudFront？](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected)
+ [什麼是 Amazon Route 53？](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [什麼是 Elastic Load Balancing？](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [什麼是 Network Load Balancer？](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [什麼是 Application Load Balancer？](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [將 Jenkins 與 AWS CodeBuild 和 AWS CodeDeploy 整合](https://aws.amazon.com/blogs/devops/setting-up-a-ci-cd-pipeline-by-integrating-jenkins-with-aws-codebuild-and-aws-codedeploy/)
+ [使用 AWS CodePipeline 建立一個四階段的管道](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-four-stage-pipeline.html)
**相關影片：**
+ [回歸基礎：將程式碼部署至 Amazon EC2](https://www.youtube.com/watch?v=f2wvEQ_sWS8)
+ [AWS 支援您 \$1 使用 AWS CloudFormation 範本開始使用您的基礎設施即程式碼解決方案](https://www.youtube.com/watch?v=bgfx76jr7tA)
+ [使用 AWS CodePipeline 簡化您的軟體版本程序](https://www.youtube.com/watch?v=zMa5gTLrzmQ)
+ [使用 Amazon CloudWatch 儀表板監控 AWS 資源](https://www.youtube.com/watch?v=I7EFLChc07M)
+ [建立跨帳戶和跨區域 CloudWatch 儀表板 \$1 Amazon Web Services](https://www.youtube.com/watch?v=eIUZdaqColg)
# REL07-BP02 在偵測到工作負載受損時取得資源
在可用性受到影響時視需要主動擴展資源，以還原工作負載可用性。
您必須先設定運作狀態檢查和這些檢查的條件，以指出可用性因資源不足而受到影響的時間。然後，通知適當的人員手動擴展資源，或啟動自動化以自動調整資源規模。
您可以針對工作負載手動調整規模 (例如，變更 Auto Scaling 群組中的 EC2 執行個體數量，或透過 AWS 管理主控台 或 AWS CLI 修改 DynamoDB 資料表的輸送量)。但是，應盡可能使用自動化 (請參閱**取得或擴展資源時使用自動化**)。
**預期成果：**啟動擴展活動 (自動或手動)，以在偵測到故障或客戶體驗降級時恢復可用性。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
在工作負載中的所有元件實作可觀測性和監控，以監控客戶體驗並偵測故障。定義可調整所需資源的手動或自動化程序。o 如需詳細資訊，請參閱 [REL11-BP01 監控工作負載的所有元件以偵測故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html)。
### 實作步驟
+ 定義會擴展所需資源的手動或自動程序。
+ 擴展程序取決於工作負載內不同元件的設計方式。
+ 擴展程序也會根據所使用的基礎技術而有所不同。
+ 使用 AWS Auto Scaling 的元件可以使用擴展計劃來設定用於擴展資源的一組指示。如果使用 AWS CloudFormation 或新增標籤到 AWS 資源，您可以針對每個應用程式的不同資源組來設定擴展計畫。Auto Scaling 為針對每個資源自訂的擴展策略提供建議。建立擴展計畫之後，Auto Scaling 會將動態擴展和預測擴展方法結合在一起，以支援您的擴展策略。有關詳細資訊，請參閱 [How scaling plans work](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)。
+ Amazon EC2 Auto Scaling 會確認您有數量正確的 Amazon EC2 執行個體來處理應用程式的負載。您可以建立 EC2 執行個體的集合，此集合稱為「Auto Scaling 群組」。您可以在每個 Auto Scaling 群組中指定執行個體的最小和最大數量，而 Amazon EC2 Auto Scaling 可確保您的群組大小永遠不會低於或高於這些限制。如需詳細資訊，請參閱 [What is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ Amazon DynamoDB Auto Scaling 功能使用 Application Auto Scaling 服務代您動態調整佈建的輸送容量，以此回應實際流量模式。這可讓資料表或全域次要索引增加其佈建的讀取與寫入容量，以處理突然增加的流量，而不需限流。如需詳細資訊，請參閱 [Managing throughput capacity automatically with DynamoDB auto scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)。
## 資源
**相關的最佳實務：**
+ [ REL07-BP01 取得或擴展資源時使用自動化](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 監控工作負載的所有元件以偵測故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html)
**相關文件：**
+ [AWS Auto Scaling：擴展計劃的運作方式](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [使用 DynamoDB Auto Scaling 功能自動管理輸送容量](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [什麼是 Amazon EC2 Auto Scaling？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP03 偵測到工作負載需要更多資源時取得資源
雲端運算最有價值的功能之一，就是動態佈建資源的能力。
在傳統的內部部署運算環境中，您必須預先確定和佈建足夠的容量，以滿足尖峰需求。這點卻是問題所在，因為它很昂貴，而且如果您低估工作負載的尖峰容量需求，它可能會對可用性造成風險。
在雲端中，您就不需要這樣做。而是能夠視需要佈建運算、資料庫和其他資源容量，以滿足目前和預測的需求。Amazon EC2 Auto Scaling 和 Application Auto Scaling 等自動化解決方案可以根據您指定的指標，自動線上提供資源。這使得擴展程序更容易且可預測，同時可確保您隨時有足夠的資源可用，進而大幅提高工作負載的可靠性。
**預期成果：**您設定自動擴展運算和其他資源以滿足需求。您在擴展政策中提供足夠的預留空間，以便在其他資源上線時處理激增的流量。
**常見的反模式：**
+ 您佈建固定數量的可擴展資源。
+ 您選擇的擴展指標與實際需求無關。
+ 您無法在擴展計畫中提供足夠的預留空間來應付需求激增的情況。
+ 您的擴展政策太晚增加容量，以致於在其他資源上線時造成容量耗盡和服務降級的情況。
+ 您未能正確設定資源計數的下限和上限，因而導致擴展失敗。
**建立此最佳實務的優勢：**擁有足夠的資源可滿足目前的需求，這點對於提供工作負載的高可用性並遵守您定義的服務層級目標 (SLO) 來說至關重要。自動擴展可讓您提供工作負載所需的確切運算、資料庫和其他資源數量，以便處理目前和預測的需求。您不需要判斷尖峰容量需求，並靜態配置資源來處理這些需求。您可以改為隨著需求增加配置更多資源來應付這些需求，並且在需求減少之後停用資源以降低成本。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
首先，確定工作負載元件是否適合自動擴展。這些元件稱為*可水平擴展*，因為它們提供相同的資源且行為相同。可水平擴展元件的範例包括相似設定的 EC2 執行個體、[Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) 任務，以及在 [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) 上執行的 Pod。這些運算資源通常位於負載平衡器後方，稱為*複本*。
其他複寫資源可能包括資料庫讀取複本、[Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 資料表和 [Amazon ElastiCache](https://aws.amazon.com/elasticache/) (Redis OSS) 叢集。如需可支援資源的完整清單，請參閱[可與 Application Auto Scaling 搭配使用的 AWS 服務](https://docs.aws.amazon.com/autoscaling/application/userguide/integrated-services-list.html)。
對於容器型架構，您可能需要採用兩種不同的方式進行擴展。第一種方式是，您可能需要擴展提供可水平擴展服務的容器。第二種方式是，您可能需要擴展運算資源以騰出空間給新容器。每一層都有不同的自動擴展機制。若要擴展 ECS 任務，您可以使用 [Application Auto Scaling](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)。若要擴展 Kubernetes Pod，您可以使用 [Horizontal Pod Autoscaler (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) 或 [Kubernetes Event-driven Autoscaling (KEDA)](https://keda.sh/)。若要擴展運算資源，您可以針對 ECS 使用[容量提供者](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html)，對於 Kubernetes，您可以使用 [Karpenter](https://karpenter.sh) 或 [Cluster Autoscaler](https://kubernetes.io/docs/concepts/cluster-administration/cluster-autoscaling/)。
接著選取您要執行自動擴展的方式。有三個主要選項：指標型擴展、排程擴展和預測性擴展。
**指標型擴展**
指標型擴展會根據一或多個*擴展指標*的值佈建資源。擴展指標是指對應工作負載需求的指標。確定擴展指標是否適當的好方法，就是在非正式作業環境中執行負載測試。在負載測試期間，將可擴展資源的數量固定，並慢慢增加需求 (例如輸送量、並行或模擬的使用者)。然後尋找隨著需求增加 (或減少) 而增加的指標，以及隨著需求下降而減少 (或增加) 的指標。典型的擴展指標包括 CPU 使用率、工作佇列深度 (例如 [Amazon SQS](https://aws.amazon.com/sqs/) 佇列)、作用中使用者數量，以及網路輸送量。
**注意**
AWS 已觀測到，在大多數應用程式中，記憶體使用率會隨著應用程式暖機而增加，然後達到穩定值。當需求減少時，記憶體使用率通常會保持在升高處，而不會跟著減少。由於記憶體使用率不會隨著需求增加和減少而對應升降，因此在選取此指標用於自動擴展時，務必審慎考慮。
指標型擴展是*延遲操作*。利用率指標可能需要幾分鐘的時間才能傳播至自動擴展機制，而且這些機制通常會等待需求增加的明確訊號，然後才做出反應。於是，當自動擴展器建立新資源時，可能需要額外的時間才能提供完整服務。因此，請務必不要將擴展指標目標設定得太接近完全使用率 (例如 90% CPU 使用率)。這樣做可能產生在額外容量上線之前就耗盡現有資源容量的風險。典型的資源使用率目標範圍介於 50-70% 之間，此範圍可實現最佳可用性，具體取決於佈建其他資源的需求模式和所需的時間。
**排程擴展**
排程擴展會根據行事曆或一天當中的時間佈建或移除資源。它經常用於具有可預測需求的工作負載，例如工作日營業時間或銷售活動的尖峰使用率。[Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) 和 [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) 都支援排程擴展。KEDA 的 [cron 擴展器](https://keda.sh/docs/latest/scalers/cron/)支援 Kubernetes Pod 的排程擴展。
**預測性擴展**
預測性擴展使用機器學習，根據預期的需求自動擴展資源。預測性擴展會分析您提供的使用率指標的歷史值，並持續預測其未來值。然後使用預測的值來向上擴展資源或縮減其規模。[Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html) 可執行預測性擴展
### 實作步驟
1. 確定工作負載元件是否適合自動擴展。
1. 確定哪一種擴展機制最適合工作負載：指標型擴展、排程擴展或預測性擴展。
1. 為元件選取適當的自動擴展機制。對於 Amazon EC2 執行個體，使用 Amazon EC2 Auto Scaling。對於其他 AWS 服務，使用 Application Auto Scaling。對於 Kubernetes Pod (例如在 Amazon EKS 叢集中執行的 Pod)，請考慮 Horizontal Pod Autoscaler (HPA) 或 Kubernetes Event-driven Autoscaling (KEDA)。對於 Kubernetes 或 EKS 節點，請考慮 Karpenter 和 Cluster Auto Scaler (CAS)。
1. 對於指標或排程擴展，請執行負載測試，以確定適合工作負載的擴展指標和目標值。對於排程擴展，確定您選取的日期和時間所需的資源數量。確定滿足預期的尖峰流量所需的資源數量上限。
1. 根據上面收集的資訊設定自動擴展器。如需詳細資訊，請參閱自動擴展服務的文件。確認已正確設定擴展的上限和下限。
1. 確認擴展組態依預期運作。在非正式作業環境中執行負載測試，以及觀察系統如何反應，並視需要調整。在正式作業環境中啟用自動擴展時，請設定適當的警報來通知您任何非預期的行為。
## 資源
**相關文件：**
+ [什麼是 Amazon EC2 Auto Scaling？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS 規範性指引：負載測試應用程式](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/)
+ [AWS Marketplace：可與 Auto Scaling 結合使用的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [使用 DynamoDB Auto Scaling 功能自動管理輸送容量](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [EC2 的預測擴展，採用機器學習技術](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Amazon EC2 Auto Scaling 排程擴展](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [說說「利特爾法則」的故事](https://brooker.co.za/blog/2018/06/20/littles-law.html)
# REL07-BP04 Load 測試您的工作負載
採用負載測試方法來衡量擴展活動是否滿足工作負載要求。
重要的是執行持續的負載測試。負載測試應探索突破點，並測試工作負載的效能。 AWS 可讓您輕鬆設定臨時測試環境，以建立生產工作負載規模的模型。在雲端，您可隨需建立生產規模的測試環境、完成測試，然後再停用資源。因為您只為執行中的測試環境付費，所以能以與內部部署測試相較之下相當微小比例的成本來模擬即時環境。
在生產系統承受壓力的演練日，以及客戶使用量較低的時間內，您也應考慮在生產中進行負載測試，並且讓可用的所有人員解釋結果並解決所發生的任何問題。
**常見的反模式：**
+ 在與生產組態不同的部署上執行負載測試。
+ 僅對工作負載的個別部分執行負載測試，而非整個工作負載。
+ 使用一部分請求而非代表性的一組實際請求來執行負載測試。
+ 對高於預期負載的小型安全係數執行負載測試。
**建立此最佳實務的優勢：**您會知道架構中的哪些元件在負載時失敗，並能夠識別要監看哪些指標，指出您正在及時處理該負載來解決問題，避免受到該故障的影響。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
+ 執行負載測試，以識別工作負載的哪些層面指出您必須新增或移除容量。負載測試的代表性流量應與您在生產環境中收到的流量相似。在觀看您已檢測的指標時增加負載，以判斷哪些指標指出何時須新增或移除資源。
+ [上的分散式負載測試 AWS：模擬數千個連線使用者](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ 識別請求混合。您可能會有不同的請求混合，因此您應該在識別流量混合時查看各種時間範圍。
+ 實作載入驅動程式。您可以使用自訂程式碼、開放原始碼或商業軟體實作載入驅動程式。
+ 最初使用小容量的負載測試。您將負載驅動到較小容量 (可能和單一執行個體或容器一樣小)，看到一些立即的影響。
+ 針對較大容量的負載測試。在分散式負載上的效果會有所不同，因此您必須盡可能在接近產品環境的條件下進行測試。
## 資源
**相關文件：**
+ [上的分散式負載測試 AWS：模擬數千個連線使用者](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [負載測試應用程式](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html)
**相關影片：**
+ [AWS Summit ANZ 2023：透過 AWS 分散式負載測試，放心加速](https://www.youtube.com/watch?v=4J6lVqa6Yh8)