【ろーりんぐあっぷでーと】
ローリングアップデート とは?
最終更新:
💡 サービスを止めずに1台ずつ入れ替える「無停止アップデート」
複数台のサーバーを少しずつ順番に新バージョンに更新していくデプロイ手法。全台を一斉に止めず、残りのサーバーで処理を続けながら更新するため、条件が整えばサービスを止めずに入れ替えられる。
📌 このページのポイント
- サーバーを1台ずつ(または数台ずつ)順番に新バージョンへ更新する
- 更新中も残りのサーバーがリクエストを処理するので、台数に余裕があり準備完了の確認が正しければ停止なしで更新できる
- 問題が起きたら更新を止めて旧バージョンへ戻せるが、Kubernetesは停滞を報告するだけで自動では戻さない
- KubernetesのDeploymentでは既定の更新戦略になっている
ローリングアップデートって全部一度に更新するのとどう違うの?
全台一斉更新だと、その間サービスが止まるよね。ローリングアップデートは例えば10台中2台ずつ更新して、残り8台でリクエストを処理し続けるんだ。全部終わるまで時間はかかるけど、残りの台数で負荷を支えられて、新しいサーバーが準備できてから振り分ければ、利用者は停止に気づかずに済むよ。
Blue/Greenデプロイとの違いは?
Blue/Greenは旧環境と新環境を両方用意して、通信の行き先を一度に切り替える方法だよ。切り替えも戻すのも早いけど、切り替えの間は環境を2つ分動かすことになる。ローリングアップデートは追加で用意するサーバーが少なくて済むのがメリットだね。
ローリングアップデートの途中で問題が起きたらどうするの?
新バージョンのサーバーが準備できたかをヘルスチェックで確認して、異常があれば更新を止めるよ。Kubernetesでは`maxUnavailable`と`maxSurge`(どちらも既定は25%)で「同時に減らしていい数」「一時的に増やしていい数」を決められる。ただ、更新が進まなくなっても状態を報告するだけで自動では戻さないから、`kubectl rollout undo`で戻すか、ほかの仕組みで自動化する必要があるんだ。
ローリングアップデート中に新旧バージョンが混在するのって問題にならないの?
もっと詳しく知りたい人へ
ローリングアップデートでも一時的にエラーが出るのはなぜ?
よくある原因は、準備が整う前のサーバーに通信が振り分けられることと、停止するサーバーが処理中のリクエストを途中で切ってしまうことだよ。Kubernetesでは、準備ができたかを確かめるreadinessProbeを設定し、停止時に処理を終えるまで待つ時間(terminationGracePeriodSeconds)やpreStopフックを適切に設定すると防ぎやすいんだ。台数が少ないと更新中に残りのサーバーへ負荷が集中するので、maxUnavailableやmaxSurgeも見直そう。
📖 おまけ:英語の意味
「Rolling Update」 = 回転式の更新
💬 Rolling(転がる・順繰りの)+ Update(更新)。ローラーのように端から順番に塗り替えていくイメージだよ