「ブルーグリーンデプロイメントの仕組み」を理解する：OpenStack上に構築する、ブルーグリーンデプロイメント実践入門（2）（2/3 ページ）

本連載では、「OpenStackを基盤としたブルーグリーンデプロイメント」を実現する“現場目線”のノウハウを解説していきます。今回は、「ブルーグリーンデプロイメントの利点とその仕組み」を説明します。

[佐々木智一，ユニアデックス株式会社]

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

　ブルーグリーンデプロイメントは、「システムのリリースを、2つの本番環境を使って安全に素早く行う手法」です（*1）。ブルー系／グリーン系、2つの本番環境を用意して、交互に切り替えられるように構築します（図1）。

図1　ブルー系／グリーン系、2つの本番環境を用意して、交互に切り替えられるようにする

（*1）ブルーグリーンデプロイメントは、2010年3月に米国のソフトウェア技術者であるマーティン・ファウラー氏によって書かれたブログで注目を集めました

　ブルーグリーンデプロイメントでは、一方（ブルー系）が本番としてサービス提供しているときには、他方（グリーン系）は待機している状態となります。新しい機能は、待機しているグリーン系側に追加して、事前にテストを実施します。その準備ができた時点でグリーン系を本番に切り替えます。「リリースそのもの」と「その準備」を別の時間帯で行えることが最大のメリットと言えます（図2）。

図2　新しい機能を待機している側（グリーン系）に追加して、テストを済ませてから、本番環境を切り替える。リリースと準備の行程を切り分けられる

　こうすることで、「システムの停止時間を限りなく少なく」でき、かつ「限られた時間で多くのことを確実に行わなければならない、切羽詰まった状況になる」のを避けられます。本番環境とステージング環境に差異が発生しないことから、差異に起因する不具合も避けられます。また、計画策定の多くを省くことも可能です。

　さらに、切り替えの直後は、元の本番環境（ブルー系）が待機側となって状態が保持されるので、万が一、切り替えた新しい本番環境に何らかの問題が発生したとしても、元に戻せます（図3）。

図3　万が一、新しい本番環境に問題が発生した場合にも、元の環境へ戻せる

大規模システムで既に採用されている、ブルーグリーンデプロイメント

　ブルーグリーンデプロイメントは、昨今登場したばかりの新しい考え方ではありません。既に米Amazon.comなどの大規模システムで実際に採用されています。

　Amazon Web Servicesのイベント「AWS re:Invent 2012」の基調講演で、同社CTO（最高技術責任者／当時）のヴァーナー・ヴォーゲルズ氏が「クラウドネイティブなデプロイ」という手法を取り入れたことを紹介しました。このシステムは、ロードバランサーの配下に2つの本番系を準備して切り替えるというもので、まさに本稿で紹介しているブルーグリーンデプロイメントと同様の手法です。これによりAmazon.comは、1時間に最大1000回以上のリリース／更新できる「スピード」を実現したそうです。

Amazon.comはブルーグリーンデプロイメントの手法で、「1時間に最大1000回以上のリリース」できるスピードを実現した

2012 re:Invent Day 2 Keynote: Werner Vogels（43分52秒付近）

　この他に、マイクロソフトのクラウドサービス「Microsoft Azure」で提供されるPaaS（Platform as a Service）である「Azure App Service」にもブルーグリーンデプロイメントと同様の機能が用意されています。Azure App Serviceは、任意のプラットフォームまたはデバイスを対象に、Webアプリ／モバイルアプリを作成できるサービスです。Webアプリをホストするための「デプロイメントスロット」と呼ばれる機能があり、現在の本番系を動作させつつも、新しい本番系を別に準備して、ボタン1つで本番系を切り替えられるようになっています。なお、デプロイメントスロットは、DNSで別の本番系に切り替えるアプローチとしているそうです。

Azure App Serviceに備わる「デプロイメントスロット」機能