システムの更新作業においてサービスを停止せずにアップデートしたいというニーズは、現代のWeb運用では当然の要求となっています。
この課題を解決するデプロイメント手法が「ローリングアップデート」です。
本記事では、ローリングアップデートの意味・仕組み・メリット・デメリット・実践的な方法を、デプロイメント・サービス停止なし・段階的更新・システム運用の観点から詳しく解説していきます。
DevOpsエンジニア・インフラエンジニア・SREの方はもちろん、サービスの安定した更新方法を探している方にぜひ参考にしていただける内容です。
ローリングアップデートはKubernetesをはじめ多くのプラットフォームで標準的に採用されているデプロイメント手法です。
その仕組みを理解することが、現代のクラウドネイティブな運用の基礎となるでしょう。
ローリングアップデートとは何か？サービス停止なしのデプロイの仕組み
それではまず、ローリングアップデートの基本的な意味と仕組みについて解説していきます。
ローリングアップデート（Rolling Update）とは、複数のサーバーやコンテナインスタンスを一度にすべて更新するのではなく、少数ずつ順番に段階的に更新していくデプロイメント手法です。
「ローリング（rolling）」は「転がりながら進む」というイメージであり、更新の波が少しずつ全体に広がっていく様子を表しています。
【ローリングアップデートの基本的な流れ（インスタンス4台の例）】
初期状態：インスタンスA・B・C・D（すべてv1.0で稼働）
↓
ステップ①：インスタンスAをロードバランサーから切り離してv2.0に更新→稼働確認→ロードバランサーに追加
↓
ステップ②：インスタンスBを同様に更新（A・C・DはまだV1.0で継続稼働）
↓
ステップ③：インスタンスCを更新
↓
ステップ④：インスタンスDを更新
↓
完了：全インスタンスがv2.0で稼働
→ 各ステップで一部のインスタンスが旧バージョンで継続稼働するためサービスは停止しない
この段階的な更新アプローチにより、常に一部のインスタンスが稼働し続けるためユーザーへのサービスは停止しません。
また問題が発生した場合にも、すべてのインスタンスが更新される前に検出できるため、影響範囲を最小限に抑えることができます。
ローリングアップデートのメリットとデメリット
続いては、ローリングアップデートのメリットとデメリットについて確認していきます。
| メリット | 内容 |
|---|---|
| サービス継続 | 更新中もサービスが停止しないためユーザーへの影響が最小化される |
| リスクの分散 | 問題が発生しても全体に広がる前に検出・対応できる |
| 追加リソース不要 | Blue/Greenデプロイと異なり新旧2系統の環境を用意する必要がない |
| 段階的な検証 | 更新したインスタンスの動作を確認しながら進められる |
| デメリット | 内容 |
|---|---|
| 旧新バージョン混在 | 更新中は旧バージョンと新バージョンが同時稼働するため互換性が必要 |
| 更新に時間がかかる | インスタンス数が多い場合は更新完了までに時間がかかる |
| ロールバックが複雑 | 部分更新済みの状態からのロールバックは手順が複雑になる場合がある |
旧バージョンと新バージョンが混在して稼働する期間があるため、APIの後方互換性・データベーススキーマの互換性・セッション管理の互換性を事前に確保することがローリングアップデート成功の前提条件です。
互換性が確保できない場合は、ブルーグリーンデプロイメントやカナリアリリースなど別の手法を検討することが必要です。
Kubernetesでのローリングアップデートの仕組みと設定
続いては、Kubernetesでのローリングアップデートの仕組みと設定について確認していきます。
Kubernetesでは、DeploymentリソースのデフォルトのデプロイメントStrategy（戦略）が「RollingUpdate」です。
【KubernetesのDeploymentでのRollingUpdate設定例】
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1 # 同時に停止できるPodの最大数
maxSurge: 1 # 一時的に追加できるPodの最大数
template:
spec:
containers:
– name: my-app
image: my-app:v2.0 # 新バージョンのイメージに更新
「maxUnavailable」は更新中に同時に停止できるPodの最大数であり、「maxSurge」は一時的に追加できるPodの最大数です。
maxUnavailable=0・maxSurge=1と設定すると、常に指定レプリカ数のPodが稼働し続けながら新Podを1台ずつ追加・旧Podを削除するゼロダウンタイムの更新が実現します。
Kubernetesのローリングアップデートは「kubectl rollout status deployment/my-app」コマンドで進行状況を確認でき、問題があれば「kubectl rollout undo deployment/my-app」で直前のバージョンに戻すことができます。
ローリングアップデートと他のデプロイ戦略の使い分け
続いては、ローリングアップデートと他のデプロイ戦略の使い分けについて確認していきます。
| デプロイ戦略 | 特徴 | 向いている場面 |
|---|---|---|
| ローリングアップデート | 段階的に更新・追加リソース不要 | 標準的な更新・後方互換性がある場合 |
| Blue/Greenデプロイ | 新旧2系統を用意して瞬時に切り替え | 即時ロールバックが必要・破壊的変更 |
| カナリアリリース | 一部ユーザーにのみ新バージョンを提供 | リスクの高い機能・段階的な検証 |
| Recreateデプロイ | 全インスタンスを停止してから新バージョンを起動 | 互換性がない変更・ダウンタイム許容時 |
ローリングアップデートは「追加リソースコストなし・サービス継続・段階的リスク管理」というバランスの良い特性から、多くの本番環境での標準的なデプロイ戦略として採用されています。
データベーススキーマの変更を伴う場合や新旧互換性が確保できない場合はBlue/Greenデプロイが適しており、機能の段階的な展開には追加でカナリアリリースと組み合わせる戦略が有効です。
まとめ
ローリングアップデートは複数のインスタンスを少数ずつ段階的に更新していくデプロイメント手法であり、サービスを停止せずにシステムを更新できます。
追加リソース不要・リスクの分散・段階的な検証が主なメリットであり、旧新バージョンの互換性確保が成功の前提条件です。
KubernetesではDeploymentのRollingUpdate戦略が標準であり、maxUnavailableとmaxSurgeの設定でゼロダウンタイム更新が実現します。
Blue/Greenデプロイやカナリアリリースと比較して、標準的な更新には最もバランスが良い手法です。
ローリングアップデートを正しく活用してサービスの継続性を保ちながら安全なシステム更新を実現していただければ幸いです。
