Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
267
Help us understand the problem. What is going on with this article?

More than 5 years have passed since last update.

@hiro_koba_jp

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

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

267
Help us understand the problem. What is going on with this article?
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
267
Help us understand the problem. What is going on with this article?