Google Cloud Well-Architected Framework 永續發展支柱中的這項原則提供建議，協助您最佳化調整 Google Cloud中工作負載的資源用量。
原則總覽
充分運用資源，是提升雲端環境永續發展的關鍵。從運算週期到資料儲存庫，每項佈建的資源都會直接影響能源用量、用水強度和碳排放量。如要減少工作負載的環境足跡，您必須在佈建、管理及使用雲端資源時，做出明智的選擇。
建議
如要充分運用資源，請參考下列各節的建議。
導入自動化和動態資源調度
自動和動態資源調度功能可確保資源用量達到最佳狀態，避免閒置或過度佈建的基礎架構浪費能源。減少能源浪費，降低成本和碳排放量。
請使用下列技術，實作自動和動態擴充功能。
使用水平資源調度
對於大多數雲端優先應用程式，水平資源調度是首選的資源調度技術。您不必增加每個執行個體的大小 (稱為垂直擴充)，而是新增執行個體來分配負載。舉例來說，您可以使用代管執行個體群組 (MIG)，自動向外擴充一組 Compute Engine VM。橫向擴充的基礎架構更具彈性，因為執行個體故障不會影響應用程式的可用性。對於負載程度不定的應用程式，水平資源調度也是一種節省資源的技術。
設定適當的資源調度政策
依據工作負載需求，設定自動調度資源。定義應用程式行為專屬的自訂指標和門檻。除了 CPU 使用率，您也可以考慮使用非同步工作的佇列深度、要求延遲時間和自訂應用程式指標等指標。為避免頻繁、不必要的資源調度或震盪，請定義明確的資源調度政策。舉例來說，如果是部署在 Google Kubernetes Engine (GKE) 的工作負載，請設定適當的叢集自動調度資源政策。
結合被動和主動資源調度
採用被動式資源調度時，系統會根據即時負載變化調整資源。這項技術適用於負載會出現無法預測高峰的應用程式。
主動調度資源適用於模式可預測的工作負載，例如每日固定營業時間和每週報表生成。針對這類工作負載，請使用排定的自動調度資源功能預先佈建資源，以便處理預期的負載量。這項技術可避免資源爭奪，並確保使用者體驗更流暢、效率更高。這項技術也有助於您主動規劃已知的負載高峰，例如大型特價活動和重點行銷活動。
Google Cloud 代管服務和功能 (例如 GKE Autopilot、Cloud Run 和 MIG) 會學習工作負載模式，自動管理主動調度資源。根據預設，如果 Cloud Run 服務未收到任何流量，就會將執行個體數量縮減至零。
設計無狀態應用程式
如要水平擴充應用程式，其元件應為無狀態。這表示特定使用者的工作階段或資料不會與單一運算執行個體連結。如果將工作階段狀態儲存在運算執行個體外部 (例如 Memorystore for Redis)，任何運算執行個體都能處理任何使用者的要求。這種設計方法可實現順暢且有效率的水平擴充。
使用排程和批次
批次處理適合大規模、非緊急的工作負載。批次工作可協助您最佳化工作負載，提高能源效率和成本效益。
請使用下列技術，實作排程和批次工作。
安排在碳排放強度較低時充電
安排批次工作在低碳區域執行，並在當地電網潔淨能源比例較高的時段執行。如要找出某個區域一天中碳密集度最低的時間，請使用碳足跡報告。
使用 Spot VM 處理非關鍵工作負載
Spot VM 可讓您以大幅折扣使用未使用的 Compute Engine 容量。Spot VM 可能會遭到先占，但能以符合成本效益的方式處理大型資料集，無須使用專屬且全天候運作的資源。Spot VM 適合非關鍵、容錯的批次工作。
整合及平行處理工作
如要減少啟動和關閉個別工作的負擔，請將類似的工作分組為單一大型批次。在 Batch 等服務上執行這些大量工作負載。這項服務會自動佈建及管理必要的基礎架構，確保資源使用率達到最佳狀態。
使用代管服務
Batch 和 Dataflow 等代管服務會自動處理資源佈建、排程和監控作業。雲端平台會處理資源最佳化。您可以專注於應用程式邏輯。舉例來說，Dataflow 會根據管道中的資料量，自動調度資源，因此您不必為閒置資源付費。
根據工作負載需求選擇 VM 機器家族
Compute Engine VM 可用的機器類型會依機器家族分組，並針對不同工作負載進行最佳化。根據工作負載需求 選擇合適的機器家族
| 機器家族 | 建議的工作負載類型 | 永續發展指南 |
|---|---|---|
| 一般用途執行個體：這類執行個體提供平衡的 CPU 與記憶體比率。 | 網路伺服器、微服務、中小型資料庫和開發環境。 | E2 系列會動態分配資源，因此成本效益和能源效率極高。C4A、N4A 和 Tau T2A 系列採用 Arm 架構處理器，在處理大規模工作負載時，每單位效能的能源效率通常較高。 |
| 運算最佳化執行個體：這類執行個體提供高 vCPU 與記憶體比率，以及高每核心效能。 | 高效能運算 (HPC)、批次處理、遊戲伺服器，以及 CPU 型資料分析。 | 運算最佳化執行個體可讓您更快完成 CPU 密集型工作，進而縮短工作的總運算時間和能源消耗量。 |
| 記憶體最佳化執行個體：這類執行個體專為需要大量記憶體的工作負載設計。 | 大型記憶體內資料庫和資料倉儲，例如 SAP HANA 或記憶體內數據分析。 | 記憶體最佳化執行個體可將記憶體密集型工作負載整合至較少的實體節點。相較於使用多個小型執行個體，這種整合方式可減少所需的總能源。高效能記憶體可縮短資料存取延遲時間，進而減少 CPU 處於運作狀態的總時間。 |
| 儲存空間最佳化執行個體：這類執行個體提供高處理量、低延遲的本機 SSD 儲存空間。 | 資料倉儲、記錄檔分析，以及 SQL、NoSQL 和向量資料庫。 | 儲存空間最佳化執行個體會在本機處理大量資料集，有助於消除跨位置網路資料輸出所使用的能源。使用本機儲存空間執行高 IOPS 工作時，可避免過度佈建多個標準執行個體。 |
| 加速器最佳化執行個體：這些執行個體專為 GPU 和 TPU 加速工作負載而建構，例如 AI、機器學習和 HPC。 | 機器學習模型訓練與推論，以及科學模擬。 | TPU 專為達到最佳能源效率而設計。每瓦運算量更高。 相較於僅使用 CPU 的替代方案，採用 NVIDIA H100 GPU 的 A3 系列等 GPU 加速執行個體，在訓練大型模型時，能源效率可大幅提升。雖然 GPU 加速執行個體的名目用電量較高，但完成工作的速度快得多。 |
升級至最新機型
使用最新機型可能有助於提升永續發展性。更新機器類型時，通常會設計成更節能，並提供更高的每瓦效能。使用最新機型的 VM 可能會以較低的耗電量完成相同的工作量。
CPU、GPU 和 TPU 通常會受益於晶片架構的技術進步，例如：
- 專用核心：處理器技術的進步通常包括專用核心或常見工作負載的指令。例如，CPU 可能有專門用於向量運算的核心，或整合式 AI 加速器。從主要 CPU 卸載這些工作後，工作完成效率會提高，且消耗的能源更少。
- 改善電源管理：晶片架構的進步通常包括更精密的電源管理功能，例如根據工作負載動態調整電壓和頻率。這些電源管理功能可讓晶片以最高效率運作，並在閒置時進入低功耗狀態，盡可能降低能源消耗。
晶片架構的技術改良，可直接帶來下列永續發展和成本效益：
- 每瓦效能更高：這是永續發展的重要指標。舉例來說，在能源消耗相同的情況下，C4 VM 的成本效益比 C3 VM 高出 40%。與同類 x86 處理器相比，C4A 處理器的能源效率高出 60%。這些效能功能可讓您更快完成工作，或使用較少的執行個體處理相同負載。
- 降低總能源消耗量：處理器效能提升後，運算資源用於特定工作的時間會縮短，進而降低整體能源用量和碳足跡。對於批次工作和機器學習模型訓練等短期、運算密集的工作負載，碳影響特別高。
- 最佳資源使用率：最新機型通常更適合現代軟體，且與雲端平台的進階功能更相容。這些機器類型通常能提高資源使用率，減少過度佈建的需求，並確保每瓦電力都能發揮效益。
部署容器化應用程式
您可以使用 GKE 和 Cloud Run 等容器式全代管服務，做為永續雲端運算策略的一部分。這些服務有助於最佳化資源使用率，並自動管理資源。
運用 Cloud Run 的「將資源調度率降至零」功能
Cloud Run 提供代管無伺服器環境，當服務沒有傳入流量或工作完成時，會自動將執行個體縮減至零。自動調度資源功能可避免閒置基礎架構消耗能源。只有在主動處理要求時，資源才會啟動。這項策略非常適合間歇性或事件驅動的工作負載。如果是 AI 工作負載，您可以搭配使用 GPU 和 Cloud Run，這樣只有在使用 GPU 時，才需要支付費用。
使用 GKE 自動最佳化資源
GKE 是容器自動調度管理平台，可確保應用程式只使用所需資源。為協助您自動最佳化資源，GKE 提供下列技術：
- 裝箱：GKE Autopilot 會智慧地將多個容器裝入可用節點。Bin packing 可盡量提高每個節點的使用率，並減少閒置或未充分利用的節點數量，有助於降低能源消耗。
- 水平自動調度 Pod 資源 (HPA)：HPA 會根據預先定義的指標 (例如 CPU 使用率或應用程式專屬的自訂指標)，自動調整容器副本 (Pod) 的數量。舉例來說，如果應用程式流量激增，GKE 會新增 Pod 來因應需求。流量減少時，GKE 會減少 Pod 數量。這種動態調度機制可避免過度佈建資源，因此您不必為不必要的運算能力付費或供電。
- 垂直自動調度 Pod 資源 (VPA)：您可以設定 GKE，自動調整個別容器的 CPU 和記憶體配置及限制。這項設定可確保容器不會分配到超出需求的資源，有助於避免過度佈建資源。
- GKE 多維度 Pod 自動調度資源：針對複雜的工作負載，您可以同時設定 HPA 和 VPA，將 Pod 數量和每個 Pod 的大小調整至最佳狀態。這項技術有助於確保在達到所需效能的前提下，盡可能降低能源足跡。
- 拓撲感知調度 (TAS)：TAS 會根據資料中心基礎架構的實體結構放置 Pod，提高 GKE 中 AI 和機器學習工作負載的網路效率。TAS 會策略性地將工作負載放在同一位置，盡可能減少網路躍點。這種共置方式有助於降低通訊延遲和能源消耗。TAS 可最佳化節點和專用硬體的實體配置，加快工作完成速度，並大幅提升大規模 AI 和機器學習工作負載的高能源效率。
設定碳感知排程
Google 持續將工作負載轉移至提供最潔淨電力的位置和時段。我們也會將舊設備回收再利用，用於其他用途。您可以運用這項碳感知排程策略，確保容器化工作負載使用潔淨能源。
如要實施碳感知排程，您需要即時瞭解某個區域中資料中心的能源組合資訊。您可以從 GitHub 的 Google Cloud 區域無碳能源存放區，或 BigQuery 公開資料集，取得機器可讀格式的這項資訊。用於計算 Google 年度碳資料集的每小時電網組合和碳排放強度資料，來自 Electricity Maps。
如要實施碳感知排程，建議您採用下列技術：
- 地理位置轉移：安排工作負載在可再生能源使用比例較高的區域執行。這種做法可讓您使用更乾淨的電網。
- 時間轉移：針對批次處理等非關鍵、彈性的工作負載，設定在離峰時段或可再生能源最充足時執行。這種方法稱為時間轉移，可利用更潔淨的能源 (如有)，減少整體碳足跡。
建立節能的災難復原架構
準備災難復原 (DR) 時，通常需要在次要區域預先佈建備援資源。不過，閒置或未充分利用的資源可能會造成大量能源浪費。選擇可充分利用資源並盡量減少碳影響的災難復原策略，同時不影響復原時間目標 (RTO)。
提高冷啟動效率
請採取下列做法，盡量減少或消除次要 (災難復原) 區域中的有效資源：
- 優先採用冷災害復原：將災害復原區域中的資源保持關閉，或將資源調度率降至零。這種做法有助於消除閒置運算資源的碳足跡。
- 善用無伺服器容錯移轉：使用 Cloud Run 等代管無伺服器服務做為災難復原端點。Cloud Run 在未使用時會將資源調度率降至零，因此您可以維護不消耗能源的 DR 拓撲，直到流量轉移至 DR 區域為止。
- 使用基礎架構即程式碼 (IaC) 自動復原：不要讓災難復原站點中的資源持續運作 (暖備援)，而是使用 Terraform 等 IaC 工具，在需要時才快速佈建環境。
兼顧備援和使用率
資源備援是能源浪費的主要原因。如要減少備援，請採用下列方法：
- 優先採用主動-主動模式，而非主動-被動模式：在主動-被動設定中，被動網站中的資源處於閒置狀態，會浪費能源。大小最佳化的雙主動架構可確保兩個區域中所有佈建的資源都能主動提供流量。這種做法有助於大幅提高基礎架構的能源效率。
- 適當調整備援：只有在需要符合高可用性或災難復原需求時，才跨區域複製資料和服務。每增加一個副本，永久儲存空間和網路輸出的能源成本就會提高。