AWS BLUE/GREENデプロイメント切り替え手順について

デプロイ手法の中の一つであるBLUEGREENデプロイについて解説していきます。社内でBLUE/GREEN構成を採用しているプロジェクトがありますので、メリットデメリットとBLUE/GREEN切り替えにの流れを記載していきます。アーキテクチャ検討中の方の参考になれば幸いです。

BLUE/GREENデプロイメントについて

一番のメリットはダウンタイムなしでアプリ更新が可能となるところです。サービス停止が許されない場合に有効です。

動作確認後不具合があれば、旧環境への戻し作業が簡単なのもメリットです。

同一インフラを２環境持つことになるので、管理やコストが２倍になります。コストに関しては、運用にもよりますが、デプロイ時以外は１環境で動かすとコストは抑えられます。

BLUE/GREEN切り替え時は緊張が走ります。

次のBLUEGREENデプロイのざっくりした流れを説明していきます。デプロイ手順にもいくつか注意事項がありますので、そこ含めて説明していきます

以下、BLUE/GREEN構成のイメージ図です。

エンドユーザはProxyServerに対して、リクエストを送ります。リクエストを受け取ったProxyServerはRoute53レコード設定（リクエスト先が書かれたもの）に従いリクエストをなげます。

以下の例では、現在BLUEのみにリクエストが流れているという状況です。また、BLUE/GREENともに同一アプリバージョンがデプロイされてます。

アプリバージョンを上げる場合、まずはユーザからのリクエストが来てないGREEN側から作業を開始します。アプリバージョンを最新にしたら、Route53を切り替える前に動作確認をします。また、AutoScalingにより本番台数が複数台になっている場合は、事前に台数を上げておく必要があります。

上記での動作確認が問題なければ、Route53の設定をBLUEからGREEN側へ変更します。切り替え後にProxyServer経由で動作確認し、問題なければ切り替え完了です。問題発生時は、即時BLUE側へ切り替え戻し作業をします。

GREEN側への切り替え後はBLUE側をアプリ更新します。が、すぐにBLUE更新するのではなく、1日や２日おいてからBLUE側を更新することが多いです。理由は、アプリ更新時はピーク時をさけているので、１，２回ピークを乗り切った後に更新します。

ざっくりしたBLUE/GREENデプロイの切り替え手順はこんな感じです。説明のために今回はシンプルなインフラ構成になっています。こんなシンプルな構成はないと思いますが、一例として参考になればなと思います。