「クックパッド」の裏側にいってきた

Web デベロッパーの祭典に行ってきた。今回は、通路沸きに用意された比較的狭いスペースで開催された。

以下、メモと自分の勝手な感想をまとめておく。

クックパッドについて

• 毎日の料理を楽しみにすることで心からの笑顔を増やす
• 1998年にオープン
• 去年のリニューアルのときに Rails で作り直した

使い方

• レシピをのせる
• レシピをさがす

インフラまわり

• ロードバランサー、アプリケーション、データベースの、よくある3層構造
• サーバ台数: ロードバランサー x 8, アプリケーション x 52, スレーブデータベース x 18, マスターデータ, 監視, ログなど
• ロードバランサー: Apache 2.2.3 mod_proxy_balancer(2.2.3 ということは CentOS 5系なのかもしれない、この規模で mod_proxy_balancer か…)
• アプリケーションサーバ: Ruby on Rails 2.0, mongrel 1.1.5 / mongrel_cluster 1.0.5(もちろん、複数プロセスで起動しているとのこt)
• データベース: MySQL 5.0.45
• Tritonn(全文検索用に使っているとのこと、かなりお気に入りらしい)
• デプロイツール: capistrano(当然ですな)
• god(mongrel でメモリリリークしたときに自動的に再起動するツール、like monit だが設定ファイルは Ruby で書けるツール、個人的には monit で統一しているが Rails ならこっちのほうがいいかもしれない)
• 監視ツール: nagios(当然ですな)
• モニタリング: munin(めずらしい)
• パフォーマンス計測ツール: FiveRuns Manage(ページを表示するとさまざまなパフォーマンス測定をしてくれるツールらしい、初めて知った)

キャッシュ、クエリーチューニング

• ページキャッシュしたデータを NFS に保存して、Apache から直接返している
• フラグメンテーションキャッシュには、memcached を使っている
• ユーザ毎に異なる表示をしているところや、アクセスログの統計、広告の挿入は、Ajax の1ページ1回のリクエストでまとめて行っている
• クエリーチューニングには、FiveRuns TuneUp や MySQL のスロークエリーログを見ながら行っている
• DBとメモリの関係で、リニューアル直後のDB構成は アプリケーション x 2GB、アプリケーション x 2GB, スレーブデータベース x 8GB、検索データベース x 4GBという仮想マシン構成だったがパフォーマンスがでないため、アプリケーション x 2GB, アプリケーション x 2GB, スレーブ + 検索データベース x 12GBに変更した、原因はメモリサイズ以上のデータベースサイズになっていたため
• さらにデータベースサイズが大きくなると、物理メモリを増やして、物理メモリを増やせないときはテーブル分割を考えているとのこと

Rails での開発ノウハウ

• プログラマーは、全員マックを使用してノウハウを共有してやすくしている(これはすごい、自分が好きな道具は使えないということか)
• Emacs、rails.el がデフォルトの開発環境とのこと(素晴らしすぎる!!!)
• Subversion と trac
• Redmine を最近から使っているとのこと
• Shinjiko を使っている(Mondrian クローンコードレビューツール)
• DBのレプリケーションを扱うため、マスターとスレーブの切替えとして acts_as_readonlyable を使用している
• レシピの全文検索には、Tritonn を使用している
• Tritonn のいいところは、MySQLを拡張しているのでテーブルをジョインできること、2インデックスを使える(通常の MySQL では1インデックス)。インデックスを張ったテーブルのファイルをそのままコピーできる(インデックスの作成時間を減らす)
• 一部のユーザは自分専用のURLをもつため、routes.rb で全てのコントローラ名を検索して一致しない場合には専用のコントローラに渡している
• 全ページのプレビュー機能(すべてのページで、任意の日付を指定してプレビューできる)は、 Time.nowを上書きして実現している、アクセス制限もつけている

クックパッドのものづくり

• つくるものを決める

Best なことに集中する(やりたい(情熱を持ってとりくめること)、できる(世界で一番になれる)、やべるき(儲かること)、Better なことはやらない Best しかやらない)

• ユーザの欲求に基づいた機能

EOGS(Emotion Oriented Goal Setting)

そのサービスに関わるキャストを立てる

キャスト毎の疑いようのない欲求を考える

• 計画する

スケジュールの3分割の法則: 設計、開発、質を高める、という三つの工程にわける

• クックパッドものづくり三原則

無言実行: 公開前にサービスについての説明をしない

サービスを言葉で説明することができない

公開前に事前告知しない(リニューアルときも事前告知しなかったとのこと、事前告知するメリットはあまりないとのこと)

無言語化: 機能を言葉で説明しない

一瞬で理解できるインタフェースじゃないと使われない、最大2秒以上理解するのにかかる機能はユーザは使ってくれない

ヘルプや FAQ を読ませるのはユーザに負担を強いるし、そもそも読まれない(ヘルプや FAQ を用意すればいいという考え方はよくないとのこと)

サービスに値段をつける: どんなサービスでも幾らかの価値があるか値段をつけて考える、無料だから大丈夫という考えでは負ける、ウェブ以外のサービスやモノは価値にたいして値段が付いている

クックパッドは当初有料だったが、時期的に早すぎたので無料にしたのこと

• 設計する

サイトの設計の順番

設計に最低限必要なもの

ユーザに届けるべきもの

遷移、ページ詳細、DB構造、サイトマップ、が最低限必要なドキュメント

• 開発する

Railsに乗る

リファクタリングし続けられる状態を保つ(いわゆるアジャイルな開発環境)

DRY(Don’t repeat yourself), YAGNI(You Aren’t Going to Need It) のバランスを意識する

 

 

• 質を高める

ユーザに狙った価値を提供できているのかテストするためのもの

ユーザテストのときには質問には答えない、質問が出るインターフェースは失敗

顔マーケティング

ライバルに勝てる「ウリ」

エンジニア紹介

• hightime.jp を作ったエンジニアがいる

クックパッド開発者ブログがある。

 

このイベントは、当初満席だったのでキャンセル待ちで連絡しておいてよかった。インフラまわりの新しいツールも知ることができたし、クックパッドのものづくりに対する姿勢はとても勉強になった。そこには、一般ユーザ向けのサービスを作るための重要な施策がいくつもあった。

前の仕事では、初めて一般ユーザ向けのシステム開発を担当していたけれど、ヘルプや FAQ を用意すればいいと思ったことがあったことのが恥ずかしいと振り返りました。

ウェブサービスは無料なものがほとんどだけれど、無料だから使われるという考え方はよくないと言われたときにドキっとした。お金を払ってもいい価値があるサービスが成功するのだと感じた。

 

とても有意義な講演でありました。

Tags: rails cookpad