Webデベロッパの祭典＠秋葉原【B-2】国内最大規模のRuby on Railsサイト「クックパッド」の裏側見せます。
2009.05.13 全内容反映完了
Webデベロッパの祭典＠秋葉原
http://www.pasonatech.co.jp/10th/event/dev_fest/tokyo.jsp
B-2セッション
http://www.pasonatech.co.jp/event/index.jsp?no=1159
クックパッドCTO
橋本 健太氏
http://www.web-career.com/contents/buyuden/34.html
○クックパッドとは？
・クックパッドのミッション
「毎日の料理を楽しくすることで、心からの笑顔を増やす」
これだけのためにやっている。
1998年 open
・想い
「世界で一番生活の役に立つウェブサイト」
使い方
1)おいしいものができたとき
レシピを載せる
２）おいしいものを食べたいとき
レシピを探す
現在47万点以上のレシピがある
３）レシピをみて作った料理の写真をとってのせられる
作りましたフォトレポート「つくれぽ」
例：
http://cookpad.com/recipe/438908
・クックパッドの規模
月間ユーザ数 547万人
#四国の人口が約400万人なのでそれを越えている
Railsサイトでは世界７位
http://rails100.pbworks.com/Alexa+Rankings
月間2.8億PV（世界３位）
リピーターが多い
1日のうちでも何回もみる
レシピ47万点
#日々増加中・・・
生活に密着しているのでトラフィックが特徴的
一日のうち16〜18時がピーク
年間では秋からバレンタインにかけてピーク
バレンタイン時期は通常の倍に達する
547万人を支える技術
メモがおっつかなかったので以下のエントリを参考にして補完した
http://www.sssg.org/blogs/naoya/archives/1126
http://d.hatena.ne.jp/h-nakao/20090201/1233458486
構成
- ロードバランサ
- Apache サーバ8台
- APサーバ
- 52台
- DBサーバ(スレーブDB)
- 18台
詳細
Apache 2.2.3
プロキシバランサ
http://www.asahi-net.or.jp/~aa4t-nngk/apache3.html
Ruby on Rails 2.0
Mongrel 1.1.5
mongrel_cluster 1.0.5
http://rubyist.g.hatena.ne.jp/muscovyduck/20070402/p1
MySQL5.0.45
一部は未来検索ブラジルの全文検索Tritonを使用
#未来検索ブラジル http://razil.jp/
運用
- デプロイ
Capistrano
http://www.capify.org/
#2009.02.25 Capistranoの開発終了アナウンスあり
#http://weblog.jamisbuck.org/2009/2/25/net-ssh-capistrano-and-saying-goodbye
#今は何使ってるんだろう
- god
http://rails.takeda-soft.jp/blog/show/213
Mogrelの再起動
メモリがやたらたまりやすいため
- 監視
- モニタリング
パフォーマンス
バレンタインで普段の倍トラフィックがあがる
まさに今(2009.02.07、バレンタインデーの約1週間前)
- キャッシュ
- クエリチューニング
- DB調査
Mongrel・・・無駄が出てしまう
1) キャッシュ・・・3種類
ページキャッシュ
NFS
APサーバ見ないでApacheから直接返す
キャッシュできないページ
フラグメントキャッシュ
memcached
http://www.danga.com/memcached/
キャッシュできないもの
- ユーザ毎の表示
ex.ユーザ名表示欄等 - アクセスログ
- 広告
ものによってはランダム
→これらはAjaxでとってきてる
バラバラにやるとすごく重い
一回のリクエストでこの3種類を解決する
2) クエリチューニング
FiveRuns TuneUp
http://www.fiveruns.com/products/tuneup
http://jp.techcrunch.com/archives/20080529dont-debug-alone-with-fiveruns-tuneup/
開発モード
事項されたクエリ、レンダリングの結果をリアルタイム表示
インデックスの使われ方とか
スロークエリログ
throw query log
DBメモリ
リニューアル直後にサーバパフォーマンスを出せず、リソース調査を行った
VM内メモリ構成
Apache 2GB
AP 2GB
スレーブDB 8GB
検索DB 4GB
→検索DBをスレーブDBに統合
Apache 2GB
AP 2GB
スレーブDB 12GB
に変更
原因：メモリにのっかるデータの量が8GBを越えていた
これがのりきらなくなったらスレーブを16GBにする
さらに越えたらDBを分割する
OSのキャッシュにデータが全部のりきるかを常に考える
開発基盤
ノウハウを共有しやすいため
- emacsを使う
同上
rails.elを使う
http://tam.qmix.org/wiki/EmacsRailsMode.html
- バージョン管理ツール
Subversion
http://subversion.tigris.org/
Trac
- コードレビューシステム
Shinji-ko（宍道湖）
http://code.google.com/p/shinjiko/
Mondrianのクローン
DBのレプレケーション
Ruby onRails・・・そのままだとDB:DBサーバが1:1
1個しかのっけらんない
解決のためのプラグイン
Acts As Readonlyable
http://railsify.com/plugins/33-acts-as-readonlyable
レシピの全文検索
Tritton(未来検索ブラジル)
→MySQLの拡張
テーブルをJOINしやすい
MySQLの欠点・・・1回にひとつしかクエリにインデックスを使えない
→Trittonだと2つ使えるようになる
MySQL・・・全文検索インデックス
稼動中サーバに対してかけると大変なことになる
他のサーバでインデックスはってからコピったらちゃんと動く
ユーザ専用URLの解決の仕方
一部のユーザ・・・自分用のURIをもてる
→Ruby on Railsで実装するのはちょっとやっかい
routes.rb
http://railspress.matake.jp/rails20%E3%81%AErouting%EF%BC%88configroutesrb%EF%BC%89%E3%81%AE%E8%A8%98%E8%BF%B0%E6%96%B9%E5%BC%8F%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E3%81%BE%E3%81%A8%E3%82%81%E3%80%82
コントローラファイル名を検索していって、ヒットしなかったらユーザURIとみなす
Rails立ち上げて一回だけ探しにいくのでサーバの負荷もかからない
全ページプレビュー機能
x月x日x時〜x時の限定公開、といったようなコンテンツがある場合
その時間にほんとうに出すことができるかどうかをテスト
全てのページにおいて、任意の日付として表示できる
→Rubyだから簡単にできた
Time.nowを上書きして実装
http://www.ruby-lang.org/ja/man/html/Time.html#Time.2enow
※もちろんアクセス制限あり
クックパッドのものづくり
４つのきまり
１）つくるものを決める
２）計画する
３）製造する
４）質を高める
→方法論を決めて実行する
１）つくるものを決める
[1] ベストなことに集中する
ベターなこと、やったほうがいいことはやらない
ではどうやって「ベスト」をみつけるか？
「三つの輪」がすべて重なるもののみを実行する
(1) やりたいこと
情熱をもって取り組めること
(2) できること
自分たちが世界一になれるか
(3) やるべきこと
事業として儲けを出せること
これら３つすべてを満たすこと。
１つないし２つだけの場合は「ベスト」ではないのでやらない。
[2] ユーザの欲求に基づいたゴール設定
「EOGS」（Emotion Oriented Goal Setting）に基づき、ワークシートを穴埋めしていく
(1) キャスト（登場人物）をたて、それぞれの疑いなき欲求（Emotion）をみつける
(2) これをやればすべてかなえられるというものをみつける
(3) 何をすれば実現できるか
(4) どうなれば成功(Goal)とみなせるか
例：レシピを検索するとき
キャスト
検索するひと
→はやく見つけたい
レシピを作った人
→自分がおいしいと思ったレシピを他の人にもみてほしい
レシピをとっておきたい
クックパッド自身
→料理を楽しめるようにしたい
もうけたい
２）計画する
スケジュールを決める時、「３分割の法則」を使う
- 設計
- 開発
- 質を高める
のそれぞれのフェーズに同じだけ時間をかける
ex.3週間でサービスインするとする
設計に1週間
開発に1週間
質の向上に1週間
1週間でできるように設計する
いらんものは削ってベストなことに集中
※設計フェーズ・・・調査、プロト作成も含む
きちんとそれぞれ３分の１づつとる
ものづくり三原則
１）無言実行（むげんじっこう）
２）無言語化
３）サービスに値段をつける
１）無言実行（むげんじっこう）
→サービスの公開やリニューアルを事前に告知しない
公開前にサービスについて説明しない。
公開していないものを説明しようとすると、往々にしてユーザに無用の誤解を与える
不要な不安をあたえることになる
リリースを告知するメリットはない
（＃編者注：こういいきれるのはすごい。まったくその通り。
それはこの次の「無言語化」があるから成り立つことであって、「無言語化」がないと更なる混乱を生む）
２）無言語化
機能を言葉で説明しない
一瞬で機能を理解できなければユーザはＢａｃｋボタンおしてどこかへいってしまう！
※一瞬＝２秒が限界だそうな
ヘルプやＦＡＱもなし
読まないと使えないのはダメ
ユーザに負担がかかる
そもそも読まないし。
３）サービスに値段をつける
どんなサービスでも、いくらに相当するか値段をつけてみる
「無料だから大丈夫」という考え方では負ける
無料だからという理由ではユーザは使わない
Web以外では、リアルの世界ではすべてのものに値段がついている
だからWeb上のものにも値段をつけてみる
「この機能はお金に換算すると500円だな」とか
クックパッドは10年前に始まったときは有料サイトだった
有料のWebサービスというのは早すぎた
→有料だと思って作りこんできたものだからこそ、よかったのだと思う
設計する
順番
最低限必要なものを考える
- 要件定義
- サイトマップ
- 画面遷移
- ページ詳細
- DB構造
設計の順番・・・広い範囲から詳細へ
詳細から設計するとき、機能にとらわれがちだと目標からずれる
ちゃんと目標から設計する
設計
アジャイル宣言の一節より
包括的なドキュメントよりも動くソフトウェアを重視する
→しかし、ドキュメントがなくていいわけではない
→では、最低限要るものは？
- 画面遷移
シンプルであるほうがいい - ページ詳細
- DB構造
途中で変わるのはかまわない
（あと、規模が大きいならばサイトマップ）
３）製造する
開発三原則
リファクタリング
→テスト駆動により
DRY
Do Not Repeat Yourself
→やりすぎるとよくない
YAGNI(You Aren’t Going to Need It) のバランスを意識する
４）質を高める
ユーザテスト
バグの発見
しかし、狙った価値を提供できるのが大事
でないと使ってもらえない
→ゴールを伝える
ex.「今日作るものを探して」
途中で質問がくる場合は
マーケティング
顔マーケティング
かつき*1
売り
ライバルに勝てる売り
クックパッド開発者ブログ
http://techlife.cookpad.com/
*1:いかん、このへんメモしきれてない
