CDP AdventCalendar 2013 - Rutherford Scaling Pattern

はじめに

CDP Advent Calendar 2013 の15日目です。
昨日はなぜか二人いたようで
@ijin さんの
Autoscalingによる自動復旧(Immutable Infrastucture)
http://ijin.github.io/blog/2013/12/14/self-healing-with-non-elb-autoscaling2/

Takuro Sasakiさんの
AutoScalingやインスタンス障害に強い　〜Stateless Serverパターン〜
http://d.hatena.ne.jp/dkfj/20131214/1387023080

の二本立てでお送りいたしました。

AutoScalingが続いているので、今日もAutoScalingでいきます。

解決したい課題

サーバをスケーリングさせるときにはいつも決まった大きさのサーバが立ち上がってしまうのが通常である。最も小さいサイズのサーバを立ち上げることで、細かいスケールアウトが出来なくは無いが、急激な負荷の上昇などの対応には遅れてしまう。
急激な負荷にも対応しつつ、細かい負荷の上昇にもコスト効率よくスケーリングしていきたい。

クラウドでの解決/パターンの説明

実装するにあたって、一つのサーバ群に対して複数のスケーリングの設定をすることで解決する。
しかし、同じ設定をしてしまうと、大きなサーバ、小さなサーバが同時に立ち上がり、同時に落ちてしまうので、コスト効率は悪くなる。
そのため、トリガーとなる値のthresholdやperiodやトリガーとなるものを変更しながら、複数のスケーリングの設定をする。

例えば、CPU使用率でのスケーリング、IOでのスケーリング、CPU使用率でも、60％でのスケーリング、80％のスケーリングなど。

構造

一つのアプリケーションに対して複数のAutoScalingがいます。
Webアプリケーションであれば、一つのELBに対して複数のAutoScaling、
非同期なアプリケーションでアレば、SQSやSWFのWorkerが複数のAutoScalingによって立ち上がるようになります。

えっ? ElasticSearchってAWSのサービスじゃなかったんですか！？|アドカレ2013 : CFn #10で紹介されているCloudFormationはこのパターンとCustomize Scaling Metrics Patternを組み合わせて使用しています。
一つのELBに対して、CPUでのスケーリングと、Disk容量でのスケーリングをしています。

利点

利点として、一番大きいのは、細かい単位でのスケーリングができるので、うまくしきい値、トリガーを調整することで、
コスト効率を最大化することが出来る。
また、スケーリングの設定が複数あるので、必ずしも全てのスケーリングの設定が恒久的なものでなくても良い。例えば、スケーリングの設定のうち一部を入札性のサーバを利用することによって、更にコスト効率をあげることが出来る。

注意点

複数のスケーリングの設定をするため、それらが同一のクラスタであり、最低限の台数を確保するために調整が必要である。
もしロードバランサーを使用するのであれば、全てを同一のロードバランサーにぶら下げるなどし、サーバ群全体のサーバ数を管理出来るようにするのが望ましい。
ある一定の規模になってくれば、この注意点は気にしなくても良い。