今回はAuto ScalingをApexからREST APIで触ってみます。

 

Auto Scalingは指定したインスタンスが落ちたら自動的に指定のインスタンス数になるまで

同じインスタンスを立ててくれたり、指定した時刻にインスタンスを動的に増減させることのできる

自動でスケーリングをしてくれるサービスです。(って名前そのまんまの説明…)

 

これを使うと、

「毎週日曜日は負荷が高いから自動的に処理をするインスタンス数を増やそう!」とか

「万が一インスタンスが落ちてもすぐにインスタンスを立ち上げるようにしよう!」とか

「不健全なインスタンスを落として健全なインスタンスだけ生かしたい!」とか

こういったスケールアウト、スケールインが自由自在にできちゃいます。

 

前回はEC2をREST APIを使って手動で立ち上げていて、

”EC2のREST APIを使ってスケジュール化するためにはApexバッチが必要”と書きましたが、

このAuto Scalingを使えばスケールアウトを自動化できるので

インスタンス数を0→1にスケールアウトするようなスケジューリングをAuto ScalingをCUIとかで

一回設定してあげれば自動インスタンス起動の処理ができちゃいます。

 

Auto Scalingのスケジューリングに関する参考URL↓

http://dev.classmethod.jp/cloud/auto-scaling-schedule/

http://blog.suz-lab.com/2012/04/ec2.html

 

また、Auto Scalingを利用しない単純なEC2インスタンス起動は、立ち上げた後は負荷が高かろうが

インスタンスが落ちようが、別のAPIでチェックしない限りは検知することができないのと

検知しても自動的にスケールさせたり、落ちた時に自動的にインスタンスを立ち上げるという

仕組みを自前で実装しなければなりません。

 

そこで、Auto Scalingの出番ということです!

 

ということで、今回のサンプル!↓

Auto ScalingはSignature Version2Version4の両方が使えるんですが、

Version4を推奨、とリファレンスに書いてあったので素直に4でやってます。

Signature Version4はDynamoDBのときにやっていたので、大枠はその回のコピペです。

 

っていうかやっぱりVersion4は複雑…。

ちゃんと間違っていたらResponseで答えを教えてくれるんで、正解にはたどり着きやすいんですけどねー。

(ちなみにSWFはResponseで答え教えてくれないっていう)

 

メソッドはupdateAutoScalingGroupしか無いですが、

SalesforceからコールするAPIとしてはこれで十分かと思われます。

 

基本的にはconsole GUIやCUIであらかじめ作成・スケジュール設定をした

launch configulationやauto scaling groupに対して

Salesforceはauto scaling groupの更新でインスタンスの増減をコントロールする運用を想定していて、

ワンタイムの設定のためにSalesforceでわざわざAPIを叩くのはあまり意味が無い気がするからです。