フレームワーク活用ガイドひとことで言うと#
リリースしたバージョンに問題が見つかったとき、素早く前のバージョンに戻す仕組みと手順。「デプロイは必ずうまくいく」前提ではなく、「問題があったらすぐ戻せる」前提で設計する。
押さえておきたい用語#
- Rollback（ロールバック）
- 問題のあるバージョンから前の安定バージョンに戻す操作のこと。手動と自動の両方がある。
- MTTR（Mean Time To Recovery）
- 障害発生から復旧までの平均時間を指す。ロールバック体制が整っているとMTTRが大幅に短縮される。
- Blue-Green Deployment
- 本番環境を2面（Blue/Green）用意し、切り替えでダウンタイムゼロのデプロイとロールバックを実現する方式。
- Expand-Contract Pattern
- DBスキーマ変更を「追加→移行→削除」の3段階で行い、どの時点でもロールバック可能にする手法である。
- Canary Release（カナリアリリース）
- 全ユーザーに展開する前に、一部のトラフィックだけに新バージョンを配信して問題を早期検知する手法。
デプロイロールバックの全体像#
こんな悩みに効く#
- デプロイ後に問題が発覚しても、復旧に数時間かかる
- ロールバック手順が属人的で、特定のエンジニアがいないと戻せない
- DB migrationを含むデプロイが怖くてリリース頻度を上げられない
基本の使い方#
ロールバックの最大の障壁はDBスキーマ変更。以下のルールを守る。
- カラム追加は後方互換: 新カラムはNULL許可またはデフォルト値付き
- カラム削除は2段階: まずアプリから参照を外し、次のリリースで物理削除
- APIの破壊的変更は避ける: バージョニングで旧クライアントをサポート
デプロイ直後に以下のメトリクスを監視し、閾値を超えたらアラートを出す。
- エラー率（5xx）の急増
- P95レイテンシの悪化
- ヘルスチェックの失敗
具体例#
月間GMV10億円のECサイト。以前、決済処理のバグで30分間注文不能になり、推定1,500万円の機会損失が発生した。
Blue-Green Deploymentを導入し、ALBのターゲットグループ切り替えでロールバックを実装。
| 指標 | Before | After |
|---|---|---|
| ロールバック所要時間 | 25分 | 15秒 |
| デプロイ頻度 | 週1回 | 日2回 |
| デプロイ起因障害の損失 | 推定1,500万円/回 | ほぼゼロ |
ALBの重み付きルーティングでカナリアリリースも併用し、全展開前に5%のトラフィックで問題を検知できるようになった。
エンタープライズ向けHR SaaS。テーブル構造の変更を伴うリリースが月2〜3回あり、ロールバック不能になるリスクを常に抱えていた。
Expand-Contractパターンを導入。
- Expand: 新カラム/テーブルを追加（旧バージョンと共存可能）
- Migrate: 新バージョンのアプリをデプロイし新旧両方を参照
- Contract: 旧バージョンの参照がゼロになったら旧カラムを削除
各フェーズが独立したデプロイになるため、どの時点でもロールバック可能。導入後1年で「ロールバック不能なデプロイ」はゼロになった。
DAU50万人のモバイルゲーム。深夜のメンテナンス後にAPIサーバーを更新するが、オンコール担当が対応遅れで4時間障害が放置されたことがあった。
ArgoCD + Prometheus + Argo Rolloutsで自動ロールバックを構築。
- デプロイ後5分間のエラー率が2%を超えたら自動ロールバック
- P95レイテンシが500msを超えたら自動ロールバック
- ロールバック実行時にSlackとPagerDutyに自動通知
人間の判断なしで 平均3分で自動復旧 できるようになり、深夜デプロイの安全性が飛躍的に向上した。
やりがちな失敗パターン#
- ロールバックをテストしない — デプロイのテストだけでなくロールバックのテストも行う。本番で初めて試みると想定外の問題で失敗する
- DB migrationを1ステップで行う — カラム追加・データ移行・旧カラム削除を1つのmigrationでやるとロールバック不能になる。必ずExpand-Contractパターンで段階的に
- ロールバック判断基準が曖昧 — 「なんかおかしい」では判断が遅れる。「エラー率X%以上」「レイテンシY ms以上」のように数値で明確にする
- 前バージョンのアーティファクトを保持しない — Dockerイメージやバイナリを削除するとロールバックできない。最低でも直近5バージョンは保持する
まとめ#
デプロイロールバックは 「すべてのデプロイは失敗し得る」 という前提に立ち、問題発覚時に素早く前のバージョンに戻す仕組み。ロールバック可能な設計（特にDB migrationの後方互換）が土台になり、その上にデプロイ後の自動監視と明確な判断基準を載せる。Blue-Green Deploymentや自動ロールバックで復旧を秒〜分単位にできれば、デプロイ頻度を上げる心理的安全性も確保できる。