

# COST 9  如何管理需求和供應資源？
<a name="w2aac19c13c11b5"></a>

針對支出和效能達到平衡的工作負載，請確保使用購買的每個項目，並避免極少使用執行個體。往任一端傾斜的使用指標，對您組織在營運成本 (因過度使用而降低效能) 或浪費的 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 對工作負載需求進行分析
<a name="cost_manage_demand_resources_cost_analysis"></a>

 分析工作負載隨時間的需求。確認分析涵蓋季節性趨勢，並準確反映整個工作負載生命週期內的運作狀況。分析工作應反映潛在效益：例如，花費的時間與工作負載成本成正比。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>

了解工作負載的需求。組織要求應指出請求的工作負載回應時間。回應時間可用來判斷需求是否已得到滿足，或是資源供應是否需要改變以符合需求。

分析應包含需求的可預測性和重複性、需求的變化速率，以及需求的變化量。確保分析針對足夠長的時間執行，以納入任何季節變化，例如月底處理或節假日尖峰。

確保分析工作與實作擴展的潛在效益相符。查看元件的預期總成本，以及工作負載生命週期內用量和成本的任何增加或減少。

您可以使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 或者 [Amazon Quick](https://aws.amazon.com/quicksight/) 搭配 AWS Cost and Usage Report (CUR) 或應用程式日誌，以視覺化的方式分析工作負載需求。

**實作步驟**
+ ** 分析現有的工作負載資料： **分析現有工作負載、舊版工作負載或預測使用模式中的資料。利用日誌檔和監控資料來深入了解客戶使用工作負載的方式。典型指標包括實際需求 (每秒請求數)、需求率變更或處於不同等級的次數，以及需求變更率。請務必分析工作負載的完整週期，藉此確保收集到所有季節性變更的資料，例如月末或年末事件。分析中所反映的工作應反映工作負載特性。應將工作重點放在需求變更最大的高價值工作負載上。針對需求變更最少的低價值工作負載，應將投入的工作量降到最低。常見價值指標包括風險、品牌知名度、收入或工作負載成本。
+ ** 預測外部影響： **與整個組織中的團隊成員面談，這些成員可能會影響或變更工作負載的需求。常見的團隊是銷售團隊、行銷團隊或業務開發團隊。與這些團隊合作以了解其作業週期，以及是否有任何事件會改變工作負載需求。利用此資料來預測工作負載需求。

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [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/)
+ [Amazon Quick](https://aws.amazon.com/quicksight/)

# COST09-BP02 實作緩衝或調節機制來管理需求
<a name="cost_manage_demand_resources_buffer_throttle"></a>

 緩衝和調節機制會修改工作負載的需求，以消除任何尖峰時段。在用戶端執行重試時實作調節機制。實作緩衝機制以儲存請求，並將處理的時間往後延遲。確認調節和緩衝區經過設計，以便讓用戶端在所需時間內收到回應。 

 **若未建立此最佳實務，暴露的風險等級：** 低 

## 實作指引
<a name="implementation-guidance"></a>

**調節：** 如果需求來源具有重試功能，則您可以實作調節。調節會告知來源，如果目前無法服務請求，則應稍後再試。來源將等待一段時間，然後重新嘗試請求。實作調節的優點是限制最大資源量和工作負載成本。在 AWS 中，您可以使用 [Amazon API Gateway](https://aws.amazon.com/api-gateway/) 實作調節。如需實作調節的詳細資訊，請參閱 [Well-Architected 可靠性支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html) 。

**緩衝為主： **與調節類似，緩衝會延遲請求處理，讓以不同速率執行的應用程式能夠有效地通訊。緩衝為主方法使用佇列來接受生產者傳出的訊息 (工作單位)。消費者可讀取訊息並進行處理，允許以符合消費者業務要求的速度運作訊息。不必擔心生產者必須應付調節問題，例如資料耐用性和回壓 (由於消費者運作緩慢而導致生產者慢下來)。

在 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 可為您的工作負載元件提供調節機制。

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [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/) 

# COST09-BP03 動態提供資源
<a name="cost_manage_demand_resources_dynamic"></a>

 資源是按計畫進行佈建。這可以是以需求為基礎 (例如，透過自動調整規模)，或是以時間為基礎，其中需求可預測，並且根據時間提供資源。這些方法可儘量減少過度佈建或佈建不足的數量。 

 **若未建立此最佳實務，暴露的風險等級：** 低 

## 實作指引
<a name="implementation-guidance"></a>

您可以使用 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)，或使用 [AWS API 或 SDK](https://aws.amazon.com/developer/tools/)。透過消除手動變更環境所需的營運成本，這可讓您降低整體工作負載成本，而且執行速度更快。這可確保工作負載資源隨時都能最符合需求。

**需求為主的供應：** 利用雲端的彈性來供應資源，以滿足不斷變化的需求。藉由取得 API 或服務功能帶來的優勢，以程式設計方式動態性地更動架構中的雲端資源量。如此可允許您增減架構中元件的規模，需求激增時自動增加資源數量以維持效能，待需求消退時減少容量以降低成本。

[AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 可協助您調整容量，以盡可能最低的成本維持穩定、可預測的效能。它是免費的全受管服務，與 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體和 Spot 叢集、Amazon Elastic Container Service (Amazon ECS)、Amazon DynamoDB 和 Amazon Aurora 整合。

Auto Scaling 提供自動資源探索，以協助尋找工作負載中可設定的資源，它具有內建的擴展策略以優化效能、成本或兩者之間的平衡，並提供預測擴展以協助處理定期發生的尖峰。

Auto Scaling 可以實作手動、排程或以需求為基礎的擴展。您也可以使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 的指標和警示，來觸發工作負載的擴展事件。典型的指標可以是標準 Amazon EC2 指標，例如 CPU 使用率、網路輸送量和 [Elastic Load Balancing (ELB) ](https://aws.amazon.com/elasticloadbalancing/)觀察到的請求/回應延遲。可能時，您應該使用可指示客戶體驗的指標，通常此指標為自訂指標，可能源自您工作負載內的應用程式程式碼。

以需求為主的方法進行建構時，請牢記兩大考量要點。第一，了解必須多迅速地佈建起新的資源。第二，了解供應與需求之間差距的大小會改變。您必須隨時因應需求的改變速度，並為資源失敗做好準備。

[ELB](https://aws.amazon.com/elasticloadbalancing/) 可跨多個資源分配需求以協助您進行擴展。當您實作更多資源時，您可將其新增至負載平衡器以接受需求。Elastic Load Balancing 具有 Amazon EC2 執行個體、容器、IP 地址和 AWS Lambda 函數的支援。

**時間為主的供應：** 時間為主方法能使資源容量符合可預測或依照時間定義完善的需求。這種方法通常不依存於資源的利用率。時間為主方法能確保需要資源的特定時間有資源可用，並且因為啟動程序和系統或一致性檢查的緣故，能在毫無延遲之下提供。採用時間為主方法，您可在忙碌期提供更多資源或增加容量。

您可以使用排程的 Auto Scaling 實作時間為主方法。可排定工作負載於定義的時間縮放規模 (例如在營業時段開始時) 如此可確保使用者或者需求到來時有資源可用。

您也可善用 [AWS API 和 SDK](https://aws.amazon.com/developer/tools/) 和 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 以視需要自動佈建整個環境以及除役。這種方法十分適合僅在定義的營業時段或時期執行的開發或測試環境。

您可使用 API 縮放環境之內的資源大小 (垂直縮放)。例如，可變更執行個體的大小或類別，以擴展生產工作負載。作法是將執行個體停止再啟動，選擇不同的執行個體大小或類別。此技法亦可套用至其他資源，例如 Amazon Elastic Block Store (Amazon EBS) Elastic Volumes，在使用中時經過修改可增加大小、調整效能 (IOPS) 或變更磁碟區類型。

以時間為主的方法進行建構時，請牢記兩大考量要點。首先，用量模式的一致性有多高？ 第二，若是模式改變會有何影響？ 您可藉由監控工作負載和使用商業智慧來提高預測的準確性。若看出用量模式有明顯變化，可調整時間以確保涵蓋。

**實作步驟**
+ ** 設定以時間為基礎的排程： **針對可預測的需求變更，以時間為基礎的擴展機制可以及時提供正確的資源數目。此外，當資源建立和設定的速度不夠快，不足以回應隨需變更時，此機制也能派上用場。透過 AWS Auto Scaling，使用工作負載分析來設定排定的擴展。
+ ** 設定 Auto Scaling： **若要根據作用中的工作負載指標來設定擴展，請使用 Amazon Auto Scaling。使用分析和設定 Auto Scaling 以便在正確的資源層級上觸發，並確保工作負載在所需時間內擴展。

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/) 
+  [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) 