ひとことで言うと
ロールバックは、本番環境でデプロイや設定変更を行ったあとに問題が起きたとき、直前の正常な状態に素早く戻す作業です。
どれだけ事前にテストしても、本番で初めて顕在化する問題はあります。 そのとき「問題のある新しい状態」を修正して再デプロイするより、「問題がなかった古い状態」に即座に戻す方が早いことがあります。 ロールバックはそのための切り戻し手順です。
たとえ話でもう少し詳しく
ロールバックは、文書編集のCtrl+Zに近いです。
- 文章を編集したら意図しない形になってしまった
- Ctrl+Zで一つ前の状態に戻す
- 落ち着いてから改めて正しい編集をする
本番環境では、新しいコードをデプロイしたらサービスに不具合が出た場合に、同じことをします。 正しく修正するより先に、まずサービスを正常な状態に戻すことを優先します。 ロールバック後に落ち着いて原因を調べ、修正してから改めてデプロイし直す流れが一般的です。
よく出る場面・使いどころ
- デプロイ直後にエラーや不具合が増え、サービスに影響が出ているとき
- データベースのマイグレーションを適用したらアプリが正常に動かなくなったとき
- 設定変更後にパフォーマンスが急激に悪化したとき
- リリースした機能に重大なバグが見つかり、修正に時間がかかるとき
似た言葉との違い
- デプロイ
- コードをサーバーに配置して動かせる状態にする作業
- ロールバックはデプロイの逆方向で、前の状態に戻す作業
- バックアップ
- データを丸ごと別の場所に保存しておく仕組み
- ロールバックはアプリのコードや設定を戻す操作で、データの復元はバックアップから行うことが多い
- マイグレーション
- データベースの構造変更を順番に適用する仕組み
- マイグレーションにはロールバック（元に戻す手順）を一緒に書いておくのが慣習
実務で気にするポイント
- ロールバックできる状態を常に用意しておく（直前のバージョンをすぐ戻せる仕組みが必要）
- データベースのマイグレーションを伴う変更は、ロールバックが難しくなる場合があるため慎重に
- モニタリングでデプロイ後の異常を早期に検知できる体制を整えておく
- ロールバックの判断基準と手順をあらかじめチームで決めておく
注意: ロールバックは「問題をなかったことにする」手段ではありません。あくまで「まずサービスを正常化する」ための緊急対応です。ロールバック後は必ず原因を調査し、修正してから改めてデプロイする必要があります。また、ロールバックを想定しない変更（データの削除など）を行うと、戻したくても戻せない状況になるため注意が必要です。