「Blue-Green Deployment」とは何か、マーチン・ファウラー氏の解説

1つ前の記事で紹介した、チャド・ファウラー氏によるImmutable Infrastructureの記事「Immutable Infrastructure（イミュータブルインフラストラクチャ）と捨ててしまえるコンポーネント」では、デプロイをより安心して行うために、サーバの内容を変更する際には既存のサーバに手を加えるのではなく、新規に作り直して切り替える、という方法を提案しています。これがサーバの不変性、すなわちImmutable Infrastructureにつながるわけです。

BlueGreenDeployment

これから紹介するマーチン・ファウラー氏の記事「BlueGreenDeployment」は、Immutable Infrastractureが昨年話題になるさらに前の2010年3月に書かれたものです。この方法はマーチン・ファウラー氏自身が次のように書いているとおりカットオーバー時のダウンタイムをできるだけ短くすることが主眼だと説明されています（マーチン・ファウラー氏が出典として言及した書籍「継続的デリバリー」でも、ゼロダウンタイムリリースのテクニックとして紹介されています）。

デプロイメントの自動化における課題の1つは、ソフトウェアをテストの最終段階からプロダクションへともっていくカットオーバーそれ自体にある。通常はこの作業を迅速に行うことで、ダウンタイムを最小化しなければならない。blue-green deploymentはこれを、可能な限り同じにした2つの本番環境によって確実に行うようにしている。

この点でBlue-Green Deploymentは、サーバの内容を変更しないことを安定したデプロイにつなげるImmutable Infrastructureとは異なるアプローチをとったように読めます。

マーチン・ファウラー氏の記事は翻訳が許可されているので、以下にその記事の翻訳を紹介します。

BlueGreenDeployment

（2010年3月1日 Martin Fowler著）

あるお客様のために同僚と一緒に私が目指していたのが、完全に自動化されたデプロイメントプロセスの実現だ。デプロイメントを自動化することは、ソフトウェアの完成とその価値を現実化することの間に存在する摩擦や時間の削減につながる。

Dave FarleyとJez Humbleがこのトピックについて「Continuous Delivery」という本を出している（日本語の書籍は「継続的デリバリー」）。これはContinuous Integrationと共通した多くのアイデアを基にしている。ソフトウェアを迅速に本番環境へと推し進められるようにすることで、価値を得ようとするのだ。

まだ用いられていないそうしたテクニックの1つとして、私はこの本の「blue-green deployment」の章に着目した。ここではその概要を紹介したいと思う。

デプロイメントの自動化における課題の1つは、ソフトウェアをテストの最終段階からプロダクションへともっていくカットオーバーそれ自体にある。通常はこの作業を迅速に行うことで、ダウンタイムを最小化しなければならない。blue-green deploymentはこれを、可能な限り同じにした2つの本番環境によって確実に行うようにしている。

例えばいまBlue環境がライブで、新リリース用のソフトウェアがテストの最終段階にあるとしよう。そのソフトウェアがGreen環境で稼働し始めたら、ルータを切り替えて外部からのリクエストをGreen環境へ行くようにする。するとBlue環境はアイドル状態になる。

Blue-Green Deploymentは迅速なロールバックも実現する。もしもなにか問題が起こったときには、ルータをBlue環境へと切り戻せばいい。このとき、Green環境がライブのときのトランザクションが失われることをどう扱うか、という問題が残っているが、これはシステムのデザインに依存するものであり、例えば、GreenがライブになったときにBlue環境をGreen環境のバックアップとして扱うといったことで両方の環境に対してトランザクションをフィードできる。

あるいはカットオーバーの前にアプリケーションをリードオンリモードでしばらく稼働させ、その後リード／ライトモードへスイッチする、という方法もある。これで顕著な問題の多くに対応できるだろう。

2つの環境は異なったものだが、可能な限り同じにしておく必要がある。それらは異なったハードウェアだったり、同一マシン上の（あるいは別のマシン上の）仮想マシンだったり、あるいは同一OS上で異なるIPアドレスを持った別のゾーンであったりもするだろう。

この手法の優れている点は、ホットスタンバイの実装と基本的には同じ仕組みであることだ。そのため、リリースごとにディザスタリカバリの手順でテストできる（災害が発生するよりも頻繁にリリースしてもらいたいと私は思っているが）。

この手法の基本的な考えは、2つの切り替え可能な環境を切り替えることであり、その詳細についてはさまざまなものがあるだろう。ルータではなくWebサーバでの切り替えなども考えられる。

こうしたテクニックは長年に当たって問題外なものとされ、そうすべきときにさえ使われてこなかったと思う。私には、ぼんやりとDan NorthとJez Humbleの組み合わせが名前ととも思い浮かんだ。

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
現代では継続的にソフトウェアをリリースすることが必須になっています。本書は、継続的なソフトウェアのデリバリーを実現するためのビルド、デプロイ、テスト、リリースの自動化についての本格的な解説書です。

※ 参考：Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（前編）
※ 参考：Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（後編）