# Cost-aware Duration Prediction for Software Upgrades in Datacenters
> [!abstract] 概要
> ソフトウェアアップグレードはデータセンターでサーバー信頼性を維持するために不可欠である。ジョブの期間予測とスケジューリングは広く研究されてきた一方、ソフトウェアアップグレードがもたらす固有の課題はほとんど未解明のままである。本論文は、データセンター規模でのソフトウェアアップグレードスケジューリングに関する初の詳細な調査を提示する。まず様々な種類のアップグレードを特徴づけたうえで、スケジューリングタスクを制約付き最適化問題として定式化する。この問題に対処するため、アップグレードスケジューリングの効率とスループットをサービスレベル目標(SLO)を満たしながら改善する、コストアウェアな期間予測フレームワーク Acela を導入する。Acela は非対称な誤予測コストを考慮し、最良の予測モデルを戦略的に選択し、ストラグラー由来の過大予測を緩和する。Meta の本番データセンターシステムでの評価では、Acela は既存のアップグレードスケジューラの効率を大幅に高め、アップグレード窓の利用率を1.25倍改善し、スケジュール・完了されたアップグレード数をそれぞれ33%・41%増やし、キャンセル率を2.4倍削減する。コードとデータセットは論文採択後に公開予定である。
関連: 本ソースが扱うのは「サーバーを一時的にサービスから外して行う計画的アップグレード(ダウンタイムを伴う保守窓の中で完了させる)」のスケジューリング最適化であり、[[ライブアップグレード]](サービス無停止で OS/ライブラリを差し替える技術)とは前提が異なる。両者とも「アップグレードの安全な実施」という目的は共有するため相互参照する。
## 論文情報
- 著者: [[Yi Ding]]、Aijia Gao、Thibaud Ryden、Michal Sedlak、Essam Ewaisha、Igor Marnat、[[Henry Hoffmann]](著者順は PDF 1ページ目)。
- 所属: Yi Ding は [[Purdue University]](Elmore Family School of Electrical and Computer Engineering)。Aijia Gao・Thibaud Ryden・Michal Sedlak・Essam Ewaisha・Igor Marnat は [[Meta]](Menlo Park, CA)。Henry Hoffmann は University of Chicago Department of Computer Science。
- 媒体: 第9回 MLSys Conference(Industry Track)、Bellevue, WA, USA, 2026。
- コード・データセット: 論文採択後に公開予定(本文執筆時点は未公開)。
## 概要
Meta のデータセンターでは、サーバーのファームウェア・OS・カーネルなどのソフトウェアアップグレードを、ラック単位の「アップグレードグループ(UG)」ごとに、固定時間の「アップグレード窓」内で周期的に実施している。既存のスケジューラは全アップグレードに対して固定・最悪ケースの所要時間を仮定するため安全だが非効率で、16 拠点・5ヶ月の観測でアップグレード窓の利用率は平均20〜40%にとどまる(Figure 1)。本論文は、アップグレードごとの実際の所要時間を予測してスケジューリング効率を上げるコストアウェア期間予測フレームワーク Acela を提案し、Meta 本番環境での大規模評価によってその有効性を実証する。
**Figure 1: アップグレード窓利用率の低さ**
![[_attachments/21_Cost_aware_Duration_Predict/fig01-window-utilization.png]]
(Figure 1. Meta の16データセンターにわたる、5ヶ月間のアップグレード窓平均利用率。黒い髭は標準偏差を示す。固定・最悪ケース想定のスケジューリングにより、利用率は平均20〜40%、最大でも50%程度にとどまり、拠点間のばらつきも大きい。)
## 問題設定
### サービスジョブとソフトウェアアップグレードの違い
サーバーのライフサイクルにおいて、サービスジョブ(SJobs: 検索・動画配信等)とソフトウェアアップグレード(SUs)は排他的な異なるフェーズである(§2.1)。SJobs はサーバー間で柔軟に再配置できる一方、SUs は特定のサーバーに紐づき、SLO も「レイテンシ」ではなく「アップグレード窓内に95%以上のアップグレードを完了させること」という達成率ベースの制約になる。この「固定されたサーバー割り当て+達成率SLO」という組み合わせが、SU スケジューリングを SJob スケジューリングより難しくしている。
**A Sever's Lifecycle(スライド由来)**
![[_attachments/21_Cost_aware_Duration_Predict/slide-sjobs-vs-sus-scheduling.png]]
(SJobs と SUs はサーバーの生存期間の異なるフェーズであり重複しない。アップグレード中はサービスジョブがバッファサーバーへ一時退避し、完了後にサーバーへ戻る。Source: MLSys 2026 発表スライド。)
### サークル型アップグレードプロセス(Circle-based Upgrade Process)
Meta のデータセンターでは、ラックを共有する電源・スイッチ単位でサーバー群がアップグレードグループ(UG)を構成する(§2.2, Table 1)。各時点でサーバーは (1) 通常のアップグレード対象サーバー、(2) アップグレード中サーバーのサービスジョブを受け入れるバッファサーバー、(3) 修理中サーバーのジョブを受け入れるオーバーフローサーバー、のいずれかの役割を担い、この役割はサイクルごとに UG 間でローテーションする。UG 内では移行先バッファ容量の制約から、同時にアップグレードできるサーバーは一部の割合(例: 25%)に限られ、部分的に逐次実行される。アップグレード窓を超過したサーバーは修理対象としてマークされ、ジョブはオーバーフローサーバーへ移される。
**UG ローテーション(スライド由来)**
![[_attachments/21_Cost_aware_Duration_Predict/slide-upgrade-group-rotation.png]]
(UG1〜UG5 が通常運用、Buffer と Overflow を含めた役割がサイクルごとにローテーションする様子。Buffer UG がサービスジョブの退避先、Overflow UG が故障サーバーのジョブ退避先となる。Source: MLSys 2026 発表スライド。論文中の Figure 4/5 に対応。)
### 予測を難しくする2つの課題
第一に、ファームウェアアップグレードの種類(BIC・BIOS・CPLD・DISK・FLASH・ME・NIC・BMC)ごとに所要時間分布が大きく異なり、長い裾を持つ(Figure 6, §3.1)。第二に、多くの機械学習予測器は予測精度の最大化を目的とするが、Acela の目標はアップグレード窓の利用効率とSLO遵守の最大化であり、両者は必ずしも一致しない(Challenge #2, §3.1)。
### 4種類の誤予測とスケジューリングへの影響
§3.2 では、過小予測(underprediction)と過大予測(overprediction)をそれぞれ「軽度」と「極端」に分けた4類型を整理する。過小予測はアップグレード窓の過負荷とサーバー復帰の遅延を招き、極端な過小予測はストラグラー(ハードウェア故障由来)に起因して修理・オーバーフロー処理を要する。過大予測は窓の低利用率を招くが、軽度の過大予測はSLO遵守の観点でむしろ望ましく、極端な過大予測は既存の最悪ケーススケジューラと同様に効率を下げる。この分析から、効果的な予測器は「軽度に過大予測しつつ、ストラグラーの影響を抑え、アップグレード種別ごとの分散を捉える」べきという設計原則が導かれる。
## 提案手法
### アーキテクチャ
Acela は既存の Meta アップグレードスケジューラを置き換えるのではなく、拡張レイヤーとして統合される。3つの新モジュール(黄色)が既存モジュール(青)に追加される: Data Collection Pipeline(DCP、アップグレードの種類・バージョン・ハードウェア仕様等を継続的にログする)、Model Training and Selection(MTS、LightGBM を用いて分位点勾配ブースティング木を訓練・選択する)、Prediction Query Service(PQS、Planning and Scheduling Service からのリクエストに応じて期間予測を返す)。モジュール間は独自の RPC と RESTful API で通信する(§5)。
**Figure 9: Acela の統合アーキテクチャ**
![[_attachments/21_Cost_aware_Duration_Predict/fig09-acela-integration.png]]
(Figure 9. 既存スケジューラのモジュール(青)に、Acela が追加する Data Collection Pipeline・Model Training and Selection・Prediction Query Service(黄)が統合される様子。Prediction Query Service は Planning and Scheduling Service からのリクエストに応じて予測を返す。)
### Acela の設計原則(まとめ)
**Acela Design Principles(スライド由来)**
![[_attachments/21_Cost_aware_Duration_Predict/slide-acela-design-principles.png]]
(4つの設計原則—非対称コストの考慮・効率とSLOの両立・極端な過大予測の抑制・種別ごとの分散の捕捉—と、それぞれに対応する Acela の技術(コストアウェア損失・SLOアウェアモデル選択・ストラグラーアウェア訓練・種別ごとの期間予測)の対応関係。Source: MLSys 2026 発表スライド。論文 §4.1 の4原則に対応。)
### アルゴリズムの詳細
**1. 非対称コストのための分位点回帰(§4.2)**
標準的な回帰は対称な二乗誤差損失を最小化して条件付き平均 $E(Y|X=x)$ を予測するが、これはアップグレード期間予測の非対称コストに対応できない。Acela は条件付き分布 $F(y|X=x)=P(Y\le y|X=x)$ の $\tau$-分位点 $q_\tau(x) = \inf\{y: F(y|X=x)\ge \tau\}$ を推定する。分位点損失は
$L_\tau(y,\hat y) = \tau(y-\hat y)I(y\ge\hat y) + (\tau-1)(y-\hat y)I(y<\hat y)$
で定義され(式1)、過小予測時は $\tau(y-\hat y)$、過大予測時は $(\tau-1)(y-\hat y)$ となる。$\tau>0.5$ にすると過小予測へのペナルティが相対的に大きくなり、モデルは高めの(過大予測寄りの)分位点を出力するよう学習する。Acela はこの $\tau$-分位点推定に、LightGBM を用いた分位点勾配ブースティング木(QGBT、Meinshausen & Ridgeway 2006)を用いる。QGBT は標準の GBT と異なり、木の分岐後もノード内のデータ分布全体を保持するため、任意の分位点への調整が可能になる。
**2. モデル選択のためのカスタムスコア(§4.3)**
複数の $\tau$ で QGBT モデルを訓練し、時系列的に訓練セットより後に発生したアップグレードからなる検証セットで評価する。スコア関数は
$
\text{score} = \begin{cases}
\text{MAE} & \text{if OPR} \ge \text{SLO} \\
(\alpha \cdot (1-\text{OPR}) + 1) \cdot \text{MAE} & \text{if OPR} < \text{SLO}
\end{cases}
$
(式2、OPR = 過大予測率、SLO = 95%、$\alpha$ = 過小予測ペナルティ係数)で与えられ、OPR が SLO を上回っていれば単純に MAE 最小化を目指し、下回っていれば OPR の不足度に応じてペナルティを強める。この設計により「最も精度の高いモデル」ではなく「スケジューリング目的を最もよく支えるモデル」が選ばれる。
**3. ストラグラーを考慮した訓練セット多様化(§4.4)**
訓練データ中の極端に長いアップグレード(ストラグラー、p99・p99.9 超)は予測を過大予測方向にバイアスさせる。Acela はこれらを除去した複数の切り詰め済み訓練セットを作り(Figure 8)、各セットで複数の $\tau$ の QGBT を訓練し、式2のスコアが最小のモデルを選ぶ。
**Figure 8: 訓練セット多様化**
![[_attachments/21_Cost_aware_Duration_Predict/fig08-training-set-diversification.png]]
(Figure 8. p99・p99.9 パーセンタイルで長時間側を切り詰めた複数の訓練セットを作る「Training Set Diversification」の模式図。オリジナルの分布(左)から、切り詰め位置の異なる複数の訓練セット(右)を作り、それぞれで QGBT モデルを訓練してスコアが最小のものを選ぶ。)
### スケジューリングロジックとの統合(§5)
Acela は既存の優先度セマンティクスを保ちつつ期間予測を組み込む。優先度は (1) 直近に実施されていないアップグレード種別を優先する履歴、(2) 依存関係(依存元 B は依存先 A より先に実施、A が B に包含されるなら A の実施を避ける)、(3) 運用者・サービス所有者が重要とみなすアップグレードの昇格、の3要素で決まる。同一優先度の場合は予測期間が短いアップグレードを優先してスループットを高め、優先度と予測期間が相反する場合は原則として優先度を優先する。複雑・曖昧なケースはオペレーターの裁量に委ねる。
### 失敗モード分析(§5.1)
著者らは、UG内での相関した過小予測(同一ラック内の複数サーバーが同時に過小評価されると害が増幅する)、新アップグレードバージョン後の分布シフト(Acela は週次再訓練でバージョン特徴量に依存するため影響を受ける)、ストラグラー除去の副作用、Prediction Query Service のタイムアウトや欠損特徴量によるサービスレベルの依存関係障害(サイレントに危険なデフォルト値へフォールバックしうる)、の4点を運用制約下での失敗モードとして議論する。各失敗モードはキャンセル率・利用率・OPRといった既存の運用指標で検知でき、リプレイや小規模フォールト注入でテスト可能だとする。ワーストケース分析についても、一部アップグレードが想定より大幅に長引き窓を超過してキャンセル・オペレーション上の曖昧性(遅いサーバーと故障サーバーの区別が困難になる)を招くシナリオを挙げ、頑健性は予測精度だけでなくテール実行時間の制御とシグナルの明確さにも依存すると指摘する。詳細なワーストケース分析は将来課題としている。
## 新規性
先行研究のジョブスケジューリング(Krishnaswamy+2004、Apollo、TetriSched、3Sigma、SLearn 等)はサービスジョブの期間予測・スケジューリングを扱ってきたが、データセンター規模でのソフトウェアアップグレードスケジューリングは未探索だったと著者らは位置づける(§7)。Ding+2019 と NURD(Ding+2022、著者の一部と重複)は「予測精度の向上が必ずしもシステム成果の向上につながらない」ことを示しており、Acela はこの知見をソフトウェアアップグレードという新領域で共有・応用する。ネットワーク変更スケジューリング(Janus、CORNET、Dionysus)とも異なり、Acela はデータセンター規模のソフトウェアアップグレード特有のスケジューリング制約(ラック単位の UG、達成率SLO、バッファ容量制約)を扱う。
論文が掲げる貢献は5点: (1) Meta 本番データセンターでのソフトウェアアップグレードの大規模特徴づけと分析、(2) ソフトウェアアップグレードスケジューリングの制約付き最適化問題としての定式化、(3) アップグレード固有の非対称予測コストの特定、(4) 新規のモデル選択・訓練手法、(5) Acela の実運用デプロイと大幅な効率改善の実証(§1)。
## 実験設定
400万件超のソフトウェアアップグレード(3ヶ月分)で訓練し、198 UG・約100万件のアップグレード(訓練後1ヶ月分の本番運用)で評価する(§6.1)。SLO は95%、スコアペナルティ係数 $\alpha=10$(候補 [0.1, 1, 10, 100, 1000] からクロスバリデーションで選択し、実運用では月次で再検討)。訓練データは p99・p99.9 パーセンタイルで切り詰め、Acela は週次で再訓練する。評価対象はファームウェアアップグレード8種(BIC・BIOS・BMC・CPLD・DISK・FLASH・ME・NIC、全ファームウェアアップグレードの99%超をカバー、Table 2)で、実行時間が長く(1〜2時間)分散も大きいため最も運用上難しいカテゴリとして選ばれた。比較対象の OS アップグレードは同程度の長さ(1〜2時間)だが安定・予測しやすく、カーネル・ネットワークスイッチのアップグレードは通常30分未満で影響が小さい。
比較手法は3つ: Heuristic(既存の固定・保守的な最悪ケース見積り、151 UG が Acela、47 UG が Heuristic を使用—Acela がスケジュール量を増やすため適用 UG 数が多い)、Strawman(種別ごとの平均期間を予測、シミュレーションのみ)、Naïve-ML(Acela と同じ GBT だが条件付き平均を予測、シミュレーションのみ)。Strawman・Naïve-ML は各サーバーのアップグレードが一度きりであるため本番デプロイでのテストコストが高く、本番評価には含めていない(シミュレーションは実測との乖離1%未満)。評価指標は利用率(アップグレード窓のうち実際にアップグレードに費やされた時間の割合)とキャンセル率(窓内に完了しなかった割合)、スケジュール数・完了数。
## 実験結果
### 本番環境でのメイン結果(§6.2)
**Figure 10 / Main Production Results(論文図+スライド要約)**
![[_attachments/21_Cost_aware_Duration_Predict/fig10-main-production-results.png]]
(Figure 10. Heuristic と Acela の本番結果比較。黒点と数値はデータの平均。SLO(キャンセル率5%未満)を Acela は平均で満たし Heuristic は満たさない。)
![[_attachments/21_Cost_aware_Duration_Predict/slide-main-production-results-summary.png]]
(表形式のまとめ(スライド由来): 利用率37.8%→47.1%(1.25倍)、スケジュール数3,888→5,182(+33%)、完了数3,536→4,989(+41%)、キャンセル率6.6%→2.8%(2.4倍低減)。Source: MLSys 2026 発表スライド、論文 Figure 10 と同じ数値。)
Acela は Heuristic に対しアップグレード窓利用率を平均1.25倍(37.8%→47.1%)改善し、これはスケジュール数33%増・完了数41%増によって駆動される。Heuristic は全アップグレードに一律の長い所要時間を仮定するため、実際は短時間で終わるアップグレードまで保守的にスケジュールしてしまう。より多くのアップグレードを処理しながらも、Acela はキャンセル率を6.6%→2.8%(2.4倍改善)に低減し、5%のSLOを満たす(Heuristicは満たさない)。
### シミュレーションでの比較(§6.3, Table 3)
14,515件のアップグレード要求を持つ実データの UG でシミュレーションした結果、Heuristic は固定長期間の仮定によりスケジュール数(9,241)・完了数(9,234)ともに最少となる。Strawman・Naïve-ML・Acela は Heuristic より最大30%多くのアップグレードをスケジュール・完了する。Naïve-ML が最もスケジュール数(12,041)が多いがキャンセル率も0.83%と高く、Acela は完了数最多(11,963)かつキャンセル率0.08%(Heuristic と同水準)を維持し、Strawman比11.75倍・Naïve-ML比10.4倍低いキャンセル率を達成する。
### 期間予測の精度(§6.4, Figure 11)
**Figure 11: 種別ごとの MAE と OPR**
![[_attachments/21_Cost_aware_Duration_Predict/fig11-mae-opr-by-type.png]]
(Figure 11. ファームウェア種別ごとの予測精度(MAE、低いほど良い)と過大予測率(OPR)。読みやすさのため MAE は300でキャップ。Heuristic は固定長を仮定するため MAE が38〜79倍悪い。Naïve-ML は精度(MAE)は最良だが対称損失のため OPR は約50%にとどまりSLOを満たさない。Strawman と Acela は中間的な MAE だが、Acela はカスタムスコア関数でSLOと効率の両立を狙う。)
Naïve-ML は対称二乗損失で条件付き平均を最小化するため MAE は最良(他手法比1.8〜79倍良い)だが OPR は約50%でSLO(95%)を大きく下回る。Heuristic は固定長仮定のため MAE が最悪。Acela は MAE で1.2〜2.4倍 Naïve-ML に劣るが、この精度低下は「予測精度でなくカスタムスコア関数」を最適化する設計の帰結である。
### 損失関数の比較(§6.5, Figure 12/13)
**Figure 13: 損失関数ごとの比較**
![[_attachments/21_Cost_aware_Duration_Predict/fig13-loss-function-comparison.png]]
(Figure 13. L2・L1・Huber(対称損失)と分位点損失(Acela、非対称)を比較した MAE と OPR。対称損失3種は全てOPRが約50%前後でSLOに届かないが、$\tau=0.9$ の分位点損失のみOPR 95%でSLOを満たす。MAEは分位点損失が対称損失3種より1.2〜2.4倍悪化するが、これは対称損失が「真値と予測値の差の最小化」を目指すのに対し、Acelaはスコア関数の最小化を目指す設計上のトレードオフである。)
L2・L1・Huber はいずれも対称な罰則構造を持ち、真の期間と予測値の差を最小化しようとするため OPR が約50%に留まりSLOを満たさない。$\tau=0.9$ の分位点損失を使う Acela のみが過小予測により重い罰則を与え、95%のOPRを達成してSLOを満たす。
### ストラグラー除去の効果(§6.6, Figure 14)
ストラグラー(p99・p99.9)を含めた訓練(W/ Stragglers)と除いた訓練(W/O Stragglers、Acelaが採用)を比較すると、OPRはほぼ同一(96.275% vs 96.075%、ストラグラーを含めても過大予測がわずかに増えるのみ)だが、W/ Stragglers は MAE が1.2倍悪化する。すなわちストラグラー除去は SLO 遵守を犠牲にせず精度を改善する。
Table 4 では95%・99%分位点 × p99・p99.9・100(除去なし)切り詰めの組み合わせでMAE・OPR・スコアを比較し、Acelaが選ぶモデルは一貫してストラグラー除去(p99またはp99.9)を伴い、SLOを満たすモデル(OPR≥95%)は一貫して低スコアになる一方、SLOを満たさないモデルは大きくペナルティを受けることを確認した。
### 分位点パラメータ τ への感度分析(§6.7, Figure 15/16)
τ を{0.5, 0.6, 0.7, 0.8, 0.9, 0.95, 0.99}で掃引すると、スケジュール数・キャンセル数はτの増加とともに減少し0.95〜0.99付近で最小化する(τが高いほど保守的な=過大予測寄りの期間になるため)。OPRはτとともに単調増加して0.99でピークに達する。一方MAEはτの増加に伴い一度減少してから増加する非単調な挙動を示す。これはデータ分布が左に歪んでおり(中央値が平均より大きい)、平均を最小化する回帰(二乗誤差)よりも中央値付近を最小化する分位点回帰の方がMAEが小さくなるためである。完了数はτと共に非単調で、予測期間と優先度の両方に影響される複雑な挙動を示す。
## 考察
Acela は「予測精度の最大化」ではなく「スケジューリング目的(効率とSLO遵守の両立)に沿った予測」を志向する点で、既存の学習ベース性能予測研究(CPR、Paragon、CALOREE、Seer 等、いずれも精度最大化が目的)と一線を画す。この立場は Ding+2019 と NURD(Ding+2022)の知見(精度向上が必ずしもシステム成果向上につながらない)をソフトウェアアップグレードという新領域に適用したものである。Table 4 の分析は、モデル選択を「精度が最良のモデル」ではなく「カスタムスコアが最小のモデル」に基づいて行うことの妥当性を裏付けている。
## 強み
- Meta 本番データセンターでの大規模実運用評価(400万件超の訓練データ、約100万件・198 UGでの評価)に基づく、実証性の高い成果(§6.1)。
- 「精度最大化」でなく「スケジューリング目的」を直接最適化するという設計思想が一貫しており、分位点回帰・カスタムスコア関数・ストラグラー除去の3技術がその思想を具体化する(§4)。
- 既存スケジューラへの非破壊的な統合(拡張レイヤーとしての Acela)により、実運用への展開障壁を下げている(§5)。
- 失敗モード分析(§5.1)とワーストケースの考察により、予測ベースシステムの運用上のリスクを率直に議論している。
## 弱点・課題
- Strawman・Naïve-ML は「1サーバーにつき1回しかアップグレードを経験しない」という制約のため本番デプロイでテストできず、シミュレーション比較(実測との乖離1%未満とされるが検証は限定的)にとどまる(§6.1)。
- 評価はファームウェアアップグレード8種に絞られており、OS・カーネル・ネットワークスイッチアップグレードでの定量評価は行われていない(§6.1で「対象外」と明言)。
- ワーストケース分析(一部アップグレードが大幅超過するシナリオ)は将来課題として明示的に残されている(§5.1)。
- コードとデータセットは執筆時点で未公開であり、外部での再現性は現時点で確認できない。