「クックパッド」のものづくりセミナーに行ってきたまとめ

昨日、ウェブキャリアさんが主催する月間524万人が利用する食のインフラ、「クックパッド」のものづくりセミナーに行ってきました。
クックパッドと言えばRails での大規模リニューアルがニュースになりました。また、大規模開発には向かないと言われたこともあるRails でこれほど大規模なサイトを開発するノウハウに興味があり、参加しました。
めちゃくちゃ良い情報を得ることができました。これはすごいセミナーでした。以下、まとめです。メモ不足だったので、一部他のサイトの情報を元にまとめています。

CookPad 概要

• サイト
  • レシピ検索No.1／料理レシピ載せるなら クックパッド
• Rails で作られたサイトの中、ユーザ数で世界で8番目の規模
  • rails100 wiki / Alexa Rankings
• Rails で作られたサイトの中、ページビューでは世界で2番目

構成

• Rails 2.0（現在2.1 に移行中）
• Mongrel 1.1.5
  • mongrel_cluster 1.0.5
• MySQL 5.0.45
• Apache(2.2.3) 8台
  • mod_proxy_balancer
• App サーバ44台
• DB Slave サーバ22台
  • 仮想サーバを使って、1つのハードにApp 2台、DB Slave１台
• ログ DB サーバ 16台
  • ログもMySQL で管理
• レシピ全文検索用
  • Tritonn
  • MySQL クライアントを使って全文検索できる

サーバの台数が走り書きで怪しいです

運用ツール

• god
  • mongrel は動かしっぱにするとメモリを使い切る問題がある
  • メモリ／CPU 使用率のしきい値を設定して再起動してくれるツール
  • おちているmongrel を再起動してくれる機能もあるらしい
• Munin
  • サーバモニタリング
• FiveRuns Manage
  • Rails モニタリング
  • Rails 用に最適化されている
  • 本番アプリを監視できる
  • 重いController/Action ランキングの表示
  • ページを開いた時に各モデル／ビュー／コントローラの処理にどのくらい時間がかかったかの表示 ç­‰

パフォーマンス改善

• 1. キャッシュ
• 2. クエリチューニング
• 3. DB 分割

1. キャッシュ

• Mongrel は重い
• ページキャッシュをメインで実装している
  • Apache でキャッシュを返す
• ページキャッシュだと、次の3つができない
  • 「ようこそ○○さん」等のユーザ毎の異なる表示
  • アクセスログの収集。キャッシュだとApp サーバまで来ないでログDB に書き込めない
  • リクエスト毎にことなる広告の表示
• これら3つは通常のリクエストとは別のAJAX の1リクエストで行う

2. クエリチューニング

• Five Runs TuneUp
  • そのページのMVC でどこに時間がかかっているか分かる
  • 開発環境でつかう
  • そのM がどんなSQL クエリを発行し、どのくらいの時間がかかっているか分かる
    • デモにあるように、▼でどんどん分析できる。こりゃ感動ものですよ！！

3. DB 分割

• 08å¹´7月にリニューアルした時には、1台のサーバに2台のApp サーバ、1台のSlave、1台の検索用DB を仮想サーバとしてのせていた
• パフォーマンスが全然でなかった
• 検索用DB ã‚’Slave に統合
• 検索用DB サーバがない分、Slave に当てられるメモリが増えてパフォーマンス改善
• DB サーバは「メモリ容量 > DB テーブルのファイルの容量」が大切
• メモリ（ページキャッシュ）にのりきらないと、Swap が発生し、その分重くなる
  • DB 起動後はDB のファイルをcat して/dev/null に投げてやるっていうアレね

開発ノウハウ

• 宍道湖
  • Rails 製コードレビューシステム
  • 一部バグがあって手直しした

• DB レプリケーション
  • acs_as_readonlyable を使用
  • 更新直後のSELECT はマスタを見に行くように工夫

• レシピ全文検索
  • Tritonn を使用
  • MySQL を拡張したもの
  • MySQL のテーブルとJOIN できる
  • 2インデックス
    • MySQL は一回のSELECT に1つのインデックスの制限がある
    • そこを拡張して2つのインデックスが使えるようにしてある
    • 一回絞り込んで、その中で全文検索するってことができる
    • インデックス貼ったファイルをscp してやるとすぐにTriconn で使える（?よく分からなかった）

• 広告のためのプレビュー
  • 未来の日付に配信される広告のプレビュー機能
  • その広告をいれてページが崩れたりしないか前もって確認するため
  • 全てのページで使える機能
    • http://..../?2008-11-12 とやると、そのページの指定した日の状態が表示
  • 誰でも使えないようにアクセス制限をかけている
  • Time.now の上書きで実現

ものづくりノウハウ

• 1. つくるものを決める
• 2. 計画する
• 3. ものづくり3原則
• 4. 設計する
• 5. 開発する（開発3原則）
• 6. 質を高める

1. つくるものを決める

• A. Best に集中する
  • 「Better なこと、やったほうがいいこと」はやらない
  • Best なこととは、以下の3つの条件を満たす
    • 情熱をもってやりたい！って思えること
    • 得意なこと。そこに関しては世界一になれるほど得意
    • やるべきこと = 収益化につながるということ

