> [!abstract] 概要(Abstract 日本語訳) > クラウドプロバイダは、テナントが購入するリソース量と実際にワークロードが消費するリソース量との間の大きな乖離を利用し、収益性を最大化するためにオーバーサブスクリプション戦略を一般的に採用している。しかし、ワークロードの時間的揮発性(temporal volatility)は、オーバーサブスクリプションされたノードでの過負荷を引き起こす可能性がある。この課題に対処するため、既存研究の多くは過負荷イベントによって起動される反応的な再スケジューリング機構の設計に注力するか、過負荷リスクを緩和するために保守的なオーバーサブスクリプション戦略を採用している。しかしながら、これらの解決策はテナント体験かプロバイダの収益性のいずれかを犠牲にする。実際には、ワークロードの時間的揮発性を低減することが、上記の課題に対処する鍵である。我々は、多くのワークロードが時間的相補性(temporal complementarity)を示すことを観察した。そのようなワークロードを集約することで時間的揮発性を効果的に緩和し、全体のリソース使用率を改善できる。この知見に動機付けられ、我々はまずワークロードの時間的揮発性を定量化する新しい指標、Maximum-based Coefficient of Variation(MCV)を設計する。次に、ワークロード集約を通じて長期的に安定したオーバーサブスクリプションを実現するフレームワーク、Hestiaを提案する。具体的には、周期性に応じて集約に適したワークロードを分類する平滑化ベースの手法を提案する。続いて、全体のMCVを最小化する集約アルゴリズムを設計し、集約されたワークロードをオーバーサブスクリプションの単位として扱う。実験結果は、CPUを代表的な例として用いた場合、HestiaがMCVを43.3%削減し、オーバーサブスクリプション利益を66.74%増加させることを示す。 ## 論文情報 - タイトル: Rethinking Cloud Optimization: Volatility-Driven for Better Outcomes - 著者: Baoqing Wang, Gongming Zhao, Hongli Xu, Shibo Wu, Zhuolong Yu, Jiawei Liu, Junhong Lu, Shaohui Xu, Fanjie Meng - 所属: [[University of Science and Technology of China]](School of Computer Science and Technology, Suzhou Institute for Advanced Research)、[[Tencent]] Cloud - 媒体: ACM SIGCOMM 2026 Conference(SIGCOMM '26)、2026年8月17日〜21日、Denver, CO, USA。14ページ(pp. 491–504) - DOI: [https://doi.org/10.1145/3789240.3829141](https://doi.org/10.1145/3789240.3829141) - ACM ISBN: 979-8-4007-2467-1/26/08 - Ethics欄: 「本論文は倫理的問題を提起しない」と明記(Source: 論文9章末尾) ## 概要 Hestiaは、クラウドのオーバーサブスクリプション(過剰申込)戦略の実効性を左右する根本要因が「ワークロードの時間的揮発性」であるという観察に基づき、時間的に相補的な複数ワークロードを空間的に集約(aggregation)することで揮発性を低減し、より積極的かつ安全なオーバーサブスクリプションを実現するフレームワークである。Classifier・Aggregator・Allocator・Schedulerの4モジュールから構成され、[[Tencent]] Cloudの本番環境に実際にデプロイされている(Source: 論文Fig.4、§3.1)。 ## 問題設定 クラウド事業者は、テナントが購入したリソースのうち実際に使用される割合が低いこと(Microsoft Azureの分析でノードの60%超がCPU使用率20%未満)を利用してオーバーサブスクリプションを行う。しかし、ワークロードのリソース使用量は時間的に大きく変動するため、過度なオーバーサブスクリプションはノード過負荷を招く。既存アプローチは大きく2系統に分かれる。(1) 過負荷イベント発生後に反応的に再スケジューリングする方式は、検知・再配置の遅延とオーバーヘッドが避けられずワークロード性能を劣化させる。(2) [[Tencent]] Cloudの Crane のように、過去のピーク使用量に安全係数(1.2倍)を掛けて予約する保守的方式は、ピークと平均の乖離が大きいワークロードほどオーバーサブスクリプション可能な余地を狭める(Source: 論文§1)。 著者らはAlibaba-trace-v2018・v2022の実データを用い、Craneのオーバーサブスクリプション戦略下でのCPU利用率とワークロードのCV(Coefficient of Variation、標準偏差÷平均)の関係を分析した。 **Figure 1: CVとCPU利用率の関係(Alibaba-trace-v2018/v2022)** ![[_attachments/3789240.3829141/fig01-cpu-util-vs-cv.png]] (Figure 1. 各点は1ワークロードを表し、CVが小さいワークロードほどCPU利用率が高い。v2022ではCVが2から0.2に下がるとCPU利用率が10.4%から61.7%に上昇する。Source: 論文Fig.1、§1) この観察から、ワークロードの時間的揮発性を低減することがオーバーサブスクリプション最適化の鍵であるという着想を得た。個々のワークロードの揮発性自体は変えられないが、時間的にずれた(temporally staggered)ワークロード群を空間的に集約すれば、集約後の揮発性を緩和できる(例: 日中にトラフィックが多い会議・オフィス業務系ワークロードと、夜間にピークを迎えるライブ配信・オンラインゲーム系ワークロードの組み合わせ)。 **Figure 2: 本番トレースから見るワークロードの特性と最適化機会** ![[_attachments/3789240.3829141/fig02-workload-characteristics.png]] (Figure 2. (a) Alibaba-trace-v2018/v2022と自社収集のTencent-trace-v2025のいずれも、ワークロードの実行時間は175〜225時間超が7〜8割を占める長時間稼働型が主体。(b) CPU・ディスクI/O・ネットワークの平均利用率はそれぞれ約40%・10%・45%と恒常的に低い。(c) FFTによる周期性分析では多くのワークロードが約1日を支配的周期として持つ。(d) 時間的にずれた2つのワークロードを集約すると揮発性が明確に緩和される例。Source: 論文Fig.2、§2.1) ### MCV指標の設計 温度計量として広く使われるCV(標準偏差÷平均)は平均を基準とした揺らぎを捉えるが、オーバーサブスクリプションが問題とするのはピーク使用量である。そこで著者らは最大値基準の変動係数 **Maximum-based Coefficient of Variation(MCV)** を新設した。 $\mathrm{MCV}(x) = \sqrt{\frac{1}{N}\sum_{i=1}^{N}\left(\frac{\mathrm{Max}(x) - x_i}{\mathrm{Max}(x)}\right)^2}$ ($x$はNタイムスタンプ分のリソース使用量のデータセット。式(1)) **Theorem 2.2(MCVの上下界)**: ワークロードの資源使用率 $U = \mu/A$($\mu$=平均使用量、$A$=割当量)を最大化するよう $A=M$(最大使用量)と設定すると、 $1 - U \le \mathrm{MCV}(x) \le \sqrt{1 - U}$ が成立する(Jensenの不等式に基づく証明。Source: 論文§2.2 Lemma 1、Theorem 2.2)。この理論的関係により、MCVは資源利用率とほぼ線形の関係を持つ。 **Figure 3: CPU利用率とMCVの関係** ![[_attachments/3789240.3829141/fig03-cpu-util-vs-mcv.png]] (Figure 3. Figure 1のCVをMCVに置き換えると、上下界(Theorem 2.2)の間にほぼ線形に分布することが確認できる。Source: 論文Fig.3、§2.2) ### 課題 1. **集約に適したワークロードの識別**(Challenge 1、§2.3.1): 周期性検知は突発的なバーストにより精度が落ちやすく、既存手法(STL分解等)は数十万ワークロード規模では計算コストが過大。 2. **時間的相補性を用いた集約**(Challenge 2、§2.3.2): ノード容量制約下での集約はバランス分割問題(NP困難)に帰着する。 3. **集約後ワークロードのオーバーサブスクリプション**(Challenge 3、§2.3.3): 積極的すぎるとSLA違反による違約金・信頼失墜を招き、保守的すぎると資源が遊休化する。 ## 提案手法 ### アーキテクチャ Hestiaは Classifier(ワークロード識別)・Aggregator(空間集約)・Allocator(資源割当)・Scheduler(配置)の4モジュールで構成される。 **Figure 4: Hestiaの全体構成とワークフロー** ![[_attachments/3789240.3829141/fig04-hestia-architecture.png]] (Figure 4. Monitorがワークロード・物理ホストのOSレベル指標を継続収集しDatabaseへ格納する。ワークロード構成の変化(新規LPW遷移数)が事業者設定の閾値(本番環境では3000)を超えるとHestiaが起動する。ワークフローは a Monitor→Classifier への情報転送、b Classifierによる周期性分析とLPW/LNPWラベリング、c AggregatorによるWorkload Group(WG)構築、d AllocatorによるWGへの資源割当、e Schedulerによる配置、の順に進む。SW/LPW/LNPWの状態遷移はまず論理更新であり、実際の再配置はin-placeなpod resizeを優先し、不足時のみmigrationを行う。Source: 論文Fig.4、§3.1–3.2) 新規ワークロードはまずShort-term Workload(SW)として保守的に扱われ、72時間の観測窓を超えるとClassifierが周期性を評価してLong-term Periodic Workload(LPW)またはLong-term Non-Periodic Workload(LNPW)に分類する。LPWのみがAggregatorによる集約対象となる。 ### Classifier設計(周期性識別) STL分解は計算コストが高く大規模環境では非実用的なため、著者らはLOESS平滑化とACF(自己相関関数)を組み合わせた軽量な周期性信頼度スコア Periodicity Confidence Score(PCS)を設計した。 生の観測系列 $R(t)$ をLOESS平滑化して $\hat{R}(t)$ を得て(局所加重一次回帰、tricube重み。式(4))、残差 $r(t) = R(t) - \hat{R}(t)$ のノイズ強度を正規化残差分散 $N_{var} = \mathrm{Var}(r(t))/\mathrm{Var}(R(t))$ で測る。周期ラグ $p$ における自己相関 $\mathrm{ACF}(p)$(式5)とあわせ、 $\mathrm{PCS} = \frac{|\mathrm{ACF}(p)|}{|\mathrm{ACF}(p)| + N_{var} + \varepsilon}$ (式6、$\varepsilon$は数値安定化のための微小定数、例: $10^{-6}$)と定義する。PCS閾値は利益駆動で決定し、実験(§7.2.1)に基づき **Threshold = 0.4** に設定した。 **Figure 5: Classifierのワークフロー** ![[_attachments/3789240.3829141/fig05-classifier-workflow.png]] (Figure 5. SWの実行時間が72時間(本番クラスタでの設定値)を超えると、平滑化後の履歴使用量から計算したPCS値によりLNPWまたはLPWに分類する。LPW⇄LNPW間の状態遷移は事象駆動: 過負荷/SLA違反が起きると即座にLPW→LNPWへ降格し、フラッピング防止のためLNPW→LPWへの昇格には連続2回のPCS閾値超過(基準間隔 $\tau_0$、バックオフ上限 $\tau_{max}$)を要求する。Source: 論文Fig.5、§4.2) ### Aggregator設計(集約アルゴリズム) ワークロード集約問題は、$k$ グループへの分割 $G=\{g_1,...,g_k\}$ の下で各グループの容量制約 $\sum_{w\in W} x_w^g \cdot R_t^w \le C_g$ を満たしつつ、全体のMCVを最小化するバランス分割問題として定式化される(式7)。 $\min_{G} \sum_{g \in G} |g| \cdot \mathrm{MCV}(R_g)$ ここで $|g|$ はグループサイズによるスケーリング係数であり、これがないとグループ数減少だけで目的値が下がってしまう(正規化項数が減るため)問題を防ぐ(Source: 論文§5.1)。 **Algorithm 1(DWA: Density-based Workload Aggregation)**: 各ワークロード $w$ の密度 $\rho_w = \sum_{t \in T} R_t^w / \max_t R_t^w$(総使用量をピークで正規化した値)を計算し、$\rho_w$ 降順にソートして貪欲に配置する。各ワークロードについて、容量制約を満たしかつMCV増分利得 $(|g|+1)\cdot\mathrm{MCV}(g\cup\{w\}) - |g|\cdot\mathrm{MCV}(g) - \mathrm{MCV}(w)$ が最も負(最も改善が大きい)グループへ割り当てる。改善するグループがなければ新規シングルトングループを作る(Source: 論文Algorithm 1、§5.2)。 密度スコア $\rho_w$ の設計はMCV上界の理論(Appendix A.1)に直接動機づけられる: $\mu_w/M_w = \rho_w/|T|$ であり、$\rho_w$ が大きいワークロードほど「尖っていない」(スパイクの少ない)トレースであり、揮発性の理論的上界が締まる。 DWAの結果は任意選択の **Algorithm 2(LSR: Local Search Refinement)** でさらに精緻化できる。LSRは各ワークロードを別グループへ移すことで全体MCVが厳密に改善する限り移動を繰り返す局所探索であり、収束するまで(または改善が見つからなくなるまで)実行する。 **Figure 6: 集約段階ごとの平均MCV収束傾向** ![[_attachments/3789240.3829141/fig06-mcv-convergence.png]] (Figure 6. Rawの平均MCV 0.81から、DWA適用で0.51まで低下し、LSRを収束まで実行するとさらに0.46まで改善する。DWAが揮発性低減の大部分を低遅延で達成し、LSRは追加の計算コストに対して逓減する改善しかもたらさないというトレードオフを示す。このためHestiaは遅延に敏感なオンライン処理ではDWA単独を使い、制御プレーンに余裕がある場合のみLSRをオフライン/低優先度バックグラウンドタスクとして併用する。Source: 論文Fig.6、§5.2) ### Allocator設計(SLA考慮型資源割当) AllocatorはSLA違反とテールリスクを明示的に増幅して扱う学習ベースの予測器である。過去窓 $\mathcal{P}$ と未来窓 $\mathcal{F}$ に分割し、対数スケールの $p$ パーセンタイル使用率 $y_g^{\mathcal{T}} = \log(\mathrm{perc}_p\{R_g(t)\}_{t\in\mathcal{T}} / (Req_g+\epsilon))$(式10)を定義、過去→未来のドリフト $\Delta_g(p) = y_g^{\mathcal{F}} - y_g^{\mathcal{P}}$(式11、教師信号)を6次元特徴量 $\mathbf{x}_g \triangleq (\mathrm{MCV}_g^{\mathcal{P}}, \mathrm{PCS}_g^{\mathcal{P}}, y_g^{\mathcal{P}}, \eta_g^{\mathcal{P}}, \gamma_g^{\mathcal{P}}, \kappa_g^{\mathcal{P}})$(MCV・PCS・percentile利用率・ピーク利用率・歪度・尖度、式13)から軽量フィードフォワードネットワーク $f_\theta: \mathbb{R}^6 \to \mathbb{R}$ で予測する(式15)。 **Figure 7: 典型的なSLAサービスクレジットと利益-違反トレードオフ** ![[_attachments/3789240.3829141/fig07-sla-service-credits.png]] (Figure 7. 可用性水準(99.975%–99%/99%–95%/95%未満)ごとにサービスクレジット(料金の10%/25%/100%)が定まる典型的SLA構造。Hestia→オーバーサブスクリプション→SLA違反→利益という因果連鎖を示す。Source: 論文Fig.7、§6.1) 学習目的は非対称二乗損失である。予測誤差 $e_g \triangleq \widehat{\Delta_g(p)} - \Delta_g(p)$ に対し、 $\mathcal{L}(\theta) \triangleq \frac{1}{|\mathcal{G}|}\sum_{g\in\mathcal{G}} \left[ \lambda_- \mathbb{I}\{e_g<0\} e_g^2 + \lambda_+ \mathbb{I}\{e_g\ge0\} e_g^2 \right]$ (式17)とし、$\lambda_- \gg \lambda_+$ として過小配分(過負荷・SLA違反リスクを高める負の誤差)をより重く罰する。過大配分は利益を減らすのみで安全側に働くため軽く罰する。 **Figure 8: $(\lambda_-, \lambda_+)$設定ごとの利益** ![[_attachments/3789240.3829141/fig08-profit-lambda-settings.png]] (Figure 8. (a) $\lambda_-$と$\lambda_+$のグリッドサーチによる利益ヒートマップは、広い範囲で81%–81.7%とほぼ一定を保つ。(b) 比率 $\lambda_-/\lambda_+$ でまとめると、$\lambda_-/\lambda_+ \approx 2\times10^3$ 付近で最大利益81.7%のピークを持つなだらかな高原状の曲線となる。絶対値ではなく比率が支配的要因であるため、以降の実験では $\lambda_-/\lambda_+ = 2000$ に固定した。Source: 論文Fig.8、§6.2) ## 新規性 既存の周期性検知手法(STL、Lomb–Scargle、Harmonic Regressionなど)は周期構造の検知自体を目的とし、オーバーサブスクリプション制御に直結する軽量かつ実行可能な信号を出すよう設計されていない。これに対しClassifierは、大規模展開向けに効率的なPCSスコアと経験的閾値で「安定した集約候補」と「リスクの高いワークロード」を分離する運用指向の設計である。 統計的多重化・co-location系の研究(Bubble-Up、Paragon、Quasar、Heracles等)は主に干渉を考慮した配置・資源マッチング・実行時分離に焦点を当てる。CompVMやTetrisなど相補的なワークロード/VM組み合わせを扱う研究もあるが、Aggregatorは生トレースを直接扱い、容量制約を明示的に強制し、全体MCVを直接最小化する点で目的が異なる。既存研究は「より良い co-location を見つける」ことを目指すのに対し、Aggregatorは「オーバーサブスクリプションにとってより安全な入力へワークロードの組み合わせを作り変える」ことを目指す(Source: 論文§8)。 オーバーサブスクリプション・資源推定の既存研究(Borg、Kubernetes、Resource Central、Bashir et al.、Autopilot、HAPPIES等)は、ワークロード揮発性を予測品質の副産物として間接的にしか扱わない。これに対しAllocatorは揮発性とテールリスクを安全なオーバーサブスクリプション水準を決定する第一級のシグナルとして明示的にモデル化する点が異なる。 フレームワークレベルでは、既存システムの多くは需要予測・配置・co-location・実行時資源制御のいずれか単一段階でのみ利用率を改善する。Hestiaはこれらの段階を「揮発性低減」という一貫した軸でつなぎ、予測可能なワークロードを識別→容量制約下で集約→揮発性考慮型ポリシーで割当、という一連の設計にしている点が新規性の核である(Source: 論文§8)。 ## 実験設定 - **環境**: Kubernetes(K8s)クラスタ、サーバ24台(各Intel® Xeon® Gold 6152 CPU×2、論理コア計88、RAM 256GB、Ubuntu 22.04 LTS、Python 3.9)。20台をワークロードホスト、2台をHestia制御ロジック・トレース処理・オフライン分析専用、残り2台を弾性資源プール(バーストストレステスト用)として使用(Source: 論文§7.1.1)。 - **データセット**: - Alibaba-trace-v2018: 4,000台超のノード、8日間、70,000ワークロード超、総容量約170GB - Alibaba-trace-v2022: 1万ノード超、13日間、CPU・メモリ利用率を4万ノード超・47万ワークロード超について記録、総容量約2TB - Tencent-trace-v2025: [[Tencent]] Cloud本番環境61クラスタから収集した14日分のCPUトレース、約107万ワークロード、総容量136.72GB(著者ら自身が収集) - **前処理**: サンプリング間隔 $\tau$(既定5分)でリソース使用量系列を構築、$T$サンプル未満の短い系列は除外、不均一サンプリングのベースライン用には線形補間で均等サンプリング化。 - **主要指標**: オーバーサブスクリプション利益(式14)とSLA違反率(Source: 論文§7.1.3)。 ## 実験結果 ### Classifierマイクロベンチマーク(§7.2.1) ベースライン: FFT(Fourier peak detector)、Lomb–Scargle、Harmonic regression、K-Means(教師なし)。 **Figure 9・10・11: PCS閾値選定・分類時間オーバーヘッド・違反率と周期比率** ![[_attachments/3789240.3829141/fig09-profit-pcs-threshold.png]] (Figure 9. PCS閾値を掃引すると利益は単峰型で Threshold=0.4 で28.2%とピークを迎え、K-Means・FFT・Lomb–Scargle・Harmonicのいずれよりも高い。閾値0.2以下では周期労働の90%超が採用されるが違反率も増え、0.6では周期比率が10.4%まで縮小し集約機会が減る。Source: 論文Fig.9、§7.2.1) ![[_attachments/3789240.3829141/fig10-classifier-time-overhead.png]] (Figure 10. 50kワークロードでK-Means 45.8秒・Lomb–Scargle 36.3秒に対しClassifierは9.7秒。K-Means比4.7倍、Lomb–Scargle比3.7倍の高速化。FFT(7.8秒)・Harmonic(3.9秒)は絶対時間ではClassifierより速いが、分類精度を合わせて見ると精度-効率のトレードオフでClassifierが優位。Source: 論文Fig.10、§7.2.1) ![[_attachments/3789240.3829141/fig11-violation-periodic-ratio.png]] (Figure 11. ClassifierはSLA違反率9.7%を保ちつつ周期トレース識別率37.4%と最良のリスク-カバレッジトレードオフを達成。FFTは違反率72.1%と過度に許容的、Harmonicは違反率1.1%だが周期識別率1.7%と過度に保守的、K-Meansは29.2%識別・違反率14.9%の中間。Source: 論文Fig.11、§7.2.1) ### Aggregatorマイクロベンチマーク(§7.2.2) ベースライン: LB-Mean(平均負荷駆動のload balancing)、LB-Peak(ピーク駆動)、Optum[1]、CompVM[47]。 **Figure 12・13・14: 集約時間オーバーヘッド・グループ平均MCV分布・改善量CDF** ![[_attachments/3789240.3829141/fig12-aggregation-time-overhead.png]] (Figure 12. 50kワークロードでAggregatorは2.8秒と最速。CompVM 5.8秒、LB-Peak 22.1秒、Optum 35.9秒、LB-Mean(本文中では「LB-Volume」とも表記されているが図13の凡例と数値0.544が一致することから同一手法を指すと判断。後述の出典検査参照)259.5秒に対し、2.1〜92.7倍の高速化。Source: 論文Fig.12、§7.2.2) ![[_attachments/3789240.3829141/fig13-group-mean-mcv-dist.png]] (Figure 13. 生トレースの平均MCVは0.817。全ベースラインは0.51〜0.54程度まで低減する(LB-Peak 0.513、LB-Mean 0.544、Optum 0.516、CompVM 0.510)のに対し、Aggregatorは最低の0.463を達成し、生トレース比43.3%減・最良ベースライン比でもさらに9〜10%の追加改善。箱ひげ図は中央値の低さと分布の狭さも示す。Source: 論文Fig.13、§7.2.2) ![[_attachments/3789240.3829141/fig14-improvement-cdf.png]] (Figure 14. ワークロードごとの改善量(Initial−Final)のCDF。Aggregatorの曲線は右側に一貫してシフトしており、負の領域(劣化)にほとんど質量を置かない。ベースラインはゼロ付近に質量が集中し、負の領域にもわずかに広がる。Source: 論文Fig.14、§7.2.2) **Table 1: LPWに対する集約の効果(前半/後半でのMCV安定性)** | Experiment Scenario | MCV 1st Half | MCV 2nd Half | \|Δ\| | |---|---|---|---| | 10k LPW(個別) | 0.701 | 0.670 | 0.031 | | 10k LNPW(個別) | 0.799 | 0.750 | 0.049 | | 10k LPW(集約) | 0.456 | 0.454 | 0.002 | | 10k LNPW(集約) | 0.512 | 0.482 | 0.030 | | 5k LPW + 5k LNPW(集約) | 0.479 | 0.467 | 0.012 | (Table 1. トレース前半・後半で別々に計算したMCV。集約は個別実行に比べ一貫して揮発性を下げるが、効果は周期的ワークロード(LPW)で最大となる。10k LPWの集約では前半・後半差が0.002と最小で、時間的に極めて安定した挙動を示す。非周期ワークロード(LNPW)は改善幅が小さく半期間差も大きい。LPWとLNPWの混合は中間的な効果を示す。Source: 論文Table 1、§7.2.2) ### Allocatorマイクロベンチマーク(§7.2.3) ベースライン: Crane[18]($\alpha=1.2$のパーセンタイル×安全係数)、Resource Central–like(RC-like、Microsoft Resource Centralに着想)、$N$-sigma(平均+$N\times$標準偏差、$N=3$)。 **Figure 15・16: 履歴窓サイズの影響とSLA違反分布** ![[_attachments/3789240.3829141/fig15-history-window-effect.png]] (Figure 15. 履歴分割比率を0.10〜0.50で掃引してもAllocatorの違反率はほぼ1%未満でフラットに保たれ、履歴窓サイズの選び方への感度が低い。RC-likeは違反率が高く不安定(中60%台〜中30%台で推移)、N-sigmaは15〜23%で安定するがなお高い。Craneは履歴が増えるほど改善する。Source: 論文Fig.15、§7.2.3) ![[_attachments/3789240.3829141/fig16-sla-violation-methods.png]] (Figure 16. SLAパーセンタイル階層(<95/95-99/99-99.975/>99.975)ごとのワークロード分布。Allocatorは安全な階層(>99.975)にv2018で86.8%・v2022で100%を配置。Craneはそれぞれ70.9%・56.8%、RC-likeとN-sigmaは違反リスクの高い階層に大半を配置し、特にRC-likeの安全階層割合は6.2%・2.9%と低い。Source: 論文Fig.16、§7.2.3) ### End-to-end評価(§7.3) **Table 2: Hestiaのアブレーション(3トレース横断)** | Ablation Setting | v2018 MCV | v2018 SLA-V. | v2018 Profit | v2022 MCV | v2022 SLA-V. | v2022 Profit | Tencent-v2025 MCV | Tencent-v2025 SLA-V. | Tencent-v2025 Profit | |---|---|---|---|---|---|---|---|---|---| | Hestia(全モジュール) | 0.45 | 0.00% | 67.10% | 0.36 | 0.01% | 41.35% | 0.16 | 0.00% | 66.74% | | w/o Classifier | 0.52 | 2.09% | 69.39% | 0.59 | 1.39% | 40.18% | 0.34 | 1.18% | 68.42% | | w/o Aggregator | 0.77 | 0.35% | 27.33% | 0.64 | 1.54% | 34.62% | 0.52 | 1.89% | 77.59% | | w/o Classifier & Aggregator | 0.84 | 0.30% | 29.11% | 0.66 | 2.84% | 37.78% | 0.44 | 0.56% | 74.52% | (Table 2. 揮発性: Hestiaが全トレースで最低MCV(0.45/0.36/0.16)を達成。Aggregator除去の影響が最大(MCVは0.77/0.64/0.52まで悪化)。違反率: Hestiaは3トレースとも0.00〜0.01%とほぼゼロ。Classifier除去が違反率悪化への影響最大(2.09%/1.39%/1.18%)。利益: v2018・v2022ではAggregator除去で利益が大幅低下(v2018: 67.10%→27.33%)。Tencent-v2025ではAggregator除去でむしろ生の利益は77.59%に上がるが、揮発性・違反率が悪化するため、Hestiaの66.74%(違反率ほぼ0%)の方が安全性-利益トレードオフとして優れる。Source: 論文Table 2、§7.3.1) **Figure 17: End-to-endレイテンシ内訳** ![[_attachments/3789240.3829141/fig17-latency-breakdown.png]] (Figure 17. ワークロード数の増加に伴いClassify(Step 1)とAggregate(Step 2)がレイテンシの支配的部分を占め、Allocate(Step 3)は相対的に小さい。Read/データ転送のオーバーヘッドは計算・転送に比べ無視できる規模。100万ワークロードでもパイプライン全体が478秒で完了し、100万ワークロード規模でも実用的であることを示す。Source: 論文Fig.17、§7.3.2) **Figure 18: Hestiaトリガー閾値の選定** ![[_attachments/3789240.3829141/fig18-trigger-threshold.png]] (Figure 18. LPW集合が1kから3kに増えると平均MCV削減効果は9.9%から12.1%(観測された最良値)に向上するが、5k〜20kではその後11.6%〜11.84%(変動0.5%未満)で頭打ちになる。この結果から、トリガー閾値を**3,000ワークロード**に設定した。Source: 論文Fig.18、§7.3.3) **Figure 19: 多次元資源集約における利益と集約可能割合** ![[_attachments/3789240.3829141/fig19-multidim-aggregation.png]] (Figure 19. 集約対象の次元数(CPU単独の1Dから複数資源同時考慮の2D/3D/4D)が増えるほど、集約可能ワークロード比率(41.87%→29.03%→16.52%→2.39%)と利益マージン(35.2%→22.5%→12.8%→5.1%)がともに単調減少する。複数資源の同時制約を満たすワークロードの母集団が急速に狭まるためであり、著者らはこの結果から単一次元(本論文ではCPU)での最適化を採用する根拠としている。Source: 論文Fig.19、§7.3.4) ## 考察 - Hestiaは「揮発性そのものを制御可能なシステムプリミティブとして扱う」という視点を導入し、需要予測・配置・co-location・実行時制御という個別段階の改善に留まっていた既存研究を、揮発性低減という一本の軸で統合する(Source: 論文§8)。 - ClassifierとAggregatorはトレードオフの異なる役割を担う: Classifierの除去はSLA違反率の悪化(信頼性)に直結し、Aggregatorの除去は利益の大幅減少(収益性)に直結する。両者が揃って初めてHestiaの安全性-利益バランスが成立する(Table 2)。 - DWA単独でMCV低減の大部分(0.81→0.51)を獲得し、LSRによる追加改善(→0.46)は逓減する。この非対称性はレイテンシ制約下でのDWA単独運用と、余裕がある場合のLSR併用という運用上の柔軟性を生む(Fig.6)。 - 多次元資源への拡張は理論上可能だが、実験的には集約対象プールが急減し利益が縮小するため(Fig.19)、著者らは単一次元最適化を実用上の既定選択としている。他資源(メモリ・ディスクI/O・ネットワーク帯域)への適用時は資源固有のリスク対応が必要と述べるに留まる(Source: 論文§1、§7.3.4)。 ## 強み / 弱点・課題 **強み** - MCVという新指標を理論的下界・上界(Theorem 2.2)付きで導入し、経験的な有効性(Fig.3)と理論の両輪で正当化している。 - Alibaba-trace-v2018・v2022という異なる年代・提供元の公開トレースに加え、著者ら自身が[[Tencent]] Cloud本番環境から収集したTencent-trace-v2025でも一貫した優位性を示し、時系列横断・事業者横断の再現性(transferability)を検証している(§7.3.1)。 - 各モジュール(Classifier/Aggregator/Allocator)を個別にマイクロベンチマークし、かつEnd-to-endアブレーションで各モジュールの寄与を分離しているため、どの設計要素がどの指標に効くかが明確。 - 100万ワークロード規模でのレイテンシ実測(478秒)を示し、大規模本番環境への適用可能性を定量的に裏付けている(Fig.17)。 **弱点・課題(論文が述べる限界、または読み取れる懸念)** - 主要な評価はCPUを「代表的な資源」として単一次元で行っており、多次元資源(メモリ・ディスクI/O・ネットワーク帯域)への同時適用は集約可能ワークロード比率と利益の急減という代償を伴うことが示されている(Fig.19)。著者らは他資源への適用可能性に言及するが、実証的な多次元実験は限定的。 - $\lambda_-/\lambda_+$ の比率(2000)や、PCS閾値(0.4)、トリガー閾値(3000ワークロード)、SW観測窓(72時間)などのハイパーパラメータは著者らの本番環境での実験的グリッドサーチに基づく値であり、他クラスタ・他ワークロード分布での再現性は未検証。 - 本文中の同一手法に対する呼称の揺れ(Fig.12/Fig.13/Fig.14の凡例は「LB-Mean」だが、本文§7.2.2末尾の説明では同じ値(259.5s)を指して「LB-Volume」と表記)が見られ、原稿の校正段階での取りこぼしと考えられる。 ## 出典 - [[.raw/papers/3789240.3829141.pdf]](PDF原本) - [[.raw/papers/3789240.3829141.txt]](抽出テキスト) - ACM DOI: [https://doi.org/10.1145/3789240.3829141](https://doi.org/10.1145/3789240.3829141)