ローリングアップデートとは？仕組みとKubernetes・ECSの設定値・採用判断を解説

ローリングアップデートは、稼働中のインスタンスを一度に全部ではなく少しずつ新しいバージョンへ入れ替える更新方式です。KubernetesのDeploymentではstrategyを書かなければこの方式が選ばれ、maxSurgeとmaxUnavailableはどちらも25%が既定になります。難所は仕組みの理解ではなく、新旧のバージョンが同じ時間帯に本番トラフィックを受けるという前提に、アプリとデータベースが耐えられるかの見極めにあります。この記事では既定値の意味と計算、終了処理の作り込み、Amazon ECSやEC2 Auto Scalingでの相当設定、そして見送るべき条件までを実装目線で追いました。数値はKubernetesとAWSの各公式ドキュメントを2026年8月5日に参照した内容に合わせています。

まとめ：ローリングアップデートが成立する条件と、設定値を決める順序

先に結論を置きます。ローリングアップデートが使えるのは、新旧2つのバージョンが同時に本番トラフィックを受けても壊れないアプリだけ。ここを確認せずに設定値だけ触ると、無停止に見えて特定の割合のリクエストだけが失敗する状態を作ります。

設定値は順番に決めます。最初がヘルスチェック。配信可能と判定する基準が甘いと、起動途中のプロセスへトラフィックが流れ込みます。次が終了処理。ロードバランサーの登録解除を待たずにプロセスを止めれば、処理中の要求が切断されます。入れ替え幅の指定は最後で構いません。maxSurgeやmaxUnavailableは速度を決めるだけで、安全性は前の2つが担保します。

データベースを共有する構成では、スキーマ変更を先に出して後から使う二段階に必ず割ります。列の削除やリネームをアプリのデプロイと同時に出すと、切り戻しの経路が消えます。ローリングアップデートは切り戻しが最も遅い方式なので、戻れる設計を先に用意しておいてください。

ローリングアップデートの定義と、新旧バージョンが同時に走る時間帯の性質

この方式が扱う対象は「どのインスタンスから止めるか」ではなく「止める前に何台立てておくか」です。台数の制約を先に理解すると、後の設定値が計算できます。

Deploymentの既定戦略として置き換えが進む順序と観測できる中間状態

Kubernetes公式ドキュメントによれば、Deploymentの.spec.strategy.typeは指定しない場合RollingUpdateになります。Podテンプレートを書き換えると新しいReplicaSetが作られ、新旧2つのReplicaSetのレプリカ数を少しずつ動かす形で置き換えが進みます。

流れは単純です。新ReplicaSetのレプリカを増やし、新Podがreadyになるのを待つ。確認できたら旧ReplicaSetを減らす。この往復を旧レプリカがゼロになるまで繰り返し、途中では新旧の合計が指定レプリカ数を上回る瞬間が観測できます。

押さえたいのは、置き換えの単位がPodであってノードではない点です。ノードのOSやkubeletの更新も同じ言葉で呼ばれますが、制御する仕組みは別物になります。基盤側の前提はKubernetesの仕組みとDockerとの違いで扱いました。

Recreate・ブルーグリーン・カナリアとの違いと使い分けの境界線

4方式の差は、同時稼働の有無と必要になる余剰リソースの量に集約されます。

境界線は「切り戻しに何分かけられるか」で引きます。数秒で戻す必要があるならBlue/Greenでの面切り替え、本番トラフィックの一部だけで検証したいならカナリアリリースによる段階的な露出制御を選びます。ローリングは倍のリソースを持たずに無停止を得る代わり、切り戻しにも同じ時間がかかる方式です。

新旧同時稼働が前提になることで壊れる箇所と、影響が出る時間の幅

更新中は、同じURLへの連続したリクエストが旧バージョンと新バージョンに振り分けられます。ここで壊れるのは主に4箇所。APIのレスポンス形式、共有データベースのスキーマ、キャッシュのキー設計、バックグラウンドジョブのメッセージ形式です。

