2026__MLSys2026__Cost-aware Duration Prediction for Software Upgrades in Datacenters

# Cost-aware Duration Prediction for Software Upgrades in Datacenters > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 4 (May 21 / Thu)、Industry Track（Bellevue, WA, USA）。公式ページでは Oral 発表 09:15 - 09:30 PDT、関連ポスターは Poster Session 3。 > - **セッション:** Industry Track — Agentic AI/MLSys（ルーティング上のトラック区分。論文は MLSys 2026 Industry Track 採択） > - **登壇者:** Yi Ding（Purdue University, Elmore Family School of Electrical and Computer Engineering）。スライド表紙で筆頭著者名に下線（発表者表記）。 > - **共著者:** Yi Ding¹、Aijia Gao²、Thibaud Ryden²、Michal Sedlak²、Essam Ewaisha²、Igor Marnat²、Henry Hoffmann³（¹Purdue University / ²Meta（1 Meta Way, Menlo Park, CA）/ ³University of Chicago, Department of Computer Science）。Meta Infra Data Center との協業（スライド表紙、論文表紙脚注）。 > - **連絡先:** Yi Ding `[email protected]`（論文表紙の Correspondence） > - **URL:** https://mlsys.org/virtual/2026/oral/3765 ／コード・データは「論文採択後に公開予定」と論文 Abstract に明記（"The code and data sets will be released after paper acceptance."） > [!note] 出典に関する注記 > 本ノートの出典は論文 PDF（18ページ）とスライド PDF（14ページ）、および公式 virtual ページのみ。文字起こしは存在しないため Q&A 節は設けない。発表者個人の発言・口頭補足は出典が無いため記述しない。スライド表紙で Yi Ding（Purdue）の名前に下線があり発表者と推定されるが、口頭内容そのものは追跡不能。時刻 09:15 - 09:30 PDT は公式 virtual ページ記載値。 > [!abstract] 概要（論文 PDF Abstract・忠実日本語訳） > ソフトウェアアップグレードはデータセンターにおけるサーバ信頼性の維持に不可欠である。ジョブの所要時間予測（duration prediction）とスケジューリングは広く研究されてきたが、ソフトウェアアップグレードが提起する固有の課題はほとんど未開拓のままである。本論文は、データセンター規模でのソフトウェアアップグレードスケジューリングに関する初の踏み込んだ調査を提示する。まず多様なアップグレード種別を特徴づけ、続いてスケジューリングタスクを制約付き最適化問題として定式化する。この問題に対処するため、我々は Acela を導入する。Acela は、サービスレベル目標（SLO）を満たしつつアップグレードスケジューリングの効率とスループットを改善するよう設計された、コストを意識した（cost-aware）所要時間予測フレームワークである。Acela は非対称な誤予測コストを考慮し、最良の予測モデルを戦略的に選択し、ストラグラー（straggler）に起因する過大推定を緩和する。Meta の本番データセンターシステムでの評価により、Acela は既存のアップグレードスケジューラの効率を大幅に向上させ、アップグレードウィンドウ利用率を 1.25倍に高め、スケジュール済み・完了済みアップグレード数をそれぞれ 33%・41% 増加させ、キャンセル率を 2.4倍低減することを示す。コードとデータセットは論文採択後に公開予定である。 ## 問題設定: ハイパースケールでのアップグレードスケジューリング - データセンターは OS・カーネル更新、ファームウェア更新などサーバソフトウェアを継続的にアップグレード。信頼性向上・バグ/脆弱性修正・計画外ダウンタイム削減のため必須だが、ハイパースケールでは定常的なアップグレードでも複雑なスケジューリング問題となる（スライド「Software Upgrades Keep Datacenters Healthy」）。 - **ソフトウェアアップグレード（SU）スケジューリング**は従来のサービスジョブ（SJob）スケジューリングと本質的に異なる（スライド「Software Upgrade (SU) Scheduling at Datacenter Scale」、論文 Figure 3）: - SJob はサーバ間に柔軟に分散可能だが、**SU は特定サーバに紐づく**（fixed assignment）。 - SJob の SLO はジョブレイテンシ中心だが、**SU の SLO はアップグレードの 95% 以上を固定ウィンドウ内に完了させること**を要求。 - **Meta の既存手法は安全だが非効率**（スライド「Meta's Existing Solution: Safe but Inefficient」、論文 Figure 1）: - 現行は全アップグレードに**固定の worst-case 所要時間を仮定**し、サーバあたりのアップグレード数を保守的に制限して SLO を保護。 - 結果としてアップグレードウィンドウに大きなアイドル時間が残る。**16 データセンター・5か月の観測でウィンドウ利用率は平均 20–40% に留まり（一部 50% 到達）、ばらつきも大きい**。 ## サーバライフサイクルと circle-based upgrade - **サーバライフサイクル**: SJob 稼働中に SU フェーズが挿入され、両者は重ならない distinct フェーズ。アップグレード中は SJob を buffer サーバへ移行し、完了後に戻す（スライド「A Sever's Lifecycle」、論文 Figure 2）。 - **circle-based upgrade process**（論文 §2.2、Figure 4–5、スライド「How Software Upgrades Rotate Across Server Groups」）: - ラック内サーバ群が **upgrade group (UG)** を構成（電源・ネットワークスイッチ共有の基本管理単位）。 - 各 UG が役割を循環: **upgrade group**（アップグレード対象）/ **buffer group**（移行 SJob をホスト）/ **overflow group**（故障サーバのジョブを処理）。 - サイクル例: 5 regular UG + 1 buffer UG + 1 overflow UG。UG 内では部分逐次でアップグレードし、buffer 容量制約から同時アップグレードは一定割合（例 25%）以下。ウィンドウ内に間に合わないサーバは repair マークし、ジョブを overflow へ移行（論文 Figure 5）。 ## 課題: 所要時間予測の難しさ - **Challenge #1（多様な所要時間分布）**: アップグレード種別・ハードウェアコンテキストにより long-tailed で異質な分布。ファームウェアアップグレード 8 種（BIC, BIOS, BMC, CPLD, DISK, FLASH, ME, NIC）の CDF はそれぞれ異なる long-tail 挙動を示す（論文 Figure 6・Table 2、スライド「Why Duration Prediction Is Challenging」。CDF 図に median を赤星、p99 を青点でマーク）。これら 8 種でファームウェアアップグレード全体の 99% 超を占める（論文 §6.1）。 - **Challenge #2（システム目的とのミスマッチ）**: 低い予測誤差が必ずしもスループット最大化や SLO 保護に直結しない。多くの ML 予測器は accuracy 最大化を狙うが、本問題の最終目的は upgrade scheduling efficiency と SLO 達成（論文 §3.1）。 ### 誤予測の 4 類型と非対称コスト論文 §3.2 / スライド「Mispredictions Have Asymmetric Scheduling Costs」: - **Underprediction**（過小）: アップグレードウィンドウ過負荷リスク。極端な過小はサーバ復旧遅延・アップグレードサイクル停滞（多くはハードウェア故障由来のストラグラーが原因で、訓練データにあるとモデルを extreme overprediction へバイアス）。 - **Overprediction**（過大）: 軽度なら SLO 遵守に安全。**extreme overprediction** はウィンドウ利用率を下げ worst-case スケジューラに退化。 - 結論: 効果的な予測器は **わずかに過大予測**して SLO を満たし、訓練時のストラグラー影響を抑え、種別間のばらつきを考慮すべき（論文 §3.2 末尾）。 ## 提案手法 Acela コアアイデア: 固定 worst-case 推定の代わりに **cost-aware duration prediction** を用いる。テーゼは「最も正確（most accurate）な予測ではなく、現実的（realistic）な所要時間を予測することでスケジューリングスループットを高める」（スライド「Our solution: Acela」）。 ### 設計原則と 4 技術（論文 §4.1、スライド「Acela Design Principles」） - **非対称コスト考慮** → **cost-aware loss**（quantile loss）。 - **効率と SLO のバランス** → **SLO-aware model selection**（カスタムスコア関数）。 - **extreme overprediction の抑制** → **straggler-aware training**（ストラグラー除去）。 - **所要時間ばらつきの捕捉** → **type-aware duration prediction**（種別ごとにモデルを分離）。 - スライド要約: 「Acela is cost-aware, SLO-aware, and variability-aware.」 ### (1) Quantile Regression（非対称コスト対応） - 平均ではなく **高分位（high quantile）を予測**。Quantile loss（論文式1）: - L_τ(y, ŷ) = τ(y − ŷ)·𝟙(y ≥ ŷ) + (τ − 1)(y − ŷ)·𝟙(y < ŷ) - τ > 0.5 で過小予測をより重く罰し、過大予測を促す。よって **Acela は τ > 0.5 を採用**（スライド「Quantile Regression Handles Asymmetric Costs」、論文 §4.2）。 - τ の効果: τ=0.5 → median / balanced、τ>0.5 → longer estimate・過小予測減、τ 過大 → near worst-case・利用率低下。τ はスケジューリングパラメータとして扱う（高 τ = 安全な SLO・低効率、低 τ = 高効率・高 SLO リスク）。 - **Quantile Gradient Boosting Trees (QGBT)** で条件付き分位を推定。標準 GBT が分割後にノード内平均のみ保持するのに対し、**QGBT は値の全分布を保持**し望む分位に応じて予測を調整可能（論文 §4.2）。Figure 7 で CQ-0.9 が CQ-0.5/CQ-0.1/CM より長い所要時間を予測することを例示。 ### (2) SLO-aware Model Selection（カスタムスコア） - 複数 τ で QGBT を訓練し、検証スコア最良のモデルを選択。検証セットは訓練セットの後の期間（chronological）で本番デプロイを模擬（論文 §4.3、スライド「Selecting the Best Quantile Model」）。 - スコア関数（論文式2）: - OPR ≥ SLO のとき score = MAE（SLO 達成見込み → MAE 最小化に注力） - OPR < SLO のとき score = (α·(1 − OPR) + 1)·MAE（SLO 危機 → ペナルティ加算） - MAE = 検証 MAE、**OPR = overprediction rate**（予測が実測を上回る割合）、SLO = 目標完了率（例 95%）、**α = SLO 未達ペナルティ**。 - スライド要約: 「選択されるモデルは最も正確なモデルではなく、スケジューリングを最良に支えるモデル」。 ### (3) Straggler-aware Training（過大予測バイアス抑制） - 訓練データに含まれる極端に長いストラグラーがモデルを過大推定へバイアス。**truncate した複数訓練セット**を作成（論文 §4.4、Figure 8、スライド「Reducing Straggler-Induced Prediction Bias」）: - Original（無切り捨て）/ **P99-truncated**（上位 1% 除去）/ **P99.9-truncated**（上位 0.1% 除去）。 - 効果: ストラグラーバイアス減 → extreme overprediction 減 → アップグレード効率向上。 ### システム統合（Putting It All Together） - 種別ごとに QGBT を構築。オンライン設定で新規アップグレードを追加・古いものを破棄して訓練/検証を継続更新。truncate データセット作成 → 複数分位で訓練 → SLO と α で式2 によりスコアリング → 種別ごとに最良モデルをデプロイ（論文 §4.5）。 - 既存スケジューラへの**強化レイヤ（enhancement layer）**として統合。3 モジュール追加（論文 §5、Figure 9、スライド「Putting It All Together」）: - **Data Collection Pipeline (DCP)**: アップグレードデータを継続記録（種別・バージョン・ハードウェア仕様・製造/アップグレード情報など。特徴量詳細は Appendix）。 - **Model Training and Selection (MTS)**: LightGBM で QGBT 構築、ハイパーパラメータ・τ 調整、データ更新。 - **Prediction Query Service (PQS)**: JSON 形式リクエスト（server ID・SU type・desired version）を受け所要時間予測を返す。 - スケジューリングロジックは既存の priority 意味論を保持（upgrade history / dependency constraints / stakeholder interests）。同 priority なら**予測所要時間が短い方を優先**してスループット向上。複雑なケースはオペレータが介入可能（論文 §5）。 ## 実験・評価 - **評価設定**（論文 §6.1、スライド「Evaluation Methodology」）: - 訓練 **400万超（4M+）** アップグレード（3か月）、評価 **約100万（~1M）**（後続1か月）、本番 **198 upgrade groups**。各 UG は 1,000 件以上をスケジュール。 - 198 UG のうち **47 UG が Heuristic ベースライン**（固定 worst-case）、**151 UG が Acela**（Acela は処理量が増えるためより多くの UG に適用）。 - SLO は **アップグレードウィンドウ内に 95% 以上完了**。スコアペナルティ α は cross-validation（[0.1, 1, 10, 100, 1000]）で選定し α=10 を採用。ストラグラー制限のため p99/p99.9 で truncate し週次再訓練。 - **焦点はファームウェアアップグレード**: 所要時間が長く（1–2時間）、サーバ/UG 間ばらつきが大、スケジューリング最難カテゴリ。OS は所要時間同程度（1–2時間）だがより安定、カーネル/ネットワークスイッチは短時間（多くは30分未満）で予測の意義が小（論文 §6.1）。 - 比較: **Acela**（duration prediction + SLO-aware model selection）vs **Heuristic**（固定 worst-case）。さらにシミュレーションで **Strawman**（種別ごと平均所要時間）と **Naïve-ML**（accuracy 最適化の標準 ML、Acela と同じ GBT だが条件付き平均を予測）も比較（本番デプロイは各サーバが各アップグレードを一度しか経験しないため不可）。 - **メトリクス**: utilization（高いほど良）、cancellation rate（低いほど良）、scheduled/completed SU 数（論文 §6.1）。 ### 主要本番結果（論文 Figure 10・§6.2、スライド「Main Production Results」） - Heuristic → Acela の比較（平均値）: - **Window utilization: 37.8% → 47.1%（1.25倍）** - **Scheduled SUs: 3,888 → 5,182（+33%）** - **Completed SUs: 3,536 → 4,989（+41%）** - **Cancellation rate: 6.6% → 2.8%（2.4倍低減）** - **SLO 結果**: Acela は **5% キャンセル率 SLO を達成、Heuristic は未達**（Figure 10 (b) の SLO ライン 5%）。Acela は所要時間予測によりウィンドウを過負荷にせず、より多くのアップグレードをスケジュール可能（論文 §6.2）。 ### シミュレーション（1 UG・14,515 件、論文 Table 3・§6.3） - #Scheduled: Heuristic 9,241 / Strawman 11,604 / **Naïve-ML 12,041** / Acela 11,972 - #Completed: Heuristic 9,234 / Strawman 11,495 / Naïve-ML 11,941 / **Acela 11,963** - CR（キャンセル率、低いほど良）: Heuristic 0.08% / Strawman 0.94% / Naïve-ML 0.83% / **Acela 0.08%** - Naïve-ML は最多スケジュールだがサーバ過負荷で高 CR。Acela は最多完了かつ低 CR を維持し、Heuristic 同等の CR を保ちつつ Strawman 比 11.75倍・Naïve-ML 比 10.4倍良いキャンセル率（論文 §6.3）。 ### 所要時間予測・損失関数・ストラグラー除去 - **Duration Prediction Results**（論文 §6.4、Figure 11）: MAE は Heuristic が最悪（他比 38–79倍）。Naïve-ML が最良 MAE（他比 1.8–79倍低、squared loss 最適化のため）。だが**対称損失手法は OPR が約 50% に留まり 95% SLO に届かない**（条件付き平均を推定するため）。Acela は条件付き分位を推定し **OPR 95% を達成して SLO を満たす**唯一の手法（過大予測を促す quantile loss による）。 - **Versus Other Loss Functions**（論文 §6.5、Figure 12–13）: L2/L1/Huber は対称でバランス型ペナルティ。Acela の quantile loss（τ=0.9）は過小予測を重く罰す非対称。Acela の MAE は他 3 損失より 1.2–2.4倍悪いが、これは accuracy ではなく設計したスコア関数を最適化するため。 - **Impact of Removing Stragglers**（論文 §6.6、Figure 14・Table 4）: W/ Stragglers vs W/O Stragglers で OPR はほぼ同一（96.275% vs 96.075%）だが、**W/ Stragglers は MAE が 1.2倍悪化**。ストラグラー除去が accuracy → 効率を改善。Table 4 では Acela が選んだ低スコアモデルが全てストラグラー除去済みで、95% SLO 達成モデルが一貫して低スコア。 - **Sensitivity to Quantile Parameter τ**（論文 §6.7、Figure 15–16）: τ ∈ {0.5, 0.6, 0.7, 0.8, 0.9, 0.95, 0.99} を sweep。scheduled/cancellation は高 τ（0.95, 0.99）で最小化。OPR は τ とともに単調増加し 0.99 でピーク。MAE は初め τ とともに減少し後に増加（データ分布が left-skewed で median > mean のため、高分位で過大予測すると真の median に近づき MAE が一旦下がる）。 ## 結論・takeaway - スライド「Conclusion」要約: **「所要時間予測のわずかな改善が、データセンターのアップグレード効率に大きな利得をもたらしうる」**（"Small improvements in duration prediction can unlock large gains in datacenter upgrade efficiency."）。 - 論文 §8: ソフトウェアアップグレードはデータセンター信頼性に不可欠だが未開拓。Meta 本番データを用いた **初のデータセンター規模の特徴づけ・分析**であり、**初のデプロイ済みソリューション**として Acela を提示。本番評価で既存ベースラインを上回る。 - 主要貢献（論文 Introduction）: - Meta 本番のソフトウェアアップグレードの大規模特徴づけ・分析。 - アップグレードスケジューリングの制約付き最適化問題としての定式化。 - アップグレード固有の非対称予測コストの同定。 - 所要時間予測のための新規モデル選択・訓練手法。 - Acela のデプロイと実データセンターでの評価（substantial efficiency gains）。 - **オープン課題**: worst-case 分析（テール実行時間の bounding、低速サーバと故障サーバの区別シグナル提供）を future work とする（論文 §5.1 Discussion）。失敗モード分析として、UG 内の相関した過小予測・新バージョン投入時の distribution shift・ストラグラー除去の副作用・PQS タイムアウトや特徴欠損時の unsafe default 退化を挙げる。