Tech Sketch Bucket of Technical Chips by TIS Inc.

AWS OpsWorksを使ってみた (概要編)

Pocket

今回は2013年2月にβ版が公開されたAWSの新たなアプリケーション管理サービスであるAWS OpsWorksについて、その概要を紹介します。


AWS OpsWorksとは

AWS OpsWorks(以下OpsWorks)とは、環境構築とアプリケーションのデプロイの自動化・統合管理を実現するサービスです。OpsWorksを用いることで、柔軟に構成変更が可能な環境一式をAWS内に自動構築することができ、アプリケーションのデプロイもコンソールから指示するだけで自動的に行うことが出来ます。

AWSは以前からアプリケーション管理サービスに分類しているサービスをいくつか提供しています。AWS Elastic Beanstalkでは、アプリケーションを動かす環境一式を選択肢から選ぶだけで環境が自動構築され、アプリケーションコードだけを用意すればすぐにWebサービスを稼動させることができます。AWS CloudFormationでは、構築する環境構成を定義したテンプレートを作成しておくことで、テンプレートに従ってAWSの各種サービスを組み合わせたIaaS層の環境を自動構築することができます。今回紹介するOpsWorksは、Elastic Beanstalkのように環境構築までの時間を短縮しつつ、より柔軟な環境を構築できる、Elastic BeanstalkとCloudFormationの中間の特性を持つサービスとなっています。

OpsWorksはAWSが2012年に買収したPeritor社が提供していたScalariumというサービスが基となっており、2013年2月からβ版として提供が開始されました。

OpsWorksの特徴

OpsWorksの主な特徴として、以下の5つの特徴が挙げられます。

Chefによる環境の自動構築

OpsWorksの大きな特徴の一つとして、最近話題のChefというツールを内部で利用して環境構築やアプリケーションのデプロイを自動化していることが挙げられます。

Chefでは、レシピと呼ばれるRubyのコードで書かれた構築手順書のようなものを事前に作成しておくことで、実行するとその手順通りに自動的に構築作業を行うことができます。構築作業がプログラムによって自動的に行われるため人的ミスが生じにくく、また構築対象の環境が大量にある場合に作業の手間と時間を大きく削減することができます。

また従来の運用では、構築手順書を別途ドキュメント化しておき、構成に変更がある度に手順書もメンテナンスしてきたかと思います。Chefでは構築手順が全てコードベースでレシピに記述され、それを基に自動構築を行うため、従来のように別途ドキュメントとして構築手順書を維持管理する必要がなく、実際に構築時に使われるレシピの実装作業と一体化できます。そのため構築手順書の更新漏れで構築手順書と実際の環境構成に差異が出るといったことも無くなります。

このようなメリットがあるChefですが、Chefによる自動構築を行うためにはまずChefが動作する環境を構築する必要があります。OpsWorksではEC2インスタンスを作成してChefを動かす環境を構築し、必要なChefレシピを実行するまでの処理を全て自動で行ってくれるため、利用者はChefの実行環境構築に関して特に意識することなくChefの恩恵を受けることができます。

Chefの利用形態には大きく分けてクライアントサーバ構成のChef Server/Clientと、単体のサーバで稼動するChef soloがありますが、OpsWorksではChef soloを採用しています。Chef soloは利用が簡単な反面、他のサーバの最新の情報を得るのが難しいのですが、OpsWorksではChef soloで得られる情報に加え、OpsWorks独自の情報がレシピ内からAttributeとして参照できるようになっており、OpsWorksの同一環境内に存在する各サーバの情報も取得できるようになっています。

ライフサイクルイベントに応じたChefレシピの自動実行

通常、Chefレシピを実行するためには実行するレシピの情報と共にknifeコマンドを実行したり、Chef-clientを呼び出したりする必要がありますが、OpsWorksでは特定のライフサイクルイベントが発生した際に、それぞれのイベントに紐付けたChefレシピが自動的に実行されます。OpsWorksで用意されているライフサイクルイベントは以下の5種類です。

