CI/CD・デプロイ

ブルーグリーンデプロイぶるーぐりーんでぷろい

デプロイリリース戦略ダウンタイムロールバックカナリアリリースCI/CD

ブルーグリーンデプロイについて教えて

簡単に言うとこんな感じ！

本番環境を「青」と「緑」の2面用意して、新バージョンを緑にこっそり準備してから一瞬でスイッチする方法だよ！サービスを止めずにアップデートできるし、問題が起きたらすぐ青に戻せる安心感がポイントなんだ！

ブルーグリーンデプロイとは

ブルーグリーンデプロイ（Blue-Green Deployment）とは、本番環境を「ブルー（青）」と「グリーン（緑）」の2つ用意し、片方を稼働中のまま、もう片方に新バージョンを展開してから切り替えるリリース手法だ。切り替えはロードバランサー（=アクセスを振り分ける装置）のルーティングを変更するだけなので、サービスを止めるダウンタイムをほぼゼロにできる。

万が一新バージョンで不具合が発生した場合は、ロードバランサーを旧バージョン側に戻すだけで即座にロールバック（=元の状態に戻すこと）できるのが最大の強みだ。旧環境をそのまま残しておくことで、「やっぱり戻す」という判断を素早く実行できる安全網になっている。

近年はクラウドサービスの普及によりサーバーを2倍持つコストが下がり、CI/CD（継続的インテグレーション／継続的デリバリー）のパイプラインに組み込む形で広く使われている。特に「24時間止められないサービス」を運用するビジネスには必須級のデプロイ戦略だ。

ブルーグリーンデプロイの仕組み

切り替えの流れ

ステップ	内容
① 現状	ブルー環境が本番として稼働中。ユーザーはブルーに接続している
② 準備	グリーン環境に新バージョンをデプロイ・テスト実施
③ 切り替え	ロードバランサーのトラフィックをグリーンへ向ける
④ 確認	グリーンが正常動作しているか監視
⑤ 完了 or 差し戻し	問題なければブルーを次回用に温存。問題があればブルーに戻す

覚え方

「青が現役、緑が控え。問題なければ緑が昇格、ミスなら青が復活」

野球のスタメンと控え選手をイメージすると覚えやすい。控えが準備OKになったら先発交代、ダメなら即先発に戻す！

メリット・デメリット

観点	メリット	デメリット
稼働継続	ほぼゼロダウンタイムでリリース可能	2倍のインフラコストがかかる
安全性	ロールバックが即時・確実	データベースのスキーマ変更を伴う場合は注意が必要
テスト	本番と同じ環境で事前テストができる	セッション情報の引き継ぎ設計が必要
運用	切り替えが自動化しやすい	2環境の設定を常に同期する管理コストがある

歴史と背景

2000年代初頭：大規模Webサービスの普及とともに「深夜メンテナンス」によるサービス停止が問題視されるようになる
2010年：Martin Fowler（マーティン・ファウラー）がブルーグリーンデプロイを体系的な手法として定義・命名し、記事として発表。継続的デリバリーの文脈で広く知られるようになる
2010年代前半：AWSやGCPなどのクラウドサービスが普及し、オンデマンドでサーバーを2倍持つコストが現実的に
2014年：Jez Humble・David Farleyによる書籍『継続的デリバリー』でブルーグリーンデプロイが重要なパターンとして紹介される
2016年〜現在：Kubernetes（コンテナ管理基盤）やAWS CodeDeploy、Spinnaker等のツールがブルーグリーンデプロイをネイティブサポートし、標準的手法として定着

他のデプロイ戦略との比較

ブルーグリーン以外にも、ダウンタイムを抑えたデプロイ戦略がいくつかある。

手法	概要	ロールバック速度	コスト	リスク
ブルーグリーン	2環境を丸ごと切り替え	★★★ 即時	高（2倍）	低
カナリアリリース	一部ユーザーだけ新版に流す	★★☆ やや遅い	中	低〜中
ローリングアップデート	サーバーを順番に1台ずつ更新	★☆☆ 遅い	低	中
インプレースデプロイ	動いているサーバーに直接上書き	✕ 困難	最低	高

カナリアリリースとの使い分け

カナリアリリースは全ユーザーではなく「全体の5%だけ」に新バージョンを流し、問題がなければ徐々に割合を増やす手法だ。ブルーグリーンデプロイが「全員一斉に切り替える潔さ」なのに対し、カナリアリリースは「段階的に様子を見る慎重さ」が特徴といえる。新機能の反応を少人数でテストしたい場合はカナリア、システム全体を丸ごと入れ替えたい場合はブルーグリーンが向いている。