AWS
Beanstalk
opsworks
AutoScaling
CodeDeploy
LivesenseDay 23

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

More than 3 years have passed since last update.


概要

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を使うことで自動化することが出来ます。

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