https://github.com/ruby-no-kai/rubykaigi/wiki/VideoSubtitleJobs

16m03ja03.txt

で、最後に、このへんの右の方の、ログの統計情報をどういう風に扱っているのかって
いう話なんですけど…。

今までアプリケーションサーバーが、ユーザさんがアクセスしてきたログが、生ログと
して一時的にIDCの方のデータセンターの方にログとして書き出すんですけど、今は、
hourly、一時間に一回、AmazonのS3のストレージの方にログ情報をけっこうコンパクト
にまとめてあげています。

で、このログの解析なんですけど、「たべみる」ってさっき言っていた、ログを利用し
て運営しているWebサービスの方はEC2とHadoopを利用して、ログ情報からガツッとデー
タを作ったりしています。

で、最近はその他の「たべみる」以外のログの処理なんですけど。それはEMR…Elastic
MapReduce。Amazon Web Serviceの機能のうちのひとつで、Amazon Web ServiceのS3上の
データを、こう…ガツンと取ってきて、MapReduceに回すという事ができるので、最近は、
なにかちょっと手元で、手元のマシンだと遅すぎるんだけど…みたいな感じの統計情報
の処理っていうのは、EMRでインスタンスをバーッと立ち上げて一気におこなって取得な
どを行っています。

で、MapReduceのMapperとReducerなんですけど、普通は他の言語…よく言われるのは、
なんか、Rubyが遅いから他の言語で書いたよー…って事は言われるんですけど、社内の
エンジニアの第一共用語がRubyなので、やっぱり速度よりもRubyで処理できるってこと
を第一に優先して、MapperとReducerはRubyで書いています。

で、実際はそのEMRでインスタンスをたくさん立ち上げれば、横に並列化されて、速度の
処理というのは行えるので、一応、Rubyでは今のところ困ってないで運用を行っています。

はい。

ではちょっと一息ついて、ちょっと速度、スピードについて考えてみましょうか。

えっと、よく一般的に言われる事で、RubyとかRailsは遅いよねー？とかって言われるん
だけど。

皆さん。遅いって思う人、手を挙げてください。
　
お？あんまり…あんまりいない。１割…１割ぐらいが遅いと感じてるようですね。

で、実際に遅いのか？って言われると、なんかそうじゃないなぁって僕は思っていて、
まあ、特にWebサービスを運営する上では、RubyとかRailsがネックになって重くなるっ
て事は、ほとんどないと思ってます。

現にCOOKPADだと、アプリケーションサーバーの表示速度を全部200ms以下で返すという
事を、目標というか、実際において今200ms以下平均レスポンスを保ってサービスを運営
しています。

で、これらって一体なにかスーパーテクニックを使ってやっているのか？…っていうと、
そんなことはなくって、やっぱりその、Webの基本技術である定石の部分を、きちんとき
ちんと、一個一個ちゃんとこなしていく事によって、けっこう速度を維持できているの
で…。

なにかスゴいテクニックで、なんかパンっ！って速くなるって言うよりかは、普通に言
われている、こうなったら速くなるよね？っていうのを、一個一個キチンと積み重ねる
事によって、この速度ができるという感じで、いまCOOKPADでは運営しています。

でまあ、それだけ言ってもアレなんで。

COOKPADの中で、どういう事を開発時に速度を低下させないために心がけているかってい
うと、一個はCOOKPADの中でやってる「GOODはやらない。BESTのみに集中」という事をやっ
ています。

これ、けっこう、選択と集中なんですけど、なんとなくこの機能いいかもしれないね？
…みたいなので、機能をどんどん追加していくと、なんか、SQLとかデータが、どんどん
どんどん増えだして、重くなったりとかしたりするので、なんとなーく…でやるって事
はやらなくて、もうホントにBESTな機能だけを出していくって事でシンプルさを保って
います。

で、このシンプルさを保つって言うのは、けっこうWebアプリケーションの速度を考える
上ではすごい大切になってきて。

シンプルさを保つと、ホントにさっき言っていたような、本当に必要な機能のみを絞っ
てリリースを行って、技術的に何とかできるんだけど…とかっていう機能って、けっこ
う意外と複雑になりすぎて、重くなっちゃうけど、出すんだけど、ユーザさんにはやっ
ぱり重くて使われない…みたいな事になってしまうので、やっぱりそこのシンプルさっ
て事を考えて作ったりしています。

で、シンプルになると、さっき言っていたように、キャッシュにのりやすくなっていた
りとか、あとはクエリー自体もどんどん変なクエリーとか…JOINとかバンバン使うよう
なクエリーがあんまり増えずに、シンプルなクエリーだけを乗せる事ができるので、けっ
こうアーキテクチャー的にも本当にシンプルで運用しやすいもの、というものを保つ事
ができます。

で、もう一個行ってる主な事として、あとでやる…非同期ロードというのを、COOKPADで
はメインの技術として取り入れています。

で、これは、COOKPADの検索ページ、ログインユーザが検索したページなんですけど、こ
のうち…ここの部分。ホントはもっといろんな場所も非同期でレンダリングしてるんで
すけど、この辺が非同期でレンダリングしています。

で、ユーザ毎に、けっこう出し分ける情報ってのは非常にあるんですけど、あとで出し
分ければいいような情報は、初段ロード時には出し分ける機能をあえて全部引っぱって
きて…って事は、やりません。

で、そのため検索サーバとかで、さっき言ってたVernishのキャッシュとかにのってるん
で、ページの最初の、HTMLをGETする部分の速度については、30msぐらいで受け取ること
ができてて、その他のユーザ情報がパッと表示される部分は、あとからほんのちょっと
時間かかるんですけど、２段階のロードを行っています。

それらの事をやることで、ユーザさん的にはページは一瞬で表示されるし、200msってほ
とんど気づかない程度の、その、非同期のレンダリングになるので、ユーザさんはほぼ
気づかないまま、高速なレスポンスというのを受け取ることが可能になっています。

そんな感じで、Railsっていうのはシンプルにキチンと考えて運用していくと、Rubyが遅
い、Railsが遅いという事で、Webのアーキテクチャーが遅くなるって事はないかなぁ、
と、思っています。

で、これらのより詳しい所については、「ウェブオペレーション」っていう、弊社の濱
崎というのが、「日本の料理のインフラ」という事で、インフラ寄りの細かい事を書い
てるので、外のジュンク堂で売ってるので、ぜひ皆さん、興味があったらご購入くださ
い。