ライフサイクルイベント名 発生タイミング
Setup インスタンスの起動時
Configure 同環境内のインスタンス数増減時
Deploy Deployコマンド実行時
UnDeploy UnDeployコマンド実行時
Shutdown インスタンスの停止時

これらのライフサイクルイベントの発生時にChefレシピが自動実行されることで、環境の初回構築時以外のタイミングでもChefを簡単に活用することができます。特に環境内のインスタンス数が増減した際に発生するConfigureをうまく活用すれば、オートスケール時に監視設定を自動的に追加・削除したり、新たに追加されたインスタンスを自動的に負荷分散対象に追加するといったことが可能になります。それぞれのライフサイクルイベントの際にどのChefレシピを自動的に実行するかは、Management Consoleから設定できるようになっており、また手動で特定のレシピを実行させることもできます。

よく使われる構成をテンプレート化した定義済みLayerの提供

OpsWorksではすぐにサービスを使い始められるように、Webサービスでよく使われる構成を構築するためのChefのレシピが既に用意されており、それらのレシピと設定情報をまとめたテンプレートに相当する、定義済みのLayerがAWSから提供されています。執筆時点でHAProxy, Nginx, PHP, Rails, Node.js, MySQL等のLayerが公開されており、これらの構成そのままで問題がなければ、選択肢から選ぶだけで簡単にシステムの一部として利用することが出来ます。一部不足している要素がある場合も、追加したい要素の部分のChefのレシピだけを作成して実行リストに追加することで自由に拡張することができます。

新規のLayerを作りたい場合は、OpsWorksの稼動に必要な最低限のレシピを含むCustomというLayerが用意されているので、これをベースに任意のレシピを追加することで様々なLayerを作成することができます。

独自のスケーリングや障害自動復旧の機能

サービスの基となったScalariumの影響なのか、OpsWorksにはこれまでAWSで提供されていたELBやAuto Scalingを用いた方式とは少し違った方式でスケーリングや障害自動復旧を実現する機能が用意されています。
詳細な仕組みについては次回の記事で紹介する予定ですが、それぞれ一長一短ある方式となっています。

Management ConsoleのGUIを用いた統合管理

AWSの他のサービスと同様に、OpsWorksもManagement Consoleから簡単に管理することが出来ます。実行するレシピや設定情報を一度登録しておけば、インスタンスの追加やアプリケーションのデプロイは画面から簡単な操作で実行できます。その時のChefの実行履歴や実行ログもManagement Consoleから確認できますし、また各インスタンスの負荷に関する監視情報が確認できる画面も用意されているので、どのインスタンスにどの程度の負荷がかかっているかをすぐに確認できます。

OpsWorksの利用の流れ

それでは実際にOpsWorksを利用してみましょう。
ここでは利用例として、AWS公式サイト内に公開されている User Guide 内に記載があるサンプルアプリを動かしてみたいと思います。本稿では所々簡略化しているので、OpsWorksの機能をより詳細に知りたい場合はUserGuideに目を通してみて下さい。

Stackの作成

まずは他のAWSのサービスと同様に、Management ConsoleにログインしてOpsWorksの画面を開きます。初回アクセス時は Welcome to AWS OpsWorks の画面が表示されますので、Add your first StackをクリックしてStackを作成します。Stackとはこれから作成する環境一式を指す単位で、環境内で共有する設定を行うことが出来ます。

opsworks_stack.png

図1 Stack登録画面

図1がStackの登録画面です。ここで、デフォルトのOS, Region, AZ, SSH Key等が登録できます。自作のレシピを利用したい場合は、Advancedの所を開いてUse custom Chef Cookbooksという項目をYesにし、Cookbookの場所を指定する必要があります。今回は自作のレシピは使用しないのでNoのままで構いません。

