NewsInsight

東京の下町でOSS関連のイベントが開催

大江戸Ruby会議：「IT勉強会じゃないコミュニティを」

2011/04/12

　いわゆるIT勉強会ではなく、プログラマが集まってプログラマ集団として成果を出す。そういうコミュニティが作りたかった――。2011年4月10日、東京・深川で行われたRuby技術者（Rubyist）の集まり「大江戸Ruby会議01」の基調講演で挨拶した松田明氏は、浅草を中心に取り組んできた地域のRuby技術者のコミュニティ作りに込めた思いを、こう述べた。

成果を出すプログラマ集団のための場を

　大江戸Ruby会議は、札幌、名古屋、仙台、東京、関西、九州などで年に数回行われている“地域Ruby会議”と呼ばれるイベントの1つ。参加者数こそ約80人とRubyKaigiやRubyConfなど内外の年次イベントより小規模だが、オープンソースコミュニティの1つのあり方を示すお祭りであり、交流会でもある。

　開催メンバーは「地域Rubyist集団の生活発表会みたいなものです」と趣旨を説明する。“生活発表会”というのは多分に自己諧謔的な表現だが、確かに自社でのRubyを使った取り組みの紹介やノウハウの共有といった発表が多かった。

　大江戸Ruby会議の企画・運営から発表までを中心となって行った地域Rubyコミュニティ「Asakusa.rb」は、Rubyコミュニティの中でも少し特異な存在だ。

　Ruby本体の開発に携わっている“Rubyコミッタ”と呼ばれる開発者が数多く参加していて、Rubyの生みの親であるまつもとゆきひろ氏も、ふらりと週次ミートアップに遊びに来ることもあるというコアなRuby技術者集団だ。このAsakusa.rbの発起人で、今回の大江戸Ruby会議で基調講演を行った松田明氏は、こうした“コア”な人々が集まっている理由は、近隣にRuby開発者が多かったということもあるが、当初から戦略によるものだという。Asakusa.rbをスタートさせた2008年頃には、「日本ではRubyコミッタはRubyを開発しているけど、みんなで集まって何かを作るという場がなかった」と振り返る。

　「海外だと、もっといきいきしたコミュニティもある。Asakusa.rbがモデルとして参考にしたSeattle.rbは、（Rubyのライブラリである）gemsをめちゃくちゃたくさん出している。皆さんが使っているもののかなりの割合がSeattle.rbから出てきている」（松田明氏）

　日本のIT業界、特に東京ではブームと言えるほど勉強会が盛んだ。しかし「Asakusa.rbは勉強会みたいなものでしょと言われることがあるが、それは違う」（松田氏）という。「勉強会でもセミナーでもないので、来ても何の勉強もできない。1人1人が黙々と何かを開発する場所でもない。自分がRubyを良くしたい、Ruby界に貢献できたらいいなというのがモチベーションで、勉強会とはベクトルが違う。先生がいてお客様がいるセミナーでもないので、お客様は来ないでください。仲間を探している人が来てください。最近のAsakusa.rbは雑談で終わることも多いが、プログラマが集まって、プログラマ集団として成果を出すという場にしていきたい」（同氏）と、意欲のある開発者の参加を呼びかけた。

「Fork Ruby！」、もっと違う種類のRubyを

　Ruby 1.9で使われているVMの作者で、Asakusa.rbメンバーの笹田耕一氏は、「Rubyには、まだまだ可能性がある」と、Rubyのバリエーションについてジョークネタを交えて発表した（資料）。

