Google Cloud Well-Architected Framework 的這個要素提供建議，協助您最佳化Google Cloud工作負載的效能。
本文適用對象為在 Google Cloud中規劃、設計、部署及管理工作負載的架構師、開發人員和管理員。
本支柱中的建議可協助貴組織提高營運效率、提升顧客滿意度、增加收益及降低成本。舉例來說，當應用程式的後端處理時間減少時，使用者會體驗到更快的反應時間，這可能會提高使用者留存率和收益。
效能最佳化程序可能需要在效能和成本之間做出取捨。不過，最佳化效能有時可協助您降低成本。舉例來說，當負載增加時，自動調度資源功能可確保系統資源不會超載，協助提供可預測的效能。此外，自動調度資源功能也會在負載較低時移除未使用的資源，協助您降低成本。
效能最佳化是持續進行的過程，而非一次性活動。下圖顯示效能最佳化程序的各個階段：
效能最佳化程序是一個持續循環，包含下列階段：
- 定義需求：在設計及開發應用程式之前，請先為應用程式堆疊的每一層定義精細的效能需求。規劃資源分配時，請考量主要工作負載特性和預期效能。
- 設計和部署：使用彈性且可擴充的設計模式，協助您滿足效能需求。
- 監控及分析：使用記錄、追蹤、指標和快訊，持續監控效能。
最佳化：隨著應用程式演進，考慮潛在的重新設計。調整雲端資源規模，並使用新功能，滿足不斷變化的效能需求。
如上圖所示，請持續監控、重新評估需求，並調整雲端資源。
如要瞭解 AI 和機器學習工作負載專屬的效能最佳化原則和建議，請參閱 Well-Architected Framework 中的「AI 和機器學習觀點：效能最佳化」。
使用代理技能評估工作負載
如要讓 AI 代理依據本支柱的原則和建議評估雲端工作負載，請使用 google-cloud-waf-performance-optimization 技能，該技能位於 GitHub 的 Google 代理技能存放區。
如要安裝技能，請在代理用戶端或終端機中執行下列指令：
npx skills add google/skills --skill google-cloud-waf-performance-optimization
系統提示時，請指定要安裝技能的 AI 代理，並設定安裝範圍 (專案或全域)。
如果已安裝技能，可以執行下列指令，更新至最新版本：
npx skills update
核心原則
Well-Architected Framework 效能最佳化支柱中的建議，對應至下列核心原則：
貢獻者
作者：
- Daniel Lees | 雲端安全架構師
- Gary Harmson | 首席架構師
- Luis Urena | 開發人員關係工程師
- Zach Seils | 網路專員
其他貢獻者：
- Filipe Gracio 博士 | 客戶工程師、AI/機器學習專家
- Jose Andrade | 客戶工程師、SRE 專家
- Kumar Dhanagopal | 跨產品解決方案開發人員
- Marwan Al Shawi | 合作夥伴客戶工程師
- Nicolas Pintaux | 客戶工程師，應用程式翻新專家
- Ryan Cox | 首席架構師
- Radhika Kanakam | Well-Architected Framework 專案負責人 Google Cloud
- Samantha He | 技術撰稿人
- Wade Holmes | 全球解決方案總監
規劃資源分配方式
這項原則屬於 Google Cloud Well-Architected Framework 的效能最佳化要素，提供建議協助您規劃Google Cloud工作負載的資源。並強調在設計及開發應用程式，以便進行雲端部署或遷移之前，定義精細需求的重要性。
原則總覽
為滿足業務需求，請務必在設計和開發前，先定義應用程式的效能需求。請盡可能針對整個應用程式和應用程式堆疊的每一層，定義這些需求。舉例來說，在儲存層中，您必須考量應用程式所需的處理量和每秒輸入/輸出作業 (IOPS)。
從一開始，就應考量效能和擴充性來規劃應用程式設計。請考量使用者人數、資料量，以及日後可能成長的幅度等因素。
各工作負載的效能需求不盡相同，取決於工作負載類型。每個工作負載都可能包含多個元件系統和服務，且各具獨特的效能特性。舉例來說，負責定期批次處理大型資料集的系統，與互動式虛擬桌面解決方案的效能需求不同。最佳化策略必須滿足各項工作負載的特定需求。
請選取符合各工作負載成效目標的服務和功能。成效最佳化沒有一體適用的解決方案。最佳化每項工作負載後，整個系統就能達到最佳效能和效率。
請考量下列可能影響效能需求的工作負載特性：
- 部署原型：您為應用程式選取的部署原型可能會影響您選擇的產品和功能，進而決定應用程式的預期效能。
- 資源位置：為應用程式資源選取 Google Cloud 區域時，建議您優先考量降低使用者延遲、遵守資料位置法規，並確保所需 Google Cloud 產品和服務可用。
- 網路連線：選擇可最佳化資料存取和內容傳遞的網路服務。充分運用 Google Cloud的全球網路、高速骨幹、互連位置和快取服務。
- 應用程式託管選項：選取託管平台時，您必須評估每個選項的效能優缺點。例如裸機、虛擬機器、容器和無伺服器平台。
- 儲存空間策略：根據效能需求選擇最佳儲存空間策略。
- 資源設定：機型、IOPS 和處理量可能會對效能產生重大影響。此外，在設計階段初期，您必須考量適當的安全功能及其對資源的影響。規劃安全防護功能時，請做好準備，在效能方面做出必要取捨，避免發生任何非預期的影響。
建議
為確保資源分配最佳化，請參考下列各節的建議。
設定及管理配額
確保應用程式只使用必要的資源，例如記憶體、儲存空間和處理能力。過度分配可能導致不必要的費用，而分配不足則可能降低效能。
為因應彈性調度資源，並確保有足夠的資源可用，請定期監控配額容量。此外，您也可以追蹤配額用量，找出潛在的擴充限制或過度分配問題，進而做出明智的資源分配決策。
教育和宣導
向使用者說明成效規定，並提供有效成效管理技巧的教育資源。
如要評估進度並找出待改進之處，請定期記錄目標成效和實際成效。對應用程式進行負載測試，找出潛在的中斷點，並瞭解如何擴充應用程式。
監控成效指標
使用 Cloud Monitoring 分析成效指標趨勢、分析實驗效果、定義重要指標的快訊，以及執行回溯分析。
Active Assist 是一組工具，可提供洞察資料和建議，協助您充分運用資源。這些建議可協助您調整資源分配，並提升效能。
發揮彈性優勢
Google Cloud Well-Architected Framework 效能最佳化支柱中的這項原則提供建議，協助您納入彈性，也就是根據工作負載需求的變化動態調整資源的能力。
彈性可讓系統的不同元件獨立調整資源配置。這種精準擴充方式可將資源分配到最需要的地方，避免過度或不足，進而提升效能和成本效益。
原則總覽
系統的效能需求會直接影響系統垂直或水平擴充的時間和方式。您需要評估系統容量，並判斷系統在基準狀態下預期要處理的負載。接著，您必須決定系統如何因應負載增減。
負載增加時，系統必須水平擴展、垂直擴充，或兩者兼具。如要水平調度資源，請新增副本節點，確保系統有足夠的整體容量，可因應增加的需求。如要垂直擴充，請將應用程式現有元件替換為容量、記憶體和儲存空間更大的元件。
負載降低時，系統必須縮減資源 (橫向、縱向或兩者皆是)。
定義系統擴充或縮減資源的情況。如果已知流量會在特定時段激增，請預先規劃手動擴充系統。使用自動調度資源等工具，因應負載增減。
建議
如要充分發揮彈性，請參考下列各節的建議。
規劃高負載時段
您需要為已知事件 (例如預期客戶需求增加的期間) 規劃有效的資源調度路徑。
建議您在已知的高流量時段前擴充系統。舉例來說，如果您是零售組織，預期需求會在季節性特賣期間增加。建議您在這些特賣活動前，手動擴充或水平擴展系統，確保系統能立即處理增加的負載，或立即調整現有限制。否則，系統可能需要幾分鐘才能新增資源，以因應即時變化。應用程式的容量可能無法快速增加，導致部分使用者遇到延遲。
對於未知或非預期的事件 (例如需求或流量突然激增)，您可以使用自動調度資源功能，根據指標觸發彈性調度資源。這些指標包括 CPU 使用率、負載平衡器服務容量、延遲時間，甚至是您在 Cloud Monitoring 中定義的自訂指標。
舉例來說，假設某個應用程式在 Compute Engine 代管執行個體群組 (MIG) 上執行。這項應用程式要求每個執行個體在平均 CPU 使用率達到 75% 之前，都能發揮最佳效能。在這個例子中，您可以定義自動調度資源政策，在 CPU 使用率達到門檻時建立更多執行個體。這些新建立的執行個體有助於吸收負載，確保平均 CPU 使用率維持在最佳速率，直到達到您為 MIG 設定的執行個體數量上限。當需求減少時，自動調度資源政策會移除不再需要的執行個體。
在 BigQuery 中規劃資源運算單元預留項目，或使用代管自動配置器調整 Spanner 的自動調度資源設定限制。
使用預測式資源調度功能
如果系統元件包含 Compute Engine，您必須評估預測自動調度資源是否適合您的工作負載。預測式自動調度資源會根據指標的歷來趨勢 (例如 CPU 使用率)，預測未來的負載。預測結果每隔幾分鐘就會重新計算，因此自動配置器會根據最近的負載變化快速調整預測結果。如果沒有預測式自動調度資源功能，自動配置器只能根據觀察到的即時負載變化，被動調度群組資源。預測式自動調度資源功能會同時使用即時資料和歷來資料，因應目前和預測的負載。
實作無伺服器架構
建議您使用本身具有彈性的無伺服器服務，實作無伺服器架構，例如：
有別於其他服務 (例如 Compute Engine) 必須依賴微調規則，無伺服器的自動調度資源功能會隨時運作，並能將配置資源縮減至零。
使用 Kubernetes 的 Autopilot 模式
如果複雜的應用程式需要更精細地控管 Kubernetes，建議使用 Google Kubernetes Engine (GKE) 的 Autopilot 模式。Autopilot 模式預設提供自動化和擴充功能。GKE 會根據流量自動調度節點和資源。GKE 會管理節點、為應用程式建立新節點，以及設定自動升級和修復功能。
推廣模組化設計
Google Cloud Well-Architected Framework 效能最佳化支柱中的這項原則，提供建議協助您推廣模組化設計。模組化元件和清楚的介面可讓您彈性擴充、獨立更新，以及在日後分離元件。
原則總覽
瞭解應用程式元件和系統元件之間的依附關係，設計可擴充的系統。
無論最初部署的是單體式或微服務架構，模組化設計都能提供彈性和韌性。將系統分解為定義明確、獨立且介面清晰的模組，即可擴充個別元件，滿足特定需求。
指定目標資源調度可透過下列方式，充分運用資源並降低成本：
- 只為每個元件佈建必要資源，並為需求較低的元件分配較少資源。
- 在流量較高的時段增加資源，維持使用者體驗。
- 移除使用率過低的資源，且不影響效能。
模組化也能提升可維護性。較小的獨立單元更容易理解、偵錯和更新，可加快開發週期並降低風險。
雖然模組化具有顯著優勢，但您必須評估潛在的效能取捨。模組之間的通訊增加，可能會導致延遲和負擔。請在模組化和效能之間取得平衡。高度模組化的設計可能不適用於所有情況。如果效能至關重要，則可能適合採用更緊密耦合的方法。系統設計是反覆進行的程序，您需要持續檢視及調整模組化設計。
建議
如要推廣模組化設計，請參考下列各節的建議。
採用鬆耦合設計
設計鬆耦合架構。依附元件最少的獨立元件可協助您建構可擴充且有彈性的應用程式。規劃服務邊界時，必須考量可用性和擴充性需求。舉例來說，如果某個元件的需求與其他元件不同，您可以將該元件設計為獨立服務。針對不重要的子程序或服務，實施適當的失敗處理計畫，以免影響主要服務的回應時間。
設計並行和平行處理
設計應用程式時，應支援同時處理多項工作，例如處理多項使用者要求，或在使用者與系統互動時執行背景工作。將大型工作拆分為多個小型區塊，以便多個服務執行個體同時處理。工作並行功能可讓您使用自動調度資源等功能，增加下列產品的資源分配：
平衡模組化，彈性分配資源
盡可能確保每個元件只使用特定作業所需的資源 (例如記憶體、儲存空間和處理能力)。資源分配過多可能會產生不必要的費用，而資源分配不足則可能影響效能。
使用定義明確的介面
確保模組化元件透過明確、標準化的介面 (例如 API 和訊息佇列) 有效通訊，減少轉譯層或不必要流量造成的負擔。
使用無狀態模型
無狀態模型可確保您能獨立處理每項要求或與服務的互動，不受先前要求影響。這種模式可提升擴充性和復原能力，因為您可以擴充、縮減或重新啟動服務，而不會遺失進行中要求或程序所需的資料。
選擇互補技術
選擇與模組化設計相輔相成的技術。評估程式設計語言、框架和資料庫對模組化的支援程度。
詳情請參閱下列資源：
持續監控及提升效能
Google Cloud Well-Architected Framework 效能最佳化支柱中的這項原則，提供相關建議，協助您持續監控及改善效能。
部署應用程式後，請使用記錄、追蹤、指標和快訊，持續監控應用程式效能。隨著應用程式成長和演變，您可以利用這些資料點的趨勢，重新評估成效需求。您可能需要重新設計應用程式的部分內容，才能維持或提升效能。
原則總覽
如要持續提升效能，必須採用完善的監控工具和策略。Cloud 觀測能力工具可協助您收集關鍵成效指標 (KPI)，例如延遲時間、處理量、錯誤率和資源使用率。雲端環境提供多種方法，可對應用程式、網路和使用者體驗進行精細的效能評估。
提升效能是一項持續的工作，需要多管齊下。下列重要機制和程序有助於提升成效：
- 為提供明確方向並協助追蹤進度，請根據業務目標定義成效目標。設定 SMART 目標：具體 (specific)、可衡量 (measurable)、可達成 (achievable)、相關 (relevant) 且有時限 (time-bound)。
- 如要評估成效並找出可改善之處，請收集 KPI 指標。
- 如要持續監控系統問題，請使用監控工具中的視覺化工作流程。使用架構程序對應技術，找出重複和效率不彰之處。
- 如要打造持續進步的文化，請提供有助於員工成長的訓練和計畫。
- 為鼓勵主動持續改善，請提供獎勵，讓員工和客戶持續提供應用程式效能的意見回饋。
建議
如要推廣模組化設計，請參考下列各節的建議。
定義明確的成效目標和指標
根據業務目標，定義明確的成效目標。這需要深入瞭解應用程式架構，以及各個應用程式元件的效能需求。
請優先最佳化會直接影響核心業務功能和使用者體驗的重要元件。為確保這些元件持續有效運作並滿足業務需求，請設定具體且可衡量的成效目標。這些目標可能包括回應時間、錯誤率和資源使用率門檻。
這種主動做法可協助您找出並解決潛在瓶頸、最佳化資源分配，最終為使用者提供流暢且高效能的體驗。
監控成效
持續監控雲端系統的效能問題，並設定潛在問題的警示。監控和快訊功能可協助您在問題影響使用者前，及早發現並修正問題。應用程式剖析可協助找出瓶頸，並盡可能提高資源使用率。
您可以使用工具，有效排解問題及最佳化網路。使用 Google Cloud Observability 找出 CPU、記憶體或網路耗用量偏高的區域。這些功能可協助開發人員提高效率、降低成本，並提升使用者體驗。Network Intelligence Center 會以視覺化方式呈現網路基礎架構的拓撲，協助您找出高延遲路徑。
鼓勵持續改進
打造持續改善的文化，讓應用程式和使用者體驗都能受益。
為員工提供訓練和發展機會，提升他們在雲端服務效能技術方面的技能和知識。建立實踐社群 (CoP)，並提供指導和輔導計畫，協助員工成長。
為避免被動效能管理，並鼓勵主動效能管理，請鼓勵員工、客戶和利害關係人持續提供意見回饋。您可以考慮將這個過程遊戲化，方法是追蹤成效 KPI，並定期以排行榜的形式向團隊展示這些指標。
如要瞭解一段時間內的成效和使用者滿意度，建議您從量化和質化兩方面評估使用者意見回饋。HEART 架構可協助您收集五個類別的使用者意見回饋：
- 滿意度
- 參與
- 採用率
- 保留
- 工作成功
使用這類架構，您就能透過資料導向的意見回饋、以使用者為中心的指標、可做為行動依據的洞察資料，以及明確的目標，激勵工程師。