この記事は最終更新から1年以上経過しています。 気をつけてね。
AWS OpsWorksを使ってオートスケールを組み立てようと思い、用意されているスケール対応インスタンスタイプを調べてみました。
ちなみにOpsWorksはCloudWatchのメトリクスと連携しているのでどのインスタンスでもAutoHealオプションを使うことができます。Statusが何かおかしかったらインスタンスを作りなおしてくれるナイス機能です。
24/7
普通のレギュラーなインスタンスで、常時上がりっぱなしのインスタンスです。
通常はこのタイプを一つ用意して、TimeBase， LoadBaseを増やしていく感じでしょう。
ただ、レイヤ内に24/7が１つもない状態で他のタイプがある場合は最低1台になるようにどれかが上がってくるようです。実は不要かもしれませんね。
Time based instance
１時間単位で起動・停止の状態をスケジュールできるインスタンスです。時間はUTCで指定するので、お間違えの無いよう。
設定のUIはこんなかんじです、薄いのは曜日別設定アリ、濃い緑はEverydayのスケジュールです。
設定後、UP指定の時間帯になったらStop状態だったインスタンスが勝手に上がって来ました。
デプロイまで完了したらELBに勝手に参加します、便利やなあ。
LoadBased
CloudWatchとのメトリクス連携真骨頂ですね。
レイヤ内のインスタンスの平均負荷状況に閾値を設定し、指定時間内にその状態だったらインスタンスを起動します。
ルールはこんな感じです。
- ５分高負荷状態が続いたらインスタンス起動
- 10分低負荷になったらインスタンス停止
- 一度に任意の台数を追加・停止可能
負荷をかけてみる
LoadBasedインスタンスを追加した後閾値を40%まで下げて、レイヤ内の1台でCPUベンチをまわしてみました。
丁度yumにsysbenchがあったのでぶっ放します。
$ while /bin/true ; do sysbench --num-threads=4 --test=cpu run ; done
インスタンス2つのうち、1つが100％ベッタリになっているのでレイヤの平均負荷も良い具合に50％です。
では5分ほど待ってみます。
勝手にインスタンスが起動
おお、レイヤの負荷に控えのインスタンスが駆けつける※様子が見られました！
※インスタンスストアでやると手軽ですが流石に遅いです、EBSにして一回くらい起動しておくとパッケージインストールなどを省けるぶんそこそこ早いかと思います。
平均負荷が軽減
3台目のインスタンスが起動したので、レイヤの平均負荷は狙い通り33％となりました、もちろんELBに参加してくれています。
終わりに
こういったオートスケールに対応するには、アプリケーション側の対応はもちろん、アプリケーションが動作するプラットフォームを、サーバに一切触らず構築する仕組みへの理解が大事になってきます。
今回試したのはStaticなWebサイトの配信だったので全く考える余地は無かったのですが、起動・デプロイ・後片付け・停止のサイクルをしっかり管理できるようなレシピを作るスキルを磨いていかないといけないですね。