　例えば、速度と安全性が必要な場合、型を付けたいところだけに付けて高速化のヒントにする「Optionally-typed Ruby」や、関数型ベースの「Closure-based Ruby」、並列処理を取り入れた「Parallel Ruby」、処理系がエラーで止まらない（SEGVしない）「Dependable Ruby」などに言及。また、急激に増えつつあるデジタルガジェットのようなデバイスに対して「Rubyでひょいひょいと書けるといいんじゃないというのは誰でも思うわけです」と組み込み向けRubyの可能性にも触れた。組み込み向けRubyは、すでにまつもと氏の取り組みがあるほか、笹田氏が在籍する東京大学大学院情報理工学系研究科 創造情報学専攻の研究室でも、Linuxカーネルのようにモジュールごとに選択可能にして、「アプリが使う機能を半自動的に判別して組み込んだり組み込まなかったりするコンパイラ」に取り組んでいる学生がいるという。

　Rubyはバージョン1.8から1.9になるときに、処理のモデルをガラリと変えてVMを採用した。このVMを設計・実装したのが笹田氏だが、まるで他人事のように「速いRubyは欲しいなと思っている。VMを書き直したい」とも話す。AOTコンパイラやGCの性能向上、Rubyのコード中に文単位でCを混ぜられる「Ricsin」、GPGPUの活用など、パフォーマンス向上の可能性は、まだまだ残されているという。

1日数億のアクセスをさばく配信サーバも

　JRubyとCRuby双方のコミッタである中村浩士氏は、「大江戸HTTPクライアント絵巻」と題して発表。Rubyで使われるHTTPクライアントのライブラリの数は非常に多い。中村氏は、こうしたライブラリの特徴や機能の有無などを横長の巻物風の一覧表にまとめて紹介した。自身がライブラリ「httpclient」の作者で、セキュリティの専門家でもあることから、HTTPライブラリに必要とされる機能、セキュリティ要件、APIなどを詳細に評価した資料は圧巻で、あまりの徹底した調査ぶりに会場からはどよめきが起こっていた。

　Ruby/Railsベースの広告配信システム「ScaleAds」を開発し、導入コンサルティングを行っているスケールアウト代表の山崎大輔氏は、RailsとCの組み合わせで「1日に数億のアクセスをカジュアルにさばく」と豪語する。高トラフィック対応の広告配信ソリューションの高額さに辟易している企業に向けて開発したシステムといい、特徴はPCサーバ1台で1日に5000万アクセス以上の性能が出せることだという（発表資料）。

　通常、広告配信サーバはRDBMSとLLで構成されることが多いが、「これでは1桁性能が落ちる」といい、ScaleAdsでは配信サーバはCとRuby、Swigで書いたという。広告案件の管理や配信、集計などの部分はRailsで作ったが、広告データは共有メモリ上に置いて複数プロセスがデータをやり取りする構成にしたという。管理画面から広告データを操作すると、共有メモリ上に反映され、それを多数のApacheが配信するというシステムだ。管理DBから共有メモリへの書き出し部分には、アップデート用のDSLを使っているという。

　山崎氏は「アーキテクチャさえしっかりしていれば、ほとんどの部分はRubyでいける」といい、ログの一次集計についても、Apacheのログ形式の工夫やMapReduce的な分散処理により、「Rubyでも間に合っている」とする。

　なぜRubyを選んだのかという点について山崎氏は、会社立ち上げ時の2006年に、良いORMを探していたところ、Railsに行き着いたのだと説明する。PerlのCatalystを試したものの、「CPAN地獄にはまり挫折」（山崎氏）したという。PHPやJavaには、フィールドを手で記述しないと動かないものなど当時は良いORMがなかった。一方、Ruby on RailsのORMはインストールが簡単だったという。Rubyを選んだのは、ある種の偶然でもあったようだが、その後は、Rubyコミュニティのハッカーが加わるなどベンチャーとして「異様に人に恵まれた」と話していた。

16分を50秒に高速化！ クックパッドのテスト事情

　Railsで運用するシステムとして世界的にも規模が大きいことで知られているクックパッドの舘野祐一氏は、自社でのテスト高速化の取り組みについて紹介した（資料）。比較的高速なマシンですら16分かかっていたテスト時間を、1台10万円程度のCorei7、メモリ16GB、SSDというマシンを4台用意してリモート実行させることで32並列処理まで実現。最終的に16分だったものを約50秒と、20倍程度高速化したノウハウを紹介した。