影響が出る時間の幅は、レプリカ数と入れ替え幅とヘルスチェック待ちの積で決まります。レプリカ20台、maxSurge 25%（5台ずつ）、1台がreadyになるまで20秒なら、単純計算で80秒前後は新旧が混在する。minReadySecondsを足せばさらに伸びます。数分間は両方が動く前提で互換性を設計してください。

KubernetesのDeploymentで無停止を成立させる設定値と既定値の落とし穴

既定値のままでも置き換えは進みます。ただし「進むこと」と「落とさないこと」は別で、後者は明示設定が要ります。

maxSurgeとmaxUnavailableの既定25%が決める同時入れ替え数の計算

公式ドキュメントによれば、RollingUpdate時のmaxSurgeとmaxUnavailableはいずれも既定25%です。maxSurgeは指定レプリカ数を超えて作れるPod数の上限、maxUnavailableは同時に利用不可にしてよいPod数の上限を表します。パーセント指定の場合、maxSurgeは切り上げ、maxUnavailableは切り捨てで整数化されます。

レプリカ10で既定のままなら、上限13台まで増やせて、常時8台は使える状態に保たれる計算です。ここで見落とされるのが、maxSurgeを大きくするとクラスタに空き容量が必要になる点。ノードに余裕がなければ新Podはスケジュールできず、置き換えは進まないまま待機します。

両方を0にする設定は許されません。片方を0にする使い分けは有効で、余剰リソースを1台も出せない環境ではmaxSurge 0とmaxUnavailable 1、逆に一時的にも可用性を落とせない環境ではmaxSurge 1とmaxUnavailable 0を選びます。後者は入れ替えに時間がかかる代わりに、更新中も常に指定レプリカ数が稼働します。

readinessProbeとminReadySecondsが決める流入開始の判定

readinessProbeを書かないPodは、コンテナが起動した時点でreadyとみなされます。アプリの初期化が終わる前にEndpointSliceへ登録され、そこへ届いたリクエストが失敗する。無停止更新の失敗として最も多い型がこれにあたります。

プローブの既定値は、initialDelaySeconds 0秒、periodSeconds 10秒、timeoutSeconds 1秒、successThreshold 1、failureThreshold 3。timeoutSecondsが1秒しかない点は要注意で、初期化中のアプリが応答を返しきれずタイムアウト扱いになる構成では明示的に伸ばします。readinessが失敗するとEndpointSliceコントローラがPodのIPをエンドポイントから外すため、コンテナは再起動されずトラフィックだけが止まる。この挙動差はLiveness ProbeとReadiness・Startupの使い分けで整理しました。

minReadySecondsの既定は0秒です。readyになった直後を「安定」と判定してしまうため、起動直後に落ちるアプリでは全レプリカが順に壊れます。10秒から30秒を入れておくと、次のPodへ進む前に初期の異常を捕まえられます。

preStopとterminationGracePeriodSecondsによる終了処理

Podの削除では、EndpointSliceからの除外とコンテナへのSIGTERM送信が並行して走ります。順序が保証されないため、ロードバランサーがまだ古いPodへ振っている最中にプロセスが終了する競合が起きます。

対処はpreStopフックに数秒の待機を入れることです。SIGTERMの前にフックが走るので、その間にエンドポイントの除外がロードバランサーへ伝播します。待機の長さはロードバランサーの振り分け方式と接続の扱いを踏まえ、登録解除の遅延設定に合わせてください。

terminationGracePeriodSecondsの既定は30秒。preStopの待機と処理中リクエストの最長処理時間の合計がこれを超えるとSIGKILLで強制終了されます。20秒待たせて長いバッチを抱えるコンテナなら、猶予を60秒以上へ伸ばす調整が要ります。

progressDeadlineSecondsの失敗判定と手動ロールバックの手順

progressDeadlineSecondsの既定は600秒です。この時間内に進捗がなければDeploymentのconditionにProgressingのFalseが立ち、失敗として記録されます。ただしKubernetesはこの判定で自動的に元へ戻しません。止まるだけです。

