一言でいうと
ブルーグリーンデプロイとは、「現行の環境(ブルー)」と「新しい版の環境(グリーン)」の2つを用意し、準備ができたら、利用者の向き先を切り替えてリリースする方法です。
名前の由来は、2つの環境を、青と緑の色で区別したことにあります。
たとえ話:舞台の入れ替え
劇場で、同じ舞台のセットを、2つ用意しておくとします。
- 片方(ブルー)では、いま、本番の公演をしている
- もう片方(グリーン)では、裏で、新しい演出の準備とリハーサルをしている
- 準備が整ったら、お客さんの案内を、グリーンの舞台に切り替える
- 問題があれば、すぐにブルーの舞台に、案内を戻す
公演を止めずに、新しい演出に変えられます。これが、ブルーグリーンデプロイの考え方です。
流れ
| 段階 | 内容 |
|---|---|
| ① 準備 | 現行(ブルー)と同じ構成の環境(グリーン)を用意する |
| ② デプロイ | グリーンに、新しい版を反映する |
| ③ 確認 | グリーンで、動作確認や、テストを行う |
| ④ 切り替え | 利用者のアクセスの向き先を、ブルーからグリーンへ切り替える |
| ⑤ 見守る | 問題がないかを確認する。あれば、すぐにブルーへ戻す |
| ⑥ 後始末 | 問題がなければ、古い環境を、一定期間後に整理する |
良い点
- ダウンタイムを、ほぼなくせる:切り替えは、短時間で済む
- 元に戻しやすい:問題があれば、向き先を戻すだけでよい
- 本番に近い環境で、事前に確認できる:切り替える前に、新しい環境をテストできる
注意点
| 注意点 | 内容 |
|---|---|
| 費用 | 環境が、一時的に2倍必要になる |
| データベースの変更 | 新旧の版が、同じデータを扱うため、変更の仕方に工夫が必要 |
| 利用中のデータ | ログイン状態や、処理の途中のデータが、切り替え時にどうなるか |
| 切り替えの判断 | 「問題なし」と判断する基準や、元に戻す条件を、事前に決めておく必要がある |
特に、データベースの変更が、最も難しい部分です。元に戻せない変更(列の削除など)をしてしまうと、切り戻しができなくなります。そのため、新旧のどちらの版でも動く形で、段階的に変更するのが基本です。
「2つ用意すれば、必ず安全」ではない
ブルーグリーンデプロイは、問題があった時に、元の環境へ戻しやすくなる方法です。しかし、環境を2つ用意すれば、必ず安全になるわけではありません。
- データベースの変更:新しい版で、データの形を変えた後は、切り戻しだけでは、元に戻らないことがある
- 外部サービスとの連携:相手のサービスに送ってしまった内容は、こちらの環境を戻しても、取り消せない
リリースの事故を防ぐ基本は、問題が起きてから慌てて調べるのではなく、事前に構成と手順を把握し、起きた時に対応できる状態を作っておくことです。ブルーグリーンは、その手段の一つにすぎません。
他のリリース方法との違い
| 方法 | 切り替え方 | 特徴 |
|---|---|---|
| ブルーグリーン | 環境をまるごと一度に切り替える | 戻しやすい。環境が2倍必要 |
| カナリアリリース | 一部のユーザーから、少しずつ新版へ誘導する | 影響範囲を小さく試せる(カナリアリリースとは) |
| ローリングアップデート | 複数のサーバーを、順番に新版へ入れ替える | 追加の環境が少なくて済む。戻すのに時間がかかる |
| フィーチャーフラグ | 機能のオンオフを、設定で切り替える | デプロイと公開を、分けて考えられる(フィーチャーフラグとは) |
これらは、排他的ではなく、組み合わせて使うことも多くあります。
向いているケースと、向かないケース
| 向いている | 向かない |
|---|---|
| 止まることの影響が大きいサービス | 小規模で、短時間の停止が許されるサービス |
| リリースのたびに、不安がある | リリースの頻度が、ごく少ない |
| 環境を、コードで再現できる(同じ構成を、簡単に作れる) | 環境の構築が、手作業で、再現が難しい |
| データベースの変更を、段階的に進められる | データ構造を、頻繁に大きく変える |
小さく始めるなら、手動での切り替えからでも、考え方は試せます。たとえば、新しい版を、別の場所に置いて確認したうえで、向き先の設定を切り替えるだけでも、ブルーグリーンの利点の一部は得られます。