## 定義 ライブアップグレードとは、稼働中のサーバーを停止・再インストールせずに、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 のみ。 ## 横断的知見 - (まだ 1 ソース。2 ソース目以降で横断観察を追記予定) ## 未解決の問い - コンテナ化・Blue-Green デプロイ・不変インフラが普及した 2020 年代においても、ベアメタルサーバーフリートでのライブアップグレードは同様の手法が有効か? - libc バージョン差を ELF バイナリパッチで吸収するアプローチは、現代の Linux ディストリビューションにも適用可能か? - 段階的パッケージ移行の「1 サイクルに何パッケージまで」という判断はどのような基準で決めるべきか? - Debian vs Ubuntu の柔軟性の差(中間リリーススキップ対応)は現在(2024 年時点)でも有効な選択基準か? ## 関連 - [[@2013__LISA__Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One]] — Google での実証 - [[ファイルレベル同期]] — ライブアップグレードを可能にする基盤技術 - 関連 MOC: [[SRE - MOC]] ## 出典 - [[@2013__LISA__Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One]]