• B. ユーザの欲求にもとづく
  • EOGS という分析方法を使う
    • そのサービスに関わるユーザを設定
    • そのユーザの欲求を分析
    • 各欲求をどうやったら満たせるかを考える
    • その全てを解決できる方法を探す
    • それが成功しているイメージを行う
    • そのイメージに対して数字での分析を行い、本当に欲求を満たせているか、検算を行う

2. 計画する

• スケジュールの決め方
  • スケジュールの3分割の法則
  • サービスを作る上で行うことになる、以下「3つ全てに同じ時間をかける」用にスケジューリングする
    • 設計
    • 開発
    • 質を高める
  • ポイントは、開発期間が3週間だとすると、1週間以内に設計できる機能しか開発しようとしないこと。Best に集中する

3. ものづくり3原則

• A. 無言実行
  • 公開前にサービスに関して一切公言しない
  • ユーザの不安をあおることになる
  • 告知するメリットがない

• B. 無言語化
  • 機能を言葉で説明しない。説明しなくても分かるようにする
    • 「このボタンを押すと○○できますよ！」とか説明しないとわからないUI は使われない
    • 基準として「2秒以内」で理解できないUI は使われず、ユーザは他の部分をクリックしてしまうと考える（2秒だと言葉での説明は無理なので、無言語化する）
  • ヘルプやFAQ を読ませるのはユーザに負担をかける。というか読まれない

• C. サービスに値をつける
  • 常に、「このサービスはいくらだろう」と考える
  • 「無料だからこのくらいの機能でも使われるよね」はダメ
  • お金を払ってもいいって思われるものが無料で提供されて初めて使われる

4. 設計する

• A. 設計の順番
• 広域な設計から始め、詳細な設計へと落とす
  • 要件定義＞サイトマップ＞ページ遷移＞ページ詳細＞DB構造
• エンジニアが好きな詳細設計から始めると、機能にとらわれる
  • ユーザに提供するのは機能ではなく、価値
• B. 設計に最低限必要なもの
  • a. 最低限のドキュメント
    • 「ドキュメントより動くソフト」!=「ドキュメント不要」
    • 最低限のドキュメントがある方がアジャイルに開発できる
  • b. ページ遷移
    • 大規模な開発なら、この前にサイトマップ考える
    • ここでは各々のページ詳細は考えないこと
    • 「トップいって」＞「検索画面いって」＞「結果ページ」というくらいシンプルなものでOK
  • c. ページ詳細
  • 手書きの図でOK
    • 作りながらもどんどんメモするために、大きめの紙にかいて余白をあけとくといい
  • d. DB構造
  • 設計の際にプロトタイプを作ったりもする。プロトタイプ作成は開発でなく、設計段階に行う

5. 開発する（開発3原則）

• A. Rail に乗り続ける
  • Rail から外れると、コードが読みにくくなる
  • Rails 自体をバージョンアップできなくなる
  • 外れそうになったら、まずRails の機能がないか探す
  • なくても、Rail を外れない代替案を探す
• B. リファクタリングし続けられるようコードの質を保つ
  • TDD
  • 2006年に一回Rails でリニューアルしたことがあるが、そのコードは2年で拡張不能になった
  • 結局また1から作ることになった
  • リファクタリングを行わないと寿命は2年で終わる
• C. DRY
  • DRY しすぎてYAGN（いずれ必要にならなくなる） にならないように

6. 質を高める

• ユーザテストを行う
  • その際、一切の質問に答えない
  • 次の点を見る
    • 正しい価値を提供できているか
    • こちらが想定した通りに機能が使われているか
    • 想定と違ったら作り直す

感想

まず、しっかりした哲学を持って開発されていると感じました。ここまで考えているからこそ、あれほどのサイトができるんですね。その哲学は広告にも及び、「サイトにのせる広告も料理をが楽しくなる広告でないといけない」とおっしゃっていました。この辺り、Apple のにおいを感じます。
メンバーもバリエーションに富んでいて、「古きUNIX の技術を最新のRails に応用するできないか」とかを考えている人もいるとか。とても面白そうですね！(*´艸｀)
CookPad だけに、満腹なセミナーでした。素晴らしかったです。1時間という短い時間にこれだけの内容をお話して下さった、CTO の橋本さん、そして、素晴らしいセミナーを提供しつづけて下さるウェブキャリアさんにお礼申し上げます。

橋本さんに質問した！

懇親会の際に、以下2点を質問しました！丁寧に教えてくださり、感謝感謝ですm(_ _)m

• Q. Rails のバージョンアップに追従すべきか
• A. そのアプリの寿命による。クックパッドは100年先も続けていたいので、バージョンアップに対応し続ける。また、新しい機能が使えるのも魅力だし、バージョンアップしていかないと、世に遅れて行ってしまい、新しい物と勝負できなくなってしまう

• Q. find_by_sql って使いますか
• A. 使います。find_by_sql はRail にのっているという解釈

参考

• カカクコム＆クックパッド共催・勉強会を開催しました « クックパッド開発者ブログ
• カカクコム&クックパッド共催 勉強会に参加してきました - Affirmative Way
• Ruby on Rails セミナー（クックパッド）へ行ってきたメモ - プログラマ 福重 伸太朗 〜基本へ帰ろう〜