2011年8月31日水曜日

SQS & CloudWatch & Auto Scaling、その後

スズキです。

下記のように"SQS"と"Auto Scaling"を使って、
"SQS"と"CloudWatch"と"Auto Scaling"
複数インスタンスでクロールする仕組みを運用しています。

はじめ、下記のように"CloudWatch"のカスタムメトリクスを使って、
SQSのキューのサイズ(メッセージ数)と"Auto Scaling"の連携をとっていたのですが、
SQSのキューのサイズをCloudWatchに登録
下記のように、SQSのメトリクス自体が標準でサポートされるようになりました。
CloudWatchでSQSのメトリクスが取得可能に
ですので、現在は"Auto Scaling"のトリガーとなるメトリクスはカスタムメトリクスではなく、
標準のSQSのメトリクス(ApproximateNumberOfMessagesVisible)を利用するように
変更しました。

ということで現状、下記のような仕組みで処理しています。
  1. SQSにクロールしたい対象ID一つを一つのメッセージとして一気に登録する。
  2. SQSのメッセージ数が0以上になると指定した数だけインスタンスが起動しキューの
    メッセージを処理(該当IDでクロール)する。
  3. SQSのメッセージ数が0になったらすべてのインスタンスがターミネートする。

また下記のようにSQSのメトリクスを監視し通知を受けることで、
クロール処理の状況をリアルタイムに把握できるようにもしています。

ApproximateNumberOfMessagesVisible

値が0以上になったらクロール処理開始、0にもどったらクロール処理終了として
通知するようにしています。

NumberOfMessageReceived

値が0以上になったらクロール処理開始、0にもどったらクロール処理が停止(正常 or 異常)
として通知するようにしています。詳細は下記となります。
SQSのキューのメッセージが処理されなくなったら通知(CloudWatch)

ここまででもAWSの機能をふんだんに利用した、定時でのバッチ処理システムですが、
さらにやりたいことがあります。

現在SQSへのメッセージ登録は、常時起動しているEC2から"cron"にて行っているのですが、
下記で紹介したように"Auto Scaling"を利用すれば、指定した時刻にインスタンスを
立ち上げることができるので、
"Auto Scaling"で指定時刻にEC2インスタンスを起動
起動時と同時にSQSにメッセージを登録して、登録し終わったらインスタンスが
ターミネートするようにできるのでは、と思っています。

これができると、定時のバッチ処理が常時起動しているサーバ無しに、サーバが遊ぶこと無く
実施することができるはずです。サーバの稼動時間がかなり限定される形になるので、
コストも大幅に下げることができると思います。

ということで上記が実現できたら、また、このブログで紹介します。乞うご期待!
--------
http://www.suz-lab.com

0 コメント: