水準擴充與垂直擴充：哪種更适合調整應用程式資源消耗并優化雲成本？
譯自 How to Avoid Overprovisioning Java Resources，作者 Pratik Patel。
開發人員是奇怪的動物；我們會在應用程式中使用閃亮的新工具或庫，而不會過多考慮，但在部署到生産環境時卻很謹慎。沒有人希望他們的尋呼機在半夜開始嗡嗡作響，更不用說保持應用程式以 高 9s 的可靠性運作的壓力了。開發人員在建構和編碼應用程式時很有冒險精神，但在操作元素方面卻非常保守。
出現了一種稱為過度配置的現象：在雲環境中為應用程式的部署添加額外的馬力（通常是 CPU 和 RAM），以確定應用程式有足夠的啟動空間，并為應用程式運作時發生的峰值提供空間。
幸運的是，有一些方法可以減少您對度配置的需求，進而節省大量的雲支出。我将專門研究 Java 應用程式中的過度配置。
應用程式負載永遠不穩定
正如任何開發人員或 DevOps 人員都會告訴您的那樣，應用程式的流量幾乎從未在一天或一周内保持一緻，并且絕大多數應用程式在一段時間内負載不均衡。每個應用程式都有低谷，在這些低谷中，它不會處理許多使用者請求或處理資料，并且有峰值，在這些峰值中，應用程式使用率非常高。隻要應用程式的執行個體沒有被推到應用程式出現問題的程度，這些峰值就沒有問題，例如：
- 響應延遲異常長，無法滿足服務級别協定 (SLA)。
- 記憶體過度使用會導緻 Java 虛拟機 (JVM) 中的垃圾收集器 (GC) 抖動。
- 資源不足（CPU 線程、檔案/網絡句柄）會導緻拒絕傳入請求，無法進行處理。
最後兩個問題會導緻應用程式完全無響應，看起來好像沒有進行任何處理。在測試期間，開發人員會注意到此上限，并調整應用程式執行個體所需的 CPU 核心和記憶體數量。然後，他們會添加通常是任意數量的 CPU 和記憶體，以适應峰值——過度配置應用程式的可用資源。過度配置是開發團隊的安全網，以確定一切順利運作，使用者對響應時間感到滿意。
但是，過度配置會給運作應用程式增加大量成本。運作中的雲 VM 通常具有固定的 CPU（核心或虛拟 CPU）和記憶體，并且不被認為是彈性的。這意味着您正在為已配置的容量付費，無論您是否完全利用它。這種額外的空間可能占您配置的雲計算的 5% 到 50%，具體取決于開發團隊認為需要多少額外容量來适應峰值。
為了幫助您處理過度配置并節省雲支出，您可以使用某些政策，具體取決于您是進行垂直擴充還是水準擴充。我将描述這兩種擴充模型以及每種模型的政策。無論您是在雲中運作還是在本地運作，都可以使用這些政策和技術。
垂直擴充
垂直擴充是擴充應用程式以處理更多負載的更簡單的政策，但它不如水準擴充靈活。垂直擴充意味着在實體或虛拟伺服器上為應用程式添加更多 CPU 核心和更多記憶體（或者如果您的應用程式是 I/O 密集型，則添加更快或更多 SSD 存儲）。更改這些内容需要停止并重新啟動應用程式，這會造成中斷。但是，有一種方法可以減少這種類型的擴充的過度配置。
更好的負載測試和估算
性能測試被認為是最困難的測試類型——它需要深入了解 整個 應用程式和所有連接配接的服務。設定性能測試環境需要大量工作，并且使其與生産環境的特征保持一緻也是一項挑戰。生成模拟生産的負載以及擁有應用程式資料（生産資料的規模和形狀）都需要思考和努力才能做到正确。
是以，開發團隊經常會做出一些假設并采取一些捷徑。這很好，但會導緻高估和過度配置應用程式生産執行個體的大小。
開發人員可以做些什麼來獲得更好的性能資料，以便正确調整其 Java 應用程式的大小？以下是可以執行的三項主要操作，以确定應用程式的峰值容量需求。
1. 測量伺服器和 JVM 的 CPU 和記憶體使用率
通常，開發人員隻關注伺服器（或虛拟機）的 CPU 和記憶體使用情況，以确定處理峰值負載所需的 CPU 和記憶體數量。使用在 JVM 内監控這些内容的工具将有助于将這些設定在正确的級别：
- JVM GC 監控：這可以幫助檢測記憶體不足，這會導緻高 CPU 使用率，因為 JVM 會陷入 GC 垃圾場景。這也有助于檢測配置設定了太多記憶體的情況，進而導緻長時間的 GC 暫停，進而導緻比預期更長的延遲。減少不必要的記憶體也可以節省資金。
- JVM 線程監控：這可以幫助檢測何時 CPU 不足，這會導緻響應時間過長或無響應。這可以幫助檢測太多空閑線程，通過減少配置設定的核心數量，您也可以節省資金。
2. 新的 JVM 版本比舊版本提供更好的性能
在我們從 JDK 11 到 17 到 21 的測試中，我們看到 JVM 的每次釋出都提高了 CPU 使用率。當然，您的應用程式代碼可能需要一些調整，尤其是在您的應用程式基于比 Java 11 更早的版本的情況下。
還有一些不同的 GC 算法可以讓您從雲虛拟機中獲得更高的效率；但是，這高度依賴于您的應用程式的記憶體使用情況。例如，進行大量資料處理和轉換的應用程式将具有與 RESTful 應用程式不同的 GC 配置檔案。您可以檢視 Azul 部落格的 GC 部分 以擷取更多資訊。
3. 了解 JVM 的工作原理
下圖顯示了典型 Java 應用程式從 JVM 啟動到随時間推移執行的方式。啟動時 CPU 使用率很高；這是 JVM 啟動、加載類等。然後您的應用程式架構（例如 Spring Boot）啟動、初始化并進入“準備服務請求”狀态。
請注意峰值上方的線，它顯示了此應用程式的 VM 部署的 CPU 過度配置程度（用于突發高負載的安全網）。随着 JVM 的即時 (JIT) 編譯器優化代碼路徑，應用程式變得 更 效率 - 它使用更少的 CPU 來服務相同數量的負載。最終發生的是，在您為應用程式提供的額外空間之上，JVM 由于 JIT 編譯器優化而達到更低的 CPU 使用率基線。是以，過度配置的量會增加！這意味着您現在在配置設定的 CPU 中有更多浪費 - 并且有機會節省更多資金。
使用高性能 JVM 意味着您可以減少（或完全消除）過度配置。了解此曲線及其對應用程式的影響可以幫助您減少為應用程式的 VM 執行個體配置設定的安全網。如果您知道長尾峰值将在哪裡，就可以降低頂線（“過度配置”），您将能夠配置設定更少的 CPU 核心并節省雲支出。
水準擴充
多年來，彈性計算一直被吹捧為可擴充應用程式開發的聖杯，而水準擴充是彈性計算的基礎。水準擴充意味着通過添加更多伺服器（具有自己的 CPU 和記憶體）來為應用程式添加容量，而不是向現有伺服器添加更多 CPU 核心和記憶體。
但是，水準擴充比垂直擴充更複雜，需要更多規劃和更多外部（對應用程式）設定。并且它不如垂直擴充效率高，因為您必須引入路由層，這意味着更多處理和網絡開銷。
在 Java 應用程式的水準擴充部署中減少過度配置是通過根據需要添加和删除容量來完成的，通常以自動方式檢測負載并啟動或關閉應用程式節點執行個體。是以，您将擁有一些過度配置的容量，但數量很少，持續時間很短（取決于您的配置方式）。
減少應用程式的大小
随着我們從将應用程式建構為單體應用程式轉變為微服務（甚至更小的雲函數），我們使應用程式越來越小。這些不同架構有優點和權衡，但在應用程式的 雲成本優化 的背景下，特别是使用水準擴充來獲得彈性計算更小（或小到中等規模）是最好的。
減少應用程式大小會減少您需要配置設定給應用程式每個執行個體的 CPU 和記憶體量。這允許更增量式的擴充和更有效地使用資源，進而意味着對雲成本的更細粒度控制。部署單元越小，您在擴充和縮減時支付的費用就越多（或更少）。當然，這隻有在您使用自動擴充時才有可能。
使用自動縮放
自動縮放是指應用程式根據負載增加或減少添加或删除應用程式執行個體節點的能力。在雲成本優化方面，我們更感興趣的是更積極地縮減規模，或者停止應用程式執行個體節點。根據您用于建構應用程式叢集的環境，您将獲得不同的自動縮放選項。最流行的自動縮放平台是 Kubernetes，它支援自動縮放。 Kubernetes 的主要權衡是它為标準的固定分布式叢集部署引入了高度的複雜性。
Kubernetes 的更簡單替代方案是容器即服務 (CaaS)，例如 AWS Fargate、Google Cloud Run 或 Microsoft Azure 容器。這些部署服務提供了一種更輕松的方式來部署您的應用程式。您将應用程式（在一個 Docker 容器中）提供給服務，它會處理向上和向下自動縮放。CaaS 解決方案的權衡是它們的成本比标準 VM 更高，可能比托管 Kubernetes 部署更高。
結論
減少過度配置可以幫助您節省雲成本。最終，您可以實作什麼在很大程度上取決于您的應用程式及其性能配置檔案。了解應用程式啟動和運作時發生的情況對于您使用哪種政策來減少過度配置都很有用。了解 Java 應用程式的 CPU 和記憶體配置檔案将有助于您了解應用程式在運作時的性能。
考慮使用更有效的高性能 JVM，例如 Azul Platform Prime，用于小型到大型 Java 應用程式部署。Azul Platform Prime：
- 由于其先進的 C4 GC、低級優化和先進的 Falcon JIT 編譯器，它比其他 JVM 更好地處理峰值負載。
- 可以使用 ReadyNow 避免 JIT 爬坡（以及高 JIT CPU 使用率）。
- 由于它處理峰值負載的方式，它在負載下提供更低的延遲，同時處理更高的峰值。
要了解更多資訊，請下載下傳 IDC 關于 優化 Java 應用程式性能以提高業務成果和雲成本效率 的白皮書。