ブルーグリーンデプロイとは｜ローリング・カナリアとの違いとデータベースの壁
システムの更新作業には、いつも同じ悩みがつきまといます。
- リリースのたびにサービスを停止している
- 不具合が見つかってもすぐに戻せない
- 本番でしか再現しない問題があり、検証しきれない
- 作業を深夜や休日に寄せざるを得ない
これらに対する解決策の一つがブルーグリーンデプロイです。
なお「Blue Deployment」「Green Deployment」という別々の手法があるわけではありません。Blue/Green Deploymentという一つの手法で、BlueとGreenは2つの環境につけた名前です。
環境を2つ用意して、まるごと切り替える。
考え方は単純ですが、実際に導入するとある一点で必ず壁にぶつかります。AWSのホワイトペーパーをもとに、仕組みと現実的な課題を整理します。
ブルーグリーンデプロイの仕組み
同じ構成の環境を2セット用意し、片方だけを稼働させます。
| 環境 | 状態 |
|---|---|
| Blue | 現在稼働中。利用者からのアクセスを受けている |
| Green | 新バージョンを配置。まだアクセスは来ていない |
手順はこうなります。
- Green環境に新バージョンを配置する
- Green環境で動作を確認する（利用者には影響しない）
- ロードバランサーやDNSの向き先をBlueからGreenへ切り替える
- 問題がなければ完了。Blueは次回のGreenとして残しておく
切り替えは経路の変更だけなので一瞬で終わります。そして問題が起きたら向き先をBlueに戻すだけです。
切り戻しが「再デプロイ」ではなく「切り替え直し」で済む。ここが最大の利点です。
旧バージョンは消さずに残っているため、復旧が数秒で完了します。障害対応の心理的な負担が大きく下がる方式です。
切り替えをどこで行うか
「経路を切り替える」と一言でいっても、実現方法によって挙動が変わります。主に2つあり、切り替わるまでの速さが決定的に違います。
| 方式 | 反映速度 | 注意点 |
|---|---|---|
| ロードバランサー （振り分け先の変更） |
即座 | 同一ネットワーク内に両環境が必要 |
| DNS （向き先レコードの変更） |
遅い | TTLの影響でキャッシュが残る |
注意すべきはDNSによる切り替えです。DNSの応答は各所にキャッシュされるため、レコードを書き換えてもすべての利用者がすぐに新環境へ向かうわけではありません。TTL（キャッシュの保持時間）が経過するまで、旧環境へのアクセスが残り続けます。
そして問題が起きたとき、切り戻しにも同じだけ時間がかかります。
「即座に戻せる」というブルーグリーンの利点が損なわれるため、DNS方式を採る場合は事前にTTLを短く設定しておく必要があります。切り替えの数日前から短縮しておかないと、古い設定がキャッシュに残ったままになります。
確実性を求めるなら、ロードバランサーの振り分け先を変更する方式が扱いやすい選択です。
ローリング・カナリアとの違い
デプロイ手法は他にもあり、混同されがちです。AWSの定義をもとに整理します。
まずローリングデプロイについて、公式はこう説明しています。
アプリケーションが動作しているインフラを完全に置き換えることで、旧バージョンを新バージョンへ徐々に置き換える戦略。（中略）ローリングデプロイは一般にブルーグリーンデプロイより高速である。しかしブルーグリーンデプロイとは異なり、ローリングデプロイでは新旧バージョン間の環境分離がない
サーバーを1台ずつ入れ替えていく方式です。環境が1セットで済むため速く、コストも抑えられますが、入れ替えの途中は新旧が混在します。
次にカナリアデプロイです。ここは誤解が多い部分です。
カナリアデプロイは、よりリスク回避的なブルーグリーンデプロイ戦略の一種である。トラフィックを2段階で新バージョンへ移す。最初の増分はトラフィックのごく一部で、カナリアグループと呼ばれる
カナリアはブルーグリーンと対立する手法ではなく、その一種という位置づけです。全アクセスを一度に切り替えるのではなく、まず数%だけ流して様子を見ます。
| ブルーグリーン | ローリング | カナリア | |
|---|---|---|---|
| 環境 | 2セット | 1セット | 2セット |
| 切り替え | 一括 | 1台ずつ | 段階的（%指定） |
| 新旧の分離 | あり | なし | あり |
| 切り戻し | 即座 | 再デプロイが必要 | 即座 |
| 速度 | 遅い | 速い | 遅い |
| コスト | 高い | 低い | 高い |
【最大の壁】データベースをどうするか
ここからが本題です。アプリケーションサーバーは複製できますが、データベースは簡単に2つにできません。
切り替え中もデータは書き込まれ続けます。BlueとGreenで別々のデータベースを持てば、切り替えた瞬間にデータが分断されます。
この問題に対するAWSの推奨は明確です。
一般的な推奨は、スキーマ変更をコード変更から切り離すことである。こうすることで、リレーショナルデータベースはブルーグリーンデプロイで定義される環境境界の外側に置かれ、BlueとGreenの間で共有される
つまりデータベースは切り替えの対象に含めず、1つを共有するという設計です。
┌─ Blue（旧アプリ）─┐
利用者 → ├→ 共有データベース
└─ Green（新アプリ）┘これなら切り替えてもデータは連続します。ただし、新旧どちらのアプリからも同じデータベースを触れる必要が出てきます。ここに制約が生まれます。
データベースを分離する場合は難易度が跳ね上がる
ホワイトペーパーは、分離せざるを得ない場合についても述べています。データの同期が必要になり、BlueからGreenへ、またその逆へと変更を伝播させる仕組みが要る。それを実現する仕組みは一般に複雑で、アプリケーションのデータ整合性の要件に制約され、デプロイにリスクを加えるとしています。
特別な事情がなければ、データベースは共有するのが現実的な判断です。
スキーマ変更をいつ行うか
データベースを共有するなら、テーブル定義の変更をどのタイミングで行うかが問題になります。公式は2つのアプローチを示し、しばしば併用されるとしています。
| 順序 | 満たすべき条件 |
|---|---|
| スキーマを先に変更 （コード配置の前） |
変更が後方互換であること。古いバージョンのアプリでもデータを扱える必要がある |
| スキーマを後に変更 （コード配置の後） |
新バージョンのコードが古いスキーマと後方互換であること |
どちらの場合も鍵は後方互換性です。切り替えの前後で新旧のアプリが同じデータベースを見るため、どちらから見ても壊れない状態を保つ必要があります。
公式は、先に変更する場合の性質についてこう補足しています。
最初のアプローチでのスキーマ変更は、しばしば追加的（additive）である。テーブルへのフィールド追加、新しいエンティティ、リレーションシップを追加できる
「追加」は安全、「削除」は危険
この違いは実務で決定的です。
| 変更内容 | 安全性 |
|---|---|
| 列を追加する | 安全（旧アプリは無視するだけ） |
| テーブルを追加する | 安全 |
| 列を削除する | 危険（旧アプリが参照して落ちる） |
| 列名を変更する | 危険（削除＋追加と同じ） |
| NOT NULL制約を追加する | 危険（旧アプリの挿入が失敗する） |
列の削除やリネームが必要な場合は、複数回のリリースに分割します。
- 1回目：新しい列を追加し、両方に書き込むようにする（古い列はそのまま残す）
- 2回目：新しい列だけを読むようにする
- 3回目：古い列を削除する
手間はかかりますが、各段階でいつ切り戻しても壊れない状態が保たれます。マイグレーションの管理を行うツールを使っている場合も、この分割は自分で設計する必要があります。
コストと向き不向き
環境を2つ持つため、単純に考えればインフラ費用は2倍になります。ただし常時2倍とは限りません。
- クラウドであれば、切り替え作業の間だけGreen環境を起動する運用が可能です
- 切り替え後、旧環境をしばらく残して問題がなければ削除する、という進め方もあります
逆に常時2環境を維持し続けると、クラウドコストが想定以上に膨らみます。停止し忘れた環境が課金され続ける、という事故は珍しくありません。
| 向いている | 向いていない |
|---|---|
| 停止が許されないサービス | 更新頻度が低いシステム |
| リリース頻度が高い開発 | インフラ費用を抑えたい環境 |
| 切り戻しの速さが重要な業務 | 状態をサーバー内に持つ設計 |
よくある質問
Q. 切り替えの瞬間、処理中のリクエストはどうなりますか？
ロードバランサーの設定次第です。既存の接続を維持したまま新規接続だけを新環境へ向ける仕組み（コネクションドレイニング）を使うのが一般的です。
Q. セッション情報はどうなりますか？
サーバー内にセッションを保持している設計では、切り替え時に利用者がログアウトします。セッションは外部（RedisやDBなど）に持たせるのが前提になります。
Q. 小規模なシステムでも導入すべきですか？
停止が許容できるなら、必ずしも必要ありません。夜間に数分止められる業務システムであれば、通常のデプロイで十分です。止められないかどうかで判断してください。
Q. カナリアとどちらを選ぶべきですか？
カナリアはブルーグリーンの一種で、切り替えをより慎重に行う方式です。利用者数が多く、影響範囲を限定したい場合はカナリアが適します。ただし段階的に流す仕組みと、異常を検知する監視が前提になります。
Q. データベースも切り替える方法はありますか？
マネージドサービスとして提供されている場合があります（Amazon RDSのブルーグリーンデプロイなど）。ただし利用条件や制約があるため、事前確認が必要です。
参考にした主な調査・資料
- Blue/Green Deployments on AWS（AWS ホワイトペーパー）— ブルーグリーンデプロイの全体像
- Best Practices for Managing Data Synchronization and Schema Changes（AWS）— スキーマ変更とコード変更の分離、後方互換性、データ同期の複雑さ
- Rolling deployments（AWS）— ローリングデプロイの定義と、環境分離がない点
- Canary deployments（AWS）— カナリアデプロイの定義と、ブルーグリーンとの関係
まとめ
ブルーグリーンデプロイは強力ですが、成否はデータベースの扱いで決まります。
- Blue（現行）とGreen（新）の2環境を用意し、経路を切り替える
- 切り戻しが再デプロイではなく切り替え直しで済む
- ローリングは環境分離がなく、代わりに高速・低コスト
- カナリアはブルーグリーンの一種。段階的に移行する方式
- AWSの推奨はスキーマ変更をコード変更から切り離し、DBは共有する
- スキーマ変更は後方互換が必須。追加は安全、削除は危険
- 列の削除は複数回のリリースに分割する
- 環境が2つになるためコスト管理と停止忘れに注意
導入を検討するなら、まず「自社のスキーマ変更を後方互換に保てるか」を確認してください。そこが成立しなければ、環境だけ2つ用意しても切り替えられません。
