RubyKaigi 2011 メモ (1 日目)

7 月 16 日から 18 日まで開催された RubyKaigi 2011 に参加してきました。非常に楽しく、ためになる 3 日間でした。

セッションをきいている間、メモをとっていたので (多少整形して) 公開します。

理解できていない部分、誤って理解している部分、抜けている部分など多々あるので、備忘録としての役割が主です。これを読んで気になる部分があれば、他のレポート (RubyKaigi2011 スペシャルレポートとか) を読むなり、ust みるなり、登壇者が発信してる情報をさがすと良いと思います。

Ruby Ruined My Life.

  • @tenderlove / Aaron Patterson
  • (自然) 言語を勉強するとき別の名前を使う
  • 自分じゃないから間違えても恥ずかしくない!
- Ruby の場合
  • 部分ごとに担当をきめる
  • 低リスク
  • コメントなどが英語でなくてもかまわない
  • 言語の壁で、コミュニケーションがとれないときが。
  • 縦割りだから、作業が人に依存する→開発速度の低下。
  • 添付ライブラリは gem になってる
    • 別のチームになって
- Rails core
  • コミッタはすべてに関与できる。
  • 便利だけど、各パートのオーナーがいないので、強い意見を持ちにくい。
  • リリースにも誰も責任を持たない。
  • 高リスク
    • バックポートされないことも
- feel free to commit - feel free to revert - responsiblity to communicate - 特定の分野のための Ruby 本が US にはない
  • racc の本とか
  • 言語の習得はできても、何が作れるのかわからない
- ASCII8bit * マルチバイト だと変なことに? - ネットワークでクラスロード
  • ?load_path に URL 追加で
- DTrace
  • probe
  • ruby / スクリプトによる allocate や method calll を見られる。
- Learn / Teach / Communicate / Take risk ### Next version of Ruby 1.8 and 1.9 - 1.8 に未来はない。 - 1.9.3
  • 実装でいろいろ改良がたまってきたのでそろそろ安定版リリース。
  • parallel_test
  • IO.write
  • プライベート定数
  • GVL
- License
  • これまでは、狭義のRubyライセンス / GPLv2 の好きなほう
  • GPLv3 は GPLv2 非互換
  • 狭義の Ruby ライセンス / 2-clause BSDL に
    • 2-clause BSDL は GPLv2 / GPLv3 互換
    • これにより明確に BSDL ライセンス互換。BSD で明確に使える。
- private constant
  • private method みたいな constant が使える。
  • constant なので、クラスやなんやも private にできる。
  • クラスオープンや const_get ならもちろんアクセスできる。
- Test::Unit
  • ruby のテストには使われてる
  • Master / Worker を作って並列化
- IO.write - String#prepend - GVL
  • 大量にスレッドつくると遅くなってたのを改善。
- IO.advise
  • posix_fadvise(3) の wrapper
  • IO.advise(:dontneed) でページキャッシュを捨てる
  • バックアップ時などに無駄にメモリ食うのを改善
- Timer スレッド
  • ruby 走らすと、2つスレッドがたつ
  • Timer スレッドはスケジューリングとかする
  • Timer は 10ms ごとに必ず動くので、何もしてなくても CPU が眠れない
  • 改善により消費電力ちょっと減った
- 既知の問題
  • Passenger が動かない
    • 変なコード書いてるため
    • file descriptor 関係で

Ruby を利用した大規模 web サービスの開発・運用

参照: Ruby を利用した大規模ウェブサービスの開発・運用 ? RubyKaigi 2011 発表資料 ? クックパッド開発者ブログ

  • 12,300,000 uu
  • 1000000 recipes
  • 30代女性の2人に1人
- mobarepi
  • ケータイ、スマホ向け
  • ユーザー多し
- iOS app
  • 2.5 milion DL
