ゼロダウンタイムデプロイ

ゼロダウンタイムデプロイとは

ゼロダウンタイムデプロイは、サービスを停止せずに新バージョンをデプロイする手法の総称である。無停止になるかどうかは戦略の名前で決まるのではなく、新しいインスタンスがヘルスチェックに合格してからリクエスト経路に入ること、古いインスタンスを止める前に経路から完全に外すこと、処理中のリクエストを返し切ってから終了することの 3 点が揃っているかで決まる。ローリングアップデートや Blue/Green を名乗っていても、どれか 1 つが欠けていればユーザーにはエラーが見える。

デプロイ戦略の比較

戦略の違いは、更新中に旧バージョンと新バージョンが併存する時間、切り戻しに必要な操作、余分に確保するリソース量に現れる。下表のリスク欄は「不具合が全ユーザーに広がる前に気付けるか」の度合いを指す。

戦略	ダウンタイム	リスク	ロールバック速度	コスト
再起動デプロイ	あり	低い	遅い	低い
ローリングアップデート	なし	中程度	中程度	低い
Blue/Green	なし	低い	速い (経路切替のみ)	高い (2 倍のリソース)
カナリアリリース	なし	最低	速い (経路切替のみ)	中程度

ロールバックが「速い」のはリクエスト経路を戻す操作のことである。切り替え後に処理されたリクエストの結果や、新バージョンが書き込んだデータは経路を戻しても元には戻らない。スキーマ変更や外部への通知を伴う変更では、経路のロールバックだけでは復旧しない。

ローリングアップデート

ローリングアップデートは、稼働中のインスタンスを少数ずつ入れ替えて全体を更新する方式である。稼働台数の下限と上限を決めておき、その範囲を保ったまま旧バージョンを減らして新バージョンを増やす。

Step 1: [v1] [v1] [v1]  ← 全て旧バージョン
Step 2: [v2] [v1] [v1]  ← 1 台ずつ更新
Step 3: [v2] [v2] [v1]
Step 4: [v2] [v2] [v2]  ← 全て新バージョン

Amazon ECS と Kubernetes のどちらでも既定のデプロイ方式だが、更新速度を決めるパラメーターは別物である (2026 年 8 月時点)。

基盤	パラメーター	意味	端数処理
Kubernetes (Deployment)	maxUnavailable / maxSurge	希望 Pod 数に対する「停止を許す数」と「超過を許す数」。どちらも既定は 25 %	maxUnavailable は切り捨て、maxSurge は切り上げ
Amazon ECS (サービス)	minimumHealthyPercent / maximumPercent	desiredCount に対する稼働タスク数の下限と上限	下限は切り上げ、上限は切り捨て

ECS 側に maxSurge や maxUnavailable は存在しない。しかも上限が切り捨てのため、desiredCount 3 で maximumPercent を 125 % にすると上限は 3 台のままで、新しいタスクを先に立ち上げる余地が無くなる (公式ドキュメントに載っている例)。この場合は下限を下げて旧タスクを先に止める設定へ変えることになる。Kubernetes 側の既定値と失敗時の挙動は Kubernetes ローリングアップデート で詳しく扱う。

Blue/Green デプロイ

Blue/Green デプロイは、現行環境 (Blue) を残したまま同じ規模の新環境 (Green) を用意し、動作確認を終えてからトラフィックの向き先をまとめて切り替える。

Blue (現行):  [v1] [v1] [v1]  ← トラフィックを受けている
Green (新規): [v2] [v2] [v2]  ← テスト中

切り替え: ALB のターゲットグループを Green に変更
ロールバック: Blue に戻すだけ (経路切替のみ)

カナリアリリース

カナリアリリースは、ごく一部のトラフィックだけを新バージョンへ流し、エラー率やレイテンシを見ながら比率を上げる。異常が全ユーザーに広がる前に検知できる点が利点である。

Step 1: [v1] x 9, [v2] x 1  ← 10% のトラフィックを v2 に
Step 2: メトリクスを監視 (エラー率、レイテンシ)
Step 3: 問題なければ段階的に v2 を増やす
Step 4: [v2] x 10  ← 全トラフィックを v2 に

Lambda でのゼロダウンタイム

Lambda では実行環境の入れ替えを Lambda 側が受け持つため、サーバーを 1 台ずつ差し替える作業は要らない。ただし切り替えが瞬時に起きるわけではなく、関数を更新した直後には短い時間 (通常は 1 分未満) だけ、旧コードと新コードのどちらで処理されるかが確定しない期間がある。この間はどちらで処理されても壊れないよう、後方互換を保った変更にしておく必要がある。

段階的に切り替えたい場合はバージョンとエイリアスを使う。エイリアスに加重ルーティングを設定すると、指定した割合だけを新しいバージョンへ振り分けられるため、メトリクスを見ながら比率を上げるカナリアリリースが組める。

経路離脱と終了処理

無停止を実際に左右するのは、旧インスタンスを止めるまでの手順である。

• 経路から外す: ALB や NLB のターゲットグループから登録解除すると新規リクエストの割り当てが止まり、処理中のリクエストが終わるのを待つ登録解除の遅延 (deregistration delay) に入る。既定値は 300 秒で、処理中のリクエストと接続が無ければ待たずに完了する。
• 遅延中に落とさない: 登録解除の遅延が終わる前にターゲット側が接続を切ると、クライアントには 500 番台のエラーが返る。プロセスを先に停止してから登録解除する順序はここで壊れる。
• 処理中のリクエストを返し切る: アプリケーション側は SIGTERM を受け取ったら新規受付を止め、処理中の応答を返してから終了する (graceful shutdown)。Kubernetes では preStop フックと terminationGracePeriodSeconds がこの猶予を与える。

前提条件

どの戦略でも、旧バージョンと新バージョンが同時に動く瞬間が必ずある。次の前提が崩れると、戦略を変えても無停止にはならない。

前提	理由
後方互換な API	新旧バージョンが同時に動くため
DB マイグレーションの分離	列の追加、新旧両対応のコード投入、旧列の削除を別リリースに分ける
ヘルスチェック	新バージョンの正常性を確認
ロールバック手順	問題発生時にリクエスト経路を戻す手順が用意されている

戦略を選ぶ前に、まず「経路から外してから止めているか」「SIGTERM を受けて処理中のリクエストを返し切っているか」を自分の環境で確かめるとよい。この 2 点が満たされていなければ、Blue/Green やカナリアリリースに変えても切り替えのたびにエラーが表に出る。