Blue-greenデプロイ戦略を解説

Blue-greenデプロイとは？

Blue-greenデプロイとは、アプリケーションの旧バージョンと新バージョンを、同一構成の2つの本番環境で並行して稼働させるデプロイ戦略です。たとえば、旧バージョンをBlue環境で稼働させ、新バージョンのテストをGreen環境で行います。テスト完了後、ルーターやロードバランサーでリクエストを徐々にGreen環境へ振り分けます。その後、開発者がスモークテストを実施してから、トラフィックをGreen環境へ完全に切り替えます。

このアプローチでは、同様の本番環境を2つ（BlueとGreen）用意し、ソフトウェアの更新をリリースします。

• Blue環境：アプリケーションの現行の本番バージョン

• Green環境：テスト中のアプリケーションの新バージョン

Blue-greenデプロイの仕組み

Blue-greenデプロイの流れは次のとおりです。

1. デプロイ

アプリケーションの新バージョンをGreen環境にデプロイします。

2. テスト

新バージョンがパフォーマンスとセキュリティの要件を満たしていることを確認するため、Green環境でテストします。

3. 切り替え

新バージョンの安定性を確認したら、トラフィックをBlue環境からGreen環境に切り替えます。

4. ロールバック

問題が見つかった場合は、トラフィックをBlue環境に戻せます。

Blue-greenデプロイが効果を発揮する場面

Blue-greenデプロイは、次のような状況で特に効果的です。

• 両方の環境が同一構成で、互いに分離されている。

• ルーターまたはロードバランサーを利用できる。

• システムが継続的なアップデートに対応している。

DevOpsプロセスにおけるBlue-greenデプロイの重要性

効率的なDevOpsパイプラインに欠かせないのは、コードを効率よくエンドユーザーに届けることです。コード変更を継続的にデプロイすれば、ソフトウェアを迅速にリリースできますが、自動チェックで見逃されたバグや脆弱性が本番環境に持ち込まれる可能性もあります。組織によっては、開発者自身がコードをデプロイする場合もあれば、CI/CDパイプラインでビルド成果物を作成し、運用チームがデプロイする場合もあります。

いずれの場合も、チームには新しいアプリケーションのバージョンをサンドボックス環境ですばやくテストし、ユーザーにデプロイして、本番環境で問題が見つかった場合は以前のバージョンにロールバックする方法が必要です。新リリースへの切り替えは慎重に検討する必要があります。現代の開発チームは「早く、頻繁にリリースする」という考え方で運用されることが多く、オフピーク時にダウンタイムを設定する必要がある複雑なリリースとは相容れません。ダウンタイムを最小限に抑えるため、切り替えは迅速に行う必要があります。

Blue-greenデプロイの基本的な考え方は、同一構成の本番環境を2つ用意し、一方を旧バージョン用、もう一方を新バージョンのステージングテスト用にすることです。2つの環境には、異なる物理デバイスや仮想マシンを使うことも、環境ごとに別のIPアドレスを割り当てたオペレーティング環境を使うこともできます。

Blue-greenデプロイのメリット

• すぐにロールバックできる。ステージング環境と本番環境がほぼ同一のため、Blue-green方式ではバグを発見しやすくなります。Green環境で稼働する新しいアプリケーションに問題が見つかった場合、開発者はリクエストをBlue環境の旧バージョンへすぐに戻せます。ユーザーにダウンタイムを発生させず、迅速にロールバックできます。

• シームレスなアップグレード。Blue-greenデプロイでは、ソフトウェアが「書かれてから」本番環境で稼働するまでの移行を自動化します。アップグレードの初期段階ではGreen環境をテストに使用し、その後、新バージョンの本番環境として稼働させます。ロールバックが必要になる場合に備え、Blue環境もしばらく稼働させておきます。その後、Blue環境を停止し、次回のリリースではステージングテストに使用します。

• ダウンタイムがない。開発者は準備ができ次第、通常の利用時間帯に新しいコードを本番環境へ移行できます。深夜や週末などの利用が少ない時間帯を待つ必要も、ダウンタイムを設定する必要もありません。さらに、ステージング環境を災害復旧のテストやバックアップに利用できます。

Blue-greenデプロイのデメリット

状況によっては、Blue-green方式に伴うリスクにより、デプロイが失敗や障害につながりやすくなる場合があります。

• データベースの同期：スキーマ変更の管理は難しい場合があります。Blue-greenデプロイでは、データベースとデータの変更をBlue環境とGreen環境の両方で同期する必要があります。同期が不十分だと、不整合が発生する可能性があります。

• QA/UATでの検出漏れ：大規模なインフラでは、本番以外の環境でQAテストを行っても特定のエラーやバグを見逃し、デプロイ前に問題を検出できない可能性があります。

• ダッシュボードが必要：この方式では、異なるコードバージョンを含む2つの本番環境を維持します。そのため、デプロイ中にパッケージやコードの状態を監視し、適切に制御して必要なアクションを実行するためのインサイトが不可欠です。