Layerの作成

次にLayerを作成します。Layerとは、Web Server, App Server, DB Serverといった役割毎の雛形をまとめたものです。Stackの画面からAdd a layerを選択するか、Management Consoleの左側のメニューからLayersを選択し、+Layerを選択すると図2のような画面が開きます。

opsworks_layer1.png

図2 Layer登録画面 (Rails App Server)

プルダウンメニューの選択肢からもわかるように、様々なLayer typeが標準で用意されています。標準で用意されているLayerの中にはバージョン等の追加の設定項目を指定できるものもあり、例えば図2に映っているRails App Serverの場合、Rubyのバージョンの選択や、Rails stack (Passengerを使うかUnicornを使うか) の選択等もこの画面から設定できるようになっています。

今回はPHPのサンプルアプリを動かすので、Layer typeの中からPHP App Serverを選択して追加します。OpsWorksは5/14からELBを利用できるようになったので、せっかくなので今回はELBも指定してみました。ELBを指定する場合はOpsWorksで利用するリージョン内に事前に手動でELBを作成しておいて下さい。

opsworks_layer2.png

図3 Layer登録画面 (PHP App Server)

この登録時の画面には最低限の項目しかありませんでしたが、一度Layerを作成した後にEdit画面を開くと、実行するレシピの追加や割り当てるSecurity Groupの選択、EBSボリュームの追加、Auto Healing機能の有効化など様々な設定が追加で行えます。今回はデフォルトのまま利用するので次に進みます。

Instanceの追加

次に、先ほど作成したLayerにInstanceを追加します。Instanceには常時稼動する24/7の他に、スケジュールに応じて起動停止するTime-based, 負荷に応じて起動停止するLoad-basedを加えた3種類があります。
今回は24/7のInstanceを1台追加しましょう。

左のメニューからInstancesを選択し、PHP App Serverの所にあるAdd an instanceを選択すると、図4のようなフォームが現れます。

opsworks_instance.png

図4 Instance登録フォーム

今回はサンプルアプリを動かすだけなのでSizeはm1.smallで十分でしょう。その他の欄には、基本的にStackの設定項目のところで決めた値がデフォルト値として入っています。問題なければAdd instanceを選択して追加しましょう。

Instanceを追加した時点では、まだOpsWorksに登録されただけで、EC2インスタンスは存在していません。追加後にInstancesの画面からstartを選択すると、EC2インスタンスが作成されてChefにより自動的に構築が行われます。Instance Typeにm1.smallを指定した場合、構築には10分程度かかりました。構築が完了してStatusがOnlineになったら次へ進みましょう。

Appのデプロイ

最後にアプリケーションをデプロイします。画面左のメニューからAppsを選択してAdd an appを選択すると、デプロイするアプリの登録画面が開きます。

opsworks_app.png

図5 App登録画面

今回はAWSのUser Guide内で使われていたサンプルアプリである、SimplePHPAppをデプロイします。設定するのは、App Name, App Type, Repository Type, Repository URLの4箇所です。App Nameは自由につけて構いません。残りの3箇所はUser Guide内の記述に従い、App TypeはPHP, Repository TypeはGit, Repository URLは git://github.com/amazonwebservices/opsworks-demo-php-simple-app.git を指定して App app を実行します。
今回はAWSが用意しているGit Repositoryを指定しましたが、アプリケーションコードの置き場所はGitやSVNのリポジトリのほかに、S3のパスやHTTPでアクセスできるURLなども指定できます。

追加するとApp画面に登録したアプリが表示されますので、Actionの中にあるdeployを選択してデプロイ画面を開きます。

opsworks_deploy.png

図6 Deploy画面

今回は特に変更する箇所は無いのでそのままDeployを実行します。Advancedの欄を開くと、Chefのレシピに与える追加のJSONを指定したり、デプロイを実行するLayerやインスタンスを個別に指定することもできます。

