Well-Architected Framework：效能最佳化支柱

Last reviewed 2025-02-14 UTC

Google Cloud 架構完善架構的這項支柱提供相關建議，可協助您最佳化Google Cloud中的工作負載效能。

本文專供架構師、開發人員和管理員參考，協助他們規劃、設計、部署及管理 Google Cloud中的工作負載。

這個支柱的建議可協助貴機構提高營運效率、提升顧客滿意度、增加收益及降低成本。舉例來說，如果應用程式的後端處理時間縮短，使用者就能更快收到回應，進而提高使用者留存率和收益。

最佳化效能的過程可能需要權衡效能和成本。不過，最佳化成效有時可以協助您降低成本。舉例來說，當負載增加時，自動調度資源功能可確保系統資源不會過度負載，進而提供可預測的效能。自動調度資源功能也會在負載偏低時移除未使用的資源，協助您降低成本。

最佳化效能是持續性程序，而非一次性活動。下圖顯示成效最佳化程序的各個階段：

效能最佳化程序

成效最佳化程序是持續進行的循環，包含下列階段：

  1. 定義需求：設計及開發應用程式前，請先為應用程式堆疊的每個層級定義精細的效能需求。如要規劃資源分配，請考量主要工作負載特徵和預期效能。
  2. 設計及部署：使用彈性且可擴充的設計模式，協助您達到效能需求。
  3. 監控及分析：使用記錄檔、追蹤、指標和快訊，持續監控效能。

  4. 最佳化：隨著應用程式演進，考慮進行潛在的重新設計。 適當調整雲端資源大小，並使用新功能來滿足不斷變化的效能需求。

    如上圖所示，請繼續進行監控、重新評估需求及調整雲端資源的週期。

如要瞭解 AI 和機器學習工作負載專用的效能最佳化原則和建議，請參閱 Well-Architected 架構中的「AI 和機器學習觀點：效能最佳化」。

核心原則

架構完善架構的效能最佳化支柱中的建議，會對應至下列核心原則：

貢獻者

作者：

其他貢獻者：

規劃資源分配

Google Cloud Well-Architected Framework 的效能最佳化支柱中，這項原則提供相關建議，協助您規劃Google Cloud工作負載的資源。並強調在設計及開發雲端部署或遷移應用程式前，定義細部需求的重要性。

原則總覽

為滿足業務需求，請務必在設計和開發前，先定義應用程式的效能需求。請盡可能詳細地定義這些需求，包括整個應用程式和應用程式堆疊的每個層級。舉例來說，在儲存層中，您必須考量應用程式所需的總處理量和每秒 I/O 作業數 (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 架構完善架構效能最佳化支柱的一部分，可提供建議，協助您持續監控及提升效能。

部署應用程式後，請使用記錄、追蹤、指標和快訊，持續監控應用程式的效能。隨著應用程式成長和演進，您可以根據這些資料點的趨勢，重新評估效能需求。您可能最終需要重新設計應用程式的部分內容，以維持或提升效能。

原則總覽

如要持續提升效能，就必須使用強大的監控工具和策略。雲端可觀測性工具可協助您收集延遲時間、輸送量、錯誤率和資源用量等主要成效指標 (KPI)。雲端環境提供多種方法，可針對應用程式、網路和使用者體驗進行精細的效能評估。

提升成效是持續性的工作，需要多管齊下。以下主要機制和程序有助於提升成效：

  • 為提供明確指引及追蹤進度，請定義與業務目標一致的成效目標。設定 SMART 目標：具體、可衡量、可達成、相關且有時限。
  • 如要評估成效並找出可改善之處，請收集關鍵績效指標。
  • 如要持續監控系統問題，請在監控工具中使用視覺化工作流程。運用架構程序對應技術，找出多餘和效率不彰的部分。
  • 為打造持續改善的文化，請提供有助於員工成長的訓練和計畫。
  • 為鼓勵主動持續改善，請獎勵員工和顧客持續提供應用程式效能的意見回饋。

建議

如要推廣模組化設計，請參考下列各節的建議。

設定明確的成效目標和指標

定義與業務目標一致的明確成效目標。這需要深入瞭解應用程式架構，以及每個應用程式元件的效能需求。

請優先最佳化直接影響核心業務功能和使用者體驗的重要元件。為確保這些元件持續有效運作並滿足業務需求，請設定具體且可衡量的成效目標。這些目標包括回應時間、錯誤率和資源使用率門檻。

這種積極主動的做法有助於找出並解決潛在瓶頸、妥善分配資源，最終為使用者提供流暢且高效能的體驗。

監控成效

持續監控雲端系統的效能問題，並針對任何潛在問題設定快訊。監控和警示功能可協助您在問題影響使用者前，及時發現並修正。應用程式剖析有助於找出瓶頸，並盡可能最佳化資源使用情況。

您可以運用相關工具，有效排解問題並提升網路效能。使用 Google Cloud Observability 找出 CPU、記憶體或網路用量偏高的區域。這些功能可協助開發人員提高效率、降低成本，以及提升使用者體驗。Network Intelligence Center 會以視覺化方式呈現網路基礎架構的拓撲，協助您找出高延遲路徑。

鼓勵持續改善

營造持續改善的文化，讓應用程式和使用者體驗都能受益。

為員工提供訓練和發展機會，提升他們在雲端服務效能技術方面的技能和知識。建立實務社群 (CoP)，並提供指導和教練計畫，協助員工成長。

為避免被動的績效管理，並鼓勵主動績效管理，請鼓勵員工、客戶和利害關係人持續提供意見回饋。您可以追蹤成效 KPI，並以排行榜的形式定期向團隊呈現這些指標，讓這個過程變得像遊戲一樣。

為瞭解一段時間內的成效和使用者滿意度，建議您從量化和質化兩方面評估使用者意見回饋。HEART 架構可協助您收集五大類別的使用者意見回饋：

  • 滿意度
  • 互動
  • 採用率
  • 保留
  • 工作成功

透過這類架構，您可以運用資料導向的回饋、以使用者為中心的指標、可做為行動依據的洞察資料，以及對目標的清楚瞭解，激勵工程師。