ローリングアップデート ろーりんぐあっぷでーと
簡単に言うとこんな感じ！
サービスを止めずにシステムを少しずつ入れ替えていく方法だよ！新幹線の車両を走りながら1両ずつ交換していくイメージ。全部を一気に止めずに済むから、ユーザーは気づかないうちにアップデートが完了するんだ！
ローリングアップデートとは
ローリングアップデート（Rolling Update）とは、システムやアプリケーションを更新する際に、稼働中のサーバーやコンテナを一度に全部止めるのではなく、少しずつ順番に入れ替えていくデプロイ（リリース）手法です。「ローリング（rolling）」は「転がるように順番に進む」という意味で、その名の通り更新が波のように広がっていきます。
従来のシステム更新では、「メンテナンス時間」を設けてサービスを全停止し、一括でアップデートするのが一般的でした。しかしインターネットサービスの普及により、24時間365日止められないシステムが増えてきた結果、稼働を維持しながら更新できるローリングアップデートが注目されるようになりました。特にKubernetes（クーバネティス）などのコンテナ管理基盤が普及した現代では、標準的なリリース戦略の一つとして広く使われています。
ローリングアップデートの仕組み
更新作業は「バッチ（塊）」単位で順番に行われます。たとえば10台のサーバーがあれば、2〜3台ずつ入れ替えていくイメージです。
| ステップ | 内容 |
|---|---|
| ① 一部を切り離す | 更新対象のサーバー（またはコンテナ）をロードバランサーから一時的に外す |
| ② 新バージョンを投入 | 切り離したサーバーに新しいバージョンをデプロイする |
| ③ 動作確認 | ヘルスチェックで正常動作を確認する |
| ④ 次のバッチへ | 問題なければ次のサーバー群に同じ手順を繰り返す |
| ⑤ 完了 | 全サーバーの入れ替えが終わったら更新完了 |
この間も更新されていないサーバーがトラフィック（通信）を受け続けるため、ユーザーからはサービスが止まって見えません。これをゼロダウンタイムデプロイと呼びます。
「波が転がる」で覚えよう
「ローリング＝波が転がる」イメージで覚えると◎。更新の波が端から端へゆっくり転がるように広がっていく様子がそのまま名前になっています。
主要パラメータ（Kubernetesの例）
Kubernetesでローリングアップデートを設定する際の代表的な設定値です。
| パラメータ | 意味 | 例 |
|---|---|---|
maxSurge | 同時に増やせる新バージョンPodの最大数 | 25%（10台なら2〜3台） |
maxUnavailable | 同時に停止を許容するPodの最大数 | 25% |
| 更新速度 | 上の2つのバランスで決まる | 速く or 安全重視 |
歴史と背景
- 1990年代: Webサービス黎明期。更新は深夜のメンテナンスウィンドウ（停止時間）で一括実施が当たり前だった
- 2000年代: 大規模ECサイト・SNSの台頭でダウンタイムの損失が顕在化。ロードバランサーを使った無停止デプロイの需要が高まる
- 2010年代前半: AmazonやGoogleが「1日に何百回もデプロイする」文化（DevOps）を公表。無停止デプロイが先進企業の常識に
- 2014年: Dockerの普及によりコンテナ単位でのデプロイが一般化し、ローリングアップデートが実装しやすくなる
- 2015年〜: Kubernetes 1.0リリース。ローリングアップデートが標準機能として組み込まれ、中小規模の開発チームにも普及
- 現在: クラウドネイティブ開発の標準パターンとして、ブルーグリーンデプロイやカナリアリリースと並ぶ主要手法に
他のデプロイ戦略との比較
ローリングアップデートは万能ではありません。目的に応じて他の手法と使い分けることが大切です。
| 手法 | 仕組み | ダウンタイム | コスト | リスク |
|---|---|---|---|---|
| ローリングアップデート | 少しずつ入れ替え | なし | 低〜中 | 新旧バージョン混在期間がある |
| ブルーグリーンデプロイ | 新環境を丸ごと用意して一瞬で切替 | なし | 高（2倍のリソース） | 切替は一瞬・失敗時の戻しが速い |
| カナリアリリース | 一部ユーザーだけに新バージョンを配布 | なし | 中 | 影響範囲を最小化して検証できる |
| 一括デプロイ（ビッグバン） | 全サーバーを止めて一気に更新 | あり | 低 | シンプルだが停止が必要 |
ローリングアップデートの注意点
- 新旧バージョンが一時的に混在する：データベースのスキーマ変更など、後方互換性のない変更があると問題が起きやすい
- 問題発生時の検知が遅れることがある：全台に広がってから不具合に気づくケースも。ヘルスチェックの精度が重要
- ロールバック（元に戻す）に時間がかかる：全台を戻すまでにまた時間が必要なため、ブルーグリーンより戻しが遅い
関連する規格・RFC
※ ローリングアップデート自体に特定のIETF RFC・ISO規格はありませんが、関連するKubernetesの設定仕様はCNCF（Cloud Native Computing Foundation）のドキュメントで定義されています。
関連用語
- ブルーグリーンデプロイ — 新旧2つの環境を用意してトラフィックを切り替えるデプロイ手法
- カナリアリリース — 一部のユーザーだけに新バージョンを先行配信して様子を見る手法
- Kubernetes — コンテナのオーケストレーション（管理・調整）を行うプラットフォーム
- CI/CD — ビルド・テスト・デプロイを自動化する開発プロセス
- ゼロダウンタイムデプロイ — サービスを止めずにシステムを更新するデプロイの総称
- ロードバランサー — 複数のサーバーにトラフィックを振り分ける装置・ソフトウェア
- コンテナ — アプリケーションとその実行環境をまとめてパッケージ化する技術
- DevOps — 開発（Dev）と運用（Ops）を連携させ、高頻度リリースを実現する文化・手法