実際にアクセス

デプロイ処理が完了すると、アプリケーションにアクセス可能な状態となっています。ELBを登録した場合はInstances画面のVisit URLを、ELB無しなら個別のインスタンスのPublic IPを開いてみると、以下の画面が確認できると思います。

opsworks_simplephpapp.png

図7 Simple PHP Appの画面

以上がOpsWorksを利用する際の基本的な流れです。
実際に利用する際はもう少し多様なLayerを追加したり、自作したChefのレシピを追加することになると思いますが、多少設定する箇所が増えるだけで基本的な流れは変わりません。

AWSの他のサービスとの使い分け

AWSには冒頭にも触れたように、OpsWorksの他にもアプリケーション管理サービスと位置づけられているサービスが存在します。ここで簡単にそれらのサービスの特徴と使い分けについて説明します。

AWS Elastic Beanstalk

Elastic Beanstalkとは、アプリケーションコードを用意するだけでそのアプリを動かす環境を自動構築してデプロイしてくれるサービスです。環境構成は動かすアプリに応じて数種類用意されており、その中から選ぶことができます。

Elastic BeanstalkがOpsWorksより優れている点として、OpsWorksの標準Layerよりも多くの種類の環境をサポートしている点と、Amazon RDS, ELB, Auto ScalingといったAWSのサービスと密に連携している点が挙げられます。Elastic BeanstalkではJava(Tomcat), .NETといった環境の選択肢も用意されており、より多様なアプリケーションを動かす環境を手間無く用意することができます。またOpsWorksで標準提供されているDB Layerは現時点ではMySQLだけで、冗長化の機能もありませんが、Elastic Beanstalkでは複数AZでの冗長化や自動バックアップに対応し、Oracle等も扱えるAmazon RDSと連携しています。

一方でOpsWorksが優れている点として、Chefを用いて自由に構成をカスタマイズできる点が挙げられます。Elastic BeanstalkでもCustom AMI機能を用いてAPサーバに対してはある程度変更を加えることは出来ますが、監視サーバやログサーバを追加したいといった場合はElastic Beanstalkとは別に構築する必要があります。OpsWorksではChefを使ってOS内の構成を自由に管理することができますし、Chefのレシピを用意すれば新たな役割を持つLayerを追加することも自由です。

これらの特徴から、Elastic Beanstalkの構成で要件を満たせるシンプルなWebアプリケーションであれば、Elastic Beanstalkを利用した方が手間も少なくすぐに使い始められるでしょう。一方で、より柔軟に環境構成を変更したい場合は、OpsWorksか、もしくは次に述べるCloudFormationを活用することになるでしょう。

AWS CloudFormation

CloudFormationとは、EC2, VPC, S3, ELB, Auto Scaling, Security GroupsといったAWSが提供している各種リソースの設定内容と組み合わせ方をテンプレートとして定義しておくことで、それを基に自動的に環境を構築してくれるサービスです。事前にテンプレートを作成しておくことで、指定したリソースを組み合わせた環境を自動で構築することができます。また設定変更が必要な場合も、テンプレートの該当箇所を更新した上でUpdateを実行すれば、更新箇所を判断して環境内の更新が必要な箇所だけを自動で更新してくれます。

CloudFormationがOpsWorksより優れている点として、AWSの多様なリソースに対応している点と、実行させる処理の自由度が高い点が挙げられます。OpsWorksでは組み合わせたいSecurity GroupやELB等は事前に手動で作成しておく必要がありましたが、CloudFormationはそういったリソースも含めて全て1つのテンプレートにまとめ、一括で自動構築することができます。またCloud-initと組み合わせればOSより上の層でも起動時に任意の処理を行えるため、起動時にChefをセットアップして実行すればOpsWorksと同様の自動構築も可能になります。

