對於在 Kubernetes 上運行 Java 應用程式的團隊而言，裝箱 (Bin Packing) 效率不佳，問題通常不在於資源容量不足，而是在於缺乏信心。

什麼是裝箱 (Bin Packing)？裝箱是一種排程策略，旨在最大化單一節點的資源使用率，以便用最少數量的節點來運行相同數量的 Pod 。

由於團隊無法準確預測 JVM 在資源使用率提高時的執行行為，因此往往採取較為保守的資源配置策略，導致大量昂貴的運算資源閒置在整個 Kubernetes 叢集中。

本文將說明，為什麼裝箱不僅是排程問題，同時也是 Runtime 預測的問題 。若能讓 Java 執行行為更加一致且可預測，團隊便能安心提高工作負載密度，在維持穩定性的同時降低雲端成本。

本文將帶您了解：

• 為何 Java 團隊會過度配置資源，以及保守的資源配置策略如何讓原本小幅的安全緩衝，轉變為實際的基礎架構成本
• 為何裝箱是Runtime可預測性的問題，而非排程器（Scheduler）的問題
• Azul Prime 的 C4、ReadyNow 與 Falcon 技術如何提升 Java 在高負載下的執行可預測性
• 實際案例：企業將資源使用率從 17% 提升至 35% 後，最終獲得了哪些效益
• 應追蹤哪些指標才能安全地提升資源使用率，如延遲、GC 行為、CPU 使用率與部署密度

每個 Kubernetes 叢集其實都有兩個「資源使用率」：一個是排程器（Scheduler）所看到的使用率，另一個則是團隊「願意」實際使用的使用率。對於 Java 工作負載而言，這兩者之間幾乎總會存在一段落差，而這段落差帶來的成本，往往比你想像得更高。

從技術層面來看，裝箱是指盡可能將工作負載有效配置到各個節點上，在不影響系統穩定性與效能的前提下，充分利用現有的 CPU 與記憶體資源。

從營運成本層面來看，裝箱則是讓已投入的基礎架構發揮更高的運作效率，減少資源閒置，並有效控制雲端支出。

從帳面數據看，Kubernetes 叢集的資源使用率可能偏低，排程器也顯示節點還有充足的可用空間，但實際維運人員知道，不能只憑這些數據就貿然下判斷。

對於 Java 工作負載而言，團隊在規劃資源配置時，通常會預留一段看不見的緩衝空間，以因應延遲尖峰、垃圾回收（GC）行為、Heap 壓力、編譯活動，以及隨著資源使用率逐漸提高而出現的各種不可預測因素。

這層額外的緩衝能讓團隊更加安心，但代價也隨之而來：工作負載的資源配置是以最壞情況為基準，而非日常營運需求；叢集的資源使用率低於應有水準；Pod 部署密度也維持在比實際需求更低的水平。最終結果就是，企業花費大量成本維持的基礎架構，更像是一份保險，而非真正發揮生產力的運算資源。當這種情況累積到足夠多的服務時，所造成的成本浪費就相當可觀。

對於 Java 工作負載而言，裝箱不只是基礎架構層面的問題，同時也是Runtime層面的問題。如果團隊無法信任 JVM 在資源使用率逐漸提高時的執行表現，就會採取保守的資源配置策略、預留更多資源餘裕，並接受低於理想的部署密度。然而，當 JVM 的執行行為變得更加可預測時，情況就會有所改變。團隊可以開始減少這些額外的資源緩衝，並讓工作負載更接近已投入資源的實際容量運行。

為何 Java 工作負載經常出現過度配置？

如果長期觀察正式環境中的 Java 應用程式，就會發現一個共同現象：採取保守的資源配置策略幾乎已成為常態。即使平均 CPU 和記憶體使用率看起來相當合理，團隊仍會預留大量額外資源。原因在於，他們並不是依據日常平均的執行情況來配置資源，而是以系統出現異常狀況時的需求作為配置基準。

而對於 Java 而言，這種思維其實有充分的理由。垃圾回收（GC）暫停就是最明顯的原因之一；Heap 使用率可能在高負載下迅速攀升；JIT 編譯活動也可能在不恰當的時機發生；隨著資源使用率提高，延遲通常也會變得更加敏感。再加上共享基礎架構、鄰近工作負載（Noisy Neighbor）干擾、突發流量，以及公有雲環境中的 Spot Instance 和節點層級資源競爭等因素，就不難理解為什麼團隊會傾向採取較為保守的資源配置策略。

