## 定義 ライブアップグレードとは、稼働中のサーバーを停止・再インストールせずに、OS や主要なシステムコンポーネントを別バージョンへ移行する手法の総称である。大規模フリートでは「フラグデー(一斉切り替え)」を避けてサービス継続性を維持しながら移行するため、変更を細かく分割して段階的に適用することが核心となる。libc のような基盤コンポーネントの変更では、バイナリ互換性の確保やシンボリックリンクを用いた二重状態管理が必要になる。(Source: [[@2013__LISA__Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One]]) ## フラグデー回避の原則 フラグデー(多数の機械が一斉に全く異なる OS になる日)は以下の理由で避けるべきである: - フリート内の OS 多様性が監視・デバッグを複雑化する。 - 大規模では小さなバグが数千台に乗算される。 - テストが困難で、問題発生時の影響範囲が大きい。 代替戦略は「OS の構成要素を一度に一つずつ移行する」ことであり、各ステップを個別にテストして必要であればロールバックできる状態を保つ。 ## Google の段階的 rpm → dpkg 移行アプローチ 1. 新ディストリビューション(ProdNG deb)のパッケージを旧パッケージ形式(rpm)に変換。 2. 各リリースサイクルで 5〜10 パッケージずつ旧イメージに注入。 3. libc は ELF ヘッダーのバイナリパッチで旧環境上での新バイナリ動作を実現。 4. 約 3〜4 年で全パッケージを置き換え後、一括切り替え。 5. 最終切り替え時の差分はほぼ initscripts とパッケージ DB のみ。 ## 横断的知見 - 「ライブアップグレード」(サービス無停止で差し替える技術)と「アップグレード窓を伴う計画的アップグレード」は別の前提を置く隣接概念であることが2ソース目([[@2026__MLSys2026__Cost-aware Duration Prediction for Software Upgrades in Datacenters]])との突き合わせで明確になった。前者(Google の rpm→dpkg 移行)はサーバーを稼働させたまま段階的にコンポーネントを置き換えることで「アップグレード窓」自体を不要にする方向性であるのに対し、後者(Meta の Acela)はサーバーを一時的にサービスから外す「窓」の存在を前提として、窓内での完了率(達成率SLO)を守りながら多数サーバーへのスケジューリングを最適化する方向性を取る。同じ「大規模フリートのソフトウェア更新」という問題でも、採る戦略(無停止差し替え vs 計画停止+スケジューリング最適化)が全く異なる。(Source: [[@2026__MLSys2026__Cost-aware Duration Prediction for Software Upgrades in Datacenters]] §2.1) - **イミュータブルなインフラストラクチャは、ライブアップグレードそのものを不要にする第3の戦略を提示する**: Google の rpm→dpkg 移行(2013 LISA)は稼働中サーバーの構成要素を段階的に置き換える「無停止差し替え」戦略を取り、Meta の Acela は計画停止窓内でのスケジューリング最適化という戦略を取る(→ 既存の横断的知見)。[[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] が描くイミュータブルなインフラストラクチャは、これら2戦略のどちらとも異なる第3の戦略を取る——「実行中のインスタンスはローンチ後、Puppet、Chef、さらには SSH などのツールを通じて更新されることが一切ない」(冒頭, §24.1)と明言し、稼働中サーバーの構成要素をその場で置き換えるのではなく、更新済みのベースイメージから起動した新しいインスタンスに交換したうえで旧インスタンスを終了する。Google の段階的コンポーネント差し替えが「1つずつ入れ替えることでフラグデーを避ける」漸進的な**内部変更**であるのに対し、イミュータブルなインフラストラクチャの交換は個々のコンポーネントを差し替えず**インスタンス全体を丸ごと入れ替える**点で、無停止差し替えという同じ目的(フラグデー回避・サービス継続性維持)を全く異なる粒度の操作で達成している。(Source: [[@2013__LISA__Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One]], [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] 冒頭, §24.1) ## 未解決の問い - コンテナ化・Blue-Green デプロイ・不変インフラが普及した 2020 年代においても、ベアメタルサーバーフリートでのライブアップグレードは同様の手法が有効か? [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] はイミュータブルなインフラストラクチャがライブアップグレードを不要化する戦略を示すが、これはクラウド上の仮想インスタンス/コンテナを前提としており、Google の rpm→dpkg 事例のようなベアメタルフリートへそのまま適用できるかは未検証(ベアメタルは「交換」のコストが仮想インスタンスより高い)。 - libc バージョン差を ELF バイナリパッチで吸収するアプローチは、現代の Linux ディストリビューションにも適用可能か? - 段階的パッケージ移行の「1 サイクルに何パッケージまで」という判断はどのような基準で決めるべきか? - Debian vs Ubuntu の柔軟性の差(中間リリーススキップ対応)は現在(2024 年時点)でも有効な選択基準か? - ファームウェア・BIOS・ハードウェア関連のアップグレード([[@2026__MLSys2026__Cost-aware Duration Prediction for Software Upgrades in Datacenters]]が扱う BIC/BIOS/CPLD 等)は原理的にサービス無停止化(ライブアップグレード)が困難で「窓」を前提にせざるを得ないのか、それとも技術的には可能で単に採用されていないだけか? ## 関連 - [[@2013__LISA__Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One]] — Google での実証 - [[@2026__MLSys2026__Cost-aware Duration Prediction for Software Upgrades in Datacenters]] — 対照的なアプローチ(窓を前提としたスケジューリング最適化) - [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] — 第3のアプローチ(ライブアップグレード自体を交換で回避) - [[ソフトウェアアップグレードスケジューリング]] — 窓を前提とする場合のスケジューリング問題 - [[ファイルレベル同期]] — ライブアップグレードを可能にする基盤技術 - [[イミュータブルインフラストラクチャ]] — ライブアップグレードを不要化する対抗戦略 - 関連 MOC: [[SRE - MOC]] ## 出典 - [[@2013__LISA__Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One]] - Jonah Horowitz, 「24章 イミュータブルなインフラストラクチャと SRE」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 冒頭, §24.1.