NewsInsight

互換性や脆弱性の問題にどう対応していくのか

Rubyが抱える課題、NaClの前田氏が講演

2008/09/11

　Rubyの適用用途が広まるにつれ、従来から継続しているコミュニティベースでの開発体制は少なからぬ課題を抱えている。こう指摘するのは、Rubyの生みの親、まつもとゆきひろ氏が勤務するネットワーク応用通信研究所（NaCl）の前田修吾氏だ。日本Linux協会が主催するイベント「Linux Conference 2008」で9月11日に講演を行った前田氏は、10年近くになる自身のRubyとの関わりや、Rubyが現在抱えている課題などについて語った。

10年前のRubyは趣味の利用が中心

　「10年前にRubyを仕事で使うといえば、ちょっとしたスクリプトで……、プロタイピングに……、無知なお客様に内緒で……、むしろ仕事をさぼって趣味で……」。前田氏はやや自嘲気味に振り返る。ここ数年、Ruby on Railsの流行で開発言語として採用されるケースが増えているが、10年前のRubyは「コアな人が『いい言語じゃないか』と注目していた程度」（前田氏）という。

　当時は、Javaもまだ仕事で使われる言語というよりも趣味で触り始める人が多かった。前田氏は、あるときJavaに欠けていた正規表現のライブラリを実装したが、「全然オブジェクト指向的な実装になっていない」とコミュニティの著名人にダメ出しされる。そのとき引き合いに出されたRubyの正規表現ライブラリに触れたのがきっかけで、以来Javaを使わずRubyばかりになったという。

　前田氏のRuby関連の活動は幅広い。

　例えば同氏が提案した仕様や実装は、いくつもRubyに取り込まれている。コンティニュエーションを実現する「call/cc」や、public、private、protectedと3つあるメソッドの呼び出し制限のうちprotected、デバッガの実装などに使われるトレースAPI、時刻オブジェクトを任意のフォーマットの文字列にする「Time#strftime」などがあるという。ライブラリではCのラッパーとして「curses」「readline」やスレッドで排他制御を行う「monitor」、ネットワーク関連では「net/ftp」、「net/imap」などがあるという。ほかにRuby関連のアプリケーションとして、Apache用Rubyモジュール「mod_ruby」や、PHPのようにHTML中にRubyコードを埋め込める「eruby」、Rubyで実装したIMAPサーバの「ximapd」などがある。また現在、Ruby公式サイトや開発用リポジトリの管理・運用も行っているという。

Rubyが普及するにつれて要求がシビアに

　Rubyに深く関わってきた前田氏が指摘するのは、Rubyが普及するにつれて要求がシビアになってきていることだ。「10年前のRubyは、たとえ落ちても誰もあまり気にしなかった。今のRubyは落とそうと思っても難しいというほどなのに、それでも安定していないと言われている」（同氏）。これは、普及期に差し掛かるころのLinuxに似た状況ではないか、という。

　Rubyへの要求は安定性だけではない。性能や互換性、脆弱性への対応、ドキュメンテーションの充実、国際標準化など多方面からのニーズが出てきている。

　性能面では「Rubyは遅い」という批判が根強い。安定版の1.8系でPythonと比較すると、ベンチマークのほとんどの項目で大幅な差をつけられてしまう。これに対するRubyコミュニティやまつもと氏の典型的な反論は、「PCより開発者の時間（生産性）のほうが重要」、「WebアプリケーションではIO性能がボトルネックになっていてCPU はあまり使わない」、「ハードウェアの性能は年々上がっている」、「スケールアウトすればいい」というもので、「実は反論のどれもRubyが速いとは言ってない。遅いのは事実」（前田氏）という。

Rubyが遅い理由

　遅いのにはいくつか理由がある。1つは変数に静的型がなく、コンパイル時に型が決まらないことから最適化が効きづらいこと。しかし、これは動的言語共通だ。ほかにRubyが遅い理由として前田氏はRubyには「関数がなく、すべてメソッドであること」があるという。多くの言語では、トップレベルの関数（メソッド）にはレシーバーがないが、Rubyではトップレベルで関数を定義すると、それは暗黙的にmainオブジェクトの”関数的”メソッドとして定義される。Rubyではすべてがメソッドで、動的束縛を行うためメソッド探索のコストがかかる。Rubyが遅い理由はほかにも、標準で提供されるクラスのメソッドも書き換え可能な”オープンクラス”であるため、例えば「1+1」をコンパイル時に計算してしまうようなことができないという事情があるという。Rubyでは正規表現のマッチングなど一部をのぞいて、プラス演算子などでもユーザーがオーバーライドできるからだ。

