Blue/Green デプロイ

2025年11月6日

Blue/Green デプロイ

英語表記: Blue/Green Deployment

概要

Blue/Green デプロイは、オーケストレーション（Kubernetes, OpenShift）環境における「更新戦略」の一つであり、アプリケーションのダウンタイムをゼロに抑えながら、安全かつ確実に新バージョンをリリースするための手法です。既存の本番環境（Blue）を完全に維持したまま、並行して新環境（Green）を構築し、準備が整った段階でトラフィックの向きを瞬時に切り替える点が最大の特徴です。この戦略は、問題が発生した場合に即座に旧環境（Blue）へ切り戻し（ロールバック）できる、非常に高い安全性を誇ります。

詳細解説

更新戦略としての位置づけ

この手法は、オーケストレーション（Kubernetes, OpenShift）が提供する高度な「更新戦略」の中でも、最もリスク回避を重視したデプロイモデルです。従来の更新方法では、稼働中のシステムを直接上書きするため、更新中にエラーが発生するとサービス全体が停止するリスクがありました。しかし、Kubernetes環境下では、このBlue/Green戦略を採用することで、システム全体としての可用性（サービスが継続して利用できること）を極限まで高めることが可能になります。これは、Kubernetesが持つトラフィックルーティング機能（Serviceオブジェクト）を最大限に活用しているからこそ実現できる機能です。

仕組みと構成要素

Blue/Green デプロイの成功は、主に以下の3つの構成要素と手順によって成り立っています。

Blue環境（旧バージョン）: 現在、本番トラフィックを処理している安定稼働中のアプリケーション群（Kubernetes Deploymentと対応するPod群）です。
Green環境（新バージョン）: Blue環境と全く同じ構成で、新しいバージョンのアプリケーションをデプロイした環境です。この環境は、トラフィックが切り替わるまで、外部からはアクセスできない状態で内部テストを実施します。
Service (トラフィック制御): Kubernetesにおいて外部からのアクセスを受け付ける窓口となるオブジェクトです。このServiceが、BlueとGreenのどちらのDeploymentにリクエストを流すかを制御します。

デプロイの流れは次の通りです。

構築: Blue環境が稼働している間に、新しいGreen環境をデプロイし、内部で徹底的に動作確認を行います。
切り替え: Green環境の準備が完了し、本番投入可能と判断されたら、Serviceの設定（セレクター）を更新し、トラフィックをBlueからGreenへ瞬時（アトミック）に切り替えます。
待機・破棄: Green環境が安定して稼働していることを確認した後、古いBlue環境は削除されますが、通常は緊急時のロールバックに備えて、一定期間は待機状態で保持されます。

メリットとトレードオフ

最大のメリットは、ロールバックの容易さと速さです。Green環境で重大なバグが発見された場合でも、Serviceのルーティング設定を再びBlue環境に戻すだけで、瞬時に旧バージョンへ切り戻すことができます。

一方で、デメリットとして無視できないのがリソースの消費です。デプロイの瞬間、BlueとGreenの二つの環境が同時に稼働するため、一時的に通常の約2倍のコンピューティングリソース（Pod、CPU、メモリなど）が必要となります。これは、オーケストレーション環境のコスト管理において重要なトレードオフとなります。

具体例・活用シーン

Blue/Green デプロイの仕組みを理解する上で、最も分かりやすいのは「劇場の舞台セットの交換」に例えることです。

アナロジー：舞台セットの交換

想像してみてください。劇場では今、第一幕の舞台セット（Blue）を使って劇が進行中です。観客は劇に集中しており、サービスが中断することは許されません。

舞台裏では、第二幕のための新しい、完全に作り込まれた舞台セット（Green）が完璧に準備されています。照明や小道具のテストも裏で完了しています。

幕間や、観客の視線が集中しない一瞬のタイミングで、舞台の幕（Service）が上がり、観客の視線（トラフィック）を瞬時に新しいセット（Green）に向けます。古いセット（Blue）はすぐに破壊せず、もし第二幕のセットに致命的な欠陥があった場合に備えて、すぐに幕を閉じて第一幕のセットに戻せるように待機させておくのです。

この例のように、サービス提供を中断せずに、新しい環境を完全に構築し、切り替えと切り戻しの準備を整えるのがBlue/Green デプロイの核心です。

活用シーン

金融取引システム: わずかなダウンタイムも許されない環境での、セキュリティパッチや機能アップデート。
大規模ECサイト: クリスマスや年末商戦など、トラフィックピークが予想される時期の直前に行う、リスクを最小限に抑えたい本番リリース。
規制の厳しい業界: 監査や法令遵守の要件から、更新プロセス全体を高いレベルで保証する必要がある場合。

この方法は、システムの可用性が最優先される場面で、Kubernetesの「更新戦略」として最も信頼されています。

資格試験向けチェックポイント

IT Passport、基本情報技術者試験、応用情報技術者試験といった資格試験では、デプロイ戦略の種類とそれぞれの特徴を比較させる問題が頻出します。特に、オーケストレーション環境の文脈で問われる際は、以下の点に注目してください。

キーワード: 「ゼロダウンタイム」「瞬時の切り替え」「切り戻し（ロールバック）の容易さ」「リソースの二重消費」
最大の特徴: Blue/Green デプロイは、ロールバックが最も容易かつ迅速であるという特性を必ず覚えておきましょう。問題文で「問題発生時に旧バージョンへすぐに戻せる戦略はどれか」と問われたら、この戦略が有力な回答候補となります。
比較対象: 他の主要な更新戦略（ローリングアップデート、カナリアリリース）との違いを明確に理解することが重要です。
- ローリングアップデート：リソース消費は少ないが、切り戻しに時間がかかる場合がある。
- カナリアリリース：特定ユーザーに限定的に公開し、徐々にトラフィックを増やすが、切り替えは段階的である。
Kubernetes機能との関連: この戦略は、Kubernetesの「Service」が持つセレクター機能（ラベルによってPod群を識別する機能）を切り替えることで実現されている、という技術的な背景も押さえておくと応用問題に対応できます。これは、オーケストレーション機能の具体的な活用例として重要です。