ブルーグリーンデプロイメントとは？流れやカナリアリリースとの違いをわかりやすく解説！

Webサービスを運用していると、新機能の追加や不具合の修正によって、アプリケーションを新しいバージョンへ更新することがあります。

その際に気になるのが、「更新中にサービスが止まらないか」「新バージョンに問題があったら元に戻せるか」という点です。

こうしたリリース時のリスクを減らす方法の1つが、ブルーグリーンデプロイメントです。

この記事では「ブルーグリーンデプロイメント」について、以下の内容をわかりやすく解説します。

• ブルーグリーンデプロイメントとは
• ブルーグリーンデプロイメントの流れ
• カナリアリリースやローリングアップデートとの違い
• ブルーグリーンデプロイメントのメリットとデメリット
• データベースや切り替え時の注意点

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

ブルーグリーンデプロイメント（Blue-Green Deployment）とは、旧バージョンと新バージョンを動かす2つの環境を用意し、ユーザーからのアクセス先を切り替えてリリースする手法です。

簡単にいうと、「今使っている環境を残したまま、別の環境で新バージョンを準備し、確認できたらアクセス先を切り替える」という方法です。

例えば、ネットショップに新しい検索機能を追加する場合を考えてみましょう。

現在ユーザーが利用している旧バージョンは、そのまま動かし続けます。その間に、別の環境へ新バージョンを配置し、商品検索や購入処理が正常に動くかを確認します。

問題がなければ、ユーザーからのアクセス先を新バージョンの環境へ切り替えます。これにより、旧バージョンのサービスを提供しながら、新バージョンの準備を進められます。

「ブルー環境」と「グリーン環境」について

ブルーグリーンデプロイメントでは、2つの環境を「ブルー環境」「グリーン環境」と呼びます。この記事では、次のように説明します。

環境	動かすバージョン	切り替え前の役割
ブルー環境	旧バージョン	ユーザーからのアクセスを受け付ける
グリーン環境	新バージョン	リリース前の動作確認を行う

グリーン環境は、切り替え後に本番のアクセスを受け付けるため、ブルー環境にできるだけ近い構成・設定で準備します。

アクセス先を切り替える仕組み

アクセス先の切り替えには、例えばロードバランサーを使います。ロードバランサーとは、ユーザーから届いたリクエスト（ページの表示などの要求）を、サーバーへ振り分ける仕組みです。

切り替え前はブルー環境へ、切り替え後はグリーン環境へリクエストを送るように、振り分け先を変更します。

ユーザーがアクセスするWebサイトのURLを変えずに、裏側で処理する環境を切り替えられるのがポイントです。

なお、必ずしも物理サーバーを2組用意する必要はありません。仮想マシンやコンテナなどで、切り替え可能な2つの環境を構成することもできます。

ブルーグリーンデプロイメントの流れ

ブルーグリーンデプロイメントの具体的な流れを以下に示します。

• ブルー環境で旧バージョンを提供する
  • ユーザーからのアクセスはブルー環境へ振り分けます。グリーン環境を準備している間も、旧バージョンのサービスを提供し続けます。
• グリーン環境に新バージョンをデプロイする
  • デプロイとは、アプリケーションを実行環境に配置し、動かせる状態にすることです。この段階では、一般ユーザーのアクセス先はブルー環境のままです。
• グリーン環境の動作を確認する
  • テスト用のアクセス経路などを使い、新バージョンを確認します。ネットショップであれば、商品検索、ログイン、注文処理などをチェックします。
• アクセス先をグリーン環境へ切り替える
  • 問題がなければ、ロードバランサーなどの設定を変更して、新バージョンへ本番のリクエストを送ります。
• 切り替え後の状態を監視する
  • エラーの発生状況、応答時間、注文処理の成功率などを確認します。事前テストで問題がなくても、実際のアクセスによって不具合が分かる場合があります。
• 問題があればブルー環境へ切り戻す
  • 旧環境を利用できる状態で残していれば、アクセス先をブルー環境へ戻せます。旧バージョンへ戻すことを「ロールバック」と呼びます。

新バージョンが安定していると判断できたら、旧環境を次回のリリース用に再利用したり、不要なリソースを削除したりします。

切り替え直後に旧環境を削除すると、アクセス先を戻すだけのロールバックはできなくなります。 旧環境を残す期間や、切り戻す条件を事前に決めておくことが大切です。

ブルーグリーンデプロイメントとカナリアリリースとローリングアップデートの違い

ブルーグリーンデプロイメントとカナリアリリースとローリングアップデートとの違いを以下に示します。

ここでは、ブルーグリーンデプロイメントはアクセス先をまとめて切り替える基本形として比較します。なお、2つの環境を用意し、カナリア方式で段階的にアクセスを切り替えるなど、手法を組み合わせることもできます。

