

# SUS 2 如何根據您的需求取得適當的雲端資源？
<a name="sus-02"></a>

使用者和應用程式使用工作負載和其他資源的方式，可協助您找到改善的機會，以達成永續性目標。擴展基礎架構以持續符合需求，並確認您僅使用支援使用者所需的最低資源。讓服務層級符合客戶需求。妥善放置資源，以限制使用者和應用程式使用資源所需的網路。移除未使用的資產。為團隊成員提供滿足其需求的裝置，同時將對永續性的影響降至最低。

**Topics**
+ [SUS02-BP01 動態擴展工作負載基礎架構](sus_sus_user_a2.md)
+ [SUS02-BP02 讓 SLA 符合永續性目標](sus_sus_user_a3.md)
+ [SUS02-BP03 停止建立和維護未使用的資產](sus_sus_user_a4.md)
+ [SUS02-BP04 根據使用者的聯網要求優化其工作負載的地理位置](sus_sus_user_a5.md)
+ [SUS02-BP05 為執行的活動優化團隊成員資源](sus_sus_user_a6.md)
+ [SUS02-BP06 實作緩衝或調節使需求曲線趨於扁平化](sus_sus_user_a7.md)

# SUS02-BP01 動態擴展工作負載基礎架構
<a name="sus_sus_user_a2"></a>

利用雲端的彈性動態擴展您的基礎架構，以達到雲端資源的供需平衡，避免工作負載出現過度佈建的容量。

**常見的反模式：**
+ 您不隨著使用者負載擴展基礎架構。
+ 您一律手動擴展基礎架構。
+ 您在擴展事件之後維持增加容量，而不是縮減規模。

 **建立此最佳實務的優勢：**設定並測試工作負載彈性有助於有效達到雲端資源的供需平衡，並避免過度佈建的容量。您可以利用雲端中的彈性，在需求尖峰期間或之後自動擴展容量，以確保您使用的資源數量正好足以滿足業務所需。

 **未建立此最佳實務時的風險暴露等級：**中 

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

 雲端提供的彈性可透過各種機制來動態擴展或減少資源，以滿足需求的變化。平衡供需關係可將工作負載受到的影響降到最低。 

 需求可為固定或可變，需要指標和自動化以確保該項管理不致成為繁重的工作。應用程式可藉由修改執行個體大小進行垂直調整 (縱向擴展或縮減規模)、藉由修改執行個體數目進行水平調整 (縮減或橫向擴展)，或進行兩者的合併調整。 

 您可以使用多種不同的方法達到資源的供需平衡。 
+  **目標追蹤法：**監控您的擴展指標，並視需要自動增加或減少容量。 
+  **預測擴展：**縮減每日和每週趨勢的預期。 
+  **排程法：**根據可預測的負載變化設定您自己的擴展排程。 
+  **服務擴展：** 挑選按設計原本就會擴展的服務 (例如無伺服器)，或提供自動擴展功能。 

 辨別使用率低或無使用率的時期，並調整資源規模以移除過剩容量、提高效率。 

## 實作步驟
<a name="implementation-steps"></a>
+ 彈性會比對您擁有的資源供應與這些資源的需求。執行個體、容器和函數提供了彈性機制，可與自動擴展功能結合使用，或是作為服務功能提供。AWS 提供了多種自動擴展機制，以確保工作負載可在使用者負載較低時迅速輕易地縮減規模。以下是自動擴展機制的幾個範例：    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-04-10/framework/sus_sus_user_a2.html)
+  擴展常與 Amazon EC2 執行個體或 AWS Lambda 函數等服務一起討論。請考慮設定非運算服務 (例如 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 讀取和寫入容量單位或 [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) 碎片) 以符合需求。 
+  確認會對要部署的工作負載類型驗證擴充或縮減規模的指標。如果您要部署影片轉碼應用程式，則預期為 100% CPU 使用率，且不應做為您的主要指標。您可以將[自訂指標](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/) (例如記憶體使用率) 用於擴展政策 (如有必要)。若要選擇正確的指標，請考量 Amazon EC2 的下列指引： 
  +  指標應為有效的使用率指標，並說明執行個體的忙碌程度。 
  +  指標值必須根據 Auto Scaling 群組中的執行個體數量按比例增加或減少。 
