日本一のRailsでの大規模サイトである「クックパッド」のお話を聞きに，WebCareer主催のセミナーに参加してきました．
- MacBook Pro 17inch だった．
##クックパッドとは
- ミッション：毎日の料理を楽しみにすることで，心からの笑顔を増やす
- 1998年オープン
- 料理のレシピを
- 公開する
- 探す
- 作者に報告することもできる
- 写真付きで
45万品のレシピがある
524万人/月
- 四国の人口よりも多い
月間 2.8 億 PV
###トラフィック
- 16～18 時がピーク
- 秋からバレンタインにかけてトラフィックが伸びる
##524万人をささえるサーバ・ネットワーク ###サーバ構成
- apache x 8
- app x 44
- master x 1
- log master 1
- slave x 13
- Apache 2.2.3 / Rails 2.0 / Tritton
###運用
- capistrano
- god
- nagios
- munin(モニタリング)
- FiveRuns Manage(モニタリング)
###パフォーマンス
キャッシュ
- Mongrel を通るだけで 10ms は空
- なので，ページキャッシュをメインに実装中
- Apache -> cache な感じ
- ページキャッシュできない3つのもの
- ユーザ毎に異なる表示のもの
- アクセスログ
- 広告
- これらは Ajax の1リクエストに埋め込んでいる
- ページキャッシュから Ajax を使ってリクエストする
クエリチューニング
- FiveRuns TuneUp
- スロークエリログ
DB 分割
- リニューアル前
- app(2GB) x 2 + slave(8GB) + 検索 db(4GB) on 1 VM
- リニューアル後
- app(2GB) x 2 + slave(12GB) on 1 VM
- OSのキャッシュにのるかが重要
- アクセス数よりもデータ数の方が負荷には重要な要素となる
##Railsでの開発ノウハウ ###開発環境
- プログラマは 全員 Mac を仕様
- Emacs with rails.el
- Subversion + trac
- Shinjiko
- Mondorian クローンのコードレビューシステム
###DBのレプリケーション
- acts_as_readonlyable を使用
- ただしデータ更新後の SELECT は master から行うように変更
###レシピの全文検索
- Tritton を使用
- 2インデックスを使って検索できる
- バッチ計算サーバでインデックスを張って，それをそのまま scp で slave へ転送したりしている
###専用 URL
- routes.rb で解決
- 既存コントローラの一覧を持っていて，存在しないコントローラの場合は専用のコントローラに渡して処理する感じ
###全ページのプレビュー機能
- MM/DD HH ～ HH のみ表示
- すべてのページで任意の時間を指定してプレビューできるようにしている
- Time.now を書き換えている
- スタッフのみにはしている
##クックパッドのものづくり ###方法
- つくるものを決める
- 計画
- 設計
- 開発
- 質を高める
###作るものを決める
- Best なことに集中する
- Betterなこと，やった方がいいことは やらない！
- Best なことを見つけるための3つの輪
- やりたいことかどうか
- 情熱を持って取り組めること
- できる
- 世界で一番になれること
- やるべき
- 儲かること
- この3つの輪が重なることだけをやる
- 非常にわかりやすく理想的な形ではないでしょうか
###ユーザの欲求に基づいたゴール設定
- EOGS(Emotion Oriented Goal Setting)
- ユーザ層を決める
- ユーザの欲求を理解する
- 解決法を探し
- それを実行する
- ゴール設定をするなかで，チーム内で意見を自然に集約されていく．
###スケジュールの3分割
- サービス完成までにやるべきこと
- 設計
- 開発
- 質を高める
- これら3つについて，同じだけ時間をかける
- 3週間後にサービスインするならば，すべて1週間ずつ
- 1週間で開発できないことは設計しない
- 設計にも1週間使う
- 質を高めるのに1週間を使うのは，非常にいい体制
###ものづくりの3原則
- 無言実行
- 公開前にサービスについての説明しない
- サービスを言葉で説明できない
- ユーザに変な不安を与えないため
- 公開前に告知するメリットはない
- 無言語化
- 機能を言葉で説明しない
- 一瞬で理解できるインターフェイスじゃないと，使われない．最大2秒
- 2秒で説明できるように作る
- ヘルプやFAQを読ませるのはユーザに負担
- そもそも，読まれない
- サービスに値段をつける
- どんなサービスでも，どれだけ価値があるか値段をつける
- 「無料だから大丈夫」という考えでは負ける
- お金を払ってでも使いたいサービスが無料だと使われる
- ウェブ以外のサービスやモノは価値に対して値段がついている
- そこと勝負するためには，作るモノに値段をつけて価値を与えないといけないのかな．
- クックパッドは当初は有料サイト
###設計する
- サイト設計の順番
- 広域から詳細へ
- 要件定義 -> サイトマップ -> 遷移 -> ページ詳細 -> DB 構造
- ユーザに届けるべきものは，「機能」ではなく「価値」
- 設計に最低限必要なもの
- アジャイル宣言の一説
- 「包括的なドキュメントよりも動くソフトウェアを重視する」
- これは「ドキュメントがない方がいい，なくてもいい」わけではない
- 最低限必要なドキュメント
- ユーザの遷移について
- ユーザの理解できる遷移でなければならない
- ページ詳細までは考えない，大枠の遷移
- ページ詳細
- DB 構造
- サイトマップ(規模の大きな開発の場合)
###開発する
- Railに乗る
- Railを外れると
- 明日の自分は他人と考える．コードが読みにくくならないように．
- Railsのバージョンアップへの対応が困難になる
- Railを外れそうになったら
- Railsでできないか調べ，
- Railsで代替案を探す
- リファクタリングし続けられる状態を保つ
- アジャイル開発のもっとも大切な概念
- テスト駆動による開発
- 2006年にリニューアルしたコードでは，2年で拡張が不可能に
- DRY
- やり過ぎると YAGNI(You Are not Going Need It) = いずれ必要でなくなる
###質を高める
- ユーザテスト
- バグの発見よりも，ユーザにねらった価値を提供できているかが重要
- ユーザにゴールを伝えて行動してもらう
- 質問などには答えない
- 質問が出る遷移・インターフェイスは失敗
- ユーザに何を考えているかを話しながら操作してもらう
- 顔マーケティング
- 「かうき」の法則
- 売りを伝える「顔」
- ライバルに勝てる「売り」
- 売りが実感できる「効き」
##エンジニア紹介
- 紹介が続く
##エンジニア募集
- 募集中
##感想とまとめなど ユーザ本意でありながら，会社の利益も重視する方法論は非常に共感できる，いい考え方だと思いました． その上で思想を持った開発体制を敷いているようなので，今後の展開に期待と言うところでしょうか．
あと Mac + Emacs で開発環境を統一しているのはいい感じですね，Emacs 使いとしてはｗ
