## 定義 ソフトウェアアップグレードスケジューリングとは、データセンター規模で多数のサーバーに対しファームウェア・OS・カーネル等のソフトウェアアップグレードを、固定長の「アップグレード窓」内で完了させるよう計画・順序付けする問題である。サービスジョブ(SJobs)のスケジューリングとは前提が異なる: SJobs はサーバー間で柔軟に再配置できレイテンシがSLOの主眼になるのに対し、SUs は特定のサーバーに固定的に割り当てられ、SLOは「アップグレード窓内に一定割合(例: 95%)のアップグレードを完了させること」という達成率ベースの制約になる。この「固定サーバー割り当て+達成率SLO」という組み合わせが SU スケジューリングを SJob スケジューリングより難しくしている。(Source: [[@2026__MLSys2026__Cost-aware Duration Prediction for Software Upgrades in Datacenters]] §2.1) Meta のデータセンターでは、ラックを共有する電源・スイッチ単位でサーバー群が「アップグレードグループ(UG)」を構成し、各 UG は通常運用・バッファ(アップグレード中サーバーのサービスジョブの退避先)・オーバーフロー(故障サーバーのジョブの退避先)の役割をサイクルごとにローテーションしながら、UG 単位で順にアップグレードを実施する「サークル型(circle-based)」プロセスを取る。UG 内では移行先バッファ容量の制約から同時アップグレード可能なサーバー数が制限され(例: 25%)、部分的に逐次実行される。(Source: [[@2026__MLSys2026__Cost-aware Duration Prediction for Software Upgrades in Datacenters]] §2.2) ## 横断的知見 - 固定・最悪ケース想定の保守的スケジューリングは、達成率SLOを安全に満たす一方で、実運用ではアップグレード窓の利用率を20〜40%程度まで低下させる主要因になる(16拠点・5ヶ月の実測)。期間予測を導入し窓利用率を上げようとすると、SLO違反のリスクとのトレードオフが生じる。(Source: [[@2026__MLSys2026__Cost-aware Duration Prediction for Software Upgrades in Datacenters]] §1, Figure 1) - SU スケジューリングにおける期間予測は、単純な予測精度(MAE等)の最大化ではなく、非対称な誤予測コスト(過小予測はSLO違反・過大予測は効率低下だが後者の方が許容度が高い)を反映した目的関数で評価すべきである。対称損失(L2/L1/Huber)で学習したモデルは高精度でもSLOを満たせないことがある。(Source: [[@2026__MLSys2026__Cost-aware Duration Prediction for Software Upgrades in Datacenters]] §6.5) - (まだ1ソース。他のジョブスケジューリング/期間予測系文献と突き合わせた横断観察は今後追記) ## 未解決の問い - Acela の分位点回帰・カスタムスコア関数・ストラグラー除去というアプローチは、Meta 以外のハイパースケールデータセンター(異なるハードウェア構成・UG設計)にどの程度一般化するか? - 論文が将来課題として残した「一部アップグレードが大幅に窓を超過するワーストケース」の分析は、どのような頑健化(テール実行時間の制御、オペレーターへの明確なシグナル)で解決できるか? - サービスジョブスケジューリングの期間予測研究(3Sigma、TetriSched、SLearn等、関連研究として引用されるが本 vault では未 ingest)と比較したとき、SU スケジューリング固有の課題(固定サーバー割り当て、達成率SLO)はどこまで技術的に共通で、どこから分岐するか? - [[ライブアップグレード]](サービス無停止でのOS/ライブラリ差し替え)を採用できる場合、そもそも「アップグレード窓」を前提としたスケジューリング問題自体が不要になるのか、それとも別の制約(段階的ロールアウトの順序付け等)として形を変えて残るのか? ## 関連 - [[@2026__MLSys2026__Cost-aware Duration Prediction for Software Upgrades in Datacenters]] — Meta 本番データセンターでの実証(Acela) - [[ライブアップグレード]] — サービス無停止でのアップグレード技術。本概念は「窓を伴う計画的アップグレード」の**スケジューリング**問題である点で異なる前提を置く - [[サービスレベル目標]] — SU スケジューリングのSLOは「アップグレード窓内の達成率」という特殊な形を取る