切り戻しはkubectl rollout undoで行い、直前のリビジョンのReplicaSetを再びスケールアップします。revisionHistoryLimitの既定10により過去10世代が保持され、番号指定で任意世代へも戻せる。自動化するならkubectl rollout statusの終了コードが非ゼロのときにundoを走らせる形が最小構成です。

Amazon ECSとEC2 Auto Scalingのローリング設定と既定値の挙動差

AWSでも同じ考え方が別の名前で用意されています。既定値がKubernetesと違うため、そのまま移植すると必要なキャパシティを読み違えます。

ECSの最小正常率100%と最大200%が要求する余剰キャパシティ

ECS APIのDeploymentConfigurationによれば、REPLICAスケジューラを使うサービスのmaximumPercent既定は200%、minimumHealthyPercent既定は100%です。desiredCountが4なら、更新中は最大8タスクまで増やせて、常時4タスクは健全な状態に保たれます。つまり既定のままだと更新のたびに倍のキャパシティが要ります。

minimumHealthyPercentは切り上げ、maximumPercentは切り捨てで整数化されます。最大125%でdesiredCountが3なら計算結果は3のままとなり、スケジューラは新しいタスクを1つも開始できません。デプロイが進まない設定を作る典型がこれです。

DAEMONスケジューラでは既定が変わり、minimumHealthyPercentはCLI・SDK・APIで0%、マネジメントコンソールで50%になります。同じ操作でもインターフェースで結果が変わるため、TerraformなどのコードからはCLI側の既定が適用される前提で明示指定してください。

デプロイサーキットブレーカーとCloudWatchアラームによる失敗判定

ECSのローリングデプロイには失敗を検知する仕組みが2つあります。デプロイサーキットブレーカーはタスクが起動できない状況を捕まえ、CloudWatchアラームはアプリのメトリクス悪化を捕まえる。両方を有効にした場合、どちらかの条件を満たした時点でデプロイが失敗扱いになります。

使い分けの軸は検知したい事象です。イメージのpull失敗やヘルスチェック不通で起動しないケースはサーキットブレーカー、起動はするがエラー率やレイテンシが悪化するケースはアラームが担当します。いずれもロールバックオプションで直前の正常なリビジョンへ戻せる。

2026年8月時点のECSはstrategyにROLLINGのほかBLUE_GREEN・LINEAR・CANARYを持ち、bakeTimeInMinutesやlifecycleHooksで切り替え後の待機や検証を差し込めます。従来型の構成はAWS CodeDeployのIn-Place・Blue/Greenの違いにまとめました。

インスタンスリフレッシュの最小正常率90%とチェックポイント分割

EC2 Auto Scalingでは、インスタンスリフレッシュがローリングアップデートに相当します。AWS公式の既定値一覧によれば、インスタンスメンテナンスポリシーを設定していない場合の最小正常率は90%、最大正常率は100%です。desiredCapacityが10なら、常時9台をInServiceに保ちながら1台ずつ入れ替える計算になります。

最大正常率が100%という既定は、KubernetesのmaxSurge相当がゼロという意味です。新しいインスタンスを先に立ち上げてから古いものを落とす動きにはならず、先に落としてから作る順序になります。起動に時間のかかるAMIでは、この既定のままだと更新中の処理能力が実質9割で長時間推移します。

段階的に止めたい場合はチェックポイントを使います。既定は無効で、チェックポイント遅延の既定値は3600秒。CheckpointPercentagesに20と50を指定すれば、2割と5割の時点で1時間ずつ待機し、その間に手動検証を挟めます。自動ロールバックも既定は無効です。

新旧同時稼働に耐えるデータベース移行の順序と後方互換を壊す変更

アプリ側の設定を丁寧に詰めても、共有データベースのスキーマ変更が同時に出れば更新は失敗します。順序の設計がここでの本題です。

データベースの列追加・削除・改名を拡張と縮約に分ける二段階手順

安全な進め方は、スキーマを広げるリリースと狭めるリリースを別々のデプロイに分ける手順です。拡張フェーズでは新しい列やテーブルを追加するだけで、既存の列には触れません。縮約フェーズは、旧バージョンが完全に消えたことを確認してから実行します。

