皆様、こんにちは。先日リーダーからタスクを任されました。「そろそろ本番環境にAアプリの新しいバージョンをリリースする予定なので、デプロイをお願いしますね。」と聞いたら、少し憂鬱な感じがしました。

本番環境で稼働中のアプリを手に入れると、冷汗が出る感じがします。頭の中にあまり良くないシナリオが浮かびました。

汗がたくさん出始めて、“how to deploy without downtime／ダウンタイムなしでデプロイする方法“, “zero downtime deployment／ゼロダウンタイムデプロイメント “などのキーワードをグーグルで検索しました。その際、「Blue/Green Deployment／ブルー/グリーン・デプロイメント 」という概念に触れ、かなり興味を惹かれました 。

最初読んだときは混乱したものの、しばらくすると気づきました。これこそ、自分が探していたものでした。それで、今日はこの「救命ボート」のような存在をみなさんに共有したいと思います。

1.「ブルー/グリーン・デプロイメント」って何？

ブルー/グリーン・デプロイメントについて説明する前に、まずは従来のアプリケーションデプロイがどのように行われているのかを振り返ってみましょう。仮に、本番環境が1つしかないとします。アプリケーションをデプロイするたびに、通常は以下のような流れで作業が進みます。

上記のような従来のデプロイ方法には、さまざまな問題が発生します。

• ダウンタイムが発生することが確実： ユーザーはシステムにアクセスできなくなります。特にECサイトや金融システムでは、ダウンタイムはそのまま売上損失につながります。
• 障害リスクが高い： 精算ロジックの不具合などのバグがある場合、ユーザーへ直接影響を及ぼします。
• ロールバック時の困難： サーバーに問題が発生した際は以前のバージョンで復旧しなければなりません。デプロイの手順を再実現し、その結果としてシステムが再びにダウンタイムを伴うことになります。

上記の問題を解決するために、Blue/Green Deploymentは最適なソリューションとして登場しました。簡単に言うと、ダウンタイムとリスクを最小限に抑えるためのソフトウェアをデプロイする手法であり、構成がまったく同じで2つの本番環境を並行し稼働させる方法です。この2つの本番環境はそれぞれ「Blue」と「Green」と呼ばれます。

その中で

• Blue環境： 現在の本稼働環境（Live）、実ユーザーにサービスを提供中の安定版です。
• Green環境： Blue環境の「クローン」環境です。アプリの新しいバージョンをデプロイし、ブルー環境に影響を与えず検証を実施する場所です。

2.「ブルー/グリーン・デプロイメント」はどのように動作するのか？

基本的にはサービスの停止時間を最小限に抑えるために、2つの同一環境を並行しデプロイすることに基づいて動作してます。この方法は現在本番（live）で稼働している環境をまるごとコピーします。サーバー、仮想マシン、コンテナ、設定、さらにはデータベースまで含めてコピーし、現在環境と完全に同一構成の別環境を作成します。

しかし、Blue/GreenDeploymentはシステムを完全にコピーする必要がありません。特にデータベースに対して2つの環境でデータ同期を行うことが非常に難しいため、その代わりに、データベースのような共通コンポーネントは両環境で共有されることが多く、これによりコストや複雑性を抑えることができます。もちろんサービスの停止を避けるために、変更管理を貴重に行う必要があります。

Blue/Greenモデルにおけるデプロイのプロセスは以下のようになります。

1. まず、ユーザーは本稼働環境としてBlue環境で稼働しているバージョンを利用します。

2. その後Blue環境からコピーを作成することで、Green環境上で新しいバージョンをデプロイします。

3. Green環境が安定に稼働した後、Green環境にRouterやロードバランサーの向き先を切り替えるだけで、このプロセスのダウンタイムはほぼゼロに抑えることができます。切り替え後、Green環境が正式なLive環境になり、Blue環境は予備の役割として万が一問題が発生した場合に即座にロールバック（切り戻し）することができます。

4. しばらくGreen環境を観察し、安定稼働を確認後、次回時のデプロイにコピー元としてBlue環境を保持することができます。あるいは、運営費用の削減やインフラリソースの解放のために完全に削除することもできます。

3. Blue/Green Deploymentの応用性

Blue/Green Deploymentは新しいバージョンをデプロイするための安全なソリューションのみかかわらず、多くの重要な運用シーンにも適しています。

• アプリケーシのリリース： これは最も一般的なアプリケーションであり、WebアプリやAPIやマイクロサービスなどの新しいバージョン（リリース）をデプロイするためです。
• インフラのアップグレード： Blue/Greenは稼働中の本番環境に直接パッチ適用やアップグレードの代わりに、インフラの基盤コンポーネントを安全に変更させる可能です。
• データベース管理： これは通常、デプロイプロセスの中で最も困難な部分です。Blue/Greenデプロイでは、後方互換性（バックワードコンパティビリティ）を担保するために適切なマイグレーション戦略が必要です。具体的には、Green環境が古いスキーマでも動作すること、またロールバックが発生した場合にBlue環境が新しいスキーマでも動作することが求められます。幸いなことに、AWSRDSなどの多くのクラウドプラットフォームではBlue/Greenデプロイメントの仕組みがデータベースのバージョンアップ（例：MySQL 5.7から8.0へのアップグレードなど）にサポートされています。

4. Blue/Greenデプロイメントのメリットとデメリット

4.1. メリット

• ダウンタイムの最小化： サービスを中断することなく、システムのアップグレードをデプロイできます。ロードバランサーやDNSを介してトラフィックを切り替えるため、ユーザーへの影響はありません。
• 迅速かつ安全なロールバック： 新しい環境でエラーが発生した場合、即座にトラフィックを古い環境（Blue）に切り戻す（ロールバックする）だけで対応が可能です。

4.2. デメリット

• インフラコストの高騰： 同等のスペックを持つ2つの環境を維持する必要があるため、リソース（サーバー、データベースなど）のコストが2倍になります。
• データベース管理の複雑さ： データベースは通常共有されるため、完全に分離することが困難です。大規模なスキーマ変更を行う場合、新しいバージョンのアプリケーションは後方互換性を考慮して設計されていなければなりません。

参考資料

https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/introduction.html

https://www.blazemeter.com/blog/blue-green-deployment-testing

https://martinfowler.com/bliki/BlueGreenDeployment.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html