AWS OpsWorksでオートスケール用のTimeBase,LoadBaseインスタンスをつかう

AWS OpsWorksを使ってオートスケールを組み立てようと思い、用意されているスケール対応インスタンスタイプを調べてみました。

inst01.jpg

ちなみにOpsWorksはCloudWatchのメトリクスと連携しているのでどのインスタンスでもAutoHealオプションを使うことができます。Statusが何かおかしかったらインスタンスを作りなおしてくれるナイス機能です。

24/7

普通のレギュラーなインスタンスで、常時上がりっぱなしのインスタンスです。
通常はこのタイプを一つ用意して、TimeBaseLoadBaseを増やしていく感じでしょう。

ただ、レイヤ内に24/7が1つもない状態で他のタイプがある場合は最低1台になるようにどれかが上がってくるようです。実は不要かもしれませんね。

Time based instance

1時間単位で起動・停止の状態をスケジュールできるインスタンスです。時間はUTCで指定するので、お間違えの無いよう。

設定のUIはこんなかんじです、薄いのは曜日別設定アリ、濃い緑はEverydayのスケジュールです。

time_base01.jpg

設定後、UP指定の時間帯になったらStop状態だったインスタンスが勝手に上がって来ました。

time_base02.jpg

デプロイまで完了したらELBに勝手に参加します、便利やなあ。

LoadBased

CloudWatchとのメトリクス連携真骨頂ですね。
レイヤ内のインスタンスの平均負荷状況に閾値を設定し、指定時間内にその状態だったらインスタンスを起動します。

ルールはこんな感じです。

  • 5分高負荷状態が続いたらインスタンス起動
  • 10分低負荷になったらインスタンス停止
  • 一度に任意の台数を追加・停止可能

LBI01.jpg

負荷をかけてみる

LoadBasedインスタンスを追加した後閾値を40%まで下げて、レイヤ内の1台でCPUベンチをまわしてみました。

丁度yumにsysbenchがあったのでぶっ放します。

sysbench_loop

$ while /bin/true ; do sysbench --num-threads=4 --test=cpu run ; done

sysbench_agent.jpg

インスタンス2つのうち、1つが100%ベッタリになっているのでレイヤの平均負荷も良い具合に50%です。

monitoring01.jpg

では5分ほど待ってみます。

勝手にインスタンスが起動

load03.jpg

おお、レイヤの負荷に控えのインスタンスが駆けつける※様子が見られました!

※インスタンスストアでやると手軽ですが流石に遅いです、EBSにして一回くらい起動しておくとパッケージインストールなどを省けるぶんそこそこ早いかと思います。

平均負荷が軽減

3台目のインスタンスが起動したので、レイヤの平均負荷は狙い通り33%となりました、もちろんELBに参加してくれています。

load04.jpg

終わりに

こういったオートスケールに対応するには、アプリケーション側の対応はもちろん、アプリケーションが動作するプラットフォームを、サーバに一切触らず構築する仕組みへの理解が大事になってきます。

今回試したのはStaticなWebサイトの配信だったので全く考える余地は無かったのですが、起動・デプロイ・後片付け・停止のサイクルをしっかり管理できるようなレシピを作るスキルを磨いていかないといけないですね。

Author Profile

sawanoboly@higanworks
sawanoboly@higanworksについて

HiganWorks LLCの代表、クラウドを利用したインターネットアプリケーションのプラットフォーム構築・運用の自動化をテーマに活動しています。OpsCode承認コントリビュータ等、サービスに関連するオープンソースコミュニティにも参加しています。