AWS OpsWorksの特徴
ここまでの解説で、OpsWorksがどのようなサービスであるのかイメージは理解して頂けたのではないでしょうか。最後に、OpsWorksの特徴的な要素を整理しておきます。OpsWorksの特徴的な要素として、以下の6つの要素が挙げられます。
Chefによる環境の自動構築
OpsWorksの大きな特徴の一つとして、最近話題のChefというツールを内部で利用して、環境構築やアプリケーションのデプロイを自動化していることが挙げられます。
前述した通り、ChefではRecipeと呼ばれるRubyのコードで書かれた構築手順書のようなものを事前に作成しておくと、実行の際にその手順通りに自動的に構築作業を行うことが可能です。構築作業がプログラムによって自動的に行われるため人的ミスが生じにくく、また構築対象の環境が大量にある場合に、作業の手間と時間を大きく削減できます。
また従来の運用では、構築手順書を別途ドキュメント化しておき、構成に変更があるたびに手順書もメンテナンスしてきたかと思います。Chefでは構築手順がすべてコードベースでRecipeに記述され、それを基に自動構築を行うため、従来のように別途ドキュメントとしての構築手順書を並行して維持管理する必要がなく、実際に構築時に使われるRecipeの実装作業と一体化できます。そのため、構築手順書の更新漏れで構築手順書と実際の環境構成に差異が出るといったこともなくなります。
このようなメリットがあるChefですが、Chefによる自動構築を行うには、まずChefが動作する環境を構築する必要があります。OpsWorksではEC2 Instanceを作成してChefを動かす環境を構築し、必要なChef Recipeを実行するまでの処理をすべて自動で行ってくれます。そのため、利用者はChefの実行環境構築に関して特に意識することなく、Chefの恩恵を受けられます。
Chefの利用形態は大きく分けて2つあります。クライアントサーバ構成のChef Server/Chef Clientと、単体のサーバで稼働するChef soloがあり、OpsWorksではChef soloを採用しています。Chef soloは利用が簡単な反面、他のサーバの最新の情報を得るのが難しいのですが、OpsWorksではChef soloで得られる情報に加え、OpsWorks独自の情報がRecipe内からAttributeとして参照でき、OpsWorksの同一環境内に存在する各サーバの情報も取得できるようになっています。
ライフサイクルイベントに応じたChef Recipeの自動実行
通常、Chef Recipeを実行するためには実行するRecipeの情報と共にknifeコマンドを実行したり、Chef-clientを呼び出したりする必要があります。しかしOpsWorksの場合は、特定のライフサイクルイベントが発生した際に、それぞれのイベントに紐付けたChef Recipeが自動的に実行されます。OpsWorksで用意されているライフサイクルイベントは以下の5種類です。
| ライフサイクルイベント名 | 発生タイミング |
|---|---|
| Setup | Instanceの起動時 |
| Configure | Stack内の構成が変化した時（Instanceの増減など） |
| Deploy | Deployコマンド実行時 |
| UnDeploy | UnDeployコマンド実行時 |
| Shutdown | Instanceの停止時 |
これらのライフサイクルイベントの発生時にChef Recipeが自動実行されると、環境の初回構築時以外のタイミングでもChefを簡単に活用できます。特に環境内のInstanceが増減した際に発生するConfigureをうまく活用すれば、オートスケール時に監視設定を自動的に追加・削除したり、新たに追加されたInstanceを自動的に負荷分散対象に追加するといったことが可能になります。それぞれのライフサイクルイベントの際にどのChef Recipeを自動的に実行するかは、Management Consoleから設定ができ、またManagement Consoleから手動で特定のRecipeの実行も可能です。
よく使われる構成をテンプレート化した定義済みLayerの提供
OpsWorksではすぐにサービスを使い始められるように、Webサービスでよく使われる構成を構築するためのChefのRecipeがすでに用意されており、それらのRecipeと設定情報をまとめたテンプレートに相当する、定義済みのLayerがAWSから提供されています。執筆時点でHAProxy、Nginx、PHP、Rails、Node.js、MySQLなどのLayerが公開されており、これらの構成そのままで問題がなければ、選択肢から選ぶだけで簡単にシステムの一部として利用できます。一部不足している要素がある場合も、追加したい要素の部分のChefのRecipeだけを作成して実行リストに追加すると、自由に拡張ができます。
新規のLayerを作りたい場合は、OpsWorksの稼働に必要な最低限のRecipeを含むCustomというLayerが用意されているので、これをベースに任意のRecipeを追加することでさまざまなLayerの作成が可能です。
Time-based/Load-based Instanceを用いたオートスケール
サービスの基となったScalariumの影響か、OpsWorksでは従来のAWSで提供されていたELBやAuto Scalingを用いた方式とは少し違った方式でオートスケールが実現されています。
先ほども少しだけ触れましたが、OpsWorksには常時稼働する24/7、スケジュールに応じて起動停止するTime-based、負荷に応じて起動停止するLoad-basedの3種類のInstanceが用意されています。これらのInstanceをうまく使いわけることで、特定の曜日・時間だけ自動的にサーバの台数を増減させたり、負荷に応じて自動的にサーバの台数を増減させることができます。
障害自動復旧機能（Auto Healing）
Auto Healingは、Instanceの障害を検知した際に代替となる新しいInstanceを自動的に立ち上げる機能です。OpsWorksの各InstanceではOpsWorks Agentと呼ばれるサービスが稼働しており、定期的にKeepaliveパケットを送信しています。それが途絶えた際にOpsWorksが自動的に新しいEC2 Instanceを作成し、Chefにより同じ環境を再構築します。
動作のイメージを表したのが以下の図9です。
EBSを自動的に引き継ぐため、うまく使えばDBのデータや障害時のログなどを失うことなく新Instanceへの移行を実現できそうです。ただし、トリガーとなるのはあくまでサービスの死活ではなくOpsWorks Agentの死活であるため、サービスの稼働については別途監視の仕組みが必要です。
Management ConsoleのGUIを用いた統合管理
AWSの他のサービスと同様に、OpsWorksもManagement Consoleから簡単に管理できます。実行するRecipeや設定情報を一度登録しておけば、Instanceの追加やアプリケーションのデプロイは画面から簡単な操作で実行が可能です。その時のChefの実行履歴や実行ログもManagement Consoleから確認できますし、また各Instanceの負荷に関する監視情報が確認できる画面も用意されているので、どのInstanceにどの程度の負荷がかかっているかをすぐに確かめられます。
まとめ
OpsWorksを利用すると、ユーザはChefを利用するための環境構築を意識することなく、Chefを利用した環境構成管理を簡単に利用できます。何種類かの基本的なLayerが最初から用意されているので、そのままの構成でよければElastic Beanstalkと同じくらいお手軽に環境を用意できます。また、ChefのRecipeを自作して追加すると柔軟に構成の変更が可能です。自分で作成するChefのRecipeは標準のLayer構成から変更したい部分だけで済むので、今話題のChefを用いた自動構築を手軽に始めてみたい人にお勧めのサービスと言えるでしょう。
現時点ではまだβ版ということもあり、Default VPC以外のVPCが利用できないといった制約はありますが、今後AWSの各種サービスとの連携や標準で提供されるLayerの追加が進めば、さらに魅力的なサービスとなっていくと思います。
次回は、統計解析向けプログラミング言語であるR言語のデータ解析結果を、ダイナミックなグラフで視覚化する方法を紹介します。
