Blue Green Deployment
Tweet
はじめに
デジカでは、2015年4月から Blue Green Deployment を実践しています。それについて、良かった点と課題を含めて紹介したいと思います。
Blue Green Deployment とは
Blue Green Deployment という言葉は、マーチン・ファウラー氏の同名の記事 (日本語訳) から広まったものだと思います。簡単に言うと、本番用のサーバを２セット用意して、別のサーバで新しいバージョンを動かしてから切り替える形でリリースする手法です。
以下のような利点があります。
- graceful restart などの複雑な機能を使わずに、ダウンタイム無しで瞬時に切り替えができる
- ユーザに公開する前に、本番環境そのもので最終的な動作確認テストができる
- 万が一、新バージョンに問題があった時、すぐに前のバージョンに戻すことができる
気軽にサーバの増設、廃棄ができるクラウドならではの手法だと思います。デジカでも AWS 移行を機にこの方法を取り入れてみました。
デジカの Blue Green Deployment
デジカでは、次のような形でこれを行なっています。
- サーバリストやクラスタの状態は、Consul で管理
- 本番系/待機系の切り替えは、haproxy + Consul Template で行う
- いくつかツールを自作して、Slack から切り替えコマンドを実行している
- データベースは1系統で、本番系/待機系で共有している
一部簡略化してますが、以下のような構成になります。
手順としては、次のようになります。
- アプリケーションサーバは、起動時に Consul に自分を登録する
- Slack上のbot経由で、Consul KV Store 上の系統が書き換えられる
- 状態の更新がフロントエンドサーバ上の Consul Template に通知される
- Consul Template が、Consul 上の情報を反映して、haproxyの設定ファイルを書き換え再起動する
- haproxy が指示された方の系統に、リクエストを転送する
- 次の更新は、Travis-CI 経由で待機系のサーバに自動的にデプロイされる
- 待機系でテストを行い、OKならば、2へ
また、これらの本番用サーバとは別に、ステージングサーバも稼働しており、開発サイクルとして見ると、次のようになります。
- 開発者のローカルの環境で開発、テスト
- github の master branch に push
- Travis-CI経由で、ステージングサーバに自動的にデプロイされる
- ステージングサーバ上でテスト
- github の production branch に push
-
- Travis-CI経由で、本番用サーバ(待機系)に自動的にデプロイされる
- 待機系サーバ上で最終動作確認
- 本番系/待機系を切り替えてリリース
ステージングサーバでのテストと本番用サーバ(待機系)でのテストは次のように使い分けています。
- ステージングサーバはテスト用の（別の）データベースに接続しているので、データの更新までのテストができる
- 本番用サーバ(待機系)は、本番用データベースに接続するので、リアルタイムの実データによるテストができる（しかし更新はできない）
- ステージングテスト用DBは月一回程度、必要に応じ、本番用データから顧客の個人情報をダミーデータに置き換えて作成している
- ステージングサーバは、メールサーバや外部APIもテスト用の別系統のものに接続しているので、これらを使うテストもほぼ制限なくできる
- ステージングサーバでは、アプリケーションの変更部分を重点的にチェックする
- 本番用サーバ(待機系)では、インフラも含めた全体的な動作確認を行う
また、本番用サーバ(待機系)は、本番系と同様に Sensu によって監視していますので、必要なプロセスが起動してないとか応答が遅いなどの問題があったら、アラートによって通知されます。
Blue Green Deployment のメリット
実際にやってみて、この方法には多くのメリットがあると感じました。
- アプリケーションだけでなくインフラも含めた動作確認ができるので、より確実なリリースができる
- リリース時のプロセスの再起動が不要なので、予期せぬトラブルが少ない
- 旧バージョンが稼働状態で残っているので、万が一、新バージョンに問題があった時に、すぐに戻すことができる
全体として、リリース時の安心感が全く違います。
心理的な安心感があるということは非常に重要で、このおかげで、大胆かつスピーディーに開発、リリースを進めることができていると思います。
また、ミドルウエアやOSなどのセキュリティパッチや新バージョンへの切り替えも、ほぼ同様の方法でサービスへ影響を与えずに行えるので、必要があった時にすぐに行うことができます。
それと、センター単位の障害など、予想外の大きなトラブルがあった時にも、すぐに使える本番用サーバが二系統あるというのは、対策の選択肢が多くて安心です。幸いなことにまだ、実際にそのような対策を行った経験はありませんが。
Blue Green Deployment のデメリット
単純な話として、これをすると本番用サーバの費用が倍になります。しかし、これは上記のメリットと比較すると十分ペイするもののように感じます。サーバ代と人件費の比率にもよりますが、信頼性が増し、開発速度がアップすれば、サーバのコストは問題にならないケースが多いのではないか、と思います。
ただ、一方で、運用面では、問題点やデメリットもたくさんあります。これは主として上記の説明で省略した部分に関連しています。
- サーバ構成が複雑で分かりにくくなる
- リリースまでの手順が煩雑になる
- 本番用サーバ(待機系)のテスト方法が煩雑
サーバ構成が複雑で分かりにくくなる
実際の構成は、上記の図から、さらに以下の点で複雑になっています。
- フロントエンドサーバが SPOF(単一障害点) になるのを避けるために、これも二重化した
- そのため、haproxy の前にELBが稼働している
- アプリケーションサーバの中では、Nginx と二つの Rails アプリケーションが動いている
信頼性と開発スピードを両立するためには、必要な構成ではあるのですが、全体として非常に複雑になり監視対象も多くなります。
リリースまでの手順が煩雑になる
この方法だと、リリースの前に、ステージングサーバと本番用サーバ(待機系)での二段階のテストを行う必要があります。両者はできることが違うので、大きな変更の時は手間とは感じませんが、簡単な変更の場合は煩雑に感じます。
また、これはデジカ特有の事情ですが、デジカでは歴史的な経緯もあって、アプリケーションサーバ上のコードが、３つのリポジトリで管理されています。そのため、リリース時には、そのすべてのリポジトリについて間違いなく最新バージョンを動かす必要があります。
そのうち一つのリポジトリだけ変更してリリースする時と、２つ以上を同時に更新する必要がある時があって、その組み合わせによっては、切り替え時に一部のコードが古いバージョンのままで動いてしまうケースがあります。
この問題については、リポジトリを統合したり、一部をマイクロサービスとして切り離すなどの対策も進めていますが、現段階では、リリース前（系を切り替える前）に稼働してるバージョンを再確認するというステップが必要になっています。
ステージングサーバでのテストも含めて考えると、リリースまでのステップが多く煩雑であるという問題があります。
本番用サーバ(待機系)のテスト方法が煩雑
このアプリケーションは、アクセスしたURLのドメイン名を参照して処理を振り分けている部分があります。そのため、本番用サーバ(待機系)での動作確認の時は、アプリケーションが動作する環境が本番と全く同じなので、本番用のURLでアクセスしないと正しく動作しません。
そのため、ローカルマシン(開発者の使うPC)の環境を変えることで、本物のURLのままで、本番用サーバ(待機系)にアクセスできるようにする必要があります。そのため、テスト用のDNSサーバを立てて、開発マシンのDNSサーバとしてそのテスト用DNSサーバを指定することで、本番用サーバ(待機系)にアクセスしています。
そして、リリースしたらすぐに、本番用サーバ(本番系)での動作確認を行うので、このDNSの設定を元に戻す必要があります。
これが手間なので、他の方法を検討していますが、「URL(ドメイン名)が本番と同じ」という条件を満たす方法は見つかっていません。
特に、新バージョンと旧バージョンの表示を比較したい時や、トラブルで旧バージョンに戻す必要があった時には、この切り替えを何度も行う必要があります。そういうケースの切り替え方法については、改善すべきだと思っています。
反省点とアドバイス
当社での経験から反省点と、今後、これを実践しようという方に向けたアドバイスを書いてみます。
Consul と Consul Template はオススメ
Consul と Consul Template の組み合わせは、このような運用を行うためのツールとして非常に優れていると思います。
- 状態の変更 → 設定ファイルの変更 → サービスの再起動の流れが自然に記述できる
- アプリケーションサーバの増減や役割変更の管理が簡単にできる
という二点で、Blue Green Deployment に非常に向いています。
また、インストールや設定も簡単で、信頼性も高いです。
本番用サーバ(待機系)を監視対象に
本番用サーバは、本番系も待機系も同様にモニタリングの監視対象にしたほうがいいと思います。
本番用サーバ(待機系)を開発者のブラウザからテストするには意外に手間がかかるので、基本的な動作確認は、モニタリングで行ったほうがいいかもしれません。
本番用サーバ(待機系)の役割（の切り替え）を明確化すべし
この構成だと、本番用サーバ(待機系)には、以下の二つの役割(状態)があります。
- A: 新バージョンをテストする
- B: 旧バージョンのサーバを一切触らないで残しておいて、トラブルに備える
切り替え直後は、B:の状態で、新バージョンの動作が確認できた時点で、B:の役割は終了します。この時に、いったんサーバを停止して、次のリリースの準備ができた時点で、改めて起動して、A:の役割として使うことになります。
デジカでの反省点として、当初、この切り替えがあることを認識していなかったので、今でも、整理しきれていないと感じています。
「旧バージョンのサーバを一切触らないで残しておいて、トラブルに備える」という状態がいつまで必要で、誰がいつこれを終了するか、ということを事前によく考えておく必要があると思います。
「新バージョンで追加、変更した機能がいつOKになるか」という問題は、ケースバイケースで意外に難しく、なんとなく旧バージョンをずっと残しておきたい、という感じになってしまいます。実際、デジカでも、ほとんどの場合、サーバを落とすことはなくて、そのまま B -> A へ役割を切り替えていくような運用になっています。
アプリケーションが３つリポジトリで管理されていることから、この問題が一層複雑になっていて、なんらかの整理をする必要があると感じています。
Immutable Infrastracture との関連
Blue Green Deployment という言葉を、「毎回、新しく構築したサーバに新しいバージョンのアプリケーションを deploy して本番投入する」という意味で使っている方もいるようです。
マーチン・ファウラー氏の記事には、そのような記述はありませんが、Bule Green deployment は、いわゆる Immutable Infrastracture と相性がいいのは確かです。
現在のデジカの構成は、そのような運用形態も視野に入れて、毎回サーバから全部作り直すような運用もできるようになっています。
ただ、これを行うと、「旧サーバ停止」と「新サーバ構築」という手順がさらに増えてしまうので、今のところは、同じサーバを交互に使うという運用をしています。
これについては、インフラのテスト方法や、Dockerの導入などと一緒に次のフェーズで再検討したいと考えています。
これは今のところは、どちらがベストプラクティスか言える段階ではないのですが、使用済みサーバを毎回廃棄するか、そのまま次に回して交互に使うのは、重要なテーマになると思います。
本番用サーバの呼び方
デジカでは、次のように呼び方を決めています。
- 二系統サーバは、blue/green の色で呼ぶ
- 本番系は live 、 待機系は staged と呼ぶ
使用例
- 「今は、blue が live です」
- 「stagingではうまくいったのに、staged でエラーが出る、なんでだ！」
- 「今から green を再起動します。 staged のテストはしばらくできなくなります」
本番用サーバ(待機系)を staged と呼ぶのはデジカ独自のプラクティスだと思いますが、これもオススメです、というか広めたい。
この用語ではなくても、静的な二系統を区別する用語と動的な役割を区別する用語をきちんと決めておいた方がいいと思います。
まとめ
デジカでは、Consulをベースに、いくつかのツールを自作して、Blue Green Deployment を導入しました。これは、信頼性と開発速度の両立という点で、非常に大きな効果があったと感じています。
ただ、一方で、構成が複雑化して運用面での負担が増えているという問題点もあります。
Immutable Infrastracture や、開発サイクル全体を視野に入れて、運用のモデルや概念を再整理する必要があると感じています。