デプロイ手法の中の一つであるBLUEGREENデプロイについて解説していきます。社内でBLUE/GREEN構成を採用しているプロジェクトがありますので、メリットデメリットとBLUE/GREEN切り替えにの流れを記載していきます。アーキテクチャ検討中の方の参考になれば幸いです。
BLUE/GREENデプロイメントについて
特徴
- BLUE/GREENの旧環境と新環境を２環境を利用します
- ダウンタイムなしにデプロイを実施可能です
メリット
- ダウンタイムなしでアプリ更新可能
- リクエストが来てない環境をアップデートし、メインサーバには影響しないため、デプロイ時は少し気がらく
- BLUE/GREEN切り替え後の不具合時、戻し作業が簡単
一番のメリットはダウンタイムなしでアプリ更新が可能となるところです。サービス停止が許されない場合に有効です。
動作確認後不具合があれば、旧環境への戻し作業が簡単なのもメリットです。
デメリット
- インフラ管理作業が２倍かかる
- コストが２倍かかる
- デプロイ作業が２倍かかる
- BLUE/GREEN切り替え時に不安
同一インフラを２環境持つことになるので、管理やコストが２倍になります。コストに関しては、運用にもよりますが、デプロイ時以外は１環境で動かすとコストは抑えられます。
BLUE/GREEN切り替え時は緊張が走ります。
ユースケース
- 24時間ずっとリクエストが来る場合、サービス停止が許されないの場面
BLUE/GREEN切り替えの流れ
次のBLUEGREENデプロイのざっくりした流れを説明していきます。デプロイ手順にもいくつか注意事項がありますので、そこ含めて説明していきます
BLUE/GREENイメージ図
以下、BLUE/GREEN構成のイメージ図です。
エンドユーザはProxyServerに対して、リクエストを送ります。リクエストを受け取ったProxyServerはRoute53レコード設定（リクエスト先が書かれたもの）に従いリクエストをなげます。
以下の例では、現在BLUEのみにリクエストが流れているという状況です。また、BLUE/GREENともに同一アプリバージョンがデプロイされてます。
GREEN側のアプリ更新
アプリバージョンを上げる場合、まずはユーザからのリクエストが来てないGREEN側から作業を開始します。アプリバージョンを最新にしたら、Route53を切り替える前に動作確認をします。また、AutoScalingにより本番台数が複数台になっている場合は、事前に台数を上げておく必要があります。
GREEN側へ切り替へ
上記での動作確認が問題なければ、Route53の設定をBLUEからGREEN側へ変更します。切り替え後にProxyServer経由で動作確認し、問題なければ切り替え完了です。問題発生時は、即時BLUE側へ切り替え戻し作業をします。
BLUE側のアプリ更新
GREEN側への切り替え後はBLUE側をアプリ更新します。が、すぐにBLUE更新するのではなく、1日や２日おいてからBLUE側を更新することが多いです。理由は、アプリ更新時はピーク時をさけているので、１，２回ピークを乗り切った後に更新します。
おわりに
ざっくりしたBLUE/GREENデプロイの切り替え手順はこんな感じです。説明のために今回はシンプルなインフラ構成になっています。こんなシンプルな構成はないと思いますが、一例として参考になればなと思います。
コメント