- [tabemiru](http://tabemiru.com/)
  • cookpad のログと位置、地域情報の結びつけ
- 環境
  • ruby 1.8.7 / rails 2.3
  • 「サーバ/インフラを支える技術」にあるような標準的な構成
- app server
  • haml / sass / jQuery
  • passenger 2.2
  • mysql 5.0
  • memcached で rails のインスタンス変数をキャッシュ
  • [varnish 2.1.5](https://www.varnish-cache.org/)
    • キャッシュ
    • ヒットすれば 30ms 程度で
- 写真サーバ
  • aws
  • url でリサイズやクロッピング指定。
  • アップロードサーバ
    • ec2
    • rails 3 -> s3
    • リサイズや検証
  • デリバリサーバ ec2
    • apache 2.2
    • akamai
- 検索
  • [Solr](http://lucene.apache.org/solr/)
  • かつては mysql + trironn
  • 柔軟な検索
  • facet 集合 / boost 重み付け / dynamic fields 動的フィールド
  • 速くなった、というわけでなく変更に強い
  • ログはs3に送る
- tabemiru
  • 統計処理
  • ec2? / hadoop
  • aws の elastic map_reduce (mapper / reducer は ruby)
  • スケールアウトできるので、ruby が遅くても問題ない
- アプリケーションサーバからのレスポンスは < 200ms - 定石をきちんと - good はやらない、best のみに。機能の追加は慎重に。
  • 本当に必要な機能のみに絞る。
- シンプルにする
  • キャッシュにのりやすい
  • クエリーがシンプルに
- 遅延ロード
  • ユーザー固有の情報は非同期でロードする
  • はじめのページは 30ms、続けて 200ms。
- 「ウェブオペレーション」にも記事あり - 開発体制
  • cookpad は 30人以上の rails engineer
  • rails で多人数開発
  • 開発 -> デプロイ -> フィードバック ... のサイクル
- テスト
  • rspec 1.x
  • unit / functional / integration
  • 以前より integration をだいぶ重視。unit も。
  • integration だと js もテストできる。
  • [capybara-webkit](https://github.com/thoughtbot/capybara-webkit)
- スペック増えるとテスト時間かかる
  • テストをリモートで行う。
  • remote spec
  • rsync でソースを同期、ssh で結果取得
  • oedo rubykaigi01 で詳細
- デプロイ
  • CI (continuos integration) のビルドが通るか
  • [jenkins](http://jenkins-ci.org/)
  • テスト通らないとデプロイできない。
  • 新しい技術を入れる -> CI で動くテストを書く。
  • Ruby 勉強会@札幌 で詳細 ([http://d.hatena.ne.jp/secondlife/20110704/1309759409](http://d.hatena.ne.jp/secondlife/20110704/1309759409 "継続的インテグレーションについて、Ruby勉強会@札幌-18 で発表しました - 川o・-・)<2nd life"))
  • デプロイの通知
    • デプロイ時に必ずメッセージ記入
    • スタッフに通知される
- エラーのモニタリング
  • rails / js のエラーログ
  • バースト検知
    • エラーを 0 にするのは難しい
    • 急激に増えたときにアラート
- Extentions
  • rails のプラグイン
  • ある機能を Extention としてひと塊にして記述できる
  • 一部ユーザにのみ限定公開など可能
  • プロトタイプ開発向き
  • これ使う場合は spec を書かなくてもよいこととする
  • 捕捉してない例外が発生したら 自動で無効化する
  • 利用の統計、ユーザーからのフィードバックをとる
  • 1 つの Extention は下記のように配置
    • /app/extensions/some_ext
      • some_ext.rb
      • spec
      • views
      • controllers
      • ...
  • 使わないと決定したら、独立して無効化・削除できる
  • 参照: [どんどん使う ? Extension Frameworkの紹介 ? クックパッド開発者ブログ](http://techlife.cookpad.com/2011/07/15/extension-framework/)

Ruby 用のリアルタイムプロファイラ

参照: RubyKaigi2011で発表しましたよ | sunagæ.net

  • オーバーヘッド大きい
  • 終わらないと測定できない
- llprof
  • ProfilingModule を include することで使える
- 構成
  • App (include Profiling module) - Profile Information Server - Web Server
  • プロファイラの情報をためるサーバを起動
  • サーバからプロセスにアクセス?
- View
  • ノードごとツリービュー
  • メソッドごと消費時間
  • 面積比例表示
  • 時系列グラフ表示
- 利点
  • リアルタイム
  • 気になったときに見られる
  • 動かしながら見られる
  • たとえば Web アプリで連続してリクエスト送ったとき、どうなるかが見られる
  • ネットワーク越しに見られる
  • Web ブラウザから見られる (JavaScript 動けば OK)
  • calling context 込みで見られる
    • メソッドごとに見られるだけでなく、そのメソッドがどこで呼ばれたかでも見られる
  • オーバーヘッド低い
    • profiler に優しくない事例で、実行時間の4倍程度
- 実稼働している Web アプリで使った例
  • http://www.arrow-arrow.com/
    • メッセージをランダムに送る、ランダムにきたメッセージに返信する。
    • 返事が早い、確実にくる、ことが売り。
    • F5アタック的な状態がデフォルト。
    • python で作成!
  • 言語非依存なので python でも
  • 追加した機能
    • リクエストごとにプロファイリングできるように
    • 複数プロセスからの情報を集約する
  • 複数稼働しているうちの1つのwebサーバでプロファイリング
  • リクエストごとに処理するため、プロファイラに「ここから」「ここまで」と伝える処理だけ追加
- 最新版は XML でダンプできる

Toggleable Mocks and Testing Strategies in a Service Oriented Architecture

  • @adelcambre
  • Engine Yard
  • SOA

    • unix の単一責任の原則
    • コードみじかい
    • それぞれの部品を別々にデプロイ
    • 並行開発
    • SSO (シングルサインオン)
    • 他のサービスがユーザーの概念をしらなくても OK
  • テストどうする

    • むつかしい
    • サーバとクライアント
    • サーバに
  • モックを使わない

    • 本物のサーバ側アプリケーションを使う
    • 簡単
    • カバレッジ高い
    • 遅い
    • 1 テストごとに初期化が必要
  • Mock

    • 本物のように振る舞う
    • どのメソッドが呼ばれるか知ってる
  • Stub

    • メソッドを仮のデータで置き換えるもの
  • Fake

    • メモリに格納された SQLite データベースなど
    • ほぼ本物だが、本物にはつかえない
  • Stub を使う

    • 速い
    • 内部をテストできない
  • Fakeweb

    • https://github.com/chrisk/fakeweb
    • net/http のスタブ
    • http サーバのスタブ
    • method, url, response を登録して使う
    • http レイヤーをテストできる
    • 内部実装をしりすぎ
  • フェイクをライブラリに組み込む

    • (よくわからん)
    • http レイヤーでない
  • artifice

    • https://github.com/wycats/artifice
    • rack アプリ
    • net/http のスタブとして使う
    • http レイヤーはフェイク
    • 実際にサーバ立ち上げる場合と同じテストがかける
    • カバレッジ高い
    • 実装を知らなくてよい
      • env で mock を使うかどうか決めれる
      • mock を使ったスペックが早い。
      • 本物のサーバに替えることもできる -> integration テストが正しくできる
      • テストを書き換えなくてよい
      • 双方のテストが通らないとデプロイしない
      • CI でフェイクを認証する必要あり
      • サービス側がフェイクを提供? ライブラリに含めてかな?
      • テストのたびにクリーンアップしないといけない
      • ユニークデータの衝突 : 同時に実行する時
      - サーバは rack アプリ
    • サーバコードを fake として使うことも?
  • (スライドは showoff で作成)

軽量 Ruby

  • @yukihiro_matz
  • Rite VM
  • Rite または mruby (embeded ruby)
  • Core: C99
  • Minimal (配列とかまで): C99
  • JIS X 3017 (JIS Ruby): POSIX
  • ソフトリアルタイム

    • ハードリアルタイムはなくてもソフトではほしい
    • GCで止まっては困る
  • FPGA による汎用CPUコア

    • メソッド検索や GC 用の命令を追加
  • コンポーネント

    • ruby コード -コンパイラ-> 構文木 -コードジェネレータ-> バイトコード
    • 全部入りでも、バイトコードを実行できるランタイムだけでも
  • Minimal とかのほかに、プラットホーム依存ライブラリの追加も

  • C でライブラリインクルードして、open、read_string、run で実行

    • Lua的
  • 用途

    • 機器組み込み
    • アプリ組み込み
    • ゲーム組み込み
    • node.rite (node.js みたいな、minimal なら IO とかないし)
  • 福岡CSK、九州工業大

  • 利用法はみんなかんがえて!

  • ほぼ C だが、ブロックをとるメソッドは Ruby で書かなくちゃいけない (バイトコードにしてリンクする)。

  • Rite VM は ruby の大きめのサブセット。rite にだけある機能、というのはない。

  • ライセンスは未定、組み込みは BSD が多いので BSD だけど、事業化を考えると GPLv2 / v3 か。Ruby ライセンスはつく。

日本の図書館はどのように Ruby を使っているか

参照: RubyKaigi2011「日本の図書館はどのようにRubyを使っているか」資料集 - 簡単な日記 はてな仮店舗

  • @nabeta
  • まちづくり三鷹 「ruby 図書館システム」
  • リブネット 「トップネット」
  • 全部 rails
  • 利用者向けの検索UIと
  • 司書向けの検索UIが必要 : 詳細な絞り込みが必要
  • Next-L Enju

    • Rails + HE のサンプルで、使えそうと判断
    • REST を備える図書館システム増加 (えー)
    • OCLCとか。
  • 問題

    • 遅い! join が多い。
    • フラグメントキャッシュで対応
    • フラグメントキャッシュの適切なテストの方法知ってたら教えて
    • 貸出・返却処理は速度重要!
    • ajax 利用、過剰な validation けずる。
  • HE -> Solr へ

    • acts_as_solr -> sunspotへ
  • カードリーダ使って貸出・返却

  • 物質・材料研究機構は夏公開

  • NDL Search

    • モジュールの一部に Next-L Enju。
    • 書誌5800万件
    • 資料の自動同定処理
  • 商用のパッケージでは

    • FRBR、Web API へ対応してない
    • 改修は高額
  • 成果物をオープンソースソフトウェアとして公開できること

  • 主にフロントエンドを Next-L Enju で

  • 管理画面

    • 書誌のコピーやら、利用統計やら
  • 書誌を XML (DCNDL) で持つ

    • psql の TEXT に
  • Solr

    • sunspot -> rsolr
    • Solr のインデクス作成は Java + Hadoop で。書誌同定もおなじく。
  • 10 年前から ruby が使われていた例

    • 神戸市図書館情報ネットワーク
    • ruby + gtk
    • 90% が Ruby。のこりは C と Emacs Lisp!
    • 書誌登録時、emacs が起動して、Emacs Lisp で検証したり
  • Ruby の利点

    • 図書館員が多少は改修できる
    • 日本語の情報をえやすい

Ruby で作った "mission critical" システムについて

  • @emorima
  • KCS carrot
  • CGIKit -> RoR
  • daemon process
  • mission critical

    • 24/365 動かす、止まってはならない
    • relilability
  • 某システム

    • (100 thread / process) * 100
    • UDP socket
    • センサーからのデータをリアルタイムに集めたい
  • スレッド動かない

    • file descriptor 上限を超える
    • 一般ユーザの上限かかるので su で動かした
  • UDP Socket のタイムアウト

  • 計算処理

    • C で
  • process 数

    • プロトタイプ時は 3 種
    • リニューアル時は 230 プロセス!
    • C で 230 も書くのは嫌。Ruby だと結構楽しい。
  • ruby だと thread と socket の扱いが楽

  • 意外と大規模システム向き

闇 RubyKaigi

  • VDD! VDD!