かれ4

かれこれ4個目のブログ

第三回 AWS user group japan 勉強会で発表したことの続き

七夕の日にもかかわらず、天の川を隠すようなクラウドの話をしてきました。

話した内容はSQSについてだったのですが、
他のゲストトークや、ライトニングトークの方たちがAutoScalingを使っていたので、
若干やりづらいところもありましたが、気にしません。

また、ディスプレイの設定でも助けていただきました。
ありがとうございました。

今回始めてのライトニングトークで、勝手もわからず、
とりあえずググって出てきた、決められた時間内にサクっとしゃべる
それがライトニングトークの醍醐味だというのを微塵も疑わず、
飛ばして飛ばして、5分ちょうどにしたわけですが、
ちょっと省略しすぎてしまって、分かりづらかったかも知れませんので、
ここで補足というかフルバージョンを書いていきます。

ちなみに好きなAWSはSQSです。


実際話したい事の7割くらいを削ってしまったので、
ここで補足させていただきます。

SQSで疎クラスタを実施する方法についてお話します。

AutoScalingがダメって言うわけではなく、AutoScalingでスケーリング出来ないようなアーキテクチャでも、SQSでスケーリング出来ますよっていう話です。


自己紹介
このライトニングトークで話をさせてもらっているのも、twitterでステッカーをおねだりした事から始まりました。
ステッカー欲しい & AWS Start-up Challenge出たい!!というつぶやきから
ここまでたどり着くことが出来ました。
ホントはここで開場の皆様にも、ステッカーをおねだりするつもり満々でした。
今も募集中ですので、皆様のステッカーを私に下さい!
gumiさんステッカーないかなぁ、
 と言ってみたり。
時間も押しているので、雑談はこの辺に、、、

なぜSQSでクラスタをつくろうと思ったの?



HPCクラスタ組むなら、もっと適した子がAWSにはいたはず。。


CloudWatch&AutoScalingがいます。
それでも彼を使わず、SQSを使う理由があるんです。
おそらくAWSで推定されている使い方は 時間という軸は変えず、
ある時間内に次々やってくる処理を即時に処理する
そういった案件に対するスケールアウトを想定しているのではないかなと思います。
具体的に言うと



Webサービスを想定したスケーリングの仕組みじゃないかと思ってます。
EC2をwebサーバとして使い、ELBとAutoScalingでスケールアウトさせて、
データベースはRDS使ってね(キリ。

片側の口角をあげ、ニヤッとしているAmazonさんの顔が目に浮かんできます。


では、SQSでスケールアウトさせるのはどんな時に使うんだろ?
てかEC2でwebサービス以外あまり考えてなかったし、、、、
ファイルサーバ スケールアウトしても、、、
データベースはRDSもSDBもあるし、、、
EMRもあるし、、、
うちではクローラをつくっていて、その仕組をほぼ全てがAWSの組み合わせです。
実行環境をEC2で構築しています
私も色々なAWSを検討しましたが、結局SQSでしか実現できない理由が二つありました。


まずその理由の一つ。
EC2を酷使します。ロードアベレージは小数点以下は気になりません。
クローラという特性上、常にイッパイイッパイの負荷がかかり続けています。
いっぱいいっぱいの負荷をかけ続けないと勿体無いんです。
その為、AutoScalingでやってしまうととんでもないことになります。



このグラフ、スケールはあえて書いていないのですが、
時間が経つにつれて、どんどんEC2のインスタンスが増えていきます。
上限なしというめちゃくちゃな想定ですが、、、
もしかしたらあっという間に持っている情報の量がgoogleを超えてしまうかもしれません。
それなら、やったらいいじゃないかとも思うのですが、


Amazon Web Services Billing Statement Available」
一か月以内にメールで死の宣告をうけます。
まだまだ資金力に乏しくて、EC2を利用しているというのに、
このメールを受け取った瞬間から、資金繰に奔走しなくてはいけなります。


実際にどのように、使っているかというと
このへん企業秘密なので、あまり詳しくはお話できないんですが、
クローリングをしてHTMLの解析をして、
リンク先についてはまた、、、といった具合に再帰的に仕事が増えていきます。
ただ、ねずみ算式に増えていくわけでもなく、終わりもあります。
この一つのページを取得して、解析するというお仕事を
全てSQSを使って、こなしていくようにしています。
数分間おきにSQSに見ていれば、今仕事が増え続けていっているのか
それとも、減っていっているのかというのを見ることが出来ます。
キューの数だけで判断します。
CPUの使用率はいつも100%なので、あてになりません。
キューが増えているなら、インスタンスを立ち上げ、
減っているのであれば、インスタンスを落とします。

いまさらっとインスタンスを落としますと言ってしまったのですが、
実はAutoScalingを使わずにSQSを使った本当の理由は
インスタンスを落とすところがAutoScalingが使えなかったからなんです。
次今日の山場です。


Graceful Stop
もうこれです。
今日はGracefulStopならSQSだしょという事だけもって帰ってくれればOKです。
AutoScalingでは出来ず、SQSならできる。
実際どうやっているのかと言うと、
まず、お仕事が入っているSQS(以降:お仕事SQS)をそれぞれのインスタンスは見張っています。
ある一定の時間内にキューが増えているのか、減っているのか、
もし減っていたら、インスタンスを落としたいんです。
このインスタンスを落とすタイミングが難しいんです。
常にCPU100%なインスタンスばかりなので、急に落としてしまっては大変です。
なので、キューが減っているのを検知したら、「自分落ちます」
というのをまた別のSQS(以降:落ちるぜSQS)に対してキューを入れます。
この時もし、落ちるぜSQSにすでにキューが入っているのであれば、
他のインスタンスが落ちようとしているので、落ちようとはしません。

で、その自分落ちますと言ったインスタンス
お仕事SQSからお仕事を取ってくることを辞め、徐々にCPU使用率を落としていきます。
完全にお仕事のプロセス(スレッド)がなくなってから
自分自身でシャットダウンします。
こうすることでGracefulStopが実現できました。
負荷が減ってきてすぐに落とさないのは、
もしこの間にまた増え始めたら、生き続けるという道を選ぶこともできますし、
すぐに落としてもEC2は1時間単位での課金なので、数分のタイムラグはそんな
コストアップになるとは考えていません。


というワケで今日のまとめは
GracefulStop がしたいなら、SQSを使ったら実現できますよ!
ということでした。


この内容を5分で話そうと思っていた自分が恥ずかしい。
かなり省略してしまったので、きっと意味がわからなくて、申し訳ないと思い
ここでまとめさせていただきました。

そういえば、会社名を一切言わないという
謎の人になりかけてしまっていました。
次回勉強会でLTやることになったら、今度は自己紹介に会社の紹介も入れようと思います。