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

一方の環境は現在稼働中でユーザーにサービスを提供する「ブルー」環境と、別の環境である「グリーン」環境は新しいバージョンのデプロイメントとテストに使用されます。新しいバージョンが承認されると、トラフィックはブルー環境からグリーン環境に即座にルーティングされます。

このストラテジーは、Jez Humble氏とDavid Farley氏によって、2010年の著書『Continuous Delivery： Reliable Software Releases through Build, Test, and デプロイメント・オートメーション』の中で広く紹介され、命名されました。

ブルー・グリーンは、ダウンタイムを排除し、古いバージョンへのロールバックを即座に発行できる継続的デプロイメント手法です。これにより、A/Bテストが容易になり、エンドユーザーが準備ができていないバージョンに遭遇するリスクを回避しながら、開発のための安全な環境を構築できます。

「ブルー・グリーン」という表現が最も一般的ですが、バリエーションもあります。Netflix社では「赤/黒」を使用していますが、概念は同じです。場合によっては、開発者は複数の環境を使用したいと考えることがあります。色の命名規則は、2つの環境を区別するのに効果的です。ただし、組織は特に2つ以上の環境が関係する場合、バージョン番号、ビルドID、カスタマイズされたタイトルなどの命名規則を使用する場合もあります。

概念自体は単純ですが、このストラテジーのメリットを活用して、安定した安全なブルーグリーン・デプロイメントを作成するためのいくつかのステップとそのステップ内に変数があります。

ブルー・グリーン・デプロイメント用に同一の環境を作成することは、手動で行うことも、自動化ツールを使用することもできます。コードとしてのインフラストラクチャー（IaC）は、プロビジョニングに対する自動化されたアプローチの1つです。IaCは、一連の指示またはレシピのような機械可読構成ファイルを使用し、事前に定義された仕様に従ってITインフラストラクチャーの自動プロビジョニングと構成を可能にします。

IaCを使用すると、開発者は、すでに運用されているブルー環境のコピーを自動的にスピンアップして、グリーン環境として使用できます。開発者は、信頼できる場所から開始していることを確認しながら、必要に応じてこれらのテンプレートを編集できます。IaCを使用すると、再現可能で正確な複製が可能になります。

コンテナ化は、アプリケーション・コード、依存関係、APIがすべて1つの「コンテナ・イメージ」にまとめられるアプローチです。コンテナを使用すると、環境全体が同一であることが保証されます。Kubernetes、オープンソースのコンテナ・オーケストレーション・プラットフォームは、ブルー・グリーン・デプロイメントにおけるコンテナ化によく使用されます。

環境が作成された後、アプリケーションはブルー（ライブ）環境にデプロイされます。

ロード・バランサーは、クラウド・プロバイダーまたはKubernetes環境内のツールとしてアプリケーション環境の前によく配置されるメカニズムで、本番トラフィックを必要に応じて誘導します。このシナリオでは、ロード・バランサーがトラフィックをライブのブルー環境に転送します。

次に、アプリケーションの更新を含む新しいコードがグリーンな運用環境にデプロイされます。ロード・バランサーはトラフィックをブルーの本番環境にルーティングしているため、グリーンは実験、テスト、構成を安全に行うための空間です。

グリーン環境へのデプロイメント・プロセスが完了したら、必要な検証手順をすべて実行します。これらのステップには、セキュリティー・スキャン、性能・チェック、バグ・スキャンなどが含まれる場合があります。

グリーン環境が必要なすべての利害関係者によって検証され、承認されたら、トラフィックを以前の青いバージョンから新しいグリーンのバージョンに転送するようにロード・バランサーを更新します。

このカットオーバーは瞬時に行われます。ユーザーには、ブルー環境またはグリーン環境以外のエラーや問題が発生することはありません。

DNSの更新を使用して、ユーザーを目的の環境に誘導できますが、キャッシュによってIP所在地が更新されるため、大幅な遅延が発生する可能性があります。こうした懸念がある場合には、更新が即座に有効になるロード・バランサーが好まれます。

検証ステップでは、ほとんどの潜在的なバグや性能の問題を検知している必要がありますが、緑豊かな新環境を監視することは依然として重要です。ここで役立つのが分析ソフトウェアとサービスです。アクティビティーを比較することで、何か異常が発生しているかどうかを示すことができます。

何か問題が発生した場合、開発者が問題のトラブルシューティングをしている間、ユーザー・トラフィックはブルー環境にリダイレクトされます。

使用されなくなったブルー環境を廃止することは任意です。組織によっては、ある時点でグリーンの環境をロールバックする必要がある場合に備えて、ブルーの環境を無期限に保持したいと考える場合があります。しかし、ライフサイクルのある時点でブルーの環境を廃止するには、潜在的なコストがかかる理由もあります。あるいは、ブルーの環境を次の実験的環境、つまりグリーンの環境にすることもできます。

継続的統合/継続Delivery Pipelineは「ソフトウェアのデバリバリー・プロセスを効率化する自動化されたDevOpsワークフロー」です。このパイプラインにより、アプリケーションでのコード変更の継続的なデリバリーが容易になります。

CI/CDはブルー・グリーン・デプロイメントと密接に統合された手法です。CI/CDはブルー・グリーン・デプロイメントを可能にし、ブルー・グリーン・デプロイメントは多くの場合CI/CDパイプラインに組み込まれて、ダウンタイムをゼロにし、リスクを軽減しながらソフトウェア更新をリリースします。

CIパイプラインは、新しいコードを中央リポジトリーに統合する前に自動的にテストして統合し、欠陥のあるコードがデプロイメントに至るリスクを軽減します。CDパイプラインは、ブルー・グリーン・デプロイメント・ストラテジーを活用して、ユーザーに影響を与えることなく迅速なリリースを最適化します。ブルー・グリーン・デプロイメントは、ほぼ継続的な可用性と安全なロールバックを提供し、頻繁かつ信頼性の高いコード・リリースという包括的なCI/CD目標を達成する上で大きな役割を果たします。