一方、OpsWorksがCloudFormationより優れている点としては、Chefの利用までの準備が不要であること、基本的なLayerが標準で用意されていてそれをベースにできることが挙げられます。CloudFormationではIaaS層もOS層も自由に組み合わせることができますが、そのためにはテンプレートを作りこんだり、cloud-initで実行させる処理内容を設計したりといった準備を全て自分で行わなければなりません。OpsWorksではChefを実行できる環境はOpsWorksが自動的に用意してくれますし、ベースとなる基本的なLayerが用意されているのでユーザは変更したい部分のChefレシピだけを用意すれば利用することができます。

これらの特徴から、EC2やELBのリソースがあれば十分で、標準で用意されている構成に少し手を加える程度で済むならばOpsWorksを利用した方が手軽に短期間で構築を終えられます。一方で、十分な知識を持つ人員を確保でき、VPCを始めとするAWSの様々なリソースを活用したり、OpsWorksのAttributeに依存しない汎用的なChefレシピを使いたいといった場合はCloudFormationを利用することになるでしょう。

導入の際に注意すべき点

ここまでで、OpsWorksがどのようなサービスなのか大体のイメージは掴んで頂けたかと思います。
最後に、現時点のOpsWorksを使う上で場合によっては少し気になるかもしれない点を挙げておきます。

現時点ではDefault VPC以外のAmazon VPCは利用できない

本稿の執筆時点では、OpsWorksではまだDefault VPC以外のAmazon VPCは利用できません。そのため、Amazon VPCが持つSubnetやVPN Gateway等の機能は利用できず、VPN接続が必要な環境の場合は対応が難しいです。Subnet内でのPrivateIPの固定ができないという課題もありますが、こちらの課題に対しては各サーバに対してホスト名でアクセス可能である(インスタンス数が変動する度に自動的にChefによって/etc/hostsが更新される)ため、それである程度は代替可能だと思われます。

構築順序を制御する仕組みが無い

CloudFormationにはWaitConditionという構築順序を制御するリソースが用意されていますが、OpsWorksでは現時点では構築順序を制御する仕組みがありません。そのため、複数のインスタンスを起動すれば並行して構築処理が実行されます。しかし例えばDB Masterを構築後にDB Slaveを構築したいといったように、構築順序に制約がある場合もあると思います。この場合は実行するレシピ側で順序を制御する工夫をするか、構築完了を確認しながら順番に起動する必要がありそうです。

構築途中のサーバの情報は他のサーバから参照できない

OpsWorksでは、ChefのAttributeに各Layerに存在するインスタンスの情報を追加しており、Chefのレシピから参照できるようになっています。しかしこのAttributeには、構築完了したインスタンスの情報しか含まれていないようです。これは未構築のインスタンスにアクセスを振り分けずに済むという点では便利ですが、並行してサーバを構築している最中に、まだ構築中のサーバの状態やIPアドレス等を知りたい場合に困るかもしれません

まとめ

OpsWorksを利用することで、ユーザはChefを利用するための環境構築を意識することなく、Chefを利用した環境構成管理を簡単に利用することが出来ます。何種類かの基本的なLayerが最初から用意されているため、そのままの構成でよければElastic Beanstalkと同じくらいお手軽に環境を用意でき、またChefのレシピを自作して追加することで柔軟に構成を変更できます。自分で作成するChefのレシピは標準のLayer構成から変更したい部分だけで済むので、今話題のChefを使った自動構築・再構成を手軽に始めてみたい人にお勧めのサービスと言えるでしょう。

現時点ではまだβ版ということもありVPCが利用できないなどの制約はありますが、5/15にはELBや監視ビューのサポート、7/24にはCustom AMIとChef 11.4のサポートが追加されるなど、短期間の間に様々な機能拡張が進められています。今後AWSの各種サービスとの連携や標準で提供されるLayerの追加が進めばさらに魅力的なサービスとなっていくと思います。

エンジニア採用中!私たちと一緒に働いてみませんか?