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 発表資料 ? クックパッド開発者ブログ

• id:secondlife / @hotchpotch
• Cookpad

• 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

• sasada lab. の 須永高浩 氏
• @sunagae
• http://sunagae.net/software/llprof
• ドキュメントなかったりするので、困ったらメールでも
• ruby-profile

• オーバーヘッド大きい
• 終わらないと測定できない

- 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 のタイムアウト

  • timeout module-> 10000 errors!
  • select を使って解決?
  • 自前で監視
  • 大江戸Ruby会議01　"mission critical"なシステムでも使えるThreadの作り方
  • スレッドが落ちても再起動する仕組み

• 計算処理

  • C で

• process 数

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

• ruby だと thread と socket の扱いが楽

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

闇 RubyKaigi

• VDD! VDD!