炭鉱のカナリアの慣用句に由来するカナリア・デプロイメントは、新しいソフトウェア・バージョンをデプロイする際のリスクを軽減するもう1つの方法です。

ブルー/グリーン・デプロイメントでは2つの個別の環境が作成され、それぞれが通常、すべてのトラフィックをホストするか、まったくホストしませんが、カナリアでは異なるアプローチを取ります。カナリア・リリースには1つの環境しかなく、複数のバージョンをホストします。

カナリア・デプロイメントでは、新しいバージョンがまず少数のユーザーにリリースされます。そして、開発者は、エラーの増加、性能の低下、その他の問題が発生していないかを確認できます。そのごく一部のユーザーは、「炭鉱のカナリア」として機能しています。問題がなければ、新しいバージョンへのトラフィックは着実に増加し、その間、エラーがないかチェックされます。

ブルー/グリーンと比較した場合の、カナリア・ デプロイメントの主な利点は、ブルー/グリーン・ デプロイメントでは2つの環境しか使用しないため、インフラストラクチャー・コストが低くなります。ただし、カナリア・デプロイメントは、ブルー/グリーンの単純な負荷分散リダイレクトと比較して、ロールバックが必要な場合、より複雑でリスクが高い可能性もあります。

カナリア・デプロイメント手法は、新しいリリースをできるだけ早くユーザーに提供する上で、潜在的なエラーがそれほど重大ではない場合や、開発者が実際のユーザー・エクスペリエンス・フィードバックで影響をモニタリングしたい場合に有効です。

ただし、ハイブリッド・アプローチもありますロード・バランサーは、一部のユーザー・トラフィック（たとえば1％）をグリーン環境に転送し、99％をブルー環境に残すことができます。これにより、両方のストラテジーを効果的に融合させることができ、ロールバックを迅速かつ簡単に発行できる機能を備えたカナリア・デプロイメントの洞察が提供されます。

ブルー・グリーン・デプロイメントには、オール・オア・ナッシングまたはカナリア・タイプのロールアウトのいずれで使用するかにかかわらず、多くの利点があります。

ロード・バランサーはトラフィックを目的の環境に瞬時に切り替えるため、エンド・ユーザーはダウンタイムをエクスペリエンスすることはありません。これは、ダウンタイムが重大なビジネス問題を引き起こす可能性がある高トラフィックのインスタンスにとって大きなメリットです。

2つの個別の環境があり、その1つは安全で運用可能であることがわかっているため、問題が発生した場合、開発者は変更を即座に元に戻すことができます。グリーン環境で問題が発生した場合は、トラフィックをブルー環境にリダイレクトするだけで済みます。

2つの独立した環境があると、異なるバージョンのメトリクス、分析、A/Bテストの分析が簡単になります。分析データとモニタリング・データはブルー環境またはグリーン環境のいずれかに明確に接続できるため、簡単な比較とヘルス・チェックが可能になります。これはカナリア・デプロイメントとは対照的です。カナリア・デプロイメントは両方のバージョンが同時にアクティブになるため、区別が難しい場合があります。

グリーンな実験環境により、エンドユーザーの見えない場所で新しいバージョンを徹底的にテストすることができます。新しいバージョンは、意図したとおりに動作することにおいて、強い確信を持って展開されます。そうでない場合、トラフィックは安定したブルー環境に即座に再ルーティングされます。

ブルー・グリーン・デプロイメントには多くのメリットがありますが、潜在的な欠点や非最適なユースケースで開発チームが考慮すべきものもあります。

完全にプロビジョニングされた2つの環境が稼働すると、ホスティングとインフラストラクチャーのコストが増加する可能性があります。これらのコストが、単一の環境のコストの正確な2倍になるとは限りません。場合によっては、グリーン環境の方がフットプリントが小さくなる場合や、ブルー環境をすぐに廃止する場合、また一部の参考情報が2つの環境間で共有される場合もあります。ただし、コストの増加は発生する可能性があります。

ブルー・グリーン・デプロイメントに限りませんが、古い環境と新しい環境間でデータベース同期を維持することが課題となる場合があります。たとえば、スキーマの変更が頻繁または複雑なブルー・グリーン・システムでは、互換性を維持するのが困難な場合があります。

ライブ環境が損なわれないようにするため、スキーマの変更は下位互換性があり、新しいシステムが古いシステムと連携できる必要があります。そうでない場合は、リアルタイムで同期する必要がある個別のデータベースが環境によって必要になる場合があります。この双方向同期には、不整合や性能の低下などのリスクがあります。

この問題に所在地するために、GitHub ActionsなどのCI/CDツールには、スキーマの更新を自動的に管理するデータベース・デプロイメント・プロセスが含まれています。場合によっては、複雑すぎるスキーマの変更によって、ブルー・グリーン・デプロイメントの価値が損なわれることがあります。

リクエスト間で永続的なデータを維持するステートフルなアプリケーションでは、ブルー・グリーン・デプロイメントは問題を引き起こす可能性があります。ステートフルなアプリケーションには、複数回訪問しても内容を保持するショッピングカートや、メッセージング・ログなどが含まれます。データベースが環境間で共有され、互換性がない場合、このデータが失われる可能性があります。

マイクロサービス・アプリケーションは多くの場合、個別にデプロイ可能な多数のコンポーネントで構成された非常に複雑なシステムです。マイクロサービス開発者は1日に何十回もデプロイすることがあるかもしれないため、カナリア・デプロイメントの増分的な性質がより安全な選択と考えられています。