因此 Kubernetes 的 Resource Requests 與 Limits 往往反映的是團隊的謹慎態度，而非工作負載在穩定運行時的實際需求。一個 Pod 在大多數時間或許根本不需要這麼多的資源餘裕，但團隊仍然會保留這些緩衝，因為他們不想成為第一個發現安全餘裕消失後會發生什麼事的人。久而久之，過度配置便成了常態。這不是因為團隊懶惰，也不是資源估算錯誤，而更多是過去實際經驗所帶來的結果。

閒置資源的累積效應

保守的資源配置策略所帶來的問題，在於成本並不會只侷限於單一 Pod。每個 Pod 多預留一點 CPU、再多預留一點記憶體，當這些額外資源分散到數十甚至數百個服務時，就會對整體環境的資源配置與營運成本產生相當顯著的影響。

每個節點可部署的 Pod 數量因此減少，導致需要配置比實際需求更多的節點。叢集整體效率下降、雲端支出持續增加，而原本看似合理的單一服務安全餘裕，在大規模部署下，最終會演變成一筆可觀的營運成本。這也是為什麼平台團隊與 FinOps 如此重視資源使用率：一旦過度配置成為整個環境的普遍現象，即使幅度不大，也會迅速累積成高昂的成本。

比較容易被忽略的是，團隊通常並不是在某個明顯的位置浪費大量容量，而是在各處分散地留下少量閒置資源。當足夠多的工作負載都是以謹慎而非實際穩定需求來進行資源配置時，這些累積起來的整體效應就會變得難以忽視。

是排程器的問題，還是資源配置的問題？

這看起來可能像是排程器（scheduler）的問題，但其實並不是。排程器只能依據所收到的資源 requests 與 limits 來進行工作負載的配置。如果團隊採取保守的資源配置策略，Kubernetes 的排程結果自然也會同樣保守。換句話說，排程器並不是限制因素，它只是反映了已經被寫入輸入條件中的謹慎程度。

真正限制節點密度的，其實是團隊的信心。當工程師不確定 Java 工作負載在資源使用率升高時會如何表現，他們就會透過預留更多資源餘裕來做補償。這種謹慎會在 scheduler 做出任何放置決策之前，就先反映在 requests 與 limits 的設定中。

這也意味著，這其實是一個可預測性（predictability）問題。如果 runtime 在高壓情況下表現得更加一致，團隊就能開始減少這些防禦性的資源預留，降低不必要的安全空間，並在不產生焦慮的情況下，以更高的密度運行工作負載。

高效能 JVM 如何提升工作負載密度？

團隊通常會透過仔細調整 GC、進行容器資源盤點，或採用不同的 JVM 發行版本來應對這個問題，但最大的效益其實來自於直接改善runtime的可預測性。

這正是高效能 Java 平台 Azul Prime 能夠改變局面的地方。Azul Prime 是一款建立在三項核心技術之上的 JVM，旨在讓 Java 在真實生產負載下的行為更加一致，特別是在那些導致保守資源配置的關鍵領域：垃圾回收、應用程式暖機（warm-up）以及最佳化機械碼。

• C4 是 Prime 的並行垃圾回收器，透過並行技術執行回收來降低暫停（pause, STW現象）所造成的不可預測性，並在資源使用率提升時減少延遲尖峰的風險。
• ReadyNow 是 Prime 的暖機最佳化技術（warm-up optimizer），可讓應用程式在啟動、重啟或重新部署後，更快達到最佳化效能，降低暖機成本，避免新實例與長時間運行實例之間出現行為差異。
• Falcon 是 Prime 基於 LLVM 的最佳化 JIT 編譯器（optimizing JIT compiler），能生成高度最佳化的機器碼，有效以提升整體吞吐量與 CPU 使用效率。

這直接改善 Bin Packing 的異常事件，減少難以建模的中斷，意味著團隊能更有信心地評估 CPU、記憶體與延遲行為。他們可以在持續確保服務等級目標（SLO）的前提下，測試更高的資源使用率，而不需要再額外預留「以防萬一」的資源餘裕。

目標本身並不是單純追求效能，而是建立信心。對平台與基礎架構團隊而言，其價值在於營運層面：C4 降低了使團隊採取保守配置的抖動（jitter），而 Falcon 則提升了在 CPU 上執行程式碼的效率。兩者結合，為團隊提供更穩固的基礎，使運行行為與狀態高度可預測，進而提升資源使用率、減少防禦性的過度配置，並在既有基礎架構上更安全地承載更多工作負載。

