RubyKaigi2010 に行ってきた(1日目) - Slow Danceに続き、今年のRubyKaigi に行ってきたレポートを書きたいと思います!例によって興味があった内容をまとめました。Chad Fowler の基調講演の内容は情熱プログラマー ソフトウェア開発者の幸せな生き方を読むのが一番いいと思います。
また、内容に誤りがありましたらお手数ですが指摘いただけますと助かります。
Ruby powering 9 million dining tables(Cookpad)
Cookpad CTO の橋本さん(@hashikem)によるCookpad のサービス、システム全般のお話と、id:secondlife さんが何故Cookpad に入社したかというお話を聴きました。
規模
- 9.89 M UU / month
- 83万レシピ
システム構成
- MySQL 5.5 + Triton
- 5.1 だったような気もする
- スライドみようと思ったけど公開されていない
- Ruby On Rails 2.3
- Cent OS 5.3
LVS - Web ---------------- LVS -- App(rails)
|_ Cache_fs |_ Cache(フラグメントキャッシュ)
- PC版とモバイル版はWeb もApp も別
- 99% 以上のリクエストを200ms で返すことが出来ている
キャッシュ
使っているキャッシュは2種類。
- ページキャッシュ
- フラグメントキャッシュ
- 3つのできないキャッシュ
- 検索結果のキャッシュ
- 講演内容に検索結果もページキャッシュしているという部分があり、「クエリパターンを全部キャッシュしているの?」とか「新しいデータ作成されたらキャッシュの再生性を行うの?」とか疑問に思ったので、講演後に中の人に伺いました
- 1日1回バッチでキャッシュを作成する
- ログから上位x 件の検索パターンに対して検索結果のキャッシュを生成
- 検索パターンはいうほど多く無いらしい
- 1日1回しか作らないので、更新されても次の日までは検索結果に反映されない
- 本当は良くないけど現在はそうやっいる
DB レプリケーションとacts_as_readonlyable
- 更新直後はマスタからselect
- 更新処理はpost で実行しているので、ApplicationController のbefore_filter を使って、post 以外はslave を見るようacts_as_readonlyable のフラグをセットしている
DSR とコネクションプーリングの問題
この問題についてはRails(ActiveRecord)でデータベースへのコネクションプーリングをさせなくする - ククラフトに詳細が書かれている。
- cookpad ではDB へのアクセスもバランシングしていて、各slave の負荷が均等になるようにしている
App - LVS - DB
マスタDBの分散
- デュアルマスタ
- マスター1がダウンした場合はマスター2 に自動切り替えするようにしている
- ホットスタンバイ状態かな?
- 切り離された元のマスタは手動で戻す
- マスター1がダウンした場合はマスター2 に自動切り替えするようにしている
- 他に、機能別にマスタを分割
ヘルスチェックの罠
- とある時にやたらマスタDB の負荷が増える
- App からマスタDB が生きているか確認している処理があって、その処理にstatus コマンドを使っていた。status コマンドは重い
- 加えて、App がどんどん増えていくにつれマスタへの負荷が増えていた
- 対策
- ping でステータスチェックをするよう変更
やはり、問題が発生したら、原因分析と解決をしっかりとやっているという印象。
画像ファイル運用上の工夫
- 画像系の規約として画像(パス)を保存しているtable にはphoto_saved_at というカラムを付けるようにしている
- このカラムの値がNULL なら画像はなし
- 画像を表示させる部分には全て同じヘルパを使うことでこの規約を適用している
- このカラムの値がNULL なら画像はなし
監視
-
- etc.
- Content Analytics and Insights for Digital Publishing | Chartbeatという外部システムも使っている。昨日との差分が見られたりして便利
オフィス
- 以前は合宿をやっていたけど、今はオフィスが快適なので毎日合宿のようなもの
- 壁一面がホワイトボート
質問
- デザイナ - プログラマ間のコミュニケーションの取り方
- デザイン専門というのはいない
- デザイン面では公開前に必ず社長のチェックを受ける
- ユーザにヒットするモノを作るには
- 最初に実装されたものは大抵使いづらい。モデルユーザに使ってもらい使いやすくしていく
- 90％ の機能を捨てるという覚悟。本質に集中する
- 公開している機能もどんどの削る
- ミッションの共有をどうやっているか
- 技術のための技術をしない
- 目的ありきの技術
- ここの認識がずれていると感じたら話しあって考える
ユーザ視点を本気でつらぬているということがヒシヒシ伝わってくる講演でした。
何故Cookpad に入ったのか(id:secondlife さん)
- ものづくりの考え方に共感
- エンジニア全員が技術+αを持っている
- 話をしていてとても面白い
- +αとは
- コードの価値観
- ここのコードがバグるのは絶対にあってはならないとかビジネスの視点を持っている
- 多様な視点
- ものづくりに真剣
- コードの価値観
- 本気でユーザのことを思っていれば+αはついてくる
橋本さんへの質問
講演終了後にその場に来ているCookpad のエンジニアが紹介され、質問がある方は直接話かけてみて下さいという形式のフリータイムに突入。
早速橋本さんに質問。
- 初心者エンジニアが育つにはどうすればいい?
個人的にも聞きたいこと。また、今自分がいる会社のエンジニアは大学時代にプログラムに触れていなかった人が大半のため、その人達が育ちやすい環境をどのように作ればいいと思うか、というあたりを伺ってみました。
- 基本的にcookpad は中途しかとらない
- 自身の経験を話すと期日までに作ると決めたら死ぬ気で作っていた
- でも作っている時はとても楽しい
- それこそ電車の中でも常にそのことを考えている。周りから見れば変な人だと思う
- しかし、実際こうやっている時が一番のびた
講演内容は素晴らしいもので、何故大ホール枠じゃないんだろうと思ったほどです。
逆に、大ホールでないから、30分以上の時間を使えるし、質問タイムも長めに設けて下さったので企画部屋枠が一番だったのかもしれません。
本当に勉強になりました。ありがとうございます。
RWikiと怠惰な私の10年間
dRuby の@m_sekiさんによるRWiki の活用事例、どうやって開発してきたのかの話。
NoSQL(ネタ)
- DB とかを使わないでログファイルに書き込む形式
- DB とかいらない。なんでもプロセスに入れている
- RWiki のプロセスが起動時にログファイルを読み込む
- 基本的にデータはメモリから返して書き込み操作のみをDisk に書いている
- メモリにはERB オブジェクトだけを保持
- メモリで処理する
- 全てのデータをオブジェクトにしてひとつのプロセスに配置
- 要素が数万程度のArray やHash は普通に使える
活用事例
問題点
- 起動が遅い
- 起動時にページをメモリに読みながらそのページにあるリンクも再帰的に読み込んで展開していた
- リンクの展開にはキューを使い、同時に生成される木はひとつになるようにした
- キャッシュとして、オブジェクトをMarshal.dump した状態でログファイルに書き込むようにした
- ログには最低限の情報しか保存しないという方針だったけどあまりこだわらないことにした
まとめ
- 全てのオブジェクトをひとつのプロセスに配置するのは自然
- 自然な設計なので変なトラブルにはまらない
- メモリが大きくなるが100 ページとかなら全然問題ない
これで、RubyKaigi2010 のレポートは終わりです。
RubyKaigi からそろそろ1ヶ月が経ちますが、本当に良いイベントでした。昨年より多くの人と話すことができたのはシャイなRubyist界隈の自分にとって良い試みだったと思います。その甲斐あって、得られたものはとても大きかったです。
(あと、デモでto_f するところがto_i になっていてテストが落ちるという現場に遭遇したので「to_f 必要です」とツッコんだw)
最後に、RubyKaigi スタッフの皆さんを初め、スピーカー、スポンサー、参加者の全ての皆さんに感謝します。ありがとうございました。