　テスト用のハードウェアを用意するとなると力技のようだが、実際にはCRubyの代わりにREE（Ruby Enterprise Edition）を使って1.45倍の高速化をしたほか、テストの並列化で4.57倍高速化するなど工夫の積み上げで実現した。REEは元々copy-on-write-friendlyパッチを取り入れた省メモリがウリのRuby処理系として知られているが、実はパラメータの調整がやりやすく、ヒープサイズを大きく取ることで、メモリは余計に食うけれども処理は速いというコンフィギュレーションが可能なのだという。

　このほか舘野氏は、分散環境でSpecが実行できるライブラリ「Spork」の問題点を解決するために作った自作ライブラリの「Prefetch-rspec」や、分散並列でSpecを実行するときの戦略を紹介。実行時の所要時間を各Specごとに残しておいて、これをソートしてSpecの振り分け方をインテリジェントに決めているなどの工夫を説明すると、聴衆から「そこまでやったのか！」というニュアンスの小さな賛嘆の声が上がっていた。

　1回のテストにかかる時間が長くなると、全体テストを通さずにリポジトリにコミットするケースが出てプロジェクトが混乱することがある。このため、テスト時間短縮は大きなテーマだ。ただ、実際にはテスト環境の構築・改善には手間がかかるので、並列・分散テスト環境を取り入れているプロジェクトは少数派ではないだろうか。さまざまなツールを試して試行錯誤したクックパッドの例は、こうしたプロジェクトで同様の取り組みをする際には参考になるのかもしれない。

JavaScript部分もうまくテストするノウハウ

　永和システムマネジメントの柴田博志氏が行った発表も、テスト時間の短縮という点で興味深い（資料）。Railsのエンドツーエンドのテストフレームワークとしては「Capybara」が広く使われているが、このCapybaraを、どの“Webドライバ”と組み合わせて使うかという点ではジレンマがあるという。JavaScriptは動かないが高速な「Rack」、そこそこの速度でJavaScriptも動く「HtmlUnit」、JavaScripがきちんと動く「JavaScript Engine」、処理は最も遅いがブラウザを起動して自動テストができる「Selenium」など、どれも一長一短だからだ。このため、JavaScriptの利用量によっては、そこだけ例外的に手動でテストしようということになりがちだ。しかし、「ここはJSだから手で押そう、というのをやってると、だいたいそこがバグになる」（柴田氏）のだという。

　実はCapybaraのWebドライバは、DSLを書いて動的に切り替えることができ、テストケースによって上記のドライバを使い分けて実行させることができるという。Capybara自体はデファクトとなりつつあるものの、Webドライバを動的に変える使い方はまだ少数派のようで、柴田氏の発表は、多くの参加者の参考となったようだ。

　このほか、100プロセス×100スレッド構成で“ミッション・クリティカル”なシステムをRubyで構築したというケーシーエスキャロットの江森真由美氏（資料）や、Rubyによる開発で、どうすればコードをクリーンに保てるのかを解説した赤松祐希氏の発表（資料）など、どれも実務指向の強い発表内容だった。

　大江戸Ruby会議は、Rubyを使って仕事をする人々がノウハウを共有するというオープンソース的なコミュニティの場だ。Ruby on Railsを取り巻くコミュニティは、特定ベンダが“ソリューション”としてフレームワークやツールを提供し、それを使う顧客がいるという世界とは様相が異なる。自分たちで作り、ノウハウを共有し、コードで貢献することで環境を変えていくというダイナミズムがある。日本はRailsではむしろ後発組といえるのかもしれないが、大江戸Ruby会議は、そうしたオープンソース的な熱っぽさも感じられるイベントだった。

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）