Inside Tabelog's Backend (Ruby会議2008「2nd day」)

Ruby会議2008の2日目は、基本、SKIPブースにいたので、サブセッションをぼんやりと聴いていたのですが。

1つだけどうしても聴きたかったメインセッションのプログラムが「食べログ」の事例。
Railsで作られたシステムとしては、国内一とも言われる規模のシステムの裏側という貴重な事例発表だったので、メモを残しておきます。

Inside Tabelog's Backend

• Windows + ASP ⇒ Railsへ
  • 発表者の京和さんはRails化を提案した本人

食べログ.com について

• 7000万PV/月
• 600万 UniqueUsers PV/月
• サーバは全部で13台
  • Apache x 2 + Mongrel x * + MySQL x 3 (master/slave/slave)
• ruby1.8.6
• rails 1.2

Mongrelについて

• メモリの使用量
  • 4〜5日で8GBのメモリを食いつぶす
  • 1台あたり15プロセスを稼動させている
• 再起動用シェルをcronで実行している
  • でも、ほぼ毎日デプロイしたりしているので、特に問題はない
• mongrelのメモリ使用量をモニタリングしながらチューニングしている
• 基本的に安定している
  • 今まで落ちたことは2〜3回だけ
    • 過負荷な状態の時とか、メモリを食いつぶした状態の時
    • いつの間にかプロセスが消えてていて、ログには何も残っていない

• だいたい50アクセス/秒で処理
  • 0.2秒/1リクエスト
• mongrelは、全部で100プロセス稼動

スケールアウトについて

• セッション共有はDBで

• DBの分散アクセス対応について
  • Magic Multi-Connections
    • 主にコネクション張りすぎなので不採用
      • テーブルの数だけ張る
      • mongrel 100プロセス * 150テーブル = ×
  • ActsAsReadonlytable
    • 30分で簡単に導入できた
    • 既存ロジックの修正箇所が少ない
    • 実装方法がシンプルなのでメンテしやすい
    • 課題
      • フェイルオーバできない
      • 同時接続数が問題
        • すべてのスレーブへ接続する
        • 2〜3台なら問題ない

パフォーマンスについて

• routesは、ほとんど使っていない
  • routesのパフォーマンスが悪いらしい

• mod_rewrite + create_url(自作) を使っている
  • マルチドメイン対応
  • 今後、routesとのパフォーマンス比較をしたい、とのこと

• cacheについて
  • memcached使ってる
    • DBクエリとか、バッチ生成のHTML
    • 100リクエスト/秒
    • Hit率80%
    • CPU使用率1%
    • 落ちたこと無い！
  • MySQLのQueryCache
    • Hit率50%
    • 意外と優秀

• Queryについて
  • 1:Nのincludeはなるべく避ける
    • 重ねると危険、メモリ大食い
  • クエリのチューニング
    • paginate、will_paginateは遅い！
  • 一覧系画面のチューニングで30倍くらい速くなった

• Sessionについて
  • DB格納
    • 今は、1日に100万レコード増えている
  • MyISAMだと消すときに時間かかる＆ロックがかかるので×
  • というわけで、InnoDBに変えた
  • 大事なデータでもないのでレプリケーションしていない
    • 今後は、memcachedに変える予定

まとめ

• やっぱり重いのはDB
• でも、広告も重い・・・

食べログくらいの規模でも全然Railsで運用できる！とのこと。

---

RubyKaigi2008、すごく楽しかったです！
発表者の皆様、スタッフの皆様、SKIPのブースに来てくださった皆様、そして参加者の皆様、本当にありがとう！