Contenu connexe
Plus de Ryuichi Tokugami (20)
Dernier
Industrial Policy - 1948, 1956, 1973, 1977, 1980, 1991Industrial Policy - 1948, 1956, 1973, 1977, 1980, 1991RKavithamani
SQS で疎クラスタ (2010-07-07 JAWS-UG 東京 第3回勉強会)
- 2. •
twitter: tottokug
•
•
Notes de l'éditeur
-
- 株式会社マイニングブラウニーの得上と申します。
ツイッター tottokug フォロワー増えると嬉しいので、
あとでフォローしておいてもらえると喜びます。
クローラを作ってマーケティングに活用するお仕事をしています。
それでは、、、、
- えっ?
なぜSQSでクラスタを??と思われるかも知れません。
- AWSにはもっと適した子がいるんです。
- CloudWatchとAutoScaling
なんだかやたら遠くを見ていますね。
彼なら、インスタンスの負荷も見てくれるし、負荷に応じてうまい具合にインスタンスも立ち上げてくれるし、彼じゃダメなのか?
彼じゃダメなんです。彼の得意な分野は、時間あたりに、この程度の処理はしてもらわないと困るよ。
と言ったときに活躍します。
例えば、外から大量のアクセスが有って、その負荷に耐えられるような仕組みを作らなきゃいけないもの。
もしかしたらAWSでもこうゆう使い方を想定されているのではないかなぁと思うのですが、
具体的に言うと
- Webサービス
ELB使って、その配下にいっぱいWebサーバが立ち上がっているような状況、
アクセスが増えたときにはサーバを増やして、アクセスをさばかなくてはイケない。
このように、時間に対する処理の量が決まっていて、それをさばくために、インスタンスを増やすようなサービスにはもってこいです。
CloudWatchとAutoScalingでは出来ないことがあります。
それはGracefulStopです。AutoScalingの対象としているものが、ELB配下にあるWebサーバであれば、
インスタンスを停止させても、ELBが別のサーバに振ってくれたりと、うまいことやってくれます。
ちょっとここで話をSQSに戻しましょう。
- SQSはどんな使い方をするときに使えるのか?
- EC2は基本的に酷使します。loadavalageも下げる気はありません。
例えば、うちの会社ではクローリングとデータの解析をしているわけですが、
クローリングして解析すると、再帰的にクローリングとデータの解析という仕事が生まれてくるんです。
自分自身が仕事をまた増やしてしまうといった具合に。
自分が処理できる量と、増えていく量が一緒であればよいのですが、それはどこをクローリングしているかによっても
予測つかないですし、また、レスポンスの速度にも大きく影響されてしまいます。
とりあえず、EC2は酷使します。負荷が増えたからインスタンスを増やすというようなことはしません。
loadavalageの小数部分なんて気にしません。負荷は常にかかってます。
それが何台あろうとも、負荷は常に掛かっているんです。
- 上限が定められるという話を無視すると、
インスタンスは天井知らずに増えていきます。それもあっという間に。
もしかしたらGoogleより早く、世界中の情報を整理出来てしまうかもしれません。
じゃあ、やったらいいじゃないか。と思いますが、大事な事が残っています。
1か月以内にある事に気づくはずです。
- ここにいる人なら、多分わかってくれると信じています。
さてそろそろ本題入ります。
- 具体的にはどう使っているのかというと、
これ実際にうちの会社で開発したクローリングとデータマイニングを組み合わせたマーケティングツールのアーキテクチャの一部抜粋です、、　
ハチのマークの付いているところ。ここがEC２です。ここは基本的に馬車馬のように働いてくれています。
ただ、クローリングの特性上、お仕事をすることで、またお仕事が増えていきます。
その増える量はまちまちで、あるページは次の仕事がたくさん増えて、それが続けば、キューがどんどんたまっていきますし、
あまり増えないようなページのクローリングが続くと、キューはどんどん減っていきます。
EC2のプログラムで具体的に言うと、このハチさんマークのところで、数分に一回SQSのキューの数を確認します。
キューの数が数十％とかそういった位の割合で増えているようであれば新しいインスタンスを立ち上げます。
逆に減っているようであれば、インスタンスを停止します。
この時問題となるのが、キューの数の確認をするタイミングが複数のインスタンスで同じようなタイミングで観てしまった時です。
100台のインスタンスが同時にキューをチェックして新しいインスタンスを立ち上げようとすると、、、、、100台のインスタンスが立ち上がってしまいます。
なので、ここでもSQSを使います。インスタンスを立ち上げたい、もしくは停止したいというキューを入れておきます。
まず、このキューを見て、立ち上がる予定がないようであれば、立ち上げる為のキューを入れます。
キューがあるのであれば、インスタンスを立ち上げます。インスタンスは立ち上がると、立ち上げる為のキューをひとつ削除します。
これでなんとなくいい感じにスケール出来ます。
けっこうゆったりとしたスケーリングではあるのですが、WEBサービスのように、すぐにでも負荷分散しないとサービスが止まってしまうとか
そういったたぐいではなく、スケーリングしたほうが早くさばけるよね、といったスケーリングの仕方になります。
逆にインスタンスを減らすというのもなかなかのクセモノで、キューが減っていていてもインスタンスはお仕事中であることがあたりまえなんですね。そこで大事な実装があります。
- グレースフルストップ。
実はうちの会社でCloudWatchとAutoScalingを使わなかった一番の理由は実はこれです。
処理の途中で終わらせるわけにはいかないので、自分で仕事のキューを見ます。
減っていれば、さぁ今やってるのを終わらせて、今日は飲みに行くかって具合に落ちます。
その時に、これ終わったら停止します！っていうキューを入れておきます。
他の人はこのキューがあれば、停止しません。まだまだ働かされます。
停止する人は仕事が終わったら、自分でいれたキューかどうかはわかりませんが、キューを削除して、
停止します。これで無事にGracefulStopができました。
これじゃ、即時にインスタンスの停止がされないじゃないかという疑問が湧いてくるかも知れませんが、
AWSは1時間単位の課金なので、すぐに落とすメリットは有りません。確率的な問題になってしまうのですが、
すぐに落とさないことで、もったいないことになるのは、インスタンス1台分の値段なので、そこまで細かく
気にしません。
- まとめると、
CloudWatch&AutoScalingは一人じゃ対応できないから、みんな手伝ってよー。
SQSは一人でやってもいいけど遅いよ?早くしたいなら手伝ってよー。
といった感じ使い分けると、SQSでキューの数をキーにしてスケールさせる意味が出てきます。
WEBサービス以外でEC2を使う場合検討してみて下さい。
以上
