AWSでデプロイとスケーリングを自動化する方法まとめ

# 概要

AWSではアプリケーションのデプロイや、システムのスケーリングを自動化することができます。
しかしそれらを実現しようとすると、似たようなサービスの中から用途に合ったものを選ぶ事になると思います。
今回は選択肢となり得るサービスを挙げて、それぞれの出来る事、出来ない事をベースに比較していこうと思います。

### 比較の軸

以下のように、評価軸を設けました。

- サービスの機構として提供されているものは◯とします。
- 機構として提供されているが、使い難いものは△とします。(例: AWS CLIを利用した場合のみ利用可能など)
- 機構としては提供されていないが、別の機構などを組み合わせることで容易に実現可能なら△とします。
- 別の機構などを組み合わせても辛い場合や、実現不可能なら×とします。

# デプロイ自動化

まずはアプリケーションのデプロイを自動化するサービスの比較を行います。
以下の4つの選択肢があります。

- EC2 + User Data
- Elastic Beanstalk
- OpsWorks
- CodeDeploy

EC2 + User Dataはサービスではありませんが、一応頑張ればAMIから起動時に環境構築からコードの取得も行えるので、入れてみました。
ということで比較していきます。

### コードの取得

|項目|EC2 + User Data|Elastic Beanstalk|OpsWorks|CodeDeploy|
|:-:|:-:|:-:|:-:|:-:|
|手動でコードアップロード|×|◯|△(*1)|△(*1)|
|Gitから自動でコード取得|△|◯(CLI必須)|◯|◯|

*1 S3にファイルをアップロードすれば出来るみたいです。

Elastic BeanstalkがGitからコードを取ってくるようにするには、AWS Elastic Beanstalk Command Line Toolを利用しないと出来ないみたいですが、結構簡単に使えそうなので◯にしました。
Elastic Beanstalk Command Line Toolについては、以下が参考になりました。
http://qiita.com/YoshikiNakamura/items/55525fa0b17e74c25ceb

### 環境構築

|項目|EC2 + User Data|Elastic Beanstalk|OpsWorks|CodeDeploy|
|:-:|:-:|:-:|:-:|:-:|
|デプロイ時のスクリプト実行|◯|◯|◯|◯|
|環境構築まで行ってくれるか|×|◯|◯|×|
|EC2にAgentを入れなくても良い|◯|×|×|×|

環境構築まで行う機能を提供しているのはElastic BeanstalkとOps Worksだけでした。
この2つのサービスの環境構築について、より細かく比較してみます。

|項目|Elastic Beanstalk|OpsWorks|
|:-:|:-:|:-:|
|カスタムAMIを使用してのデプロイ|◯|◯|
|テンプレートから環境構築出来るか|◯|◯|
|Chefで環境構築|×|◯|
|Dockerで環境構築|◯|×|
|Microsoft Windowsの利用|◯|×|

