日本最大級Railsサイトの裏側見せますvol.2〜クックパッド＆食べログ

行ってきました、ただのメモです
聞き違え等間違っているところは多々あると思います

クックパッドインフラ

キャパシティプランニング

ユーザが快適に使えるために

  • 分析
    • キャパシティを知る
    • ユーザが快適に使えなくなる限界値を知る
      • 限界値を知る
  • 予測
    • ユーザが快適に使えなくなる限界値を知る
      • 予測日を知る
サーバ増設のスピードアップ
質問
  • 仮想化は?
  • Manifestファイルのサイズ
    • 200行
  • 日々の平均の2倍耐えられる位

食べログで動いている大石さん作のライブラリ

自作ライブラリの必要性
  • 必要な機能を持つライブラリがない
    • 無いなら作る
  • 食べログのニーズに合わない
    • 仕様にぴったり
  • 開発が止まっている
    • メンテナンス早い
ActsAsReadonlyable改
  • 概要
  • 問題
  • スレーブ１台が壊れるとFailOverしない
  • 改造点
    • スレーブが死んだら自動的に切り離す機能を追加
      • MySQL::ConnectionErrorで検知して外す
  • 良かった点
    • 気軽にDBを落とせる
    • DB落としても
TabelogAsync
  • 非同期処理ライブラリ
    • backgroundrbをつかていた
      • 時々暴走
  • 特徴 
TabelogAsync::Thrower.send(
   :class => :async_log,:args => "good"
)
  • 設計思想
    • 軽くてすぐに終わって同期が不要な大量の処理を
    • 思い処理も回すようになった
    • シングルスレッドなので遅延が。。。
    • 重い処理利用サーバと軽い処理用サーバで分けている
WordScoop
  • 公開されている
  • キーワード検索ライブラリ 
gem install word_scoop
  • 公開する場合は英語で
質問

クックパッドHadoopで　分散処理

Hadoop導入理由
  • たべみるで使う
  • データ量が多い
    • GROUP BYが多い
    • GROUP BYが重い
    • SQLでやると7000時間==一年くらい？
Hadoop概要

cookpadでのHadoop利用

  • Hadoop Streamingを利用
    • Javaで使い易いがStreamingを使うと多言語でOK
  • EC2で50台
  • HDFSはS3

Hadoopの効果

  • 7000時間->30時間
質問
  • Amazon EC250台とあるが、一ヶ月にどれくらいのインスタンスを起動どれくらい費用がかかるのか
    • ずっとつけっぱなしではない必要な時だけ
    • 会社全体で使っている10万から40万

PCI-Express型SSDとMySQL

SSDについて
  • HDDより高速
  • Random accessに強い
  • エンタープライズ向けSSDが出てきている
    • コンシューマよりも高価
    • IBMとかEMCとか
    • 導入事例も多い
    • テストもされている
    • はてなとかも使っている
  • PCI-Express
    • 高価
      • 128GB 14万
    • 対応ドライバが必要
    • Writeの性能があまりでない
    • I/Fよりも高速
ベンチマーク
環境
結果

クックパッドサーバー、クライアントのボトルネック調査と高速化

問題
  • ページキャッシュ、アクションキャッシュ導入済み
  • フラグメントキャッシュは可読性の問題で導入していない
Web
  • muninでモニタリング
  • apache access_logを集計
  • 250-300
App
  • production.logをモニタリング
DB
  • MySQL Tritton
  • appサーバのproduction.log
  • スロークエリ
  • FiveRuns
Web<->Appをからてをつける
  • passengerをつかう
  • Ruby Enterprice Edition
    • メモリはかなり減った
    • 起動時にすべてのFileを読み込む
    • Memcacheのコネクションが共有されてしまう問題
      • マニュアルに解決策あり
  • mod_deflate
    • 以前レイアウト崩れが発生
    • HTMLのみ
    • IE6,Firefoxのみ
  • レイアウト崩れ対策
    • screenshot.jpでチェック
      • 一部導入から全体へ
    • 150-200msecに下がった
  • クライアントサイド
    • 広告とか動的に書き込むところはAjax
    • Ajaxの遅延を改善
  • 表示完了まで1sec以上掛かっている
  • asset id がAppサーバごとに異なる
    • appサーバ毎にタイムスタンプがバラバラ
    • GitのログからRAILS_ASSET_IDを設定
  • Ajax高速化
    • onloadは遅い
    • headerでリクエストを送信
    • footerで描画
    • BBvFlashbackの不レム数で測定
    • 200msec以上Ajaxが高速
  • 本番環境で計測
  • 測定は重要だ
質問
  • 200msec以下の理由
    • ユーザにとって快適
    • Googleの目標値が100msecだから
  • たまにとんでもないのはあるか
  • レスポンスタイムの寄与
    • 広告のクリック率はわからない
    • ユーザ数が増え続けけている
  • フレーム数 BB Flashbackはだれが発想
  • CDNはつかっている
    • すでに使っている
    • リクエストの9割はCDN
  • CDNはどこつかっている？
ボトルネック特定の為のログ解析
食べログの構成
Apache遅い/Railsが速
  • どのAPサーバ?
  • HTTPレスポンスヘッダ
  • X-Runtimeを使う
    • RailsログのTotalと同じ時間
  • X-AppServer(食べログで拡張)
    • Apサーバのホスト名:Mongrelポート番号
    • railsでheaderに出す
    • Apacheのログに吐き出すように設定
  • 結果
  • 誰が犯人
    • mongrel?
      • HttpServer#process_clientの処理を細分化
    • 結果
      • Socket#writeで時間がかかる
      • 最高300秒
      • passengerを検討
Rails遅い/MySQLが速
  • どこが遅い
  • production.logに吐かれるのを拡張
    • RailsLogger#benchmark
    • production.logを取り込んで解析するツールを自作
  • 犯人は
    • 広告！！！
    • タイムアウト
    • 広告を一部外して対応
      • 営業サイドと交渉
      • ログを見せて納得
質問
  • ログ運用の対策
    • ファイルサイズに気を付ける
    • debug logとか出さない