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

  • 249
    いいね
  • 7
    コメント
この記事は最終更新日から1年以上が経過しています。

概要

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

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

この投稿は Livesense Advent Calendar 201423日目の記事です。