+  對於 Auto Scaling 群組請使用[動態擴展](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html)，而非[手動擴展](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html)。我們也建議您在動態擴展中使用[目標追蹤擴展政策](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html)。 
+  確認工作負載部署可處理橫向擴展和縮減事件。建立縮減事件的測試案例，以確認工作負載的行為符合預期，且不會對使用者體驗造成影響 (例如失去黏性工作階段)。您可以使用[活動歷史](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html)來驗證 Auto Scaling 群組的擴展活動。 
+  評估工作負載以取得可預測模式，並在預計發生預測中的變化和隨需規劃變化時主動擴展。透過預測擴展，可以避免過度佈建容量的需求。如需詳細資訊，請參閱 [Amazon EC2 Auto Scaling 的預測擴展](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)。 

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

 **相關文件：** 
+  [Amazon EC2 Auto Scaling 入門](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) 
+  [EC2 的預測擴展，採用機器學習技術](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) 
+  [使用 Amazon OpenSearch Service、Amazon Data Firehose 和 Kibana 分析使用者行為](https://aws.amazon.com/blogs/database/analyze-user-behavior-using-amazon-elasticsearch-service-amazon-kinesis-data-firehose-and-kibana/) 
+  [什麼是 Amazon CloudWatch？](https://docs.aws.amazon.com/Amazon/latest/monitoring/WhatIs.html) 
+  [在 Amazon RDS 上使用 Performance Insights 監控資料庫負載](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) 
+  [介紹對於 Amazon EC2 Auto Scaling 預測擴展的原生支援](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/) 
+  [介紹 Karpenter - 一個開放原始碼的高效能 Kubernetes Cluster Autoscaler](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/) 
+  [深入探討 Amazon ECS 叢集 Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/) 

 **相關影片：** 
+  [打造兼具成本、能源和資源優勢的運算環境](https://www.youtube.com/watch?v=8zsC5e1eLCg) 
+  [更好、更快、更便宜的運算：成本優化 Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw) 

 **相關範例：** 
+  [實驗室：Amazon EC2 Auto Scaling 群組範例](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples) 
+  [實驗室：使用 Karpenter 實作自動擴展](https://www.eksworkshop.com/beginner/085_scaling_karpenter/) 

# SUS02-BP02 讓 SLA 符合永續性目標
<a name="sus_sus_user_a3"></a>

 根據您的永續性目標審查並優化工作負載的服務水準協議 (SLA)，例如可用性或資料保留期，以盡可能減少支援工作負載所需的資源，同時繼續滿足商業需求。 

 **常見的反模式：** 
+  工作負載 SLA 不明或語意不清。 
+  您僅針對可用性和效能定義 SLA。 
+  您對所有的工作負載使用相同的設計模式 (例如多可用區域架構)。 

 **建立此最佳實務的效益：**讓 SLA 符合永續性目標，可達到最佳資源用量並滿足商業需求。 

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

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

 SLA 會定義雲端工作負載應有的服務水準，例如回應時間、可用性和資料保留。其影響範圍涵蓋雲端工作負載的架構、資源用量和環境影響。請定期審查 SLA，並做出能大幅降低資源用量的取捨，換取可接受的服務水準降低。 

 **實作步驟** 
+  定義或重新設計支援永續性目標，同時正好滿足業務要求的 SLA。 
+  做出能大幅降低永續性影響的取捨，換取可接受的服務水準降低。 
  +  **永續性和可靠性：**高可用性的工作負載往往會耗用較多資源。 
  +  **永續性和效能：**使用較多資源以提升效能，可能會對環境造成較大的影響。 
  +  **永續性和安全性：**保護過度的工作負載可能會對環境造成較大的影響。 
+  使用優先執行業務關鍵功能的設計模式 (例如 [AWS 上的微型服務](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html))，對於非關鍵功能允許採用較低的服務水準 (例如回應時間或復原時間目標)。 

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

 **相關文件：** 
+  [AWS 服務水準協議 (SLA)](https://aws.amazon.com/legal/service-level-agreements/?aws-sla-cards.sort-by=item.additionalFields.serviceNameLower&aws-sla-cards.sort-order=asc&awsf.tech-category-filter=*all) 
+  [服務水準協議對 SaaS 供應商的重要性](https://aws.amazon.com/blogs/apn/importance-of-service-level-agreement-for-saas-providers/) 

 **相關影片：** 
+ [提供永續、高效能的架構](https://www.youtube.com/watch?v=FBc9hXQfat0)
+ [打造兼具成本、能源和資源優勢的運算環境](https://www.youtube.com/watch?v=8zsC5e1eLCg)

# SUS02-BP03 停止建立和維護未使用的資產
<a name="sus_sus_user_a4"></a>

將您工作負載中未使用的資產除役，以降低支援您個人需求所需的雲端資源數量，並盡可能減少浪費。

 **常見的反模式：** 
+  您未分析應用程式是否有冗餘或不再需要的資產。 
+  您未移除冗餘或不再需要的資產。 

 **建立此最佳實務的優勢：**移除未使用的資產可釋出資源，並改善工作負載的整體效率。 

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

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

 未使用的資產會耗用儲存空間和運算能力等資源。識別這些資產並將其消除可以釋出這類資源，進而提升雲端架構的效能。定期分析應用程式資產 (例如預先編譯的報告、資料集和靜態影像) 和資產存取模式，找出冗餘、未充分利用和可以除役的目標。移除這類冗餘資產，避免工作負載中的資源浪費。 

 **實作步驟** 
+  使用監控工具識別不再需要的靜態資產。 
+  移除任何資產之前，均應先評估該移除對架構的影響。 
+  制定計劃並移除不再需要的資產。 
+  合併重疊產生的資產以消除冗餘處理。 
+  更新您的應用程式，使其不再產生及儲存不需要的資產。 
+  指示第三方停止生產和儲存代表您管理但不再需要的資產。 
+  指示第三方合併代表您生產的冗餘資產。 
+  定期審查您的工作負載以識別並移除未使用的資產。 

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

 **相關文件：** 
+  [優化您的 AWS 永續性基礎設施，第 II 部分：儲存](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage/) 
+ [如何終止我的 AWS 帳戶 上不再需要的作用中資源？](https://aws.amazon.com/premiumsupport/knowledge-center/terminate-resources-account-closure/)

 **相關影片：** 
+ [如何檢查我的 AWS 帳戶 上是否有不再需要的作用中資源，並加以移除？](https://www.youtube.com/watch?v=pqg9AqESRlg)

# SUS02-BP04 根據使用者的聯網要求優化其工作負載的地理位置
<a name="sus_sus_user_a5"></a>

為您的工作負載選取可減少網路流量傳輸距離的區域和服務，並減少支援工作負載所需的整體網路資源。

 ** 常見的反模式： ** 
+  您可以根據自身所在位置選取工作負載的區域。 
+  您可以將所有工作負載資源合併到單一地理位置。 
+  通過現有資料中心的所有流量。 

 **建立此最佳實務的優勢：** 將工作負載分配到使用者附近的位置，可提供最低的延遲，同時減少網路間的資料移動，並降低環境影響。 

 **未建立此最佳實務時的曝險等級：** 中 

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

 AWS 雲端 基礎設施是根據如下的位置選項而建置的：區域、可用區域、放置群組和邊緣節點，例如 [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) 和 [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)。這些位置選項負責維護應用程式元件、雲端服務、邊緣網路和內部部署資料中心之間的連線。 

 分析工作負載中的網路存取模式，以識別如何使用這些雲端位置選項，以及減少網路流量必須輸送的距離。 

## 實作步驟
<a name="implementation-steps"></a>
+  分析您工作負載中的網路存取模式，以識別使用者如何使用您的應用程式。 
  +  使用監控工具，例如 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 和 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)，收集關於網路活動的資料。 
  +  分析資料以識別網路存取模式。 
+  根據下列關鍵元素，為您的工作負載部署選取區域： 
  +  **您的永續目標：** 相關說明請見 [區域選擇](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/region-selection.html)。
  +  **資料所在位置：** 對於資料密集型應用程式 (例如大數據和機器學習)，應用程式碼執行時應盡可能接近資料。 
  +  **使用者所在的位置：** 對於面向使用者的應用程式，請選擇接近工作負載使用者的一或多個區域。
  + **其他限制：** 請考量成本和合規性等限制，相關說明請見 [為工作負載選取區域時應考慮的事項](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)。
+  使用本機快取或 [AWS 快取解決方案](https://aws.amazon.com/caching/aws-caching/) 取得常用的資產，以提升效能、減少資料移動，以及降低環境影響。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-04-10/framework/sus_sus_user_a5.html)
+  使用可協助您在更接近工作負載使用者的位置執行程式碼的服務：    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-04-10/framework/sus_sus_user_a5.html)
+  使用連線共用來支援連線重複使用，減少所需資源。 
+  使用不倚賴持續連線和同步更新的分散式資料存放區來實現一致性，以服務區域的人口。 
+  以共用動態容量取代預先佈建的靜態網路容量，與其他訂閱者分攤網路容量的永續性影響。 

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

 **相關文件：** 
+  [優化您的 AWS 永續性基礎架構，第 III 部分：聯網](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/) 
+  [Amazon ElastiCache 文件](https://docs.aws.amazon.com/elasticache/index.html) 
+  [什麼是 Amazon CloudFront？](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) 
+  [Amazon CloudFront 主要功能](https://aws.amazon.com/cloudfront/features/) 

 **相關影片：** 
+  [揭密 AWS 上的資料傳輸](https://www.youtube.com/watch?v=-MqXgzw1IGA) 
+ [ 擴展新一代 Amazon EC2 執行個體的網路效能 ](https://www.youtube.com/watch?v=jNYpWa7gf1A)

 **相關範例：** 
+  [AWS 聯網研討會](https://catalog.workshops.aws/networking/en-US) 
+ [ 永續性架構 - 盡可能減少跨網路的資料移動 ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)

# SUS02-BP05 為執行的活動優化團隊成員資源
<a name="sus_sus_user_a6"></a>

優化提供給團隊成員的資源，以盡量減少對環境永續性的影響，同時支援他們的需求。

 **常見的反模式：** 
+  您忽略團隊成員所使用的裝置對雲端應用程式的整體效率產生的影響。 
+  您手動管理及更新團隊成員所使用的資源。 

 **建立此最佳實務的優勢：**優化團隊成員資源，可為具備雲端功能的應用程式改善整體效率。 

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

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

 了解團隊成員用來使用您的服務的資源、其預期生命週期，以及財務和永續性的影響。實作將這些資源優化的策略。例如，在使用率高的可擴展基礎設施上執行複雜的操作 (例如轉譯和編譯)，而不是在使用率低的高功率單一使用者系統上執行。 

 **實作步驟** 
+  根據使用方式佈建工作站和其他裝置。 
+  使用虛擬桌面和應用程式串流來限縮升級與裝置要求。 
+  將大量使用處理器或記憶體的任務移至雲端，以運用其彈性。 
+  評估程序和系統對裝置生命週期的影響，並選擇在滿足業務需求的同時可將裝置更換需求降至最低的解決方案。 
+  為裝置實作遠端管理，以減少必要商務差旅時間。 
  +  [AWS Systems Manager Fleet Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet.html) 是一種整合式使用者介面 (UI) 體驗，可協助您從遠端管理在 AWS 內部部署環境執行的節點。 

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

 **相關文件：** 
+  [什麼是 Amazon WorkSpaces？](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html) 
+ [Amazon WorkSpaces 的成本優化器](https://docs.aws.amazon.com/solutions/latest/cost-optimizer-for-workspaces/overview.html)
+  [Amazon AppStream 2.0 文件](https://docs.aws.amazon.com/appstream2/) 
+  [NICE DCV](https://docs.aws.amazon.com/dcv/) 

 **相關影片：** 
+  [在 AWS 上管理 Amazon WorkSpaces 的成本](https://www.youtube.com/watch?v=0MoY31hZQuE) 

# SUS02-BP06 實作緩衝或調節使需求曲線趨於扁平化
<a name="sus_sus_user_a7"></a>

緩衝和調節可讓需求曲線趨於扁平化，並減少您的工作負載所需的已佈建容量。

 **常見的反模式：** 
+ 您非必要地立即處理用戶端要求。
+ 您未分析用戶端要求的需求。

 **建立此最佳實務的優勢：**讓需求曲線趨於扁平化，可減少工作負載所需的已佈建容量。減少已佈建的容量意味著較低的能源耗用量和環境影響。 

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

 使工作負載需求曲線扁平化，有助於減少工作負載所需的已佈建容量，以及降低對環境造成的影響。假設某個工作負載的需求曲線如下圖所示。此工作負載有兩個尖峰，為了處理這些尖峰，已佈建了資源容量 (以橙色線顯示)。用於此工作負載的資源和能源並非由需求曲線底下的區域表示，而是已佈建的容量底下的區域，因為這兩個尖峰必須用已佈建的容量處理。 

![\[已佈建容量的波形圖，內含兩個需要大量已佈建容量的相異尖峰。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-04-10/framework/images/provisioned-capacity-1.png)


 

 您可以使用緩衝或調節來修正需求曲線，並使尖峰趨緩，意即減少已佈建的容量和耗用的能源。在用戶端可執行重試時實作調節。實作緩衝機制以儲存要求，並將處理的時間往後延遲。 

![\[此波形圖顯示使用緩衝或調節讓尖峰趨緩的工作負載。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-04-10/framework/images/provisioned-capacity-2.png)


 

 **實作步驟** 
+  分析用戶端要求以判斷如何予以回應。應考量的問題包括： 
  +  此要求是否可進行非同步處理？ 
  +  用戶端是否有重試能力？ 
+  如果用戶端有重試功能，您可以實作調節，以告知來源若目前無法處理要求，則應稍後再試。 
  +  您可以使用 [Amazon API Gateway](https://aws.amazon.com/api-gateway/) 來實作調節。 
+  針對無法執行重試的用戶端，必須實作緩衝區使需求曲線扁平化。緩衝會延遲要求處理，讓以不同速率執行的應用程式能夠有效地通訊。緩衝為主方法使用佇列或串流來接受生產者傳出的訊息。消費者可讀取訊息並進行處理，允許以符合取用者業務要求的速度運作訊息。 
  +  [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) 是一個受管服務，可提供佇列，允許單一取用者讀取個別訊息。 
  +  [Amazon Kinesis](https://aws.amazon.com/kinesis/) 可提供串流，允許許多取用者讀取相同訊息。 
+  分析整體需求、變更率及所需的回應時間，以適當調整所需的調節或緩衝區大小。 

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

 **相關文件：** 
+ [Amazon SQS 入門](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [使用佇列和訊息進行應用程式整合](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)

 **相關影片：** 
+ [為分散式應用程式選擇適當的傳訊服務](https://www.youtube.com/watch?v=4-JmX6MIDDI)