1. 新しい列をNULL許容で追加する（旧バージョンは無視できる）
2. 新旧どちらでも読める状態でアプリをローリングアップデートする
3. 既存データを新しい列へ埋める移行処理を流す
4. 旧バージョンが残っていないことを確認する
5. 不要になった旧列を削除する別リリースを出す

列のリネームは、この分割では扱えない変更の代表格です。追加・二重書き込み・移行・削除の4リリースに割るか、リネームを諦めて新しい名前の列を足す判断のどちらかを選びます。1リリースで済ませようとした時点で無停止は成立しません。

切り戻し時に新バージョンの書き込みが壊れる条件と二重書きの期間

見落とされやすいのが、前へ進むときではなく戻るときの互換性です。新バージョンが新しい列にだけ書き込んでいた状態で旧バージョンへ切り戻すと、更新中に書かれたデータを旧コードが読めません。データは消えていないのに画面から消えたように見える障害がここで起きます。

回避策は、拡張フェーズの間だけ旧列と新列の両方へ書く二重書き込みです。期間は切り戻し判断のタイムリミットに合わせ、障害を1日以内に検知して戻す運用なら次のリリースサイクルまで残します。ただし永久に残すとコードが腐るので、削除予定日はコメントではなくチケットに置いてください。

NOT NULL制約やユニーク制約の追加も同型です。旧バージョンが制約を知らずにINSERTすると失敗するため、制約の追加は縮約フェーズへ回します。

長時間ロックを伴う移行をデプロイから切り離す実行手順と判断基準

大きなテーブルへのインデックス追加やALTER TABLEは、実行中にテーブルロックを取ることがあります。デプロイパイプラインの中でこれを走らせると、アプリの入れ替えは進んでいるのにデータベースが応答しない状態が生まれ、ヘルスチェックが落ちて置き換えが止まります。

判断基準はシンプルで、実行時間がヘルスチェックのタイムアウトを超えうる移行はデプロイから切り離します。PostgreSQLのCREATE INDEX CONCURRENTLYのようなオンライン実行手段があるならそれを使い、無いなら移行専用のジョブとして別枠で流す。パイプラインの組み方そのものはCI/CDのパイプライン設計の考え方が下地になります。

分離するとリリース手順は複雑になります。それでも一体化を避けるのは、データベース側の失敗がアプリの切り戻し経路まで巻き込むからです。

ローリングアップデートを見送る条件と代わりに選ぶ方式の判断基準

この方式が向かない構成は実在します。無理に通そうとして起きる失敗を先に潰しておきます。

セッション固定やインメモリ状態を持つ構成で壊れる整合性の中身

アプリケーションサーバのメモリにセッションを持つ構成では、旧Podが落ちた瞬間にそのPodへ固定されていた利用者がログアウトします。更新のたびに一定割合の利用者が作業を失う。これは設定値では直せません。

解決の方向はセッションの外出しです。RedisやDynamoDBへ移し、どのインスタンスでも同じセッションを読める状態にする。この改修が終わるまでは、利用者が少ない時間帯にRecreateで一括更新するほうが、中途半端な無停止より被害が小さくなります。

WebSocketのような長時間接続も同型です。接続はPodの終了で切れるため、クライアント側に再接続処理が無ければ更新のたびに機能が止まります。

PodDisruptionBudgetがローリング更新を守らないという誤解の訂正

PodDisruptionBudgetを設定すれば更新中の可用性が守られる、という理解は誤りです。Kubernetes公式のDisruptionsドキュメントは、DeploymentやStatefulSetといったワークロードリソースがローリングアップデートを行う際、PDBによる制限を受けないと明記しています。

PDBが効くのはEviction APIを経由する中断、つまりkubectl drainによるノードの退避やクラスタの縮小です。アプリの更新中の可用性は、あくまでワークロード側のspec、Deploymentならstrategyの設定で制御します。