• コストへの影響：Blue-Greenデプロイでは並行する環境を2つ用意する必要があるため、運用と保守にかかる本番環境のコストが実質的に2倍になります。

Blue-greenデプロイとアプリケーションのロードバランシング

Blue-greenデプロイでは、切り替え時のユーザーへの影響を最小限に抑えるため、慎重に実装する必要があります。切り替えにはDNSレコードの切り替えを利用する方法がありますが、DNSの伝播には時間がかかるため、制約があります。

別の方法として、アプリケーションのロードバランシングを使い、Green環境へトラフィックを徐々に振り分けることができます。これにより、ユーザーへの影響を細かく制御できます。Green環境でエラーが発生した場合、ロードバランサーでトラフィックを切り戻すこともできます。また、Blue環境のユーザーを切断したり、セッションを終了したりする前に、一定時間待機するよう設定することも可能です。

全体として、トラフィックの振り分け前にユーザーへセッションの終了を強いる場合と比べ、アップグレードがよりシームレスになり、混乱も少なくなります。ロードバランシングによって処理が遅くなったり、一部のユーザーで失敗したりする可能性はありますが、ほとんどのユーザーはダウンタイムや違いに気づきません。

その他のデプロイ戦略

• Blue-greenデプロイ：Blue-greenデプロイは高可用性を実現し、重大なバグが見つかった場合も簡単にロールバックできます。2つの環境を並行して稼働させ、一方を本番稼働、もう一方を待機状態にすることで、アプリケーションのダウンタイムを最小限に抑えます。

• A/Bデプロイ：Blue-Greenデプロイと同様に、A/Bデプロイではトラフィックの一部を別のサーバーや環境に振り分けます。この手法は、新バージョンの機能利用状況を評価し、ユーザーのフィードバックを収集するためによく使われます。

• カナリアデプロイ：カナリアデプロイでは、サーバーをユーザーグループごとに割り当て、新機能を一部のユーザーに段階的にリリースします。機能を段階的にデプロイしながら、リリースを通じてフィードバックを収集するのに適した方法です。ローリングデプロイ：旧バージョンのアプリケーションを稼働させるサーバーを、新バージョンを稼働させるサーバーに順次置き換える方法です。必要に応じてデプロイを中断しやすいという利点があります。

Blue-greenデプロイとカナリアデプロイの違い

Blue-greenデプロイとは異なり、カナリアデプロイではテスト用と本番用に別々の環境を用意する必要はありません。DevOpsチームや運用チームが一部のユーザー（「カナリア」）に変更をデプロイしてリリースをテストし、その後、全ユーザーに展開するかどうかを判断します。

別々の環境を使わないため、カナリアデプロイに必要な追加インフラはわずかです。予備のノードやサーバーを利用してセットアップでき、本番環境の一部と少量のトラフィックを処理するために必要なリソースだけで済みます。

Infrastructure as Code（IaC）を使ったBlue-greenデプロイ

Blue-greenデプロイは、技術面とビジネス面のリスクを抑えながらソフトウェアをすばやくリリースできる強力な手法です。一方で、セキュリティについても慎重に考慮する必要があります。Webサーバー、コンテナ、マイクロサービスを使う複雑なアプリケーションアーキテクチャとデプロイ環境に加え、CI/CDパイプラインでビルド、テスト、デプロイを自動化するツールの利用は、設定ミスや安全でない環境、切り替え後に発覚する予期せぬ問題につながる可能性があります。

従来のアプリケーションセキュリティでは、IaCインフラストラクチャの保護が不十分です。本番環境にデプロイされたアプリケーションに焦点を当てるため、バグや脆弱性がエンドユーザーに影響する可能性があります。セキュリティチームは開発者とは別に運用されているため、問題を発見しても修正は開発チームに頼らざるを得ず、デリバリーのボトルネックや、開発者とセキュリティ担当者の優先順位の不一致につながります。さらに、セキュリティはCI/CDパイプラインに組み込まれず、開発プロセスの外部機能として扱われています。

Blue-greenデプロイとIaCツール

幸いなことに、解決策があります。Snyk Infrastructure as CodeはCI/CDパイプラインとシームレスに統合し、本番環境に反映される前に設定を保護します。開発者を第一に考えて設計されており、コード内の問題を自動修正できます。Snyk IaCには、Terraformファイルとプラン、AWS CloudFormation、Kubernetesの設定、Azure Resource Manager（ARM）を対象とした自動テストが含まれています。開発チームはCI/CDパイプライン全体でIaCスキャンを実行し、設定の問題を早期に検出して修正できます。DriftCTLによるドリフトテストでは、通常のフロー外で人やツールによって加えられたデプロイ後のインフラ変更も検出します。これにより、ビルド、テスト、デプロイのセキュリティに対する責任を開発者が担い、IaCツールを使ったBlue-greenデプロイでDevSecOpsの原則を実践できます。