　ただ、Rubyは次期開発バージョンのRuby1.9系ではインタープリタをまるごと差し替え、バイトコードを処理するVM を採用したことで多くの最適化を実施し、大幅に高速化しているという。

互換性確保への取り組み

　性能面よりも現在大きな課題となりつつあるのは互換性の問題だ。まつもと氏らが開発するRubyのバージョン間の互換性と、JRuby、IronRuby、Rubinius、MagLevなどのRuby処理系の間の互換性の問題がある。Rubyは仕様が文書化されておらず、「ときどき各処理系の開発者がメーリングリストでまつもとさんに確認している状態」（前田氏）という。またバグか仕様かはまつもと氏にしか分からないこともあり、「しかも言ってることが時々変わっている（笑）」という。前田氏は「ソースコードがドキュメントだ。バグも完全に記述されている」というまつもと氏のハッカーらしい発言を引用して苦笑いする。リファレンスマニュアルに関しても、現在では日本語よりも英語のほうが充実しているのだという。

　本家Rubyでも「RubyをバージョンアップしたらRailsが動かなくなったということがある」といい、バージョン間の互換性が問題になることもある。Ruby 1.8系では仕様を変えるような修正は行わないことになっているが「機能追加と仕様修正は微妙」（前田氏）で、例えば最近、stringクラスにcharsというメソッドを追加して機能拡張を行ったが、すでにRailsが同名のメソッドを別の目的で使っていたために問題が起こるということがあったという。

　互換性を保証するための活動は始まっている。RubySpecは「実行可能な仕様」（前田氏）で、リリース時のテストなどに利用されているフレームワークだという。「英語のような書き方でテストが書ける」（同）のが特徴で、例えばあるコードを実行したときに配列に「123」という値が入るとき、「a.should == [123]」というように書けるという。

　RubySpecはまだカバレッジが充分でなく、また対応プラットフォームもIA32のLinuxと限定されているため、今後はRubyアソシエーションで環境を用意するなどしてほかのプラットフォームへの対応が必要だという。

　Ruby仕様の国際標準化という動きもある。情報処理推進機構（IPA）は9月9日までRubyの国際標準化に関する調査の請負契約を公募しており、まつもと氏や前田氏が所属するネットワーク応用通信研究所も、これに応募したという。同社では、仕様を一から書き起こすのではなく、実装から抽出し、最小限の仕様を文書化するというアプローチを検討しているという。これまでの開発スタイルである「オープンなメーリングリストで仕様について議論する」というRubyコミュニティのあり方に対してマイナスの影響がないようにという配慮だ。

　従来、多くのプログラミング言語は特定の組織や企業に属する少数の設計者が作るものだったが、Rubyは開発者が自由に出入りして、議論の上で開発を進める、いわゆる”バザール方式”がプログラミング言語設計という領域で成功した、歴史上まだ数多くない例と評する声がある。このモデルが機能し続けるためには「Linuxの標準化プロセスが参考になるかもしれない」（前田氏）と考えているという。Linuxの開発では開発者コミュニティがさまざまなアイデアやコードを取捨選択しながら仕様を決定していき、まずデ・ファクト・スタンダードとしての実装がディストリビューションベンダなどから登場する。そうした実装から仕様を抽出したものが「LSB」（Linux Standard Base）として文書化される。また、開発プロセスと標準化が明確に分離されている点も、Linuxのモデルが参考になるのではないかという。

　前田氏は脆弱性報告に、コミュニティとしてどう対応していくべきかというのも、現在Ruby開発者たちが頭を悩ませている問題だと指摘する。2008年に入ってから、Ruby本体やライブラリでいくつか脆弱性が報告されているが、「対応が遅い、不完全、リリースに脆弱性と関係のないバグが入ったことがある、情報公開が不十分」などの課題を認識しているという。Rubyが広く普及するにつれて、ただパッチを公開するだけでは不十分なユーザー層も出てきている。

　こうした品質に関する問題については開発コミュニティと、バイナリパッケージの提供者を分けて考えるLinuxのモデルが有効である可能性もあるという指摘が会場から出ていた。すでにRubyもバイナリパッケージの利用が一般的であることから、各プラットフォームのパッケージ作成者の役割の重要性が増している。

　Linuxのように多様性と統一性をうまくバランスさせたコミュニティとしてRubyは一層の成長ができるのか。日本人メンバーを中心としたRuby開発コミュニティだけでなく、広い意味でのRubyコミュニティが成熟するにはまだ時間がかかりそうだ。

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