両方が必要になる場面もあります。ノードのローリング入れ替えとアプリのデプロイが重なるとPodが二重に減るため、メンテナンス作業とリリースの時間帯を分けるか、PDBのminAvailableをレプリカ数から逆算して設定してください。

ローリングを見送る具体条件と、代替方式へ切り替える判断の実務

採用しないと判断してよい条件を4つ挙げます。第1に、セッションや接続の状態をインスタンス内に持ち、外出しの見込みが立たないアプリ。第2に、切り戻しの許容時間が入れ替え所要時間より短い決済系や基幹系。第3に、スキーマ変更を二段階に割れない事情があるケース。第4に、レプリカが1台しかないサービスです。1台では入れ替え中の可用性が確保できないため、Recreateと変わりません。

1と3に当てはまるならブルーグリーン、2に当てはまるならカナリアかブルーグリーンへ寄せます。4は方式の問題ではなく冗長化の問題なので、まずレプリカを増やす話から始めます。

既存システムでこの判断に踏み込むと、セッション外出し・スキーマ移行の分割・ヘルスチェックの作り込みといった改修が同時に必要になります。手が足りない場合は、保守運用・内製化支援で現行構成の棚卸しからデプロイ手順の整備までを引き受けています。

よくある質問

ローリングアップデートの設計で実際に問い合わせの多い論点を5つ取り上げます。

ローリングアップデートとローリングデプロイは違うものですか？

実務上は同じ意味で使われています。Kubernetesの文脈ではRollingUpdateという戦略名が公式表記で、ECSでは「ローリング更新」や「ROLLINGデプロイ戦略」と呼ばれます。厳密に分けるなら、アップデートはノードのソフトウェア更新まで含み、デプロイはアプリのリリースを指すという程度の差。設計上の論点は同じで、入れ替え幅とヘルスチェックに集約されます。

maxSurgeとmaxUnavailableは両方0にできますか？

できません。両方を0にするとPodを作ることも止めることもできず置き換えが進まないため、Kubernetesはこの組み合わせを拒否します。片方を0にする指定は有効で、余剰リソースを出せない環境ならmaxSurge 0とmaxUnavailable 1、更新中も指定レプリカ数を維持したいならその逆を選びます。

ローリングアップデートならダウンタイムは本当にゼロですか？

設定が揃っていなければゼロにはなりません。readinessProbeが無いと初期化前のPodへトラフィックが流れ、preStopが無いと終了直前のPodへ振られた要求が切断されます。この2つが揃って初めて、利用者から見た停止時間が消える。加えて、新旧が同時に動く時間帯にAPIやスキーマの互換性が崩れていれば、サーバは200を返しているのに画面だけが壊れます。

ロールバックにはどれくらい時間がかかりますか？

往路と同じだけかかると見積もってください。kubectl rollout undoで戻す動作もローリングアップデートとして実行されるため、レプリカ20台・5台ずつ・1台20秒の構成なら復旧まで80秒前後が目安になります。数秒で戻す必要があるならブルーグリーンを選ぶ判断になります。切り戻し時間の要件は、方式選定の入口で確認しておく項目です。

ステートフルなアプリでもローリングアップデートは使えますか？

データの持ち方によります。KubernetesのStatefulSetもRollingUpdateを既定の更新戦略に持ち、序数の大きいPodから1つずつ入れ替えます。partitionを指定すれば、その番号以上のPodだけを段階的に更新する運用も可能。ただしレプリカ間でデータ同期が要るミドルウェアでは各製品の公式手順に従うべきで、Deploymentと同じ感覚では扱えません。

関連記事

• ブルーグリーンデプロイメントとは：面ごと切り替える方式で、切り戻し速度が要件のときの代替になります
• カナリアリリースとは：トラフィック比率で露出を絞る方式で、本番検証を挟みたい場合に選びます
• AWS CodeDeployとは：AWS側の失敗判定と自動ロールバックの設定を具体的に確認できます
• Liveness Probeとは：readiness・startupとの役割分担で、流入判定の設計を詰められます
• CI/CDとは：デプロイ自動化と移行ジョブを分離する前提の考え方を整理しています