ITコンサルの日常

ITコンサル会社に勤務する普通のITエンジニアの日常です。

Railsセミナー行ってきました。

Ruby

ウェブキャリアさん主催のやつです。
http://www.web-career.com/seminar/rails_2008_0924.html
以前もいったのですが、また行ってきました。
今回は、ライトニングトーク風のリレーセミナーということで、色々な話が一度に聞けて楽しかったです。

1. Rails のアプリケーションの運用環境概要

  • 昔: lighttpd + FastCGI + Rails
  • 今: Apache(mod_proxy_balancer) + mongrel(mongrel_cluster)
  • 今後: Apache + Passenger
    • トラフィックに合わせてインスタンス数自動調整
      • あらかじめ必要プロセス数を見積もって立ち上げておくという方式に比べて無駄がない
    • 設定容易
    • メモリ使用量が少ない
  • 将来: Rails2.2 + スレッドセーフRails
    • プロセスをたくさん上げるとメモリ消費大で、4GBあっても足りないことも。。
      • なので、スレッドセーフRailsは期待
    • ただ、Rubyはネイティブスレッドではない
      • JRubyはネイティブスレッド

JRubyここでもきた!って思いました。
JRuby on Railsが、ひとまずJRubyの生きる道なわけですね。。

2. パーソナライズドレコメンダー開発事例

  • パーソナライズドレコメンダー = おすすめ商品をバナーで出すASPサービス
  • 管理画面の開発容易性のためRails採用
  • APサーバ2台、DBサーバ2台で運用
  • CentOS5.1 + Apache2.2 + Rails2.1 + MySQL5.0
  • サーバが複数台あることで、管理コストが増大
  • ASPサービスのため、埋め込まれるページのPVに応じた負荷がかかる
    • 必要に応じてセッションをやめてCookieにした
    • memcachedの導入
  • 4.5MPV/月、1.4GPV/月をさばいている

CentOSって名前は良く聞くのですが、実際使われているんですね。
capistranoは、とにかく一度動いてしまえば、あとはコマンド一発で色々やってくれるのでラクだと思います。
昨日「サーバー/インフラを支える技術」を立ち読みしたら、はてなでも使ってるらしいです。
Rubyに限らず使えるんですね。


あと、パフォーマンスチューニングのところは色々ノウハウありそうですが、
会場に来てて実際Rubyの開発をやっているという人に話を聞いたら、フラグメントキャッシュ使ったり、場合によってはActiveRecord使わないで直SQLを使ったり、色々苦労されているみたいでした。
この辺のノウハウは本になってても良さそうですけど、そのものズバリは本はまだないみたいですね。「Railsレシピブック」にも載ってるのかな?

3. SNSエンジン開発事例

  • 2005年: 当初JavaでSNSを開発
  • 2006年: SNSをパッケージ化するとともにRails化
    • 技術面、営業面の両面において、アピールできると考えた
  • とにかく苦労。。
    • Rubyの知名度が低かった
    • PHPとの違いや、そもそもRubyって何という質問がはじめにあり、なかなかSNSパッケージの売り込みにまでいけなかった
  • 2008年: Rubyに好意的な反応をするお客さんが多い
    • 使ってみたかったというお客さんや、生産性が高いって本当? などの質問をよく受ける

Rubyに好意的な反応をするお客さんが多いってのが、ちょっと興味ありますね。
日経ｘｘとかにも、結構Railsの記事が出てるんですかね。
僕が読んでる日経SYSTEMSでも、以前にフレームワークのパフォーマンス検証記事とか出てましたが。そういや、Djangoが速かったみたいな話だったような気がします。

4. パフォーマンス対応事例

  • パフォーマンスチューニングの手順
    • 重いページを見つける
    • 原因の調査
    • 対処 or 回避
  • 重いのは全体の1割くらい
  • 主な原因
    • コーディングレベル
    • データ量が多い
    • 処理が多い(という原因は、あまりないらしい)
  • ログ
    • log/環境名.log(production.logとか)
    • Completedの行に処理時間が載ってるので注目
    • 全体の処理時間＋以下の情報が取れるので、MVCのどこで問題が起こっているか切り分けられやすい
      • Rendering (ビュー処理にかかった時間)
      • DB (DB処理にかかった時間)
    • config.log_levelを調整することで、本番環境でもデバッグログを出力することが可能(ただし、性能劣化やディスク圧迫につながるので注意)
    • 個人情報が入っていることもあるので、取り扱いには注意が必要

たぶん、全体の処理時間 - Rendering - DB = Controllerなんだと思いますが、MVCのどこで問題が起こっているか切り分けられやすいってのは親切設計ですね。
ただ、DB処理で問題が起こっている場合は、多分発行されているSQLをみたくなるので、その場合はデバッグログが必要になりますが。

5. 電脳★スターラリー取り組み紹介

拡張現実スゲーって感じです。
http://star.yuiseki.net/
右側のムービーをみると、大体どんなことなのか分かると思います。
あと自走式サーバとか、完全にネタ的なものも披露されてました。


Ruby(Rails)は、

  • RubyGems、拡張Cライブラリによって強化され
  • RailsによってWebと容易に接続でき
  • Gainer、シリアル通信によってリアルワールドと容易に接続できるので

リアルとWebをつなぐグルーレイヤとして最適というようなお話もありました。
リアルワールドとつなげられると面白そう。


というわけで、Railsの開発面だけじゃなくて、運用面とか、お客さんの反応とか、応用例とか色々聞けて面白かったです。