ブルーグリーンデプロイの仕組み ― ダウンタイムゼロで本番を切り替える方法

本番環境をまったく同じ構成で2つ用意して、片方を「ブルー」、もう片方を「グリーン」と呼ぶ手法だよ。今動いているのがブルーだとしたら、新しいバージョンをグリーンにデプロイして、準備ができたらロードバランサーでトラフィックをグリーンに切り替える。これだけでダウンタイムゼロのリリースが実現できるんだ。

そこがブルーグリーンの最大の強みだよ。ブルー環境はそのまま残っているから、ロードバランサーの向き先をブルーに戻すだけで一瞬でロールバックできるんだ。従来のデプロイだと、バグが見つかったら古いバージョンを再デプロイしなきゃいけなくて時間がかかるけど、ブルーグリーンなら数秒で元に戻せるよ。

カナリアリリースは新バージョンにトラフィックの一部（たとえば5%）だけを流して、問題がなければ徐々に比率を上げていく方法だよ。ローリングアップデートはサーバーを1台ずつ順番に更新していく方法。ブルーグリーンは全トラフィックを一気に切り替えるから、シンプルで分かりやすい反面、中間状態がないんだ。

AWSならALB（Application Load Balancer）のターゲットグループを2つ用意して、リスナールールで切り替えるのが定番だよ。Kubernetesの場合は、ServiceのselectorラベルをBlueからGreenに書き換えるだけでトラフィックが切り替わる。どちらもインフラの設定変更だけで済むから、アプリのコードを一切触らなくていいんだ。

いい質問だね。実はそこがブルーグリーンデプロイの一番の難所なんだ。多くの場合、DBは共有にする。でもそうすると、新バージョンのマイグレーション（テーブル変更など）が旧バージョンと互換性を保つ必要がある。カラム追加は大丈夫だけど、カラム削除やリネームは旧バージョンが壊れるから、段階的にやるのがセオリーだよ。

その通り。常時2セットの環境を動かすと単純にインフラ費用が倍になるんだ。だから最近はデプロイ時だけグリーン環境を立ち上げて、切り替え後にブルーを落とすパターンも増えているよ。クラウドの従量課金と相性がよくて、コンテナやサーバーレスなら待機中のコストを最小限にできるんだ。

鋭いね。ステートフルなセッション（サーバー側にログイン状態を保持するタイプ）を使っていると、切り替え先にセッション情報がなくてログアウトされることがあるんだ。対策としては、セッションをRedisなど外部ストアに保存するか、JWTトークンのようなステートレス認証にしておくのが定石だよ。

フィーチャーフラグはコードの中で機能のON/OFFを切り替えるスイッチだよ。ブルーグリーンと組み合わせると最強なんだ。新機能をフラグOFFのままグリーンにデプロイして切り替え、問題なければフラグをONにする。万が一バグがあってもフラグをOFFにするだけで済む。環境のロールバックすら不要になるケースもあるよ。

もちろん使えるよ。むしろクラウドのマネージドサービスが充実した今こそ小規模チームに向いているんだ。AWS App RunnerやGoogle Cloud Runは内部的にブルーグリーン方式でデプロイしてくれるから、開発者が意識しなくてもゼロダウンタイムが実現できる。大切なのはDB移行の互換性とセッション管理を設計段階で考慮しておくことだね。