# COST 9. 如何管理需求和供應資源？
針對支出和效能達到平衡的工作負載，確認您購買的每一個項目都用到，並避免極少使用執行個體。往任一端傾斜的使用指標，對您組織在營運成本 (因過度使用而降低效能) 或浪費的 AWS 花費 (因過度佈建) 方面會造成負面影響。
**Topics**
+ [COST09-BP01 對工作負載需求進行分析](cost_manage_demand_resources_cost_analysis.md)
+ [COST09-BP02 實作緩衝或調節機制來管理需求](cost_manage_demand_resources_buffer_throttle.md)
+ [COST09-BP03 動態提供資源](cost_manage_demand_resources_dynamic.md)
# COST09-BP01 對工作負載需求進行分析
分析工作負載隨時間的需求。確認分析涵蓋季節性趨勢，並準確反映整個工作負載生命週期內的運作狀況。分析工作應反映潛在效益：例如，花費的時間與工作負載成本成正比。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
要分析工作負載對雲端運算的需求，就必須了解雲端環境中啟動的運算工作模式和特性。這類分析可協助使用者優化資源配置、管理成本，並確保效能符合所需等級。
了解工作負載的需求。組織要求應指出請求的工作負載回應時間。回應時間可用來判斷需求是否已得到滿足，或是資源供應是否需要改變以符合需求。
分析應包含需求的可預測性和重複性、需求的變化速率，以及需求的變化量。針對足夠長的時間執行分析，以納入任何季節變化，例如月底處理或節假日尖峰。
分析工作應反映實作擴展的潛在效益。查看元件的預期總成本，以及工作負載生命週期內用量和成本的任何增加或減少。
以下是執行雲端運算的工作負載需求分析時需要考慮的一些關鍵事項：
1. **資源使用率和效能指標**：分析 AWS 資源在一段時間內的使用方式。確認尖峰和離峰使用模式，以最佳化資源配置和擴展策略。監控效能指標，例如回應時間、延遲、輸送量和錯誤率。這些指標有助於評估雲端基礎架構的整體運作狀態和效率。
1. **使用者和應用程式擴展行為**：了解使用者行為及其對工作負載需求的影響。檢查使用者流量的模式，有助於提高交付內容的完整性和應用程式的回應能力。分析工作負載如何隨著需求增加而擴展。判斷是否已正確、有效地設定自動擴展參數，以處理負載波動。
1. **工作負載類型**：識別在雲端中執行的不同工作負載類型，例如批次處理、即時資料處理、Web 應用程式、資料庫或機器學習。每種工作負載類型可能有不同的資源需求和效能資料。
1. **服務水準協議 (SLA)**：將實際效能與 SLA 進行比較，以確保合規性並找出需要改進的部分。
您可以使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 收集和追蹤指標、監控日誌檔、設定警示，以及自動對 AWS 資源的變更做出反應。您也可以使用 Amazon CloudWatch 全面了解系統的資源使用率、應用程式效能和運作狀態。
使用 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)，您可以根據最佳實務佈建資源，以改善系統效能和可靠性、提高安全性，並尋找節省成本的機會。您也可以關閉非生產執行個體，並使用 Amazon CloudWatch 和 Auto Scaling 來因應需求增加或減少。
最後，搭配 AWS Cost and Usage Report (CUR) 檔案或應用程式日誌使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 或 [Quick](https://aws.amazon.com/quicksight/)，以執行工作負載需求的進階分析。
整體而言，全面的工作負載需求分析可讓組織在資源佈建、擴展和最佳化方面做出明智決策，進而提高效能、成本效益和使用者滿意度。
### 實作步驟
+ **分析現有工作負載資料：**分析現有工作負載、舊版工作負載或預測使用模式中的資料。使用 Amazon CloudWatch、日誌檔和監控資料來深入了解工作負載的使用情況。分析工作負載的完整週期，並收集所有季節性變更的資料，例如月末或年末事件。分析中所反映的工作應反映工作負載特性。應將工作重點放在需求變更最大的高價值工作負載上。針對需求變更最少的低價值工作負載，應將投入的工作量降到最低。
+ **預測外部影響：**與整個組織中的團隊成員面談，這些成員可能會影響或變更工作負載的需求。常見的團隊是銷售團隊、行銷團隊或業務開發團隊。與這些團隊合作以了解其作業週期，以及是否有任何事件會改變工作負載需求。利用此資料來預測工作負載需求。
## 資源
**相關文件：**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/)
+ [Amazon SQS 入門](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ [快速](https://aws.amazon.com/quicksight/)：
**相關範例：**
+ [監控、追蹤和分析以實現成本最佳化](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/monitor-track-and-analyze/)
+ [搜尋和分析 CloudWatch 中的日誌](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/cloudwatch-search-analysis.html)
# COST09-BP02 實作緩衝或調節機制來管理需求
緩衝和限流機制會修改工作負載的需求，以消除任何尖峰時段。在用戶端執行重試時實作限流機制。實作緩衝機制以儲存請求，並將處理的時間往後延遲。確認調節和緩衝機制經過設計，以便讓用戶端在所需時間內收到回應。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
在雲端運算中實作緩衝或調節機制至關重要，如此才能管理需求並降低工作負載所需的佈建容量。為了獲得最佳效能，請務必評估總需求，包括峰值、請求變更速度以及必要的回應時間。當用戶端能夠重新發送他們的請求時，套用限流就變得很實用。相反地，對於缺少重試功能的用戶端，最理想的方法是實作緩衝解決方案。這類緩衝機制簡化了請求的湧入作業，並且會將有不同操作速度之應用程式的互動最佳化。
![\[需求曲線圖，內含兩個需要大量佈建容量的相異尖峰\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/provisioned-capacity-1.png)
假設某個工作負載的需求曲線如上圖所示。此工作負載有兩個尖峰，為了處理這些尖峰，已佈建了資源容量 (以橙色線顯示)。用於此工作負載的資源和能源並非由需求曲線底下的區域表示，而是已佈建的容量底下的區域，因為這兩個尖峰必須用已佈建的容量處理。使工作負載需求曲線扁平化，有助於減少工作負載所需的已佈建容量，以及降低對環境造成的影響。若要消除尖峰時段，請考慮實作限流或緩衝解決方案。
為了深入了解，讓我們探索一下限流和緩衝機制。
**限流：**如果需求來源具有重試功能，則您可以實作限流。限流會告知來源，如果目前無法服務請求，則應稍後再試。來源會等待一段時間，然後重試請求。實作限流的優點是限制最大資源量和工作負載成本。在 AWS 中，您可以使用 [Amazon API Gateway](https://aws.amazon.com/api-gateway/) 實作限流。
**基於緩衝區：**基於緩衝區的方法會使用*生產者* (將訊息傳送至佇列的元件)、*取用者* (從佇列接收訊息的元件) 和*佇列* (保留訊息) 來儲存訊息。消費者可讀取訊息並進行處理，允許以符合取用者業務要求的速度運作訊息。透過使用緩衝為主的方法，生產者的訊息會儲存在佇列或串流中，隨時可供取用者以符合其操作需求的速度來存取。
在 AWS 中，有多個服務可供選擇以實作緩衝方法。[Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) 是一個受管服務，可提供佇列，允許單一取用者讀取個別訊息。[Amazon Kinesis](https://aws.amazon.com/kinesis/) 可提供串流，允許許多取用者讀取相同訊息。
緩衝和限流可透過修改工作負載的需求來消除任何尖峰時段。當用戶端會重試動作時請使用限流，並使用緩衝機制來保存請求以供稍後處理。使用緩衝為主的方法時，請將工作負載建構為可在所需的時間內為請求提供服務，並確認您能夠處理重複的工作請求。分析整體需求、變更率及所需的回應時間，以適當調整所需的調節或緩衝區大小。
### 實作步驟
+ **分析用戶端要求：**分析用戶端請求以判斷是否能夠執行重試。針對無法執行重試的用戶端，則需要實作緩衝機制。分析整體需求、變更率及所需的回應時間，以便判斷所需的調節或緩衝區大小。
+ **實作緩衝區或限流：**在工作負載中實作緩衝區或限流。Amazon Simple Queue Service (Amazon SQS) 這類佇列可為工作負載元件提供緩衝區。Amazon API Gateway 可以為您的工作負載元件提供限流。
## 資源
**相關的最佳實務：**
+ [SUS02-BP06 實作緩衝或限流使需求曲線趨於扁平化](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_user_a7.html)
+ [REL05-BP02 限流請求](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)
**相關文件：**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/)
+ [Amazon API Gateway](https://aws.amazon.com/api-gateway/)
+ [Amazon Simple Queue Service](https://aws.amazon.com/sqs/) ()
+ [Amazon SQS 入門](https://aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [Amazon Kinesis](https://aws.amazon.com/kinesis/)
**相關影片：**
+ [為分散式應用程式選擇正確的訊息傳遞服務](https://www.youtube.com/watch?v=4-JmX6MIDDI)
**相關範例：**
+ [管理和監控工作負載中的 API 限流](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [使用 API Gateway 大規模限流分層、多租用戶 REST API](https://aws.amazon.com/blogs/architecture/throttling-a-tiered-multi-tenant-rest-api-at-scale-using-api-gateway-part-1/)
+ [使用 Amazon API Gateway 在租用戶 Amazon EKS SaaS 解決方案中啟用分層和限流](https://aws.amazon.com/blogs/apn/enabling-tiering-and-throttling-in-a-multi-tenant-amazon-eks-saas-solution-using-amazon-api-gateway/)
+ [使用佇列與訊息進行應用程式整合](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)
# COST09-BP03 動態提供資源
資源會按計劃進行佈建。這可以是以需求為基礎 (例如，透過自動調整規模)，或是以時間為基礎，其中需求可預測，並且根據時間提供資源。這些方法可盡量減少過度佈建或佈建不足的數量。
**未建立此最佳實務時的曝險等級：**低
## 實作指引
AWS 客戶有數種方法可以增加應用程式的可用資源並提供資源，以滿足需求。其中一個選項是使用 AWS Instance Scheduler，它可自動啟動和停止 Amazon Elastic Compute Cloud (Amazon EC2) 和 Amazon Relational Database Service (Amazon RDS) 執行個體。另一個選項是使用 AWS Auto Scaling，這可讓您根據應用程式或服務的需求自動擴展運算資源。根據需求提供資源可讓您僅為自己使用的資源付費，以及在需要時啟動資源，並在不需要資源時將其終止，藉以降低成本。
[AWS Instance Scheduler](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/) 可讓您將 Amazon EC2 和 Amazon RDS 執行個體設定為在已定義的時間停止及啟動，以便在一致的時間模式下達到相同資源的需求，例如，使用者在每天早上八點存取 Amazon EC2 執行個體，而晚上六點後則不需存取。此解決方案可停止非使用中的資源，並在需要時才加以啟動，藉以降低營運成本。
![\[此圖顯示使用 AWS Instance Scheduler 的成本優化。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/instance-scheduler-diagram.png)
您也可以使用 AWS Systems Manager 快速設定，透過簡單的使用者介面 (UI) 輕鬆設定跨帳戶和區域的 Amazon EC2 執行個體排程。您可以使用 AWS Instance Scheduler 來排程 Amazon EC2 或 Amazon RDS 執行個體，也可以停止和啟動現有的執行個體。但是，您無法停止和啟動屬於 Auto Scaling 群組 (ASG) 的執行個體，或管理 Amazon Redshift 或 Amazon OpenSearch Service 等服務的執行個體。Auto Scaling 群組對群組中的執行個體有自己的排程，並且會建立這些執行個體。
[AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 可協助您調整容量，盡可能以最低的成本維持穩定、可預測的效能，以因應持續變動的需求。它是免費的全受管服務以擴展與 Amazon EC2 執行個體和 Spot 機群、Amazon ECS、Amazon DynamoDB 和 Amazon Aurora 整合的應用程式的能力。Auto Scaling 提供自動資源探索，以協助尋找工作負載中可設定的資源，它具有內建的擴展策略以優化效能、成本或兩者之間的平衡，並提供預測擴展以協助處理定期發生的尖峰。
有多個擴展選項可用來擴展您的 Auto Scaling 群組：
+ 隨時維持目前執行個體層級
+ 手動擴展
+ 依據排程擴展
+ 依據需求擴展
+ 使用預測擴展
Auto Scaling 政策有所不同，可分類為動態和排程擴展政策。動態政策是手動或動態擴展，屬於排程或預測擴展。您可以使用擴展政策來進行動態、排程和預測擴展。也可以使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 中的指標和警示，為您的工作負載觸發擴展事件。建議您使用[啟動範本](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html)，它允許您存取最新功能和改善項目。即便使用啟動組態，也並非所有 Auto Scaling 功能都可用。例如：您無法建立同時啟動 Spot 及隨需執行個體的 Auto Scaling 群組或指定多個執行個體類型的群組。您必須使用啟動範本來設定這些功能。使用啟動範本時，建議您對每個範本進行版本控制。藉由啟動範本的版本控制，您可以建立一組完整的參數子集，之後可以重複使用子集來建立相同啟動範本的其他版本。
您可以使用 AWS Auto Scaling，或使用 [AWS API 或 SDK](https://aws.amazon.com/developer/tools/) 在程式碼中加入擴展功能。透過消除手動變更環境所需的營運成本，這可讓您降低整體工作負載成本，且變更的執行速度更快。這也可讓您隨時依據需求做出相應的工作負載資源配置。為了遵循此最佳實務，並且為組織動態提供資源，您應了解 AWS 雲端 中的水平和垂直擴展，以及在 Amazon EC2 執行個體中執行的應用程式有何性質。建議讓您的雲端財務管理團隊與技術團隊相互合作，以遵循此最佳實務。
[彈性負載平衡 (Elastic Load Balancing)](https://aws.amazon.com/elasticloadbalancing/) 可跨多個資源分配需求以協助您進行擴展。藉由使用 ASG 和 Elastic Load Balancing，您可以用最佳方式路由流量以管理傳入請求，讓 Auto Scaling 群組中的所有執行個體都不會不堪負荷。請求會以循環方式散佈在目標群組的所有目標之間，而不考量容量或使用率。
典型的指標可以是標準 Amazon EC2 指標，例如 CPU 使用率、網路輸送量，以及 Elastic Load Balancing 觀察到的請求與回應延遲。若可行的話，您應該使用可指示客戶體驗的指標，這通常是自訂指標，可能源自您工作負載內的應用程式程式碼。為了在本文件中詳細說明如何動態滿足需求，我們將 Auto Scaling 分類為需求為主和時間為主的供應模式，並深入探討這兩種模式。
**需求為主的供應：**依賴幾近即時的需求狀態，充分利用雲端的彈性來供應資源，以滿足不斷變化的需求。對於需求為主的供應，請使用 API 或服務功能，以程式設計方式更動架構中的雲端資源量。這樣可讓您增減架構中元件的規模，在需求激增時增加資源數量以維持效能，待需求消退時減少容量以降低成本。
![\[此圖說明需求為主的擴展政策，例如簡單/階段式擴展和目標追蹤。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/demand-based-supply.png)
+ **簡單/階段式擴展：**根據客戶手動定義的步驟，監控指標及新增/移除執行個體。
+ **目標追蹤：**類似恆溫器的控制機制，可自動新增或移除執行個體，以在客戶定義的目標上維護指標。
以需求為主的方法進行建構時，請牢記兩大考量要點。第一，了解必須多迅速地佈建起新的資源。第二，了解供應與需求之間差距的大小會改變。您必須隨時因應需求的改變速度，並為資源失敗做好準備。
**時間為主的供應：**時間為主方法能使資源容量符合可預測或依照時間定義完善的需求。這種方法通常不依存於資源的利用率。時間為主方法能確保需要資源的特定時間有資源可用，並且因為啟動程序和系統或一致性檢查的緣故，能在毫無延遲之下提供。採用時間為主方法，您可在忙碌期提供更多資源或增加容量。
![\[此圖說明時間為主的擴展政策，例如排程和預測調整。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/time-based-supply.png)
您可以使用排程或預測自動擴展來實作時間為主的方法。可排定工作負載於定義的時間橫向擴展或縮減 (例如在營業時段開始時)，以便在使用者到來或需求增加時有資源可用。預測擴展會使用模式進行橫向擴展，而排程的擴展則使用先定義的時間進行橫向擴展。您也可以在 Auto Scaling 群組中使用[屬性型執行個體類型選取 (ABS) 策略](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html)，以透過一組屬性 (例如 vCPU、記憶體和儲存) 來表達您的執行個體要求。這也可讓您自動使用新發行的新世代執行個體類型，並使用 Amazon EC2 Spot 執行個體來存取更大範圍的容量。Amazon EC2 Fleet 和 Amazon EC2 Auto Scaling 會選取和啟動符合指定屬性的執行個體，您不必再手動挑選執行個體類型。
您也可利用 [AWS API 和 SDK](https://aws.amazon.com/developer/tools/) 以及 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 以視需要自動佈建和停用整個環境。這種方法十分適合僅在定義的營業時段或時期執行的開發或測試環境。您可使用 API 縮放環境之內的資源大小 (垂直縮放)。例如，可變更執行個體的大小或類別，以擴展生產工作負載。作法是將執行個體停止再啟動，選擇不同的執行個體大小或類別。此技法亦可套用至其他資源，例如 Amazon EBS 彈性磁碟區，在使用中時經過修改可增加大小、調整效能 (IOPS) 或變更磁碟區類型。
以時間為主的方法進行建構時，請牢記兩大考量要點。首先，用量模式的一致性有多高？ 第二，若是模式改變會有何影響？ 您可藉由監控工作負載和使用商業智慧來提高預測的準確性。若看出用量模式有明顯變化，可調整時間以確保涵蓋。
## 實作步驟
+ **設定排程擴展：**針對可預測的需求變更，以時間為主的擴展機制可以及時提供正確的資源數目。此外，當資源建立和設定的速度不夠快，不足以回應隨需變更時，此機制也能派上用場。透過 AWS Auto Scaling，使用工作負載分析來設定排程的擴展。若要設定以時間為基礎的排程，您可以根據預期或可預測的負載變更，事先使用排程擴展的預測擴展來增加 Auto Scaling 群組中的 Amazon EC2 執行個體數目。
+ **設定預測擴展：**預測擴展允許您在流量的每日和每週模式之前增加 Auto Scaling 群組中的 Amazon EC2 執行個體數量。如果您有定期流量尖峰和啟動耗時的應用程式，則應考慮使用預測擴展。預測擴展可在預估的負載之前初始化容量，協助您以優於單純動態擴展 (本質上是被動的) 的速度進行擴展。例如，如果使用者在營業時間開始時開始使用您的工作負載，且在營業時間結束後不使用，則預測擴展可在營業時間之前新增容量，以消除動態擴展為了回應變動的流量而產生的延遲。
+ **設定動態自動擴展：**若要根據作用中的工作負載指標來設定擴展，請使用 Auto Scaling。使用分析並設定 Auto Scaling 以在正確的資源層級上啟動，並確認工作負載在所需的時間內擴展。您可以在單一 Auto Scaling 群組內啟動和自動擴展隨需執行個體和 Spot 執行個體組成的機群。除了獲得使用 Spot 執行個體的折扣之外，您還可以使用預留執行個體或 Savings Plan，以獲得定期隨需執行個體定價的折扣費率。這些因素組合起來，可協助您將 Amazon EC2 執行個體的費用節省最佳化，並協助您獲得應用程式所需的規模與效能。
## 資源
**相關文件：**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/)
+ 擴展 Auto Scaling 群組的大小
+ [Amazon EC2 Auto Scaling 入門](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [Amazon SQS 入門](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [Amazon EC2 Auto Scaling 排程擴展](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [Amazon EC2 Auto Scaling 的預測擴展](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html)
**相關影片：**
+ [Auto Scaling 的目標追蹤擴展政策](https://www.youtube.com/watch?v=-RumeaoPB2M)
+ [AWS Instance Scheduler](https://www.youtube.com/watch?v=nTLEyo2NzUs)
**相關範例：**
+ [Amazon EC2 Fleet 的 Auto Scaling 屬性型執行個體類型選取](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [使用已排程的擴展，針對成本最佳化 Amazon Elastic Container Service](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/)
+ [Amazon EC2 Auto Scaling 的預測擴展](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [如何搭配使用 Instance Scheduler 與 CloudFormation 來排程 Amazon EC2 執行個體？](https://aws.amazon.com/premiumsupport/knowledge-center/stop-start-instance-scheduler/)