はじめに
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容量でのスケーリングをしています。
利点
利点として、一番大きいのは、細かい単位でのスケーリングができるので、うまくしきい値、トリガーを調整することで、
コスト効率を最大化することが出来る。
また、スケーリングの設定が複数あるので、必ずしも全てのスケーリングの設定が恒久的なものでなくても良い。例えば、スケーリングの設定のうち一部を入札性のサーバを利用することによって、更にコスト効率をあげることが出来る。
注意点
複数のスケーリングの設定をするため、それらが同一のクラスタであり、最低限の台数を確保するために調整が必要である。
もしロードバランサーを使用するのであれば、全てを同一のロードバランサーにぶら下げるなどし、サーバ群全体のサーバ数を管理出来るようにするのが望ましい。
ある一定の規模になってくれば、この注意点は気にしなくても良い。
最後に
この構造は頭の中でなんとなく、
ラザフォードの原子模型のようにひとつの原子核に対して電子が周りを回っているイメージと
SWF,SQS,ELBの周りをEC2が複数のリングによって回っているイメージが重なったので、
このデザインパターンには
Rutherford Scaling Patternと付けたいと思います。
このCDPのイメージ
Shadeのデータも公開します。
Download