Scalr.jpでAWS EC2を管理する #ScalrJP

Scalrとは

Scalrとは米国Scalr, Inc.が提供するマルチクラウド管理ソリューションです。
日本にもScalr.jpとして拠点を構えています。
詳しくはOSSクラウド連携ツール（Cloud Federation Tool）『Scalr』も参照してください。

Scalrの登録

SaaS版Scalrには30日間の無料試用期間があります。
Scalr.jpの右上の「Start Free Trial」ボタンから、氏名、メールアドレスなど必要事項を入力し、登録を行ってください。
なお、Scalr.comとは情報が共有されていないことに留意してください。

AWS EC2との連携

登録を行うとScalr.jpの管理画面へ遷移します。

既にAWSのアカウントを所持しているとします。
Scalrで管理する対象のEC2のAccess Key IDとSecret Access Keyを入力し、「Save keys」ボタンを押してください。
キーに間違いがなければ、Scalrの管理単位の1つであるEnvironmentが作成されます。
デフォルト名はEnvironment 1です。

Farmの作成

Farmとは、Scalrの管理単位の1つで、システム全体を表す管理単位です。
例えば、「ブログサイト」はFarmです。

画面上部のナビゲーションバーの左上の「Farms」ボタンを押すと、現在のFarm一覧が表示されます。
現時点では1つもFarmがありません。

「Add farm」ボタンを押し、Farmビルダーを呼び出します。

「Name」にはFarmの名前を入力します。
ここではtest-farmとし、「Save」ボタンを押してFarmを保存します。

Farmが追加されました。
右の「Actions」プルダウンから「Configure」を選ぶと、対象のFarmビルダーに戻ります。

Roleの追加

Roleとは、Scalrの管理単位の1つで、システムの構成要素を表す管理単位です。
例えば、「ブログサイト」はFarmで、それを構成するウェブサーバ、ブログアプリケーション、バックエンドデータベースの1つ1つがRoleです。

Scalr,Inc.ではEC2にさまざまなRoleのAMIを準備しており、それを利用することができます。
画面上部のナビゲーションバーの左上の「Roles」ボタンを押すと、利用可能なRoles一覧が表示されます。

Farmビルダーの左の「Add new role」ボタンを押すと、Farmに追加できるRoleの一覧が表示されます。

ここではApache Roleをtest-farmに追加します。
このRoleはApache HTTP Serverをインストールしたインスタンスイメージと考えてください。

LocationやOperating system、Instance typeを選択し、「Add to farm」ボタンを押してRoleをFarmに追加します。

オートスケーリングの設定

引き続き、追加したApache Roleの設定を行います。
左にあるRoleのアイコンを押してください。

ここでオートスケーリングの設定を行ってみます。
負荷が高まれば同一のRoleを持つインスタンスを増やし、収まればインスタンスを終了します。
当然ながら、インスタンス間の連携を行わなければオートスケーリングとして役に立ちませんが、ここでは単純に負荷によるインスタンスの自動起動と自動終了のみに着目することにします。

中央にある「Add scaling rule」ボタンを押すと、スケーリングの方法を選択するプルダウンメニューが表示されます。

ここでは「LoadAverages」を選択します。

テストを簡単にするため、スケーリングに用いるロードアベレージの値は1分のものを(Use 1 minute(s) load averages for scaling)、インスタンスを解放してスケールインする閾値をロードアベレージ1以下(Scale in (release instances) when LA goes under 1)、インスタンスを追加してスケールアウトする閾値をロードアベレージ2以上(Scale out (add more instances) when LA goes over 2)とします。

また、ダウンスケール後に最も古いインスタンスを保持する(Keep oldest instance running after scaling down)にチェックを入れます。
これはテストのために操作用のインスタンスを残しておくためです。

さらに、ダウンスケール中に1時間待たない(Do not wait for full hour during downscaling)にチェックを入れます。
EC2は1時間単位の課金のため、それに満たない時間でインスタンスを終了させてすぐにまたインスタンスが必要になった場合に余分に料金がかかってしまうので、Scalrはダウンスケール時に課金単位時間いっぱい待つようになっています。
今回はテストのため、ダウンスケールが行われた際にすぐにインスタンスを終了させる様子をわかりやすくする目的でわざと待たないようにしています。

最後に「Save」ボタンを押してRoleへの変更を保存します。

Farmの起動

右の「Actions」プルダウンから「Launch」を選び、対象のFarmを起動します。

FarmのStatusがRunningとなるので、ServersのViewをクリックします。

ServerのStatusがPendingとなり、EC2で対応するRoleのAMIを用いてインスタンスを準備しています。

しばらく待っているとStatusがRunningとなり、インスタンスの起動が完了します。

オートスケーリングの確認

ServersのActionsの左のアイコンを押すとMindTermが起動し、対象のインスタンスにコンソール接続しての操作が可能です。

ここでインスタンスに負荷をかけるため、abコマンド(Apache Bench)を利用します。
このインスタンスはApache Roleのため、Apache HTTP Serverが起動しており、abコマンドもインストールされています。
自分自身に対し、100万リクエストを50リクエストずつ同時に発行します。

ab -n 1000000 -c 50 http://127.0.0.1/

ただちにロードアベレージが上昇し、オートスケーリング設定に基いて新しいインスタンスが準備されます。

しばらく待つと、新しいインスタンスが起動しました。

今回はテストのため、両者のインスタンスは同じApache Roleですが特に連携しているわけではありません。
実際に活用するには別途ロードバランサーのRoleなどを準備して負荷分散の設定を行う必要があるでしょう。

一方、Apache Benchが終了して負荷をかけ終わると、徐々にロードアベレージが下がっていき、オートスケーリング設定に基いてインスタンスの停止が行われます。

停止できたインスタンスは削除されます。

この記事では非常に簡単にScalrとAWS EC2の連携とオートスケーリングについて紹介しました。
詳しくは公式ドキュメントを参考にしてください。