ローリングアップデート

2025年11月6日

ローリングアップデート

英語表記: Rolling Update

概要

ローリングアップデートは、「オーケストレーション（Kubernetes, OpenShift） → Kubernetes 機能 → 更新戦略」という文脈において、稼働中のアプリケーションを停止させることなく、新しいバージョンへ切り替えるためのデプロイメント手法です。これは、Kubernetesのデプロイメント（Deployment）オブジェクトが提供する標準的な機能であり、ユーザー体験を損なうことなく、安定してサービスを提供し続けることを目的としています。古いバージョンのコンテナ（Pod）を徐々に新しいバージョンのコンテナに置き換えていく点が最大の特徴です。

詳細解説

ローリングアップデートの最大の目的は、サービスの可用性を維持しつつ、アプリケーションの更新を安全かつ効率的に行うことです。オーケストレーションシステムにおける「更新戦略」として、この手法は現代のクラウドネイティブ環境では不可欠な要素となっています。

動作原理と主要コンポーネント

Kubernetesにおいて、ローリングアップデートは主にDeploymentリソースによって管理されます。Deploymentは、アプリケーションの望ましい状態（Desired State）を定義し、その状態を維持するためにReplicaSetを管理し、ReplicaSetが実際のコンテナ群であるPodを管理するという構造になっています。

ローリングアップデートが開始されると、Deploymentコントローラーは以下のステップを踏んで処理を進めます。

新しいReplicaSetの作成: まず、新しいバージョンのコンテナイメージを参照する新しいReplicaSetが作成されます。
新しいPodの段階的起動: 新しいReplicaSetが、定義された数のPodを「少しずつ」起動し始めます。この「少しずつ」が非常に重要です。一度にすべてを置き換えるのではなく、サービスに影響が出ない範囲で徐々に増やしていきます。
古いPodの段階的停止: 新しいPodが正常に起動し、トラフィックを受け付けられる状態になったことを確認した後、古いバージョンのPodが「少しずつ」停止・削除されていきます。
無停止の実現: この「新しいPodの増加」と「古いPodの削除」のプロセスが交互に、または並行して行われることで、常に一定数以上のPodが稼働している状態を維持します。これにより、ユーザーからのリクエストが途切れることなく処理され、サービス停止（ダウンタイム）を回避できるのです。

パラメータによる制御

この更新の速度や許容されるサービスの中断レベルは、Deploymentの設定パラメータ（特にmaxSurgeとmaxUnavailable）によって細かく制御されます。

maxSurge: 望ましいレプリカ数を超えて、一時的に作成してもよい新しいPodの最大数を指定します。これにより、更新中に一時的にキャパシティを増強し、サービスのパフォーマンス低下を防ぐことができます。これは本当に気の利いた設定だと思います。
maxUnavailable: 更新中に、望ましいレプリカ数から一時的に停止してもよい古いPodの最大数を指定します。これにより、サービス停止のリスクを最小限に抑えつつ、スムーズに切り替えを進めることが可能になります。

これらの制御機能があるからこそ、ローリングアップデートは「更新戦略」として非常に柔軟性が高いと言えるでしょう。

具体例・活用シーン

ローリングアップデートは、Webサービス、APIバックエンド、マイクロサービスなど、継続的な可用性が求められるあらゆるアプリケーションの更新に利用されます。

活用シーン：大規模ECサイトのAPI更新

例えば、ある大規模なECサイトの注文処理APIを更新するとします。このAPIは常に膨大なトラフィックを処理しており、数秒でも停止することは許されません。

古いバージョン（V1）：現在、10台のPod（コンテナ）が稼働しています。
更新開始：Deploymentの設定に基づき、まず新しいバージョン（V2）のPodが2台起動されます（例：maxSurge=2）。この時点で合計12台稼働。
トラフィック確認：V2のPodが正常に動作していることを確認。
古いPodの削除：V1のPodが2台停止されます。この時点で合計10台（V2が2台、V1が8台）。
繰り返し：このプロセスが繰り返され、最終的にV1のPodがすべて削除され、V2のPodが10台稼働している状態に移行します。

ユーザーは更新中にV1とV2のPodのどちらかに接続されますが、サービス全体が停止することはないため、更新が行われたことすら気づきません。

アナロジー：飛行中の旅客機のエンジンの交換

ローリングアップデートを理解するための強力なアナロジーは、「飛行中の旅客機のエンジンの交換」です。

旅客機は、複数のエンジンを搭載して飛行しています。もし、すべてのエンジンを同時に停止して交換したら、飛行機は墜落してしまいます。これはサービス停止と同じ状態です。

ローリングアップデートでは、まず古いエンジン（古いPod）を停止させる前に、新しいエンジン（新しいPod）を起動し、それが正常に動いていることを確認します。

新しいエンジンの起動（MaxSurge）：飛行中に予備の新しいエンジンを起動し、一時的にエンジンの数を増やします。
古いエンジンの停止（MaxUnavailable）：新しいエンジンが正常に稼働していることを確認した後、古いエンジンを一つずつ停止し、交換します。

このプロセスを繰り返すことで、飛行を止めずに、すべてのエンジンを最新のものに交換できます。この「サービスを止めない」という思想こそが、オーケストレーションにおける更新戦略の核心であり、ローリングアップデートの素晴らしさなのです。

資格試験向けチェックポイント

ローリングアップデートは、クラウドやコンテナ技術の試験では非常に頻出するテーマであり、「オーケストレーション（Kubernetes, OpenShift） → Kubernetes 機能 → 更新戦略」という文脈で問われます。

無停止更新の実現: ローリングアップデートの最大の目的は、ダウンタイムを発生させずにアプリケーションを更新することであると理解しておきましょう。「無停止」「ダウンタイムゼロ」といったキーワードと結びつけて覚えてください。
Deploymentとの関係: Kubernetesにおいて、ローリングアップデートを実行するのはどのリソースか、という問いがよく出ます。答えは「Deployment（デプロイメント）」です。DeploymentがReplicaSetを制御し、更新を実行します。
段階的な切り替え: 一度にすべてのPodを切り替えるのではなく、徐々に新しいバージョンに置き換えていくプロセスが重要です。これにより、問題が発生した場合でもすぐに古いバージョンに戻す（ロールバック）ことが容易になります。
対比される戦略: ローリングアップデートは、カナリアリリースやブルー/グリーンデプロイメントといった他の更新戦略と比較して問われることが多いです。ローリングアップデートは比較的シンプルで標準的ですが、カナリアやブルー/グリーンはさらに高度なトラフィック制御や環境分離を伴います。
ITパスポート/基本情報技術者試験: このレベルでは、「ローリングアップデートとは何か？」といった基本的な定義（無停止で段階的に更新する手法）が問われます。
応用情報技術者試験: Kubernetesやクラウド環境の具体的な運用知識と結びつけられ、更新中の可用性維持の方法や、ロールバックの容易さといったメリット・デメリットが問われる可能性があります。