こんにちは、サイオステクノロジー技術部 武井です。今回は、Elastic BeanstalkによるBule-Green Developmentを実践してみたいと思います。
Blue-Green Deploymentとは？
以下のように本番環境(図中ではProduction)とステージング環境(図中ではStaging)があるとします。文字通り本番環境では、現在ユーザーが利用中の本番向けのアプリ(Ver1.0.0)が稼働しているものとします。ステージング環境は次期バージョン(Ver2.0.0)が稼働しているものとします。そして、ステージング環境は十分にテストを重ねてリリースが可能となったものとします。
アプリケーションのエンドポイントURLはそのままに、ProductionとStagingをひっくり返します。すると下図のようになり、ユーザーはその後、Ver2.0.0のステージング環境にアクセスするようになります。このときから今までステージング環境だったものは実質上本番環境になります。これが、Blue−Green Deploymentです。
本番環境とステージング環境をひっくり返す手法は、DNSのCNAMEを変更するものだったり、色々あります。
Blue-Greenデプロイメントのメリットは以下のとおりです。
- 本番環境に近いステージング環境でリリース前に十分テストできる。
- リリースに伴うダウンタイムがほとんどない。
- ステップバックが簡単にできる。(もう一度ひっくり返せばよい)
Elastic BeanstalkでBlue-Green Deployment
本来であれば、このBlue-Green Deploymentは、DNSのCNAMEを変更したりと何らかの複雑な作業をする必要がありますが、Elastic Beanstalkの場合、ものすごーく簡単に出来ます。これを実践してみたいと思います。
まず、以下のような2つのPHPのソースコード(hogeと表示するものとfugaと表示するもの)を作成して、同じアプリケーションの中に2つの環境を作成します。環境の作成方法は、「さくっとすぐに始めるAWS Elastic Beanstalk入門 」を参考にして下さい。
<?php echo "hoge"; ?>
<?php echo "fuga"; ?>
以下のようになるはずです。環境名「BlueGrenn-env1」がhogeと表示する方(先の図でいうところのProduction)、「BlueGrenn-env2」がfugaと表示する方(先の図でいうところのStaging)とします。ProductionとStagingを入れ替えてみましょう。期待値としては、BlueGrenn-env1にアクセスするとfugaと表示されるはずです。
2つの環境を表示させた状態で、画面右上の「アクション」をクリックし、さらに「環境URLのスワップ」をクリックします。
「環境に関する詳細」の「環境名」にはProductionに相当する環境名選択します。「スワップする環境の選択」の「環境名」にはStagingに相当する環境名選択します。最後に「スワップ」をクリックします。
すると一瞬でProductionとStagingが切り替わります。試しに環境名BlueGrenn-env1のURLにアクセスすると、fugaと表示されるはずです。
まとめ
本来なら手間のかかるBlue-Green Deploymentがこんなに簡単にできるなんてElastic Beanstalkすごいですね。Elastic Beanstalkバンザーイ。