圖 1：深藍色為 Prime的執行吞吐，淺藍、淺綠為其他傳統JDK的運行吞吐。箭頭顯示每項 Azul Prime 技術如何隨時間影響效能表現。ReadyNow 的箭頭指向曲線的前段，表示先前收集的最佳化資料可協助應用程式在啟動後更快達到較高效能，深藍色區段無需太多啟動階段，馬上權力運行。

C4 的箭頭從曲線的較低區段向上指，表示並行垃圾回收（concurrent garbage collection）可在整個執行期間維持穩定且一致的應用程式效能。淡藍色的凹陷為一般 JDK 執行 GC 時的暫停，而Prime完全沒有暫停。

Falcon 的箭頭則指向曲線的後段與高位區域，表示持續的 JIT 編譯可產生更高度最佳化的機器碼，並推動應用程式逐步達到最佳的穩態效能表現。因此深藍色的基礎效能表現便高於淺藍色。

現在，讓我們來看一個大型企業目前正在使用 Azul Prime 進行的實際案例。

某位客戶在非常大的節點上，以 17% 的資源使用率運行 Cassandra 容器。該環境並非基於 Kubernetes，但 Bin Packing 問題本質相同：每個節點都運行多個容器化的 Java 工作負載，而業務希望在不犧牲應用穩定性與營運信心的前提下提升資源使用率。

這個 17% 並不是容量限制，而是信心限制。當 Java 工作負載被推得更高時，團隊必須承受更高的不確定性與風險，包括延遲、GC 行為以及執行時變異性。因此，他們選擇以謹慎的方式進行資源配置。

他們的長期目標是將資源使用率提升至 35%。從 17% 提升到 35% 並不是一個小幅的調整，而是每個實例能安全承載的有效工作量的根本性改變。在沒有調整執行時行為的情況下，這樣的提升會顯得相當冒險，因為一旦判斷錯誤，其代價會直接反映在正式環境中，例如延遲飆升、SLA 無法達成，以及緊急回滾。

Azul Prime 透過降低 JVM 層級的不可預測性，改變了原本導致團隊保守配置的討論基礎。藉由 C4 提供更穩定且可預測的垃圾回收行為，團隊可以在測試更高資源使用率時，不必擔心暫停行為會突然主導尾端延遲。這並不代表所有工作負載都能在一夜之間翻倍，也不代表可以忽略必要的量測。但它確實讓客戶擁有一條更具可信度的路徑，在不進行大規模程式碼重構或架構調整的情況下，更積極地提升單一實例的負載能力。

更大的機會是整體時程的縮短。該客戶原本需要兩到三年才能達成約 35% 的資源使用率目標，如今可能在更短時間內實現。從 17% 提升到 35%，實質上等於讓每個容器承載的有效工作量翻倍，也就是能用大約一半的實例來運行相同的工作負載。在企業規模下，這會直接轉化為更少的節點、更低的雲端支出，以及更小的整體營運足跡，而且無需進行大規模的架構重構。這也讓執行時的可預測性，轉化為基礎架構層面的槓桿效應。

團隊應該衡量什麼？

如果目標是安全地提高資源使用率，團隊需要衡量的就不只是平均資源消耗。CPU 與記憶體固然重要，但單靠這些指標無法呈現全貌。真正關鍵的是，隨著壓力上升，工作負載的行為如何變化，以及它是否仍能在更接近資源上限的情況下滿足服務期望。

關鍵在於以能建立信心的方式進行測量。問題不僅是是否可以提高資源使用率，而是能否在安全、可預測且不引入新的營運風險的情況下提高。

以實際情境配置，而非最壞情況

對許多 Java 團隊而言，糟糕的裝箱並不真正源自於基礎設施容量不足，而是缺乏信心。當營運人員不確定工作負載在資源使用率上升時會如何表現，他們會採取任何合理團隊都會做的做法：預留額外安全空間、以保守方式配置資源，並以降低密度來換取穩定性。

問題在於，這種謹慎並不是沒有成本的。它會以閒置容量（stranded capacity）、較低的容器密度、更多不必要的節點數量，以及最終高於預期的雲端支出形式呈現。在足夠多的服務規模下，這些微小的安全餘裕會逐漸累積成一種實質的成本負擔。

若對 Azul 有興趣歡迎留下資訊，將會有專人與您聯繫 ➤ https://www.gss.com.tw/product-services-nav/info-security/azul