RED-MOUNT.COM

2009年2月7日、秋葉原で行われた「WEBデベロッパの祭典＠東京」に行ってきました。
約１ヶ月も前になってしまったので激しく今更ですが、僕が参加した「国内最大規模のRuby on Railsサイト 〜「クックパッド」の裏側見せます〜」というセッションについてまとめておきます。

COOKPADについて

http://www.cookpad.com/
技術ブログ　http://techlife.cookpad.com/
COOKPAD自体は1998年にオープンしたレシピ投稿・検索サイト。
現在までに47万品以上のレシピが登録されており、月間PV約2.8億、月間ユーザー数約547万人を抱えています。
「世界で一番生活に役に立つサイト作り」を目指しており、投稿されたレシピをただ見るだけでなく、自分が作った料理の写真を作者にフィードバックすることが可能です。

COOKPADはどのくらいすごいのか

月間ユーザー数547万人というのは、Railsサイト中世界7位。
月間PV約2.8億というのは、Railsサイト中世界3位なのだとか。
(Alexa調べ)

トラフィックの傾向

COOKPADのトラフィック傾向は、「レシピサイト」というサイトの特性もあり、16-18時がアクセス数のピーク。年間で見ると秋からバレンタインにかけてトラフィックが伸びる。
バレンタインまでのユーザー数の伸び率が、次の年のユーザー数に繋がるのだとか。

COOKPADの基本的なサーバー構成

apache 8台 (ロードバランス用)

アプリケーションサーバー 52台

slave dbサーバー 18台

その他 imagedbサーバー、master dbサーバーなどが複数

※VM上にサーバーを立ち上げているので、実際の数は30台程度？

サーバー内で使用しているアプリケーションは、

• Apache 2.2.3 + mod_proxy_balancer
• Rails 2.0
• mongrel 1.1.5 / mongrel_cluster 1.0.5
• MySQL 5.0.45
• Tritton (未来検索ブラジル)

など。そのほか、管理ツールとして下記を使用している。

• capistrano*1 (deploy)
• god (mongrelの再起動 / メモリリリース用)
• Nagios (サーバー/ネットワーク 監視ツール)
• Munin (モニタリングツール)
• FiveRuns Manage (Rails用パフォーマンス計測)

パフォーマンスUPの方法

キャッシュ
ページキャッシュはNFSに保存して、apacheから直接返す。(Mongrelに回さずに済むので早い)
更新処理などのあるページはmemcachedを使ってフラグメントキャッシュを行っている。
ページキャッシュできない「ユーザー毎に異なる表示を行う部分」「アクセス解析」「広告」については、Ajaxの1リクエストでまとめてページ内に埋め込むようにしている。（Ajaxリクエストをそれぞれに発行するとその分処理が遅くなる）

クエリチューニング
実行されたクエリをブラウザ上でリアルタイムに表示してくれる「FiveRuns TuneUp」を使用している他、MySQLのスロークエリログを見ながらチューニングをしている。

DB・メモリチューニング
データベースは、アクセス量よりもむしろ保存されているデータ量がパフォーマンスを低下させる。DBチューニングの際には、OSのキャッシュにテーブルファイルが収まるかが最も重要なポイントなのだとか。

例えば、2008年夏にCOOKPADがリニューアルした際、VM上のサーバーと割り当てメモリ量は下記の通りだった。

• アプリケーションサーバー 2GB × 2
• slaveDB 8GB
• 検索DB 4GB

しかし、データベースのサイズがメモリサイズを上回っていたため、パフォーマンスが出なかった。
結果的に、slaveDBと検索DBを一つのサーバーにし、割り当てメモリ量を12GBにすることで、パフォーマンスの改善が見られた。

• アプリケーションサーバー 2GB × 2
• slaveDB+検索DB 12GB

今後、DBの容量が増えて12GBでは足りなくなったら、テーブルの分割を考えているのだとか。

Railsでの開発ノウハウ

DBのレプリケーション
マスターとスレーブの切り分けはacts_as_readonlyableプラグインで行っている

レシピの全文検索
trittonを使用して全文検索を行っています。MySQLを拡張しているので、テーブルのJOINが可能な他、2インデックスが効く点や、インデックスを貼ったテーブルのファイルをそのままコピーできる点が採用のポイントなのだとか。
また、インデックス用DBと稼働DBを分けて、インデックス用DBのインデックスデータを稼働DBにコピーすることで、インデックス時にかかる負荷を稼働DBから取り除いています。

専用URL
http://hoge.fuga.jp/[ユーザー名]
のような、ユーザー毎に割り当てられる専用URLの作成には、下記のような方法を使っています。

1. routes.rb*2で全てのコントローラー名を検索
2. 一致しない場合はユーザー名として専用のコントローラーに飛ばす

routes.rbの評価はRailsサーバー起動時に1度のみなので、オーバーヘッドは気にならないそうです。

全ページのプレビュー機能
全てのページで任意の日付を指定しプレビューすることが可能（管理者のみ）。
before_filterか何かで取得したparamsを見て、Time.nowを上書きしている模様。

感想と所感

実はこのセッションを聞いていた時、斜め前に小飼弾さんが居られたのですが、セッション終了後ぼそっと「このセッション、エントリーし辛いなぁ」とつぶやかれていたのがとても印象的でした。

確かに今回、僕もこの記事を書くにあたって相当苦心しました。
改めて記事を見返してみて、記事が書きづらかった原因は恐らく「伝えたい事が多すぎた」からなのかな、と思います。

セッション自体は45分しかなかったのですが、その中にあれもこれもと情報を詰め込みすぎた結果、何が一番大事で、何を一番伝えたかったのかがぼやけてしまった。
人に何かを伝える時は、あれもこれも一度に伝えるのではなく、必要な事を数回に分けて伝えないとダメだな、と強く感じました。

とはいえ、45分という短い時間の中で、色々な事を説明していただき、大変勉強になりました。
機会を設けて下さった、パソナテックさんとCOOKPADさんに感謝。

用語について
capistrano: 複数のサーバ上で同時に並行してコマンドを実行できるツール
routes.rb: Ruby on Rails上で、ルーティングを定義しているファイル