概要
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を使うことで自動化することが出来ます。
いかがでしたか。今回はそんなに多くの比較を行うことが出来ませんでしたが、どのサービスを選択するか悩んだ時に読んでいただければ幸いです。