比較項目	ブルーグリーンデプロイメント	カナリアリリース	ローリングアップデート
手法	2つの環境（ブルー環境とグリーン環境）を切り替えて一度にリリースする	一部のユーザーやリクエストに新バージョンを提供し、段階的に展開する	全インスタンスを段階的に新バージョンに切り替える
リリース対象	全ユーザー	最初は一部のユーザーやリクエスト。問題がなければ全体へ拡大する	全ユーザー
安全性の確認	切り替え前に新環境で動作確認を行い、切り替え後も監視する	一部のユーザーやリクエストで動作確認を行いながら、公開範囲を広げる	更新中に段階的に動作確認を行う
ロールバックの方法	問題が発生した場合、アクセス先を旧環境へ切り戻す	問題発生時は新バージョンへの振り分けを止め、対象範囲を旧バージョンに戻す	問題が発生した場合、更新したインスタンスを段階的に旧バージョンに戻す
適しているケース	アクセス先をまとめて切り替え、全体に新バージョンを展開したい場合	高リスクの新機能や変更を段階的にリリースし、安全性を確認したい場合	サービスの停止時間を抑えつつ、サーバーやコンテナを順番に更新したい場合

上記の表から分かるように、ブルーグリーンデプロイメントは、2つの環境を切り替えて一度に新バージョンをリリースする手法です。

カナリアリリースは、新バージョンを一部のユーザーやリクエストに限定して提供し、問題がないかを確認しながら、段階的に適用範囲を広げる方法です。

ローリングアップデートは、インスタンス（アプリケーションを動かすサーバーやコンテナなど）を段階的に新しいバージョンに切り替える方法です。

ブルーグリーンデプロイメントのメリットとデメリット

ブルーグリーンデプロイメントのメリットとデメリットを以下に示します。

こうした特徴から、停止時間を抑えたいサービスや、問題発生時に旧環境へ素早く戻したいサービスで検討しやすい手法です。一方で、追加コストやデータの扱いも含めて判断する必要があります。

ブルーグリーンデプロイメントの注意点

2つの環境を用意するだけで、安全に切り替えられるとは限りません。ブルーグリーンデプロイメントの注意点についてこれから説明します。

データベースの変更は、アクセス先を戻すだけでは元に戻らない

ブルーグリーンデプロイメントでは、アプリケーションの環境を2つに分け、データベースは共通のものを使う構成もあります。

この場合、新バージョンがデータベースへ行った変更は、旧環境へ切り戻しても残ります。

例えば、旧バージョンが使う「住所」の項目を、新バージョンの公開時に削除したとします。アクセス先を旧環境へ戻しても「住所」の項目は復活しないため、旧バージョンが正常に動かなくなる可能性があります。

そのため、データベースの構造を変えるときは、旧バージョンと新バージョンの両方が動く状態を保つことが大切です。例えば、新しい項目を先に追加し、新バージョンが安定して旧バージョンへ戻す必要がなくなってから、不要な項目を削除します。

また、データベースも2つに分ける場合は、切り替え前に旧環境で更新されたデータを新環境へ反映する仕組みが必要です。さらに、新環境で受け付けた注文などを、切り戻し先へどう引き継ぐかも設計しておきます。アプリケーションを戻すことと、データを安全に扱うことは、別々に考える必要があります。

処理中のリクエストやログイン状態を考慮する

切り替え時には、ブルー環境で注文処理やファイルのアップロードが進んでいるかもしれません。処理の途中で旧環境を停止すると、エラーが起きる可能性があります。

そのため、新しいリクエストはグリーン環境へ送りつつ、旧環境で処理中のリクエストには、完了するための待ち時間を設けるといった対応が必要です。

ログイン状態を維持するための情報（セッション情報）を旧環境のメモリだけに保存している場合は、新環境でその情報を参照できず、再ログインが必要になることもあります。共有の保存先を利用するなど、切り替え後も必要な情報を引き継げるように設計します。

本記事のまとめ

この記事では『ブルーグリーンデプロイメント』について、以下の内容を説明しました。

• ブルーグリーンデプロイメントは、2つの環境を用意し、アクセス先を切り替えて新バージョンを公開する手法です。
• 新環境を切り替え前にテストし、切り替え後も実際の動作を監視します。
• カナリアリリースは公開範囲を、ローリングアップデートはサーバーやコンテナを、段階的に切り替えます。
• 停止時間を抑え、旧環境へ戻しやすい一方で、2環境分のリソースや管理が必要になります。
• 安全に切り戻すには、旧環境を残すだけでなく、データベースやセッション情報などの扱いも考慮する必要があります。

お読みいただきありがとうございました。