[Twitter][サービス][リリース] Twitter解析サービスをherokuでリリースしてみました

"Be on the same list"というTwitterのデータ解析サービスを先週リリースしてみました。
http://be-on-the-same-list.mat-aki.net/

自分の入れられているTwitterのリストを解析して、自分が誰と同じリストに多く入れられているのかを調べてくれるサービスです。
たとえば、私のTwitterアカウント mat_aki で解析すると以下のような感じ。

意外に面白い結果が出ます。こんな風に自分が他の人から捉えられているんだということを知ることができます。

このサービスの面白いと思っているところは、他の人が作り出したデータから自分を分析できるところです。他のTwitterデータ解析サービスは、自分のつぶやきとかからその人の属性をはじき出す系が多いかと思いますが、リストに自分が含まれるのは、基本的に他人が作成したものです。なので他人の入力から自分を解析できるのです。

っと宣伝はこんなところにしておいて、今回heroku上でサービスとしてリリースしてみたので、そのあたりの感想をまとめておきたいと思います。herokuについては、以前のブログを見てください。
http://d.hatena.ne.jp/mat_aki/20100308/1268043759

今回のサービスの環境は、heroku, Ruby on Railsで作成しました。最初は、sinatraで作成していたのですが、NewRelic RPMや他のアドオンとの連動を考えたりすると、Railsの方が相性がよく、あえてsinatraで構築する必要もないかと考え、得意のRailsでやりました。

実装は、3×4時間くらいでした。

Twitterのデータ取得からリストに含まれている人を洗い出す処理 4h
Twitterからデータを取得する処理を複数リクエストに分割する処理 4h
デザインや文言、ナビゲーションなど 4h

だいたいそんな感じでした。

2.についてですが、Twitterからデータを取得する際に複数回リクエストを送信します。ユーザからの１つのリクエストでTwitterに複数回投げるともちろんレスポンスは悪くなります。さらに、herokuの制限で 30s 以上レスポンスを返さないとエラーとなってしまいます。このため、ユーザのリクエスト１つに対して、Twitterにリクエスト１つを投げるという風に処理を分割する必要がありました。しかし、毎回クリックしてもらうのも面倒なのでAjaxにしつつ分割するという工夫を今回は行いました。

このあたりの動きは、実際に試してもらえると嬉しいです。

作成に関しては、まぁまぁの短期間で作成できたのではないかと思います。さすがRailsです。

実装が、9日からスタートし、ぼちぼち続けながら、13日に完成し、14日にTwitter上で宣伝を始めました。それ以降のアクセス解析のグラフはこんな感じ。

宣伝初日がやっぱりページビュー数が多いですね。それ以降は、下降を続けています。誰か止める方法を教えて！！！

そして今回のブログの本題のherokuのパフォーマンスですが、今回のケースでいくとあまりよくなかったなかなと思っています。というのは、herokuは無料版だと、１つのスレッドしか走らせられなかったからです。

今回のTwitter解析部分は、Twitterからデータを取得しなければなりません。そこは、どんな工夫をしようとも走っている間は、１スレッドを占有し続けます。なので、他のレスポンスは待つことになるので無料では、パフォーマンスがいまいち上げられませんでした。あたりまえっちゃ、あたりまえですが。

本当はお金をかけたくなかったのですが、初日にアクセス数に興奮してしまって、herokuのスレッド数を有料ですが追加してみました。3スレッド(無料1+2)位たてるとかなり余裕で回せていた印象です。今回のアクセス数であれば、2(無料+1)がちょうど良いかなぁという感じですかね。現在は普通に無料で持っていますが、今後おお流行りしたらなにか対策は考えないといけないですね。

そんな雰囲気を感じていただけるグラフがこれでしょうか？前回のブログで紹介した New Relic RPM という heroku のアドオンとして装備されているパフォーマンスモニタリングサービスのグラフをはっておきます。左のグラフが平均レスポンスタイムのグラフです。緑の領域が１スレッドのための待ち時間です。３スレッドにするとおそらくこの部分を減らせるはずでした。青い部分がTwitterにアクセスしている時間です。やっぱりここには、常に時間がかかっている感じですね。最近は、DBのパフォーマンスチューニングしていないので、件数が大きくなってDBのパフォーマンスが落ちつつあります。

右上のApdexというのがパフォーマンスのスコアです。0.8以上が好ましいのですが、余裕の0.3です。Twitterにリクエストしているアクセスは、どうしても遅くなってしまうためこんなスコアになってしまいました。しかし、Twitterにリクエストするものを除くとこんな感じ(下のグラフ)です。まぁまぁの結果ですね。ほとんど無料で動かしているので、十分な結果かもしれません。

っと、今回Twitter解析ツールにherokuのプラットホームで挑んだ感想はこんな感じです。参考になりましたでしょうか？
ただし、お金をかければ、３スレッドにしても $30/月なのでまぁ、そんなにたいしたことないっちゃないのかもしれません。でも、このサービスで $30/月稼げるかというと？なので、どうでしょうか。

まとめ

heroku+Rails+RDBは、やっぱり開発速度は早い。僕自身が慣れているのもあるけど。
herokuのパフォーマンスは、今回の他のサービスのAPIを多く叩くようなサービスは、あまりよくならない。無料では。

なので、Twitter関連サービスを作るときは、heroku+Rails+RDBで手早く作って、とりあえずリリース。本当に流行ったら、GoogleAppEngine+jRuby+KVSに再実装して、安価にパフォーマンスを出すのが良い方法かなっと感じています。

次回は、ソースコードの解説 or Twitter マーケティングをやってみたでブログを書いてみようかなっと思っています。
今回の内容や、次こっちがいいなどご意見がありましたら http://twitter.com/mat_aki まで。