效能效率取捨
符合其效能目標的工作負載，而不過度布建是有效率的。 效能效率的目標是要有足夠供應，隨時處理需求。 效能效率的關鍵策略包括適當使用程式代碼優化、設計模式、容量規劃和調整。 清除效能目標，並測試支撐此支柱。
在交涉工作負載的效能目標及設計工作負載以提升效能效率的過程中，請務必瞭解效能效率設計原則和效能效率設計檢查清單中的建議，可能會影響其他要素的優化目標。 某些效能效率決策可能會有利於某些要素，但對其他要素構成取捨。 本文列出在設計工作負載架構和作業以提升效能時，工作負載小組可能會遇到的範例取捨。
效能效率取捨可靠性
取捨：減少複寫並增加密度。 可靠性的基石是使用復寫來確保復原能力，並限制故障的爆破半徑。
工作負載，可藉由延遲調整直到最後一個負責的時刻密切符合需求，但容易受到未預期節點失敗和調整延遲的影響，以達到效率。
合併工作負載資源可以使用多餘的容量並提高效率。 不過，它會增加共置元件或應用程式平臺中故障的爆破半徑。
相應縮小或縮小以將剩餘容量降到最低，可能會讓工作負載在使用量尖峰期間過度布建，這會導致因供應不足而導致服務中斷。
使用自動調整來平衡工作負載供應與需求之間的變化，會導致工作負載拓撲的變化，並新增必須正確運作的元件，讓系統可靠。 自動調整會導致觸發更多應用程式生命週期事件，例如啟動和停止。
數據分割和分區化有助於避免大型或經常存取數據集的效能問題。 不過，這些模式的實作會增加複雜度，因為需要跨其他資源維護（最終）一致性。
將優化存取模式的數據反正規化可以改善效能，但會帶來複雜性，因為需要保持同步處理數據的多個表示法。
以效能為中心的雲端設計模式有時需要引進其他元件。 使用這些元件會增加工作負載的介面區。 然後，元件本身必須可靠，才能讓整個工作負載保持可靠。 範例包含：
- 用於負載撫平的訊息總線，引進了重要的具狀態元件。
- 自動調整複本的負載平衡器，需要可靠的作業和複本登記。
- 將數據卸除至快取，這需要可靠的快取失效方法。
使用綜合交易等使用中環境中的效能測試，可能會因為測試動作或設定而造成故障。
工作負載應使用應用程式效能監視 （APM） 系統進行檢測，讓小組能夠從作用中環境學習。 APM 工具會在應用程式程式代碼或裝載環境中安裝及設定。 不當使用、超過限制或工具設定錯誤，可能會危害其功能和維護，這可能會破壞可靠性。
與安全性的效能效率取捨
效能優化策略是移除或略過造成流程延遲的元件或進程，尤其是在處理時間不合理時。 不過，此策略可能會危害安全性，而且應該伴隨著徹底的風險分析。 請參考下列範例：
拿掉傳輸中或待用加密以改善傳送速率，會將數據公開為潛在的完整性或機密性缺口。
拿掉或減少安全性掃描或檢查工具以減少處理時間，可能會危害這些工具所保護的機密性、完整性或可用性。
減少安全性修補以限制效能影響的頻率，可能會讓工作負載更容易受到新興威脅的影響。
從網路流程移除防火牆規則以改善網路等待時間，可能會允許不想要的通訊。
將數據驗證或內容安全性檢查降至最低，以便更快速的數據處理可能會危害數據完整性，特別是輸入為惡意時。
例如，在初始化向量上，在加密或哈希演算法中使用較少的 entropy 會更有效率，但可讓加密更容易破解。
以效能為中心的雲端設計模式有時需要引進其他元件。 這些元件會增加工作負載的介面區。 新的元件必須受到保護，可能的方式尚未在系統中使用，而且通常會增加合規性範圍。 請考慮這些常用的元件：
用於負載撫平的訊息總線
自動調整複本的負載平衡器
將數據卸除至快取、應用程式傳遞網路或內容傳遞網路
將處理卸除至背景作業，甚至是客戶端計算
透過增加密度共享資源是提升效率的方法。 範例包括多租使用者案例，或在通用應用程式平臺上的架構中結合不同的應用程式。 密度增加可能會導致下列安全性考慮：
增加從一個租使用者到另一個租使用者未經授權橫向移動的風險。
共用工作負載身分識別，違反最低許可權原則，並遮蔽存取記錄中的個別稽核線索。
周邊安全性控制，例如網路規則，減少以涵蓋所有共置元件，讓個別元件具有比必要更多的存取權。
由於較大的爆破半徑，應用程式平臺主機或個別元件遭到入侵。 這種增加是因為更容易存取共置元件所造成。
由於共用主機，共置不同的元件，導致合規性範圍中的更多元件。
效能效率取捨與成本優化
當小組嘗試降低工作負載中的效能問題時，過度布建是一種風險。 過度布建的一些常見原因包括：
- 初始容量規劃被誤判，因為小組只專注於尖峰負載估計，忽略了工作負載設計中尖峰平滑的策略。
- 在事件回應的疑難解答步驟期間相應增加或相應放大資源。
自動調整可能會設定錯誤。 設定錯誤自動調整的一些範例包括：
- 在需求變更最少的情況下相應增加，或延長降溫期間可能會產生比需求更高的成本。
- 在沒有設定上限的情況下使用自動調整可能會導致因系統故障或濫用而導致不受控制的成長，並超過預期的工作負載需求。
擴充至多個區域可藉由讓工作負載更接近用戶來增強效能，並可避免暫時性資源容量限制。 不過，該拓撲也會增加複雜度和資源重複。
以效能為中心的雲端設計模式有時需要引進額外的元件。 這些額外的元件通常會導致工作負載的整體成本增加。 例如，您可能會包含訊息總線，以便將工作負載撫平或卸除至應用程式或內容傳遞網路，以改善回應時間。
資源分割可讓工作負載的不同部分具有不同的效能特性，為每個區段啟用獨立的微調。 不過，它可能會增加總擁有成本，因為它需要多個優化的區段，而不是單一的一般化元件。
進階服務和SKU可協助工作負載符合效能目標。 這些服務通常會花費更多成本，而且可以提供額外的功能。 如果許多進階功能並未特別用於達到效能目標，它們可能會使用量過低。
高效能工作負載需要遙測數據，才能進行可觀察性，必須傳輸和儲存。 所收集效能遙測的增加可能會增加遙測數據傳輸和記憶體的成本。
效能測試活動會增加與生產系統值無關的成本。 效能測試成本的範例包括：
- 具現化專用於以效能為中心的測試的環境。
- 使用特製化效能工具。
- 花時間執行測試。
為特製化效能優化工作訓練小組成員，或為效能微調服務付費，會增加工作負載的成本。
卓越營運的效能效率取捨
減少記錄和計量磁碟區以減少收集遙測所花費的處理時間，而不是其他工作，可減少系統的整體可觀察性。 產生的可觀察性降低的一些範例包括：
- 它會限制用來建置有意義警示的數據點。
- 這會導致事件響應活動的涵蓋範圍差距。
- 它會限制安全性敏感性或合規性相關互動和界限的可檢視性。
實作效能設計模式時，工作負載的複雜性通常會增加。 元件會新增至重要流程。 工作負載監視策略和效能監視必須包含這些元件。 當流程跨越多個元件或應用程式界限時，監視該流程效能的複雜性會增加。 流程效能必須與所有互連元件相互關聯。
藉由增加密度提升作業工作的風險，提升效能效率。 單一程式中的錯誤可能會有較大的爆破半徑。
實作效能設計模式時，它們會影響備份、金鑰輪替和復原策略等作業程式。 例如，當小組嘗試確保這些工作不會影響數據一致性時，數據分割和分區化可能會使例行工作複雜化。
對效能問題進行根本原因分析，可識別需要更正之程式或實作的缺陷。 小組應該考慮練習是學習機會。 如果小組成員被指責為問題，士氣可能會受到影響。
例程和臨機操作程式可能會影響工作負載效能。 通常最好在離峰時段執行這些活動。 不過，對於負責或熟練處理這些工作的小組成員來說，離峰時間可能會不方便或超出正常時間。
相關連結
探索其他要素的取捨：