Elastic Beanstalkは言語を選択すると、AWSが用意したAMIから環境構築が行われるみたいです。(参考: http://www.slideshare.net/AmazonWebServicesJapan/20130506-23096544)
一方、OpsWorksはAMIだけでなく、Chefでの環境構築も行うようです。
また、OpsWorksがサポートしているOSはAmazon LinuxとUbuntu 12.04 LTS、Ubuntu 14.04 LTSのみのようです。

### 使用できるテンプレート

テンプレートから環境構築できるのはElastic BeanstalkとOps Worksだけということがわかりましたが、それぞれデフォルトで用意されているテンプレートの種類を比較してみました。

|項目|Elastic Beanstalk|OpsWorks|
|:-:|:-:|:-:|
|Node.js|0.8.6 ~ 0.10.26|0.8.19 ~ 0.10.33|
|PHP|PHP 5.3 ~ 5.5|5.3(*1)|
|Ruby|Ruby 2.1 + Puma 2.8.1 + Nginx 1.4.7(*2)|Ruby 2.0.0 + Passenger 4.0.46(*2)|
|Tomcat|Java 8 + Tomcat 8|Java OpenJDK 7 + Tomcat 7|
|IIS|IIS 8.5|×|
|Python|Python 3.4 (Preconfigured - Docker)|×|
|HAProxy|×|◯|
|MySQL|×|◯|
|Memcached|×|◯|

*1 OSにUbuntu 14.04を指定した場合のみ、PHP 5.5が利用可能みたいです。(参考: http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/workinglayers-php.html)
*2 表示はデフォルトで選択されているものです。これ以外にもRubyのバージョンや、ミドルウェアの種類を複数の選択肢から選択可能です。具体的に指定できるバージョンは以下をご参照下さい。
Elastic Beanstalk: http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/create_deploy_Ruby_rails.html
OpsWorks: http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/workinglayers-rails.html

OpsWorksは、HAProxyやMySQL、Memcachedなどの、Webサーバ以外の環境も構築出来ます。
Microsoft Windowsを利用しなければならない場合はElastic Beanstalkを利用しなければなりません。

### 複数インスタンスへのデプロイ

|項目|EC2 + User Data|Elastic Beanstalk|OpsWorks|CodeDeploy|
|:-:|:-:|:-:|:-:|:-:|
|複数インスタンスへのデプロイ|△|◯|◯|◯|
|デプロイ順序の細かい指定など|×|×|×|◯|

EC2 + User Dataの複数インスタンスへのデプロイは、Auto Scalingと組み合わせることで実現可能です。
CodeDeployはデプロイ順の指定が細かく指定できます。デフォルトで以下の3種類のDeploy Configurationが用意されています。

- 1インスタンスずつデプロイ
- 半分だけデプロイ
- 全インスタンス一斉にデプロイ

### モニタリング

|項目|EC2 + User Data|Elastic Beanstalk|OpsWorks|CodeDeploy|
|:-:|:-:|:-:|:-:|:-:|
|デプロイ状況のモニタリング|×|◯|◯|◯|

# スケーリング自動化

次に、スケーリングの自動化を行うサービスの比較を行います。
システムのスケーリングを自動化するサービスなどには、以下の3つがあります。

- Auto Scaling
- Elastic Beanstalk
- OpsWorks

Auto Scalingはサービスではないですが、単体でもスケーリングを行うことができるので、比較対象に入れました。

### スケーリング時の挙動

|項目|Auto Scaling|Elastic Beanstalk|OpsWorks|
|:-:|:-:|:-:|:-:|
|ELBへの自動アタッチ|◯|◯|◯|
|スケール時にChefを使用|×|×|◯|
|スケール時にDockerを使用|×|◯|×|

それぞれのサービスがデプロイ時に実行可能な処理が、スケーリング時にも適用できるみたいです。

### スケーリングのトリガー

|項目|Auto Scaling|Elastic Beanstalk|OpsWorks|
|:-:|:-:|:-:|:-:|
|Cloud Watchベースでのスケーリング|◯|◯|×|
|時間ベースでのスケーリング|×|×|◯|
|Load Avarageベースでのスケーリング|×|×|◯|

OpsWorksは独自のメトリクスを使用してスケーリングを行います。そのためメモリ使用量やLoad Avarage等、Cloud Watchでは取得できない項目でのスケーリングが可能です。
ちなみにOpsWorksの時間ベースのスケーリング機能を使用すれば、指定した時間だけ起動するCronサーバ用インスタンスなども作れて非常に便利です。スケーリングとは関係ないですが・・・。

# まとめ

今回はデプロイとスケーリングの自動化という観点で、複数のサービスの比較を行ってみました。
中でもElastic BeanstalkとOpsWorksは、デプロイとスケーリングの両方で使えるサービスだということがわかりました。
両者には以下の様な違いがあるため、用途によって選ぶ必要があります。

- Elastic BeanstalkはAMIベースで環境構築を行う
- OpsWorksはAMI+Chefで環境構築を行う
- Elastic BeanstalkはCloudWatchのメトリクスをベースにスケーリングを行うことが出来る
- OpsWorksはCPU使用率、メモリ使用率、ロードアベレージ、時間をベースにスケーリングを行うことが出来る

ネット上にある記事を読んでみても、Elastic Beanstalkはよりシンプルだが、細かく設定する必要があればOpsWorksを使うべきだ、という主張が多いように感じます。
これらの違いは、OpsWorksが元々Peritor社の製品で、後からAWSによって買収されたことも関係するのかもしれません。

ちなみに、今回比較対象としたサービスではカバーできていない領域があります。例えば、今回はELBやSecurity Groupなどは手動で作成しましたが、この様な設定はCloud Formationを使うことで自動化することが出来ます。

いかがでしたか。今回はそんなに多くの比較を行うことが出来ませんでしたが、どのサービスを選択するか悩んだ時に読んでいただければ幸いです。